是什么击垮了我们的系统：黑天鹅事件分类

图片来源：

黑天鹅是一种隐喻，指的是具有严重影响的异常事件（如 2008 年的金融危机）。在生产系统中，这些事件会引发您之前未知的、造成重大可见影响的问题，并且无法通过回滚或来自您的随叫随到手册中的其他标准响应快速轻松地解决。这些是您在多年后告诉新工程师的事件。

根据定义，黑天鹅事件是无法预测的，但有时我们可以找到一些模式，并利用这些模式来创建针对相关问题类别的防御措施。

例如，很大一部分故障是更改（代码、环境或配置）的直接结果。以这种方式触发的每个错误都是独特的且不可预测的，但对所有更改进行金丝雀测试的常见做法在一定程度上有效地对抗了此类问题，并且自动回滚已成为标准的缓解措施。

随着我们这个行业的不断成熟，其他类型的问题正在成为广为人知的危害类别，并具有通用的预防策略。

在野外观察到的黑天鹅事件

所有技术组织都会遇到生产问题，但并非所有组织都会分享他们的分析。公开讨论事件的组织正在为我们所有人提供服务。以下事件描述了一类问题，绝非孤立的个例。我们所有人的系统中都潜伏着黑天鹅事件；只是有些人还不知道而已。

触及限制

一头扎进任何类型的限制都可能导致非常严重的事件。这方面的一个典型例子是 Instapaper 在 2017 年 2 月的宕机事件。我敢说，任何值过班的工程师在阅读宕机报告时都会感到不寒而栗。Instapaper 的生产数据库位于一个文件系统上，该文件系统具有 2TB 的限制，但运行该服务的团队对此一无所知。在没有任何警告的情况下，它停止接受写入。完全恢复花费了数天时间，并且需要迁移其数据库。

公开讨论事件的组织正在为我们所有人提供服务。

限制可能以各种方式出现。Sentry 触及了 Postgres 中最大事务 ID 的限制。Platform.sh 触及了管道缓冲区的大小限制。SparkPost 触发了 AWS 的 DDoS 保护。Foursquare 在其数据存储之一耗尽 RAM 时遇到了性能悬崖。

获取系统限制预先知识的一种方法是定期进行测试。良好的负载测试（在生产副本上）应该包括写事务，并且应该包括将每个数据存储扩展到超出其当前的生产规模。很容易忘记测试那些不是您的主要数据存储（例如 Zookeeper）的东西。如果您在测试期间遇到限制，您有时间修复这些问题。鉴于与限制相关的问题的解决可能涉及重大更改（例如拆分数据存储），时间非常宝贵。

当涉及到云服务时，如果您的服务产生异常负载或使用不太广泛使用的产品或功能（例如较旧或较新的产品或功能），您可能更有可能触及限制。也值得对这些进行负载测试。但请首先警告您的云提供商。

最后，在已知限制的情况下，添加监控（以及相关的文档），以便您了解您的系统何时接近这些上限。不要依赖人们仍然在场来记住。

蔓延的缓慢

“世界比我们认为的相关性更高。因此，我们看到了更多纳西姆·塔勒布所称的‘黑天鹅事件’——罕见事件发生的频率高于它们应该发生的频率，因为世界的相关性更高。”

—理查德·塞勒

HostedGraphite 关于 AWS 宕机如何导致其负载均衡器（不是托管在 AWS 上）瘫痪的事后分析，很好地说明了分布式计算系统中存在多少相关性。在这种情况下，负载均衡器连接池被托管在 AWS 中的客户的慢速连接饱和。应用程序线程、锁和数据库连接也可能发生同样的饱和——任何类型的资源都被慢速操作垄断。

HostedGraphite 的事件是外部强加的缓慢的一个例子，但缓慢通常可能是由于您自己系统中的某个地方的饱和而导致的级联效应，并导致您系统的其他部分减速。Spotify 的一次事件表明了这种蔓延——流媒体服务的前端由于不同微服务中的饱和而变得不健康。对所有请求强制执行截止日期，以及限制请求队列的长度，可以防止这种蔓延。您的服务至少会服务一些流量，并且恢复会更容易，因为您系统中损坏的部分会更少。

应该使用指数退避和一些抖动来限制重试。Square 的一次宕机事件，其中其 Redis 数据存储由于一段代码而过载，该代码在没有退避的情况下重试失败的事务多达 500 次，这表明了过度重试的潜在严重性。断路器设计模式在这里也可能有所帮助。

仪表板的设计应清晰地显示所有资源的利用率、饱和度和错误，以便可以快速发现问题。

惊群效应

通常，当系统处于异常重负载下时，会出现故障场景。这可能是由用户自然产生的，但通常是由系统产生的。午夜开始的 cron 作业激增就是一个古老的例子。如果移动客户端被编程为在同一时间获取更新，则它们也可能成为协调需求的来源（当然，最好是抖动此类请求）。

在预配置时间发生的事件并不是惊群效应的唯一来源。Slack 在短时间内经历了多次宕机，原因是大量客户端断开连接并立即重新连接，导致负载大幅飙升。CircleCI 在 GitLab 宕机结束后看到了严重宕机，导致其数据库中排队的构建激增，数据库变得饱和且非常缓慢。

几乎任何服务都可能成为惊群效应的目标。因此，规划此类突发事件——并测试您的计划是否按预期工作——是必须的。客户端退避和负载脱落通常是此类方法的核心。

如果您的系统必须不断摄取无法丢弃的数据，那么拥有可扩展的方式将此数据缓冲在队列中以供稍后处理至关重要。

自动化系统是复杂的系统

“复杂系统本质上是危险的系统。”

—医学博士理查德·库克

如果您的系统必须不断摄取无法丢弃的数据，那么拥有可扩展的方式将此数据缓冲在队列中以供稍后处理至关重要。

过去几年的趋势是软件操作的自动化程度越来越高。任何可能降低系统容量的自动化操作（例如，擦除磁盘、停用设备、关闭服务作业）都需要谨慎进行。这种自动化操作的事故（由于错误或不正确的调用）可能会非常有效地使您的系统瘫痪，甚至可能以难以恢复的方式瘫痪。

Google 的克里斯蒂娜·舒尔曼和艾蒂安·佩罗在他们的演讲使用安全约束来帮助保护您的数据中心中描述了一些示例。一次事件将 Google 的整个内部内容交付网络 (CDN) 发送到磁盘擦除。

舒尔曼和佩罗建议使用中央服务来管理约束，这限制了破坏性自动化操作可以运行的速度，并注意系统状况（例如，如果服务最近发出过警报，则避免破坏性操作）。

当自动化系统与操作员（或其他自动化系统）交互时，也可能造成严重破坏。Reddit 经历了一次重大宕机事件，原因是其自动化系统重启了一个操作员已停止维护的系统。一旦您拥有多个自动化系统，它们潜在的交互就会变得极其复杂且无法预测。

如果所有这些自动化操作都将日志写入到易于搜索的中央位置，这将有助于应对不可避免的意外情况。自动化系统应始终具有一种机制，使其能够快速关闭（完全关闭或仅针对操作或目标的子集关闭）。

防御黑暗天鹅

这些并不是唯一可能等待袭击您系统的黑天鹅事件。还有许多其他类型的严重问题可以通过诸如金丝雀测试、负载测试、混沌工程、灾难测试和模糊测试等技术来避免——当然，还有冗余和弹性设计。即使有了所有这些，您的系统在某个时候仍然会失败。

为了确保您的组织能够有效地响应，请确保您的主要技术人员和您的领导层在宕机期间有一种协调方式。例如，您可能必须处理的一个令人不愉快的问题是您的网络完全宕机。重要的是要有一个完全独立于您自己的基础设施及其依赖项的故障安全通信渠道。例如，如果您在 AWS 上运行，则使用也在 AWS 上运行的服务作为您的故障安全通信方法不是一个好主意。电话桥或在与您的主系统分开的地方运行的 IRC 服务器是不错的选择。确保每个人都知道通信平台是什么，并练习使用它。

另一个原则是确保您的监控和操作工具尽可能少地依赖您的生产系统。分离您的控制平面和数据平面，以便您即使在系统不健康时也可以进行更改。例如，不要将单个消息队列用于数据处理以及配置更改或监控——使用单独的实例。在 SparkPost：DNS 死亡之日中，杰里米·布洛瑟提出了一个示例，其中关键工具依赖于生产 DNS 设置，而生产 DNS 设置失败了。