鲜为人知的混沌工程，到底哪里好？

混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里电商域在2010年左右开始尝试故障注入测试的工作，希望解决微服务架构带来的强弱依赖问题。通过本文，你将了解到：为什么需要混沌工程，阿里巴巴在该领域的实践和思考、未来的计划。

一、为什么需要混沌工程？

（翻译自Chaos Engineering电子书）

1.1 混沌工程与故障测试的区别

混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心，最早由Netflix及相关团队提出。

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

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

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

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

混沌实验的输入示例：

模拟整个区域或数据中心的故障。

部分删除各种实例上的Kafka主题。

重新创建生产中发生的问题。

针对特定百分比的交易服务之间注入一段预期的访问延迟。

基于函数的混乱（运行时注入）：随机导致抛出异常的函数。

代码插入：向目标程序添加指令和允许在某些指令之前进行故障注入。

时间旅行：强制系统时钟彼此不同步。

在模拟I/O错误的驱动程序代码中执行例程。

在 Elasticsearch 集群上最大化CPU核心。

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

1.2 实施混沌工程的先决条件

要确定是否已准备好开始采用混沌工程，需要回答一个问题：你的系统是否能够适应现实世界中的事件，例如服务故障和网络延迟峰值？

如果答案是“否”，那么你还有一些工作要做。

混沌工程非常适合揭露生产系统中未知的弱点，但如果确定混沌工程实验会导致系统出现严重问题，那么运行该实验就没有任何意义。先解决这个弱点，然后回到混沌工程，它将发现你不了解的其他弱点，或者它会让你发现你的系统实际上是有弹性的。混沌工程的另一个基本要素是可用于确定系统当前状态的监控系统。

1.3 混沌工程原则

为了具体地解决分布式系统在规模上的不确定性，可以把混沌工程看作是为了揭示系统弱点而进行的实验。破坏稳态的难度越大，我们对系统行为的信心就越强。如果发现了一个弱点，那么我们就有了一个改进目标。避免在系统规模化之后问题被放大。以下原则描述了应用混沌工程的理想方式，这些原则来实施实验过程。对这些原则的匹配程度能够增强我们在大规模分布式系统的信心。

二、阿里巴巴在混沌工程领域的实践：故障演练

混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里电商域在2010年左右开始尝试故障注入测试的工作，开始的目标是想解决微服务架构带来的强弱依赖问题。后来经过多个阶段的改进，最终演进到 MonkeyKing（线上故障演练平台）。从发展轨迹来看，阿里的技术演进和Netflix的技术演进基本是同时间线的，每个阶段方案的诞生都有其独特的时代背景和业务难点，也可以看到当时技术的局限性和突破。

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

目前阿里巴巴集团范围内的实践偏向于故障测试，即在一个具体场景下实施故障注入实验并验证预期是否得到满足。这种测试的风险相对可控，坏处是并没有通过故障注入实验探索更多的场景，暴露更多的潜在问题，测试结果比较依赖实施人的经验。当前故障测试的预期比较两级分化，要么过于关注系统的内部细节，要么对于系统的表现完全没有预期，与混沌工程定义的稳态状态行为差异比较大。

引起差异的根本原因还是组织形态的不同。2014年，Netflix团队创建了一种新的角色，叫作混沌工程师（Chaos Enigneer），并开始向工程社区推广。而阿里目前并没有一个专门的职位来实施混沌工程，项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。

2.2 多样化真实世界的事件

阿里巴巴因为多元化的业务场景、规模化的服务节点及高度复杂的系统架构，每天都会遇到各式各样的故障。这些故障信息就是最真实的混沌工程变量。为了能够更体感、有效率地描述故障，我们优先分析了P1和P2的故障（P是阿里对故障等级的描述），提出一些通用的故障场景并按照IaaS层、PaaS层、SaaS层的角度绘制了故障画像。

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

任何故障，一定是硬件如IaaS层，软件如PaaS或SaaS的故障。并且有个规律，硬件故障的现象，一定可以在软件故障现象上有所体现。

故障一定隶属于单机或是分布式系统之一，分布式故障包含单机故障。

对于单机或同机型的故障，以系统为视角，故障可能是当前进程内的故障，比如：如FullGC，CPU飙高；进程外的故障，比如其他进程突然抢占了内存，导致当前系统异常等。

同时，还可能有一类故障，是人为失误，或流程失当导致，这部分我们今天不做重点讨论。

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

2.3 在生产环境中运行实验

从功能性的故障测试角度来看，非生产环境去实施故障注入是可以满足预期的，所以最早的强弱依赖测试就是在日常环境中完成的。不过，因为系统行为会根据环境和流量模式有所不同，为了保证系统执行方式的真实性与当前部署系统的相关性，推荐的实施方式还是在生产环境（仿真环境、沙箱环境都不是最好的选择）。

很多同学恐惧在生产环境执行实验，原因还是担心故障影响不可控。实施实验只是手段，通过实验对系统建立信心是我们的目标。关于如何减少实验带来的影响，这点在"最小化爆炸半径"部分会有阐述。

2.4 持续自动化运行实验

2014年，线下环境的强弱依赖测试用例是默认在每次发布后自动执行的。2015年，开始尝试在线上进行自动化回归。不过发展到最近两年，手动实验的比例逐渐变高。原因也不复杂，虽然故障注入自动化了，业务验证的成本仍然比较高。在业务高速发展、人员变化较快的环境之下，保持一套相对完善的线上回归用例集对是见非常难的事情。虽然也出现了流量录制技术，不过因为混沌工程实验本身会打破系统已有的行为，基于入口和出口的流量比对的参考度就下降许多。

为了解决测试成本问题，2017年初开始推进线上微灰度环境的建设。基于业务、比例来筛选特征流量，通过真实的流量来替换原来的测试流量，通过监控&报警数据来替代测试用例结果。目前已经有部分业务基于微灰度+故障演练的模式来做演练验证（比如：盒马APOS容灾演习）。

因为故障演练之前是作为一个技术组件被嵌入到常态和大促的流程中，所以在系统构建自动化的编排和分析方面的产品度并不高。演练可视化编排和能力开放会是我们团队未来的一个重点，下文中的规划部分会有所阐述。

2.5 最小化爆炸半径

在生产中进行试验可能会造成不必要的客户投诉，但混沌工程师的责任和义务是确保这些后续影响最小化且被考虑到。对于实验方案和目标进行充分的讨论是减少用户影响的最重要的手段。但是从实际的实施角度看，最好还是通过一些技术手段去最小化影响。Chaos Engineering和Fault Injection Test的核心区别在于：是否可以进一步减小故障的影响，比如微服务级别、请求级别甚至是用户级别。在MonkeyKing演进的中期阶段，已经可以实现请求级别的微服务故障注入。虽然那个时候演练实施的主要位置在测试环境，但初衷也是为了减少因为注入故障而导致的环境不稳定问题。除了故障注入，流量路由和数据隔离技术也是减少业务影响的有效手段。