ACM通信

实践

Antifragile组织

由阿里尔Tseitlin
ACM通讯，2013年8月，Vol. 56 No. 8, page 40-44
10.1145/2492007.2492022
评论

失败是不可避免的。磁盘失败。软件bug潜伏着等待合适的条件来攻击。犯错误的人。数据中心是建立在不可靠的商用硬件上的。如果您在云环境中运行，那么其中许多因素都不在您的控制范围之内。更复杂的是，失效是不可预测的，并且发生的概率和频率不均匀。缺乏统一的频率增加了系统中的不确定性和风险。面对这种不可避免和不可预测的故障，您如何构建一个可靠的服务，为您的用户提供高级别的可用性?

一个朴素的方法可以试图通过严格的分析来证明一个系统的正确性。它可以模拟所有不同类型的故障，并通过模拟或分析真实操作环境的另一个理论框架推断出系统的正确工作方式。不幸的是，行业中的静态分析和测试技术还没有达到这些能力。⁴

另一种方法可以尝试创建详尽的测试套件，在单独的测试环境中模拟所有失败模式。每个测试套件的目标是维护每个组件的正常功能，以及当单个组件出现故障时整个系统的正常功能。大多数软件系统以一种或另一种形式使用这种方法，并结合了单元测试和集成测试。更高级的用法包括测量测试的覆盖面以指示完整性。

虽然这种方法确实提高了系统的质量，并可以防止大量的故障，但它在大规模分布式系统中维持弹性方面是不够的。分布式系统必须应对数据和信息流带来的挑战。设计和执行正确捕获目标系统行为的测试的复杂性比构建系统本身的复杂性要大。在此基础上再加上大规模的属性，以目前的手段，在保持高创新速度和特性交付的同时，在实践中实现这一点变得不可行。

另一种方法，在这篇文章中提倡，是诱导系统的失败，以经验证明弹性和验证预期的行为。考虑到系统设计具有抗故障能力，在原始设计参数中引入这些故障，验证了系统的预期行为。因为这种方法使用实际的动态系统，所以随着系统的发展和变化，出现的任何弹性缺口都可以被快速识别和捕获。在刚刚描述的第二种方法中，许多复杂的问题在测试环境中没有捕捉到，只有在实际环境中才会以独特和罕见的方式表现出来。这反过来又增加了潜在bug未被发现和积累的可能性，只会在正确的故障模式发生时造成更大的问题。通过失败诱导，在测试环境中对数据、信息流和部署架构的更改建模的需求被最小化了，并减少了错过问题的机会。

在深入讨论之前，让我们讨论一下什么是弹性以及如何提高弹性。

弹性是系统的一个属性，它使系统能够以一种不会导致整个系统失败的方式处理故障。它可能包括在故障发生时最小化爆炸半径，或者改变用户体验以绕过故障组件。例如，如果电影推荐服务失败，用户可以得到一个非个性化的热门电影列表。一个复杂的系统不断地发生不同程度的故障。弹性是指它能够从当前和未来的失败中恢复或绝缘的措施。⁷

有两种方法可以增加系统的弹性:

• 构建具有冗余和容错功能的应用程序．在面向服务的体系结构中，组件封装在服务中。服务由冗余的执行单元(实例)组成，它们保护客户端免受单单元或多单元故障的影响。当整个服务发生故障时，该服务的客户端必须实现容错，以定位故障并继续工作。
• 通过定期诱导失败来减少不确定性．增加故障发生的频率可以减少其不确定性和不适当或意外响应的可能性。在观察应用时，每个独特的失效都可能被诱导。对于每一种对诱发失效的不良反应，可以采用第一种方法来防止其再次发生。虽然在实践中不可能诱发所有可能的故障，但列举可能的故障并对它们进行优先排序有助于理解可容忍的操作条件，并在故障超出这些范围时对故障进行分类。

第一个项目在其他文献中有很好的论述。本文的其余部分将重点讨论第二点。

回到顶部

猴军队

一旦你接受了经常导致失败的想法，接下来就有几个选择。一个选择是GameDays，¹一组有计划的演习，其中失败是人工引入或模拟的，以反映真实世界的失败，目标是确定结果并进行相应的消防演习。GameDays被Amazon和谷歌等公司使用，它是一种很好的方法，可以在常规基础上诱导失败，验证关于系统行为的假设，并改进组织响应。

但是，如果您想要一个更可扩展和自动化的解决方案，而不是每季度运行一次，而是每周或甚至每天运行一次，该怎么办?你不希望失败是一场消防演习。你希望它是一个无关紧要的事情——一直在后台发生的事情，这样当真正的失败发生时，它就会融入其中，而不会产生任何影响。

实现这一目标的一种方法是设计在实际环境中发生故障。这就是“猴子”(实际上是自主代理，但猴子能激发想象力)的想法如何来到Netflix，造成破坏并导致失败。后来，这些猴子被聚集在一起，并被称为“猿军”。⁵下面是对每只与弹性相关的猴子的描述。

混乱的猴子．虚拟实例的故障是典型的公共云环境中最常见的故障类型。它可能是由主机机架中的电源中断、磁盘故障或网络分区切断访问引起的。不管原因是什么，结果都是一样的:实例变得不可用。诱导此类故障有助于确保服务不依赖于任何on-instance状态、实例关联或持久连接。

为了解决这一需求，Netflix创建了它的第一个猴子:Chaos monkey，它在生产环境中随机终止服务于实时客户流量的虚拟实例。^3.

Chaos Monkey首先查看服务注册表，以找到所有正在运行的服务。在Netflix的案例中，这是通过Asgard的组合实现的⁶和埃达。²每个服务都可以覆盖缺省的Chaos Monkey配置，以更改终止概率或完全退出。每个小时，Chaos Monkey都会醒来，掷骰子，并使用Amazon Web Services (AWS) api终止受影响的实例。

当服务终止时，Chaos Monkey可以有选择地向服务所有者发送电子邮件，但大多数服务所有者不启用此选项，因为实例终止非常常见，不会导致任何服务退化。

混乱的大猩猩．使用Chaos Monkey，系统对单个实例的故障具有弹性，但如果整个数据中心变得不可用怎么办?如果整个亚马逊可用分区(AZ)下线，会对用户产生什么影响?为了回答这个问题，并确保这样的活动对客户的影响最小，Netflix创建了混沌大猩猩。

混乱大猩猩导致整个AZ失败。它模拟了两种故障模式:

• 网络分区．专区中的实例仍然在运行，并且可以相互通信，但是无法与专区之外的任何服务通信，并且专区之外的任何其他服务都无法访问这些实例。
• 区总失败．区域中的所有实例都被终止。

混乱大猩猩造成了巨大的破坏，需要一个复杂的控制系统来重新平衡负载。对于Net flix来说，该系统仍在开发中，因此，Chaos Gorilla是手动运行的，类似于之前提到的GameDay练习。随着每一次连续的运行，Chaos Gorilla在执行失败的方式上变得更加积极，目标是像在Chaos Monkey中那样以自动无人看管的方式运行它。

混乱的香港．区域由多个数据中心(可用分区)组成，这些数据中心之间相互隔离。健壮的部署架构通过使用多个AZ实现AZ冗余。在实践中，确实会发生区域性故障，这使得单区域部署无法为区域性故障提供弹性。一旦一个系统冗余部署到多个区域，区域故障必须以类似的方式测试实例和可用分区。《混沌金刚》就是为了这个目的。Netflix正致力于通过《混沌金刚》让整个地区下线。

延迟的猴子．一旦Chaos Monkey运行，并且单个实例故障不再产生任何影响，就会出现一种新的故障类型。处理实例失败相对容易:只需终止坏的实例，让新的健康实例取代它们。当实例变得不健康，但仍在工作时，检测是更加困难的，对这种故障模式具有弹性也更加困难。错误率可能会提高，但服务偶尔会返回成功。服务可能响应成功，但延迟可能会增加，导致超时。

---

一个复杂的系统不断地发生不同程度的故障。弹性是指它能够从当前和未来的失败中恢复或绝缘的措施。

---

Netflix需要的是一种模拟部分健康实例的失败诱导方法。因此出现了Latency Monkey，它在RESTful客户端-服务器通信层中诱导人为延迟，以模拟服务退化，并衡量上游服务是否适当响应。此外，通过创建非常大的延迟、节点停机、甚至整个服务停机，可以在不停机的情况下模拟实例或服务。当通过模拟其依赖项的失败来测试新服务的容错能力时，这尤其有用，而且不会使这些依赖项对系统的其他部分不可用。

剩余的军队．猿猴军团的其他成员，包括管理员猴子，负责维护和其他与可用性没有直接关系的杂项任务。(详情,请参阅http://techblog.netflix.com/2011/07/netflix-simian-army.html．)

回到顶部

Netflix的猴子训练

虽然类人猿军队是一个新的概念，可能需要转变观点，但它并不像最初看起来那样难以实施。了解Netflix的经历对其他有兴趣追随这条道路的人来说是一个示范。

Netflix以大胆地快速追求创新和高可用性而闻名，但并没有到麻木不仁的地步。要小心避免这些失败诱导练习对客户产生任何明显的影响。为了降低风险，Netflix在引入猴子时采取了以下步骤:

1. 在测试环境中使用新猴子，工程师观察用户体验。目标是对客户的影响可以忽略不计或为零。如果工程师看到任何不利的结果，他们就会进行必要的代码更改，以防止再次发生。这个步骤需要重复多次，直到没有观察到不良的用户体验。
2. 一旦在测试环境中没有观察到不良结果，就在生产环境中启用新的猴子。最初，新monkey以opt-in模式运行。选择一个或多个服务来运行新monkey，这些服务已经在测试环境中运行过。新猴子会在这种模式下运行几个月，随着时间的推移会选择新的服务。
3. 在许多服务选择加入后，新猴子就会选择退出模式，在这种模式下，所有的服务都是新猴子的潜在目标。如果一个服务被放置在一个选择退出列表中，猴子就会避开它。
4. 每只猴子都会定期检查退出列表，并鼓励服务所有者将他们的服务从列表中删除。该平台和猴子得到了改进，以增加采用和解决选择退出的原因。

回到顶部

可观测性的重要性

如果不强调监测的重要作用，关于恢复力的讨论就不完整。监控这里指的是能够观察系统及其组件的外部和内部状态，并可选地发出警报。在故障诱导和恢复的背景下，监测是重要的两个原因:

• 在真实的、非模拟的客户影响事件中，重要的是稳定系统并尽快消除客户影响。在此期间，必须停止任何导致额外故障的自动化操作。不这样做会导致混乱猴，延迟猴，和其他猿类进一步削弱一个已经不健康的系统，造成更大的不利最终用户的影响。观察和检测客户影响的服务退化的能力是构建和启用导致故障的自动化的重要前提。
• 建设有弹性的系统不是在某个时间点发生的;这是一个持续的过程，包括发现弱点并在迭代学习周期中处理它们。对系统的深入了解是理解系统如何运行以及它以何种方式失效的关键。如果没有对系统及其组件的操作的度量和洞察，很少有根本原因调查能够成功。监视提供了对系统如何运行的深入理解，特别是当它发生故障时，并使发现系统中的弱点和确定弹性的反模式成为可能。

在一个影响客户的事件中，首先要问的最重要的问题之一是:“发生了什么变化?”因此，监视和可观察性的另一个关键方面是记录系统状态变化的能力。无论是新代码部署、运行时配置中的更改，还是外部使用的服务的状态更改，都必须记录这些更改，以便稍后检索。Netflix为此建立了一个内部名为Chronos的系统。任何改变系统状态的事件都被记录在Chronos中，可以快速查询以帮助确定因果关系。

回到顶部

Antifragile组织

坚韧地面对失败是一个崇高的目标。它使系统能够生存并经受住失败。然而，还有一个更高的目标值得我们去奋斗:让系统在每次失败后变得更强大、更好。用纳西姆•塔勒布(Nassim Taleb)的话说，它可以成为antifragile从每一个相继的压力、干扰和失败中成长壮大。⁸

Netflix采取了以下步骤来创建一个更抗脆弱的系统和组织:

1. 每个工程师都是服务的操作者．这有时被戏称为“无行动”，尽管它实际上更像是“分布式行动”。开发和运营的分离造成了责任的划分，这可能会带来一系列挑战，包括网络外部性和不协调的激励措施。网络外部性是由运营商感受到开发者带来的问题带来的痛苦而引起的。失调的激励机制是运营商希望稳定而开发商希望速度的结果。DevOps运动就是为了应对这种分歧而开始的。开发人员应该操作自己的服务，而不是将开发和运营分开。他们将代码部署到生产环境中，然后如果代码的任何一部分出错并影响到客户，他们就会在半夜被唤醒。通过将开发和运营结合起来，每个工程师都可以通过改变服务来响应故障，以提高对未来故障的弹性和容错能力。
2. 每次失败都是一次学习的机会，产生以下问题:“如何能更快地检测到故障?”“系统如何才能对这种类型的故障更有弹性?”“这种失败怎么会经常发生呢?”其结果是，每次失败都会让系统变得更加强大和有弹性，就像战士在每次战斗中获得的经验会让他在下一次战斗中变得更加强大和凶猛。系统失败的次数和方式越多，它就会变得越好。
3. 培育了一种无可指责的文化．作为一个组织，Netflix在创新和速度方面进行了优化，它承认错误有时会发生，并把每一次错误都当作一次学习的机会。在Netflix，人们经常听到这样一句话:“如果我们没有犯任何错误，那就意味着我们行动不够迅速。”错误并不是坏事，除非重复犯同样的错误。其结果是，人们不那么担心犯错，事后分析可以作为有效的学习机会(见步骤2)。

回到顶部

结论

故障发生得越频繁，系统和组织就越有准备，能够以透明和可预测的方式处理它。诱导失败是确保系统和组织弹性的最佳方法。我们的目标是最大限度地提高可用性，使服务的用户免受故障的影响，并提供一致的可用用户体验。弹性可以通过增加故障的频率和种类来提高，并改进系统以更好地处理每一个新发现的故障，从而增加抗脆弱性。注重学习和培养无可指责的文化是在系统中创造适当反馈的重要组织因素。

相关文章
在queue.acm.org

自动化软件故障报告
布伦丹·墨菲
http://queue.acm.org/detail.cfm?id=1036498

保持比特安全:有多难?
大卫·s·h·罗森塔尔
http://queue.acm.org/detail.cfm?id=1866298

监控，为您服务
比尔·霍夫曼
http://queue.acm.org/detail.cfm?id=1113335

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2013 ACM有限公司

---

没有发现记录