作者介绍：
叶文宸，浩鲸科技云原生技术专家，开源 chaosBlade 社区贡献者，多年分布式系统架构和稳定性建设经验，致力于稳定保障(SRE)、IT蓝军建设和运维数字化提升。
前言
1、敏捷开发，DevOps 的稳定性痛点
随着业务规模的快速扩张，敏捷开发、DevOps 实践、云原生架构和治理的出现，极大地提升了应用交付的能力，缩短了业务上市周期。且与之带来的微服务治理复杂度呈指数级扩大，业务敏捷和技术迭代的难度也在不断加大，同时还必须保证业务持续的高可用性和稳定性，面对故障过去传统的灾备方式已无法跟上这个节奏。
减少故障的最佳方法就是用反脆弱的思路来管理故障，将故障发生视为常态，通过不断重复异常过程，持续提升系统的容错和弹性能力。混沌工程正是因应这个挑战，主动注入故障，提前发现潜在问题，迭代改进架构和运维方式，最终实现业务韧性。
2、混沌工程需求
混沌工程是一套通过在分布式系统上进行实验，主动找出系统中的脆弱环节的方法学，最早由 Netflix 及相关团队提出。它旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。2012年，Netflix 开源了 Chaos Monkey。今天，许多公司(包括谷歌，亚马逊，IBM，耐克等）都采用某种形式的混沌工程来提高现代架构的可靠性。
浩鲸科技在海量互联网服务以及当前爆炸式增长的流量场景实践过程中，沉淀出了包括，链路压测，流控管理，动态扩缩容，故障演练等高可用核心技术，并通过云上服务化、平台化和工具化的形式，帮助内部产品研发部门以及客户，提高开发效率，提升业务稳定性。
为了打通故障发现，故障管理，故障演练，应急响应等多方高可用措施，形成稳定性建设的完整链路。浩鲸科技组建 IT 蓝军，实施演练突袭，质量控制，联合作训。自2019年开始建设 IT 蓝军队伍，重点围绕生产环境，开展混沌工程实践，以推动代码、基础设施、流程、人员、监控上的提升。自今年起，深化演练力度，演练常态化、周期化，不断提高 SRE 单兵作战能力。
故障演练平台
1、搭建故障演练平台
基于这个指导思想，浩鲸科技决定建立故障演练平台，基于工具化故障注入和平台化故障演练管理来实现标准化，周期性的故障演练，从而提高产品韧性。
平台目标：
- 提供自动化，可视化，可编排，无侵入的故障注入能力；
- 作为高可用演练，故障测试的统一入口；
- 积累沉淀高可用测试用例，建立量化的稳定性评估体系；
功能目标：
- 适配目前JVM、CPP、容器化、K8S等故障场景；
- 故障注入自动化，具备故障生命周期管理能力；
- 故障爆炸范围可控；
- 故障注入类型具备良好的扩展性；
2、故障注入工具选型
目前业内模拟故障的工具比较多样化，支持的功能和场景也各有优劣。通过对比来看，chaosblade 支持功能和场景比较丰富，同时社区也是比较活跃的。我们在充分验证了大部分注入功能后，选择了它作为底层注入的核心模块。
混沌工程开源工具对比
3、故障演练步骤
结合 chaosblade 的混沌工程模型，我们将整个故障注入标准化，划分为五个步骤：
4、平台模块
作为故障演练的核心组件和故障注入引擎，平台的模块构建围绕服务业务演练展开。
故障演练
1、演练过程详解
我们实际实施故障演练时，涉及环境准备、故障注入任务编排、实施故障注入、故障复盘、问题改进等一系列操作。
- 演练方案确认
实施故障演练之前，确认实施故障注入的目标服务/节点，并确认纳入故障演练平台管理。确认故障实施的时间，地点，干系人，服务稳态，演练预期，观测指标及完整的演练执行顺序。
- 故障演练用例编排
基于高可用演练工具 HATT ，完成自动化演练任务编排、并实施演练全流程操作。
- 演练实施
通过演练工具监控演练全生命周期并获取演练结果。演练过程中出现的告警、监控异常，稳定性指标同步至演练执行结果，验证稳定性预期。
- 演练完结/复盘
基于故障演练平台输出当次演练结果，演练报告，基于指标分析输出演练问题复盘报告。
- 稳定性改进
基于演练复盘报告，确定稳定性改进建设方案，并跟踪执行。便于下次演练的故障回归。
故障演练用例则作为当前业务的建设资产沉淀在故障演练平台内，通用的还可予以复用。
2、从1-100
稳定性建设从不是一蹴而就的事，混沌工程旨在建设一个稳固的 PDCA 循环，促使 SRE 们在快速迭代的产品研发周期中不停验证，优化产品稳定性，跟上产品 DevOps 的脚步。而面临大量、反复、周期化的故障演练，标准化、自动化执行和演练过程固化沉淀成了提效利器。
在完成演练方案设计及对接后，利用平台，做到了单个 IT 蓝军即可完成全部自动化演练过程。
典型案例
验证消息队列单节点假死 hang 住时服务的可用性。
- 演练场景：
消息队列单个 Broker 节点 hang 住，验证消息收发是否正常。
- 稳定性预期：
单个 broker 异常不影响其他节点消息发送，故障节点将被排除出可用节点列表。短暂 tps 下降后，消息发送恢复正常 tps。
- 演练中稳定性异常：
节点 hang 住后，tps 骤降为 0，不符合预期；
- 改进成果：
1. 客户端引入熔断机制，消息发送重试失败后不再尝试往故障节点发送消息，避免了持续不可用；
2. namesrv 路由服务主动将 broker 失效信息推送至客户端，减少故障恢复时长。
浩鲸混沌工程实践
基于混沌工程实践，我们意识到，故障演练属于稳定性建设中的一环，而要做到稳定性提升，故障的应急响应处理是一个环环相扣的链条，任一环节的缺失，影响总体的稳定性质量。建立故障协同处理响应链还是一个长足发展的过程。
目前，我们在：
- 规划层面，推动故障演练能力分层；
- 平台层面，致力于打通架构感知及运维组件的联动协调；
- 制度层面，建立故障应急协同响应链；
- 演练实施层面，将故障演练从测试预生产环境向生产环境迈进；
- 积极贡献力量，回馈开源社区，随着底层注入工具chaosblade的蓬勃发展，引入更丰富的故障类型和灵活的注入方式。
以浩鲸科技内部混沌工程实践为例，对 30+ 重要产品线编排实施各种类型的演练，形成 月/季度 周期性故障演练累计 200+ 用例，以确保整个产品线能应对业务极端条件下的压力。全面提升开放平台应用服务水平，为浩鲸云系统架构的持续优化、产品的快速创新提供坚实支撑。
