黑天鹅mobi

黑天鹅是影响严重的异常事件（例如2008年金融危机）的隐喻。 在生产系统中，这些事件会触发您不知道遇到的问题，造成重大的可见影响，并且无法通过回拨或呼叫中的剧本的其他一些标准响应来快速轻松地修复。 它们是您在事实发生后数年告诉新工程师的事件。

根据定义，黑天鹅是无法预测的，但有时我们可以找到并使用某些模式来针对各种相关问题创建防御措施。

例如，大部分故障是更改（代码，环境或配置）的直接结果。 以这种方式触发的每个bug都是独特且不可预测的，但是消除所有更改的通用做法在解决此类问题方面有些有效，并且自动回滚已成为标准缓解措施。

随着我们的职业的不断成熟，通过通用的预防策略，其他类型的问题也正逐渐成为易于理解的危险类别。

在野外观察到的黑天鹅

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

击中限制

Instapaper于2017年2月停运 。 我挑战任何携带寻呼机的工程师阅读停机报告时，都不会感到紧张。 Instapaper的生产数据库位于一个文件系统上，该文件系统对于运行该服务的团队来说是未知的，限制为2TB。 在没有警告的情况下，它停止接受写入。 完全恢复需要几天的时间，并且需要迁移其数据库。

极限可能以各种方式发生。 Sentry达到了Postgres中最大交易ID的限制 。 Platform.sh 在管道缓冲区上达到了大小限制 。 SparkPost 触发了AWS的DDoS保护 。 当它的一个数据存储空间用完RAM时，Foursquare陷入了性能瓶颈。

一种获得系统限制的高级知识的方法是定期进行测试。 良好的负载测试（在生产副本上）应该涉及写入事务，并且应该使每个数据存储区超出其当前的生产规模。 忘记测试不是您的主要数据存储的事物（例如Zookeeper）很容易。 如果在测试期间达到极限，则有时间解决问题。 鉴于与限制相关的问题的解决可能涉及重大更改（例如拆分数据存储），因此时间非常宝贵。

在云服务方面，如果您的服务产生异常负载或使用不那么广泛使用的产品或功能（例如较旧或较新的产品或功能），则您更有可能遇到极限。 值得对它们进行负载测试。 但是请先警告您的云提供商。

最后，在已知限制的地方，添加监视（带有相关的文档），以便您知道系统何时达到这些上限。 不要依靠周围的人来记住。

传播缓慢

“世界的关联度远远超出了我们应给予的重视。因此，我们看到了纳西姆·塔勒布（Nassim Taleb）所说的“黑天鹅事件”更多-稀有事件的发生比本来应该发生的频率更高，因为世界之间的关联性更高。”
— 理查德·泰勒

HostedGraphite关于AWS中断如何中断其负载均衡器 （不在AWS上托管）的事后分析是一个很好的例子，说明了分布式计算系统中存在多少关联。 在这种情况下，负载平衡器连接池被AWS托管的客户的缓慢连接所饱和。 应用程序线程，锁和数据库连接可能会发生同样的饱和-任何由缓慢的操作所垄断的资源。

HostedGraphite事件是外部施加的速度缓慢的一个示例，但速度缓慢通常可能是由于您自己系统中某处的饱和导致创建级联并导致系统其他部分速度变慢。 Spotify发生的事件证明了这种扩散-流式传输服务的前端由于其他微服务的饱和而变得不健康。 强制所有请求的截止日期，以及限制请求队列的长度，可以防止这种传播。 您的服务将至少为某些流量提供服务，并且恢复会更容易，因为将减少系统中较少的部分。

重试应以指数回退和一些抖动来限制。 Square发生中断，其Redis数据存储区由于一段代码重试了失败的事务（无回退）最多500次而过载 ，这表明重试次数可能很严重。 断路器设计模式在这里也很有用。

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

雷电群

通常，当系统负载异常大时，会出现故障情况。 这可以由用户自然产生，但通常是由系统引起的。 从午夜开始的大量cron工作就是一个很好的例子。 如果将移动客户端编程为同时获取更新，则它们也可能是协调需求的来源（当然，抖动此类请求要好得多）。

在预先配置的时间发生的事件并不是雷电群的唯一来源。 由于大量客户端断开连接并立即重新连接，因此Slack在短时间内经历了多次中断 ，从而导致大量的负载峰值。 当GitLab中断结束时，CircleCI发生了严重的中断 ，导致数据库中排队的构建数量激增，变得饱和且非常缓慢。

几乎所有服务都可以成为雷群的目标。 因此，必须计划此类事件，并测试您的计划是否按预期工作。 客户退回和减载通常是此类方法的核心。

如果您的系统必须不断摄取无法丢弃的数据，那么采用可扩展的方式将该数据缓冲在队列中以便以后处理就变得至关重要。

自动化系统是复杂的系统

“复杂的系统是本质上有害的系统。”
- 医学博士Richard Cook

在过去的几年中，趋势一直是朝着更加自动化的软件操作方向发展。 任何可能会减少系统容量的操作（例如，擦除磁盘，停用设备，减少服务工作）的自动化都必须谨慎进行。 这种自动化的事故（由于错误或错误的调用而引起）可以非常有效地关闭您的系统，可能以难以恢复的方式。

Google的Christina Schulman和Etienne Perot在他们的演讲“ 利用安全约束帮助保护数据中心”中描述了一些示例。 一次事件使Google的整个内部内容交付网络（CDN）遭到磁盘擦除。

Schulman和Perot建议使用中央服务来管理约束，这限制了破坏性自动化的运行速度，并了解系统状况（例如，如果该服务最近发出警报，则避免破坏性操作）。

自动化系统在与操作员（或其他自动化系统）进行交互时也会造成严重破坏。 Reddit的自动化系统重新启动了操作员已停止进行维护的系统时，发生了严重故障。 一旦拥有多个自动化系统，它们的潜在相互作用将变得极其复杂，无法预测。

如果所有这些自动化操作将日志写入易于搜索的中央位置，则将有助于处理不可避免的意外情况。 自动化系统应始终具有一种允许快速关闭它们的机制（完全或仅针对部分操作或目标）。

防御黑天鹅

这些并不是可能正在等待攻击您系统的唯一黑天鹅。 使用诸如金丝雀，负载测试，混乱工程，灾难测试和模糊测试之类的技术可以避免许多其他严重的问题，当然还可以设计冗余性和弹性。 即使有这些，您的系统有时也会发生故障。

为了确保您的组织可以有效地做出响应，请确保关键技术人员和领导层有办法在停电期间进行协调。 例如，您可能要处理的一个不愉快的问题是网络完全中断。 拥有完全独立于您自己的基础架构及其依赖性的故障安全通信通道非常重要。 例如，如果您在AWS上运行，则将同样在AWS上运行的服务用作故障安全通信方法也不是一个好主意。 与主系统分开运行的电话桥或IRC服务器是不错的选择。 确保每个人都知道通信平台是什么，以及使用该平台的实践。

另一个原则是确保监视和操作工具尽可能少地依赖生产系统。 将控制平面和数据平面分开，以便即使系统运行不正常也可以进行更改。 例如，不要将单个消息队列用于数据处理和配置更改或监视，而要使用单独的实例。 Jeremy Blosser在《 SparkPost：DNS死亡的那一天》中 ，举了一个例子，其中关键工具依赖生产DNS设置，但失败了。

对抗黑天鹅的心理

处理生产中的重大事件可能会带来压力。 对于这些情况，采用结构化的事件管理流程确实有帮助。 许多技术组织（ 包括Google ）成功使用了FEMA的事件指挥系统。 在遇到无法独自解决的重大问题时，应有明确的方式让任何待命的人员寻求帮助。

对于长时间运行的事件，重要的是要确保人们不要在不合理的时间长度内工作，并有休息的时间来进食和睡眠（不受寻呼机的干扰）。 精疲力竭的工程师很容易犯错误或忽略某些可以更快解决问题的事情。

学到更多

关于黑天鹅（或以前的黑天鹅）以及与之打交道的策略还有很多其他事情可以说。 如果您想了解更多信息，我强烈推荐这两本书介绍生产中的弹性和稳定性：Susan Fowler的《 生产就绪微服务》和Michael T. Nygard的Release It！ 。

劳拉·诺兰（Laura Nolan）将于10月29日至31日在美国田纳西州纳什维尔举行的LISA18上展示“破坏 我们的系统的东西：黑天鹅的分类学” 。

翻译自: https://opensource.com/article/18/10/taxonomy-black-swans

黑天鹅mobi