四步心法: 混沌工程不是灵丹妙药 | IDCF

混沌工程不是灵丹妙药，不会自动修复系统和解决问题。市面上有很多工具可以更轻松地实施混沌实验，但真正的困难在于对系统行为的预测。添加故障很容易，困难的是知道在哪里注入以及为什么要注入。换句话说，从混沌实验中获得的价值，取决于系统本身、对系统的理解深度以及建立可观测性的程度。本文将分享有关混沌实验的四步心法，帮助大家更快上手混沌工程。

一、混沌工程不是什么

“混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。”

但是，混沌工程不是灵丹妙药，它不会自动修复您的系统。事实上，甚至可能并不适用于您的任何情况。

一个常见的误解，混沌工程就是用来随机破坏系统。

这可能和名字有关系，Chaos Monkey(混沌猴子)是第一个在该领域获得业界声誉的工具，它在很大程度上依赖于随机性。随机性是一种强大的工具，并且有时与模糊测试有重叠。

但通常，添加失败都很容易；困难的是知道在哪里注入以及为什么要注入。

混沌工程不仅仅是 Chaos Monkey、ChaosToolkit、PowerfulSeal或 GitHub 上可用的众多项目中的任何一个。

这些工具可以更轻松地实施某些类型的实验，但真正的困难在于学习如何批判性地看待系统并预测可能存在的脆弱点。

另外，混沌工程不会取代已有的测试方法（例如单元或集成测试等），而是对已有测试方法的补充。

在碰撞测试期间，安全气囊可单独测试，也可与汽车的其余部件一起进行，混沌工程可以在不同的系统级别上运行和测试。

每个系统都不同，您需要深入了解系统的弱点，才能提出有用的混沌实验。

换句话说，您从混沌实验中获得的价值将取决于您的系统、您对系统的理解程度、您想要测试系统的深度以及您建立可观测性的程度。

尽管混沌工程的独特之处在于，其可应用于生产系统，但这并不是唯一场景。

网上很多混沌工程的内容似乎都围绕着“生产中的破坏”，很可能是因为这是您能做的最激进的事情，但同样，这并不是混沌工程的全部——甚至不是它的主要关注点。

因为，您也可以从混沌工程原理应用在其他环境中获得价值。

最后，混沌工程并非源于数学和物理学中的混沌理论。

二、什么是混沌实验

混沌工程实验（简称混沌实验）是混沌工程的基本组成，也是重要的表现形式，即通过一系列混沌实验进行混沌工程实践。

给定一个系统及其一定数量的系统特性，就可以设计实验来观察系统在发生故障时的种种表现。每个实验都专注于证明或反驳实验前对系统受故障影响的假设。

2.1 混沌实验的示例

例如，假设您运营着一个流行的网站，维护着整个数据中心。如何让网站在断电后仍可以正常运行？比如，在数据中心中安装了两个独立的电源。

理论上，这可以解决这个问题——但在实践中，仍存在着很多潜在的其他问题：也许电源之间的自动切换不起作用，亦或者网站的规模已经大到，单一电源无法为所有服务器提供足够的电力。

除此之外，是否每三个月有请电力工程师进行定期检查？

讨论到这里，您会担心。

好在，我们有混沌工程这个技术。设计一个简单的混沌实验，用科学的方式，通过实验说明当其中一个电源出现故障时系统会发生什么。甚至整个实验操作，可选择新进的实习生来执行这些步骤。

对所有电源重复以下过程，一次一个：

• 检查网站是否正常运行
• 打开电气面板并关闭电源
• 检查网站是否仍在正常运行
• 重新打开电源

这个过程很粗糙，听起来很简单，让我们再回顾一下这些步骤。

给定一个系统（一个数据中心）和一个系统特性（在单个电源故障时仍能工作），您设计了一个实验（关闭电源并观察网站是否仍在运行），若结果与预期假设一致，就会增加您对系统的信心。

不过（话锋一转），有一件事我们不能漏掉，即有必要问问如果这个实验失败会发生什么？

在这个过于粗略的实验中，您将自行制造故障点，这里就需要很谨慎，我们要最大限度地减少实验带来的风险，选择合适的环境来执行。稍后我们将对此进行更多介绍。

下图总结了您刚刚经历的混沌实验过程。

您会接着提出下一个问题：如果您正在处理更为复杂的系统，应该怎么办？

首先要对系统形成一个想要证明或反驳的假设，然后围绕该假设设计整个实验。

格雷戈尔·孟德尔，这位遗传学家，还记得吗？

当他对遗传规律有了假设时，设计了一系列关于黄豌豆和绿豌豆的实验，以证明显性和隐性遗传性状的存在。虽然，实验结果没有达到预期，事实上，这就是他在遗传学方面取得突破的方式。这和我们现在在讨论的实验方式很类似。

下面我们来仔细讨论一下混沌实验的具体步骤和注意事项。

2.2 混沌实验的四个步骤

让我们先简单捋一遍图上的步骤要点，后面会深入讨论。

• 实验结果的可观测性

无论是豌豆的颜色、假人碰撞测、网站是否正常运行、CPU负载、每秒请求数还是成功请求的延迟，第一步总是先确保，可以准确读取到这些数值。

自从有了计算机，我们可以轻松生成非常准确和详细的数据。这个我们称之为可观测性。

• 使用观测数据定义正常的状态

通过这种方式，您就可以了解系统行为在何时超出了预期范围。

例如，您可能希望应用服务器在工作时间内，平均 15 分钟的 CPU 负载低于 20%。或者，您可能期望在硬件参考规范中，四核应用服务器的实例每秒有 500 到 700 个请求。

这个正常范围被称为稳定状态，简称稳态。

• 利用观测数据验证直觉假设

直觉假设的一个简单例子，“杀死其中一台机器不会影响服务的平均延迟。”

执行实验，进行测量以得出您的假设是否正确的结论。有趣的是，您可能会喜欢犯错，因为那时您能学到更多的东西，然后继续实验，依次迭代。

• 实验越简单越好

您不会因精心设计的设计而获得加分，除非这是证明假设的最佳方式。

下面，让我们对混沌实验的四步骤进行更深入的探讨。

第一步 设置可观测指标

“可观测性”这个词，非常直截了当，这意味着能够可靠地查看您感兴趣的任何指标。这里的另一个关键词则是可靠。

硬件生产商或操作系统已经提供了读取各种指标的机制，从 CPU 的温度到风扇的 RPM，再到内存使用和各种内核事件钩子。

这里要小心的一点是，这些指标的采集器会影响指标的准确性。例如，您用来测量 CPU 负载的工具，其使用的 CPU 比您的应用程序多，那可能是一个问题。

如果您曾在电视上看过汽车碰撞测试，就会知道它既令人恐惧又令人着迷：一台1.5吨轿车加速到一个精心控制的速度，然后像纸天鹅一样撞击到一块巨大的混凝土。

但是，碎玻璃飞来飞去的高清慢动作镜头，几秒钟前坐在汽车中的假人看似没有受伤（并且没有受到影响），这不仅仅是为了娱乐。碰撞测试专家和混沌工程从业者都需要可靠的数据来断定实验是否有效。

这就是为什么可观测性至关重要，能够可靠地收集实时系统的数据至关重要。

第二步 定义系统稳态

有了上一步的可靠数据（可观测性），需要定义什么是系统稳态，以便可以识别异常。

观测指标将取决于您的系统和想实现的目标。它可能是“未损坏的汽车以 100 公里/小时的速度直行”，或者“99% 的用户可以在 200 毫秒内访问 API”。

通常，观测指标应直接由业务需求驱动。

让我们以进程的 CPU 使用率为例。听起来很简单，但在实践中，很多事情都会产生影响。

• 该进程是否获得了足够的 CPU？是否被其他进程窃取？
• 可能是共享机器，或者可能是cron在实验期间启动更新系统的工作？
• 内核调度是否将 CPU 分配给了另一个具有更高优先级的进程？
• 管理程序决定其他进程更需要 CPU？

按这种思路，您持续深入发掘问题。

好消息是，多次重复实验，能够发现一些其他影响因素，但是请记住，所有这些都可能会影响实验结果。

第三步 对事件提出假设

这一步，才是真正有趣的部分。

将您对系统行为的直觉，总结成一个可检验的假设——在出现明确定义的事件时，对系统行为进行有根据的猜测。

系统会继续工作吗？系统性能会受到影响吗？如果会，影响程度有多少？

在现实生活中，这些问题往往是由事件引发的，大致可分为以下几类：

类型	事件示例
外部事件	地震、洪水、火灾、停电等
硬件故障	磁盘、CPU、交换机、电缆、电源等
资源匮乏	CPU、物理内存、虚拟内存、磁盘空间、网络带宽等
软件错误	死循环、崩溃、黑客攻击等
虚拟机故障	意外重启、意外关闭、部署失败等
硬件错误	系统时钟错误、CMOS电池失效、内存校验错误等
人为错误	按错按钮、发送错误配置、拔错电缆等

模拟其中一些事件很容易（关闭机器以模拟机器故障，或者，拔出电缆以模拟网络问题），而其他事件则要难得多（为系统调用添加延迟）。

选择合适的故障，需要您对自己的系统有很好的了解。

以下是一些示例假设：

• 以每小时 100 公里的速度发生正面碰撞时，不会挤压到任何假人。
• 如果两个亲本豌豆都是黄色的，那么所有的后代都是黄色的。
• 如果 30% 的服务器被关闭，API 会在 200 毫秒内继续为 99% 的请求提供服务。
• 如果其中一台数据库服务器出现故障，仍将满足服务级别目标 (SLO)。

现在，是时候运行实验了。

第四步 运行实验并验证假设

最后，运行实验，观测结果，并验证假设。

请记住，假设被证伪，被打脸，一点问题没有——反而是令人兴奋的事！

• 如果假设是对的，恭喜！您刚刚对自己的系统获得了更多信心。
• 如果假设是错的，恭喜！您刚刚在客户发现之前，提前找到了系统问题，并且可以在任何人受到影响之前修复它！

请记住，只要这是一门好科学，您就可以从每个实验中学到一些东西。

三、结束语

混沌工程是一门在系统上进行实验以发现问题的学科，这些问题通常无法被其他测试技术发现。

这就像汽车行业所做的碰撞测试，试图确保整辆汽车在真实的事件中仍能以某种方式运行一样。

而混沌工程实验旨在引入现实事件来验证对上述汽车行为的假设。

混沌工程不会自动解决您的问题。

想要提出有意义的系统行为假设，需要您具有一定的专业知识。

此外，混沌工程不是随机破坏，而是事关添加可控数量的故障。

最后，混沌工程不需要很复杂。

刚刚介绍的混沌实验四步骤，应该能帮助您在事情变得更复杂之前走得更远。任何规模的系统都可以从混沌工程中受益。

来源：混沌工程实践 作者：宁远之

原文来源：Java Magazine

原文作者：Mikolaj Pawlikowski

标题：Introduction to chaos engineering, Part 2: Four steps for disrupting complex systems

声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

IDCF DevOps黑客马拉松👉 9月11-12日，上海站，11月20-21日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~公众号回复“黑马”加入