混沌工程的力量：阿里周洋亲述这一技术背后那些事儿

阿里巴巴技术团队对混沌工程的研发迭代持续了数年，对于这一技术，阿里为什么如此坚持？

2010 年底，Netflix 向全世界推出 Chaos Monkey （混乱猴子），该技术以在生产环境中随机关闭服务节点而“恶名远扬”，这就是目前熟知的混沌工程的早期雏形。《Chaos Engineering》书中是这样描述的：

混乱猴子的美妙之处就在于此，它能尽可能地将服务节点失效的痛苦提到最前，同时让所有工程师在构建一个具有足够弹性应对失败的系统上，达成一个一致的目标。

混乱猴子的灵感来自于 Netflix 几年前搬迁上云的过程，主要是为了解决该阶段暴露的问题。然而，目前不少企业的上云进程依旧缓慢，这种状态下是否还需要混沌工程？随着软件的测试流程越来越成熟且完善，是否有必要花费精力搞混沌工程？如果需要，这一领域有哪些开源工具可供快速部署实践？

针对上述问题，InfoQ 记者在QCon 2019 全球软件开发大会的现场采访了阿里巴巴高级技术专家周洋（花名：中亭），并与业内多名技术专家进行了不同程度的交流，本文将试图通俗讲解混沌工程的含义、作用及阿里巴巴的实践经验。

混沌工程的含义

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

这句话同样出自《Chaos Engineering》，粗看起来，这一含义有些晦涩难懂。如果简单概括下，周洋对混沌工程的理解是如下四点：

• 一种拥抱失败的技术文化

• 一套抽象严谨的实践原则

• 一种主动防御的稳定性手段

• 一个高速发展的技术领域

从原理性角度来讲，周洋认为，实施混沌工程是分布式系统构建业务的必然选择。一方面架构的复杂性让系统负责人员很难自信承诺实际情况一定符合预期设计。另一方面组织对 ROI（投资回报率）的追求，又要求稳定性团队不能只是一个成本中心，所有措施要富有成效。业内不少工程师倾向于将混沌工程比作疫苗，通过"接种疫苗"的方式，让系统具备抵挡"重大疾病"的能力。混沌工程的原则又可以概括为：建立一个围绕稳定状态行为的假说；多样化真实世界的事件；在生产环境中运行实验；持续自动化运行实验；最小化爆炸半径。

想必看到混沌工程的那一刻，不少人脑海中会闪过一个词“测试”。如今，故障注入和故障测试的手段已经非常成熟，为什么还需要混沌工程。周洋认为，这之间存在一定重叠性，但混沌工程是发现新信息的实践。

故障注入和故障测试是通过引入故障，让程序走入一些不常经过的路径，以此提高程序覆盖率，是对特定条件、变量的验证。混沌工程虽然也使用短期度量结果代表系统状态，但该度量结果一般是监控指标，而非具体的接口返回值。混沌工程是围绕稳态进行验证和探索的过程，比如混乱猴子随机杀死部分节点的行为，每次实验都可能产生新的数据。

举例来说，故障注入的典型场景是对系统服务注入通信故障，比如超时、错误等，但无法探究流量激增、资源竞争条件等其他异常行为，这个实践过程本质上并不能发掘系统内未知或尚不明确的认知。而混沌工程的输入条件可能是模拟整个云服务区域或数据中心故障；挑选一个时间段，和针对一部分流量，对其涉及的服务间调用注入一些特定的延时；方法级别的混乱（运行时注入），让方法随机抛出各种异常等。

此外，实施混沌工程的人员也有所不同。周洋表示，以阿里内部的全链路压测为例，实施主要还是研发人员为主。传统意义上，测试人员更关注上线前的状况，之后交由 SRE 团队负责运维。混沌工程可以理解为测试的思想，但并不一定只有测试人员操刀，可以是 SRE、研发、技术支持甚至运营。

不为，就不需要混沌工程？

所谓不为，此处可以理解为较低频次的迭代和平缓的业务变更。如上文所言，Netflix 对混沌工程的探索起源于数据中心迁移上云的过程，因此不乏有企业认为只要不进行大规模的云迁移，就不需要实践混沌工程。

其实，这种想法是非常片面的。无论是激进的架构变迁，还是平缓的系统迭代，很多问题并不是因为迁移上云才出现，只是因为迁移上云才被暴露出来。

只要有过在生产环境中实际运行分布式系统的经历，一定会清楚分布式系统天生包含大量交互、依赖点，可以出错的地方数不胜数，比如硬盘故障、网络不通、流量激增压垮系统等，人力并不能完全阻止故障发生，而应该在异常行为被触发之前，尽可能多地识别出系统中脆弱且易出故障的环节。

根据 Netflix 的实践历程，尝试破坏系统和服务很简单，但并不是全都可以有建设性、高效地发现问题。周洋认为，严格来讲，混沌工程与云的关系不大，但目前大部分企业都处于云迁移、云就绪或者云原生的不同阶段，上云已经成为无法阻挡的趋势，该阶段正是故障爆发的高发期，这些问题可能潜藏在系统中良久，只是一直未被集中发现。虽然上云集中变革的是基础设施层面，但需要某种手段验证上层技术平台是否可以在这个过程中不受影响并保持一致，混沌工程的引入可以让问题提前暴露、提前解决，让企业更全面地理解这些系统性固有现象，从而在分布式系统中实现更好的工程设计，不断提高系统弹性。

此外，周洋特别强调，混沌工程并不是大公司的专属，除非企业完全不在乎系统运行情况。相比较而言，金融、游戏、电商、航空航天等业务发展较快且对可用性具备高要求的领域更加需要混沌工程。如果本身的研发团队或者业务团队规模较小，同样需要混沌工程提高效率和产出比。

阿里巴巴混沌工程实践

早在 2011 年，阿里电商就开始尝试通过故障注入技术去解决微服务的依赖问题，从注入实现、实验效率、业务影响等多个方面进行演进；2012 年，阿里推出同城容灾，进行断网演练；2015 年，异地多活上线；2016 年，MonkeyKing 被用于故障演练；2019 年，阿里开源混沌工程工具ChaosBlade（混沌之刃）。

周洋介绍，阿里之所以下定决定做这件事情，源自大促备战的反思，虽然内部有完善的体系和流程，但真实情况下的系统稳定性是未知的。因此，阿里决定手段与技术并行，通过混沌工程解决技术和组织层面的问题。

实践早期，团队希望通过混沌工程解决微服务依赖治理的问题，因为当时的微服务拆分还没有特别彻底。举例来说，一个核心服务与某个非核心服务之间可能存在强依赖关系，非核心服务出现问题时，可能拖垮核心服务，这肯定是不合理的，也是业务无法接受的。因此，团队通过引入混沌工程进行强依赖治理，优化整个流程。

一些基础技术团队也尝试通过混沌工程解决容器相关的问题。周洋介绍，作为云服务，容器平台本身属于 PaaS 层，通过实施混沌工程可以保证系统本身没有问题；其次，传统企业上云时，面临着应用向容器转换的过程，设计模式等都需要进行改变，如果对业务稳态具有要求，混沌工程的引入可以解决这一阶段出现的问题。

目前，集团安全生产团队开始牵头运作"突袭演练"这种跨公司的稳定性战役。在一个可控的环境下，通过有计划的打擂和无计划的突袭，让安全生产蓝军和业务红军进行对抗，通过实战演练的方式验收稳定性措施的全面性和有效性。

回顾整个发展过程，周洋认为，比较难的事情，一是让团队意识到可以通过混沌工程技术趋同整个稳定性链条，更自动化、智能化得提升平台稳定性。因为，平台能力越差，支持各个团队的人力成本就越高，平台能力越高，防御相应就越差；二是，让更多人接受并实施该理念，无论是内部还是云上的客户，都可以了解平台的问题，阿里团队也希望将内部稳定性的经验通过平台化的方式对外输出，ChaosBlade 便由此开源。

ChaosBlade 经历了 6 年改进和实践，累计在线上执行演练场景达数万次，是一款遵循混沌实验模型，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，其特点是操作简洁、无侵入、扩展性强。基于 Apache License v2.0 开源协议，目前有 chaosblade 和 chaosblade-exe-jvm 两个仓库，后续还会添加 C++、Node.js 等其他语言的混沌实验执行器。

目前，混沌工程领域已经出现不少优秀的开源工具，比如 kube-monkey、ChaosIQ 等，但很多开源工具的功能存在高度重叠，或者难以满足实际诉求。阿里希望可以同用一套工具体系，解决所有故障场景问题，未来通过开源社区的力量完善实验场景，共同推进混沌工程领域的发展。

周洋强调，AHAS（阿里云应用高可用服务）是面向业务稳定性的云服务，这对企业而言非常重要。企业上云，并不仅仅是为了享受稳定的基础设施，也需要保证业务稳定性，而目前很少有厂商注意到这一点，AHAS 的出现不是为了拉动营收，而是帮助云上用户更好得搭建云原生系统。

目前，ChaosBlade 已经可用并处于快速演进阶段，团队大概每周都会发版，按照微服务、容器和云原生的路线迭代。近期，该项目会增强 JVM 演练场景；支持更多 Java 主流产品，比如 Redis，gRPC；增强 Kubernetes 演练场景以及对 C++、Node.js 等应用的支持。周洋透露，目前团队也希望更多志同道合的朋友加入，感兴趣的朋友可以通过 Github 平台了解该项目。