ACM通信

实践

生产中故障注入

由约翰·Allspaw
ACM通讯，2012年10月，第55卷第10期，48-52页
10.1145/2347736.2347751
评论

当我们在Etsy构建Web基础设施时，我们的目标是使它们具有弹性。这意味着要仔细设计它们，以便在失败面前能够维持(越来越关键的)操作。值得庆幸的是，已经有几十年的时间和大量的论文用于研究如何将容错和优雅的退化引入计算机系统。这有助于解决问题。

为了确保Etsy系统内建的弹性是健全的，系统的行为符合预期，我们必须看到失败被容忍在生产中．

为什么生产?为什么不在QA或阶段环境中模拟这一点呢?原因是，在这些环境中存在的任何差异都会给测试带来不确定性，而且不恢复的风险不会产生任何后果，这会给容错设计和恢复带来不可预见的假设。我们的目标是减少不确定性，而不是增加不确定性。

强迫失败发生，甚至设计系统使其自行失败，一般都不容易说服管理层。工程师不习惯于接受他们应对紧急情况的能力;他们的目标是完全避免使用。仔细研究如何更好地应对失败，本质上就是接受失败会发生的事实，你可能认为这与你在工程或商业中想要的是相反的。

举个例子，你通常认为这是一个简单的例子:服务器或云实例的供应从零到生产:

1. 提供了裸金属(或云计算实例)。
2. 基本操作系统通过PXE(预启动执行环境)或机器映像安装。
3. 操作系统级配置就位(通过配置管理或机器映像)。
4. 应用程序级配置就位(通过配置管理、应用程序部署或机器映像)。
5. 应用程序代码就位，底层服务正确启动(通过配置管理、应用程序部署或机器映像)。
6. 系统集成在网络中进行(负载均衡器、vlan、路由、交换、DNS等)。

这可能过于简化了，每个步骤或层都可能代表多个CPU周期;磁盘、网络和/或内存操作;以及各种各样的软件机制。所有这些结合在一起就可以将一个节点投入生产。

可操作性意味着您可以确信该节点将投入生产，可能加入集群，并在每次发生时无缝地服务实时流量。此外，您希望并期望有这样的信心:如果底层功能、配置、应用程序或计算资源(CPU、磁盘、内存、网络等)遇到故障，那么您可以通过某种方法避免此类故障:允许应用程序正常降级、重新构建自身、退出生产并就故障的细节发出警报。

建立这种信心通常有以下几种方式:

• 硬件老化测试．您可以在节点中的各种硬件组件上运行极端测试，以确认它们在负载开始时不会出现故障。这在云计算实例中可能不是必要的，也不是可行的。
• 组件单元测试．可以轻松地隔离测试每个服务，并检查配置以确保预期。
• 集成的功能测试．每个执行路径(通常基于应用程序特性)都可以通过某种形式的自动化过程进行探索，以确保预期的结果。

传统上，这些提高信心的明智措施是在系统或应用达到生产之前做出的。一旦进入生产环境，传统的方法是依靠监视和日志记录来确认一切正常工作。如果它的行为符合预期，那么您就没有问题。如果不是这样，并且需要人工干预(故障排除、分类、解决等)，那么您需要对事件做出反应，并以尽可能快的速度恢复工作。

这意味着一旦系统投入生产，“不要碰它!”当然，除非它坏了，在这种情况下，在停机响应固有的时间压力下，您可以随意碰它。

在许多层面上，这种方法并不像它可能的那样富有成效。

在实战中，你要做好应对不良行为的准备。电力可能突然中断。对应用程序或配置的更改会产生不可预见的行为，无论测试的覆盖率有多高。在各种资源争用条件下的应用程序行为(考虑新闻事件或类似消防水带的分布式拒绝服务攻击的流量峰值)可能会产生令人惊讶的结果。这不是纯粹的学术好奇;这些类型的故障可以(而且将会)影响生产，因此，在Etsy的情况下，我们的卖家和我们的业务。然而，这些类型的事件很难用精确的模型和模拟来激发围绕未知失败病理的行为的信心。

挑战在于Web系统(像许多“复杂”系统一样)在很大程度上是难以处理的，这意味着:

• 要完整地描述，细节很多，而不是很少;
• 变化率很高;在完整的描述(以及理解)完成之前，系统会发生变化;
• 组件如何发挥作用部分是未知的，因为它们在不同的条件下会相互共振;而且
• 过程是异质的，可能是不规则的。

换句话说，虽然在生产环境之外进行测试是一种非常合适的方法，但它是不完整的，因为无论构建多么相同的登台环境，有些行为只能在生产环境中看到。

因此，另一种方法必须添加到增强信心的武器库中:错误注入练习，有时被称为GameDay。我们的目标是让这些错误发生在生产为了预测未来类似的行为，了解故障对底层系统的影响，并最终了解它们对业务构成的风险。

导致复杂系统发生故障并不是一个新概念。数十年来，消防部门等机构一直在进行全面的灾难演习。与这些类型的演练相比，Web工程有一个优势，系统工程师可以以极高的分辨率收集任何故障的大量细节，对复杂的故障机制进行大量控制，并学习如何快速地从故障中恢复。

回到顶部

故障注入

在Etsy上构建GameDay练习遵循以下模式:

1. 想象一下您的基础设施中可能发生的麻烦事件。
2. 弄清楚需要什么来防止该事件影响你的业务，并实施它。
3. 让事件发生在生产中，最终证明事件没有影响，并获得围绕它的信心。

GameDay实践的最大优势在于找出如何避免失败影响业务。第一步和第二步的重要性再怎么强调也不为过。其理念是将一组工程师聚集在一起，对特定应用程序、服务或基础设施可能遇到的各种故障场景进行头脑风暴。这将有助于消除对整个系统安全的自满情绪。自满是韧性的敌人。如果一个系统有一段退化很少或没有退化的时期，那么它就有在多个层面上滑向故障的真实风险，因为工程师可以错误地相信系统没有经历意外事件，因为它天生是安全的。

想象失败的场景，并问:“如果……会怎么样?”可以帮助对抗这种想法，并给组织带来持续的不安感。这是高可靠性组织的一个显著特征。可以将其看作是持续部署业务连续性计划(BCP)。

回到顶部

商业理由

从理论上讲，GameDay练习的想法可能听起来很合理:您明确地预测失败场景，为优雅地处理它们做好准备，然后通过有意地将这些失败注入生产中来确认这种行为。在实践中，这种想法似乎对企业没有吸引力:它把风险摆在了最前面;如果没有背景，故意让失败发生的概念可能看起来很疯狂。如果出了问题怎么办?

对于生产中的失败，传统的观点是不惜一切代价避免。假设失败是完全可以避免的，如果它真的发生了，那么找到该负责的人(通常是那些最接近代码或系统的人)并解雇他们，相信摆脱“坏苹果”是你为组织带来安全的方式。

当然，这种观点是可笑的。故障注入和GameDay场景可以将此视图还原为更实用和更现实的视图。

当我与Etsy的执行团队接触GameDay练习的想法时，我解释说，我们并不是想因为某些反常的需要而导致失败，以看着基础设施崩溃;这是因为我们知道系统的一部分将不可避免地会失败，我们需要获得信心，相信金融体系有足够的弹性，能够优雅地处理它。

我向高管们解释说，我们的理念是，构建弹性系统需要有应对失败的经验，我们希望预测并确认我们对失败的预期更多的通常,不少经常。在降低风险的错误尝试中逃避失败的影响，将导致糟糕的设计、陈旧的恢复技能和错误的安全感。

换句话说，最好是在生产中做好准备，并让失败发生当我们看着，而不是依赖于希望系统能够正确运行的策略当我们不看的时候．最糟糕的情况是，在GameDay练习中会出现问题。在这种情况下，整个工程师团队都准备好了对这些意外做出反应，系统也会因此变得更强大。

在缺乏GameDay演练的情况下，最糟糕的情况是，制作中的某些东西会出现意料之外或没有准备的失败，这种情况会发生在团队没有预料到或没有密切关注的时候。

如何确保将故障注入到实时生产系统中不会影响实际流量、收入和最终用户体验?这可以通过将容错和优雅的降级机制当作它们是可以做到的特性．这意味着将所有其他的建立信任技术(单元测试和功能测试、登台硬件环境等)都引入到这些弹性措施中，直到您满意为止。就像应用程序的所有其他特性一样，只有将其部署到生产环境并验证其正确工作时，它才算完成。

回到顶部

例:支付系统

今年早些时候，Etsy推出了一个新的支付系统(http://www.etsy.com/blog/news/2012/announcing-direct-checkout/)，为买卖双方提供更灵活和可靠的网站。显然，弹性对于项目的成功至关重要。与Etsy的许多功能一样，产品的推出是在一个循序渐进的过程中完成的。对这种新的支付方式感兴趣的卖家可以选择加入，Etsy将为一桶又一桶的卖家开启这项功能。

正如你所想象的，支付系统并不是特别简单。它具有欺诈检测组件、审计跟踪、安全机制、处理状态机和其他需要相互交互的组件。因此，Etsy有一个任务关键系统具有相当大的复杂性，其弹性的期望是非常高的。

为了确认其从容地承受失败的能力，Etsy列出了一份合理的场景清单，用于准备、开发和在生产中测试，其中包括:

• 其中一个应用服务器死亡(电源线被拔出);
• 所有应用服务器都离开负载平衡池;
• 其中一个应用服务器会被清理干净，需要从头开始完全重建;
• 数据库死亡(电源线拔出和/或进程不正常地死亡);
• 数据库完全损坏，需要从备份中完全恢复;
• 离线数据库副本需要调查/恢复/重播单个事务;而且
• 与第三方网站的连接被完全切断。

然后，工程师将所有的期望放在一起，以确定如果这些场景在生产中发生，系统将如何表现，以及他们如何通过日志、图表和警报来确认这些期望。一旦有了这些设想，他们就开始研究如何解决这些失败:

• 完全无关紧要(透明地恢复并继续处理);
• 物质只是暂时的(优雅地降级，没有数据丢失，并提供建设性的反馈给用户);或
• 只对最小的用户子集有影响(包括用于快速且可能自动地重构和恢复的审计日志)。

在开发中编写并测试这些机制之后，就到了在生产中测试它们的时候了。Etsy团队知道系统看到了多少活动;支持和产品小组随时待命，帮助进行必要的沟通;团队成员经历了每个场景，收集了以下问题的答案:

• 他们成功地通过冗余、复制和排队透明地恢复了吗?
• 在从头自动重建节点和恢复数据库的情况下，每个进程需要多长时间?
• 他们能确认整个演习过程中没有数据丢失吗?
• 有什么惊喜吗?

该团队能够确认大多数预期的行为，Etsy社区(卖家和买家)能够继续其在网站上的经验，不受失败的阻碍。

然而，在这个过程中，Etsy团队也发现了一些意外，并将其作为会议的补救措施。首先，在支付过程中，第三方欺诈检测服务机构获得了交易信息。虽然Etsy使用了许多外部api(欺诈或设备声誉)，但这个特殊的服务在外部调用上没有指定超时。在测试无法联系服务时，Etsy团队使用了防火墙规则来硬关闭连接，并试图将其挂起。没有指定的超时意味着它们依赖于默认值，默认值为60秒，太长了。预期的行为是失败打开，这意味着如果外部服务关闭，事务可以继续。这一方法有效，但只有在60秒的超时后才有效，这导致实际支付在演习中花费了超过必要的时间。

---

强迫失败发生，甚至设计系统使其自行失败，一般都不容易说服管理层。

---

这是一个意外，也是一个相对容易修复的部分，但它仍然是一个影响测试期间生产的疏忽。

从数据库损坏中恢复也花费了比预期更长的时间。GameDay练习是在一个主-主数据库对的一端执行的，当恢复发生在损坏的服务器上时，这对数据库对中的其他服务器进行生产所需的所有读写操作。虽然没有发生生产数据丢失，但产能减少的暴露时间比预期更长，所以Etsy团队开始分析，然后试图减少恢复的时间。

这项运动的文化影响是显而易见的。它大大减少了人们对支付系统升级的焦虑;它暴露了代码和基础设施中需要改进的一些黑暗角落;它使人们对金融体系的信心全面增强。因此，自满并不是对体系的直接威胁。

回到顶部

限制

故障注入和GameDay练习的目标是增加对复杂系统保持弹性能力的信心，但它们也有局限性。

首先，这些练习并不是为了告诉工程团队如何在时间压力下处理不断升级甚至有时令人困惑的场景。这需要来自于对实际事故的事后分析，而不是来自于处理已经计划和设计的故障。

故障和故障类型为不自然的．它们反映了故障设计者的想象力，因此不能被认为是足够全面的，以获得系统安全的完美覆盖。尽管对金融体系弹性能力信心的任何增加都是积极的，但它仍然只是:信心的增加，而不是完全信心的完成。任何复杂的系统都可能(而且将会)以令人惊讶的方式失败，无论您注入和恢复了多少种不同类型的故障。

有些人认为，比起将GameDay练习作为工程团队的活动来手动运行，自动地不断引入失败是获得系统适应性的更有效的方法。这两种方法都有这里提到的相同的限制，因为它们导致信心的增加，但不能用于实现充分的安全覆盖。

自动故障注入会带来一个悖论。如果以透明和优雅的方式处理注入的错误(即使是随机的)，那么它们可能不会被注意到。你可能会认为这就是我们的目标:当失败发生时，无论如何都不重要。然而，这种对失败的掩盖可能导致他们打算(至少应该打算)减少的自满情绪。换句话说，当随机生成和/或连续故障注入和恢复成功发生时，必须小心提高详细地意识到这正在发生，何时，如何，何地。否则，失败本身就会成为增加系统复杂性的另一个组件，同时仍然对其功能有限制(因为它们仍然是人为设计的，因此足够了)。

回到顶部

恐惧

我提出的许多建议应该只是扩大各组织已经拥有的建立信任的工具。自动化质量保证、容错、冗余和A/B测试都属于GameDay场景的同一个类别，尽管可能没有那么多戏剧性。

---

在降低风险的错误尝试中逃避失败的影响，将导致糟糕的设计、陈旧的恢复技能和错误的安全感。

---

所有东西都应该有一个相关的游戏日练习吗?可能是，也可能不是，这取决于您对应用程序和基础设施中的组件、交互和复杂性的信心程度。即使您的企业不认为GameDay练习是必要的，但是，它们应该在您的工程工具包中占有一席之地。

回到顶部

安全的疫苗

为什么要在正常运行的生产系统中引入错误呢?为什么会有用呢?

首先，这些诱导失败的练习可以作为“疫苗”来提高系统的安全性，注入少量的失败来帮助系统学会恢复。它还保持了工程团队文化中对失败的关注，并抑制了自满情绪。

它将一群通常不会聚集在一起的人聚集在一起，分享经历失败的经验，并建立容错能力。它还可以帮助开发人员更接近产品中可操作性的概念，他们可能不习惯这种概念。

在高水平上，生产故障注入应该被认为是提高系统安全性和弹性的众多方法之一。与单元测试、功能测试和代码审查类似，这种方法的局限性在于它可以防止哪些意外事件，但它也有好处，其中许多是文化方面的。我们当然无法想象没有它的工作。

相关文章
在queue.acm.org

黑盒调试
詹姆斯·惠特克，赫伯特·h·汤普森
http://queue.acm.org/detail.cfm?id=966807

太大而无法测试
基斯Stobie
http://queue.acm.org/detail.cfm?id=1046944

《与史蒂夫·伯恩、埃里克·奥尔曼和布莱恩·坎特里尔的对话》
http://queue.acm.org/detail.cfm?id=1413258

并发的奸诈之徒
2009年1月14日,
http://blogs.sun.com/bmc/entry/concurrency_s_shysters

回到顶部

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

---

没有发现记录