这是一篇较为详细的混沌工程调研报告，包含了背景，现状，业界部分实践，希望帮助大家更好的了解到混沌工程技术，通过混沌工程实验，更好的为系统保驾护航。

一、概述

1.1 研究背景

     Netflix公司最早系统化地提出了混沌工程的概念。2008年8月，Netflix公司由于数据库发生故障，导致了三天时间的停机，使得DVD在线租赁业务中断，造成了巨大的经济损失。于是Netflix公司开始尝试利用混沌工程优化稳定性保障体系。2010年，Netflix公司开发了混沌工程程序Chaos Monkey，于2012年在Simain Army项目中开源，该程序的主要功能是随机终止在生产环境中运行的虚拟机实例和容器，模拟系统基础设施遭到破坏的场景，从而检验系统服务的健壮性。2019年，阿里巴巴开源了ChaosBlade混沌工程程序，该程序可以结合阿里云进行混沌工程实验。2020年，PingCap 作为国内优秀的数据库领域开源公司，开源了其公司内部的混沌工程实践平台ChaosMesh。

     基于以上开源项目，混沌工程项目在国内受到了多家公司的关注，越来越多的公司开始引入混沌工程进行系统稳定性保障工作，通过混沌工程主动注入故障的方式，避免软件系统带来的未知危机。图1.1展示了软件系统稳定性危机与对策发展时间线的对应关系，可以发现，随着软件系统规模的扩大，系统复杂度的增长及开发周期缩短，陆续爆发了多次软件危机，同时，每次的软件危机都促进了软件系统稳定性保障措施的不断完善。而当下的软件系统的规模，复杂度和开发敏捷程度再次迈入了一个新的阶段，导致系统的稳定性面临着新的挑战。此时，主动发现系统稳定性缺陷的混沌工程应运而生，再次弥补了当下系统稳定性保障方式的短板。

图1.1 软件系统稳定性危机和对策发展时间线图 [来源：中国信息通信研究院]

1.2 研究目的

     塔勒布曾经在《反脆弱》一书中阐述了“系统如何在不确定性中获益”的思想，混沌工程基于这一伟大思想，提倡使用一系列实验来真实地验证系统在各类故障场景下的表现，通过频繁地进行大量实验，使得系统本身的反脆弱性持续增强。每一次故障中的获益，让系统不断进化，形成正向循环，逐步提高系统的质量，保证系统的健壮性。因此，混沌工程研究的首要目的就是主动发现系统的稳定性缺陷。表1-1列举了近几年比较严重的几个系统稳定性故障事件，从侧面反映了系统稳定性保障的重要性。

表1-1 系统稳定性故障事件

     当混沌工程成为常态化的系统稳定性的保障手段后，系统的整体稳定性将得到进一步提升。通过混沌工程平台，主动向系统注入故障，验证和评估系统抵抗故障并保持正常运行的能力，提前识别未知的缺陷并进行修复，保障系统更好得抵御生产环境中的失控条件，有效提升系统的整体稳定性。

1.3 研究意义

     混沌工程的主要研究意义在于提高系统的稳定性，通过主动向系统中注入故障的方式，研究和提高系统的健壮性，在一定程度上弥补了系统发生故障时被动响应的短板，降低了系统应对故障的风险和成本。表1-2列举了使用混沌工程前后的系统稳定性保障方式的对比，可以发现，使用混沌工程后，系统稳定性的保障方式更加出色。

表1-2 使用混沌工程前后的系统稳定性保障方式对比

     另外，实践混沌工程对不同职位的工作人员也有着各自的意义。如表1-3所示，混沌工程有助于帮助系统相关人员发现潜在的脆弱点，降低系统稳定性缺陷可能造成的损失。同时，通过混沌工程注入故障，可以有效锻炼团队发现和定位问题并快速恢复系统的能力。

表1-3 实践混沌工程对不同职位的意义

1.4 研究方法

图1.2 混沌工程实践体系和软件开发一般流程联系图 [来源：中国信息通信研究院]

     根据调研的混沌工程实践经验，混沌工程的研发方法可以概括为图1.2中的混沌工程实践体系。其中，混沌工程实践配套是混沌工程成功实践的关键，因此要求实践团队做好混沌工程实践的战略规划，培养混沌工程实践相关人员，形成混沌工程文化，识别应对潜在的风险并对混沌工程实践做出有效的评估。在此基础上，混沌工程实验是混沌工程研究的核心工作，即混沌工程以实验为最小单元研究发现系统的稳定性缺陷，实验的一般流程是：实验设计、实验实施和结果分析。具体内容一般包括：实验需求和对象、实验可行性评估、观测指标设计、实验场景环境设计、实验工具平台框架选择、实验计划和沟通、实验执行及指标收集、环境清理与恢复、实验结果分析、问题追踪、自动化持续进行验证。当通过混沌工程发现了系统稳定性缺陷时，需要根据实际情况给出对应的解决方案，如果存在架构的缺陷，则需针对性得采用韧性设计对稳定性缺陷进行改进，其他如边界条件和极端情况未考虑或者编码错误的缺陷，若占比较高且反复出现，则需要评估是否需要在制度规范上对软件开发过程进行更好的管控。

     关于更加具体理的论和混沌工程的一般实验步骤，可以从该书《混沌工程：Netflix系统稳定性之道》中获取到，电子版书籍见本报告附录。该书对混沌工程进行了非常详细的阐述，图1.3为该书的目录结构。

图1.3 《混沌工程：Netflix系统稳定性之道》目录

二、研究现状

2.1 业界混沌工程工具

     目前业界使用的混沌工程工具的种类很多，表2-1汇总了本次调研中发现的业内保持维护更新的几个工具，不同工具侧重于不同种类的故障注入。

表2-1 混沌工程工具汇总

2.2 业界混沌工程实践平台  

     业内的混沌工程平台一般由：用户界面、任务调度模块、故障注入、监控告警系统四个部分组成。

     用户界面：为实验平台提供混沌工程实验任务的编排和配置服务，使得用户方便管理各类混沌工程实验任务。当混沌工程实验开始后，用户可以通过任务进度条、服务器指标等展示图实时的查看实验进度和系统指标情况。当混沌工程实验结束后，用户可以看到最后的混沌工程实验报告。

     任务调度模块：该模块负责用户界面和故障注入之间的交互，核心功能是实现混沌工程任务的批量下发和调度。

     故障注入：故障注入负责接收任务调度模块下发的故障注入任务，实现相应的故障注入事件，并反馈故障注入任务的执行状态。

     监控告警系统：该系统负责记录和管理系统产生的所有数据，生成告警和相关统计并反馈给用户。

2.3 混沌工程实践能力评估

     混沌工程实践能力的评估可以帮助团队更好地了解混沌工程实践的状况，表2-2列举了混沌工程实验成熟度的等级，该等级可以用来评估当前系统进行混沌工程实践的能力，主要反映执行混沌工程实践的可行性、有效性和安全性，等级越高则说明可实践混沌工程的能力越强。

表2-2 混沌工程实验成熟度等级

三、混沌工程实验调研

     本次主要调研了京东内部混沌工程的实验以及业界部分公司的混沌工程实践情况，调研内容如下：

3.1 京东泰山混沌工程平台

     泰山混沌工程平台是基于业界成熟解决方案ChaosBlade并结合京东业务特色设计并落地实现的一款自助式故障演练平台。用户可根据自身服务特点有针对性的场景编排、故障注入，对服务容灾能力进行评估，通过实验探究的方式建立对系统行为重新的认知理解。推动建立混沌文化，通过主动探索的方式发现系统中潜在的、可以导致灾难的、让我们的客户受损的脆弱环节，消灭它们，让我们的系统更加健壮有韧性。

     图3.1展示了泰山混沌工程演练的流程图，基于泰山混沌平台，红方的任务是：

     （1）创建演练计划：通过访问泰山平台，进入路径：安全生产-混沌工程页面，页面提供“创建演练计划”按钮，点击即可进入演练配置页面。

     （2）演练配置：点击创建演练计划按钮后，进入演练配置页面，可录入演练基本信息及任务配置项（演练配置-应用相关（类型、方式、场景）、演练配置-执行相关），图3.1中红色字体为本次演练重点配置项。

     （3）执行演练：演练任务创建保存后，生成一条待执行的演练任务，手工点击执行按钮执行演练。

     蓝方的任务是：

     （1）故障排查：在演练执行中，蓝方通过报警信息，先下掉报警机器，进行排查。

     （2）恢复方案：演练中发现问题要及时恢复，演练后要重启恢复演练机器，确保机器正常运行

     实验完成后需要进行演练复盘，即对演练中发现问题总结及分析，确保不再出现类似风险问题。

图3.1 泰山混沌工程演练流程图【来源：全渠道混沌工程实践文章】

3.1.1 核心能力

     平台的核心能力可以用四化一灵活概括，即：

     一、自动化：演练过程全程自动调度、插件部署、故障注入、现场恢复。

     二、可视化：演练期间，可实时观测MDC指标变化、UMP业务监控指标变化以及故障注入进度等。

     三、精准化：可通过指定IP、分组、机房、网络POD，针对演练影响范围进行明确限制，演练效果更贴合实际场景。

     四、规模化：平台设计目标支持单任务1000+演练目标、多演练任务同时调度的能力，为集团范围内各种预案演练、攻防演练、常态化混沌测试提供强有力的支持。

     五、灵活控制：在演练过程中可灵活进行取消、终止、全部终止等操作；针对故障场景可多维度进行配置提调整；演练时长、调度方式执行时可调整。

3.1.2 支持故障注入类型

     泰山混沌工程实验平台支持丰富的混沌场景能力，表3-1列举了平台支持的基础资源类故障场景，主要验证基础资源或者业务监控告警的及时性、有效性（干预手段），从而优化资源规格、部署规模和跨机房部署，同时希望增加进程存活、URL存活的监控。表3-2列举了平台支持的JAVA进程故障和中间件依赖故障场景，主要验证业务、JVM监控告警的及时性、有效性（干预手段），从而调整JVM参数、使用合理垃圾回收器等，同时调整中间件集群配置、治理降级方案、优化缓存策略等，通过演练也可以进一步理解系统架构，梳理强弱依赖、治理服务性能和评估下游服务能力。

表3-1 基础资源类故障场景

表3-2 JAVA进程故障和中间件依赖故障场景

      表3-3汇总了泰山混沌实验平台的故障使用统计表，从使用情况上可以看出，目前基础资源类故障场景使用居多。图3.2更加直观的展示出泰山混沌工程实践平台的故障使用类型为基础资源类故障。

表3-3 泰山混沌工程实验平台故障类型使用统计表

3.1.3 常见问题

     通过调研泰山混沌工程的实践，可以汇总一些常见问题如下：

     （1）报警未配置（MDC、UMP、存活）；

     （2）报警阈值不合理、间隔时长不合理、联系人缺失、联系人授权不足；

     （3）进程假死未报警，需配置URL存活报警；

     （4）暂停了告警，未及时开启；

     （5）值班人员对预案处理不熟练，内部系统工具使用不熟练（加强内部培训）；

     （6）群组内反馈问题后，未有相关同事进行处理，职责分工不明确；

     （7）内部工具设计不合理，无法应对不同场景（比如：多机房分组出异常）；

     （8）忽视偶发问题，后期范围扩大不易处理（比如：低版本Linux内核处理）。

3.2 阿里巴巴混沌工程调研

     关于阿里巴巴混沌工程的调研，主要是围绕该公司的开源项目ChaosBlade展开，调研内容汇总如下：

3.2.1 ChaosBlade简介

     ChaosBlade是阿里巴巴2019年开源的混沌工程项目，包含混沌工程实验工具chaosblade 和混沌工程平台chaosblade-box，旨在通过混沌工程帮助企业解决云原生过程中高可用问题。实验工具chaosblade支持3大系统平台，4种编程语言应用，共涉及200多的实验场景，3000多个实验参数，可以精细化的控制实验范围。混沌工程平台chaosblade-box 支持实验工具托管，除已托管 chaosblade 外，还支持 Litmuschaos 实验工具。已登记使用企业40多家，其中已在工商银行、中国移动、小米、京东等企业中落地使用。

     特性：

     （1）丰富的实验场景：包含基础资源（CPU、内存、网络、磁盘、进程、内核、文件等）、多语言应用服务（Java、C++、NodeJS、Golang 等）、Kubernetes 平台（覆盖 Container、Pod、Node 资源场景，包含上述实验场景）。

    （2）多样化的执行方式：除了使用平台白屏化操作，还可以通过工具自带的 blade 工具或者 kubectl、编码的方式执行。

    （3）便捷的场景扩展能力：所有的实验场景遵循混沌实验模型实现，并且不同层次场景对应不同的执行器，实现简单，易于扩展。

    （4）实验工具自动化部署：无需手动部署实验工具，实现实验工具在主机或集群上自动化部署。

    （5）支持开源实验工具托管：平台可托管业界主流的实验工具，如自身的 chaosblade 和外部的 litmuschaos 等。

    （6）统一混沌实验用户界面：用户无需关心不同工具的使用方式，在统一用户界面进行混沌实验。

    （7）多维度实验方式：支持从主机到 Kubernetes 资源，再到应用维度进行实验编排。

    （8）集成云原生生态：采用 Helm 部署管理，集成 Prometheus 监控，支持云原生实验工具托管等。

     更加具体的内容见：https://chaosblade.io/docs/

3.2.2 ChaosBlade项目梳理

     ChaosBlade将场景按领域实现封装成一个个单独的项目，不仅可以使领域内场景标准化实现，而且非常方便场景水平和垂直扩展，通过遵循混沌实验模型，实现chaosblade cli统一调用。目前包含的项目如下：

     chaosblade：混沌实验管理工具，包含创建实验、销毁实验、查询实验、实验环境准备、实验环境撤销等命令，是混沌实验的执行工具，执行方式包含 CLI 和 HTTP 两种。提供完善的命令、实验场景、场景参数说明，操作简洁清晰。

     chaosblade-spec-go: 混沌实验模型 Golang 语言定义，便于使用 Golang 语言实现的场景都基于此规范便捷实现。

     chaosblade-exec-os: 基础资源实验场景实现。

     chaosblade-exec-docker: Docker 容器实验场景实现，通过调用 Docker API 标准化实现。

     chaosblade-operator: Kubernetes 平台实验场景实现，将混沌实验通过 Kubernetes 标准的 CRD 方式定义，很方便的使用 Kubernetes 资源操作的方式来创建、更新、删除实验场景，包括使用 kubectl、client-go 等方式执行，而且还可以使用上述的 chaosblade cli 工具执行。

     chaosblade-exec-jvm: Java 应用实验场景实现，使用 Java Agent 技术动态挂载，无需任何接入，零成本使用，而且支持卸载，完全回收 Agent 创建的各种资源。

     chaosblade-exec-cplus: C++ 应用实验场景实现，使用 GDB 技术实现方法、代码行级别的实验场景注入。

图3.3 ChaosBlade项目梳理图

     如图3.3所示，ChaosBlade项目开源的为图中绿色部分，待开源为黄色部分。

3.3 字节跳动混沌工程调研

     关于字节的混沌工程，主要调研总结了故障模型、故障中心的设计以及演练系统的设计，调研内容如下：

3.3.1 故障模型的定义

     以某个微服务作为观察目标进行故障定义，故障模型定义如图3.4所示：

图3.4 故障模型定义图

     其中，Target是目标微服务，即在开始混沌工程实验前，需要明确对什么服务注入故障，该服务为主要观察目标。Scope Filter为爆炸半径，为了降低实验风险，一般不会令服务的全流量受到影响，所以通常会过滤出某一部署单元，该单元可能是某个机房或者某个集群，甚至精确到实例级别或者流量级别。Dependency是目标服务的依赖，当依赖有异常时，可能是来自中间件或者某个下游服务，也可能是依赖的CPU，磁盘，网络等。Action是描述服务的外部依赖发生的故障，如下游服务返回拒绝，发生丢包或者延时，或者磁盘发生写异常，读繁忙，写满等异常情况。根据故障模型，进行故障声明的伪代码可以描述如下：

spec. //微服务application A 的 cluster1集群内10%的实例cpu突然满载
    tareget("application A").
    cluster_scope_filter("cluster1").
    percent_scope_filter("10%").
    dependency("cpu").
    action("cpu_burn").
    end_at("2020-04-19 13:36:23")

spec. //服务application B 的 cluster2集群所依赖的下游application C突然延时增加100ms
tareget("application B").
cluster_scope_filter("cluster2").
dependency("application C").
action("delay, 200ms").
end_at("2020-04-19 13:36:23"

     基于故障模型，字节设计了一套声明式接口，当注入某一故障时，只需要按模型添加故障声明即可生效，如果想终止故障，只需要删除该声明。

3.3.2 故障中心的设计

     字节混沌工程的故障中心的架构设计如图3.5所示：

图3.5 故障中心架构图

     故障中心由三个核心组件API Server，Scheduler，Controller，外加一个核心存储etcd组成。其中API Server负责包装etcd并对外提供声明式接口；Scheduler则负责将故障声明解析，并根据声明持续寻找Target对应的实例，以及Dependency对应的下游实例/中间件/物理设备，然后，Controller则将action故障解析为可执行指令，下发至对应实例的agent，或者调用对应中间件的API，达到精准的故障注入。

3.3.3 演练系统设计

 图3.6 演练系统设计图

     如图3.6所示，演练系统包括平台层和原子能力层。在原子能力层，添加自动化指标观察能力。通过引入机器学习，可以实现基于指标历史规律的无阈值异常检测。在平台层，添加自动化强弱依赖梳理，与红蓝对抗模块。其中，自动化指标观察有：

     （1）故障指标：确定故障是否注入成功 。

     指标定义：故障指标源于故障，因故障触发了指标波动。比如注入了故障：redis延时增加 30ms，那么该指标则为目标服务 -> redis之间的均值延时pct99延时等。该指标可帮助用户直观看到故障的产生与结束。

     如何处理：对于此类指标，仅做展示即可，可以保证用户清晰看到故障何时开始，何时结束。

     获得途径：来自故障，平台制造故障时，平台知道会受影响的直接指标是什么。

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

     指标定义：止损指标对于目标服务/目标业务至关重要，表示该次演练所能承受的最大限度，指标可能来自服务本身相关（比如对外错误率），亦可能来自关联较远的业务指标（比如每分钟点播量），甚至可能来自兜底服务的指标（比如兜底服务的最大承受指标）；也可能是以上提到的各类指标某种组合。

     如何处理：对于此类指标，需要非常精准地标识关键阈值，一旦波动到阈值时，表示到达了损失底线，任何操作必须马上停止，故障需要恢复。

     （3）观察指标：观察细节，观察故障导致了哪些关联异常。

      指标定义：观察指标，对于在实验的时候发现新的问题，有很大的辅助作用。观察指标应该是一切与服务和故障相关的指标。比如服务本身的SRE四项黄金指标（latency, traffic, errors, and saturation），比如故障可能影响的关联指标（redis延时故障，是否会导致redis其他指标的变化？redis qps，eids errors，降级服务的qps 变化），比如关联告警记录，关联日志。

     如何处理：此类指标，没有明确的阈值，但往往此类指标在事后分析的时候最容易发现各种潜在问题，字节在处理此类指标的时候引入了机器学习方法，与指标历史规律进行对比，可做到自动化异常检测。因此指标观察的核心是智能指标筛选和无阈值异常检测。另外配合一套基于经验的人工规则，可以实现面向不同的实践活动做各类自动化判断或者辅助决策。

3.4 快手混沌工程调研

     快手的混沌工程平台架构底层是基于开源项目ChaosBlade和ChaosMesh，然后结合自身业务开发的实验平台。如图3.7所示。

图3.7 快手混沌工程平台架构图      

     快手的混沌工程实验分为了三个阶段，分别是：首轮注入演练、业务场景演练、常态化演练，这三个阶段演练的目标侧重点不同。

     首轮注入演练：验证业务稳定性基线，对业务核心服务进行基础场景和关键场景注入，与业务侧各角色进行磨合。

     业务场景演练：梳理业务核心流程及稳定性目标，针对业务架构特点和业务特性设计演练方案，逐步完善故障演练场景和演练覆盖。

     常态化演练：建立防退化机制，沉淀业务演练场景，建立持续性的演练验证机制。如：每月进行例行演练，在pipeline中加入场景验证等。常态化演练内容完善，是一个逐渐丰富故障场景库的过程，包含了服务稳定性的设计预期、历史故障复盘、监控有效性覆盖检查和应急预案验证。如图3.8所示。

图3.8 首轮注入与常态化演练流程图

四、总结和思考

4.1 调研总结和思考

     本次调研涵盖了混沌工程的起源，发展，以及在京东和业界的落地情况。通过调研，我进一步体会到：（1）混沌工程最先进的，是它大胆超前的思维理念和安全受控的方法论。（2）故障注入只是手段，而不是混沌工程的全部。场景再多，也不代表韧性就够好。（3）如果只是根据稳态假说，写测试用例，然后再使用故障注入工具进行试验，最后结果验证，这只能算是混沌工程最基本的内容。（4）混沌工程的使命是探索问题，而不仅仅是验证问题。总体而言，混沌工程的核心就是增强系统信心，保证系统在某个场景下的能力不退化。

4.2 混沌工程未来发展

     混沌工程的目标是主动发现问题，因此，未来依然离不开这个核心目标，但是在未来，可以使得这个目标更加智能化的实现。通过调研发现，业界中部分企业已经开始探索将混沌工程和人工智能、机器学习等领域相结合，通过注入故障时系统指标的变化和定位的历史数据进行相关模型的训练，使得模型可以通过指标变化自动识别故障，这将有助于解决混沌工程在结果分析和故障恢复环节的自动化问题。其次，当下的混沌工程演练平台的交互性和可视化等能力在未来可以做到更好。此外，混沌工程的量化指标也需要进一步完善。

参考文献

1.ChaosMesh https://github.com/chaos-mesh/chaos-mesh

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

3.ChaosToolkit https://github.com/chaostoolkit/chaostoolkit

4.orchestrator https://github.com/openark/orchestrator

5.powerfulseal https://github.com/powerfulseal/powerfulseal

6.toxiproxy https://github.com/Shopify/toxiproxy

7.混沌工程深度实战专场 https://live.juejin.cn/4354/xdc2021-01

附录

1.混沌工程：Netflix系统稳定性之道​

2.快手混沌工程实践