Everyone is Responsible for Success DevOps中行动与后果的重要性

观看完本视频后，您将能够：

• 解释后果的重要性
• 描述功能孤岛如何导致冷漠
• 确定您的组织 DevOps 目标

Jez Humble 的观点

《持续交付》（Continuous Delivery）一书的作者 Jez Humble 曾说过：

“当人们与他们行为的后果脱节时，坏行为就会出现。”

Jez Humble 提到，功能孤岛让人们看不到或感受不到自己行为对其他团队的影响，因为他们与其他团队的工作隔离开来。因此，他们没有意识到自己的行为会带来怎样的后果。

一个典型的案例

Jez Humble 分享了他与一位工程总监的对话，讨论了一个公司面临的软件质量问题。该公司没有 QA（质量保证）团队，于是他们认为通过招聘 QA 团队可以解决这个问题。然而，令他们惊讶的是，软件质量实际上变得更差了。
原因之一是开发人员觉得自己不再需要为代码的测试负责了。他们不再关注代码的质量，而是专注于尽快将功能提交到“测试”阶段。他们认为质量问题应该由 QA 团队来处理。这样一来，开发团队就脱离了编写有缺陷代码的后果。
当开发人员不再进行测试时，QA 团队无法应对增加的测试量，结果软件质量反而下降了。
这就是为什么我们说，功能孤岛会滋生不良行为。

---

避免这种情况的两种方法

为了解决这个问题，您可以采取以下两种方法：

创建跨职能团队

通过创建跨职能团队，让每个人直接与同事合作，而不是通过票务队列来处理问题。这样可以增加团队之间的协作与沟通，从而提升工作的质量。

开发人员轮岗

如果无法创建跨职能团队，您可以让开发人员轮流参与运维工作，这样他们可以感同身受地理解运维工程师每天为保持应用正常运行所做的工作。此外，运维工程师也可以加入开发团队的站会和展示会，了解开发人员的工作内容和面临的挑战。

让开发人员承担责任

为了让开发人员对自己的工作负责，可以让他们参与值班或承担服务级别协议（SLA）的责任。
事实上，只要在凌晨 3 点打一次电话给开发人员，他们就会开始写出更高质量的代码！通过让开发人员加入值班轮换，他们能切身体会到运维的痛苦，从而开始更加注重代码质量。

---

核心信息

如果人们与他们行为的后果脱节，他们将变得冷漠。让团队感受到自己行为的后果，能够促进同理心，从而提升工作质量。

您的 DevOps 目标

您的 DevOps 组织目标应该是：

• 实现共享意识（Shared Consciousness）
• 分布式的本地控制（Local Control）

您需要确保每个人都理解组织的大方向和目标，但同时给予他们自主权，允许他们根据实际情况决定如何实现目标。这样做可以激发团队成员发挥最佳表现，而不是等待上级的指令。

正如 亚马逊的首席技术官 Werner Vogels 所说：“你建设它，你就运营它！”
在 DevOps 中，开发和运维之间并没有区别。每个人都应对向客户交付价值负责，但必须给予他们实现目标的手段。

---

总结

• 行动如果没有后果，就容易导致冷漠。
• 让团队感受到自己行动的后果，可以促进同理心，从而产生更高质量的工作。
• 您的 DevOps 组织目标应当是：实现共享意识并赋予团队成员本地控制权，帮助每个人更好地为客户交付价值。