IT系统混沌工程实践 构建综合“演练”方案

文章来源：《华为云确定性运维案例集（稳定可靠篇）》

      随着IT系统业务规模逐渐扩大，系统复杂度不断增长，带来基础设施的大规模分布式演进。与此同时，微服务的增长和分布式系统相互依赖，错综复杂，导致系统故障发生的可能性增大，系统的潜在风险和承受能力、故障影响面未知。提升演练验证系统的高可用性和故障的快速恢复能力越来越重要。

      企业面临的挑战主要体现在以下方面：
      » 缺乏健全的流程：没有专业的运维工具和运维体系流程支撑。
      » 缺乏技术储备：运维复杂度高，缺少资源监控、容量评估、可靠性检查、演练等技术能力。
      » 缺乏演练经验：日常运维工作中，为保障环境稳定，不敢进行演练，担忧演练期间出现无法预知的故障，导致业务异常。

      为解决故障发生与恢复的不确定性，确保业务稳定运行，混沌工程解决方案通过一系列的演练流程和相关的工具支撑，解决演练落地实施难的问题。
混沌工程是通过主动向系统中引入软件或硬件的异常状态（动荡），制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段。

    1、故障模式识别

      针对混沌工程演练，总结出FMEA+五维故障场景分析法，来提升该平台的混沌工程成熟度。FMEA从故障模式和影响面分析，五维故障分析法从冗余、容灾、过载、依赖、数据备份五个维度进行，可以将该平台绝大部分故障场景基本覆盖。常见的故障场景，比如：CPU占用、磁盘IO高、多次杀进程、内存过载、网络包错误、文件损坏等等。

      2、演练风险分析

      对故障场景的风险等级进行评估分析，同时评估该场景的实施可行性以及优先级，识别出设计和部署中存在的潜在风险。分析应用架构，找出风险点。对常见的演练风险进行分析，排查思路的梳理，风险控制策略分析总结等。完善架构设计、应用部署文档，提前发现设计和部署中存在的明确风险。

      3、风险控制
      根据演练风险分析结果，进行演练前的风险整改，同时制定应急预案，在真实故障发生时，故障恢复“有法可依”。混沌工程与以往演练最大的区别是注入真实故障，所以要注意风险控制。

      4、故障注入
      设计故障场景的故障注入方式，并考虑演练的爆炸半径，演练异常时的及时中止手段，根据设计的故障注入手段进行故障注入，并验证故障注入方案是否成功。
针对风险分析的结果和应急预案，制定演练方案，进行故障演练。CDR演练系统提供自动故障注入能力。混沌工程与以往演练最大的区别是注入真实故障，这样才能真正模拟真实业务场景，在线验证业务可用性。

      5、监控与应急恢复

      在故障注入后，通过监控平台对演练对象监控指标覆盖度、完整度进行观测，包括注入故障时、检测、定位、恢复、隔离、降级等全链路的观测；在故障注入后，根据应急预案进行故障恢复。
      比如：故障注入后XX服务显示故障，其他服务正常；故障回滚后，XX服务恢复正常。故障注入后部分服务分钟级影响感受到SLI指标告警变红；云服务分钟级容灾切换后，SLI指标恢复。

      6、复盘改进

      对整个演练的过程进行总结，从技术方面发掘客户系统的薄弱点，从流程方面发掘流程的不足之处，输出演练复盘报告和改进事项。
      对演练中发现的问题，跟踪整改，举一反三，形成设计和部署的标准。混沌工程演练复盘改进，主要从以下场景展开：故障注入与回退、租户监控、服务系统监控、客户报障、演练和现网报障等。

      混沌工程演练是实现“确定性恢复”的重要手段，围绕故障发现、故障快速恢复等相关指标的测试及衡量，来构筑系统的快速恢复能力，驱动产品可靠性提升，提升系统动荡时的组织应急能力。
      实现流程优化，提升应急响应能力
      构建混沌工程的组织、流程、工具体系能力。流程持续优化，监控告警、事件、变更、问题、回溯改进流程联动集成。增强团队信心，验证稳定性措施有效性，量化团队价值。
      完善故障模式库
      系统性建立和持续更新故障模式库。未雨绸缪，利用演练应对未知故障，识别系统漏洞及潜在风险，及早闭环。避免因故障导致业务中断，节省总成本。
      扩大应急预案覆盖度
      不断完善应急预案的覆盖度，减少客户业务损失，让重大风险在可控范围提前暴露。检验故障切换、限流熔断、降级等策略以及预案是否有效。发现预案中存在的问题，增扩和完善预案。提高系统弹性，持续验证系统对极端场景的容错能力。
      实现故障快速恢复
      通过模拟各种故障和异常情况，提前发现故障，定界时长缩短70%，当故障发生后，发现时长（MTTI）控制在1分钟，定界时长（MTTK）为1分钟，止损时长（MTTF+MTTV）为2分钟，故障解决时长平均为4分钟，提升业务的连续性。

      为解决系统故障发生可能性大、系统的潜在风险高、故障影响面未知等问题，本案例通过故障模式识别、演练风险分析、风险控制、故障注入、监控与应急恢复、复盘改进等一系列措施，形成一套完整的演练方案，驱动产品可靠性提升，并提升系统动荡时的组织应急能力，构建混沌工程能力，助力企业提升业务的高可用性和稳定性。
      【名词释义】
      MTTI：Mean Time To ldentify，平均故障发现时间。
      MTTK：Mean Time To Know，平均故障认知时间。
      MTTF：Mean Time To Fix，平均故障解决时间。
      MTTV：Mean Time To Verify，平均故障修复验证时间。