万字长文：深入解读混沌工程

在分布式系统架构下，服务间的依赖日益复杂，很难评估单个服务故障对整个系统的影响，并且请求链路长，监控告警的不完善导致发现问题、定位问题难度增大，同时业务和技术迭代快，如何持续保障系统的稳定性和高可用性受到很大的挑战。我们永远难以全面掌握发生什么事件会导致系统局部不可用，甚至全面崩溃。但我们却可以尽可能地在这些不可用的情况发生之前找出系统中的脆弱点。

Netflix的工程师团队是根据多年实践经验主动发现系统中脆弱点的一整套方法。这套方法现在已经逐渐演变成计算机科学的一门新兴学科，即“混沌工程”。通过一系列可控的实验和执行实验的原则，混沌工程将揭示出分布式系统中随时发生的各类事件是如何逐步导致系统整体不可用的。所以构建稳定性系统很重要的一环是混沌工程，在可控范围或环境下，通过故障注入，来持续提升系统的稳定性和高可用能力。

Chaos engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production. -《混沌工程原理》http://principlesofchaos.org/

混沌工程

混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。

只要你有过在生产环境中实际运行一个分布式系统的经历，你就应该清楚，各种不可预期的突发事件是一定会发生的。分布式系统天生包含大量的交互、依赖点，可能出错的地方数不胜数。硬盘故障，网络不通，流量激增压垮某些组件……我们可以不停地列举下去。这都是每天要面临的常事，任何一次处理不好就有可能导致业务停滞、性能低下，或者其他各种无法预料的异常行为。

在一个复杂的分布式系统中，我们单靠人力并不能够完全阻止这些故障的发生，而应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的、在系统中脆弱的、易出故障的环节。当我们识别出这些风险时，就可以有针对性地对系统进行加固、防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性系统的同时，建立对运行高可用分布式系统的信心。

混沌工程正是这样一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实验验证的方法显然可以为我们打造更具弹性的系统，同时让我们更透彻地掌握系统运行时的各种行为规律。

混沌工程，是一种提高技术架构弹性能力的复杂技术手段。Chaos工程经过实验可以确保系统的可用性。混沌工程旨在将故障扼*在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

它被描述为“在分布式系统上进行实验的学科，目的是建立对系统承受生产环境中湍流条件能力的信心。”

它也可以视为流感疫苗，故意将有害物质注入体内以防止未来疾病，这似乎很疯狂，但这种方法也适用于分布式云系统。混沌工程会将故障注入系统以测试系统对其的响应。这使公司能够为宕机做准备，并在宕机发生之前将其影响降至最低。

如何知道系统是否处于稳定状态呢？通常，团队可以通过单元测试、集成测试和性能测试等手段进行验证。但是，无论这些测试写的多好，我们认为都远远不够，因为错误可以在任何时间发生，尤其是对分布式系统而言，此时就需要引入混沌工程（Chaos Engineering）。

混沌工程首次提出是在2008 年 8 月，由网飞公司(Netflix)提出，当时提出的背景是网飞公司的数据库发生故障使得网飞公司长达三天的停机，经济损失巨大。于是网飞公司开始探索用混沌工程去优化稳定性保障体系，防止此类事件的再次发生，于是2010 年该公司开发Chaos Monkey 程序，其主要功能是随机终止在生产环境中运行的虚拟机实例和容器，模拟系统基础设施遭到破坏的场景，使得工程师能够观察服务是否健壮、有弹性，能否容忍计划外的故障。

2012年Chaos Monkey 在 Simain Army 项目中开源，Simian Army成为首个开源的混纯工程工具集，此举为混沌工程工具的发展打下了基础。

2015年网飞公司正式发布《混沌工程理念》(Principal of Chaos Engineering)，主要介绍了混沌工程实验的目的、意义和方法论。2016 年混沌工程商业公司 Gremlin成立，混沌工程正式走向商用化。

2018 年开始，混沌工程的春天开始来临，国内企业纷纷引入并实践混沌工程，2019年阿里推出国内厂商主导的混沌工程开源项目Chaos Blade，2020年PingCap推出 Chaos Mesh，现已发展成为具备国际顶级影响力的混沌工程项目，并加入CNCF。

今天，包括 Facebook，Amazon，Netflix 和 Google在内的许多公司都有自己的 Chaos Engineer，使用某种形式的混沌工程实验，来提高现代架构的可靠性。

混沌工程、故障注入和故障测试在关注点和工具中都有很大的重叠。

混沌工程和其他方法之间的主要区别在于，混沌工程是一种生成新信息的实践，而故障注入是测试一种情况的一种特定方法。当您想要探索复杂系统可能出现的不良行为时，注入通信延迟和错误等失败是一种很好的方法。但是我们也想探索诸如流量激增，激烈竞争，拜占庭式失败，以及消息的计划外或不常见的组合。如果一个面向消费者的网站突然因为流量激增而导致更多收入，我们很难称之为错误或失败，但我们仍然对探索系统的影响非常感兴趣。同样，故障测试以某种预想的方式破坏系统，但没有探索更多可能发生的奇怪场景，那么不可预测的事情就可能发生。

测试和实验之间可以有一个重要的区别。在测试中，进行断言：给定特定条件，系统将发出特定输出。测试通常是二进制态的，并确定属性是真还是假。严格地说，这不会产生关于系统的新知识，它只是将效价分配给它的已知属性。实验产生新知识，并经常提出新的探索途径。我们认为混沌工程是一种实验形式，可以产生关于系统的新知识。它不仅仅是一种测试已知属性的方法，可以通过集成测试更轻松地进行验证。

混沌实验的输入示例：

• 模拟整个区域或数据中心的故障。
• 部分删除各种实例上的Kafka主题。
• 重新创建生产中发生的问题。
• 针对特定百分比的交易服务之间注入一段预期的访问延迟。
• 基于函数的混乱（运行时注入）：随机导致抛出异常的函数。
• 代码插入：向目标程序添加指令和允许在某些指令之前进行故障注入。
• 时间旅行：强制系统时钟彼此不同步。
• 在模拟I/O错误的驱动程序代码中执行例程。
• 在 Elasticsearch 集群上最大化CPU核心。

混沌工程实验的机会是无限的，可能会根据您的分布式系统的架构和您组织的核心业务价值而有所不同。

分布式系统日益复杂，而且在系统逐渐云化的背景下，系统的稳定性受到很大的挑战。这里从四个角色来说明混沌工程的重要性。

• 对于架构师来说，可以验证系统架构的容错能力，比如验证现在提倡的面向失败设计的系统；
• 对于开发和运维，可以提高故障的应急效率，实现故障告警、定位、恢复的有效和高效性。
• 对于测试来说，可以弥补传统测试方法留下的空白，之前的测试方法基本上是从用户的角度去做，而混沌工程是从系统的角度进行测试，降低故障复发率。
• 对于产品和设计，通过混沌事件查看产品的表现，提升客户使用体验。所以说混沌工程面向的不仅仅是开发、测试，拥有最好的客户体验是每个人的目标 所以实施混沌工程，可以提早发现生产环境上的问题，并且可以以战养战，提升故障应急效率和可以使用体验，逐渐建设高可用的韧性系统。

实施混沌工程可以提早发现生产环境上的问题，提升故障应急处理效率、梳理服务间的强弱依赖关系、验证预案有效性等等，逐渐建设具有韧性的高可用系统。

尽管混沌测试的好处是显而易见的，但它是一种应该慎重进行的实践。以下是最关心的问题和挑战。

• 不必要的损坏。混沌测试的主要问题是可能造成不必要的损坏。混沌工程可能导致超出合理测试允许的实际损失。为了限制发现应用程序漏洞的成本，组织应避免超出指定爆炸范围的测试。目标是控制爆炸半径，以便您可以查明故障原因，而无需引入新的故障点。
• 缺乏可观察性。建立这种控制说起来容易做起来难。缺乏对爆炸半径可能影响的所有系统的端到端可观察性和监控是一个常见问题。如果没有全面的可观察性，可能很难理解关键依赖关系与非关键依赖关系，或者很难有足够的上下文来理解故障或降级的真正业务影响，以便确定修复的优先级。缺乏可见性还可能使团队难以确定问题的确切根本原因，这会使补救计划复杂化。
• 不清楚启动系统状态。另一个问题是在测试运行之前清楚地了解系统的启动状态。如果没有这种清晰度，团队可能难以理解测试的真实效果。这会降低混沌测试的有效性，并使下游系统面临更大的风险，并使控制爆炸半径变得更加困难。

第一条：”建立一个围绕稳定状态行为的假说“，其包含两个含义，一个是定义能直接反应业务服务的监控指标，需要注意的是这里的监控指标并不是系统资源指标，比如CPU、内存等，这里的监控指标是能直接衡量系统服务质量的业务监控。举个例子，一个调用延迟故障，请求的 RT 会变长，对上层交易量造成下跌的影响，那么这里交易量就可以作为一个监控指标。这条原则的另一个含义是故障触发时，对系统行为作出假设以及监控指标的预期变化。

第二条指模拟生产环境中真实的或有理论依据的故障场景，比如依赖的服务调用延迟、超时、异常等。

第三条建议在生产环境中运行实验，但也不是说必须在生产环境中执行，只是实验环境越真实，混沌工程越有价值，但如果知道系统在某个故障场景下不具备容灾能力，不可以执行此混沌实验，避免资损发生。

第四条，持续的执行才能持续的降低故障复发率和提前发现故障，所以需要持续的自动化运行试验。

最后一个，混沌工程很重要的一点是控制爆炸半径，也就是试验影响面，防止预期外的资损发生，可以通过环境隔离或者故障注入工具提供的配置粒度来控制。

1. 提升系统的容错能力，提高稳定性
2. 评估系统容灾红线
3. 验证云服务、云资源的动态扩容能力
4. 验证监控、告警的有效性和问题处理流程是否完善
5. 故障突袭，提升相关人员定位、恢复问题的能力

混沌工程以实验发现系统性弱点。这些实验通常遵循以下四个步骤：

1.定义并测量系统的“稳定状态”。首先精确定义指标，表明您的系统按照应有的方式运行。Netflix使用客户点击视频流设备上播放按钮的速率作为指标，称为“每秒流量”。请注意，这更像是商业指标而非技术指标;事实上，在混沌工程中，业务指标通常比技术指标更有用，因为它们更适合衡量用户体验或运营。

2.创建假设。与任何实验一样，您需要一个假设来进行测试。因为你试图破坏系统正常运行时的稳定状态，你的假设将是这样的，“当我们做X时，这个系统的稳定状态应该没有变化。”为什么用这种方式表达？如果你的期望是你的动作会破坏系统的稳定状态，那么你会做的第一件事会是修复问题。混沌工程应该包括真正的实验，涉及真正的未知数。

3.模拟现实世界中可能发生的事情，目前有如下混沌工程实践方法：模拟数据中心的故障、强制系统时钟不同步、在驱动程序代码中模拟I/O异常、模拟服务之间的延迟、随机引发函数抛异常。通常，您希望模拟可能导致系统不可用或导致其性能降低的场景。首先考虑可能出现什么问题，然后进行模拟。一定要优先考虑潜在的错误。“当你拥有非常复杂的系统时，很容易引起出乎意料的下游效应，这是混沌工程寻找的结果之一，”“因此，系统越复杂，越重要，它就越有可能成为混沌工程的候选对象。”

4.证明或反驳你的假设。将稳态指标与干扰注入系统后收集的指标进行比较。如果您发现测量结果存在差异，那么您的混沌工程实验已经成功 - 您现在可以继续加固系统，以便现实世界中的类似事件不会导致大问题。或者，如果您发现稳定状态可以保持，那么你对该系统的稳定性大可放心。

各式各样的故障。这些故障信息就是最真实的混沌工程变量。为了能够更体感、有效率地描述故障，我们优先分析了P1和P2的故障（P是阿里对故障等级的描述），提出一些通用的故障场景并按照IaaS层、PaaS层、SaaS层的角度绘制了故障画像。

从故障的完备性角度来看，上述画像只能粗略代表部分已出现的问题，对于未来可能会出现的新问题也需要一种手段保持兼容。在更深入的进行分析之后，我们定义了另一维度的故障画像：

• 任何故障，一定是硬件如IaaS层，软件如PaaS或SaaS的故障。并且有个规律，硬件故障的现象，一定可以在软件故障现象上有所体现。
• 故障一定隶属于单机或是分布式系统之一，分布式故障包含单机故障。
• 对于单机或同机型的故障，以系统为视角，故障可能是当前进程内的故障，比如：如FullGC，CPU飙高；进程外的故障，比如其他进程突然抢占了内存，导致当前系统异常等。
• 同时，还可能有一类故障，是人为失误，或流程失当导致，这部分我们今天不做重点讨论。

从故障注入实现角度，我们也是参照上述的画像来设计的。之前我们是通过Java字节码技术和操作系统层面的工具来分别模拟进程内和进程外的故障。随着Serverless、Docker等新架构、新技术的出现，故障实现机制和承接载体也将会有一些新的变化。

针对上述故障场景模拟，在真实展开实验时分为两个阶段：准备阶段、执行阶段。

1）准备阶段

• 确认本次实验需要验证的目标。遵循建立稳定状态的假设、多样化现实世界事件的原则。例如：Redis的超时不会对系统影响。代码中已经对Redis超时的情况做了相关的工作，保证业务的可靠。实验只是用来测试验证。
• 选择实验范围。遵循对线上业务影响最小、尽量与生产环境相近的原则。例如先测试环境验证，生产环境选择最小量用户验证。
• 确认监控指标。例如：订单成交量、应用请求响应时间、应用响应错误率，做好监控实时查看状态。
• 团队成员沟通。遵循最小化影响范围。确保团队相关成员了解实施情况，关注业务状态。准备阶段一般只是第一次实验的时候操作，一旦验证好了以后以后，后续重复执行本次工程不需要重新准备，除非对实验过程有变动。

2）执行阶段

• 执行实验。遵循最小化影响范围。执行过程中实时关注指标，如果有异常，随时终止实验。例如，把Redis延时调大，查看监控指标是否有异常。
• 分析结果。遵循最小化影响范围。根据收集的指标数据确认假设Redis的超时不会对系统影响。如果验证假设不成立，则需要分析代码，确认好原因，再组织下一次的混沌工程实验。
• 扩大实验范围。遵循最小化影响范围。先小范围测试，再逐步扩大测试范围。
• 自动化。遵循持续自动化运行实验。当对代码有足够的信心之后，将混沌工程实践做成自动化，让混沌工程实验能够持续保证业务的可用性，获得最大的价值。

为了减轻对生产环境的破坏，混沌工程师从非生产环境开始，然后以可控的方式慢慢扩展到生产环境。一旦建立，混沌工程就成为微调服务水平指标和目标、改进警报和构建更高效仪表板的有效方法，因此您知道您正在收集准确观察和分析环境所需的所有数据。

大家可以从工具的场景丰富度、类型、易用性等方面来选择一款合适的工具，awesome-chaos-engineering Github 项目收纳了一些开源的混沌工程工具，在 CNCF Landscape 中混沌工程作为单独的一个领域存在，并且收纳了一些主流的工具。

开源工具：

kube-monkey、PowerfulSeal、ChaosIQ，提供了一些容器层面的故障注入能力。详细可以看：

https://Github.com/dastergon/awesome-chaos-engineering

阿里已开源一款混沌工程测试工具 ChaosBlade，提供基础资源、应用服务、容器等多维度的故障模拟能力。

商业化工具：

Gremlin 提供一款商用的故障注入平台，部分功能免费，目前在公测中。

阿里云 - 应用高可用服务（AHAS）：AHAS 供了基于混沌工程原则的完整的实现，除了提供常见的故障注入能力，默认也打通了一些常见的云服务，提升系统的可观测性和自动化能力。目前免费公测中（支持非阿里云机器公网使用）。

混沌工程工具对比：

下文重点介绍阿里开源的ChaosBlade 及其相关实践。

阿里巴巴探索混沌工程的时间线和 Netflix 差不多，只不过 Netflix 从基础资源开始实践，阿里巴巴则是从应用层开始。阿里巴巴最开始是为了解决技术架构变化和组织变化的问题，才去演进一些新的实践。针对于混沌工程，阿里巴巴最初的概念叫做故障演练，故障演练的概念定义如下：

故障演练（MonkeyKing）：是阿里巴巴在混沌工程领域的产品，目标是沉淀通用的故障模式，以可控成本在线上重放，以持续性的演练和回归方式运营来暴露问题，不断推动系统、工具、流程、人员能力的不断前进。

阿里于2019年开源的ChaosBlade混沌工程产品，早期内部叫做Eos，整体看一下阿里巴巴混沌工程的发展路线：

• 2012年，Eos 1.0(强弱依赖系统统)开发完成，在线下环境进行应用依赖的检测。
• 2013年2月，Eos 2.0，尝试在二套环境下面进行检测，通过SCM脚本自动化安装应用，减少人工安装应用成本。
• 2013年5月，完成二套环境下面的改造，应用检测的自动化完成。
• 2013年7月，开始和持续集成团队合作，复用测试用例，做接口级别的依赖检测。
• 2014年7月，进入Eos 3.0，基于RPC进行故障模拟，不依赖具体的环境，更加丰富的注解，实现强弱依赖的自动化。
• 2015年8月，Eos 4.0，全部基于ASM字节码技术进行故障模拟，不依赖具体的环境，丰富的注解，支持根据用户ID进行屏蔽和检测，主要围绕自动化、常态化、降低成本几个方面发展，实现强弱依赖的常态化运行。
• 2015年12月，与线上测试团队产品进行合作，识别压测数据，尝试在线上进行故障演练。
• 2016年，故障演练项目立项（GOC 中间件），重新设计架构和产品流程，确定产品名为MonkeyKing，在交易和中间件链路尝试演练。
• 2016年11月，开始筹备和推进线上微灰度环境的建设。
• 2017年3月，具备前后端灰度隔离的能力，可以基于业务、比例来筛选特征流量，通过真实的流量来替换原来的测试流量。
• 2017年，成立双11故障演练项目组（GOC 中间件），优化产品流程和使用体验，把演练推广到更多业务线，演练场景3.9k个。
• 2018年，演练场景7.6k个。
• 2018年9月，应用高可用服务（AHAS）在阿里云公测，故障演练服务面向公有云客户输出。
• 2018年10月，阿里巴巴实践混沌工程的实践产品AHAS也被列入CNCF混沌工程云原生全景图中。

混沌工程一步步走进阿里巴巴，大致可以分为五个阶段：

第一个阶段在 2012 年，阿里巴巴电商业务遇到了微服务依赖不合理的问题，导致整个系统架构出问题，花了很长的时间做依赖的自动识别及治理，最后通过打破业务和稳定性之间的边界、引入故障注入的技术，解决了微服务的问题。

第二个阶段，阿里巴巴开始尝试做线上容灾、异地多活等容灾技术。通过比较大的断网等机房切换演练等方式，解决问题。

第三个阶段是里程碑的阶段。在 2015 年备战双十一之后，阿里巴巴技术团队发现整个备战的方法可以非常体系化：当系统复杂到一定阶段，纸面梳理已经难以解决问题，是否可以通过一种逆向的方式暴露问题？2015-2016 年，阿里巴巴开始去做线上故障演练，也是今天提到的混沌工程的前期阶段。在这个阶段的核心是希望借助混沌工程解决分布式技术，不只是微服务，对整个线上稳定性的问题做全方位的度量，包括工具系统和监控预案等。

第四个阶段开始于 2018年，阿里巴巴开始做两件事情：阿里云技术团队开始对云底座进行混沌工程探索，提升基础设施的韧性；伴随着阿里巴巴技术上云，开始把内部的高可用保障技术，通过云的方式对外输出，解决客户应用高可用的问题。可以看到，随着云服务云能力的对外输出，混沌工程能力开始服务外部客户。

等到第五个阶段，也就是在 2019 年 -2021 年，阿里巴巴在混沌工程上的探索开始分为两条线，一条是商业服务和开源一体化，清晰化技术演进路线、加速技术演进速度，体现在现在就是面向开发者的一站式混沌工程平台；另一条是阿里巴巴集团内部把混沌工程重视程度提到一个空前的规模。

2020 年阿里巴巴做了生产突袭项目，把所有可能影响高可用的重大故障因子，全部都聚合在一个平台，公司的管理层会在一个不定时的时刻随机的去发起这种突袭。这次生产突袭的核心要求是，被突袭业务具备在1分钟发现，5分钟定位，10 分钟恢复。

在这个阶段，已经把混沌工程和阿里巴巴集团的上云，包括人员组织的应急，已经完全串联起来，在内部的阶段沉淀到今天，其实已经是一个比较好的阶段。在阿里巴巴内部，将“高可用架构”和“韧性架构组织”升级成为“安全生产”，目前混沌工程已经成为安全生产的一个基础能力，现在内部的各个团队借助混沌工程去自发性地做垂直演练。基本上覆盖了阿里巴巴内部的几千个应用，所有的核心业务都有覆盖。

在阿里巴巴内部有一个制度：第一，被演练过的所有发生的故障，都要具备线上可演练的机制，真正验证是否可以恢复；第二，所有微服务的架构或分布式系统的架构，一级或核心级应用与非核心级别的应用的关系不能是强依赖，需要有自己的预案；第三，从组织的角度有一定的验收，比如说监控发现率、问题处理率等，需要在一个量化的数字之间。

ChaosBlade 中文名混沌之刃，是阿里巴巴开源的一款混沌实验实施工具，支持丰富的实验场景，比如应用、容器、基础资源等。工具使用简单，扩展方便，其遵循社区提出的混沌实验模型。

Github 地址：

https://github.com/chaosblade-io/chaosblade

• 场景丰富度高: ChaosBlade 支持的混沌实验场景不仅覆盖基础资源，如 CPU 满载、磁盘 IO 高、网络延迟等，还包括运行在 JVM 上的应用实验场景，如 Dubbo 调用超时和调用异常、指定方法延迟或抛异常以及返回特定值等，同时涉及容器相关的实验，如*容器、* Pod。后续会持续的增加实验场景。
• 使用简洁，易于理解: ChaosBlade 通过 CLI 方式执行，具有友好的命令提示功能，可以简单快速的上手使用。命令的书写遵循阿里巴巴集团内多年故障测试和演练实践抽象出的故障注入模型，层次清晰，易于阅读和理解，降低了混沌工程实施的门槛。
• 动态加载，无侵入: ChaosBlade采用动态故障注入的方式，执行混沌实验时用户系统不需要做任何系统改造或发布，开箱即用。
• 场景扩展方便: 所有的 ChaosBlade 实验执行器同样遵循上述提到的故障注入模型，使实验场景模型统一，便于开发和维护。模型本身通俗易懂，学习成本低，可以依据模型方便快捷的扩展更多的混沌实验场景。

在 ChaosBlade Release 页面下载最新版本的包，解压即用。如创建一个 CPU 满载实验，命令为：

blade create cpu fullload

其他故障场景在这里就不一一列举了，想了解更多故障场景使用方法可参考：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/。

ChaosBlade 本质上是一个故障注入的工具集，它提供了故障注入，故障销毁，状态查询等多种能力，也支持多种故障场景例如:基础资源、java、docker、k8s等。

但是缺点也比较明显，它没有可视化的界面，也不能对故障场景进行管理，多个故障注入也没有编排能力，每一次故障注入都需要先到目标机器上安装ChaosBlade等等，这对于真正的落地使用混沌工程来说还是有很多挑战的。

为了解决上面提到的问题，在2021年重磅开源混沌工程平台ChaosBlade-Box，提供统一的可视化界面，并提供演练场景，经验库，应用管理，探针管理，演练编排等功能。

该模型分四次，层层递进，很清晰的表达出对什么组件做实验，实验范围是什么，实验触发的匹配规则有哪些，执行什么实验。该模型简洁、通用，语言领域无关、易于实现。阿里集团内的 C 、NodeJS、Dart 应用以及容器平台的实验场景都基于此模型实现。此模型具有很重要的意义，依据此模型可以更精准的描述、更好的理解、更方便沉淀实验场景以及发掘更多的场景。依据此模型实现的工具更加规范、简洁。实验模型介绍可详见：混沌实验模型介绍(https://github.com/chaosblade-io/chaosblade/wiki/混沌实验模型)。

此拓扑图来自于阿里云 AHAS 产品架构感知功能，可自动感知架构拓扑，并且可以展示进程、网络、节点等数据。这个分布式服务 Demo 分三级调用，consumer 调用 provider，provider 调用 base，同时 provider 还调用 mk-demo 数据库，provider 和 base 服务具有两个实例，在 AHAS 架构拓扑图上，我们点击一个实例节点，可以到非常清晰的调用关系。我们后面结合这个 Demo 去讲解实践。

案例一，我们验证系统的监控告警性有效性。按照前面提到的混沌工程实施步骤，那么这个案例执行的实验场景是数据库调用延迟，我们先定义监控指标：慢 SQL 数和告警信息，做出期望假设：慢 SQL 数增加，钉钉群收到慢 SQL 告警。接下来执行实验。我们直接使用 ChaosBlade 工具执行，可以看下左下角，我们对 demo-provider 注入调用 mysql 查询时，若数据库是 demo 且表名是 d_discount，则对 50% 的查询操作延迟 600 毫秒。我们使用阿里云产品 ARMS 做监控告警。大家可以看到，当执行完混沌实验后，很快钉钉群里就收到了报警。所以我们对比下之前定义的监控指标，是符合预期的。但需要注意的是这次符合预期并不代表以后也符合，所以需要通过混沌工程持续性的验证。出现慢 SQL，可通过 ARMS 的链路追踪来排查定位，可以很清楚的看出哪条语句执行慢。

前面讲了一个符合预期的案例，我们再来看一个不符合预期的。此案例是验证系统异常实例隔离的能力，我们的 Demo 中 consumer 调用 provider 服务，provider 服务具有两个实例，我们对其中一个注入延迟故障，监控指标是 consumer 的 QPS，稳态在 510 左右。我们做的容错假设是系统会自动隔离或下线出问题的服务实例，防止请求路由的此实例，所有 QPS 会有短暂的下跌，但很快会恢复。这个案例，我们使用阿里云 AHAS 混沌实验平台来执行，我们对 demo-provider-1 注入延迟故障，基于此平台可以很方便的执行混沌实验。执行混沌实验后，QPS 下跌到 40 左右，很长时间没有自动恢复，所以不符合预期，我们通过人工的方式对该异常的实例做下线处理，很快就看到，consumer 的 QPS 恢复正常。所以我们通过混沌工程发现了系统问题，我们后面需要做就是记录此问题，并且推动修复，后续做持续性的验证。

混沌工程会越来越多的应用于分布式系统之中，特别越来越庞大、越来越复杂的云原生环境，需要借助混沌工程的方式来持续探索和减少脆弱的节点，持续增强抗脆弱性能力，从而适应和满足不同场景下的稳定性、韧性需求。

单纯的依靠混沌工程并不能够保证系统100%可靠，关于系统的稳定性更多的可以参考我之前写的文章：

稳定性实践

孔凡勇，公众号：互联网技术集中营万字长文：系统稳定性治理最佳实践

通过混沌测试实践,在如何开展混沌测试方面取得一定经验。同时,也引发进一步思考,通过对实施流程进行分析,总结出以下改进思路:

1.在混沌工程的实施过程中,要做好演练样例的复用、演练测试场景的回放以及权限管理和爆炸范围的控制。由于混沌测试是一个持续的演练过程,演练样例复用可以一定程度上提高工作效率。支持演练场景回放有助于演练系统排查故障发生时的可靠性缺陷,减少缺陷定位的时间。爆炸范围的控制及权限管理,提高故障演练环境可用性,不会对其他应用系统正常运行造成影响。未来,建设混沌测试平台的时候,在完成上述功能的前提下,还需要提供自动化编排及执行能力和供其他系统集成的接口,实现工具自动化部署。

2.演练测试环境隔离,完善管理流程制度。由于在故障演练测试环境中,系统不一定会稳定的提供服务,因此需要在测试环境方面做好隔离,避免系统测试过程受到不可控影响。在混沌测试平台建设过程中,不仅要将演练测试环境与其他测试环境隔离,还需要做好权限的管理,避免各模块演练测试的相互影响。同时,配套的管理流程及规章制度,帮助混沌测试演练更加规范化、合理化的使用,避免多人同时进行造成演练测试结果不准确、结果不符合预期等问题。

3.拓宽混沌工程在应用系统各阶段的使用价值。目前混沌工程理论多用于开展混沌测试,实际上,对于开发、系统运维人员而言,均有不可小觑的作用。通过混沌演练测试,我们可以积累丰富的故障场景以及故障画像,它们不仅是测试人员的资产,也在系统运维阶段可以发挥价值。系统运维人员可以参考故障演练测试收集的故障画像,在生产发生可靠性相关异常的时候进行快速定位,减小系统异常造成的损失。对于开发人员,可以将混沌工程工具用于系统开发使用框架、组件等方面的测试中,尽早发现开发框架及组件的可靠性缺陷。