聊聊混沌工程

这是鼎叔的第五十四篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

混沌工程是一门新兴学科，它不仅仅只是个技术活动，还包含如何设计能够持续协作的混沌实验。它由Neflix首先在实践中发现了混沌工程的商业价值，通过构建更有韧性的系统来抵御海量组件系统的意外失效。本文还会聊聊混沌工程的概念澄清，原则，投资回报和成熟度模型。

本文的内容参考了《混沌工程-复杂系统韧性实现之道》，作者是Casey Rosenthal,Nora Jones。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Neflix的混沌猴‍‍

Neflix的高绩效文化体现在管理层和技术人员的有趣协作，管理者不会告诉技术人员要做什么，而是确保他们了解要解决什么问题，并信任技术工程师，让他们决定工作的完成方式。

为了解决大型数据中心的实例无故消失问题，工程师尝试了各种方法，最终只有混沌猴这种方法保留下来。原理非常简单，遍历集群列表，从每个集群中随机选一个实例，在每个工作日的某个时间点将其关闭且不会发出警告。工程师只有解决了问题才能进行其他工作，不管是增加冗余，还是增加自动化容量伸缩，或是架构层面设计优化，都带来了可观的成效。‍‍‍‍‍‍‍‍‍‍‍‍‍

不幸的是，随机性混沌注入方法，在分布式系统上的效果都不好，故障的组合空间巨大，且并不孤立。随机方法也无法告诉我们实验的覆盖情况，应该进行多长时间才能得出结论。‍‍‍‍‍

替代随机搜索的方法，就是利用系统专家的领域知识来推动实验探索，利用之前实验观察形成新的假设并逐步完善。专家对故障注入进行筛选，决定哪些实验不需要进行，避免重复。专家还会决定实验的运行顺序，尽可能提高知识增加的速度。专家也需要可观测的基础设施，越丰富越好。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

混沌猴后来升级为混沌金刚，使某个AWS区域关闭，验证AWS区域性故障的解决方案，大幅提升了组织内部对于故障的处理速度。后面即使发生多起停机事故，混沌金刚使用的区域故障转移机制都发挥了作用。‍

混沌工程由此被定义：它是分布式系统上进行实验的学科，目的是建立该系统能够承受生产环境的动荡条件的信心。不需要建立对系统的信心，就不需要混沌工程。

混沌工程通过提供可能超出“快乐路径”（即系统构建的默认路径，没有异常或错误情况）的各种条件和变化参数，来做到这一点。

如今混沌工程已经形成了强大的专业社区。‍‍‍‍‍‍‍‍‍‍‍‍‍

复杂系统

混沌工程这门科学要寻找系统存在弱点的证据，它们会隐藏在系统的本质复杂性中。复杂系统因为非线性导致不可预测，必然会导致不良结果。系统内的部件所发生的变化会导致系统输出发生指数级变化。输出难以模拟或建模，导致传统的探索系统安全性的方法不够充分。‍‍‍‍‍‍‍‍

复杂系统中，不同服务模块各自都有合理的设计决策和监控处理机制，但仍然会出现难以意料的崩溃。

比如场景一，少量用户的消息异常不断重试，可能导致服务降级，进而触发更大范围的重试风暴，导致服务不可用。

场景二，导入的程序库出现的内存泄漏，可能会随着服务请求数量的增加而缓慢增长，直到影响大量实例的错误率，导致局部停机。‍‍‍‍‍‍‍‍

面对复杂性，人月神话（聊聊没有35岁焦虑的《人月神话》）将其分类为偶然复杂性和本质复杂性，前者是在资源有限的项目中编写代码，必然产生各种债务-代码劣化、含糊的契约、废弃的代码路径、不清晰的变量名等。编写软件和理解软件如何失效，完全是两件不同的事情。

没有可持续的方法来解决偶然复杂性，甚至新系统会做得更加复杂。对于本质复杂性，只要添加新功能就会增加。

既然无法避免复杂性，那就接纳它，学会如何应对，而混沌工程就是最有效可行的利器。推荐两个应对复杂系统的模型。‍‍‍‍

一 动态安全模型

这模型有三个属性：经济性（投入的成本），工作量和安全性。工程师对成本和工作量有边界直觉，但是对安全性缺乏直觉。安全事故通常都是意料之外的，而工程师只会对能看到的地方进行优化。混沌工程就是培养工程师安全性直觉的，进而默默地改进行为，让系统更有韧性。‍

二 经济支柱模型

复杂性有四个经济支柱：状态，关系，环境，可逆性。

一个研发组织控制某个支柱的程度，能反映出组织应对竞争性生产过程的复杂性的成熟度。一个汽车大厂可以控制产品状态（有限的款式），关系（上下游产业链的供货关系），环境（对外部法规的影响），但没法控制可逆性，汽车制造容易回退难。‍‍‍‍‍‍‍‍

一个应用程序的功能（状态）大多不断在增加，而无法简化。组件关系和人际关系都在复杂化。大多软件公司都没有影响环境的规模化能力。只有可逆性是软件团队可以大放异彩的支柱（即不断修改完善软件）。

而混沌工程实验能够揭示系统哪些方面违背了“可逆性”。‍‍‍‍‍‍‍‍

混沌工程的原则

混沌工程的通用解释，是“促进发现系统弱点的实验”，分为四个步骤‍‍‍‍‍‍

1 先定义“稳态”(steady state)，系统行为正常时有哪些可以度量的输出。‍‍‍

例如，在XXXX情况下，用户依然拥有良好的体验，表现在XXX数据上。

在XXX事件发生时，技术人员会得到XXX提醒。‍‍‍‍

2 建立假说，对照组和实验组都会持续这种稳态。

3 引入体现真实事件的变量。选择变量常见的误区是，工程师的选择标准经常是容易执行的，基于自身体验而不是用户体验的。有些“异常事件”在现实世界不太可能发生，这就不是好的引入变量。

4 通过在对照组和实验组之间寻找稳态差异来推翻假说

混沌工程原则提供了五项高级实践及黄金标准：建立稳态行为假说，多样化引入现实世界的事件，在生产环境实践，持续运行自动化实验，最小化爆炸半径。

为了给真正关心的生产环境建立信息，高级的混沌工程都在生产环境发生，但是初始阶段先在准生产系统上实验也是有意义的。‍‍

自动化提供了规模化搜索的方法，比人手动操作，能覆盖更多的实验集；随着时间的推移能低成本地持续验证经验假设，及时发现系统的变化。‍‍‍‍‍‍‍

设计更安全的实验方法，将对生产环境中用户流量的负面影响降到最低，还带来加强信号检测效果的好处。‍

聚焦用户体验是所有高级原则的基础。‍‍

对混沌工程的常见误解

一 实验和测试是不同的

实验并不知道如何断言，而是通过假说的验证或推翻来得到新知识。源于应对复杂系统问题，所以混沌工程更多体现“未知的实验性”而非“已知的测试性”，主张验证有效性，而不是检查如何工作。

二 混沌工程并非人们误解的“搞破坏”

单纯搞破坏，很难做到减小爆炸半径，和漏洞的批判性思考。混沌工程最终的价值是修复生产环境的漏洞。

三 很多人认为塔勒布的《反脆弱》理论和混沌工程在本质上是一样的。

实际上两个流派分歧很多，反脆弱缺乏软件工程学的同行评审和理论基础，给出的解决手段（如增加冗余）可能会带来更多风险。反脆弱希望给系统引入混沌，而混沌工程希望发现复杂系统的固有混沌。

四 软件接口设计不规范等问题能否通过混沌工程来发现‍‍‍‍‍‍‍‍

接口契约不匹配的协商解决，是开发过程的一部分，无需纳入混沌工程来解决，这些已知属性问题最好通过软件测试解决。混沌实验主要为不确定的自动化行为提供信心，它发现的BUG往往是多个细微逻辑错误的组合，以及时间相关性故障。‍‍‍‍

注意，被选定实验的特定服务及其依赖服务，如果存在已知的关键缺陷，要先修复后再进行实验，否则我们不能从实验中学到确定的新东西。

混沌工程的投资回报

“ 只有事故真的发生了，才能有故事可讲。”-- John Allspaw‍‍‍

混沌工程是一门务实的学科，旨在为企业提供价值。但是如何证明混沌工程的回报是令人困惑的。

系统可用性指标的上升，是否应该归功于混沌工程实践呢？混沌工程触发的改进，倾向于给其他业务增加压力，比如牺牲了发布速度，那如何确定收益率呢？‍‍‍‍‍

Kirkpatrick模型提供了一种评估投资回报率的方法，原本用于教学培训领域，它把评估分解为四个递进的级别：反应（混沌工程示范对受训者有帮助，是否支持维持或加大该实验），学习（证明并列举团队学到了什么），转移（把知识转化为实践，发生了行为变化，提高了协作效率，提高了应急成熟度），结果（混沌工程的总成本，与商业结果价值进行比较）。每一级是否评价为积极，就展示了对应的投资回报。

混沌成熟度模型

成熟度模型横轴是采用度，纵轴是复杂性。‍

“采用度”考虑这几个因素：接受者，参与者，采用门槛（是否有观测工具，积极讨论的共识，经得起考验的假说，一致的响应行动），采用障碍（业务的担心，合规性，从未发生过事故，难以衡量回报率）‍

“复杂性”，会随着实验的发展而提升，如下所示：

• 1 Game Day，实践试水，复杂性低，但是消耗大量人力，无法在大量服务上规模化执行。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

• 2故障注入框架。工具可以让多个团队进行实验，进行更多跨功能性的学习。‍‍‍

• 3 实验平台。满足更好实验的需求，在对照组和变量组进行安全对比，控制最小爆炸半径。每个实验都要被平台监控。‍‍

• 4 平台自动化。完全自动化进行的混沌工程，包括实验的创建、优先级排序、执行和推翻/终止。平台能够“自我反省”，只自动运行哪些对实验假说有可量化期望的实验。

  平台还可以进一步进行能力升级，如控制“混沌预算”，使用组合实验变量构建实验，自动修复漏洞。

  被引入的实验变量也可以不限于基础设施层级，还可以是应用程序逻辑层的变量-比如给服务返回出乎意料的响应。

  ‍‍‍‍‍‍‍‍‍‍‍‍

‍‍‍‍‍‍基于混沌成熟度绘制的表格，就可以看到本组织所处的位置，确定如何技术投资的路径，达到高复杂性与高参与度，让混沌工程创造最大的价值。

下一篇，我们详细介绍各大企业实践混沌工程的优秀流程，经验教训，人和组织的能力提升，从中学习到了哪些洞见。‍‍