初识混沌工程

混沌工程探索

混沌工程介绍

背景

• 分布式系统越来越复杂，出现各种无法预估的异常行为，急需一种方案让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。

  分布式系统天 生包含大量的交互、依赖点，可能出错的地方数不胜数。 硬盘故障， 网络不通，流量激增压垮某些组件…。这 都是每天要面临的常事，任何一次处理不好就有可能导致业务停滞、 性能低下，或者其他各种无法预料的异常行为。

  在一个复杂的分布式系统中，我们单靠人力并不能够完全阻止这 些故障的发生， 而因该在这些异常行为被触发之前，尽可能多的去定位导致这些异常的、在系统中脆弱的、易出故障的环节 。

  识别出这些风险后，就可以有针对性的进行防范、修复、加固从而避免故障发生时带来的严重后果。

  混沌工程正是通过在系统基础设施上进行实验，主动找 出系统中的脆弱环节的方法学

  混沌工 程并非是简单地制造服务中断等故障。

  破坏系统和服务很 简单，但并不是全都可以有建设性地、高效地帮我们发现问题。

  混沌 工程存在的意义在于，能让复杂系统中根深蒂固的混乱和不稳定性浮 出水面，让我们可以更全面地理解这些系统中的固有现象，从而有根 据地在分布式系统中实现更好的工程设计，来不断提高系统弹性。

为什么需要混沌测试

• 混沌工程和传统测试的区别

  • 混沌工程和其他测试方法的主要区别在于，混沌 工程是发现新信息的实践过程，而故障注入则是基于一个特定的条 件、变量的验证方法

  • 实验和测试的重要区别

    测试中我们要进行断言：给定一个特定的条件，系统会输出一个特定的结果。一般来说，测试只会产生二元的结果，既验证结果是真还是假。可是这个测试过程并不能挖掘出系统未知的或还不明确的的认知，仅仅是对已知的系统属性可能 的取值进行测验。

    而实验可以产生新的认识，因为谁也无法准确预料，系统在实验过程中会产生什么反应，出现那些故障。在实验过程中我们会对复杂的系统有更加全面的认知。进而打造更具弹性的系统。

    它 和已有的功能测试、集成测试等测试已知属性的方法有本质上的区 别。

• 实时混沌工程的前提条件

  • 先解决掉已确定的异常会对系统造成的故障，使系统已经具备一定的弹性来应对真实环境中的一些异常事件。要不进行混沌工程实验将失去意义

  • 配套监控系统

    • 实施混沌工程的另一个前提条件是配套监控系统，需要用它来 判断系统当前的各项状态。如果无法对系统行为进行观察，就无法 从实验中得出有效的结论。

• 提高系统的韧性

  故障是注定的，随着时间的流逝，一切终将归于失败”。我们必须接受故障发生是新常态的想法，处在部分故障的系统正常运行是完全可行的。当我们处理多达几十个服务实例的小型系统时，100％的健康运行通常是正常状态，故障则是一种特殊情况。然而，在处理大规模系统时，即100％的健康运行几乎是不可能实现的。因此，运维的新常态便是接受部分故障。处在部分故障中的系统要求仍能正常运行对外提供服务，这就需要架构本身具备 Resilient 能力，这里的Resilient即为韧性（具备恢复能力）。

  混沌工程就是利用实验提前探知系统风险，通过架构优化和运维模式的改进来解决系统风险，真正实现上述韧性架构，降低企业损失，提高故障免疫力。

  • 韧性架构的重要特征

    • 冗余性。架构的设计要增加冗余性，以便提高该系统的整体可用性。

    • 扩展性。架构的设计必须要考虑扩展性，即启用 Auto Scaling ，根据需求动态扩展资源（ 而不是手动执行） ，确保可以满足各种流量模式。

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

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

      • 转移切换：当一个集群宕机时，所有的流量都转移到另一个集群，如跨可用区切换，或者跨区域切换。
      • 重试退避：指数退避算法逐渐对客户端重试请求减速，避免网络拥塞，同时添加抖动保证性能。
      • 超时机制：过载请求会将连接耗尽，导致系统宕机。超时机制的引入，服务的质量会下降但不至于系统全面崩溃。
      • 幂等操作：由于暂时的错误，客户端可能多次发送相同的请求，可能导致系统处理错误。幂等操作，一种可以反复重复的操作，没有副作用或应用程序的失败，可以消除上述隐患。
      • 服务降级：当服务器压力剧增的情况下，有策略地减少或退化部分服务，以此释放服务器资源以保证核心任务的正常运行，如只读模式、停用耗时耗资源的功能等等。
      • 拒绝服务：请求过载时，按优先级开始丢弃相应的请求。
      • 服务熔断：若某个目标服务调用过慢或者有大量超时，直接熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回响应，快速释放资源，待目标服务情况好转则恢复调用。

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

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

混沌工程原则

在实施混沌工程的过程中，并不是所有高级原则都必须用 到。但我们发现，运用的原则越多，你对系统弹性的信心就越充足。

请牢记以下原则，它们将有助于实验的 设计

建立稳定状态的假设

任何复杂系统都会有许多可变动的部件、许多信号，以及许多形 式的输出。我们需要用一个通用的方式来区分系统行为是在预料之内 的，还是在预料之外的。我们可以将系统正常运行时的状态定义为系 统的“稳定状态”。

• 定义稳定状态

  • 系统指标

    有大量的开源工具和商业工具可以帮助我们采集系统方方面面 的数据:

    CPU负载、内存使用情况、网络I/O，以及各类时序信息，例 如需要多长时间来响应一个Web请求，或者各类数据库的查询耗时。

    系统指标有助于帮助我们诊断性能问题，有时也能帮助我们发现 功能缺陷。

  • 业务指标

    现有的数据采集框架已经默认采集大量的系统级别指标，所以通常来说，让系统有能力抓取业务级别的指标比抓取系统级别 的指标更难

    ·我们正在流失用户吗? ·用户目前可以操作网站的关键功能吗?例如，在电子商务网站

    上为订单付款，或者将商品添加到购物车等。 ·目前存在较高的延迟致使用户不能正常使用我们的服务吗?

• 建立假设

  当你进行混沌工程实验的时候，应该首先在心里对实验结果有一 个假设

  没有一个预先的假设，你就不清楚应该从数据里 找什么，最终也难以得出有效的结论

  定义好指标并理解其稳定状态的行为之后，就可以使用它们来 建立实验的假设了。比如 当向系统中注入不同类型的事件 时，稳定状态的行为会发生什么变化。

用多样的现实世界事件做验证

每个系统，从简单到复杂，只要运行时间足够长，都会受到不可 预测的事件和条件的影响。例如，负载的增加、硬件故障、软件缺 陷，以及非法数据(有时称为脏数据)的引入 。
我们无法穷举所有可 能的事件或条件，但常见的有以下几类:

我们不需要穷举所有可能对系统造成改变的事件，只需要注入那 些频繁发生且影响较大的事件，同时要足够了解会被影响的故障域。

• 硬件故障
• 功能缺陷
• 状态转换异常(例如发送方和接收方的状态不一致)
• 网络延迟和分区
• 上行或下行输入的大幅波动以及重试风暴
• 资源耗尽
• 服务之间不正常的或者预料之外的组合调用
• 拜占庭故障(例如性能差或有异常的节点发出有错误的响应、 异常的行为、对调用者随机地返回不同的响应等)
• 资源竞争条件
• 下游依赖故障

在生产环境中进行实验

在离生产环境越近的地方进行实验越好。理想的实践就是直接在生产环境中进行实验。

• 状态和服务

• 生产环境的输入

  比如：系统是提供了一个从用户接收不同类型请求的服务，
  用户永远不会如你预期的那样与系统进行交互

  所以混沌实验很有必要在生产环境中对真实的输 入数据进行验证并实验。

• 第三方系统

  如果你的系统部署在云服务上，那么大量的你所依赖的、又不完全了解的外部服务的存在就是显而易见的。但 即使你的系统全都运行在自己的数据中心上，你也会发现在生产环境 中系统还是会依赖其他的外部服务，例如DNS、SMTP、NTP等。就算 这些服务都是自己部署的，它们也经常会需要和不受你控制的外部服 务进行交互。

  第三方系统在生产环境中的行为总是和在它与其他环境集 成的大环境中的行为有所不同。这进一步强调了在生产环境中进行实 验的必要性，生产环境才是你的系统和第三方系统进行真实交互的唯 一场所

• 生产环境变更

  系统一直在不断更新。开发者和自动脚本每天 都在通过不同的方式更新着系统，例如，发布新代码，更改动态配 置，添加持久化的数据，等等

• 外部有效性

• 不愿意实践混沌工程的说辞

  对系统的弹性具备一定信心的时 候再进行混沌工程实验
  已经看到了明显的薄弱环节，那么你应该首先专注于 提高系统在这一点上的弹性。当你确信系统有足够的弹性时，就可以 开始进行混沌工程实验了。

  在进行任何混沌工程实验之前，都应该先有一个用来立即终止实 验的“大红色按钮”(我们真的有一个大红色按钮，虽然是虚拟的)。 更好的方法是将这个功能自动化，当监测到对稳定状态有潜在危害时 立即自动终止实验。

• 离生产环境越近越好

  越接近生产环境，对实验外部有效性的威胁就越 少，对实验结果的信心就越足

自动化实验以持续运行

自动化是最长的杠杆。在混沌工程的实践中，我们自动执行实 验，自动分析实验结果，并希望可以自动创建新的实验。

• 自动化执行实验

  在理想情况下，实验应该随着每次的变化而执行

  在非理想情况下，在每年一次的演习中进行问题调查就很难，需要完全从零开始检查，而且很难确定这个潜在的问 题在生产环境中存在多久了。

• 自动创造实验

  自动创建实验想做的：找到那些本 不应该让系统崩溃的事件的原因，包括那些还从未发生过的事件，然 后持续不断地设计实验进行验证，保证这些事件永远不会导致系统崩 溃。

最小化爆炸半径

每一次的混沌工程实验 的确具备导致生产环境崩溃的风险。
混沌工程师的一项专业职责就是 要理解和降低生产风险，可以为实验设计良好的系统，以阻止大规模 的生产事故，将受影响的用户数量降到最少。

随时遏制和停止 实验的能力是必备的，这可以避免造成更大的危机

实验通过 很多方法来探寻故障会造成的未知的和不可预见的影响，所以关键在 于如何让这些薄弱环节曝光出来而不会因意外造成更大规模的故障。 我们称之为“最小化爆炸半径”。

混沌工程实验应该只承受可以衡量的风险，并采用递 进的方式，进行的每一步实验都在前一步的基础之上。这种递进的方 式不断增加我们对系统的信心，而不会对用户造成过多不必要的影 响。

混沌工程实践

设计实验

• 选定假设

  需要做的第一件事就是选定要验证的假设，比如，你最近发现在访问Redis时有超时报错的情况，于是你想确 保系统不会被缓存访问超时所影响。再比如，你希望验证主从数据库 配置，在主数据库故障时可以无缝切换到从数据库。

• 设定实验的范围

  选定了要验证的假设后，下一步需要做的就是设定好实验的范 围。这里有两个原则:“在生产环境中运行实验”和“最小化爆炸半 径”。实验离生产环境越近，我们能从实验中获得的收益就越大。虽然 这么说，但还是要仔细关注可能对系统和用户造成影响的风险。

  选定了要验证的假设后，下一步需要做的就是设定好实验的范 围。这里有两个原则:“在生产环境中运行实验”和“最小化爆炸半 径”。实验离生产环境越近，我们能从实验中获得的收益就越大。虽然 这么说，但还是要仔细关注可能对系统和用户造成影响的风险。

• 识别出要监控的指标

  明确了假设和范围之后，我们需要选定用来评估实验结果的指 标。要尽可能基于指标来验证假设。例如，你的假设是“即使主数据库出现故障，所有服务也都能正常运行”，那么在 运行实验之前，你需要清晰地定义什么是“正常”。再举个例子，如果 你有一个明确的业务指标，比如“每秒订单数”，或者更低级别的指 标，比如“响应时间”和“响应错误率”，那么在执行实验之前要明确定 义清楚这些指标的合理数值范围。

• 在组织内沟通到位

  当你第一次在生产环境中执行混沌工程实验时，你需要通知所在 组织中的其他成员:你将要做什么，为什么要这么做，以及什么时间 要做

• 执行实验

  准备工作都已经完成，是时候执行实验了!要盯住那 些指标，因为可能随时需要终止实验。

• 分析实验结果

  实验结束后，用“选定假设”一步中制定的指标数据来验证之前的 假设是否成立。

• 扩大实验范围

  你从小范围实验中获得了信心之后，就可 以逐步扩大实验范围了。扩大实验范围的目的是进一步暴露小范围实 验无法发现的一些问题。例如，微服务架构中存在少量的超时或许不 会有什么问题，但超过一定比例就可能会导致系统整体瘫痪。

• 自动化实验

  当有信心手动执行混沌工程实验之后，就可以开始周期性地自动化运行实验，持续从中获得更大的价值了。

混沌工程成熟度模型

混沌工程成熟度模型(CMM)给我们提供了一个评估当前混沌 工程项目成熟度状态的途径

CMM的两个坐标轴分别是“熟练度”和“应用度”。缺乏熟练度的时 候，实验会比较危险、不可靠，且有可能是无效的。缺乏应用度的时 候，所做的实验就不会有什么意义和影响

• 熟练度

  熟练度可以反映出，组织中混沌工程项目的有效性和安全性

  • 入门

    • 未在生产环境中运行实验
    • 全人工流程
    • 实验结果反映系统指标，而不是业务指标
    • 对实验对象注入一些简单事件，如“关闭节点”

  • 简单

    • 用复制的生产环境中的流量来运行实验
    • 自助式创建实验，自动运行实验，手动监控和停止实验
    • 实验结果反映聚合的业务指标
    • 对实验对象注入较高级的事件，如网络延迟
    • 实验结果是手动整理的
    • 实验的定义是静态的
    • 具有可以支持对历史实验组和控制组进行比较的工具

  • 高级

    • 在开发流程中的每个环节及所有环境中运行实验

    • 设计、执行和终止实验完全自动化

    • 将实验框架和A/B测试以及其他测试工具集成，以减少噪声干 扰

    • 可以注入如对系统的不同使用模式、返回结果和状态的更改等 类型的事件

    • 实验具有动态可调整的范围以找寻系统拐点

      通过不断扩大爆炸半径，即扩大流量和影响范围，找到例如雪崩 这样的问题的发生点，这类问题的发生通常都有一个临界点，用一两个单独的条件测试时一切都正常，但给予其一定的流量压力，或使用某些调用的组 合，就会引发问题，这个临界点就是拐点

    • 实验结果可以用来预测收入损失

    • 对实验结果的分析可以用来做容量规划

    • 实验结果可以用来区分服务实际的关键程度

• 成熟度

  应用度用来衡量混沌工程实验覆盖的广度和深度。应用度越高， 暴露的脆弱点就越多，我们对系统的信心也就越充足

  • 暗中进行

    • 对重要项目不采用
    • 只覆盖少量系统
    • 组织内部基本没有感知
    • 早期使用者偶尔进行混沌工程实验

  • 适当投 入度

    • 实验获得正式批准
    • 工程师兼职进行混沌工程实验
    • 多个团队有兴趣并参与进来
    • 一些重要服务会不定期地进行混沌工程实验

  • 正式采用

    • 有专门的混沌工程团队
    • 所有故障的复盘都会进入混沌工程框架来创建回归实验
    • 定期对大多数关键服务进行混沌工程实验
    • 偶尔进行实验性的故障复盘验证

  • 成为文化

    • 对所有关键服务进行高频率的混沌工程实验
    • 对多数非关键服务进行高频率的混沌工程实验
    • 混沌工程实验是工程师入职流程的一部分
    • 所有系统组件都默认要参与混沌工程实验，不参与的话需要进 行特殊说明

成熟技术

Chaos Monkey

Netflix 最早系统化地提出了混沌工程的概念，并出版了混沌工程领域内的首部书籍《混沌工程：Netflix 系统稳定性之道》，在本书中提出了混沌工程成熟度模型与应用度模型，并总结了五条高级原则，对于混沌工程的发展具有指导性意义。另外 Netflix 开源了其混沌工程项目 – Chaos Monkey。

ChaosBlade

阿里巴巴是国内较早开始探索混沌工程并做出开源的公司，其开源项目 ChaosBlade可以结合阿里云进行 chaos 实验。

• ChaosBlade 不仅使用简单，而且支持丰富的实验场景，场景包括

  • 基础资源：比如 CPU、内存、网络、磁盘、进程等实验场景；
  • Java 应用：比如数据库、缓存、消息、JVM 本身、微服务等，还可以指定任意类方法注入各种复杂的实验场景；
  • C++ 应用：比如指定任意方法或某行代码注入延迟、变量和返回值篡改等实验场景；
  • Docker 容器：比如杀容器、容器内 CPU、内存、网络、磁盘、进程等实验场景；
  • 云原生平台：比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景，Pod 网络和 Pod 本身实验场景如杀 Pod，容器的实验场景如上述的 Docker 容器实验场景；

Chaos Mesh

PingCap 作为国内优秀的数据库领域开源公司，其在混沌工程领域一直有投入，并在最近开源了内部混沌工程实践平台 – Chaos Mesh。

Gremlin 提供的混沌工程实验平台

Gremlin 为一家混沌工程商业化公司，该公司提供了一个混沌工程实验平台，通过将其 agent 安装在云主机上触发故障。同时提出了 chaos gameday的概念。