👉目录

1 为什么要做混沌工程

2 如何落地

3 成果

4 总结与展望

• 功能/程序缺陷：单元测试，集成测试，UAT 测试，流量回放；
  
• 容量不足：常态化压测，自动弹性伸缩；
  
• 人为破坏（人因）：去登陆 IDC，变更审核，权限控制，模块认证；
  

• 建立稳定状态的假设；
• 用多样的现实世界事件做验证；
• 在生产环境中进行实验；
• 自动化实验以持续运行；
• 控制最小化爆炸半径。

• 故障有效，注入的故障贴近实际发生故障环境；
• 业务安全，注入故障对现网业务无影响或者影响较低。

• 安全、有效的实验；
• 高效、全面的发掘风险。

考虑”数据篡改“类的故障，可能会导致写脏数据，尤其是篡改业务执行主体（如商户 ID、用户 ID）写脏真实业务数据的风险，因此禁止”篡改执行主体“的故障。

考虑执行的实验的风险，我们对这些场景加了审批：

• “修改”类的故障加审批。避免写脏异常影响真实环境，由leader二次评估确认。

• 非资源负责人执行审批。如对他人模块实验（模块混部对母机实验校常见），避免无法发现其它业务异常。

• 非工作时间实验审批。避免实验异常，干预时间长。

1. 实施的业务团队人力投入大：人工注入故障，人工观察、分析业务监控，以及监控偏离时是否影响业务、是否会扩散风险、是否有其他潜在风险；
2. 工具团队不能做到有的放矢，不能将有效的人力投入到最有价值的原子开发上来。

1. 实验对象从 高价值 往 低价值 覆盖。根据这个思路，得到了优先实施的模块。1）公共组件：RPC 框架、队列、存储 、缓存，安全认证、日志等；2）生命线业务：收付结退。
2. 基于高可用原则拆解，得到工具待开发的原子需求和待注入的资源。

• 单故障注入：18模块 * 15个故障原子 = 270个，即单原子无差别的注入次数；
  
• 2个组合空间为 C2270 = 36315，任一组合空间为2270。
  

• 模块内构成依赖关联影响（包括三园区容灾设计）；
  
• 业务内模块间依赖关联影响；
  
• 业务间依赖关联影响；
  
• 基础设施间依赖关联影响；
  
• 潜在依赖关联影响。

一个实验任务由4个部分组成：

1. 业务资产：集群、模块、接口；集群是多个模块的总称，如某个存储集群包括接入模块、存储模块、元数据模块；

2. 系统资源：业务资产执行所依赖的机器、容器、网络、CPU、磁盘、进程、文件、内存、共享内存等；

3. 故障类型：针对每种系统资源的有多种故障，如机器包括机器重启、机器时间错误等，如网络包括慢、丢包、乱序等。

4. 故障程度：除个别的像机器重启这类0-1类型故障，其它大多数涉及一定程度的故障，比如网络丢包30%，不同程度下的表现略有不同，一般将故障程度拆解成几档，如丢包有单机内10%、30%、50%、80%、100%，再组合多机情况。

一个实验，首先圈出所包含的业务资产，再整理出其依赖的系统资源（除了磁盘、文件、共享内存这几项，其它一般都包含），再展开系统资源的故障类型，最后确定故障程度，有两种策略：

• 标记资产类型，如标记为某类存储集群，则套用已设计过的实验模板库生成实验任务；

• 标记业务所适用的高可用原则，如单机/园区剔除能力、异常防御、分区切换、旁路冗余设计等，裁剪掉全展开的无效程度值，如单机剔除原则只容忍下游单机或单园区机器故障所以不生成多机故障，而做了旁路冗余设计的业务则容许旁路模块的所有机器故障所以生成单机故障的必要性就不大。

因此业务需要做的是：圈定资产范围及依赖的系统资源，并标记资产类型或适用于哪些高可用原则，便可自动生成实验任务。

自动执行

系统建设不是一蹴而就的，从手工执行到自动化我们经历了三个阶段：

• 手动执行单个故障，主要解决0-1的问题，主要精力放在故障原子建设上；

• 单次批量执行多个故障，采用 yaml 文件记录编排方式，支持串行、并行调度。应用于业务首次实验和定位问题。

• 定时执行/事件触发执行，主要用于变更回归和可用性巡检场景，因为定时执行也依赖后续的“自动分析”，所以放在最后。

自动分析

上述自动执行减少了“点击”操作的工作量，实验要”完全“自动化，还要结合自动分析，即自动判断是否偏离稳态。一是当稳态偏离正常范围及时停止，避免造成次生灾害；二是只有做到自动分析，才能低成本的“定时执行”，否则每次自动执行后都依赖人工分析，不可持续。

我们根据实验的时间(实验开始时间到实验结束后一个周期)，自动匹配与之相关的稳态告警：

• 业务：业务用例维度监控是否触发告警。强优先级，触发后停止实验。

• 模块：上下游调用关系是否出现告警。中优先级，触发后不停止实验，展示在实验报告中。

• IP/容器：机器和容器是否出现资源异常告警。中优先级，触发后不停止实验，展示在实验报告中。

• 业务自定义监控，上述无法自动覆盖的监控，由业务配置后自动收集。

发现的风险的除了负责人处理外，方法：

1. 个性问题：周知组件、业务负责人处理

2. 共性问题，通过 SOA 治理、架构模式化、完善研发流程等手段来大规模消除，达成组织价值最大化。

对不同时期出现的问题采用不同的策略：

• 存量：采用了 SOA 治理平台推动修复（SOA 治理是微信支付风险和异常项治理的平台，提供了统一的异常接入、展示、周知、跟进管理的指标数据，在部门内形成了统一的风险治理共识，以快速治理、收敛风险。混沌工程将发现的风险接入 SOA 治理平台，快速治理大面积的共性风险）。

• 新增：通过 MR 流水线门禁和变更门禁堵住新增，需处理后才能通过。

有效性和安全性始终是一个权衡取舍的因素，如前文介绍，微信支付在独立的混沌分区架构中实施，前期使用仿真流量，因此除篡改数据类的原子外，在控制请求量的情况下，注入故障的爆炸半径很小、对线上影响极低。

但出于业务安全的思考惯性，我们在建设故障原子时基本是按照演习的思路建设：先摸清组件原理，逐个组件/业务定制原子，导致前期交付周期较长。若在控制爆炸半径的基础上，开放更多故障注入的自由度，注入更多、强度更大的故障，可以低成本的发现更多有价值的风险。