混沌工程先锋实践者 优秀案例

1、 混沌工程先锋实践者优秀案例（2022 年） 目录 HYPERLINK l _TOC_250006 第一部分 互联网领域 1阿里云：阿里云容器服务混沌实践 1蚂蚁集团：蚂蚁集团红蓝攻防实践 9腾讯云：混沌工程对于云计算服务应用案例 19京东科技：京东云全平台破坏演练 27 HYPERLINK l _TOC_250005 第二部分 银行领域 38工商银行：工商银行混沌工程平台及混沌演练实践 38农行研发中心：农行金库系统混沌演练实践 47建信金科：建信金科混沌实践之道 63北京银行：顺天技术平台混沌工程实践 78平安银行：平安银行 ASTA 非功能测试平台 91中电金信：恒丰银行红蓝对抗演练 1

2、00 HYPERLINK l _TOC_250004 第三部分 证券领域 111中信建投：故障演练平台项目 111中泰证券：混沌工程在互联网金融业务的应用与实践 119 HYPERLINK l _TOC_250003 第四部分 通信领域 132中移信息：磐基 PaaS 平台混沌能力山东应急演练 132 HYPERLINK l _TOC_250002 第五部分 零售领域 139永辉科技：永辉生活电商全链路故障演练实践 139 HYPERLINK l _TOC_250001 第六部分 能源领域 144南网数研院：云原生应用架构驱动的全栈高可靠探测 144 HYPERLINK l _TOC_2500

3、00 编后语 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图

4、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图 3

5、0应用中间件演练解决思路 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平台故障演练活

6、动 116图 48仿真环境架构图 123图 49混沌工程平台技术架构图 124图 50混沌工程平台原子能力 125图 51基于混沌工程与演练质保的故障演练 126图 52混沌平台核心组件架构图 141图 53云原生系统高可用故障探测框架 147图 54应用系统高可用总体架构 148表目录表 1主要故障场景和预期结果 32表 2混沌工程分布式平台应用效果表 74表 3混沌工程实验演练步骤 127第一部分 互联网领域 阿里云：阿里云容器服务混沌实践一、 申报单位 阿里云计算有限公司。二、 案例简介 阿里云创立于 2009 年，是全球领先的云计算及人工智能科技公司。阿里云为 200 多个国家和地区的

7、企业、公共机构和开发者，提供安全、可靠的云计算、大数据、人工智能等产品和服务。阿里云作为全国首家云等保试点示范平台和首家通过国家等保四级备案测评的云服务商，为中国超过一半的上市公司， 80%的中国科技创新企业提供云计算服务。2021 年 7 月可信云大会，阿里云故障演练平台入选可信云最佳技术实践，并首批通过可信云混沌工程平台能力要求最高等级先进级认证。阿里云容器服务混沌实践是一套应用于云原生架构的混沌工程实践案例，内部实践沉淀了针对云原生架构丰富的 200+核心场景及其组合，通过无人值守演练和生产突袭有效发现了 90 多个高可用问题，提升了响应应急能力，推进了各个产品的自动恢复能力、预案能力演

8、进，使得整体公有云产品高可用能力大大提升。同时一部分场景转化成为了商业化产品 AHAS Chaos，更好地服务云客户，为其提供混沌工程解决方案。 三、 用户简介 阿里云云原生容器服务产品族，作为阿里云产品，在传统云计算基础上，具备更快更低成本的弹性，更好的软硬一体化灵活性，以标准的 Kubernetes 界面丰富生态，已经成为了云计算发展最快的技术方向。云原生帮助开发者大幅度降低资源成本和交付成本，从而更快更好地赢得市场。同时，云原生也给传统运维、研发方式带来了彻底的变革，这就使得传统的混沌工程手段需要跟随演进。四、 需求分析 阿里云容器服务支持业务分析：阿里云容器服务需要同时支持阿里云公有云

9、、专有云客户和阿里集团客户。云产品面临的业务场景、周边设施越来越复杂。为了应对复杂的架构演进，面向失败设计和稳定性显得尤为重要。阿里内部需要支撑 30W 级别的 POD 量级，挑战巨大。阿里云容器服务依赖分析：相比其他行业或者系统，阿里云容器服务面对的客户更为复杂，体量更大，作为整个阿里集团底座，承载了几乎全部的在线业务及离线运行资源；对于容器来说，所有的这些运行资源都是无差别的，但一旦出现故障，故障打击也是无差别的；为了 k8s 在阿里集团内的落地，需要对内部的网络、存储、OS 进行适配，同时这也会依赖内部的运维体系和基础设施，导致拓扑结构变得非常复杂。社区追寻：近两年的云原生技术风起云涌，

10、内部为了紧跟社区架构更替速度，每年会有两次的版本迭代，紧跟社区版本迭代，同时这也会引入新的风险。故障演练：作为稳定性问题充分暴露的练兵场，可以在更接近实际故障场景的环境中，暴露系统在生产环境中可能出现的问题，而混沌工程的引入，使得演练测试更接近真实的故障场景，在不断混沌化实验的过程中发掘可能出现的一些系统问题。 五、 技术方案介绍 （一）整体实施流程及框架整体实施流程一般分为这几个阶段：手工演练，流程工具自动化演练，常态化无人值守演练，生产突袭演练。这几个阶段的实施难度是从低到高，当然相应的收益也是从低到高。一个组织（云用户）可以随着自己业务应用服务体量的增大、复杂化和高可用能力的增高的历程，

11、根据实际情况需要来选择自己合适的阶段，然后随之进行升级和发展。即使从最简便的手工演练开始做起实施，经常也能带来相当明显且长远的高可用能力系统性提升。图 1 阿里云容器服务混沌实践实施流程手工演练： 一般在高可用能力建设初期阶段，或者一次性验收 的情况下手工注入故障完成。通过人为查看告警是否生效，系统恢复 情况来进行演练。在这个阶段只需要一些故障注入的小工具或者脚本，方便后续使用即可。自动化演练：高可用能力建设到一定阶段后，往往会有定期检查高可用能力是否退化的需求，自动化演练开始排上日程。自动化演练步骤一般包括：环境准备 - 故障注入 - 检查 - 环境恢复。在每个步骤中配置相应的脚本来形成演练

12、流程，下一次就可以一键点击自动化执行了。常态化执行：演练进行到下一阶段，我们会有更高的要求，希望演练可以自主混沌化执行，以无人值守的方式进行，这又对系统的高可用能力有了新的挑战。这要求系统不仅有监控告警可以发现故障，也有对应的预案模块来负责恢复，而要做到无人值守，需要系统进行更智能精确的判断故障情况，自动执行相应预案。图 2 阿里云容器服务混沌实践实施框架生产突袭：以上演练大多在灰度环境进行，不会影响到业务，生产突袭则要求系统有能力在生产环境控制爆炸半径的前提下进行故障演练，以期发现一些业务相关、规模相关、配置相关、应急响应相关的，在灰度环境中遗漏的部分，生产环境的演练对系统的要求较高，需要有

13、一套执行规范，对系统的隔离能力也有较高要求。大多数的工作，能力建设都在灰度环境完成验证，但生产突袭仍作为一个有效且必要的演练手段，用更真实的场景给研发体感，让其真实执行预案，也锻炼了应急能力，对系统有更多信心和认知。原子能力支持：在阿里云原生的架构上，我们整理了如下所示的演练模型，在这个高可用能力模型中，我们根据系统架构按照管控层组件、元集群组件、addon 组件，数据存储，节点层，整体集群进行区分，在每个模块中有一些通用的故障可以互相借鉴。图 3 阿里云容器服务混沌演练模型（二）常见问题及解决常态化运行的稳定性：由于容器服务本身的架构特性，系统自带很多自愈能力，正因如此，可以进行规模化的无人

14、值守常态演练；常态化运行可能因为环境原因、依赖系统不稳定等因素导致运行不稳定，不能反映系统真实的能力情况。针对环境问题，一般会使用一个较为 稳定、和生产网络环境、依赖一致、但无生产流量的灰度环境进行，同时透明变更记录，有问题马上告警介入。针对依赖系统不稳定等因 素导致的演练失败，需要提高系统自身的容错性建设，增加重试机制，及时更新系统依赖。生产突袭的风险控制：生产突袭会在有用户流量的集群进行，绝不能有超出预期的行为。可以通过流量隔离的方式圈定影响范围，也可以通过黑白名单、多重校验的方式增加拦截，一旦超出预期，系统可以自动熔断或人工介入主动熔断，防止进一步扩大影响范围。六、 实验创新点 （一）无

15、人值守混沌化演练在形式上做到了创新，真正做到无人值守，注入故障后触发系统告警及自愈机制，故障升级自动告警升级，进而值班介入。节省人效，问题自动发现。混沌化能力的创新，在实践中支持定制故障集合、时间周期、随机参数等混沌指数，使得故障注入更接近真实场景，得以探测系统问题。（二）云服务在线生产突袭相比其他行业或者系统，阿里云容器服务面对的客户更为复杂，在线服务影响也较大，但为了更真实的进行生产突袭，评估系统提供服务的稳定性，内部进行了架构改造、环境隔离、数据分离等全链路的隔离，使得生产级别的演练可以进行。在突袭过程中，可以在不影响用户流量的情况下识别系统高可用能力的退化情况，同时触发真实的故障处理流

16、程，锻炼了运维人员的处理故障能力和整个系统的鲁棒性。阿里云容器服务的混沌工程实践影响范围大，会在 1500+节点、 10W+用户容器规模生产集群进行突袭实践。同时形式上有所创新，突袭频次很高，截止 2021 年度，内部实施过程突袭了 150+次，在突袭过程中模拟真实故障发生情况，生产环境、历史故障、一定范围内随机时间及场景进行注入。（三）分层演练，推进预案产品化演进通过无人值守演练，不断验收产品自动化恢复能力；通过生产突袭推进产品，将非自愈预案逐步转化为自愈；通过以上的方式，使得短期人治能力逐渐转换成普适的产品能力，不随人员更迭而变动，同时普惠云产品广泛用户。 七、 实验收益 在阿里云内部实施

17、过程中，常态化无人值守演练有效的覆盖了 100%历史故障及业务核心故障场景 200 个，年执行次数 8000+，有效的发现了 90+个高可用问题，其中 17 个告警问题得到优化，43 个预案得到优化，在演练的有效推进下，产品的告警发现率提升了 20%，预案覆盖率也从无到有，自动化预案比例提升了 40%。生产突袭演练覆盖了所有核心云产品，发现解决了 14 个问题，响应力预案告警能力有整体提升，2021 全年生产突袭次数达到 150+，有效推进了各个产品的预案能力，应急能力，etcd 故障响应时长从10min 到 3min ，公有云 ACK apiserver 故障：响应时长从10min到 4mi

18、n；镜像仓库产品告警时长从 11min 到 1min,系统恶意流量场景恢复时长从 35min 提升到 8min。同时在演练过程中推进了各个产品轮班制度的建立，整体公有云产品高可用能力大大提升。除此外，混沌工程实施过程中的工具具备一定的通用性，对接了内部各种告警平台，20+种故障注入插件，演练流程灵活适配，给业务团队提供了便捷工具。八、 反思及改进 目前的故障注入基本都基于已有已知的场景进行随机组织、参数变化得到，后续考虑进行 AI 探测架构，自动分析系统薄弱点，组织场景集，可以根据集群入口、网关等配置，自动嗅探薄弱点，同时自动组织注入点，和负载 liveness hook 等配置结合，判断健康

19、度，减少配置成本，增加风险覆盖。对于生产故障，目前通常需要人工捞取现场进行回溯，问题的复现也往往依赖人工组织场景，后续考虑进行问题复现路径全息回放能力建设，每次根据现场情况上下文不同进行回放现场，解决问题后，也可以利用该能力复现历史具体故障进行复盘和回归，用同时刻的全息 360 复现能力以确保问题解决。蚂蚁集团：蚂蚁集团红蓝攻防实践一、 申报单位 蚂蚁科技集团股份有限公司。二、 案例简介 蚂蚁集团混沌工程实践起源于技术风险部。蚂蚁集团技术风险部于 2015 年正式成立，部门组建之初的目标主要是夯实容灾能力，构建资金安全防控体系；2016 年部门组建国内第一支 SRE 团队，开始全面开展故障自动

20、定位、自适应容灾、灰度环境搭建、资金安全免疫、精细化高可用等工作；时至今日，技术风险部已取得云通未来、容灾三地五中心建设、模化应用“绿色计算”等里程碑，并完成仿真环境从 0 到 1 建设，实现风险左移、有损演练；目前，部门正朝着建设数字化运营管理体系方向前进，驱动风险、效能和成本持续改进。蚂蚁混沌工程实践以红蓝攻防为主要表现形式，已持续数年，其显著特点为超大规模，主要体现在如下几点：参与的团队和人数多：几乎涵盖所有蚂蚁业务及其技术团队，直接参与混沌工程的工程师人数有近千人；覆盖的应用系统多：覆盖数千个应用系统；发现的问题多：包括系统问题，业务问题，配置问题等，2021年全年发现问题 500 多

21、个；攻防执行的次数多：2021 年全年各领域的故障注入次数合计达到上亿级别，大部分演练以天为粒度进行持续回归。三、 用户简介 蚂蚁集团是移动支付平台支付宝的母公司，也是全球领先的金融科技开放平台，致力于以科技推动包括金融服务业在内的全球现代服务业的数字化升级，携手合作伙伴为消费者和小微企业提供普惠、绿色、可持续的服务，为世界带来微小而美好的改变。图 4 蚂蚁集团-为世界带来微小而美好的改变四、 需求分析 蚂蚁集团的业务大多具有金融属性，每天都有大量的交易在生产环境发生，涉及的金额巨大，另外，支付宝 app 已深深融入国民的日常生活，其中诸如扫码支付、地铁出行等是人们每天高频使用的功能，因此，蚂

22、蚁对系统稳定性和可用性，以及业务逻辑的正确性的要求极高，生产环境一旦发生故障，很可能导致用户发生资损，或者导致社会舆情。蚂蚁技术风险部围绕生产故障开展工作，在故障发生前能够识别出潜在风险并阻断，在发生故障后能够快速止血减少影响，为此建设了一整套的分布式系统稳定性以及业务风险防控系统，包括监控，变更，容量，应急，资金核对等，这些系统有效降低了生产故障数量， 蚂蚁近 3 年的生产故障数量呈现明显下降的趋势。在上述背景下，混沌工程（红蓝攻防）的主要fi求包括：第一，在生产故障逐年降低的背景下，全套技术风险防控能力仍然需要不断被检验，保障这些能力在下一次故障发生前或者发生时能够起作用；第二，故障处理相

23、关人员的能力需要不断被检验，包括个人处理能力，团队之间的协作能力，故障处理能力在团队的传承等；第三，通过混沌工程帮助业务发现潜在风险，例如通过故障泛化的能力，将某个业务出现过的故障泛化至还未发生过类似故障的业务，做到提前防范；第四，技术风险智能化是当前蚂蚁技术的主要方向之一，通过混沌工程提供智能化防线需要的海量数据，训练智能算法，牵引智能防线建设；第五，宣导混沌工程的文化，通过混沌工程在技术工程师心中建立技术风险心智，时刻对线上系统保持敬畏之心。 五、 技术方案介绍 蚂蚁混沌工程的整体技术框架图如下：图 5 蚂蚁混沌工程整体技术框架图 （一）技术方案的要点包括：在软件生命周期的各个阶段，都有混

24、沌工程的实践，包括开发测试阶段，发布阶段，运行阶段，数据处理阶段。这部分会在“实验创新点”中详细叙述。混沌工程的业务主要包括三个方面，场景构建，攻击（故障注入），度量和运营。场景构建。主要作用是生成混沌工程的攻击场景，分为自动化构建和人工构建两种类型。自动化构建基于统一场景模型和元数据，结合一些算法，构建出通用防线的攻击场景，例如在资金核对防线方面，通过资金表识别技术（资金表模型+采集生产资金流数据+算法），自动化生成资金一致性的攻击场景（资金表的资金字段内容错误）；人工构建主要是将专家经验转化为攻击场景，用于业务逻辑较强的复杂场景设计。另外，还运用泛化技术，将针对某个业务的攻击场景，扩展到其

25、他业务中。攻击，即故障注入。包括上层的业务逻辑，如攻击流程的编排（攻击之前的权限控制和环境准备，攻击时的故障下发，攻击之后的度量和环境回收）、攻击持续集成调度（周期性的持续运行），攻击执行统一客户端（屏蔽底层不同故障原子能力）；底层的混沌攻击武器库，即故障原子能力，包括任意 JAVA 方法的代码化攻击（可动态替换任意 JAVA 方法的执行逻辑）、日志攻击（篡改日志，追加日志）、云原生攻击（k8s 和容器层面的故障）等等。从蚂蚁技术整体来看，目前故障注入的覆盖范围包括，任意 JAVA 应用，中间件，容器，K8S，数据库，离线数据仓库。度量和运营。度量主要是将攻击产生的效果以及发现的问题揭示出来，

26、目前大部分可持续集成运行的攻击，其度量也是自动化的；攻击会发现一些问题，也会由专门的系统负责记录和追踪；通过攻击体现出的业务防控水平，会定期形成报表呈现给业务用户。运营分为日常运营和活动运营，日常运营通过业务之间的横向比较，驱动防控能力低的业务不断提升；活动运营会在每年定期组织大型的红蓝攻防活动，目前包括一年两次的 527 和 1218 红蓝攻防活动。混沌工程依赖很多基础技术和基础设施，基础技术包括统一应用切面 awatch（主要提供 JAVA 代码化故障注入能力，以及资金流数据采集能力），污点分析（主要服务于资金服务攻击场景的自动化构建），流量染色（主要目的是识别出攻击影响的用户，将影响限制

27、在内部用户）；基础设施包括多云（蚂蚁的业务分布在多云环境中，要求混沌工程这套技术能够支持私有云，公有云，混合云的多云环境），依赖的软件基础数据和运行数据（主要帮助构建场景），以及各类环境（生产环境，仿真环境，线下环境等）。（二）实施案例遇到的问题案例实施过程中遇到和解决了不少问题，这里选取几个重要的问题进行阐述：第一，在混沌工程实践初期，攻击主要以真实故障注入为主要方式，即“有损”攻击，这类攻击需要业务进行应急恢复，成本较高，导致攻击频率无法提升。针对这个问题，主要的解决思路是“无损”攻击思路的提出，即将攻击的目的进行拆解，有损攻击类似生产故障，需要先发现再应急，如果将发现和应急二者拆分开来，

28、如果只检验发现（发现率也是更重要的指标），那就无需制造真实故障。例如，在资金核对的攻防上面，有损攻击发生在业务系统，会真实篡改业务数据，而无损攻击发生在资金核对系统，篡改的是核对系统消费的数据（该数据可以认为是真实业务数据的副本），这是与业务主路径无关的一条旁路，注入核对系统不会对业务产生影响，业务也无需应急，这种注入主要检验核对系统中的核对规则是否有效，以及核对系统本身是否有问题。第二，无损攻击的真实度不够，有些复杂场景也不能通过无损攻击实现，解决这个问题的思路主要是依赖仿真环境的建设，仿真环境与生产环境高度相似，但应用和数据都与生产环境进行隔离，这个环境特别适合进行真实故障注入，目前很多复

29、杂的业务攻击场景都是在仿真环境完成的。第三，无损攻击会产生很多告警，对业务开发测试人员的打扰严重，解决这个问题，有两个思路，第一是对无损攻击的链路进行改造，监控能够区分出异常来源，对来源于攻击的异常进行告警屏蔽；第二，也是一个创新的思路，是建设混沌靶场，将针对通用防线的无损攻击，转移到靶场进行，靶场会在“实验创新点”中详细叙述。 六、 实验创新点 （一）面向软件完整生命周期的混沌工程软件完整生命周期包括开发测试，发布，运行，数据等多个阶段，每个阶段都会产生技术风险，蚂蚁在每个阶段都有技术风险的防控工作，因此要求混沌工程也能够覆盖到每个阶段。具体包括：开发阶段，进行源代码级别的故障注入，在源代码

30、中增加注入代码，目的是检验 code review 是否做的足够充分和细致。测试阶段，进行测试用例级别的故障注入，修改测试用例目标方法入参，检验测试用例是否会因为入参的变化而失败，从而检验是否有断言(不写断言，测试用例总会通过，有风险)。发布阶段，发布本质上是一种变更行为，在这个阶段进行的是针对变更的故障注入，蚂蚁技术风险建设有统一变更核心，通过各种变更防御规则对有风险的变更进行拦截，变更故障注入模拟不符合规则的变更，例如模拟一个发生在中午 12 点的变更(12 点属于午餐时间段，业务高峰期，本来不允许变更)，检验相应的变更防御规则是否能够拦截该变更；或者模拟变更导致的系统故障，检验变更核心是

31、否能够发现该故障并关联到正确的变更，并将该变更回滚；另外，变更影响面(变更影响的服务，变更影响的资金表等)也是风险挖掘的主要方向之一。运行阶段，包括系统稳定性和可用性的故障注入，以及面向业务的故障注入。前者例如服务异常，数据库超时，后者例如资金表数据篡改，业务代码逻辑篡改。数据阶段，在线运行的系统，产生的数据会周期性同步至离线，离线进行加工处理之后的数据，又会被一些在线系统使用，在这个过程中也会进行故障注入，例如在离线数据同步发生延迟，数据计算过程中出现数据错误和丢失，等等。（二）面向业务的故障注入由于蚂蚁的业务大多具有金融属性，对业务正确性的要求极高，对资金相关故障是零容忍的。根据内部数据分

32、析，蚂蚁的生产故障跟资金相关的，多数为业务内部逻辑错误导致，某些逻辑错误在测试阶段难以发现，发生的条件极其复杂，因此对该类型故障的设计，就必须紧贴业务进行。面向业务的故障注入，基于蚂蚁自研的统一 JAVA 字节码框架 Awatch，在技术上能够做到 JAVA 应用的代码级替换注入，即用故障注入设计的代码片段，在系统运行过程中，动态替换掉业务原本运行的代码片段，从而达到非常灵活的业务逻辑层面的错误。例如，运用此技术，可以实现修改方法的参数和返回值，跳过方法内部某些关键操作，重复执行某些操作，打乱操作的顺序，等等。 （三）混沌靶场混沌靶场是指在生产环境中自建的一套小型分布式系统，专门用于在生产环境

33、进行故障注入。混沌靶场提出的主要考虑是，目前蚂蚁技术风险的各种防线，大多为通用防线，即提供各个业务通用的防御能力，例如高可用领域中的服务限流，通用定位(服务异常定位等)，通用变更防御(通用防御规则)，等等，这些能力不因应用系统的差异而发生变化，因此没有必要一定通过注入业务系统对其进行检验，靶场系统接入这些通用防御能力之后，通过注入靶场系统也能够达到相同的检验目的，同时不会因故障注入而影响业务，也不会因高频的故障注入产生大量告警而打扰开发测试人员。 （四）污点分析技术污点分析作为一种经典的信息流分析技术，可以追踪指定的关键数据字段在程序中的传播和流向。通过指定关注的数据(source)作为污点，

34、分析该数据字段是否在程序中可以传播到指定的终点(sink)，此技术主要用于混沌工程中的风险挖掘领域，在该领域，资金服务和消息到达资金表的路径是关键挖掘目标，通过污点分析技术，可以准确识别出资金表的字段的源头对应的服务和消息中的参数，进而为面向业务的故障注入提供丰富的攻击场景（修改服务和消息的关键参数）。 七、 实验收益 在 2021 年，通过混沌工程发现的业务风险和问题有 300 多个，推进解决的有 200 多个；日常红蓝攻防次数有几十万次，涵盖高可用，资金安全，研发质量等领域，混沌工程的服务覆盖到蚂蚁所有主要业务，核心业务单元的技术风险防控保持较高水位（例如核心业务变更防御率达到 90%以上

35、，核心业务指标异常的监控发现率达到 99%以上，资金一致性核对的发现率达到 90%以上）；大型活动如 1218 牵引资金核对规则部署新增 1000 多条；诞生自混沌工程的统一 JAVA 字节码框架 awatch，不仅服务于混沌工程，而且扩展到其他业务领域，包括仿真环境、安全切面、业务巡检等，有效解决了业务遇到的问题。 八、 反思及改进 混沌工程智能化程度不够，目前需要人参与的比例较高，主要集中在场景构建方面，专家经验转化为场景需要大量人力投入，未来需要结合数据和算法，采用泛化的方式，提升智能化场景构建的水平。风险挖掘的结果准确性不足，需要较多人为打标的修正工作，未来在技术上需要有所突破，数据和

36、算法的使用需要更加有深度。混沌工程平台使用门槛较高，部分故障注入的配置较为复杂，需要不断降低学习成本，提升使用体验，提升易用性。基础设施建设例如仿真环境还需要加速，部分业务由于环境的制约，无法大规模的进行混沌工程实践。大型活动的人力时间投入较多，主要体现在活动的故障场景设计方面，需要加强日常面向业务的红蓝攻防，提升大型活动的举办效率。3. 腾讯云：混沌工程对于云计算服务应用案例一、 申报单位 深圳市腾讯计算机系统有限公司。二、 案例简介 腾讯云混沌工程旨于为客户提供适合各业务环节的混沌工程实践解决方案，集成数百余故障注入原子能力，并采用混沌工程全生命周期的管理方案形式进行整体管控，满足客户开展

37、常态化混沌工程实验需求。腾讯云混沌工程共累计实战演练万余次，发现并排查系统隐患故障，助力客户系统优化系统高可用性架构，有效地减少系统故障出现次数，降低系统故障影响时长，提升客户系统的运营质量。三、 用户简介 腾讯云，腾讯集团倾力打造的云计算品牌，面向全世界各个国家和地区的政府机构、企业组织和个人开发者，提供全球领先的云计算、大数据、人工智能等技术产品与服务，以卓越的科技能力打造丰富的行业解决方案，构建开放共赢的云端生态，推动产业互联网建设，助力各行各业实现数字化升级。 四、 需求分析越来越多的业务选择基于云原生技术构建系统架构，在云原生架构迁移的过程中，混沌工程可以助力构建容错性好、弹性可扩展

38、的云原生系统。在这种时代背景下，混沌工程开源协同联合协同团队与腾讯学院通力打造混沌工程系列课程，帮助业务了解混沌工程的思想和原则，并分享在不同的业务场景下如何实施落地混沌工程，为希望通过混沌工程来提升系统韧性的业务提供指引和帮助。随着腾讯云的规模越来越大，无论是基础设施还是产品架构都越来越复杂，出现故障的风险也越来越大，希望有个系统能够：持续发现云产品服务的故障隐患，优化服务架构；持续检验云产品服务应对解决故障的能力；持续检验腾讯云监控告警及服务自恢复的能力。腾讯云混沌工程正是因这个背景，通过主动注入故障，提前发现潜在问题，迭代改进架构和运维方式，最终实现业务韧性。五、 技术方案介绍（一）混沌

39、工程整体技术框架图用户在通过云 API 的形式访问的混沌工程平台，通过网关过滤掉非法的请求内容。由平台根据用户的权限提供相应的功能。用户的故障演练任务数据存储在数据库，故障注入整个流程采用的异步事务处理流程。服务端会创建演练数据，通过消息队列产生故障注入消息。动作库在监听到消息内容后，通过数据库获取到故障注入参数后，通过与 Agent 探针的通信通道，下发故障到目标机。在执行完成后，动作库更新任务状态，完成整体的故障注入过程。图 6 混沌工程整体技术框架图 （二）基础设施支持情况目前混沌工程平台已支持物理机、虚拟机、Kubernetes(K8s)、关系型数据库（MySQL）、负载均衡器(CLB

40、)、非关系型数据库（Redis）等资源的故障注入能力。 （三）故障注入原子能力（共 200+故障原子能力）物理机、虚拟机CPU 负载、IO 负载、主机重启、内存负载、文件删除、时间偏移、磁盘填充、网络压测、网络限速、网络丢包、自定义 Shell 脚本、网络访问不可达等；Kubernetes容器：CPU 负载、网络延迟、域名访问异常、网络丢包、删除容器等；Pod: 网络延迟、网络丢包、删除 Pod、磁盘 IO 负载、磁盘满载等；关系型数据库(MySQL)主从实例不可以达、主备切换、设置最大连接数等；非关系数据库（Redis）主备切换、主备节点不可用等；负载均衡器（CLB）集群宕机故障、外网 IP

41、 封堵等。 （四）实验流程管理方案目前采用混沌工程全生命周期的管理方案形式，将生命周期分为事前、事中、事后三大部分进行整体管控。事前：由产品架构师根据现有的产品架构提出基础设施故障假说，明确演练的爆破顺序编排、爆破范围、人员安排。然后在混沌工程中创建演练计划，通过演练计划自动通知相关人员，同步整体的演练计划方案。事中：创建演练，根据演练计划的内容一键生成演练任务，由运维人员根据整体方案的部署内容以及爆破目标的类型设定护栏阈值，确保控制影响范围。配置稳态监控指标，方便及时了解相关目标的数据指标波动情况。演练审批，运维人员在执行前需要通过相关机器负责人审 批授权，方便相关人员在第一时间知晓自身所负

42、责的机器要进行演练。演练执行，执行人员根据配置的执行模式（手动或者自动）进行操作进行故障注入。观察稳态指标，验证产品对于故障的反应是否符合预期。执行完成故障注入后，通过恢复动作移除故障，进行稳妥恢复。事后：总结复盘：根据本次演练的执行结果进行总结复盘。然后创建相应的改进事件督促产研方进行容灾能力提升。演练报告：将事件的全流程形成大屏报告，发送给相关人员了解本次演练的全流程。 （五）实施遇到问题及解决思路问题：涉及的产品较多，其中包含了公司的重点产品。产研方出行安全的考虑，没有深度参与混沌工程的使用。解决思路：第一，成立混沌工程推广专项。从上到下推广混沌工程全流程管理方案理念，设定各个产品的使用

43、目标；定期组织内部分享会，协助产品方正确的使用混沌工程平台。第二，提出准生产模拟方案，利用产品方的准生产环境进行混沌工程爆破实验，降低在生产环境的爆破风险；对于未构建准生产环境的产品，利用容器能力，混沌工程平台快速根据用户提供的配置文件构建沙箱环境，然后进行实验。 六、 实验创新点云上产品存在几个特点：底层依赖多、迭代快、多地域部署，针对这几个特点，腾讯云混沌工程平台做出创新的解决方案：结合网络管理部门，实现快速探查目标机器的组件依赖能力。通过混沌平台的扫描工具，输入目标的域名，在 10 分钟内完成整体架构的扫描。从而解决产品方在构建准生产环境时，需要大量人力来梳理复杂的组件依赖关系。配合内部

44、的 DevOps 研效工具，以插件形式切入到持续部署（CD）流水线中。提高测试人员使用混沌工程的效率，从原先的半小时提高 到 10 分钟（在混沌工程的构建与使用上所耗费的时间）。极大的减 轻测试人员在验证准生产环境的工作量。组建虚拟组织，从上至下的推到混沌工程的使用落地。以纵向方式传递混沌工作全事件管理理念，以及混沌工程实施的好处；以横向方式组织混沌工作案例交流会，让各云产品相关人员针对混沌工程实施经验进行横向交流。内部设定产品的混沌工程成熟度评级制度，对于优秀的云产品进行嘉奖；对于成熟度低的产品制定辅导推进计划，协助相关负责人推进云产品使用混沌工程平台。 七、 实验收益为腾讯云提供适合各业务

45、环节的混沌工程实践的解决方案，满足业务测试日常的混沌试验，提高分布式系统的弹性与韧性，建设了腾讯云混沌工程项目和混沌演练平台项目。腾讯云混沌工程项目截止目前覆盖 30+云产品，共累计实战演练万余次，发现并排查掉了发现并排查系统隐患故障，助力客户系统优化系统高可用性架构，有效地减少系统故障出现次数，降低系统故障影响时长，提升客户系统的运营质量。同时，在一个月内结合内部混沌工程最佳实践从 0 到 1 建设并上线了腾讯云混沌演练平台产品，目前已接入多家大客户，助力客户双活架构改造，提升腾讯云对客户的支持效率。 八、 反思及改进反思：混沌工程在内部体系下的实施与云上协助用户实施效果存在较大差异，云上混

46、沌工程产品效果低于预期。协助用户在企业内部进行混沌工程的实验主要通过自上而下的推行，用户的成员可以快速的响应政策，加入到混沌工程使用的队伍中。但是协助用户构建云上混沌工程产品时，因为大部分客户还 处于一个观望和测试阶段，难以将较为真实的场景进行混沌工程实验。改进措施：协助用户举办线下活动。以行业范围来划分客户群体，协助用户对客户进行混沌工程理念的宣讲与沟通；提高用户的混沌工程产品在行业内的影响力。协助用户将相关培训资料定期通过线上课程、论坛、博客等形式推广产品，提高客户对于用户产品的认可度。 4. 京东科技：京东云全平台破坏演练一、 申报单位 京东科技信息技术有限公司。二、 案例简介 随着云计

47、算被各行业广泛应用并成为关键基础设施，云的稳定性越来越重要。政务、金融、互联网、制造、能源等各行业逐渐将核心业务和数据部署到云上，如何评估及保障云产品特别是云平台整体的稳定性是各家云厂商必须面临和解决的问题，也是已上云、有上云计划企业关注的核心问题。为了评价和提升云平台面对失控情况下的抗脆弱能力、建立产品 信心，京东云需要落地混沌工程中更为复杂的业务场景，即全平台阶 段性验收大演练，涉及全平台、全系统、大规模下的复杂场景。一方 面验证系统在各类真实故障场景下的表现，并对问题加以分析和优化，使得系统的“抗脆弱性”持续增强，同时提高云产品的稳定性，进而 提高服务可用性 SLA。本案例主要描述了京东

48、云全平台破坏演练场景下的解决方案和落地效果。通过多年的京东 618、双 11，以及 2022 央视春晚的磨练，京东 云成为混沌工程的领先实践者和受益者，从单业务场景故障到整机房 故障宕机，京东云完美通过各类复杂场景考验。作为最懂产业的云，京东云将积极在混沌工程领域的探索，并持续输出京东云的成功经验，助力产业数字化过程中 IT 系统稳定性的持续提升。 三、 用户简介 京东科技集团是京东集团旗下专注于以技术为产业服务的业务子集团，致力于为企业、金融机构、政府等各类客户提供全价值链的技术性产品与解决方案。依托人工智能、大数据、云计算、物联网等前沿科技能力，京东科技打造出了面向不同行业的产品和解决方案

49、，以此帮助全社会各行业企业降低供应链成本，提升运营效率，成为值得产业信赖的数字合作伙伴。京东云（JD Cloud）是京东科技旗下的智能技术提供商，依托京东集团在人工智能、大数据、云计算、物联网等方面的业务实践和技术积淀，打造服务于数字企业、数字政府的多维场景解决方案。 四、 需求分析 为了评价和提升云平台面对失控情况下的抗脆弱能力、建立产品信心，京东云需要落地混沌工程：验证系统在各类真实故障场景下的表现对问题加以分析和优化，使得系统的“抗脆弱性”持续增强提高云产品的稳定性，进而提高服务可用性 SLA 在具体的落地中，方案需要支持两种场景：CICD 场景，单产品单系统的故障注入和演练，确保单系统

50、、或少量产品组合下的抗脆弱能力。此场景主要覆盖：资源占满、进程异常、网络延时、实例切换等场景。全平台阶段性验收大演练，关注全平台、全系统、大规模下的复杂场景。 五、 技术方案介绍 （一）演练目的：主动发现公有云稳定性风险，提前加固，模拟严重故障，需要全平台一起联动的场景。验证故障发生时，各产品：可用性(SLA 偏移及损耗)、报警及时性、预案有效性、MTTR、人员操作熟练度等。（二）演练环境：由于是全平台严重故障模拟，在当前情况下为避免在生产环境爆炸半径过大导致产生重大影响的线上故障，本次云平台整体故障演练是在公有云仿真环境进行。为更真实的模拟生产环境，演练前需要对仿真环境进行治理和必要的准备：

51、模拟京东公有云某区域多可用区部署参演产品根据特点进行跨 AZ、AZ 内高可用部署明确所部署产品与对应物理机资源、虚拟机资源的对应关系各产品留足资源冗余水位，确保满足自愈、稳态验证等需求各产品部署版本大于等于生产环境版本将服务间依赖信息作为基准数据设计有一定云产品覆盖度的业务场景，例如电商场景、物流场景等对业务进行大并发压力准备资源稳态和业务稳态监控准备仿真环境概况：（三）演练流程：图 7 京东云平台仿真环境 稳态指标：图 8 京东云全平台故障演练流程 为实现在演练过程中实时、全局观测各产品稳态，需要在演练前做好稳态监控的配置。京东云云泰故障注入与演练平台提供了强大的稳态监控能力，包括云资源稳态

52、(SLI 实时探测、SLA 损耗分析)和业务稳态两大部分。云资源稳态示意图：采用云所承诺的 SLA 算法，对每一个云资源实例进行可用性主动探测。通过实时对 SLI 和 SLA 偏移量对比，评价故障对云资源可用性的影响。业务稳态示意图：图 9 云资源稳态示意图 支持配置任意协议及自定义脚本，支持调试。首屏实时观测云平台所有产品当前的整体稳态情况，次屏可观察产品各监控项的成功率和耗时以及失败日志。图 10 业务稳态示意图： 通过压测结果反馈稳态变化： 图 11 压测结果观测稳态变化 （四）演练场景编排：本案例目标是模拟会影响整个京东云的严重故障，爆炸半径较大，期望在严重故障场景下发现各产品稳定性风

53、险。梳理了内外部容易发 生的严重故障，结合内部实际需求，制定了主要故障场景和预期结果 如下表： 表 1 主要故障场景和预期结果 京东云云泰故障注入与演练平台的基础资源故障可很好的支持虚拟路由、虚拟交换机、柜顶交换机以及普通服务器的开关机、数据库无法访问、DNS 服务不可用等故障，自定义故障类型可支持专线网络到骨干网不通和恢复的模拟。（五）演练场景执行和问题分析定位在全平台大演练中，对参与演练的同事进行了角色划分，各角色在演练过程中按照如下分工协同作战，完成各故障场景的演练执行以及问题分析定位。图 12 演练场景执行和问题分析定位 （六）演练总结演练结束后，从以下几个方面进行了总结：复盘演练全过

54、程，总结得与失；各演练 case 是否满足预期，如不满足预期，明确根因及待解决项；故障发生时各产品监控报警是否及时准确、预案是否有效等；服务依赖情况校准。（七）平台技术框架京东云-云泰故障注入与演练平台，基于混沌工程原理，通过故障的仿真和注入、结合业务“稳定状态”监控检验系统的健壮性和可用性。 图 13 云泰故障注入与演练平台技术框架 基础设施故障：CPU、内存占用、网络延迟/丢包、磁盘故障、杀进程等。K8S 故障：杀 pod、pod 资源占用类故障、pod 网络类故障、容器 remove、容器资源占用类故障、容器网络类故障、node 资源及网络类故障等。应用服务故障：数据库、Redis、ES

55、 延时和自定义异常，JVM类故障。自定义故障：主机宕机、开机、自定义 shell 命令、交换机等自定义故障。六、 实验创新点 组织云底座&100+云产品参与的云平台整体破坏性演练是非常有挑战性的，如何保证在一天的时间内有序完成多个严重故障模拟、实时评价各产品业务稳态、并同步定位和分析可能出现的高可用问题，需要在演练组织上、混沌工程平台功能上都有所创新。（一）创新的组织保障机制成立演练小组，明确总指挥和导演小组。总指挥负责总体把控演练启动宣贯、演练前各项工作的准备和治理、演练当天的各事项明确和推进。导演小组有多人，每人负责多个产品的具体事项跟进，如演练前的产品部署情况确认、高可用情况确认、稳态监

56、控和配置；演练中的产品稳态实时监控、问题定位和分析；演练后的问题梳理和待跟进项明确。 在本演练案例中，正是得益于总指挥的全局统筹、导演小组各成员的协调推进，加上各产品接口人职责明确，促成了本次大规模演练有序、按时、高质量的完成。创新的多视角稳态评价、故障根因定位云产品不是常规的接口类业务系统，每个云产品的日常监控能力和监控项都是分散在各个监控途径，且具体的监控项内容基本是不一致的。为了满足大规模演练时有统一的监控结果展示和问题定位的途径，混沌工程平台创新性的支持了：在平台进行各云产品的控制面和数据面监控项分别配置（支持任意协议、自定义脚本等）和调试。自动在混沌工程平台生成实时可用性趋势大屏，次

57、屏可展示详细监控项成功率和耗时趋势、异常日志追溯。次屏可以关联故障事件，能直观、精确的看到故障发生、恢复时，稳态的变化情况，满足一站式演练、实时的监控和快速的问题定位。综合多视角稳态评估：“业务稳态+资源 SLI 稳态+产品功能稳态+性能稳态”。（二）创新的云底座故障模拟方法通过自定义故障注入的方案，可自动化模拟主机宕机、开机、自定义 shell、交换机等故障。使深层次、大面积故障的自动模拟和恢复得以低门槛实施。七、 实验收益 “京东云全平台破坏演练项目” 积累了混沌工程在大规模、复杂场景落地实践的经验，提前发现了近 40 个风险和问题，验证了在机房、专线、机架、物理机、虚拟机、进程、依赖等故

58、障下，预案的有效性、监控及时性、流程适配性、人员熟练度，并获取了第一手 MTTR数据，进一步理清服务依赖，潜在风险挖掘，和风险影响范围，有助于制定下一步全平台稳定性改进方向和方案。得益于“京东云全平台破坏演练项目”的阶段性、持续性实施和迭代，京东云可用性大幅提升，其中云计算可用性提升至 99.995%，跻身世界一流云计算厂商行列。在细化指标上，京东云的故障数、MTTR大幅降低，故障提前发现率大幅提升。 八、 反思及改进 在故障演练过程中，个别被其他产品依赖的基础组件和产品在出现不可用问题后，分析、定位和解决的时间较长，影响了其他产品的 MTTR 数据有效性，需要针对此类产品在大演练前进行单项小

59、演练，最大程度避免此类问题在大演练时发生。为了识别此类组件和产品，需要对所有参演产品提前进行关键依赖梳理和验证。（未来改进工作项： Ring 环依赖识别和治理）本次演练中有多个产品出现了因运维人员对预案执行不熟练导致操作遗漏、操作错误的问题，为了避免此类问题在后续演练甚至线上运维时发生，需要提高各产品运维人员对预案，特别是较少发生的故障应对预案的熟悉程度，提高预案执行的效率和准确性。（未来改进工作项：定期演练，预案自动化率提升，故障自愈率提升。） 第二部分 银行领域 工商银行：工商银行混沌工程平台及混沌演练实践一、 申报单位 中国工商银行。二、 案例简介 本案例为中国工商银行在混沌技术领域三年

60、的研究实践分享。为提升“云计算+分布式”架构体系运行稳定性，中国工商银行于 2019年开始建设混沌工程故障演练方案，运用混沌工程技术，建设故障演练平台，形成涵盖系统、应用、容器三大类 100 余种故障演练能力，提供介质下发、压测发起、故障实施、环境恢复的自动化演练能力，形成常态化的故障演练机制。截至 2022 年 4 月，故障演练平台使用人员已超 700 人，落地 250 余个业务系统，累计超 1 万个演练案例。通过主动制造故障，帮助落地应用发现 400 余个高可用问题，提前预防平台系统性风险，并通过信通院可信云混沌工程平台能力评估最高级别“先进级”认证，成为业界首批且金融同业首家拿到最高级别