混沌工程先锋实践者 案例

混沌工程先锋实践

者优秀案例

（2022年）

目录

第一部分互联网领域.......................................1

1.阿里云：阿里云容器服务混沌实践........................1

2.蚂蚁集团：蚂蚁集团红蓝攻防实践........................9

3.腾讯云：混沌工程对于云计算服务应用案例...............19

4.京东科技：京东云全平台破坏演练.......................27

第二部分银行领域........................................38

5.工商银行：工商银行混沌工程平台及混沌演练实践.........38

6.农行研发中心：农行金库系统混沌演练实践...............47

7.建信金科：建信金科混沌实践之道.......................63

8.北京银行：顺天技术平台混沌工程实践...................78

9.平安银行：平安银行ASTA非功能测试平台...............91

10.中电金信：恒丰银行红蓝对抗演练.....................100

第三部分证券领域.......................................111

11.中信建投：故障演练平台项目..........................111

12.中泰证券：混沌工程在互联网金融业务的应用与实践.....119

第四部分通信领域.......................................132

13.中移信息：磐基PaaS平台混沌能力山东应急演练........132

第五部分零售领域.......................................139

14.永辉科技：永辉生活电商全链路故障演练实践...........139

第六部分能源领域.......................................144

15.南网数研院：云原生应用架构驱动的全栈高可靠探测......144

编后语..................................................150

附录1.............................................................................................................151

附录2.............................................................................................................152

附录3.............................................................................................................154

图目录

图1阿里云容器服务混沌实践实施流程.......................3

图2阿里云容器服务混沌实践实施框架.......................4

图3阿里云容器服务混沌演练模型............................5

图4蚂蚁集团-为世界带来微小而美好的改变..................10

图5蚂蚁混沌工程整体技术框架图...........................12

图6混沌工程整体技术框架图...............................21

图7京东云平台仿真环境....................................30

图8京东云全平台故障演练流程.............................30

图9云资源稳态示意图......................................31

图10业务稳态示意图：.....................................31

图11压测结果观测稳态变化................................32

图12演练场景执行和问题分析定位.........................33

图13云泰故障注入与演练平台技术框架.....................34

图14工商银行混沌工程平台框架示意图.....................40

图15工商银行混沌平台故障注入能力.......................41

图16工商银行混沌演练实施效果............................45

图17金库系统混沌演练部署架构............................49

图18金库系统混沌演练平台总体架构.......................50

图19金库系统混沌试验演练流程图.........................50

图20混沌工程故障演练平台功能架构图.....................68

图21故障演练平台技术架构图..............................69

图22故障演练平台实施流程图..............................70

图23混沌工具集原子能力图.................................71

图24顺天技术平台生态体系整体框架图.....................81

图25混沌工程整体技术框架图..............................82

图26两阶段测试实验流程管理情况..........................83

图27混沌工程案例应用范围示意图..........................85

图28平台演练解决思路（重点实施）.......................85

图29平台演练解决思路（安全可信测试）...................85

图30应用中间件演练解决思路..............................86

图31平台可观测性能力.....................................86

图32平台可观测性能力.....................................87

图33ASTA平台PaaS层技术方案...........................94

图34ASTA平台能力全景..................................94

图35实验流程管理模型.....................................95

图36典型案例图...........................................96

图37Starlink平台可视化展示能力...........................97

图38非功能指标观测指标评分体系.........................97

图39ASTA平台助力降本增效减少风险.....................99

图40恒丰银行团队........................................101

图41中电金信团队........................................102

图42混沌工程平台........................................104

图43全链路演练..........................................105

图44红蓝对抗演练.........................................107

图45自动生成实验报告....................................110

图46中信建投故障演练平台能力...........................115

图47平台故障演练活动.....................................116

图48仿真环境架构图......................................123

图49混沌工程平台技术架构图.............................124

图50混沌工程平台原子能力................................125

图51基于混沌工程与演练质保的故障演练..................126

图52混沌平台核心组件架构图..............................141

图53云原生系统高可用故障探测框架......................147

图54应用系统高可用总体架构.............................148

表目录

表1主要故障场景和预期结果.............................32

表2混沌工程分布式平台应用效果表.......................74

表3混沌工程实验演练步骤..............................127

第一部分互联网领域

1.阿里云：阿里云容器服务混沌实践

一、申报单位

阿里云计算有限公司。

二、案例简介

阿里云创立于2009年，是全球领先的云计算及人工智能科技公

司。阿里云为200多个国家和地区的企业、公共机构和开发者，提供

安全、可靠的云计算、大数据、人工智能等产品和服务。阿里云作为

全国首家云等保试点示范平台和首家通过国家等保四级备案测评的

云服务商，为中国超过一半的上市公司，80%的中国科技创新企业提

供云计算服务。2021年7月可信云大会，阿里云故障演练平台入选

可信云最佳技术实践，并首批通过可信云混沌工程平台能力要求最高

等级一一先进级认证。

阿里云容器服务混沌实践是一套应用于云原生架构的混沌工程

实践案例，内部实践沉淀了针对云原生架构丰富的200+核心场景及

其组合，通过无人值守演练和生产突袭有效发现了90多个高可用问

题，提升了响应应急能力，推进了各个产品的自动恢复能力、预案能

力演进，使得整体公有云产品高可用能力大大提升。同时一部分场景

转化成为了商业化产品AHASChaos,更好地服务云客户，为其提供混

沌工程解决方案。

三、用户简介

阿里云云原生容器服务产品族，作为阿里云产品，在传统云计算

基础上，具备更快更低成本的弹性，更好的软硬一体化灵活性，以标

准的Kubernetes界面丰富生态，已经成为了云计算发展最快的技术

方向。云原生帮助开发者大幅度降低资源成本和交付成本，从而更快

更好地赢得市场。同时，云原生也给传统运维、研发方式带来了彻底

的变革，这就使得传统的混沌工程手段需要跟随演进。

四、需求分析

阿里云容器服务支持业务分析：阿里云容器服务需要同时支持阿

里云公有云、专有云客户和阿里集团客户。云产品面临的业务场景、

周边设施越来越复杂。为了应对复杂的架构演进，面向失败设计和稳

定性显得尤为重要。阿里内部需要支撑30W级别的POD量级，挑战巨

大。

阿里云容器服务依赖分析：相比其他行业或者系统，阿里云容器

服务面对的客户更为复杂，体量更大，作为整个阿里集团底座，承载

了几乎全部的在线业务及离线运行资源；对于容器来说，所有的这些

运行资源都是无差别的，但一旦出现故障，故障打击也是无差别的；

为了k8s在阿里集团内的落地，需要对内部的网络、存储、OS进行适

配，同时这也会依赖内部的运维体系和基础设施，导致拓扑结构变得

非常复杂。

社区追寻：近两年的云原生技术风起云涌，内部为了紧跟社区架

构更替速度，每年会有两次的版本迭代，紧跟社区版本迭代，同时这

也会引入新的风险。

故障演练：作为稳定性问题充分暴露的练兵场，可以在更接近实

际故障场景的环境中，暴露系统在生产环境中可能出现的问题，而混

沌工程的引入，使得演练测试更接近真实的故障场景，在不断混沌化

实验的过程中发掘可能出现的一些系统问题。

五、技术方案介绍

（一）整体实施流程及框架

整体实施流程一般分为这几个阶段：手工演练，流程工具自动化

演练，常态化无人值守演练，生产突袭演练。

这几个阶段的实施难度是从低到高，当然相应的收益也是从低到

高。一个组织（云用户）可以随着自己业务应用服务体量的增大、复

杂化和高可用能力的增高的历程，根据实际情况需要来选择自己合适

的阶段，然后随之进行升级和发展。即使从最简便的手工演练开始做

起实施，经常也能带来相当明显且长远的高可用能力系统性提升。

:.........J

生产突袭

真实演练

结合业务特性

图1阿里云容器服务混沌实践实施流程

手工演练：一般在高可用能力建设初期阶段，或者一次性验收

的情况下手工注入故障完成。通过人为查看告警是否生效，系统恢复

情况来进行演练。在这个阶段只需要一些故障注入的小工具或者脚本,

方便后续使用即可。

自动化演练：高可用能力建设到一定阶段后，往往会有定期检查

高可用能力是否退化的需求，自动化演练开始排上日程。自动化演练

步骤一般包括：环境准备->故障注入->检查->环境恢复。在每

个步骤中配置相应的脚本来形成演练流程，下一次就可以一键点击自

动化执行了。

常态化执行：演练进行到下一阶段，我们会有更高的要求，希望

演练可以自主混沌化执行，以无人值守的方式进行，这又对系统的高

可用能力有了新的挑战。这要求系统不仅有监控告警可以发现故障，

也有对应的预案模块来负责恢复，而要做到无人值守，需要系统进行

更智能精确的判断故障情况，自动执行相应预案。

图2阿里云容器服务混沌实践实施框架

生产突袭：以上演练大多在灰度环境进行，不会影响到业务，生

产突袭则要求系统有能力在生产环境控制爆炸半径的前提下进行故

障演练，以期发现一些业务相关、规模相关、配置相关、应急响应相

关的，在灰度环境中遗漏的部分，生产环境的演练对系统的要求较高，

需要有一套执行规范，对系统的隔离能力也有较高要求。大多数的工

作，能力建设都在灰度环境完成验证，但生产突袭仍作为一个有效且

必要的演练手段，用更真实的场景给研发体感，让其真实执行预案，

也锻炼了应急能力，对系统有更多信心和认知。

原子能力支持：在阿里云原生的架构上，我们整理了如下所示的

演练模型，在这个高可用能力模型中，我们根据系统架构按照管控层

组件、元集群组件、addon组件，数据存储，节点层，整体集群进行

区分，在每个模块中有一些通用的故障可以互相借鉴。

1富成组件元集群组件］Addon组件［数据存储1节点层1整体集群.

应用通用故障应用通用故障应用通用故障应用通用故障Node故障网络故障

正程挂

Pod故障Pod故障Pod故障容器故障外部依赖故障

:机器故障

:磁盘故障图徽:证书故障证书故障行心做障财侬

外期依赖故障证书故障■数据故障Pouchjfc—片黑量嚣」

;云盘国书过期」:虢输匚尸故障量&懿：

SLB

\ECSopenAPI：陛里置电....：国启,宕机磁：

，依赖配置丢失：:盘.load高，内；

，依赖配置错误：［修罢区......：

：Vpc故障

图3阿里云容器服务混沌演练模型

（二）常见问题及解决

常态化运行的稳定性：由于容器服务本身的架构特性，系统自带

很多自愈能力，正因如此，可以进行规模化的无人值守常态演练；常

态化运行可能因为环境原因、依赖系统不稳定等因素导致运行不稳定,

不能反映系统真实的能力情况。针对环境问题，一般会使用一个较为

稳定、和生产网络环境、依赖一致、但无生产流量的灰度环境进行，

同时透明变更记录，有问题马上告警介入。针对依赖系统不稳定等因

素导致的演练失败，需要提高系统自身的容错性建设，增加重试机制，

及时更新系统依赖。

生产突袭的风险控制：生产突袭会在有用户流量的集群进行，绝

不能有超出预期的行为。可以通过流量隔离的方式圈定影响范围，也

可以通过黑白名单、多重校脸的方式增加拦截，一旦超出预期，系统

可以自动熔断或人工介入主动熔断，防止进一步扩大影响范围。

六、实验创新点

(-)无人值守混沌化演练

在形式上做到了创新，真正做到无人值守，注入故障后触发系统

告警及自愈机制，故障升级自动告警升级，进而值班介入。节省人效，

问题自动发现。

混沌化能力的创新，在实践中支持定制故障集合、时间周期、随

机参数等混沌指数，使得故障注入更接近真实场景，得以探测系统问

题。

(二)云服务在线生产突袭

相比其他行业或者系统，阿里云容器服务面对的客户更为复杂,

在线服务影响也较大，但为了更真实的进行生产突袭，评估系统提供

服务的稳定性，内部进行了架构改造、环境隔离、数据分离等全链路

的隔离，使得生产级别的演练可以进行。在突袭过程中，可以在不影

响用户流量的情况下识别系统高可用能力的退化情况，同时触发真实

的故障处理流程，锻炼了运维人员的处理故障能力和整个系统的鲁棒

性。

阿里云容器服务的混沌工程实践影响范围大，会在1500+节点、

10W+用户容器规模生产集群进行突袭实践。

同时形式上有所创新，突袭频次很高，截止2021年度，内部实

施过程突袭了150+次，在突袭过程中模拟真实故障发生情况，生产环

境、历史故障、一定范围内随机时间及场景进行注入。

（三）分层演练，推进预案产品化演进

通过无人值守演练，不断验收产品自动化恢复能力；

通过生产突袭推进产品，将非自愈预案逐步转化为自愈；

通过以上的方式，使得短期人治能力逐渐转换成普适的产品能力,

不随人员更迭而变动，同时普惠云产品广泛用户。

七、实验收益

在阿里云内部实施过程中，常态化无人值守演练有效的覆盖了

100%历史故障及业务核心故障场景200个，年执行次数8000+,有效

的发现了90+个高可用问题，其中17个告警问题得到优化，43个预

案得到优化，在演练的有效推进下，产品的告警发现率提升了20%,

预案覆盖率也从无到有，自动化预案比例提升了40%。

生产突袭演练覆盖了所有核心云产品，发现解决了14个问题，

响应力预案告警能力有整体提升，2021全年生产突袭次数达到150+,

有效推进了各个产品的预案能力，应急能力，etcd故障响应时长

从＞10min到3min,公有云ACKapiserver故障：响应时长从＞10min

到4min；镜像仓库产品告警时长从llmin到lmin,系统恶意流量场景

恢复时长从35min提升到8min。同时在演练过程中推进了各个产品

轮班制度的建立，整体公有云产品高可用能力大大提升。

除此外，混沌工程实施过程中的工具具备一定的通用性，对接了

内部各种告警平台，20+种故障注入插件，演练流程灵活适配，给业

务团队提供了便捷工具。

八、反思及改进

目前的故障注入基本都基于已有已知的场景进行随机组织、参数

变化得到，后续考虑进行AI探测架构，自动分析系统薄弱点，组织

场景集，可以根据集群入口、网关等配置，自动嗅探薄弱点，同时自

动组织注入点，和负载livenesshook等配置结合，判断健康度，减

少配置成本，增加风险覆盖。

对于生产故障，目前通常需要人工捞取现场进行回溯，问题的复

现也往往依赖人工组织场景，后续考虑进行问题复现路径全息回放能

力建设，每次根据现场情况上下文不同进行回放现场，解决问题后，

也可以利用该能力复现历史具体故障进行复盘和回归，用同时刻的全

息360复现能力以确保问题解决。

2.蚂蚁集团：蚂蚁集团红蓝攻防实践

一、申报单位

蚂蚁科技集团股份有限公司。

二、案例简介

蚂蚁集团混沌工程实践起源于技术风险部。蚂蚁集团技术风险部

于2015年正式成立，部门组建之初的目标主要是夯实容灾能力，构

建资金安全防控体系；2016年部门组建国内第一支SRE团队，开始

全面开展故障自动定位、自适应容灾、灰度环境搭建、资金安全免疫、

精细化高可用等工作；时至今日，技术风险部已取得云通未来、容灾

三地五中心建设、模化应用“绿色计算”等里程碑，并完成仿真环境

从0到1建设，实现风险左移、有损演练；目前，部门正朝着建设数

字化运营管理体系方向前进，驱动风险、效能和成本持续改进。

蚂蚁混沌工程实践以红蓝攻防为主要表现形式，已持续数年，其

显著特点为超大规模，主要体现在如下几点：

1.参与的团队和人数多：几乎涵盖所有蚂蚁业务及其技术团队，

直接参与混沌工程的工程师人数有近千人；

2.覆盖的应用系统多：覆盖数千个应用系统；

3.发现的问题多：包括系统问题，业务问题，配置问题等，2021

年全年发现问题500多个；

4.攻防执行的次数多：2021年全年各领域的故障注入次数合计

达到上亿级别，大部分演练以天为粒度进行持续回归。

三、用户简介

蚂蚁集团是移动支付平台支付宝的母公司，也是全球领先的金融

科技开放平台，致力于以科技推动包括金融服务业在内的全球现代服

务业的数字化升级，携手合作伙伴为消费者和小微企业提供普惠、绿

色、可持续的服务，为世界带来微小而美好的改变。

图4蚂蚁集团-为世界带来微小而美好的改变

四、需求分析

蚂蚁集团的业务大多具有金融属性，每天都有大量的交易在生产

环境发生，涉及的金额巨大，另外，支付宝app已深深融入国民的日

常生活，其中诸如扫码支付、地铁出行等是人们每天高频使用的功能,

因此，蚂蚁对系统稳定性和可用性，以及业务逻辑的正确性的要求极

高，生产环境一旦发生故障，很可能导致用户发生资损，或者导致社

会舆情。蚂蚁技术风险部围绕生产故障开展工作，在故障发生前能够

识别出潜在风险并阻断，在发生故障后能够快速止血减少影响，为此

建设了一整套的分布式系统稳定性以及业务风险防控系统，包括监控,

变更，容量，应急，资金核对等，这些系统有效降低了生产故障数量，

蚂蚁近3年的生产故障数量呈现明显下降的趋势。

在上述背景下，混沌工程（红蓝攻防）的主要fi求包括：第一，

在生产故障逐年降低的背景下，全套技术风险防控能力仍然需要不断

被检验，保障这些能力在下一次故障发生前或者发生时能够起作用；

第二，故障处理相关人员的能力需要不断被检验，包括个人处理能力，

团队之间的协作能力，故障处理能力在团队的传承等；第三，通过混

沌工程帮助业务发现潜在风险，例如通过故障泛化的能力，将某个业

务出现过的故障泛化至还未发生过类似故障的业务，做到提前防范；

第四，技术风险智能化是当前蚂蚁技术的主要方向之一，通过混沌工

程提供智能化防线需要的海量数据，训练智能算法，牵引智能防线建

设；第五，宣导混沌工程的文化，通过混沌工程在技术工程师心中建

立技术风险心智，时刻对线上系统保持敬畏之心。

五、技术方案介绍

蚂蚁混沌工程的整体技术框架图如下:

以混沌工程为技术被心，通过红蓝攻防模式驱动人与智能的双重闭环，

持续提升风险防控水位，构建业界领先的技术风险体系

图5蚂蚁混沌工程整体技术框架图

（一）技术方案的要点包括:

1.在软件生命周期的各个阶段，都有混沌工程的实践，包括开发测试

阶段，发布阶段，运行阶段，数据处理阶段。这部分会在“实验创新

点”中详细叙述。

2.混沌工程的业务主要包括三个方面，场景构建，攻击（故障注入），

度量和运营。

（1）场景构建。主要作用是生成混沌工程的攻击场景，分为自

动化构建和人工构建两种类型。自动化构建基于统一场景模型和元数

据，结合一些算法，构建出通用防线的攻击场景，例如在资金核对防

线方面，通过资金表识别技术（资金表模型+采集生产资金流数据+算

法），自动化生成资金一致性的攻击场景（资金表的资金字段内容错

误）；人工构建主要是将专家经验转化为攻击场景，用于业务逻辑较

强的复杂场景设计。另外，还运用泛化技术，将针对某个业务的攻击

场景，扩展到其他业务中。

（2）攻击，即故障注入。包括上层的业务逻辑，如攻击流程的

编排（攻击之前的权限控制和环境准备，攻击时的故障下发，攻击之

后的度量和环境回收）、攻击持续集成调度（周期性的持续运行），

攻击执行统一客户端（屏蔽底层不同故障原子能力）；底层的混沌攻

击武器库，即故障原子能力，包括任意JAVA方法的代码化攻击（可

动杰替换任意JAVA方法的执行逻辑）、日志攻击（篡改日志，追加

日志）、云原生攻击（k8s和容器层面的故障）等等。从蚂蚁技术整

体来看，目前故障注入的覆盖范围包括，任意JAVA应用，中间件，

容器，K8S,数据库，离线数据仓库。

（3）度量和运营。度量主要是将攻击产生的效果以及发现的问

题揭示出来，目前大部分可持续集成运行的攻击，其度量也是自动化

的；攻击会发现一些问题，也会由专门的系统负责记录和追踪；通过

攻击体现出的业务防控水平，会定期形成报表呈现给业务用户。运营

分为日常运营和活动运营，日常运营通过业务之间的横向比较，驱动

防控能力低的业务不断提升；活动运营会在每年定期组织大型的红蓝

攻防活动，目前包括一年两次的527和1218红蓝攻防活动。

混沌工程依赖很多基础技术和基础设施，基础技术包括统一应用

切面awatch（主要提供JAVA代码化故障注入能力，以及资金流数据

采集能力），污点分析（主要服务于资金服务攻击场景的自动化构建），

流量染色（主要目的是识别出攻击影响的用户，将影响限制在内部用

户）；基础设施包括多云（蚂蚁的业务分布在多云环境中，要求混沌

工程这套技术能够支持私有云，公有云，混合云的多云环境），依赖

的软件基础数据和运行数据（主要帮助构建场景），以及各类环境（生

产环境，仿真环境，线下环境等）。

（二）实施案例遇到的问题

案例实施过程中遇到和解决了不少问题，这里选取几个重要的问

题进行阐述：

第一，在混沌工程实践初期，攻击主要以真实故障注入为主要方

式，即“有损”攻击，这类攻击需要业务进行应急恢复，成本较高，

导致攻击频率无法提升。针对这个问题，主要的解决思路是“无损”

攻击思路的提出，即将攻击的目的进行拆解，有损攻击类似生产故障，

需要先发现再应急，如果将发现和应急二者拆分开来，如果只检验发

现（发现率也是更重要的指标），那就无需制造真实故障。例如，在

资金核对的攻防上面，有损攻击发生在业务系统，会真实篡改业务数

据，而无损攻击发生在资金核对系统，篡改的是核对系统消费的数据

（该数据可以认为是真实业务数据的副本），这是与业务主路径无关

的一条旁路，注入核对系统不会对业务产生影响，业务也无需应急，

这种注入主要检验核对系统中的核对规则是否有效，以及核对系统本

身是否有问题。

第二，无损攻击的真实度不够，有些复杂场景也不能通过无损攻

击实现，解决这个问题的思路主要是依赖仿真环境的建设，仿真环境

与生产环境高度相似，但应用和数据都与生产环境进行隔离，这个环

境特别适合进行真实故障注入，目前很多复杂的业务攻击场景都是在

仿真环境完成的。

第三，无损攻击会产生很多告警，对业务开发测试人员的打扰严

重，解决这个问题，有两个思路，第一是对无损攻击的链路进行改造，

监控能够区分出异常来源，对来源于攻击的异常进行告警屏蔽；第二，

也是一个创新的思路，是建设混沌靶场，将针对通用防线的无损攻击，

转移到靶场进行，靶场会在“实验创新点”中详细叙述。

六、实验创新点

（-）面向软件完整生命周期的混沌工程

软件完整生命周期包括开发测试，发布，运行，数据等多个阶段，

每个阶段都会产生技术风险，蚂蚁在每个阶段都有技术风险的防控工

作，因此要求混沌工程也能够覆盖到每个阶段。具体包括：

1.开发阶段，进行源代码级别的故障注入，在源代码中增加注入

代码，目的是检验codereview是否做的足够充分和细致。

2.测试阶段，进行测试用例级别的故障注入，修改测试用例目标

方法入参，检验测试用例是否会因为入参的变化而失败，从而检验是

否有断言（不写断言，测试用例总会通过，有风险）。

3.发布阶段，发布本质上是一种变更行为，在这个阶段进行的是

针对变更的故障注入，蚂蚁技术风险建设有统一变更核心，通过各种

变更防御规则对有风险的变更进行拦截，变更故障注入模拟不符合规

则的变更，例如模拟一个发生在中午12点的变更（12点属于午餐时

间段，业务高峰期，本来不允许变更），检验相应的变更防御规则是

否能够拦截该变更；或者模拟变更导致的系统故障，检验变更核心是

否能够发现该故障并关联到正确的变更，并将该变更回滚；另外，变

更影响面（变更影响的服务，变更影响的资金表等）也是风险挖掘的主

要方向之一。

4.运行阶段，包括系统稳定性和可用性的故障注入，以及面向业

务的故障注入。前者例如服务异常，数据库超时，后者例如资金表数

据篡改，业务代码逻辑篡改。

5.数据阶段，在线运行的系统，产生的数据会周期性同步至离线，

离线进行加工处理之后的数据，又会被一些在线系统使用，在这个过

程中也会进行故障注入，例如在离线数据同步发生延迟，数据计算过

程中出现数据错误和丢失，等等。

（二）面向业务的故障注入

由于蚂蚁的业务大多具有金融属性，对业务正确性的要求极高，

对资金相关故障是零容忍的。根据内部数据分析，蚂蚁的生产故障跟

资金相关的，多数为业务内部逻辑错误导致，某些逻辑错误在测试阶

段难以发现，发生的条件极其复杂，因此对该类型故障的设计，就必

须紧贴业务进行。

面向业务的故障注入，基于蚂蚁自研的统一JAVA字节码框架

Awatch,在技术上能够做到JAVA应用的代码级替换注入，即用故障

注入设计的代码片段，在系统运行过程中，动态替换掉业务原本运行

的代码片段，从而达到非常灵活的业务逻辑层面的错误。例如，运用

此技术，可以实现修改方法的参数和返回值，跳过方法内部某些关键

操作，重复执行某些操作，打乱操作的顺序，等等。

（三）混沌靶场

混沌靶场是指在生产环境中自建的一套小型分布式系统，专门用

于在生产环境进行故障注入。混沌靶场提出的主要考虑是，目前蚂蚁

技术风险的各种防线，大多为通用防线，即提供各个业务通用的防御

能力，例如高可用领域中的服务限流，通用定位（服务异常定位等），

通用变更防御（通用防御规则），等等，这些能力不因应用系统的差异

而发生变化，因此没有必要一定通过注入业务系统对其进行检验，靶

场系统接入这些通用防御能力之后，通过注入靶场系统也能够达到相

同的检验目的，同时不会因故障注入而影响业务，也不会因高频的故

障注入产生大量告警而打扰开发测试人员。

（四）污点分析技术

污点分析作为一种经典的信息流分析技术，可以追踪指定的关键

数据字段在程序中的传播和流向。通过指定关注的数据（source）作为

污点，分析该数据字段是否在程序中可以传播到指定的终点（sink）,

此技术主要用于混沌工程中的风险挖掘领域，在该领域，资金服务和

消息到达资金表的路径是关键挖掘目标，通过污点分析技术，可以准

确识别出资金表的字段的源头对应的服务和消息中的参数，进而为面

向业务的故障注入提供丰富的攻击场景（修改服务和消息的关键参

数）。

七、实验收益

在2021年，通过混沌工程发现的业务风险和问题有300多个,

推进解决的有200多个；日常红蓝攻防次数有几十万次，涵盖高可用,

资金安全，研发质量等领域，混沌工程的服务覆盖到蚂蚁所有主要业

务，核心业务单元的技术风险防控保持较高水位（例如核心业务变更

防御率达到90%以上，核心业务指标异常的监控发现率达到99%以上，

资金一致性核对的发现率达到90%以上）；大型活动如1218牵引资

金核对规则部署新增1000多条；诞生自混沌工程的统一JAVA字节码

框架awatch,不仅服务于混沌工程，而且扩展到其他业务领域，包括

仿真环境、安全切面、业务巡检等，有效解决了业务遇到的问题。

八、反思及改进

1.混沌工程智能化程度不够，目前需要人参与的比例较高，主要

集中在场景构建方面，专家经验转化为场景需要大量人力投入，未来

需要结合数据和算法，采用泛化的方式，提升智能化场景构建的水平。

2.风险挖掘的结果准确性不足，需要较多人为打标的修正工作，

未来在技术上需要有所突破，数据和算法的使用需要更加有深度。

3.混沌工程平台使用门槛较高，部分故障注入的配置较为复杂，

需要不断降低学习成本，提升使用体验，提升易用性。

4.基础设施建设例如仿真环境还需要加速，部分业务由于环境的

制约，无法大规模的进行混沌工程实践。

5.大型活动的人力时间投入较多，主要体现在活动的故障场景设

计方面，需要加强日常面向业务的红蓝攻防，提升大型活动的举办效

率。

3.腾讯云：混沌工程对于云计算服务应用案例

一、申报单位

深圳市腾讯计算机系统有限公司。

二、案例简介

腾讯云混沌工程旨于为客户提供适合各业务环节的混沌工程实

践解决方案，集成数百余故障注入原子能力，并采用混沌工程全生命

周期的管理方案形式进行整体管控，满足客户开展常态化混沌工程实

验需求。腾讯云混沌工程共累计实战演练万余次，发现并排查系统隐

患故障，助力客户系统优化系统高可用性架构，有效地减少系统故障

出现次数，降低系统故障影响时长，提升客户系统的运营质量。

三、用户简介

腾讯云，腾讯集团倾力打造的云计算品牌，面向全世界各个国家

和地区的政府机构、企业组织和个人开发者，提供全球领先的云计算、

大数据、人工智能等技术产品与服务，以卓越的科技能力打造丰富的

行业解决方案，构建开放共赢的云端生态，推动产业互联网建设，助

力各行各业实现数字化升级。

四、需求分析

越来越多的业务选择基于云原生技术构建系统架构，在云原生架

构迁移的过程中，混沌工程可以助力构建容错性好、弹性可扩展的云

原生系统。在这种时代背景下，混沌工程开源协同联合协同团队与腾

讯学院通力打造混沌工程系列课程，帮助业务了解混沌工程的思想和

原则，并分享在不同的业务场景下如何实施落地混沌工程，为希望通

过混沌工程来提升系统韧性的业务提供指引和帮助。

随着腾讯云的规模越来越大，无论是基础设施还是产品架构都越

来越复杂，出现故障的风险也越来越大，希望有个系统能够：持续发

现云产品服务的故障隐患，优化服务架构；持续检验云产品服务应对

解决故障的能力；持续检验腾讯云监控告警及服务自恢复的能力。腾

讯云混沌工程正是因这个背景，通过主动注入故障，提前发现潜在问

题，迭代改进架构和运维方式，最终实现业务韧性。

五、技术方案介绍

(-)混沌工程整体技术框架图

用户在通过云API的形式访问的混沌工程平台，通过网关过滤掉

非法的请求内容。由平台根据用户的权限提供相应的功能。

用户的故障演练任务数据存储在数据库，故障注入整个流程采用

的异步事务处理流程。服务端会创建演练数据，通过消息队列产生故

障注入消息。动作库在监听到消息内容后，通过数据库获取到故障注

入参数后，通过与Agent探针的通信通道，下发故障到目标机。

在执行完成后，动作库更新任务状态，完成整体的故障注入过程。

6

图6混沌工程整体技术框架图

（二）基础设施支持情况

目前混沌工程平台已支持物理机、虚拟机、Kubernetes（K8s）、

关系型数据库（MySQL）、负载均衡器（CLB）、非关系型数据库（Redis）

等资源的故障注入能力。

（三）故障注入原子能力（共200+故障原子能力）

1.物理机、虚拟机

CPU负载、10负载、主机重启、内存负载、文件删除、时间偏移、

磁盘填充、网络压测、网络限速、网络丢包、自定义Shell脚本、网

络访问不可达等；

2.Kubernetes

容器：CPU负载、网络延迟、域名访问异常、网络丢包、删除容

器等；

Pod：网络延迟、网络丢包、删除Pod、磁盘10负载、磁盘满载

等；

3.关系型数据库(MySQL)

主从实例不可以达、主备切换、设置最大连接数等；

4,非关系数据库(Redis)

主备切换、主备节点不可用等；

5.负载均衡器(CLB)

集群宕机故障、外网IP封堵等。

(四)实验流程管理方案

目前采用混沌工程全生命周期的管理方案形式，将生命周期分为

事前、事中、事后三大部分进行整体管控。

1.事前：

由产品架构师根据现有的产品架构提出基础设施故障假说，明确

演练的爆破顺序编排、爆破范围、人员安排。然后在混沌工程中创建

演练计划，通过演练计划自动通知相关人员，同步整体的演练计划方

案。

2.事中：

（1）创建演练，根据演练计划的内容一键生成演练任务，由运

维人员根据整体方案的部署内容以及爆破目标的类型设定护栏阈值，

确保控制影响范围。配置稳态监控指标，方便及时了解相关目标的数

据指标波动情况。

（2）演练审批，运维人员在执行前需要通过相关机器负责人审

批授权，方便相关人员在第一时间知晓自身所负责的机器要进行演练。

（3）演练执行，执行人员根据配置的执行模式（手动或者自动）

进行操作进行故障注入。观察稳态指标，险证产品对于故障的反应是

否符合预期。执行完成故障注入后，通过恢复动作移除故障，进行稳

妥恢复。

3.事后：

（1）总结复盘：根据本次演练的执行结果进行总结复盘。然后

创建相应的改进事件督促产研方进行容灾能力提升。

（2）演练报告：将事件的全流程形成大屏报告，发送给相关人

员了解本次演练的全流程。

（五）实施遇到问题及解决思路

问题：涉及的产品较多，其中包含了公司的重点产品。产研方出

行安全的考虑，没有深度参与混沌工程的使用。

解决思路:

第一，成立混沌工程推广专项。从上到下推广混沌工程全流程管

理方案理念，设定各个产品的使用目标；定期组织内部分享会，协助

产品方正确的使用混沌工程平台。

第二，提出准生产模拟方案，利用产品方的准生产环境进行混沌

工程爆破实验，降低在生产环境的爆破风险；对于未构建准生产环境

的产品，利用容器能力，混沌工程平台快速根据用户提供的配置文件

构建沙箱环境，然后进行实验。

六、实验创新点

云上产品存在几个特点：底层依赖多、迭代快、多地域部署，针

对这几个特点，腾讯云混沌工程平台做出创新的解决方案：

1.结合网络管理部门，实现快速探查目标机器的组件依赖能力。

通过混沌平台的扫描工具，输入目标的域名，在10分钟内完成整体

架构的扫描。从而解决产品方在构建准生产环境时，需要大量人力来

梳理复杂的组件依赖关系。

2.配合内部的DevOps研效工具，以插件形式切入到持续部署(CD)

流水线中。提高测试人员使用混沌工程的效率，从原先的半小时提高

到10分钟(在混沌工程的构建与使用上所耗费的时间)。极大的减

轻测试人员在验证准生产环境的工作量。

3.组建虚拟组织，从上至下的推到混沌工程的使用落地。以纵向

方式传递混沌工作全事件管理理念，以及混沌工程实施的好处；以横

向方式组织混沌工作案例交流会，让各云产品相关人员针对混沌工程

实施经验进行横向交流。

4.内部设定产品的混沌工程成熟度评级制度，对于优秀的云产品

进行嘉奖；对于成熟度低的产品制定辅导推进计划，协助相关负责人

推进云产品使用混沌工程平台。

七、实验收益

为腾讯云提供适合各业务环节的混沌工程实践的解决方案，满足

业务测试日常的混沌试验，提高分布式系统的弹性与韧性，建设了腾

讯云混沌工程项目和混沌演练平台项目。腾讯云混沌工程项目截止目

前覆盖30+云产品，共累计实战演练万余次，发现并排查掉了发现并

排查系统隐患故障，助力客户系统优化系统高可用性架构，有效地减

少系统故障出现次数，降低系统故障影响时长，提升客户系统的运营

质量。

同时，在一个月内结合内部混沌工程最佳实践从0到1建设并上

线了腾讯云混沌演练平台产品，目前已接入多家大客户，助力客户双

活架构改造，提升腾讯云对客户的支持效率。

八、反思及改进

1.反思：

(1)混沌工程在内部体系下的实施与云上协助用户实施效果存

在较大差异，云上混沌工程产品效果低于预期。

(2)协助用户在企业内部进行混沌工程的实验主要通过自上而

下的推行，用户的成员可以快速的响应政策，加入到混沌工程使用的

队伍中。但是协助用户构建云上混沌工程产品时，因为大部分客户还

处于一个观望和测试阶段，难以将较为真实的场景进行混沌工程实验。

2.改进措施：

（1）协助用户举办线下活动。以行业范围来划分客户群体，协

助用户对客户进行混沌工程理念的宣讲与沟通；提高用户的混沌工程

产品在行业内的影响力。

（2）协助用户将相关培训资料定期通过线上课程、论坛、博客

等形式推广产品，提高客户对于用户产品的认可度。

4.京东科技：京东云全平台破坏演练

一、申报单位

京东科技信息技术有限公司。

二、案例简介

随着云计算被各行业广泛应用并成为关键基础设施，云的稳定性

越来越重要。政务、金融、互联网、制造、能源等各行业逐渐将核心

业务和数据部署到云上，如何评估及保障云产品特别是云平台整体的

稳定性是各家云厂商必须面临和解决的问题，也是已上云、有上云计

划企业关注的核心问题。

为了评价和提升云平台面对失控情况下的抗脆弱能力、建立产品

信心，京东云需要落地混沌工程中更为复杂的业务场景，即全平台阶

段性验收大演练，涉及全平台、全系统、大规模下的复杂场景。一方

面验证系统在各类真实故障场景下的表现，并对问题加以分析和优化,

使得系统的“抗脆弱性”持续增强，同时提高云产品的稳定性，进而

提高服务可用性SLA。

本案例主要描述了京东云全平台破坏演练场景下的解决方案和

落地效果。

通过多年的京东618、双11,以及2022央视春晚的磨练，京东

云成为混沌工程的领先实践者和受益者，从单业务场景故障到整机房

故障宕机，京东云完美通过各类复杂场景考验。作为最懂产业的云，

京东云将积极在混沌工程领域的探索，并持续输出京东云的成功经验,

助力产业数字化过程中IT系统稳定性的持续提升。

三、用户简介

京东科技集团是京东集团旗下专注于以技术为产业服务的业务

子集团，致力于为企业、金融机构、政府等各类客户提供全价值链的

技术性产品与解决方案。依托人工智能、大数据、云计算、物联网等

前沿科技能力，京东科技打造出了面向不同行业的产品和解决方案，

以此帮助全社会各行业企业降低供应链成本，提升运营效率，成为值

得产业信赖的数字合作伙伴。

京东云（JDCloud）是京东科技旗下的智能技术提供商，依托京

东集团在人工智能、大数据、云计算、物联网等方面的业务实践和技

术积淀，打造服务于数字企业、数字政府的多维场景解决方案。

四、需求分析

为了评价和提升云平台面对失控情况下的抗脆弱能力、建立产品

信心，京东云需要落地混沌工程：

1.验证系统在各类真实故障场景下的表现

2.对问题加以分析和优化，使得系统的“抗脆弱性”持续增强

3.提高云产品的稳定性，进而提高服务可用性SLA

在具体的落地中，方案需要支持两种场景：

1.CICD场景，单产品单系统的故障注入和演练，确保单系统、

或少量产品组合下的抗脆弱能力。此场景主要覆盖：资源占满、进程

异常、网络延时、实例切换等场景。

2.全平台阶段性验收大演练，关注全平台、全系统、大规模下的

复杂场景。

五、技术方案介绍

（一）演练目的：

主动发现公有云稳定性风险，提前加固，模拟严重故障，需要全

平台一起联动的场景。验证故障发生时，各产品：可用性（SLA偏移及

损耗）、报警及时性、预案有效性、MTTR、人员操作熟练度等。

（二）演练环境：

由于是全平台严重故障模拟，在当前情况下为避免在生产环境爆

炸半径过大导致产生重大影响的线上故障，本次云平台整体故障演练

是在公有云仿真环境进行。为更真实的模拟生产环境，演练前需要对

仿真环境进行治理和必要的准备：

1.模拟京东公有云某区域多可用区部署

2.参演产品根据特点进行跨AZ、AZ内高可用部署

3.明确所部署产品与对应物理机资源、虚拟机资源的对应关系

4.各产品留足资源冗余水位，确保满足自愈、稳态验证等需求

5.各产品部署版本大于等于生产环境版本

6.将服务间依赖信息作为基准数据

7.设计有一定云产品覆盖度的业务场景，例如电商场景、物流场

景等

8.对业务进行大并发压力准备

9.资源稳态和业务稳态监控准备

仿真环境概况：

图7京东云平台仿真环境

（三）演练流程:

核志■”标学练驴型外L田练当即邑々析层位四练里结

F降温矫rF丽苒丽

业务!»忐*=>魏鹏卬分析的结演努

•装就由侵故Q•注入/帐筮改通

•业先请求成功率•暝审箱态盾标•

•K8S故同•手曲/自即程班

•业转请求响应延迟・顺搪日志分析•依0校准

•中间件/依1»•g态触及大脚

陵舞0芯・一键建止雷缥•总结下次计划

•应用故国•皤续业务压n

图8京东云全平台故障演练流程

稳态指标:

为实现在演练过程中实时、全局观测各产品稳态,需要在演练前

做好稳态监控的配置。

京东云云泰故障注入与演练平台提供了强大的稳态监控能力，包

括云资源稳态（SLI实时探测、SLA损耗分析）和业务稳态两大部分。

云资源稳态示意图：

采用云所承诺的SLA算法，对每一个云资源实例进行可用性主动

探测。通过实时对SLI和SLA偏移量对比，评价故障对云资源可用性

的影响。

可

用

性

采

集

屋

«

意图

稳态示

云资源

图9

图：

示意

稳态

业务

云平

时观测

首屏实

试。

持调

，支

脚本