AWS 云上混沌工程实践之可行性评估篇

自首篇《AWS 云上混沌工程实践之启动篇》发表之后，引起了大家的兴趣，不少读者发信讨论。为了更好地围绕混沌工程实践分享我们的知识和经验，特此成立了混沌工程专栏以飨读者。

我们在启动篇中谈到混沌工程的发展不是一蹴而就的， Chaos Monkey 开创了混沌工程的先河，从对基础设施的扰动（ EC2 实例随机终止 Chaos Monkey 、模拟可用区中断 Chaos Gorilla 、模拟区域中断 Chaos Kong 等），到利用应用网关控制爆炸半径，再到精细化流量配比以区分影响，直至引入断路器实现真正无人值守的混沌工程实验平台。本篇是混沌工程专栏的第二篇，笔者会探讨大家比较关心的第一个问题——为了能够成功实施混沌工程实验有哪些可行性要求：对实现对象的架构要求？对实验技术能力的要求？对实验工具的要求？还是实验可控性的要求？通常分析这样的问题，我们必须首先弄清楚混沌工程实验的目标。有了明确的目标，才可以深入地评估所做的混沌工程实验是否“可行”，能否“成功实施“。

混沌工程的目标 – 实现韧性架构

正如 AWS CTO Werner Vogels 常说的“故障是注定的，随着时间的流逝，一切终将归于失败”。我们必须接受故障发生是新常态的想法，处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个 EC2 实例的小型系统时，100％的健康运行通常是正常状态，故障则是一种特殊情况。然而，在处理大规模系统时，即 100％的健康运行几乎是不可能实现的。因此，运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务，这就需要架构本身具备 Resilient 能力。这里我并不想把“ Resilient ”翻译成弹性，而应该是韧性（具备恢复能力）。混沌工程就是利用实验提前探知系统风险，通过架构优化和运维模式的改进来解决系统风险，真正实现上述韧性架构，降低企业损失，提高故障免疫力。

韧性架构的重要特征

冗余性

架构的设计要增加冗余性，以便提高该系统的整体可用性。如在 AWS 云中，这意味着将其部署到多个可用区，甚至跨多个区域进行部署。

正如上图中所看到的那样，组件 X 的可用性是 99％（按今天的标准来说非常糟糕），但并行放置，增加冗余性，可以将系统的可用性提高到 99.99％！如果将三个组件 X 并行放置，那么就可以达到 6 个 9 的可用性！这个结果很惊人，这就是为什么我们总是建议客户跨多个可用区设计架构。

扩展性

架构的设计必须要考虑扩展性，即启用 Auto Scaling ，根据需求动态扩展资源 – 而不是手动执行 – 确保可以满足各种流量模式。如在 AWS 云中，可使用 Application Auto Scaling 功能为 EC2，DynamoDB 和 EMR 等服务提供相同的自动扩展引擎，以支持 AWS 外部服务的自动扩展。

不可变基础设施

不可变基础设施指的是，每次部署都会替换相应的组件，不做更新。应用部署则使用金丝雀发布（俗称灰度发布），以减少部署新版本应用时出现故障的风险。使用这种技术，可以在真实的生产环境中进行测试，并在需要时进行快速回滚。

无状态应用

无状态应用是自动扩展和不可变基础设施的先决条件，要求应用必须独立于先前的请求或会话，处理所有客户端请求，并且不会存储在本地磁盘或内存中。

避免级联故障

级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃（俗称蝴蝶效应）。架构设计必须考虑级联故障的处理方式：

• 转移切换：当一个集群宕机时，所有的流量都转移到另一个集群，如跨可用区切换，或者跨区域切换。

• 重试退避：指数退避算法逐渐对客户端重试请求减速，避免网络拥塞，同时添加抖动保证性能，详细讨论参看这里。

• 超时机制：过载请求会将连接耗尽，导致系统宕机。超时机制的引入，服务的质量会下降但不至于系统全面崩溃。

• 幂等操作：由于暂时的错误，客户端可能多次发送相同的请求，可能导致系统处理错误。幂等操作，一种可以反复重复的操作，没有副作用或应用程序的失败，可以消除上述隐患。

• 服务降级：当服务器压力剧增的情况下，有策略地减少或退化部分服务，以此释放服务器资源以保证核心任务的正常运行，如只读模式、停用耗时耗资源的功能等等。

• 拒绝服务：请求过载时，按优先级开始丢弃相应的请求。

• 服务熔断：若某个目标服务调用过慢或者有大量超时，直接熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回响应，快速释放资源，待目标服务情况好转则恢复调用。

基础设施即代码

基础设施即代码可减轻繁琐的手工配置和部署任务，由于可用完全相同的方式反复执行，因此解决了随时间推移引发的配置漂移问题，当有故障发生，基础设施的恢复快速且有效。同时可对基础架构以代码的形式进行版本控制，管理其更新、审核、验证和回溯分析。

弄清楚了混沌工程的目标，现在可以来深入讨论如何来评估混沌工程实验的可行性条件。

混沌工程的可行性评估模型

在执行混沌工程实验时，我们需有一个通用的标准来，判断这个实验可不可行，做得好不好。混沌工程的可行性评估模型，结合了亚马逊和 Netflix 的混沌工程成熟度模型，从成熟度等级和接纳指数两个维度来衡量混沌工程实验成功实施的可行性：

混沌工程实验的成熟度等级

成熟度可以反映出混沌工程实验的可行性、有效性和安全性。成熟度的级别也会因为混沌工程实验的投入程度而有差异。这里将成熟度等级分为 1、2、3、4、5 级进行描述，等级越高成熟度越好，混沌工程实验的可行性、有效性和安全性会更有保障。

混沌工程实验的接纳指数

接纳指数通过对混沌工程实验覆盖的广度和深度来描述对系统的信心。暴露的脆弱点就越多，对系统的信心也就越足。类似成熟度等级，对接纳指数也定义了 1、2、3、4 级进行描述。

混沌工程实验的可行性路线图

把当前项目进行成熟度等级和接纳指数的评估，将两者的结果合并放在一张图上，就可构建出类似于魔力象限的坐标轴。这不仅可以了解当前项目进行混沌工程实验的可行性，同时还可以与其他项目进行差异对比。此外，根据之前所讨论的混沌工程实验目标，设定想要达到的成熟度等级和接纳程度，便获得可行性路线图，了解自身努力的方向。

综上，本文是混沌工程专栏的第二篇，在此我们弄清楚了混沌工程实验的目标，并通过对混沌工程的成熟度等级和接纳指数的深入描述，探讨了如何通过上述可行性评估模型来衡量混沌工程实验的可行性、有效性和安全性。

作者介绍：

黄帅

亚马逊 AWS 专业服务团队云架构咨询顾问。负责企业级客户的云架构设计和优化、DevOps 组织咨询和技术实施。在软件研发领域有多年架构设计和运维、团队管理经验，对 DevOps、云原生微服务治理框架、容器化平台运维、混沌工程实践等有深入的研究和热情。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/aws-chaos-engineering-feasibility-assessment/