概述：为提升系统稳定性，和线上故障的触达、定位、恢复的速度，以及建立一套可执行、便于操作的特色的演练规范，并沉淀通用、可移植的演练规范，故发起了故障演练。

混沌工程不是一次性的实验，通过验证、改进和再实验，形成一种往复性的提升机制。根据混沌工程原则（PRINCIPLES OF CHAOS ENGINEERING），它在设计上强调了5大基本要素：

1.2 故障演练的意义

首先，我们的演练是从核心链路防劣化开始做起，防止日常迭代将核心链路和业务场景劣化掉。有几个前置工作：

按照前面所说的混沌工程5大基本要素，结合我的实验场景，我们按照以下4个步骤进行实验：

1、首先将“稳态”定义为指示系统正常运行的可测量指标

这里我们通过梳理一份核心链路回归case，用这份case做为系统“稳态”的可测量指标

2、假设这种稳态将在对照组合实验组中持续下去

对照组：没有注入异常前的系统。实验组：注入异常后的系统。我们假设稳态的那一份case会在两组都持续正常下去

3、引入反映现实世界事件的变量，如服务器崩溃、超时等

目前主要还只是做了宕机的事件引入，后续流程上和工具层面完善后，我们会继续加入类型超时、npe等真实事件进行实验

4、试图通过寻找对照组和实验组的稳态上的差异，来反驳第2步中的假设

通过对对照组和实验组的case的结果的差异，来反驳第2步中的假设。反驳的难度越大，我们对系统行为的信心就越大。如果发现了一个弱点，我们就有了一个改进的目标，在该行为在生产上整个系统中表现出来之前。

由于做的是防止劣化的混沌实验，以及目前的基础设施水平，我们在5大基本要素上，并没有严格的执行，比如说：

我们没有在生产上进行实验，目前我们也没有做到自动化的程度（不过也是在积极落地为自动化case中）。具体详情如下：

1、建立一个系统稳定状态运行的假设

这边我们通过梳理一份核心链路回归case，通过case全部运行通过，来证明系统稳定状态运行的假设成立

2、多样化的真实事件

目前主要还只是做了宕机的事件，后续流程上和工具层面完善后，我们会继续加入类型超时、npe等真实事件进行实验

3、在生产环境中进行实验

因为目前的情况是需要对核心链路的劣化进行控制，故我们需要将所有的非核心服务注入异常，通过对爆炸半径的分析，故防劣化的实验在测试环境进行

4、持续自动化实验

目前验证系统稳定状态运行的假设这一步还没有实现自动化（目前也是在积极落地为自动化case中），故我们目前是每个迭代人工持续的在进行防止劣化的实验，自动化这块目前还有很大的优化空间

5、最小化爆炸半径

最小化半径这块，我们将爆炸半径控制在非S1服务，控制实验期间不影响其他业务线的正常测试，并达到我们自己的实验目的的效果

这一块主要是为了提升线上故障的应急效率5-5-10（监控告警的时效、故障原因定位的效率以及止血、故障恢复的快速性）而做的实验。所以我们严格按照混沌工程的5大要素进行实验。

首先我们选取了可以建立假设“稳态说”的可以测量的系统输出--业务核心（用车领域关键节点）大盘指标和注入的场景相关的tps、error指标；

其次在真实事件多样化这块，我们选取了目前超时异常和非超时异常(npe)，来验证这两大类型的异常对系统稳态的影响；

第三，因为目标是应急，故我们的实验直接上到了生产进行；

第四，我们也是持续性、常规化的进行故障实验（自动化这一块，因为目前的进度、系统现状以及平台能力，暂时还不支持）；

第五，最小化爆炸半径，从选取异常注入场景上，我们每次选择范围在3个左右，并且会在测试环境提前做影响范围验证；从故障注入工具层面，通过流量标识，保证异常注入期间异常只会影响压测流量，不影响上线真实流量；

S1线下故障演练操作规范、流程机制

绿通系统故障演练操作规范、流程机制

故障演练团队分享(相关流程规范以及工具使用)