推动 DevOps 变革的 3 个领域

推动大规模组织变革是痛苦的，但当涉及到 DevOps 时，回报是值得付出痛苦的。

图片来自

Monsterkoi。由 Opensource.com 修改。CC BY-SA 4.0

避免痛苦是一种强大的动力。一些研究暗示，甚至植物也会体验到某种痛苦，并采取措施保护自己。然而，我们有很多人类为了某种目的而忍受痛苦的例子——锻炼通常会很痛苦，但我们仍然会去做。当我们相信回报是值得付出痛苦的时候，我们几乎可以忍受任何事情。

事实是，推动大规模组织变革是痛苦的。对于那些不得不改变价值观和行为的人来说是痛苦的，对于领导层来说是痛苦的，对于那些只是想做好本职工作的人来说也是痛苦的。但在 DevOps 的情况下，我可以告诉你，这种痛苦是值得的。

我亲眼目睹了团队如何学习他们必须花时间改进技术流程，掌握自动化管道的所有权，并成为自己命运的主人。他们获得了成功的工具。

Improvements after DevOps transformation

这张图表显示了变革的价值。在我指导 DevOps 转型的一家公司中，其 60 多个团队每月向发布管理部门提交 900 多个请求。如果将这些工单保持打开状态的时间加起来，每月超过 350 天每天。贵公司每月增加 350 人天的工作量能做什么？除了上面看到的改进之外，他们的部署量从每月 100 次增加到 9,000 次，高危错误减少了 24%，工程师更快乐，净推荐值 (NPS) 也得到了提高。《Puppet DevOps 现状报告》预测，最大的 NPS 改进与 DevOps 旅程中最远的团队有关。最重要的是，对技术流程改进的投资转化为更好的业务成果。

DevOps 领导者必须关注三个主要领域来推动这种变革：高管、文化和团队健康。

高管

最重要的是，对技术流程改进的投资转化为更好的业务成果。

您的组织越大，业务领导层与向客户提供服务的个人之间的距离（和误解的机会）就越大。更糟糕的是，技术工具和实践的格局正在加速变化。这使得业务领导者实际上不可能独自理解像 DevOps 或敏捷这样的转型是如何运作的。

DevOps 领导者必须帮助高管参与进来。教育领导者在他们做出决策时为他们提供选择，并使他们更有可能选择有助于贵公司的道路。

例如，假设您的管理人员认为 DevOps 将改善您将产品部署到生产环境的方式，但他们不理解如何改进。您一直在与一个软件团队合作，以帮助他们实现部署自动化。当一位高管听到部署失败（并且会发生失败）时，他们会想了解它是如何发生的。当他们得知是软件团队而不是发布管理团队执行了部署时，他们可能会试图通过规定所有生产版本都必须通过传统的变更控制来保护业务。您将失去信誉，团队将不太可能信任您并接受进一步的更改。

在事件发生后重建与高管的信任并获得他们的支持，比一开始就教育他们花费的时间更长。预先投入时间建立一致性，当您实施战术性变更时，它将获得回报。

在建立这种一致性时，有两条建议

首先，不要忽视他们提出的任何限制。如果他们担心合同或安全问题，请让法律和安全主管成为您新的挚友。通过与他们合作，您将建立他们的信任并避免犯下代价高昂的错误。
其次，使用指标在您的交付团队正在做的事情与您的管理人员的担忧之间架起一座桥梁。如果企业的目标是减少客户流失，并且您从研究中了解到，许多客户由于计划外停机而离开，请强调您的团队致力于跟踪和改进平均检测时间和平均恢复时间（MTTD 和 MTTR）。您可以使用这些关键指标来展示团队和高管理解并支持的有意义的进展。

文化

DevOps 是一种持续改进的文化，专注于代码、构建、部署和运营流程。文化描述了组织的价值观和行为。本质上，我们谈论的是改变人们的行为方式，这绝非易事。

我建议阅读CIO 外衣下的狼。花时间思考心理学和动机。阅读驱动力，或者至少观看 Daniel Pink 的精彩 TED 演讲。阅读千面英雄，并学会识别每个人正在经历的不同旅程。如果这些事情都没有让您感兴趣，那么您就不是推动公司变革的合适人选。否则，请继续阅读！

本质上，我们谈论的是改变人们的行为方式，这绝非易事。

大多数理性的人都按照自己的价值观行事。大多数组织没有每个人都理解和遵守的明确价值观。因此，您需要识别导致当前状态的行为的组织价值观。您还需要确保能够讲述这些价值观是如何产生的，以及它们是如何将您带到今天的境地的故事。当您讲述这个故事时，请注意不要妖魔化这些价值观——它们不是不道德的或邪恶的。鉴于他们当时所知道的和所拥有的资源，人们已经尽力而为了。

解释说公司及其组织目标正在发生变化，团队必须改变其价值观。以对比的方式表达这一点很有帮助。例如，贵公司可能历来最重视成本节约。这种价值观的存在是有原因的——公司当时资金短缺。为了推出新产品，基础设施团队不得不通过共享数据库集群或服务器来紧密耦合服务。随着时间的推移，这些做法造成了一个真正的混乱，变得难以维护。简单的更改开始以意想不到的方式破坏事物。这导致了严格的变更控制流程，这对交付团队来说很痛苦，因此他们停止了更改。

如果这部电影播放五年，最终你会发现几乎没有创新、遗留技术、人才吸引和保留问题以及劣质产品。您已经发展了公司，但您已经达到了瓶颈，并且无法继续以相同的价值观和行为方式发展。现在您必须将工程效率置于成本节约之上。如果一个选项可以帮助团队更轻松地维护其服务，而另一个选项在短期内更便宜，那么您应该选择第一个选项。

您必须一遍又一遍地讲述这个故事。然后，您必须庆祝团队通过他们的行为表达新价值观的任何时候——即使他们犯了错误。当团队部署失败时，祝贺他们承担风险并鼓励他们继续学习。解释他们的行为如何导致正确的结果并支持他们。随着时间的推移，团队会看到这个信息是真实的，他们会感到安全地改变自己的行为。

团队健康

您是否曾在计划会议中听到过类似这样的话：“在 John 度假回来之前，我们无法真正评估这个故事。他是唯一一个非常了解该代码区域的人。” 或者：“我们无法完成这项任务，因为它与网络工程存在跨团队依赖关系，而设置防火墙的那个人生病了。” 或者：“John 最了解该系统；如果他将这个故事估计为 3，那么我们就用 3 吧。” 当团队处理这个故事时，最有可能做这项工作的人是谁？没错，是 John，循环将继续。

长期以来，我们已经接受这只是软件开发的本质。如果我们不解决这个问题，我们就会延续这个循环。

熵总是会自然而然地将团队推向混乱和不良健康状态。我们作为团队成员和领导者的工作是，有意识地管理熵，并保持团队的健康。像 DevOps、敏捷、迁移到云或重构遗留应用程序这样的转型都会放大和加速熵。那是因为转型增加了团队承担新型工作所需的新技能和专业知识。

熵总是会自然而然地将团队推向混乱和不良健康状态。

让我们看一个产品团队重构其遗留单体应用的例子。像往常一样，他们在 AWS 中构建这些新服务。遗留单体应用部署在数据中心，由 IT 部门监控和备份。IT 部门确保应用程序的信息安全要求在基础设施层得到满足。他们进行了灾难恢复测试，修补了服务器，并安装和配置了所需的入侵检测和防病毒代理。他们还保留了变更控制记录，这是年度审计流程所要求的，记录了对应用程序基础设施所做的一切。

我经常看到产品团队犯一个致命的错误，认为 IT 完全是成本和瓶颈。他们渴望摆脱 IT 的束缚并使用公共云，但他们从未停止欣赏 IT 提供的关键服务。迁移到云意味着您以不同的方式实施这些事情；它们不会消失。AWS 仍然是一个数据中心，任何使用它的团队都接受相关的责任。

实际上，这意味着产品团队在迁移到云时必须学习如何执行这些 IT 服务。因此，当我们的虚构产品团队开始重构其遗留应用程序并将新服务放入云中时，它将需要大大扩展的技能组合才能成功。这些技能不会神奇地出现——它们是学习或聘请来的——团队领导者和经理必须积极管理这个过程。

我构建了 Tekata.io，因为当我帮助我的团队发展时，我找不到任何工具来支持我。Tekata 是免费且易于使用的，但该工具不如人员和流程重要。确保您将持续学习融入到您的节奏中，并跟踪团队的薄弱环节。这些薄弱环节会影响您的交付能力，而弥补这些薄弱环节通常涉及学习新事物，因此这里存在着奇妙的协同作用。事实上，76% 的千禧一代认为职业发展机会是公司文化最重要的要素之一。