Netflix混沌工程手册Part 2：混沌工程原则

本文翻译自Netflix工程师合著的 *Chaos Engineering*一书。这本书介绍了混沌工程的主要概念，以及如何在组织中实践这些概念和经验。也许我们开发的相关工具只适用于Netflix自身的业务和系统环境，但我们相信工具背后的原则可以更广泛地应用于其他领域。

InfoQ 将就这一专题持续出稿，感兴趣的同学可以持续关注。

本文略长，共计1.3万字，预计阅读时间35分钟。

混沌工程原则

优化复杂系统的性能通常需要在混乱的边缘进行，即系统行为将要变得混乱且无迹可寻之前。

Sydney Dekker，《陷入失败》

“混乱”一词让我们想起随机性和无序。然而，这不意味着混沌工程的实施也是随机和随意的，也不意味着混沌工程师的工作就是引发混乱。相反，我们把混沌工程视为一种学科，一种实验学科。

在上面的引用中，Dekker观测了分布式系统的整体行为，他也主张从整体上了解复杂系统是如何失效的。我们不应该仅仅着眼于发生故障的组件，而是应该尝试去理解，例如组件交互中的一些偶发意外行为，最终如何导致系统整体滑向不安全，不稳定的状态。

你可以将混沌工程视为一种解决“系统离混乱的边界有多远” 的经验方法。从另一个角度去思考，“如果我们把混乱注入到系统里，它会怎么样？”

在这一部分，我们会介绍混沌工程实验的基本设计，之后我们会讨论一些更高级的原则。这些原则建立在真实实践混沌工程的大规模系统之上。在实践混沌工程的过程中，并不是必须遵照所有高级原则，但我们发现，运用的原则越多，你对系统弹性的信心就越充足。

实验

在大学里，电气工程专业的学生必须学习一门“信号和系统”的课程，在这个课程中他们学习如何使用数学模型来推理电气系统的行为。其中一门需要掌握的技术被称为拉普拉斯变换。你可以用拉普拉斯变换，将整个电路的行为用一个数学函数表达，我们称之为传递函数。传递函数描述的是系统在受到脉冲时如何响应，输入信号包含所有可能的输入频率的总和。一旦你有了一个电路的传递函数，就可以预测它在受到所有可能的输入信号时会如何响应。

软件系统里并没有类似的传递函数。像很多复杂系统一样，我们无法为软件系统表现出的各种行为建立一个预测模型。如果我们有这样一个模型，可以推导出一次网络延迟骤升会给系统带来什么影响，那样就太完美了。但不幸的是，迄今为止我们并没有发现这样一个模型。

因为我们缺乏这样的理论预测模型，所以就不得不通过经验方法来理解，在各种不同情况下系统会如何表现。我们通过在系统上运行各种各样的实验，尝试给系统制造各种麻烦，看它会发生什么状况。

但是，我们肯定不会给系统随机的不同的输入。我们在系统性分析之后，期望可以最大化每个实验可以获得的信息。正如科学家通过实验来研究自然现象一样，我们通过实验来揭示系统的行为。

FIT 故障注入测试

分布式系统的经验告诉我们，各种系统问题基本都是由预期外的事件或不良的延迟导致的。2014年初，Netflix开发了一个名为FIT的工具，意思是故障注入测试（Failure Injection Testing）。这个工具能让工程师在访问服务的一类请求的请求头中注入一些失败场景，当这些注入了失败场景的请求在系统中流转时，微服务中被注入的故障锚点会根据不同的失败场景触发相应的逻辑。

例如，我们要测试系统在某个保存用户数据的微服务中断时的弹性能力。我们预计系统中某些服务不会如预期运行，但诸如重放等基本功能仍适用于已登录用户。使用FIT，我们指定进入服务的所有请求中，有5%会在请求头中包含失败场景。当这些请求在系统中传播时，只要发到客户数据微服务的请求都会自动收到故障响应。

高级原则

在开发混沌工程实验时，牢记以下原则将有助于实验设计。在接下来的章节里将会深入探讨以下每个原则：

• 建立稳定状态的假设；
• 多样化现实世界事件；
• 在生产环境运行实验；
• 持续自动化运行实验；
• 最小化“爆炸半径”。

预测和预防故障

在2017年美洲SRECon大会上，Preetha Appan介绍了她和她的团队在 indeed.com 开发的一个引入网络故障的工具。在演讲中，她阐述了预防故障的切实需求，而不是仅仅在故障发生时做出响应。他们的工具Sloth，作为一个守护进程，运行在基础设施的每一个节点上，包括数据库和索引服务器。参见 https://www.usenix.org/conference/srecon17americas/program/presentation/appan

3. 建立稳定状态的假设

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

如果你在开发或运行一个软件服务，你如何清楚地了解它是否在正常工作？你如何认定它的稳定状态？你应该从哪里着眼来回答上面的问题？

稳定状态

在系统思维社区中使用“稳定状态”这个术语，来指代系统维持在一定范围内或一定模式的属性，诸如人体维持体温在一定范围内一样。我们期望通过一个模型，基于所期望的业务指标，来描述系统的稳定状态。这是我们在识别稳定状态方面的一个目标。要牢记稳定状态一定要和客户接受程度一致。在定义稳定状态时，要把客户和服务之间的服务水平协议（SLA）纳入考量。

如果你的服务是一个新服务，想知道它是否正常工作的唯一途径可能只有自己去运行一下。例如服务可以通过网站访问，那你可能需要打开网页并尝试触发一个任务或事务来检查这个服务。

这种快速检查系统健康的方法显然并不理想：他是劳动密集型的，也就是说我们基本不会或不常会做这件事。我们可以自动化运行类似测试，但这还不够。如果这些测试不能找到系统中的问题，该怎么办？

更好的方法是先搜集和系统健康有关的数据。如果你在阅读本书，我们相信你已经在使用某种指标收集系统来监控你的系统。有大量的开源和商业工具可以采集系统方方面面的数据：CPU负载，内存使用情况，网络I/O，以及各类时序信息，例如需要多长时间响应一个Web请求，或者查询各种数据库的耗时。

系统的指标有助于帮助我们诊断性能问题，有时也能帮助我们发现功能缺陷。业务指标与系统指标形成对比，业务指标通常回答这样的问题：

• 我们正在流失用户吗？
• 用户目前可以操作网站的关键功能吗？例如在电子商务网站里为订单付款，添加购物车等。
• 目前存在较高的延迟致使用户不能正常使用我们的服务吗？

某些组织有非常明确的，和收入直接相关的实时指标。例如像Amazon和eBay会跟踪销售量，Google和Facebook会跟踪广告曝光次数。

由于Netflix使用的是按月订阅模式，所以我们没有这类指标。我们也会测量注册率，这是一个重要的指标，但是只看注册率不能反映整体系统的健康状况。

我们真正想要的是一个可以反映当前活跃用户的满意状况的指标，因为满意的用户才有可能连续订阅。可以这么说，如果当前和系统做交互的用户是满意的，那么我们基本可以确定系统目前是健康的。

遗憾的是，我们目前还没找到一个直接、实时的可以反映用户满意度的指标。我们会监控客服电话的呼叫量，这或许是一个可以间接反映客户满意度的指标，但是从运营角度出发，我们需要更快、更细粒度的反馈。Netflix有一个还不错的可以间接反映用户满意度的指标——播放按钮的点击率。我们管这个指标叫做视频每秒开始播放数，简称为SPS（Starts per sencond）。