混沌工程

第 15 章 混沌成熟度模型 混沌成熟度模型

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

当 Netflix 的团队写出第一本关于混沌工程的书时，他们提出了 "混沌成熟度模型"、¹他们提出了 "混沌成熟度模型"。这最初只是一个玩笑，是对80年代末/90年代初的CMM--卡内基梅隆大学为分析软件开发过程而开发的 "能力成熟度模型"--的一种模仿。该框架是一个非常严谨的过程，与 Netflix 的文化形成了鲜明对比，在 Netflix，"过程 "是一个不好的词。

当 Netflix 的团队使用这个模型时，发现它确实很有道理。事实证明，这并不是一个玩笑。混沌成熟度模型实际上提供了价值，特别是对于那些正在寻找评估和增加对混沌工程实践投资的方法的组织来说。

，从广义上讲，软件行业作为一个整体，其同质性不足以支持围绕混沌工程的行业标准。基础架构、文化、期望值和成熟度都有很大差异，因此不可能有一个简单的解决方案，为不同公司提供一些基本的可比功能。作为行业标准的替代，混沌成熟度模型提出了滑动尺度，可以对不同的混沌工程实践进行评估，以便进行比较和改进。

本章将混沌成熟度模型（CMM）作为一个框架进行说明。这可用于绘制团队或组织的定位图。如果其他人在混沌工程领域的发展道路能够说明团队的进步潜力，那么该地图就能直观地提示团队可以在哪些方面进行改进。CMM 地图有两个轴：采用度和复杂度。这两个方面都可以单独探讨。

采用

关于混沌工程，一个 最常见的问题是如何说服管理层接受这一概念。温斯顿-丘吉尔（Winston Churchill）有一句名言："永远不要让好的危机白白浪费"。这句话非常适用于混沌工程的采用。正如《导言》中所述：正如《混沌的诞生》一书中所描述的，这门学科本身就诞生于 Netflix 的危机之中。Chaos Monkey 是在2008年数据中心向云迁移过程中发生故障时发明的。混沌金刚则是在2012年圣诞节前夕的故障之后发明的。

这可能有点像在追赶救护车，但有时帮助他人的最佳时机恰恰是在他们感受到得不到所需帮助的后果之后。我们曾多次看到，在发生可用性或安全事故后，管理层才愿意实施混沌工程。紧接着，就有了强有力的协调和预算来防止类似事件的发生。作为提高可靠性的少数主动方法之一，这往往是引入混沌工程的最佳机会。

随着这门学科的整体成熟，最终我们会达到这样一个地步：公司会将一定程度的混沌工程作为一项策略强制推行。光是稳健性验证就对合规流程产生了重大影响。但在达到这一目标之前，采用混沌工程通常需要从基础做起。

采用 可以分为四个方面：

• 谁接受了这一理念

• 有多少组织成员参与

• 先决条件

• 障碍

谁支持混沌工程

在采用周期的早期 ，最容易受到故障或安全事件影响的个人贡献者（ICs）最有可能采用混沌工程，或者出于显而易见的原因寻求采用该学科。随后往往是内部倡导，倡导者通常是 DevOps、SRE 和事件管理团队。在更传统的组织中，这通常由运营或 IT 部门负责。这些团队深知被呼叫处理可用性事件的压力。

当然，让系统重新上线的紧迫性也为学习设置了障碍。很多组织都在努力优化事件审查或学习审查流程，但很少有组织能够找到通往弹性工程（Resilience Engineering）的便捷途径：从已完成的工作中学习，以提高社会技术系统中人员的适应能力。

相反，我们通常看到的是持续关注缩短检测时间和修复时间。努力缩短这两方面的时间固然很好，也是一项必要的工作，但这也是被动的。最终，通过合理的论证、举例或后果，选择 ...