混沌工程：分布式系统稳定性的“疫苗”

李康建，来自中原银行信息技术部，目前就职于应用开发中心技术平台组，负责微服务体系相关开发工作，以及云原生架构下混沌工程的探索落地建设工作。

01 容灾了，但没完全容灾

2021 年 7 月 14 日夜晚，B 站突发宕机事故，导致服务不可用长达 40 分钟，B 站“难民”们纷纷涌入其他竞品平台，导致了连锁性的服务雪崩事件。事故原因众说纷纭，据传可能有机房失火，停电，云设施故障，程序猿手滑等等。

且不论有多少可怜的程序猿会因为此次事故而面临祭天的命运，拨开围绕在此事件上的热点讨论，它的本质无非就是未能对生产环境突发故障做出合理的预警和未雨绸缪的预防，或者说没有对各种可能影响服务高可用性的因素做出充分考虑和应对；以至于千里之堤，溃于蚁穴。

比较戏剧性的是，那篇《B 站高可用架构实践》还在各大技术博客上优哉游哉地挂着，里面充斥着我们耳熟能详的名词：负载均衡、分布式限流、超时控制、优雅降级、故障演练等等，听上去给服务可用性叠上了一层层可靠的护甲，如同马奇诺防线一样坚不可摧，如同泰坦尼克号一样永不沉没，如同苏维埃联盟一样牢不可破。然而实践是检验真理的唯一标准，残酷的现实告诉我们，这些名词并不一定像它们看上去那样可靠。有人在文章评论区留下了这样的调侃：容灾了，但没完全容灾。

随着微服务化、云原生、敏捷开发的快速普及，我们在快速迭代相应业务需求即时变化的同时，也面临着分布式架构复杂程度急剧上升，故障频发，强弱依赖关系难以厘清，系统变化过快稳定性难以保证等问题，这使得架构的容错性和高可用性都受到了前所未有的挑战。为此我们引入了混沌工程的概念，它是提升分布式系统架构稳定性的“疫苗”。

“一只南美洲亚马逊河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可以在两周以后引起美国得克萨斯州的一场龙卷风”。这就是我们耳熟能详的蝴蝶效应。无独有偶，英国有这样一段著名的民谣描述国王查理三世的悲剧命运：“少了一枚铁钉，掉了一只马掌。掉了一只马掌，失去一匹战马。失去一匹战马，失去一场战役。败了一场战役，毁了一个王朝。”它们背后的原理是一致的，即初始条件的微小差异经过复杂系统的层层放大后，引起了影响深远的连锁反应。我们用混沌一词来描述这种状态，混沌是一个非线性科学概念，指确定性动力学系统因对初值敏感而表现出的不可预测的、类似随机性的运动。

应用的分布式架构体系同样可以视为一个混沌体系，浩如繁星的微服务数目，错综复杂的调用链路，海量的交易数据，这一切使得生产环境遍布着难以预测的湍流，即使是一个看似不起眼的波动，都有可能造成整个系统的雪崩。混沌工程正是为了探究与应对生产环境的混沌状态而诞生的实验学科。

02 NetFlix、猴子与疫苗

2008 年 8 月， Netflix 主要数据库的故障导致了三天的停机，之后 Netflix 工程师着手寻找替代架构，并在 2011 年起，逐步将系统迁移到 AWS 上，运行基于微服务的新型分布式架构。这种架构消除了单点故障，但也引入了新的复杂性类型，需要更加可靠和容错的系统。为此，Netflix 工程师创建了 Chaos Monkey，会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮，是否有足够的弹性，是否可以容忍计划外的故障。混沌工程由此发源。

Netflix 把他们的故障测试工具命名为混沌猴子，意指它会像猴子一样在系统中上蹿下跳搞破坏，以此来验证云应用的可靠性。在后续的产品更新和升级中，他们延续了这一设定，创造出了五花八门以猴子为名的新工具，组成了一支庞大的猴子家族；比如 Chaos Kong、Latency Monkey、Simian Army 等。

在 2016 年，它的前工程师创建了 Gremlin，成为首个商用化的混沌工程实验平台。2017 年，开源了 Chaos Toolkit 混沌工程实验框架。目前混沌工程的概念和落地实践已在国内外得到快速传播和推广，包括微软、谷歌、亚马逊、阿里、腾讯、字节等公司，都在以种种形式践行着混沌工程。

混沌工程的概念由 Netflix 最早系统化的总结提出，它的定义如下：

混沌工程是在分布式系统上进行实验的学科，目的是建立对系统抵御生产环境中失控条件的能力以及信心。

混沌工程是一套通过在生产分布式系统上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实证的验证方法可以为我们打造更具弹性的系统，同时更透彻的掌握系统运行时的各种行为规律，树立运行高可用分布式系统的信心。

Netflix 将混沌工程的实践原则总结为五条：

01 建立一个围绕稳定状态行为的假说

稳定状态是指系统正常运行时的状态。具体来说，系统的稳定状态可以通过一些指标来定义。指标可以分为系统指标和业务指标。系统指标（如 CPU 负载、内存使用情况、等）有助于帮助我们诊断性能问题，有时也能帮助我们发现功能缺陷。在混沌工程中，业务指标通常比系统指标更有用。

02 多样化真实世界的事件

混沌变量反映了现实世界中的事件。我们可以通过潜在影响或估计频率排定这些事件的优先级。不需要穷举所有可能对系统造成改变的事件，只需要注入那些频繁发生且影响重大的事件。任何能够破坏稳态的事件都是混沌实验中的一个潜在变量。

03 在生产环境中运行实验

系统的行为会依据环境和流量模式都会有所不同。由于资源使用率变化的随时可能发生, 因此通过采集实际流量是捕获请求路径的唯一可靠方法。为了保证系统执行方式的真实性与当前部署系统的相关性, 混沌工程强烈推荐直接采用生产环境流量进行实验。

04 持续自动化运行实验

手动运行实验是劳动密集型的, 最终是不可持续的。所以我们要把实验自动化并持续运行，混沌工程要在系统中构建自动化的编排和分析。应该自己投入精力来开发混沌工程的工具和平台，以期不断降低创建新实验的门槛。

05 最小化爆炸半径

为了避免对生产环境造成较大程度的影响和损害，混沌工程应该采取循序渐进的推进方式，将影响范围控制在最小。需要具备随时遏制和停止实验的能力，避免对生产环境造成不可挽回的影响。

作为一个类比，我们可以把混沌工程看做打疫苗的过程。疫苗也是通过事先注入抗原引导免疫系统产生抗体，来增强人体对于特定病原体的防御能力的。这和混沌工程注入故障以未雨绸缪预防更多故障的思想是一致的。疫苗是灭活病毒，以防对人体造成真实损害；混沌工程也强调要最小化爆炸半径，避免对生产环境造成过度破坏。

03 混沌工程的价值

混沌工程的意义主要体现在探索和避免潜在的稳定性缺陷，检验和提升系统高可用性及容错性，提升运维故障响应修复效率等方面。我们也可以从定量的角度来描述混沌工程的价值。从降低故障发生频率和提升应急响应效率的角度而言，主要涉及到的量化指标包括 MTBF、MTTR、MTTF。

MTTR 即为平均恢复时间，是故障发生后经过修复回复正常的平均时间。可以通过发现缺失的系统监控、告警，缩短故障发现时间；以及提高技术⼈员应急效率，缩短故障解决时间来优化这一指标。

MTTF 是平均无故障时间，是故障修复到再次发生的平均时间。改善措施包括对历史故障持续进⾏回放，避免相同故障再次发⽣；对架构薄弱点持续进⾏验证，避免架构稳定性衰退。

MTBF 平均失效间隔，是两次故障发生的平均间隔。通过提升平均⽆故障时间和降低平均修复时间，可以有效提升平均失效间隔。

字节跳动在混沌工程落地实践中，用这样的公式来衡量其价值：

A=MTBF(N-1)/[MTBF(N-1)+MTTR*N*S]

其中 N 为故障发生次数，S 为故障影响范围。通过计算平均失效间隔和平均恢复时间与故障规模之积的比例，来计量混沌工程对于故障应急能力的提升程度。

也可以从经济成本的角度来衡量混沌工程的价值。 

这是阿里计量混沌工程投入产出比的方法。投入成本主要包括混沌工程师的工资支出，安装相应软件的成本，以及运行实验的开销。收益来自于因混沌工程的实施而提前避免的运维故障造成的潜在损失，包括业务收入，员工生产率损失，故障修复成本等。

Netflix 也通过类似的方式去计算混沌工程的收益。据其技术团队统计，在混沌工程实施后的某一年中，提前暴露了 2 次大故障和 8 次小故障，避免的潜在损失大约为 70 万美元。相应的投入为混沌工程团队的工资，共计 3 人，15 万美元/人，以及实验成本 1 万美元，投资回报率为 52.17%。

04 国内混沌工程开源项目现状

混沌工程目前在国内的大型互联网企业已经得到了广泛的和落地实践，用于迭代改进应用架构的健壮性和韧性。业界也开源出了一批混沌工程实验工具，比较著名的是阿里开源的 ChaosBlade 和 PingCAP 研发的 Chaos Mesh。此外云原生产业联盟还主导制定了混沌工程相关的行业标准。

混沌之刃—ChaosBlade

ChaosBlade 是阿里内部 MonkeyKing 对外开源的项目，支持丰富多样的实验场景。涵盖基础资源、 Java 应用、C++ 应用，、Docker 容器、云原生平台、Pod 网络和 Pod 本身等实验场景。

（1）混沌实验模型

ChaosBlade 的混沌实验模型分为四层，描述了实验的对象、范围、匹配条件以及具体操作：

Target：实验靶点，指实验发生的组件，例如 容器、应用框架（ Dubbo、Redis、Zookeeper）等。

Scope：实验实施的范围，指具体触发实验的机器或者集群等。

Matcher：实验规则匹配器，根据所配置的 Target，定义相关的实验匹配规则，可以配置多个。比如缓存领域的 Redis，可以根据 set、get 操作进行匹配。

Action：指实验模拟的具体场景，Target 不同，实施的场景也不一样，比如磁盘，可以演练磁盘满，磁盘 IO 读写高，磁盘硬件故障等。

MonkeyKing 将场景按领域实现封装成一个个单独的项目，方便场景水平和垂直扩展，通过遵循混沌实验模型，实现 ChaosBlade cli 统一调用。目前，ChaosBlade 已在国内四十多家企业中登记使用，包括工商银行、浙江移动、中国电信、小米集团、携程 &去哪⼉、滴滴、哔哩哔哩等。

混沌网格—Chaos Mesh

Chaos Mesh 是 PingCAP 开源的一款为 k8s 设计的混沌工程演练工具。使用 CustomResourceDefinitions（CRD）定义混沌对象，允许针对不同类型的故障注入使用灵活且独立的 CRD 对象。如果添加符合现有 CRD 对象的故障注入方法，则可以直接基于此对象进行缩放；如果这是一种全新的方法，将为其创建一个新的 CRD 对象。它支持多样化的故障场景注入，包括 pod 类，基础资源类，网络类，文件系统类以及内核类故障。

（1）Chaos Mesh 架构

Chaos Mesh 包含三个主要组件：

Controller-manager：它充当平台的“大脑”，管理 CRD 对象的生命周期并安排混乱实验，具有用于调度 CRD 对象实例的对象控制器。

Chaos-daemon：作为特权 daemonset 运行，可以在节点和 Cgroup 上操作网络设备。

Chaos Dashboard：与用户交互的 Web UI，用户通过该面板制定和编排混沌实验。

（2）Chaos Mesh 运作原理 

用户使用 YAML 文件或 Kubernetes 客户端，创建或更新混乱对象到 Kubernetes API 服务器。Chaos Mesh 使用 API 服务器来监视混沌对象，并通过创建，更新或删除事件来管理混沌实验的生命周期。控制器管理器，chaos-daemon 和 sidecar 容器一起工作以注入错误。当 admission-webhooks 收到 Pod 创建请求时，将动态更新要创建的 Pod 对象。例如，将其注入边车容器和 Pod 中。

      除了专用于 k8s 的 Chaos Mesh 外，PingCAP 还开源了适用于物理机环境的 Chaosd；此外还提供了可用于实验及指标可视化的 Grafana 插件。目前 Chaos Mesh 在腾讯、美团、网易、小鹏汽车等众多企业得到了推广应用。

05 国内混沌工程行业标准

混沌工程在国内方兴未艾，也在业内形成了广泛的讨论，造就了一套行业标准的雏形。由中国信通院(CNIA)牵头成立的云原生产业联盟从 2020 年初开始组织专家进行混沌工程技术研究，提出了应用混沌工程方法来验证云原生系统的韧性架构，将相关研究成果写入《云原生中间件白皮书（2020）》并于 2020 年 7 月可信云大会上发布，同时成立混沌工程项目组。2021 年 4 月 2 日，由 CNIA 组织的混沌工程项目研讨会议在京召开，讨论近期工作组研究成果并发布《混沌工程测试平台能力》标准纲要。

      纲要将混沌工程平台技术架构分为五大部分：资源支持能力、故障注入类型、功能模块、上层能力以及横向支撑能力。资源支撑能力中，明确了混沌工程平台应该兼容的底层资源；故障类型对混沌工程应提供的故障注入类型进行分类；功能模块介绍了为了实现混沌实验，平台应提供实验设计、实验实施及实验度量分析三大部分能力；上层能力是规范了平台的对外输入、输出能力；横向支撑能力则就权限管理和安全审计能力进行规范。

      此外，信通院还联合多家云应用服务商成立了混沌工程实验室，旨在通过专家研讨和行业交流，明确混沌工程产业发展定位，引领产业发展方向；并集合行业内龙头企业的专业力量，整合优质资源，形成产业合力，开展技术研究，加强标准体系建设，提高混沌工程产业的发展向心力和发展质量。

06 结语

回到最初的问题，如何才能切实有效提升复杂分布式架构的容灾能力，使其尽可能降低故障发生的频率，以及在故障发生后能够及时恢复正常，保证业务连续性？一方面，我们应该通过生产事故分析以及故障模拟演练，尽可能多地去发掘引发故障的原因和场景，对于故障原因明晰且能够修复的，应该及时加以修正；另一方面，对于故障原因随机无法确认的，应该通过相应的故障注入模拟，验证系统是否存在有效的容灾机制，防止故障影响进一步扩大，使应用能够及时恢复正常并继续提供服务；最后，在以上条件都已满足的基础上，通过大规模成体系自动化的混沌工程演练，自主探索那些我们尚未知晓，但对于系统健壮性存在潜在影响的领域。通过对于上述“已知的已知”、“已知的未知”、“未知的未知”问题的分层次探索与解决，充分运用“面向失败编程”的思想，不断完善提升应用架构的韧性和稳定性。

笔者的领导在研讨混沌工程时说过这么一句话：一个保洁阿姨不小心拔了机房的电源线，这就是混沌工程思想的最简单落地实践。不要小看这种听上去有些天方夜谭的场景，B 站此次就是因为类似的简单问题而掉线。必须对各种可能的场景都充分考虑，未雨绸缪，这样才能在事故来临之际有条不紊地解决问题，才能保证《高可用架构实践》真正的在实践中高可用。