混沌工程作为保障分布式系统稳定性的重要技术，已成为推动企业IT韧性系统建设的强大助力。目前，国内一些企业成功的落地了混沌工程，覆盖互联网、软件、银行、证券、通信、零售、能源等行业和领域。下面是中国信通院在混沌工程实验室的协助下，评选出来的首届“混沌工程先锋实践者”优秀案例，从中选择了3个典型案例：
1. 北京银行基于云原生、分布式架构自主研发的顺天技术平台以混沌工程为抓手积极推动数字化转型中的信息科技稳定性保障能力建设，通过技术创新驱动金融业务敏捷升级，进一步助力业务连续性水平提升，走出一条“敏稳双态”的金融科技创新发展之路。2021年北京银行在生产环境上云部署28套业务系统，其中分布式核心系统、柜员系统、网银系统等7套重要业务系统开展了混沌工程实践，混沌工程覆盖率达25%。工程实践模拟了175个带有银行业务属性的故障场景，在执行过程中所有场景的测试过程、验证过程、监控观测过程全部使用自动化工具完成，通过工具开发、自动化脚本开发、编排程序开发完成自动化能力建设，合计积累了70余个自动化测试场景、120余个程序脚本、18项自动化原子故障注入模型，为银行业务系统规模化故障模拟演练提供了自动化工具支撑
2. 2019 年，在平安银行PaaS平台的生产环境中，偶现高可用，高可靠等缺陷，造成中间件产品的不稳定。平安银行对PaaS平台进行了大量破坏性测试，覆盖了高可靠、高可用、可运维的大部分测试场景，在其后平安银行信用卡新核心A+ PaaS专项测试中，通过同时运用性能测试、破坏性测试、混沌工程方法进行了三轮测试，在测试环境和投产演练环境进行了充分的测试和验证，积累了丰富的分布式系统的破坏性测试经验。通过投产前执行三轮的混沌测试，案例合计2000+，提前发现了涉及PaaS、IaaS、SaaS层的不同类型问题总计30+个。
3. 2019 年，工商银行引入混沌工程，运用混沌工程技术，建成故障演练平台，形成涵盖系统、应用、容器三大类100余种故障演练能力，提供介质下发、压测发起、故障实施、环境恢复的自动化演练能力，形成常态化的故障演练机制，以夯实系统健壮性、提高应用架构的高可用能力。混沌工程在工商银行实践过程中体现出了其应有的目标价值，截至目前，日常使用混沌平台人员700余名，已落地300余个业务系统，累计超1万个演练案例，覆盖应用自隔离、同城双活、优雅启停等六方面生产常用重点高可用能力，帮助落地应用发现600余个高可用问题。
从这几个案例中，可以看到因为分布式系统的复杂性，导致混沌工程需要测试的案例非常多，从200个，到2000个，再到1万个都有。我们可以把IT系统可能发生的所有故障的集合叫做故障空间。
企业的IT系统可能有上百种应用，每种应用都是由多个微服务组成的，微服务之间互相依赖，微服务又依赖中间件和底层的容器、虚拟机或者物理机。从简单的SaaS、PaaS和IaaS的分层模型来看，大企业最上面的SaaS有上百个，中间的PaaS成百上千个，下面的IaaS也是成百上千个。
可以这样评估故障空间：
故障空间=SaaS应用个数PaaS中间件个数IaaS容器/虚拟机/物理机的个数
因此整个故障空间可能有上万甚至上十万的数量。所以采用复杂分布式IT系统带来的故障空间的膨胀。
分布式系统的故障空间这么大，要完全覆盖基本上是不可能的，投入的时间和成本是巨大的。因此落地过程中最重要的是对各种可能的故障进行识别后，还要对每个故障进行评估。只有准确的对每个故障进行评价，才可以分清故障的重要程度并确定需要预防和改善的优先级，才能提出并采取对应的应对措施。可以借鉴FMEA的失效模式评估与决策方法。
FMEA，中文译为潜在故障模式影响分析，是一种广泛使用的事前预防的重要定性分析方法。它针对某一产品的组件或某个过程，列举和探究其可能存在的潜在故障模式，并确定各个故障模式所造成的影响，以便进行事前预防和应对。FMEA最重要的作用是分析通过对风险度进行计算，从而对故障风险进行了量化，并提供了评定故障等级的标准。根据风险度数值的大小，对所有故障进行降序排序，就能够确定故障应对的优先顺序，为合理应对系统的故障提供依据，从而引导有限的资源优先去应对排名较高的关键故障。
如何评价失效模式的影响大小、需要引入“致命度”这一概念。“致命度”是用来评估失效模式所造成的破坏的指标。FMEA分析可以量化各类失效模式的致命度，并对其进行降序排序。在预防和改善时，只需重点预防和改善致命度较高、排名较靠前的失效模式。
计算公式如下：
致命度=故障严重度*故障发生度
公式中：
-
致命度是指故障所造成的破坏程度；
-
故障严重度指特定故障模式发生后对业务功能、经济性所造成影响的严重程度。此要素可以量化进行评价
- 故障发生度指特定故障发生的可能频度。此要素可以量化进行评价
致命度的数值越大，则该故障模式所造成的破坏越大，应对其进行预防和改善。算出各个故障模式的致命度以后，就可以对故障模式进行降序排序。通常情况下，排名前的故障模式引发的致命度占总致命度数值的80%以上，需针对前20%的关键少数采取预防和改善措施，效果较为明显。
下面以某银行的一个分布式应用为例，该应用涉及A、B、C、D四个服务，以及数据库和kafka的基础IT组件。
通过这种图，可以看到服务之间的调用关系：A服务调用B服务，B服务调用C服务，C服务调用D服务。也可以看到IT基础架构：该应用涉及四个应用容器，和数据库IP1，数据库IP2，数据库IP3，缓存服务器IP4。
梳理应用和IT基础架构的故障，这个应用的故障空间如下：
按照类型，统计故障的数量：
-
服务故障：A、B、C、D这四个服务每个服务可能发生9种故障，一共就是36种故障
-
数据库故障：IP1、IP2、IP3这三个数据库每个数据库可能发生4种故障，一共就是12种故障
-
Kafka故障：IP4这个kafka可能发生一种故障
这个分布式应用一共存在49种可能的故障。这么多故障如果都进行混沌工程，那么成本很高。如何对众多的故障进行评估，找到最有价值的故障？
根据FMEA致命度的计算公式，对例子中的A服务和B服务的故障进行计算（其他类似）， 如下：
可以看出A服务和B服务的故障类型是一样，但是每个故障的发生度和严重程度不一样，导致同样的故障所造成的的致命度是不一样的。对致命度排序后，选择排名前20%的故障，本文例子中的49个故障选取其中最关键的10个故障进行混沌工程，大幅减少了工作量。
本文使用FMEA评估故障，除此之外还可以使用STPA（Systems Theoretic Process Analysis）来进行自顶向下的评估。无论是采用哪种方法，混沌工程故障评估的能力，能够量化故障的影响，从而减少盲目的无效测试，提高混沌工程的效率；同时跟BCM业务连续性结合，确保对影响业务500万以上的故障进行全覆盖。实现混沌工程朝着自动化、常态化、降低成本的更高级目标发展。
