混沌工程的意义在于突破现有对复杂系统的认知，产生新的认知。

一、介绍

1.1、发展

2008 年 Netflix 开始将服务从数据中心迁移到云上，之后开始尝试在生产环境中开展一些系统弹性的测试。过了一段时间，这个实践过程才被称为混沌工程。2010 年年底 Netflix 向全世界推出了“混乱猴子＂(ChaosMonkey)。

1.2、简介

主动、反脆弱、探索

混沌工程是一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学，通过实验探究的方式理解系统的行为。和被动式故障响应流程相比，混沌工程向前迈进了一大步。

1.3、混沌工程和故障测试的区别

混沌工程、故障注入、故障测试在侧重点和工具集的使用上有些重叠。混沌工程是发现新信息的实践过程，而故障注入则是基于一个特定的条件、变址的验证方法。和故障注入类似，故障测试是通过对预先设想到的可以破坏系统的点进行测试 。

故障测试和混沌工程都可以基于故障注入引入。但除故障场景外，混沌工程也可以探究非故障类场景，例如流量激增、资源竞争条件 、拜占庭故障（例如性能差或有异常的节点发出错误的响应、异常的行为、对调用者随机返回不同的响应等）、非计划中的或消息内容非正常组合的处理等，而故障测试并不能去探究上述这类更广阔领域里的、不可预知的、但很可能发生的事情。

综合来看，测试是断言的执行过程，其结果非真即假，而混沌工程的意义在于突破现有对复杂系统的认知，产生新的认知。

1.4、价值

提高系统弹性，管理复杂性，增强团队对系统的信心。

混沌工程通过设计和执行一系列实验，帮助我们发现系统中潜在的、可以导致灾难的或让我们的用户受损的脆弱环节，推动我们主动解决这些环节存在的问题。

利用实验提前探知系统风险，通过架构优化和运维模式的改进来解决系统风险，真正实现上述韧性架构，降低企业损失，提高故障免疫力。

1.5、混沌工程原则

1.5.1、建立稳定状态的假设

首先，借助一些系统指标、业务指标等来定义稳定状态。然后，基于所期望的指标来描述系统的稳定状态。最后，定义好指标并理解它们稳定状态的行为后，就可以使用它们来建立实验的假设了。

实验的假设一般是这样的形式：我们向系统注入的事件不会导致系统稳定状态发生明显的变化。要注意的是，定义偏离稳定状态的偏差是否在合理的范围内是具有挑战性的。

1.5.2、用多样的现实世界做验证

注入的事件应该是所有可能的真实世界的事件，而不仅仅是故障或延迟。

1.5.3、在生产环境中进行实验

经典测试的一般信条是，寻找软件缺陷要离生产环境越远越好。但是在混沌工程领域，整个策略却要反过来，在离生产环境越近的地方进行实验越好。传统的软件测试是验证代码写的对不对，而当进行混沌工程时，我们感兴趣的是整个系统作为一个整体的行为。

我们要在生产环境中建立对系统的信心，所以当然需要在生产环境中进行实验，否则会削弱实践的价值。只有生产环境中的输入数据才是最真实的。同时，对于系统依赖的外部系统，生产环境才是你的系统和第三方系统进行真实交互的唯一场所。

最后，即便不能在生产环境中进行实验，也要尽可能地在离生产环境最近的环境中进行。

1.5.4、自动化实验以持续进行

自动化是最长的杠杆。在混沌工程的实践中，我们要追求的目标是：自动执行实验，自动分析实验结果，并希望可以自动创建新的实验。

1.5.5、最小化爆炸半径

每一次的混沌工程实验的确具备导致生产环境崩溃的风险。所以，随时遏制和停止实验的能力是必备的，这可以避免造成更大的危机。建议实施自动终止实验，尤其是在定期自动执行实验的情况下。混沌工程实验应该只承受可以衡量的风险，并采用递进的方式，进行的每一步实验都在前一步的基础之上。

二、业内实践

2.1、开源 chaos 工具

纵观国内外互联网公司，都能够看到混沌工程的影子，混沌工程也经历了 10 多年的演进。以下是业内比较有代表性的混沌工程公司。

• Netflix 最早系统化地提出了混沌工程的概念，并出版了混沌工程领域内的首部书籍《混沌工程：Netflix 系统稳定性之道》，在本书中提出了混沌工程成熟度模型与应用度模型，并总结了五条高级原则，对于混沌工程的发展具有指导性意义。另外 Netflix 开源了其混沌工程项目 - Chaos Monkey。

• 阿里巴巴是国内较早开始探索混沌工程并做出开源的公司，其开源项目 **ChaosBlade **可以结合阿里云进行 chaos 实验。

• PingCap 作为国内优秀的数据库领域开源公司，其在混沌工程领域一直有投入，并在最近开源了内部混沌工程实践平台 - Chaos Mesh。

2.2 ChaosBlade 简介

ChaosBlade 支持目前主流的故障注入场景，相对其他几个故障注入工具，ChaosBlade 故障注入覆盖的场景最全，支持四大类、几十种常用的故障注入能力，且提供了统一的 CLI 交互界面，学习成本也相对较低。

2.3、一线互联网公司 chaos 实践

2.3.1、字节跳动

字节跳动各业务线内一直都能看到故障演练的踪迹，也有一些简单的工具，并演化出了故障演练平台，chaos 的核心能力-故障注入已经具备，通过该平台，实现了以下目标：

• 在自动化指标分析方面，补齐指标分析能力。

• 在故障注入方面，丰富故障的类型。

• 在实践活动方面，沉淀上一阶段总结的实践活动，并进一步探索实践形式，挖掘更大的价值产出。

2.3.2、工商银行

工商银行的混沌平台是基于 ChaosBlade 实现的， 平台主要由门户、任务调度框架、故障注入介质、高可用专家库四部分组成。

• 门户：提供各类混沌实验任务的编排和配置服务，借助演练流程编排面板，用户可以便捷地管理各类混沌实验任务

• 任务调度框架：负责门户和故障注入介质之间的交互，核心功能是实现混沌实验任务的批量下发和调度，该模块可以快速批量下发各种类型的混沌实验，支持失败重发、超时重发、高并发等机制。

• 故障注入介质：负责接收门户下发的任务，并实施相应的故障注入事件。

• 高可用专家库： 混沌工程测试人员根据平时混沌测试总结得到的高可用测试模型，基于高可用专家库用户可以根据演练场景自动关联对应的故障注入事件，并为用户提供一键生成演练流程的能力。

2.3.3、小米

以 chaosblade 为底层注入的核心模块，以故障注入的四个主流程为核心开展 chaos 平台的建设。 平台模块如下：

目前小米的故障植入平台的注入场景支持了系统层和网络层类型，主要包含了网络延迟、丢包、cpu 满载、内存满载、磁盘 IO 满载场景。这些场景都是热插拔式集成到平台，方便平台场景灵活调整和扩展。

三、落地

3.1、前提准备

3.1.1、团队转变

引入混沌工程前，需要先建立面向失败设计（可以使系统暴露出已有问题的设计）和拥抱失败的技术文化，混沌工程的核心是通过引入一些风险变量去暴露已有问题，而不是创造问题。

3.1.2、定义一个清晰可衡量的目标

在架构和团队膨胀到一定阶段，要想完全消除线上故障已经成为不可能的任务。当故障发生时，微服务架构能否准确进行出错重试、限流、熔断、流量控制；报警响应是否及时，提供的监控信息是否支持迅速排障；DevOps 研发平台是否能够允许应用迅速回滚，快速上线紧急修复等，都成为降低业务损失的重要一环。 因此，从故障驱动的角度出发，提前挖掘当前架构、链路、系统存在的隐患，验证基础设施的完备性，限制故障影响的范围，成为需要思考的方向。从前、中、后期三个角度，定义清晰可以衡量的目标。 前期：对历史故障的复现率以及解决率，确保故障改进的有效性； 中期：监控发现率，验证故障发现能力的全面性和监控的完备程度； 后期：故障的“发现-定位-恢复”这种综合性指标；

3.1.3、推广混沌工程

通过 ChaosBlade 工具，先从简单的场景开始尝试，逐渐增加大家对混沌工程的认识，以及对平台建设的信心（准备工作比落地执行更重要）。

3.2、chaos 平台建设构想

目标：提供多样化、可视化操作的故障注入自动化平台；作为各种演练和故障测试及验证的统一入口；帮助业务发现更多未知的影响业务稳定的问题；验证业务的告警有效性和完整性；验证业务的故障预案是否有效。

首先，基于对当前的技术架构以及团队结构的认知，在具体实施过程中需要满足以下条件：

• 方案的实施必须契合整体架构的长期演进方向，满足低成本、高收益、可复用三个要求。在技术方案的选择上，可以通过开源和自研相结合的方式，在降低成本的同时最大限度贴合自身的架构特点。

• 从当前的运维方式，需要支持虚拟机、docker、k8s 三种攻击模式。

• 从安全角度，线上故障注入为高危动作，需要有严格的权限控制流程。在实施前期，允许团队在线下及预发环境中验证故障注入方案的合理性。

其次，平台构建的思路可以以故障注入的四个主流程为核心来开展。

平台基础能力（0->1） 1、管理平台 权限管理、故障场景、故障模板、执行计划、任务调度管理。 基础设施、中间件资源、应用信息等已在 CMDB 中维护。

2、故障中心 提供底层故障注入能力（基于 chaosblade，开源和自研相结合）。初期提供应用类、基础设施类、中间件类等场景的故障注入能力。需考虑故障自动停止，故障自愈。

3、监控 结合公司已有监控平台，观测实验指标，记录实验结果，必要时自动停止实验。 相关指标如下：

• 故障指标 - 确定故障是否注入成功 。

• 止损指标 - 确保系统不会因故障无法承受而造成过大损失。

• 观察指标 - 观察细节，观察故障导致了哪些关联异常。