1.3 混沌工程的四个步骤

混沌工程实验（简称混沌实验）是混沌工程的基本单元。你需要通过一系列混沌实验来进行混沌工程。给定一个计算机系统和一些你感兴趣的特性，你设计实验，看看当糟糕的事情发生时，系统是如何运行的。在每个实验中，你都专注于证明或反驳关于系统将如何受特定条件影响的假设。

例如，假设你正在运行一个受欢迎的网站，并且你拥有整个数据中心。你需要你的网站在断电时服务不受影响，因此请确保在数据中心中安装了两个独立的电源。从理论上讲，你解决了这个问题，但实际上，仍然有很多地方会出错。也许电源之间的自动切换不起作用。也许自数据中心启动以来你的网站已经发展壮大，并且单一电源无法为所有服务器提供足够的电力。你还记得每三个月付钱给电工做一次机器的定期检查吗？

你是否感到担心，实际上你也应该如此。幸运的是，混沌工程可以帮助你更好地入睡。你可以设计一个简单的混沌实验，以科学地告诉你其中一个电源出现故障时会发生什么（为获得更出色的效果，请始终选择新来的实习生运行这些步骤）。

对于所有的电源重复如下操作，每次只执行一个步骤：

1.检查网站是否正常。

2.打开电源面板，关闭电源。

3.检查网站是否正常。

4.重新打开电源。

这个过程很粗糙，也很显而易见，但是让我们回顾一下这些步骤。给定一个计算机系统（一个数据中心）和一个特性（能够在单一电源故障下存活下来），你设计了一个实验（关闭电源并查看网站是否仍在运行），以增强你对系统抵抗电源问题的信心。你利用科学为善，并且一分钟就搞定了。“这是一个人的一小步，却是人类的一大步。”

不过，在你沾沾自喜之前，值得一问的是，如果实验失败并且数据中心出现故障，将会发生什么。在这种出于演示目的过于粗糙的情况下，你将自己造成中断。你工作的很大一部分将是最大限度地减少实验带来的风险，并选择合适的环境来执行它们。这部分内容之后再说。

看一下图1.1，它总结了你刚经历的过程。在你回来时，我猜你的第一个问题是：如果你要处理更复杂的问题该怎么办？

与任何实验一样，你首先要形成一个你想要证明或反驳的假设，然后围绕这个想法设计整个实验。当孟德尔察觉到遗传规律时，他在黄豌豆和绿豌豆上设计了一系列实验，以证明显性性状和隐性性状的存在。他的结果与预期不符，这很好，事实上，他就是这样在遗传学上取得突破的。在整本书中，我们将从他的实验中汲取灵感，但是在我们进入设计实验的绝妙技术细节之前，让我们先播下正在寻找的想法的种子。

让我们放大图1.1中的这些混沌实验框之一，看看它是由什么组成的。如图1.2所示，该图描述了设计实验的四个简单步骤：

1.你需要能够观察你的结果。无论是最终豌豆的颜色、碰撞试验中假人所拥有的四肢、你的网站正在运行、CPU负载、每秒请求数，还是成功请求的延迟，第一步是确保你可以准确地读取这些变量的值。我们很幸运能和计算机打交道，因此我们可以很容易地得到非常准确和详细的数据。我们称之为可观测性。

2.使用观测到的数据，你需要定义什么是正常的。这样，当事情超出预期时，你能够知道。例如，你可能希望应用程序服务器在工作周内平均15分钟的CPU负载低于20%。或者，你可能希望在参考的硬件规格上，运行具有四个内核的应用服务器的每个实例每秒可以处理500到700个请求。此正常范围通常称为稳态。

3.你利用可以可靠地收集（可观测性）到的数据，将你的直觉塑造成一个可以被证明或被反驳的假设。一个简单的例子是“终止其中一台机器不会影响平均服务延迟”。

4.你运行实验，进行测量以得出你是否正确的结论。有趣的是，你希望得到错误的结果，因为这样你可以从中学到更多。清理环境并重复这些步骤。

实验通常越简单越好。你不会因精心的设计而获得加分，除非这是证明假设的最佳方式。再看一下图1.2，让我们从可观测性开始深入一点。

1.3.1 确保可观测性

我很喜欢可观测性这个词，因为它直截了当，意味着能够可靠地看到任何你感兴趣的指标。这里的关键字是可靠。在使用计算机时，我们经常会遇到麻烦——硬件制造商或操作系统（OS）已经提供了读取各种指标的机制，从CPU的温度、风扇的RPM，到内存使用和用于内核事件的钩子。但与此同时，我们也很容易忘记，这些指标是由最终用户需要考虑的bug和警告所决定的。如果你用于测量CPU负载的进程最终使用的CPU多于你的应用程序，那么这可能是个问题。

如果你曾经在电视上看过碰撞测试，就会知道它既可怕又迷人。看着一台重达3000磅的机器加速到一个精心控制的速度，然后像折纸天鹅一样在与一个巨大的混凝土块撞击下折叠，多么震撼人心。

但是，高清慢镜头拍摄的破碎的玻璃四处飞舞，以及看起来毫发无损（也没有受到惊吓）的假人坐在一辆几秒钟前曾经是汽车的东西上，这不仅仅是为了娱乐。就像所有的科学家一样，碰撞测试专家和混沌工程实践者都需要可靠的数据来判断实验是否有效。这就是为什么可观测性，即可靠地收集关于活动系统的数据，是至关重要的。

在本书中，我们将重点关注Linux和它提供给我们的系统指标（CPU负载、RAM使用、I/O速度），以及我们将要进行实验的应用程序中的高级指标示例。

1.3.2 定义稳态

有了上一步（可观测性）的可靠数据，你需要定义什么是正常的，以便可以测量异常情况。一个更有趣的说法是“定义一个稳态”。

衡量什么将取决于这个系统和你的目标。它可以是“完好无损的汽车以60英里每小时的速度直线行驶”，也可以是“99%的用户可以在200毫秒内访问我们的API”。通常，这将直接由业务策略驱动。

值得一提的是，在现代的Linux服务器上有很多东西运行，你将会尽最大努力隔离尽可能多的变量。让我们以你的进程的CPU使用情况为例。这听起来很简单，但实际上，很多事情都会影响你读取这个指标。你的进程是否获得了足够的CPU？或者它是否正在被其他进程占用（可能是一个共享机器，或者可能是一个cron作业更新了你在实验期间启动的系统）？内核调度是否将周期分配给了另一个具有更高优先级的进程？你是否处于VM中，并且管理程序可能决定了其他更需要CPU的事情？

你可以深入探索。好消息是，你通常会多次重复实验，一些其他的变量会暴露出来，但是请记住，所有这些其他因素都会影响你的实验，这很重要。

1.3.3 形成假设

现在是真正有趣的部分。在这一步，你要把你的直觉塑造成一个可验证的假设——在一个明确定义的问题出现时，你的系统会发生什么情况的有根据的猜测。它会继续工作吗？它会变慢吗？慢多少？

在现实生活中，这些问题通常是由意外事件引起的（当事物停止工作时发现的未被发现的问题），但你在这个游戏中做得越好，你就越能（也应该）抢占先机。在本章的前面，我列出了一些容易出问题的例子。这些事件大致可分为以下几类：

❑外部事件（地震、洪水、火灾、断电等）

❑硬件故障（硬盘、CPU、交换机、线缆、电源等）

❑资源短缺（CPU、RAM、交换、磁盘、网络）

❑软件bug（无限循环、崩溃、黑客攻击）

❑无人管理的系统瓶颈

❑系统不可预测的涌现性特性

❑VM（Java VM、V8等）

❑硬件bug

❑人为错误（按错按钮、发送错误配置、拔错电缆等）

在本书的第二部分中，我们将研究如何模拟这些问题。其中一些很容易（关闭机器以模拟机器故障，或拔出以太网电缆以模拟网络问题），而其他方式则更为先进（为系统调用增加延迟）。在选择要考虑的故障之前，你需要对你正在使用的系统有充分的了解。

下面是一些例子，假设看起来是这样的：

❑在以每小时60英里的速度正面碰撞时，没有假人会被压扁。

❑如果豌豆的双亲都是黄色的，那么所有的后代都是黄色的。

❑如果我们关闭30%的服务器，API仍可以提供服务，并且99%的请求在200毫秒内。

❑如果我们的一个数据库服务器宕机，我们的系统仍然可以满足SLO。

现在，我们该运行实验了。

1.3.4 运行实验并证明（或反驳）你的假设

最后，你运行实验，测量结果，并得出结论是否正确。请记住，如果假设是错的也没关系——这个阶段更加令人兴奋！

在以下情况下，每个人都将获得奖牌：

❑如果你是对的，那么恭喜！在风雨如磐的日子里，你对系统有了更多的信心。

❑如果你是错的，那么恭喜！你在客户发现之前就在系统中发现了一个问题，而且可以在任何人受到影响之前修复它！

在后面的章节中，我们将花一些时间制定良好的流程规范，包括自动化、管理爆炸半径和在生产环境下测试。现在，只要记住，只要这是一门好科学，你就可以从每个实验中学到一些东西。