解决 DevOps 转型中最重要的议题

您已被任命为贵组织的 DevOps 倡导者：恭喜。那么，您需要解决的最重要的问题是什么？

是技术——工具和工具链——对吗？每个人都知道，除非您为工作找到合适的工具，否则您永远无法使事情正常运转。您需要与现有堆栈集成（尽管您是选择紧密集成还是松散集成将是一个有趣的问题），一个支持计划（供应商、第三方或内部），以及一个错误跟踪系统来配合您的源代码管理系统。而这仅仅是个开始。

不！别傻了：显然最重要的是流程。如果团队在站立会议如何进行、谁参与、会议的频率和时长以及法定人数需要多少人方面没有达成一致，那么您将永远无法建立一致的、可重复的工作模式。

事实上，尽管技术和流程都很重要，但还有第三个组成部分同样重要，但通常更难做好：文化。是的，就是我们技术人员倾向于难以应对的那种情感化的东西。¹

文化

几个月前，我拜访了一家中型政府机构（碰巧不在英国），我们提前一点到达，与 CEO 和 CTO 会面。我们被领到 CEO 的办公室，等了一会儿，他们两人才结束了每日站立会议。他们为迟到了一两分钟道歉，但我非但没有被冒犯，反而印象深刻。这是一个参与文化显然渗透到最高层的组织。

并非文化可以从上而下强加，也不能指望它从下而上渗透³，但这两位 C 级高管不仅在为他们的团队其他成员树立他们期望的行为榜样，而且从我们之后就该流程进行的简短讨论来看，他们似乎也真正投入其中。如果您能让管理层认同该流程——并且被看到认同——那么您至少不太可能遇到其他团队找到合理的借口来保持距离并蒙混过关的问题。

那么，让我们假设管理层认为您应该尝试一下 DevOps。您从哪里开始？

开发人员，勾选？⁵

开发人员很可能成为您最容易实现的目标群体。他们通常渴望尝试新事物并找到更快推进事情的方法，因此他们通常是期望采用新技术和方法的群体。DevOps 可以说是主要由开发社区推动的。

但是您不应假设所有开发人员都会热衷于接受这种改变。对于某些人来说，事情一直以来的方式——如果您愿意，可以称他们为开发界的瑞克·帕菲特⁷——就很好。找到帮助他们在新的世界中高效工作的方法是您的工作的一部分，而不仅仅是他们的工作。如果您有不乐于接受改变的超级明星开发人员，如果您试图强迫他们进入您美好的新世界，您可能会冒着疏远和失去他们的风险。更糟糕的是，如果他们固执己见，当他们向他们的经理解释说，如果事情让他们的生活更加困难并降低他们的生产力，事情就不会改变时，您可能会冒着您的 DevSecOps 愿景的采用受到损害的风险。

也许您无法立即将所有系统和人员转移到 DevOps。也许您需要选择哪些应用程序开始使用，以及谁将成为您的第一批 DevOps 倡导者。也许是时候慢慢来了。

不是也许：绝对是

不——我撒谎了。您绝对需要慢慢来。试图一次性改变一切是灾难的根源。

这适用于所有更改要素——选择哪些人、选择哪些技术、选择哪些应用程序、选择哪些用户群、选择哪些用例——除了一个。对于这些要素，如果您尝试一次性移动所有内容，您将会失败。您会因为许多原因而失败。您会因为我无法想象的原因而失败，更重要的是，您会因为您无法想象的原因而失败。但其中一些原因包括

• 人们——大多数人——不喜欢改变。
• 技术不喜欢改变（您不能只是切换并期望一切仍然正常工作）。
• 应用程序不喜欢改变（事情以前运行良好，或者至少以已知的方式失败）。您想一次性改变一切？好吧，它们都会以新的和令人兴奋的⁹方式失败。
• 用户不喜欢改变。
• 用例不喜欢改变。

唯一的例外

您注意到我在讨论不应该一次性更改哪些要素时写了“除了一个”吗？做得好。

那个例外是什么？它是初始团队。当您选择要更改的初始应用程序并且您正在考虑选择团队进行更改时，请仔细选择成员并选择完整的集合。这很重要。如果您只选择开发人员、只选择测试人员、只选择安全人员、只选择运维人员或只选择管理人员——如果您从列表中遗漏了一个职能组——您将根本无法证明任何事情。好吧，您可能已经向您社区的一小部分人证明了它有点有效，但您会错过一个技巧。而那个技巧是：如果您从您的各个职能组中选择热衷的人，那么更难失败。

假设您的第一次尝试非常成功。您将如何说服其他人复制您的成功并采用 DevOps？嗯，当然是公司新闻通讯。这将说服多少人呢？确切地说，就是那个数字。¹²另一方面，如果您有来自组织各个职能部门的团队成员，当您成功时，他们会告诉他们的同事，下次您会获得更多的认同。

如果它失败了，如果您明智地选择了您的团队——如果他们都充满热情并且知道“经常失败，快速失败”是好的——他们将准备好再次尝试。

因此，您需要从您的各个职能组中选择充满热情的人。他们可以致力于技术和流程，一旦它开始工作，正是人将创造文化变革。您只需坐下来享受即可。当然，直到下一次危机。

1. 好的，您是对的。应该是“我们技术人员倾向于难以应对的那种情感化的东西。”²

2. 您以为我要限定技术人员难以应对情感化内容的那部分，对吧？再读一遍：我用了“倾向于”。这是您能得到的最好的解释了。

3. 渗透是自下而上的过程吗？我不喝咖啡，⁴所以我不知道。

4. 现在还有人用渗滤壶煮咖啡吗？请随时在评论中告诉我。如果您幸运的话，我可能会假装感兴趣。

5. 对于美国读者（以及其他一些国家，可能？），请在此处用“check”代替“tick”。⁶

6. 对于美国技术读者，请随意执行 s/tick/check/;。

7. 这是一个 Status Quo⁸的引用，对此我深感抱歉。

8. 对于千禧一代读者，请查阅您最喜欢的在线参考引擎，或者 просто 翻个白眼然后继续前进。

9. 对于那些说“但我喜欢刺激”的人，请尝试在季度末的星期日凌晨 2 点值班，当时您的首席财务官打电话给您，询问为什么上个月的所有销售数据都被字母“DEADBEEF”损坏了。¹⁰

10. 对于不了解的人来说，这是一个技术人员经常用作测试数据的字符串，因为 a) 它不是数字；b) 它是数字（十六进制）；c) 它很容易在调试文件中搜索；d) 它很有趣。¹¹

11. 虽然参见⁹。

12. 我只是说这是一个很小的数字。

本文最初发表在 Alice, Eve, and Bob – a security blog 上，并经许可转载。