作者：京东物流 刘锐

1、何谓混沌工程？

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

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

2、混沌工程实验的核心原则

a、建立稳定性指标

建立系统稳定性指标，是观测混沌工程实验效果的关键手段。在混沌工程启动前，必须明确系统稳定性状态的定义，稳定性状态可以是系统的技术指标、业务指标或用户体验指标等。例如，系统 TP99 指标范围、可用率指标范围、页面响应时间范围、订单处理成功率范围等。

b、多样化故障注入

多样化的故障注入，是验证系统故障应急能力的前提。混沌工程应尽可能模拟真实世界中可能发生的各种故障或异常情况。包括不限于，硬件故障、软件故障、网络故障、人为错误等。例如，服务器宕机、网络延迟、数据库故障、配置错误等。

c、生产环境接纳度

生产环境对演练实验的接纳度，是确保故障演练实验精度和有效性的基础要素。混沌工程实验最好在生产环境中进行，因为生产环境是最真实的系统运行环境，能够反映出系统在实际使用中的各种情况。当然，在生产环境中进行实验务必谨慎操作，确保实验不会对生产运营及用户造成不良影响。

d、常态化运转

混沌工程实验的常态化运转，是确保系统健壮性得以持续巩固的基础。混沌工程实验应该持续自动化运行，以便及时发现系统中的潜在问题。自动化实验可以定期进行，也可以在系统发生变化时进行。通过持续自动化运行实验，可以不断提高系统的弹性和稳定性。

3、混沌工程实验的关键步骤及落地

快递快运技术部，自 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）剧本设计详解

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

2）剧本构建样例

故障演练方案-快递快运-分拣条线-2024年12月

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）什么是混沌工程成熟度模型

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

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

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

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

4、移动端混沌实验

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

a、核心原则

b、核心要素

1）故障场景库设计

2）实验优先级矩阵

c、工具链与自动化集成

1）分层工具矩阵

2）自动化流水线设计

d、落地实施步骤

1）设备覆盖计划

测试设备根据一线使用频率较高的系统版本和设备类型的 TOP3 来选择。

2）常态化落地机制（弱网与断网故障注入深度实践）

弱网与断网测试，是验证应用网络韧性的核心环节。通过 Charles 工具链与深度业务场景结合，系统性验证了移动端在极端网络条件下的行为，为后续自动化混沌工程流水线建设提供了实践范本。未来可进一步与 mpaas 监控、灰度发布联动，实现“故障注入-监控告警-自动修复”闭环。以小哥工作台 APP 为例，其测试实施过程如下：

5、AI 大模型与混沌工程的双向融合

a、AI 场景下的混沌实验

1）AI 大模型系统与传统系统的差异

随着 AI 大模型技术的快速发展，各行各业的传统系统都在逐步融合 AI 大模型能力，那么由此给混沌实验带来了新的挑战，与传统系统的混沌实验相比，融合了 AI 大模型能力的系统则会有一定的差异性，如下：

因此，在对 AI 大模型融合系统实施混沌实验时，在满足传统系统混沌实验关注点的同时，还需要更加关注模型服务可靠性（如推理延迟、数据异常影响），覆盖数据噪声、GPU 资源争用及模型输出漂移等复杂场景，指标监控上应额外追踪模型性能（如准确率）、数据分布偏移及 GPU 利用率。在进行结果分析时需量化模型鲁棒性、数据链路风险及业务间接损失（如用户信任）。

2）AI 大模型混沌工程实验

①实验目标

•验证大模型服务降级/熔断策略的有效性

•测试模型服务与业务系统的异常协同能力

•检测数据流-模型-业务链路的健壮性

•验证模型性能监控与自动恢复机制。

②实验原则

•最小化爆炸半径：从非核心业务开始，逐步扩大范围

•可观测性：确保所有操作可监控、可记录、可回滚

•稳态假设：明确定义系统正常运行的指标（如成功率、延迟、QPS 等）

•生产环境优先：优先在生产环境进行（需严格规划）

③实验标准

④场景设计原则

针对 AI 大模型工程系统的混沌实验设计，需结合核心业务场景和底层依赖（算力、数据、模型、网络），重点验证系统的容错性、自适应能力和用户体验鲁棒性。

b、快递快运小哥 AI 智能助手-混沌工程探索

1）系统简介

快递快运终端系统是服务于一线快递小哥及站点管理者的日常工作作业实操系统，是京东物流作业人员最多、物流揽派作业最末端以及作业形态多元化的系统。

AI 大模型具有超强自然语言处理、泛化能力、意图理解、类人推理以及多元化结果输出的独特能力，基于此，快递快运小哥 AI 智能助手通过结合 AI 大模型工程系统、大数据、GIS、语音 SDK 等分别在揽收、派送、站内、辅助、问答服务五大类作业环节上实现了如小哥揽收信息录入、打电话、发短信、查询运单信息、小哥揽派任务信息聚合查询、知识问答及揽派履约时效精准化提示等场景。提升小哥作业效率和揽派实操体验。

2）系统架构分析

快递快运小哥 AI 智能助手【产品架构图】快递快运小哥 AI 智能助手故障演练【系统架构图】

3）实验场景

针对 AI 大模型工程系统的混沌实验设计，需结合核心功能（智能提示、智能问答、智能操作）和底层依赖（算力、数据、模型、网络），重点验证系统的容错性、自适应能力和用户体验鲁棒性。

c、混沌工程的 AI 智能化演进展望

混沌实验的 AI 化演进是系统稳定性测试与人工智能技术深度融合的重要趋势。这一演进不仅体现在实验工具的智能化升级上，更体现在实验设计、执行与分析的全链路优化中。以下分别从技术融合、工具创新及场景扩展三个维度展开论述：

1）技术融合：AI 赋能混沌实验的核心环节

混沌实验包含了实验设计、实验执行及实验监控与根因分析三大核心环节，具体而言。

①实验设计智能化

传统混沌实验依赖于人工假设（如“当网络延迟增加时，系统可用性应保持在 99.99%以上”），而 AI 可通过历史故障数据与系统日志，自动识别潜在脆弱点并生成实验假设。

例如，基于强化学习的 AI 模型可模拟复杂故障场景的组合，优化实验参数（如故障注入的强度、范围），提升测试覆盖率。AI 可分析服务调用链，预测依赖服务失效后的级联影响，并自动设计针对性的网络分区实验。在验证电商大促场景下的订单支付链路韧性时，通过 AI 驱动的智能实验设计，系统可自动化发现潜在风险组合并生成针对性实验方案，具体而言

通过借助 AI 智能实验方案设计，获得以下收益。

以上，AI 不仅替代了人工设计中的重复劳动，更重要的是通过系统化挖掘隐性关联与动态博弈式测试，将混沌工程从“已知-已知”测试升级为“已知-未知”甚至“未知-未知”风险探索。

②执行与调控动态化

AI 的动态决策能力使得混沌实验从“预设故障”向“自适应故障注入”演进。例如，通过实时监控系统指标（如 CPU 负载、请求延迟），AI 可动态调整故障注入的强度或终止实验，避免超出系统容灾阈值。通过 AI 驱动的动态实验调控，可以使混沌工程实现更多的突破，例如：实现动态适应性，从“固定剧本”升级为“实时博弈”，更贴近真实故障场景；实现精准调控，避免因过度测试导致业务受损，平衡实验风险与价值；实现多目标优化，同时验证性能、稳定性、安全性的综合影响，例如：验证系统在流量激增时自动扩缩容的能力。

③智能监控与智能根因分析

传统监控工具（如 Prometheus）依赖人工设置告警阈值，而 AI 可通过异常检测算法（如 LSTM、自编码器）实时识别系统行为的偏离，并关联故障注入事件，快速定位根因。例如，南京大学利用 AI 分析古生物大数据揭示复杂系统的演化模式，类似方法可用于预测分布式系统中的故障传播路径。

智能监控与根因分析通过 AI 技术实现从“被动告警”到“主动预测-定位”的跨越，其核心是通过多维度数据融合与因果推理，快速定位复杂系统中的故障根源。其技术原理可以从以下几个方面深入展开：

AI 驱动的智能监控与根因分析通过动态异常检测-因果推理-传播预测的三层技术架构，将故障定位从“人工地毯式排查”升级为“秒级精准定位”。此能力不仅大幅缩短了故障恢复时间，更重要的是通过预测潜在连锁反应（如“缓存失效→数据库过载→服务雪崩”），推动系统架构从“容灾”向“抗灾”演进。未来，结合故障注入实验的闭环验证，AI 监控有望实现“自愈推荐”，即自动生成修复策略并验证其有效性，真正实现系统的智能韧性。

2）AI 驱动的混沌工程平台能力升级

①混沌工程工具 AI 能力建设焦点

以下针对目前的发展方向，混沌工程平台，可基于以下几个方面拓展能力升级。

②自动化工具链的升级

当前的各类工具主要依赖手动配置，通过 AI 的引入使得工具能够从以下几个维度升级

③应用层故障注入的精细化

应用级故障注入工具通过“坐标系统”，精确定位实验范围（如特定用户或服务版本），而 AI 可进一步扩展这一能力。例如，通过自然语言处理解析日志，自动生成针对特定 API 接口的异常返回规则

④场景扩展

•智能化场景推荐

包括不限于，基于系统架构特性、基于既往线上故障、基于系统核心指标异动的智能化场景推荐，具体而言：

•云原生与边缘计算

在动态的云原生环境中，AI 可预测容器编排（如 Kubernetes）的故障恢复效率，并验证自动扩缩容策略的有效性。

•跨学科复杂系统模拟

混沌实验的理念正被引入生物、气候等复杂系统研究。例如，南京大学团队利用 AI 模拟元古宙生命演化中的“雪球地球”事件对生物多样性的冲击这种“环境混沌实验”为评估极端条件下的系统韧性提供了新范式。

随着 AI 技术的不断发展和应用场景的落地实施，混沌实验正从“被动容灾”转向“主动韧性构建”，其核心是通过智能算法提升实验的精准度与系统自愈能力。未来，随着 AI 与量子计算、生物模拟等领域的交叉，混沌实验或将突破工程范畴，成为探索复杂系统普适规律的科学工具。

6、【积微成著】专业分享

•【积微成著】性能测试调优实战与探索（存储模型优化+调用链路分析）：http://xingyun.jd.com/shendeng/article/detail/24444?forumId=174&jdme_router=jdme://web/202206081297?url%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F24444

•【积微成著】规模化混沌工程体系建设及AI融合探索：http://xingyun.jd.com/shendeng/article/detail/44438?forumId=99&jdme_router=jdme://web/202206081297?url%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F44438

•【积微成著】“泰山变更管控”在物流技术的深入实践：http://xingyun.jd.com/shendeng/article/detail/45193?forumId=1414&jdme_router=jdme%3A%2F%2Fweb%2F202206081297%3Furl%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F45193