混沌工程成熟度模型

网飞第一本混沌工程的书提到成熟度模型，是为了取笑CMMI。CMMI描述了一个非常繁琐的过程，与网飞文化形成鲜明对比。在网飞，过程是一个坏词儿。然而网飞对成熟度模型深入了解后，发现了它的价值，玩笑不再是玩笑。不同公司的基础设施、文化、期望等成熟度相差太大，无法给出一个现成的通用的技术解决方案成熟度模型超越行业标准，提供了一种可以滑动的级别，可以在此基础上评估不同的混沌工程实践，以进行对比和完善。混沌成熟度模型可以标出团队或组织在框架地图上的位置。从视觉上展示团队可以朝哪个方向改进。混沌成熟度模型有两个轴: 采用度和复杂性。

采用度。混沌工程的常见问题是如何管理人员接受这一概念。温斯顿丘吉尔说，不要浪费一场好危机。混沌工程诞生于网飞的危机。有时帮助某人的最佳时机，就是在他们事前没有寻求帮助、但事后感到切肤之痛时。直到发生可用性或安全性事故时，管理层才一改之前不情愿的态度，开始积极实践混沌工程。混沌工程在此时引入是最佳时机。采用混沌工程需要考虑: 谁接受混沌工程?组织中有多少人参与?前提条件是什么?有什么阻碍?

那些对停机事故有切肤之痛的工程师，最有可能采纳混沌工程。之后他们通常会在组织内为混沌工程奔走呼号。倡导者常常有DevOps、SRE、事故管理团队的身影在一些前瞻性的组织中，混沌工程已成为法令，由高级副总裁、首席信息官、首席安全官级别的高管发起。采用混沌工程的常见过程，是从受事故影响的人员到管理层，然后形成组织的策略性指令进行颁布。

混沌工程可以从应用开发团队或集中运维团队的个人开始。最终可以设立混沌工程全职职位或成立混沌工程团队。

实践混沌工程的前提条件比大多数人想象的要少。对于考虑混沌工程的组织，第一个要问的问题是，一旦系统处于服务降级状态我们能否知道。如果组织不能区分系统降级的程度，那么来自混沌工程的任何结果都会灰飞烟灭。监控和可观测性是解药，当改善了可观测性，就是一个传播混沌工程实践意识的好时机。

混沌工程中的混沌一词，可能会吓跑公司高管、阻碍该实践的采纳。其他反对意见是，业务模式无法承受在生产流量中进行实验而产生的副作用。合规性是实践混沌工程的另一个潜在的障碍。系统当前的稳定状态也是常见的障碍。采用混沌工程最棘手的障碍是如何确定混沌工程的投资回报率。

复杂性。复杂性位于两极之间: 提供咨询服务还是提供一组工具。无论提供咨询服务还是提供工具，都可以由一个小的集中式团队来启动。由于软件基础设施的多样化，无法使用一个预制的工具，能够在所有这些异质的环境中满足复杂的混沌工程实验用例。混沌工程的推进进程通常如下:举办演练日、提供故障注入咨询、提供故障注入自助服务工具、实现混沌工程实验平台、实现平台自助化。

先提升复杂性，后扩大采用度，能让混沌工程创造最大价值。高复杂性和无处不在的混沌工程是主动提高软件行业可用性和安全性的最佳方法。