混沌工程由 Netflix 率先提出并应用，其业务高度依赖分布式系统，为确保系统在面对各种故障时仍能稳定运行，其组织开发了混沌工程工具集 ——Chaos Monkey 等，通过随机地关闭生产环境中的服务器来验证系统弹性。

混沌工程是一种在分布式系统上进行实验的方法，目的是提升系统的弹性和稳定性。它通过主动向系统注入故障，观察系统在各种压力情况下的行为，以发现系统中的潜在问题并加以改进。

京东物流快递快运技术部，自2024年11月起，针对分拣拣揽派及C端、B端核心业务线，0-1落地研测联动红蓝攻防机制，完成共两轮，87个核心接口架构分析，覆盖31个核心应用（79个场景），识别拦截5类36处风险（监控、流程、代码、预案、依赖），持续巩固快快应急预案体系，在此基础上，25年持续推动演练线上化实践、成熟度评估体系建设、落地及能力升维。

a、实验范围圈定

通过对核心系统的架构分析，梳理系统链路的关键指标（系统规模、SLA及限流指数等）和关键依赖（应用、存储及其他中间件），明确要进行实验的系统或服务范围，标记故障注入点。

实验范围可以是一个或多个单体应用、某个业务场景下的应用链路、某个数据中心或整个分布式系统。

b、稳定性指标定义

定义明确的稳定性指标，用以衡量系统在实验过程中的状态，稳定性指标可以是技术监控指标、业务监控指标或用户体验指标等。

1）技术监控指标

技术监控指标，一般从技术视角监控系统稳定性，通常分为几个维度监控。

2）业务监控指标

业务监控指标，是整个监控体系的“顶层”，能够直接反映用户使用业务的真实情况。在快递快运分拣业务域，体现如下（例如，发货环节，设置【发货环节成功率】作为监控指标，通过配置规则：当前时间的发货成功数据与上周同比下降超过30%，如果5分钟内连续出现3次告警，则触发严重级别的告警）。

c、实验场景构建

根据系统的架构及技术特点，以及可能出现的故障情况，参考设计各种实验场景。实验场景应该尽可能地模拟真实世界中可能发生的各种故障和异常情况（可参考 历史存量线上故障）。

1）一般场景构建

①CPU使用率（单个故障场景样例及核心参数解释）

• 演练目的：CPU混沌实验用于在主机模拟CPU负载情况，通过抢占CPU资源，模拟CPU在特定负载情况下，验证其对服务质量、监控告警、流量调度、弹性伸缩等应用能力的影响。

• 核心参数解释：

• 使用率：根据研发配置的MDC告警阈值决定（例：研发配置60%。80%-90%）

• 抢占模式：故意运行占用大量 CPU 资源的进程，使得系统的 CPU 使用率飙升，从而观察其他服务和进程在资源竞争下的表现。（勾选代表打开该模式）

• 满载核数：核心满载个数（如果一个系统在正常运行时很少有核心达到满载，但在混沌工程测试中有多个核心持续满载，那么可能表明系统在极端情况下的资源分配存在问题，或者系统并没有正确地平衡负载。）

• 满载核索引：每个 CPU 核心在操作系统中都有一个唯一的索引号，这些索引号通常从 0 开始计数。（例：0,1 / 0-2） 参数优先级：使用率 > 满载核数 > 满载核索引 建议：第一次演练优先使用【使用率】

2）复杂场景构建

①单应用单故障场景“多参数”组合构建

场景构建说明

（场景样例）连接库请求延迟&业务的异常流量注入

• 场景描述：依据场景构建的基本原则，我们在构建数据库请求延迟的情况前提下，向系统注入带有异常业务数据的流量，以检查应急预案对应的处理能力。

②单应用多故障场景组合构建

• 场景构建说明：可参考如下组合方式，构建单应用多故障场景。

（场景样例）核心依赖中间件MySQL请求延迟&CPU使用率增加场景

• 场景描述：该场景主要在单应用模式下，在数据库和CPU维度，参考故障的一般发生顺序，进行组合注入，并同步观察系统恢复能力。

• 实际执行层面，在植入CPU使用率和数据库延迟故障时，预期触发CPU和接口可用利率告警，但实际情况中，CPU告警按预期触发，但接口可用率报警并未触发。

③多应用多故障场景组合构建

场景构建说明：多应用多故障场景的构建，可基于单应用单故障的场景进行组合，可参考如下组合方式。目前针对该类型场景还未进行覆盖，后续基于上下游系统的架构分析和调用关系，进行组合。如应用A调用应用B，在给应用A植入故障的同时，B应用也进行故障植入。

3）计划外场景构建

故障演练计划外场景通常是指在没有预先计划或通知的情况下，模拟系统或服务出现故障的情境，以测试和提高系统的可靠性和团队的应急响应能力。其主要特点包括：突发性、真实感、压力测试、团队协作。以下是在研发毫无防备的情况，进行的一次突袭式的故障演练例子：

混沌工程与传统的故障引入测试，在注入场景和工具使用方面存在重叠。故障注入测试，是混沌工程实验的一种验证策略。 其本质区别，是思维方式的差异 ，故障注入测试是通过已知故障和应急预案，确认系统对已知风险的承载能力。而混沌工程，是通过构造诸如应急预案范围外的故障场景，确认系统对未知风险的承载能力。

（场景样例）JAVA进程线程池满（未在演练剧本内的故障，观察系统应急能力）

通常在剧本评审阶段，测试团队会与架构团队完成全量场景评估，同时会提取部分场景，在约定演练时间计划外执行，研发团队对此类故障的执行计划不知情，以此强化验证其应急处理能力。

例如：在某计划外场景演练过程中，发现2个问题，①当植入JAVA进程线程池满的故障时，预期触发CPU告警，研发团队并未第一时间同步报备。②在故障停止时，预期所有机器及事务恢复正常，并由研发接口人报备同步恢复信息，但研发团队并未第一时间同步报备。

由此可见，计划外的场景，在识别系统应急能力之外，可更多反映研发团队，在故障处理过程中的组织协同能力。

4）流量冲击融合场景构建

• 系统在故障发生时，例如，C端用户在响应卡滞情况下，如系统未给予明确的故障提示、降级方案或恢复预期，往往会通过重复操作，确认系统恢复进展，请求量存在倍增可能。

• 后端平台类系统对接，请求方往往会通过自动重试，尝试重建成功请求，同时在长链路业务场景下，如链路各应用重试策略未统一，请求量存在倍增可能。以上，在故障恢复过程中，已部分恢复的服务，大概率会被倍增流量快速击溃，造成系统可用性雪崩。有必要通过融合流量冲击场景的混沌实验，确认系统的极端风险承载能力。

（场景样例）应用CPU满载混合单机流量激增

• 场景描述：在CPU满载的情况下，模拟接口流量激增。首先植入CPU满载，再调节注入流量，观察整个处理过程。

d、实验剧本构建

1）剧本设计详解

故障注入过程，尤其是在生产或准生产环境实验，未经评估的故障场景，极易造成线上生产异动，对实验方案的严谨性以及人员的专业性，提出了更高的要求。实验剧本构建主要包括以下几个要素。

e、工具选型

1）工具选型原则

①功能特性

• 复杂场景构建：对于复杂的分布式系统，尤其是包含多种技术栈（如同时有微服务、数据库、消息队列等）的系统，需要选择能够模拟多种故障类型的工具，以更全面地测试系统的弹性。

• 实验场景定制化：混沌工程工具应该允许用户根据自己的系统特点和需求定制实验场景，提供丰富的实验模板，并可通过修改这些模板或编写自己的实验脚本来定制实验。这种灵活性使得用户能够模拟特定的业务场景下可能出现的故障，如模拟电商系统在购物高峰期时数据库查询缓慢的情况。

• 系统集成能力：实验工具需要能够与企业现有的系统和工具集成，如监控系统、日志系统等。通过插件或者 API 的方式实现与其他系统的集成，增强工具的实用性。

②环境适配

• 容器化基础设施兼容性：随着容器技术和 Kubernetes 的广泛应用，混沌工程工具需要加强对以上基础环境的支持，更充分地兼容 Kubernetes（Pod、Deployment、Service 等），并进行有效的故障注入。

• 云平台兼容性：对于部署在云平台（如 京东云、阿里云、腾讯云、华为云、百度云、GCP、IBM Cloud、Oracle Cloud、AWS、Azure、Ali 等）上的系统，需要考虑工具是否与这些云平台兼容，是否能够提供针对特定云平台的故障模拟功能，。例如，AWS S3 存储桶故障、Azure 虚拟机故障等特定故障情况，以适应云环境下的实验需求。

• 跨平台支持：对于同时在多种操作系统（如 Linux、Windows、Android、IOS、MacOS 等）和硬件架构（如 x86、ARM）上运行的系统，确保所选工具能够在所有相关平台上正常工作，避免出现因平台差异导致实验无法进行的情况。

③易用性和学习成本

• 用户界面友好程度

• 直观、易于操作的用户界面可以降低用户的学习成本和操作难度。例如，Gremlin 有一个相对直观的 Web 界面，用户可以通过简单的操作（如选择故障类型、目标系统等）来设置和启动实验。对于非技术人员或者刚接触混沌工程的团队成员来说，这样的界面更容易上手。

• 文档和社区支持

• 完善的文档和活跃的社区可以帮助用户更快地学习和使用工具。工具的官方文档应该包括详细的安装指南、实验设置说明、故障模拟类型介绍等内容。同时，一个活跃的社区可以让用户分享经验、解决问题，例如在开源的混沌工程工具社区中，用户可以找到其他使用者分享的自定义实验场景案例，帮助自己更好地开展实验。

④安全性和可靠性

• 实验风险控制

• 混沌工程工具在进行故障注入时可能会对生产系统造成一定的风险，因此需要选择能够有效控制实验风险的工具。一些工具提供了诸如 “安全模式” 或 “沙箱模式” 的功能，在这些模式下，故障注入的强度和范围可以得到限制，并且可以提前设置好终止实验的条件，以确保在系统出现异常时能够及时停止实验，避免对生产系统造成严重破坏。

• 工具自身的可靠性

• 工具本身应该是可靠的，不会因为自身的故障而导致实验结果不准确或者对系统造成额外的干扰。可以查看工具的版本更新记录、用户评价等信息来了解工具的可靠性情况。例如，经过多个企业长时间使用且更新频繁的工具，通常在可靠性方面有更好的保障。

2）业界混沌工程解决方案

在混沌工程实践里，通过模拟各类故障场景，像是模拟服务器崩溃、制造网络延迟，或是触发数据丢失状况等方式，能够极为精准地挖掘出系统中潜藏的薄弱环节。目前，市面上既有开源性质的解决方案，也不乏商业化的专业工具。接下来，我们将着重对京东（JD）的混沌解决方案，以及其他具有代表性的开源方案展开详细介绍。

①JD泰山混沌工程平台（快快技术-首选解决方案平台）

• 简介：是一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助用户检验系统高可用、提升分布式系统的容错能力，平台使用简单、调度安全。是基于 ChaosBlade 底座进行打造，并增加了JIMDB、JSF、JED等中间件类故障场景，让大家可以精细地控制演练影响范围（爆炸半径）。

• 特点：支持多种类型的故障，如基础资源故障：CPU、 内存、网络、磁盘、进程；Java进程故障：进程内CPU满载、内存溢出、类方法延迟/抛异常/篡改返回值、MYSQL请求故障、JIMDB请求故障、JSF请求故障；JED集群故障：集群分片主从切换、集群分片节点重启

• 适用场景：适用于复杂分布式系统和微服务架构中的故障模拟，另外针对JD特有的服务可支持故障植入。

②业界工具平台及能力对标

f、执行实验

1）系统架构分析

①架构分析的必要性

系统级架构分析，是所有稳定性保障工作开展的首要条件。通过对系统机构的充分理解和分析，才能准确识别故障演练的切入点（可能的弱点），以下，是系统架构分析的必要环节和目的。

②识别关键组件和依赖关系

系统架构分析帮助识别系统中关键的组件和服务，以及它们之间的依赖关系。这有助于确定哪些部分对系统的整体功能至关重要，并需要优先进行故障演练。

③理解数据流和通信路径

分析架构可以揭示数据在系统内的流动路径和通信模式。这有助于设计针对网络延迟、带宽限制或通信中断的故障演练。

④识别单点故障

系统架构分析可以帮助识别系统中的单点故障，这些是可能导致整个系统崩溃的薄弱环节。通过故障演练，可以测试这些点的冗余性和故障恢复能力。

⑤优化故障演练设计

了解系统架构可以帮助设计更加真实和有针对性的故障场景，从而提高故障演练的有效性和相关性。

⑥评估故障影响范围

系统架构分析可以帮助预测故障可能影响的范围和程度，从而为故障演练设定合理的范围和目标。

⑦加强团队的协作与沟通

通过架构分析，团队成员可以更好地理解系统的整体设计和各自的角色。这有助于在故障演练中提高团队的响应能力和协作效率。

⑧支持持续改进：

架构分析提供了一个基准，用于在故障演练后评估系统的改进效果。通过反复的分析和演练，可以不断优化系统架构，提高系统的弹性。

总之，系统架构分析是故障演练的基础，它确保演练的设计和实施是有针对性的，并能有效地提高系统的可靠性和稳定性。

2）架构分析案例

①架构分析要求

• 梳理系统全局架构图，标注演练（压测同理）入口。

• 梳理演练（压测同理）接口调用架构图，标识调用链路强弱依赖、调用层级关系以及演练（压测同理）切入点。

• 沉淀调用链路信息文档。

（图例）系统总架构图

（图例）单接口调用架构图

3）实验方案

在生产环境或测试环境中执行实验，观察系统在各种故障情况下的行为。在执行实验过程中，应严格遵照剧本要求明确分工及实验步骤，密切关注系统的稳定状态指标，确保实验不会对用户造成不良影响。

①方案样例

实验方案实施过程中，应严格按照分工和剧本执行，第一时间留存关键证据，记录关键步骤结论。

g、结果分析

• 对实验结果进行分析，找出系统中的潜在问题和薄弱环节。分析实验结果可以使用数据分析工具、监控工具或日志分析工具等。针对实验结果总结经验并后续做针对性改进。

• 样例：如针对某一个应用，演练完成之后，会从以下维度评估，并总结经验。

• 应用：workbench-xxxxx-backend-xxxxx

• 故障场景：强依赖JSF超时不可用+弱依赖JSF超时不可用

• 故障时间：2025-01-02 21:14:38 ~ 2025-01-02 21:35:00

• 问题现象

• 下游强依赖接口（计费系统）持续响应3S，TP99飚高，可用率未下降，仍100%

• 从植入故障到引起监控报警，间隔13min，该接口性能告警配置建议调整时间（现状：5次/分钟超过配置的阈值则报警，并在10分钟内不重复报警）

• 问题原因

• 针对强依赖接口，下游超时未上报可用率下降

• 告警时间配置10min，告警配置不敏感

• 改进措施

• 针对强依赖接口，下游超时上报可用率下降

• 更改UMP告警配置，更改为5min告警1次

h、问题修复及重复实验

• 根据实验结果，修复系统中的潜在问题和薄弱环节。之后重复进行实验，以验证修复效果并进一步提高系统的弹性和稳定性。

• 目前快快技术团队，在演练过程中，关键问题修复之后，会针对性进行二次验证。

i、成熟度评估

1）什么是混沌工程成熟度模型

混沌工程成熟度模型是一种框架，用于评估和指导组织在实施混沌工程实践中的发展阶段和成熟度。这个模型帮助组织理解它们在混沌工程实践中的位置，并为进一步改进提供路线图。

通常，混沌工程成熟度模型会分为几个阶段，每个阶段代表不同的能力和实践水平，通常包括初始阶段、基础阶段（初级）、标准化阶段（发展中）、优化阶段（成熟）、创新阶段（卓越）。

混沌工程成熟度模型的演变可以帮助组织系统化地实施混沌实验，并逐步提高其混沌工程实践的成熟度。通过系统化的成熟度评估，组织可以更有效地实施混沌工程实践，提升其整体系统的稳健性和响应能力。

混沌工程成熟度模型的演变反映了组织在复杂系统环境中不断追求更高弹性和可靠性的努力，结合业内对成熟度模型理解和京东实际情况，对成熟度框架进行剪裁（去掉接纳度维度和初始阶段），剪裁后的成熟度框架如下。

2）成熟度评估案例

基于成熟度模型的关键维度，我们对多个研发团队，进行了实际的落地评估工作，具体某个团队的评估过程，详见下表。

结合移动端特性与现有稳定性测试基础，以下为混沌工程在移动端的系统性实施框架，涵盖设计原则、核心要素、工具链及落地步骤。