Tech
导读

本文从整体介绍了混沌演练的实践流程，读者可以通过本文了解到混沌实践的典型演练场景、重要考核指标以及风险控制方案等。

混沌工程介绍

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了

1.1 什么是混沌工程

混沌工程是通过主动制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段，简单说就是通过主动注入故障的方式、提前发现问题，然后解决问题规避风险。

1.2 为什么要进行混沌演练

随着互联网业务发展，微服务架构、分布式架构和虚拟化容器技术的广泛普及，软件架构的复杂度在不断提升，服务之间的依赖所带来的不确定性也成指数级增长，在这样的服务调用网中，任何一环出现的正常或者异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。目前营销体系的服务量级不断增加，整体链路增长以及数据流转复杂，对整个系统的可用性、稳定性挑战也越来越大，所以引入混沌演练，主动找出系统中的脆弱环节，然后针对性地进行加固、防范，从而避免故障发生时所带来的严重后果，进一步提升业务系统的高可用，提高业务系统应急保障能力。

1.3 混沌演练的价值

应用混沌演练可以对系统抵抗扰动并保持正常运作的能力进行校验和评估，提前识别未知隐患并进行修复，进而保障系统更好地抵御生产环境中的失控条件，提升整体稳定性。

图1 混沌演练的价值

混沌演练实践

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

2.1 演练流程介绍

目前借助京东云RPA自动化服务平台进行混沌攻防演练，测试人员为红方（攻击方），研发人员为蓝方（防守方），红方随机挑选一个时间段，针对服务系统注入故障（比如：CPU使用率达到100%、网络延迟、JSF接口响应延迟等），蓝方负责故障感知以及应急处理，通过这样的方式，达到针对系统高可用的应急演练。

红方：

创建演练计划：通过访问RPA自动化服务平台，进入工具市场——演练类，选择不同的故障方案，点击“立即执行”；

演练配置：点击执行后，进入配置页面，选择执行环境，选取要演练的应用，并随机选取要演练的实例IP；

执行演练：演练任务创建完成后，在对应的演练时间范围内，审批通过后，开始按照选择的演练任务开始执行；

蓝方：

故障排查：在演练过程中，蓝方通过报警信息，先对模拟故障的实例机器，进行排查；

恢复方案：演练中发现问题要及时恢复，演练后对模拟故障的实例机器进行重启恢复，确保机器正常运行，各项性能指标恢复；

图2 混沌演练平台介绍

2.2 初次演练实践

2.2.1 准备阶段

混沌演练准备阶段是设计演练策略，主要有设定演练的考核目标，选择演练的场景、应用和机器，生成相应的演练计划，周知相关人员。

其中准备阶段最重要的是做好风险评估，根据系统的等级或者混沌的成熟度，初期演练一些简单的事件比如高CPU、高内存；等系统抵抗力逐步提升演练比较高级的事件如网络延迟、进程终止等。

图3 混沌演练具体计划

2.2.2 执行阶段

演练场景执行，执行故障注入，测试人员应观察日志和系统监控，记录指标变动情况。

执行场景JSF接口响应延迟100ms，因接口超时时间为50ms，可以在监控图中看到故障注入期间接口超时失败率100%。

图4 混沌演练任务信息和监控信息

2.2.3 恢复阶段

故障发现及排查定位：演练进行中，蓝方事先不知道演练哪些故障场景（目前是通过预发演练，研发侧能明确受影响的机器），蓝方通过收到报警，对报警信息进行排查，摹略引擎系统针对报警信息做出反应和应急处理。

蓝方发现故障 CPU使用率负载故障，报警机器与演练机器相同，重启服务后，应用服务器响应正常，可用率恢复；

图5 演练应用告警通知

2.2.4 复盘阶段

通过本次演练，发现两个待优化的点：

1.CPU使用负载的演练场景，发现了监控告警邮件延迟，建议增加电话和咚咚报警策略；

2. 模拟JSF接口响应超时场景，发现缺少失败阈值告警邮件，增加相应告警邮件；

图6 增加的告警通知

混沌演练总结

3.1 典型演练场景

借助于平台进行混沌演练，可以降低演练的学习成本，提高演练的效率，目前平台对于常用的演练场景已经支持，大家可以在平台进入工具市场选择相应的演练场景。

图7 重点演练场景

3.2 重要考核指标

混沌演练结束后，需要根据演练执行过程和结果，记录演练流程和对应监控指标变化情况，总结存在的问题以及优化方案发出演练报告，对于演练中的关注指标主要是从故障“发现-定位-恢复”的时效性指标，下面具体介绍了在实践演练中需要重点关注的指标，如是否有告警监控、系统容错能力情况，以及响应机制，其中最后灰色部分高可用指标属于探索部分，会随着系统当前的实际情况和业务不同有变化，作为探索性指标。