什么是混沌工程

从混乱的猴子开始，Netflix为应对不确定性的领域带来了一种全新的思维方式--主动出击。这种主动出击的思维方式衍生出的一套实践方法，被称为混沌工程（Chaos Engineering），它旨在从根本上改变开发者应对软件缺陷和故障的思维方式。在此之前，我们期望通过一系列的测实验证手段，尽最大的可能确保在线上运行的系统没有缺陷和故障。而混沌工程的理念认为这既不现实，也不符合系统自然发展的规律。混沌工程提倡我们首先要正面接受系统一定会存在缺陷，并且一定会时不时地发生故障的事实；然后，要求我们通过一些列实验找出可能发生问题的风险点，进而在不断加固系统的同时，促使开发者在开发软件时必须选择将防御性内建在系统中。

如何使用混沌工程提高系统的韧性

混沌工程通过设计和执行一些列实验，帮助我们发现系统中潜在的，可以导致灾难的或让我们用户受损的脆弱环节，推动我们主动解决这些环节存在的问题。和现在各大公司主流的被动式故障响应流程相比，混沌工程向前迈进了一大步。
混乱的猴子最大的成就在于使工程师之间形成了构建具备足够韧性性的服务规约和原则。

混沌工程原则

1. 建立稳定状态的假设。

将系统正常运行时的状态定义为系统的“稳定状态”。稳定状态一定要和客户接受程度一致。通过一个模型，基于所期望的业务指标来描述系统的稳定状态。假设们向系统注入的事件不会导致系统稳定状态发生明显的变化。

2. 用多样的现实世界事件做验证。

要彻底阻止对可用性的各种威胁是不可能的，但是我们可以尽可能地减轻这种威胁。在决定引入那些事件的时候，我们应当估算这些事件发生的频率和影响范围，权衡因让他们的成本和复杂度。
注入的事件一定是你认为系统能处理的。同时注入的事件应该是所有可能的真实世界的事件，而不仅仅是故障和延迟。

3. 在生产环境中进行实验。

我们要在生产环境中建立对系统的信心，所以当然需要在生产环境中进行实验。即便你不能在生产环境中进行实验，也要尽可能地在离生产环境最近的环境中进行。

4. 自动化实验以持续运行。

生产环境实际上处在一个无时不变的状态，这导致的结果就是，对实验的结果的信心是随着时间而衰减的。在理想情况下，实验应该随着每次的变化而执行。这有点像混沌金丝雀。当发现新的风险时，操作人员如果相当确定风险的根源就是即将发布的新代码，那么他就可以选择是否阻止发布新版本并优先修复缺陷。这种方法可以帮助我们更深入地了解生产环境中可用性风险的发生和持续时间。在非理想情况下，在每年一次的演习中进行问题调查就很难，需要完全从零开始检查，而且很难确定这个潜在的问题在生产环境中存在多久了。

5. 最小化爆炸半径。

每一次混沌工程实验的确具备导致生产环境崩溃的风险。随时遏制和停止实验的能力是必备的，这可以避免造成更大的危机。我们的实验通过很多方法来探寻故障会造成的未知的和不可预见的影响，所以关键在于如何让这些薄弱的环节曝光出来而不会因为意外造成更大规模的故障。我们称之为“最小爆炸半径”。混沌工程实验应该只承受可以衡量的风险，并采用递进的方式，进行的每一步实验都在前一步的基础上。这种递进的方式不断增加我们对系统的信心，而不会对用户造成过多不必要的影响。

混沌工程成熟度模型

1. 熟练度

熟练度可以反映出组织中混沌工程项目的有效性和安全性。

入门：

• 未在生产环境运行实验。
• 全人工流程。
• 实验结果反映系统指标，而不是业务指标。
• 对实验对象注入一些简单事件，如“关闭节点”。

简单：

• 使用复制的生产环境中的流量来运行实验。
• 自助创建实验，自动运行实验，手动监控和停止实验。
• 实验结果反映聚合的业务指标。
• 对实验对象注入较高级的事件，如网络延迟。
• 实验结果是手动整理的。
• 实验的定义是静态的。
• 具有可以支持对历史实验组合控制进行比较的工具。

高级：

• 在生产环境中运行实验。
• 自动分析结果，自动终止实验。
• 实验框架和持续发布工具集成。
• 在实验组和控制组之间比较业务指标差异。
• 对实验组引入一些事件，比如服务级别的响应和组合式的故障。
• 持续收集实验结果。
• 具有可以交互式地对比实验组和控制组的工具。

熟练：

• 在开发流程中的每个环节及所有环节中运行实验。
• 设计、执行和终止实验完全自动化。
• 将实验框架和A/B测试以及其他测试工具集成，以减少噪声的干扰。
• 可以注入如对系统的不同使用模式，返回结果和状态的更改等类型的事件。
• 实验具有动态可调整的范围以找寻系统拐点。
• 实验结果可以用来预测收入损失。
• 对实验的结果的分析可以用来做容量规划。
• 实验结果可以用来区分服务实际的关键程度。

1. 应用度

应用度用来衡量混沌工程实验覆盖的广度和深度。应用度越高，暴露的脆弱点就越多，我们对系统的信心也就越充足。

“暗中进行”：

• 对重要项目不采用。
• 只覆盖少量系统。
• 组织内部基本没有感知。
• 早期使用者偶尔进行混沌工程实验。

适当投入：

• 实验获得正式批准。
• 工程师兼职进行混沌工程实验。
• 多个团队有兴趣并参与进来。
• 一些重要服务会不定期地进行混沌工程实验。

正式采用：

• 有专门的混沌工程团队。
• 所有故障的复盘都会进入混沌工程框架来创建回归实验。
• 定期对大多数关键服务进行混沌工程实验。
• 偶尔进行实验性的故障复盘验证，例如通过“比赛日”的形式来做。

成为文化：

• 对所有关键服务进行高频率的混沌工程实验。
• 对多数非关键服务进行高频率的混沌工程实验。
• 混沌工程实验是工程师入职流程的一部分。
• 所有系统组件默认都要参与混沌工程实验，不参与的话需要进行特殊说明。

总结

在任何一个开发和运行复杂分布式系统的组织机构里，如果既想拥有高开发效率，又想保障系统具有足够的弹性，那么混沌工程一定是必备的方法。