什么是混沌工程？

架构师口中的混沌工程，到底有什么用呢？

就让我们为你带来循序渐进的混沌工程超详细讲解吧：

本文将分为以下三个篇章：

• 启动篇——详述混沌工程的基本概念、主要解决的问题、最终的目标，对混沌工程实践的突出困惑做了分析和解答。
• 可行性评估篇——探讨如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性。
• 对照实验设计篇——基于前两个篇章引申出“如何进行对照实验设计”这个实施性问题，并从实验可行性评估、观测指标设计与对照、实验场景和环境的设计三个维度，深入分析和讨论了混沌工程实验的对照设计原则和方法。

启动篇

工程师团队最不愿碰到的便是大半夜被电话叫醒，开始紧张地查验问题，处理故障以及恢复服务。也许就是因为睡前的一个很小的变更，因某种未预料到的场景，引起蝴蝶效应，导致大面积的系统混乱、故障和服务中断，对客户的业务造成影响。特别是近几年，尽管有充分的监控告警和故障处理流程，这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于，对投入生产的复杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对，那有没有可能提前发现这些复杂系统的弱点呢？

混沌工程 Chaos Engineering

在分布式系统上进行由经验指导的受控实验，观察系统行为并发现系统弱点，以建立对系统在规模增大时因意外条件引发混乱的能力和信心。

混沌工程发展简介

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

图1中展示了混沌工程从2010年演进发展的时间线：

2010年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具： Chaos Monkey
2011年 Netflix 释出了其猴子军团工具集： Simian Army
2012年 Netflix 向社区开源由 Java 构建 Simian Army，其中包括 Chaos Monkey V1 版本
2014年 Netflix 开始正式公开招聘 Chaos Engineer
2014年 Netflix 提出了故障注入测试（FIT），利用微服务架构的特性，控制混沌实验的爆炸半径
2015年 Netflix 释出 Chaos Kong ，模拟AWS区域（Region）中断的场景
2015年 Netflix 和社区正式提出混沌工程的指导思想 – Principles of Chaos Engineering
2016年 Kolton Andrus（前 Netflix 和 Amazon Chaos Engineer ）创立了 Gremlin ，正式将混沌实验工具商用化
2017年 Netflix 开源 Chaos Monkey 由 Golang 重构的 V2 版本，必须集成 CD 工具 Spinnaker 来使用
2017年 Netflix 释出 ChAP （混沌实验自动平台），可视为应用故障注入测试（FIT）的加强版
2017年 由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版
2017年 Russell Miles 创立了 ChaosIQ 公司，并开源了 chaostoolkit 混沌实验框架

今天，许多公司包括 FANG，都有自己的 Chaos Engineer ，使用某种形式的混沌工程实验，来提高现代架构的可靠性。由于混沌工程的目的是给复杂的分布式系统引入扰动，并观察系统行为，借此发现系统弱点。因此，混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式，都需要科学的分析和有经验的混沌工程专家指导。根据笔者的观察，多数用户对混沌工程实践踌躇不前，总绕不开下面这几个问题：

问题1：混沌工程是不是只适合像 FANG 这样技术成熟的大公司，拥有复杂的分布式系统，很强的研发和运维能力？

答：否。混沌工程进行的是探索系统复杂性的开放实验，目的是改善原有的系统架构和运维模式，加强业务服务的健壮性。没有像 FANG 那样复杂的分布式系统，一样需要混沌工程实践来达到健壮性的目的，只是混沌工程设计实施的复杂性不同、实践的成熟度不同：技术成熟的大公司，由于其系统的复杂性更大，无法完全理解透彻其上下游纷繁的依赖关系，因此更需要借助混沌工程实践，并利用自身较强的研发和运维能力，来深入了解系统行为以提高稳定性。另外，从资源获取的角度上看，在云上实施混沌工程实验，对其他公司而言，更加便捷有效。

问题2：混沌工程实验像 Chaos Monkey 只是杀杀机器而已，运维看看就好了吧？

答：否。回溯混沌工程发展的时间线，业界对混沌工程的理解是逐步深入的。 Netflix 开发的 Chaos Monkey 成为了混沌工程的开端，但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现，终止 EC2 实例只是其中一种实验场景。因此， Netflix 提出了 Simian Army 猴子军团工具集，除了 Chaos Monkey 外还包括：

• Latency Monkey 在 RESTful 客户端到服务器通信中引入随机延迟，以模拟服务降级并测量上游服务是否正确响应。
• Conformity Monkey 在发现不符合最佳实践的实例时将其关闭。
• Doctor Monkey 会在每个实例中运行健康检查，同时也通过其他外部监控指标来检测不健康的实例。一旦检测到不健康的实例，将它们从服务中删除，并且在实例所有者找到问题的原因后终止。
• Janitor Monkey 搜索未使用的资源并按规则处理，以确保AWS上的环境资源有效避免浪费。
• Security Monkey 在发现安全违规或漏洞时，如发现未正确配置的AWS安全组，并终止使用该违规安全组的实例。此外，还会确保所有的 SSL 和 DRM 证书有效且无需续订。
• 10-18 Monkey （l10n-i18n）针对多个区域和国家的客户提供服务的实例，检查有关语言和字符集的配置。
• Chaos Gorilla 模拟了 AWS 可用区域（AZ）的中断，以验证服务是否会自动平衡至可用的 AZ ，而无需人工干预，也不会给用户带来可见的影响。

使用 Simian Army 进行混沌工程实验，看起来似乎已经很完美。类似像 Latency Monkey 的引入，由于服务之间的调用链传递，到最后这个小的扰动到底会引发多大的故障，没有人可以预测。在生产上做这样不可控的实验，是很危险的。随着故障注入测试（FIT）的提出，社区开始关注利用应用架构的特性，特别是微服务架构，来控制实验的爆炸半径，比如 Netflix 使用 Zuul 强大的流量检查和管理功能，将受影响的请求隔离到特定的测试帐户或特定设备，避免100％的混乱。

进一步分析发现， FIT 的执行过程也影响了整个系统的监控指标，即实验群体与其他非实验群体的统计指标混合不可分辨：无法确定实验的进行时间，无法评估其影响是否超过了系统本身的噪音。为了进一步的区分，则需要进行更多更大的实验，这将有可能给用户带来不必要的中断。因此需要对实验集群和非实验群集的流量配比进行精细控制，同时因应无人值守的实验要求，则引入微服务架构中的断路器，如其超出预定义的误差预算，自动结束实验。这就是为何 Netflix 提出了新的 ChAP （混沌实验自动平台）以加强故障注入测试。

综上所述，混沌工程的发展不是一蹴而就的， Chaos Monkey 是其开端，但社区对混沌工程的理解在逐步深入，从对基础设施的扰动（ EC2 实例随机终止等），到利用应用网关控制爆炸半径，再到精细化流量配比以区分影响，直至引入断路器实现真正的无人值守。混沌工程9年来的发展，由浅入深，由基础设施演进到应用架构，不是单单运维看看就好。

问题3：混沌工程实验的概念听着很吸引人，可是不知道从而下手。有没有什么实际可落地的框架和工具呢？

答：笔者有幸参与了混沌工程的革新实践，总结起来对混沌工程的理解有两点特别重要：

• 尽量减少实验的爆炸半径（故障注入测试的引入）。为了确保不会破坏生产业务，工程团队需“精心策划”混沌工程实验。
• 混沌实验不只是测试，而是生成新知识的过程（ Chaos Monkey -> Simian Army -> FIT -> ChAP ）

混沌工程试验不仅仅是测试系统的一个案例。另一方面，混沌工程是一种产生新知识的方法。正是因为现代软件系统往往太复杂，任何人都无法完全理解它们，所以工程师通过混沌工程实验以揭示系统的更多面。

当然混沌工程实验有其自身的技术门槛，因此必须专家的指导并配以完善的混沌实验框架和工具。此为整个系列的首篇，后面笔者会深入探讨有关混沌工程实验中涉及的可行性调研、实验场景和环境的设计与计划、工具的选型和配合方式、系统行为的观测方法、以及找到问题后如何改善系统架构和运维模式等等问题 – stay tune for next episode!

可行性评估篇

我们在前文启动篇中谈到混沌工程的发展不是一蹴而就的， Chaos Monkey 开创了混沌工程的先河，从对基础设施的扰动（ EC2 实例随机终止 Chaos Monkey 、模拟可用区中断 Chaos Gorilla 、模拟区域中断 Chaos Kong 等），到利用应用网关控制爆炸半径，再到精细化流量配比以区分影响，直至引入断路器实现真正无人值守的混沌工程实验平台。本篇是混沌工程专栏的第二篇，笔者会探讨大家比较关心的第一个问题——为了能够成功实施混沌工程实验有哪些可行性要求：对实现对象的架构要求？对实验技术能力的要求？对实验工具的要求？还是实验可控性的要求？通常分析这样的问题，我们必须首先弄清楚混沌工程实验的目标。有了明确的目标，才可以深入地评估所做的混沌工程实验是否“可行”，能否“成功实施“

混沌工程的目标 – 实现韧性架构

正如 AWS CTO Werner Vogels 常说的“故障是注定的，随着时间的流逝，一切终将归于失败”。我们必须接受故障发生是新常态的想法，处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个 EC2 实例的小型系统时，100％的健康运行通常是正常状态，故障则是一种特殊情况。然而，在处理大规模系统时，即100％的健康运行几乎是不可能实现的。因此，运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务，这就需要架构本身具备 Resilient 能力。这里我并不想把“Resilient”翻译成弹性，而应该是韧性（具备恢复能力）。混沌工程就是利用实验提前探知系统风险，通过架构优化和运维模式的改进来解决系统风险，真正实现上述韧性架构，降低企业损失，提高故障免疫力。

韧性架构的重要特征

冗余性

架构的设计要增加冗余性，以便提高该系统的整体可用性。如在AWS云中，这意味着将其部署到多个可用区，甚至跨多个区域进行部署。

正如上图中所看到的那样，组件X的可用性是99％（按今天的标准来说非常糟糕），但并行放置，增加冗余性，可以将系统的可用性提高到99.99％！如果将三个组件X并行放置，那么就可以达到6个9的可用性！这个结果很惊人，这就是为什么我们总是建议客户跨多个可用区设计架构。

扩展性

架构的设计必须要考虑扩展性，即启用 Auto Scaling ，根据需求动态扩展资源 – 而不是手动执行 – 确保可以满足各种流量模式。如在AWS云中，可使用 Application Auto Scaling 功能为EC2，DynamoDB和EMR等服务提供相同的自动扩展引擎，以支持AWS外部服务的自动扩展。

不可变基础设施

不可变基础设施指的是，每次部署都会替换相应的组件，不做更新。应用部署则使用金丝雀发布（俗称灰度发布），以减少部署新版本应用时出现故障的风险。使用这种技术，可以在真实的生产环境中进行测试，并在需要时进行快速回滚。

无状态应用

无状态应用是自动扩展和不可变基础设施的先决条件，要求应用必须独立于先前的请求或会话，处理所有客户端请求，并且不会存储在本地磁盘或内存中。

避免级联故障

级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃（俗称蝴蝶效应）。架构设计必须考虑级联故障的处理方式：

• 转移切换：当一个集群宕机时，所有的流量都转移到另一个集群，如跨可用区切换，或者跨区域切换。
• 重试退避：指数退避算法逐渐对客户端重试请求减速，避免网络拥塞，同时添加抖动保证性能，详细讨论参看这里。
• 超时机制：过载请求会将连接耗尽，导致系统宕机。超时机制的引入，服务的质量会下降但不至于系统全面崩溃。
• 幂等操作：由于暂时的错误，客户端可能多次发送相同的请求，可能导致系统处理错误。幂等操作，一种可以反复重复的操作，没有副作用或应用程序的失败，可以消除上述隐患。
• 服务降级：当服务器压力剧增的情况下，有策略地减少或退化部分服务，以此释放服务器资源以保证核心任务的正常运行，如只读模式、停用耗时耗资源的功能等等。
• 拒绝服务：请求过载时，按优先级开始丢弃相应的请求。
• 服务熔断：若某个目标服务调用过慢或者有大量超时，直接熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回响应，快速释放资源，待目标服务情况好转则恢复调用。

基础设施即代码

基础设施即代码可减轻繁琐的手工配置和部署任务，由于可用完全相同的方式反复执行，因此解决了随时间推移引发的配置漂移问题，当有故障发生，基础设施的恢复快速且有效。同时可对基础架构以代码的形式进行版本控制，管理其更新、审核、验证和回溯分析。

弄清楚了混沌工程的目标，现在可以来深入讨论如何来评估混沌工程实验的可行性条件。

混沌工程的可行性评估模型

在执行混沌工程实验时，我们需有一个通用的标准来，判断这个实验可不可行，做得好不好。混沌工程的可行性评估模型，结合了亚马逊和Netflix的混沌工程成熟度模型，从成熟度等级和接纳指数两个维度来衡量混沌工程实验成功实施的可行性：

混沌工程实验的成熟度等级

成熟度可以反映出混沌工程实验的可行性、有效性和安全性。成熟度的级别也会因为混沌工程实验的投入程度而有差异。这里将成熟度等级分为1、2、3、4、5级进行描述，等级越高成熟度越好，混沌工程实验的可行性、有效性和安全性会更有保障。

混沌工程实验的接纳指数

接纳指数通过对混沌工程实验覆盖的广度和深度来描述对系统的信心。暴露的脆弱点就越多，对系统的信心也就越足。类似成熟度等级，对接纳指数也定义了1、2、3、4级进行描述。

混沌工程实验的可行性路线图

把当前项目进行成熟度等级和接纳指数的评估，将两者的结果合并放在一张图上，就可构建出类似于魔力象限的坐标轴。这不仅可以了解当前项目进行混沌工程实验的可行性，同时还可以与其他项目进行差异对比。此外，根据之前所讨论的混沌工程实验目标，设定想要达到的成熟度等级和接纳程度，便获得可行性路线图，了解自身努力的方向。

对照实验设计篇

笔者有感而发画了下面这个混沌工程的小漫画：

“如果你不提早发现和解决问题（引入混沌工程实验），最后问题会来（周末／半夜）解决你”。

我们在启动篇从混沌工程的发展历程出发，分析了社区对混沌工程的理解并不是一蹴而就而是循序渐进，以此得到了第一个重要结论：

结论1 :“并不是只有研发实力突出的大型互联网公司才能实践混沌工程”。

可行性评估篇明确了混沌工程的过去、当前和未来目标（实现韧性系统，如图2所示），为了帮助不同类型的公司来进行实践混沌工程，我们提出了混沌工程的可行性评估模型。

因此，我们得到了第二个重要的结论：

结论2 :“也许很多公司目前仍处在第三象限（实验技术成熟度低、公司接纳指数低），但只要根据可行性评估模型中的逐项要求和未来发展的路线图，迭代推进和持续改进，我们都可以从混沌工程实践中获得收益。”

接下来的问题便是，混沌工程实验要怎么做，具体的设计方法是什么？

混沌工程实验：一个持续性迭代的闭环体系

如图4所示，完整的混沌工程实验是一个持续性迭代的闭环体系，从初步的实验需求和实验对象出发，通过实验可行性评估，确定实验范围，设计合适的观测指标、实验场景和环境，选择合适的实验工具和平台框架；建立实验计划，和实验对象的干系人充分沟通，进而联合执行实验过程，并搜集预先设计好的实验指标；待实验完成后，清理和恢复实验环境，对实验结果进行分析，追踪根源并解决问题，并将以上实验场景自动化，并入流水线，定期执行；之后，便可开始增加新的实验范围，持续迭代和有序改进。

下面我们会深入讨论有关混沌工程实验的准备事项：

• 实验可行性评估
• 观测指标设计与对照
• 实验场景和环境的设计
• 实验工具和平台框架选型（限于篇幅，未完待续）

实验可行性评估

可行性评估篇提供了这样一个混沌工程实验的可行性评估模型，从多个维度对实验技术的成熟度做了定性分析。此处的实验可行性评估，依照这个可行性评估模型，会针对具体的实验需求和实验对象进行细致评估。常见的一个形式是对照“可行性评估问题表”，对实验对象的干系人进行访谈。可行性评估问题表的内容会包含以下几个方面：

• 架构抵御故障的能力：通过对实验对象的架构高可用性的分析和评估，找出潜在的系统单点风险，确定合理的实验范围。
• 实验指标设计：评估目前实验对象判定业务正常运行所需的业务指标、应用健康状况指标和其他系统指标。
• 实验环境选择：选择实验对象可以应用的实验环境：开发、测试、预生产、生产。
• 实验工具使用：评估目前实验对象对实验工具的熟悉程度。
• 故障注入场景及爆炸半径：讨论和选择可行的故障注入场景，并评估每个场景的爆炸半径。
• 实验自动化能力：衡量目前实验对象的平台自动化实施能力。
• 环境恢复能力：根据选定的故障注入场景，评估实验对象对环境的清理和恢复能力。
• 实验结果整理：根据实验需求，讨论确定实验结果和解读分析报告的内容项。

观测指标设计与对照

观测指标设计

观测指标的设计是整个混沌工程实验成功与否的关键之一。最新的调研报告“Chaos Engineering Observability: Bringing Chaos Experiments into System Observability”指出在进行混沌工程实验过程中，系统可观测性已成为一种“强制性功能”，良好的系统可观测性会给混沌工程实验带来一个强有力的数据支撑，为后续的实验结果解读、问题追踪和最终解决提供了坚实的基础。

以下是常见混沌工程实验的观测指标类型：

• 业务性指标：价值最大，探测难度最大
• 应用健康指标：反映应用的健康状况
• 其他系统指标：较易获取，反映基础设施和系统的运行状况

以Netflix为例，早在2008年Netflix起步流媒体，手动追踪数百个指标，全靠人工来检测问题。 这种方法适用于数十台服务器和数千台设备，但不适用于未来的数千台服务器和数百万台设备。最终Netflix找到了一个可以反映业务状况、用户参与度的指标：每秒流视频启动次数SPS (stream-starts-per-second).

SPS指标示例比较（红色=当前周，黑色=前一周）

SPS 模式通常是比较规则的，受到假日和事件等外部影响会有所变化。上图描绘的就是 SPS 随时间变化的波动情况，可以看出，它有一个稳定的模式，每天 SPS 峰值发生在晚上，谷值发生在清晨。这是因为人们习惯于在晚餐时间看电视节目。假期时，白天的观看次数增加，因为有更多的空闲时间在Netflix上观看节目。

观测指标对照

如果我们将过去一周的波动图放在当前的波动图之上，就像上图中当前的图线是红色，上一周的图线是黑色，以求找出其中的差异。由此，我们可用“受SPS影响”或“不影响SPS”来衡量业务的状况。此外，由于 SPS 随时间的变化可以预期，所以我们可用一周前的 SPS 波动图作为稳定状态的模型，并通过使用预期SPS级别与实际SPS级别来衡量业务的可用性。Netflix SPS指标的这种特性，也提醒我们应以观测指标的稳定状态进行对照。

不过可行性评估中，我们发现有很多的用户还是无法定义一个合适的业务指标，如无法准确定义一个稳定状态，那么我们也可以退而求其次，使用多个指标进行联合分析来对照。具体的联合分析方法包括：静态阈值、指数平滑、双指数平滑、贝叶斯检测、马尔可夫链蒙特卡罗方法（MCMC）、鲁棒主成分分析（PCA）等等，后面我们可以专门来详细讨论。

实验场景和环境的设计

实验场景和环境的设计要努力遵循以下三大设计目标：

• 在生产环境运行实验
• 持续自动化运行实验
• 最小化实验场景的“爆炸半径”

实验场景设计

以下是亚马逊云科技云上常见的实验场景：

这些场景的实施能力，依赖于实验工具和平台框架的选型，后面我们会专门来深入讨论。

实验环境设计

实验环境的不同，带来不同的业务风险。生产环境的业务风险最大，开发环境的业务风险最小，其他依次类推。我们会建议用户在生产环境上进行混沌工程实验，当然前提是这些实验场景和工具已经在开发／测试和预生产环境得到了验证。当然在生产环境上进行混沌工程实验也不是强制的，用户可以选择适合自己的推进节奏，逐步向生产环境靠拢。因为实验越接近生产环境，从结果中学到的越多。同时，为了体现实验对照的效果，在生产环境进行的混沌实验可以通过真实生产流量分支的方式，组建控制组和对照组，以此区分故障注入的影响，从一定程度上控制了爆炸半径。对于非生产环境的混沌工程实验，可采用模拟生产流量的方式，尽量和生产流量相似，来验证实验场景和工具的可靠性。

“

未知，

既然避不开，为何不拥抱它？

在实际生产环境中，各种无法预知的事件难以避免，风险隐患无处不在。分布式系统架构的复杂性、海量数据的计算与存储、跨团队协同等，这些都在向系统的稳定性发起挑战。系统不确定性风险的加剧，最终将会波及到我们业务的连续性。

你是否想过：如果整个区域或数据中心出现故障、服务出现访问延迟、系统时钟不同步等这些问题发生，将会带来怎样的后果？其中有些结果我们可以预知，但更多可能在意料之外。这时候，你可以阅读这篇文章了解——“混沌工程”。

01

初识混沌工程

混沌工程 (Chaos Engineering) 是通过主动向系统中引入软件或硬件的异常状态 (扰动)，制造故障场景，并根据系统在各种压力下的行为表现，确定优化策略的一种系统性稳定性保障手段。

Netflix 前云架构师 Adrian Cockcroft，在 2018 年关于混沌工程的演讲中，提出了关于混沌工程的更精确的定义：“混沌工程是一种确保减轻故障影响的实验”。也有人将混沌工程比作疫苗，通过 “接种疫苗” 的方式，让系统具备抵挡 “重大疾病” 的能力。

2010 年底，Netflix 向全世界推出 Chaos Monkey ，其主要功能是随机终止在生产环境中运行的虚拟机实例和容器，模拟系统基础设施遭到破坏的场景，使得工程师能够观察服务是否健壮、有弹性，能否容忍计划外的故障。这就是混沌工程的早期雏形。

混沌工程可以为我们做什么？

混沌工程是故障测试吗？

混沌工程，与故障注入、故障测试等测试方法，有本质上的区别。混沌工程是一种生成新信息的实践，而故障注入是测试已知属性的方法。

在传统测试里，我们可以写一个断言，给定特定的条件，产生一个特定的输出，如果不满足断言条件，就说明测试出错，它不能产出一些让我们始料未及的 “惊喜”。

而混沌工程是探索更多未知场景的实验，实验会有怎样的新信息生成，我们是不确定的。

02

混沌工程原则

以下原则描述了应用混沌工程的理想方式：

可量化的稳定状态

实施混沌工程，首先要了解系统在正常状态下的行为。因为，在人为注入故障后，不仅要评估故障注入对系统造成的影响，还要确保系统能够恢复到这个稳定状态。

因此，需要收集一些可测量的指标，来实现系统稳定状态的可观测性。而业务指标相比系统指标 (如 CPU 负载、内存使用率等)，更能反映系统的健康状态以及用户满意度。

反映真实世界但风险未知的假设

在真实业务场景中，遇到的任何故障都是混沌实验的潜在变量。目前业界已经有了按照 IaaS 层、PaaS 层、SaaS 层划分的故障画像 (如下图)。除了对这些已出现的问题进行分类、优先级排序外，也要对未来可能会出现的新问题保持关注。

图片来源：C114 通信网 https://www.c114.com.cn/tech/169/a1174314.html

同时，践行混沌工程要以接受不确定性为思想前提，即把重点放在发现未知的风险并进行改进，而非做出对实验输入和输出有明确预期的假设。

但是，在决定引入哪些事件时，也需要估算事件发生的概率和最终影响范围，推算造成的成本和复杂度等。

自动化的生产环境实战

同军队演练一样，将每次演习都看作是一次实战。生产环境的服务状态和流量模式等问题也会影响到系统的行为。

因此，最好直接在生产环境中进行混沌实验。混沌工程实验还应该实现自动化且可持续运行，能够全自动的设计、执行和终止实验。

影响最小化

面对未知实验，想要完全避免不出问题是不可能的。在生产环境中进行实验必然是有风险的，但冒这个风险的代价总会比将来大规模业务中断所带来的打击要小。

而我们所要做的就是，使用技术手段最小化故障对客户的影响，即 “最小爆炸半径”，如采取小范围的故障注入、流量路由、数据隔离等手段。

03

如何实施
混沌工程

1. 设计实验

1.1 确定稳态指标

确定一个与用户相关的关键性能指标，如订单量或每秒的流量等。

1.2 创建假设

假设系统会出现哪些问题，注入了相应故障后会发生什么，这个结果可能会对客户造成什么影响。

2.执行实验

2.1 确定实验范围——控制半径

2.2 故障注入

3.故障观察

如果观测到稳态指标受到影响，则可以停止实验。接下来首先评估故障本身，根据指标变化情况来验证 (或反驳) 预先的假设。然后，检查仪表板和警报，看看是否有其他意外变动。

4.事后分析——发现新故障

实验结束后，需要深入分析总结故障的种类、影响、发生的原因以及防止未来发生类似故障的方法。

通过混沌实验，你有可能在系统瘫痪之前，发现了新故障并及时进行了修复，你也有可能会发现，系统对注入的故障具有恢复弹性，因而增强了对系统的信心。

04

开源项目

Chaos Monkey

Chaos Mesh

Chaos Mesh 是一个云原生混沌工程平台，提供了在 Kubernetes 平台上进行混沌测试的能力。

Litmus

Litmus 是一种开源的云原生混沌工程工具集，帮助 K8s SRE 和开发人员发现 K8s 平台和应用的韧性问题。

Chaosblade

ChaosBlade 是阿里巴巴在其自身故障测试和演练实践基础上，结合自身业务场景而开发的面向多集群、多环境、多语言的混沌工程平台。

本文作者

蓝维洲

「DaoCloud 道客」云原生研究院院长