Merge pull request #11338 from wxy/20181025-What-breaks-our-systems--A-taxonomy-of-black-swans

PRF&PUB:20181025 What breaks our systems  A taxonomy of black swans

published/20181025 What breaks our systems- A taxonomy of black swans.md

@@ -1,27 +1,27 @@
 让系统崩溃的黑天鹅分类
 ======
 
-在严重的故障发生之前，找到引起问题的异常事件，并修复它。
+> 在严重的故障发生之前，找到引起问题的异常事件，并修复它。
 
 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/black-swan-pair_0.png?itok=MkshwqVg)
 
-黑天鹅用来比喻造成严重影响的小概率事件（比如 2008 年的金融危机）。在生产环境的系统中，黑天鹅是指这样的事情：它引发了你不知道的问题，造成了重大影响，不能快速修复或回滚，也不能用值班说明书上的其他标准响应来解决。它是事发几年后你还在给新人说起的事件。
+<ruby>黑天鹅<rt>Black swan</rt></ruby>用来比喻造成严重影响的小概率事件（比如 2008 年的金融危机）。在生产环境的系统中，黑天鹅是指这样的事情：它引发了你不知道的问题，造成了重大影响，不能快速修复或回滚，也不能用值班说明书上的其他标准响应来解决。它是事发几年后你还在给新人说起的事件。
 
 从定义上看，黑天鹅是不可预测的，不过有时候我们能找到其中的一些模式，针对有关联的某一类问题准备防御措施。
 
-例如，大部分故障的直接原因是变更（代码、环境或配置）。虽然这种方式触发的 bug 是独特的，不可预测的，但是常见的金丝雀发布对避免这类问题有一定的作用，而且自动回滚已经成了一种标准止损策略。
+例如，大部分故障的直接原因是变更（代码、环境或配置）。虽然这种方式触发的 bug 是独特的、不可预测的，但是常见的金丝雀发布对避免这类问题有一定的作用，而且自动回滚已经成了一种标准止损策略。
 
 随着我们的专业性不断成熟，一些其他的问题也正逐渐变得容易理解，被归类到某种风险并有普适的预防策略。
 
 ### 公布出来的黑天鹅事件
 
-所有科技公司都有生产环境的故障，只不过并不是所有公司都会分享他们的事故分析。那些公开讨论事故的公司帮了我们的忙。下列事故都描述了某一类问题，但它们绝对不是只属于一个类别。我们的系统中都有黑天鹅在潜伏着，只是有些人还不知道而已。
+所有科技公司都有生产环境的故障，只不过并不是所有公司都会分享他们的事故分析。那些公开讨论事故的公司帮了我们的忙。下列事故都描述了某一类问题，但它们绝对不是只一个孤例。我们的系统中都有黑天鹅在潜伏着，只是有些人还不知道而已。
 
 #### 达到上限
 
 达到任何类型的限制都会引发严重事故。这类问题的一个典型例子是 2017 年 2 月 [Instapaper 的一次服务中断][1]。我把这份事故报告给任何一个运维工作者看，他们读完都会脊背发凉。Instapaper 生产环境的数据库所在的文件系统有 2 TB 的大小限制，但是数据库服务团队并不知情。在没有任何报错的情况下，数据库不再接受任何写入了。完全恢复需要好几天，而且还得迁移数据库。
 
-资源限制有各式各样的触发场景。Sentry 遇到了 [Postgres 的最大事务 ID 限制][2]。Platform.sh 遇到了[管道缓冲区大小限制][3]。SparkPost [触发了 AWS 的 DDos 保护][4]。Foursquare 在他们的一个 [MongoDB 耗尽内存][5]时遭遇了性能骤降。
+资源限制有各式各样的触发场景。Sentry 遇到了 [Postgres 的最大事务 ID 限制][2]。Platform.sh 遇到了[管道缓冲区大小限制][3]。SparkPost [触发了 AWS 的 DDoS 保护][4]。Foursquare 在他们的一个 [MongoDB 耗尽内存][5]时遭遇了性能骤降。
 
 提前了解系统限制的一个办法是定期做测试。好的压力测试（在生产环境的副本上做）应该包含写入事务，并且应该把每一种数据存储都写到超过当前生产环境的容量。压力测试时很容易忽略的是次要存储（比如 Zookeeper）。如果你是在测试时遇到了资源限制，那么你还有时间去解决问题。鉴于这种资源限制问题的解决方案可能涉及重大的变更（比如数据存储拆分），所以时间是非常宝贵的。
 
@@ -32,7 +32,7 @@
 #### 扩散的慢请求
 
 > “这个世界的关联性远比我们想象中更大。所以我们看到了更多 Nassim Taleb 所说的‘黑天鹅事件’ —— 即罕见事件以更高的频率离谱地发生了，因为世界是相互关联的”
-> — [Richard Thaler][6]
+> —— [Richard Thaler][6]
 
 HostedGraphite 的负载均衡器并没有托管在 AWS 上，却[被 AWS 的服务中断给搞垮了][7]，他们关于这次事故原因的分析报告很好地诠释了分布式计算系统之间存在多么大的关联。在这个事件里，负载均衡器的连接池被来自 AWS 上的客户访问占满了，因为这些连接很耗时。同样的现象还会发生在应用的线程、锁、数据库连接上 —— 任何能被慢操作占满的资源。
 
@@ -40,7 +40,7 @@ HostedGraphite 的负载均衡器并没有托管在 AWS 上，却[被 AWS 的服
 
 重试的间隔应该用指数退避来限制一下，并加入一些时间抖动。Square 有一次服务中断是 [Redis 存储的过载][9]，原因是有一段代码对失败的事务重试了 500 次，没有任何重试退避的方案，也说明了过度重试的潜在风险。另外，针对这种情况，[断路器][10]设计模式也是有用的。
 
-应该设计出监控仪表盘来清晰地展示所有资源的[使用率，饱和度和报错][11]，这样才能快速发现问题。
+应该设计出监控仪表盘来清晰地展示所有资源的[使用率、饱和度和报错][11]，这样才能快速发现问题。
 
 #### 突发的高负载
 
@@ -48,7 +48,7 @@ HostedGraphite 的负载均衡器并没有托管在 AWS 上，却[被 AWS 的服
 
 在预定时刻同时发生的事件并不是突发大流量的唯一原因。Slack 经历过一次短时间内的[多次服务中断][12]，原因是非常多的客户端断开连接后立即重连，造成了突发的大负载。 CircleCI 也经历过一次[严重的服务中断][13]，当时 Gitlab 从故障中恢复了，所以数据库里积累了大量的构建任务队列，服务变得饱和而且缓慢。 
 
-几乎所有的服务都会受突发的高负载所影响。所以对这类可能出现的事情做应急预案——并测试一下预案能否正常工作——是必须的。客户端退避和[减载][14]通常是这些方案的核心。
+几乎所有的服务都会受突发的高负载所影响。所以对这类可能出现的事情做应急预案 —— 并测试一下预案能否正常工作 —— 是必须的。客户端退避和[减载][14]通常是这些方案的核心。
 
 如果你的系统必须不间断地接收数据，并且数据不能被丢掉，关键是用可伸缩的方式把数据缓冲到队列中，后续再处理。
 
@@ -57,7 +57,7 @@ HostedGraphite 的负载均衡器并没有托管在 AWS 上，却[被 AWS 的服
 > “复杂的系统本身就是有风险的系统”  
 >   —— [Richard Cook, MD][15]
 
-过去几年里软件的运维操作趋势是更加自动化。任何可能降低系统容量的自动化操作（比如擦除磁盘，退役设备，关闭服务）都应该谨慎操作。这类自动化操作的故障（由于系统有 bug 或者有不正确的调用）能很快地搞垮你的系统，而且可能很难恢复。
+过去几年里软件的运维操作趋势是更加自动化。任何可能降低系统容量的自动化操作（比如擦除磁盘、退役设备、关闭服务）都应该谨慎操作。这类自动化操作的故障（由于系统有 bug 或者有不正确的调用）能很快地搞垮你的系统，而且可能很难恢复。
 
 谷歌的 Christina Schulman 和 Etienne Perot 在[用安全规约协助保护你的数据中心][16]的演讲中给了一些例子。其中一次事故是将谷歌整个内部的内容分发网络（CDN）提交给了擦除磁盘的自动化系统。
 
@@ -69,11 +69,11 @@ Schulman 和 Perot 建议使用一个中心服务来管理规约，限制破坏
 
 ### 防止黑天鹅事件
 
-可能在等着击垮系统的黑天鹅可不止上面这些。有很多其他的严重问题是能通过一些技术来避免的，像金丝雀发布，压力测试，混沌工程，灾难测试和模糊测试——当然还有冗余性和弹性的设计。但是即使用了这些技术，有时候你的系统还是会有故障。
+可能在等着击垮系统的黑天鹅可不止上面这些。有很多其他的严重问题是能通过一些技术来避免的，像金丝雀发布、压力测试、混沌工程、灾难测试和模糊测试 —— 当然还有冗余性和弹性的设计。但是即使用了这些技术，有时候你的系统还是会有故障。
 
-为了确保你的组织能有效地响应，在服务中断期间，请保证关键技术人员和领导层有办法沟通协调。例如，有一种你可能需要处理的烦人的事情，那就是网络完全中断。拥有故障时仍然可用的通信通道非常重要，这个通信通道要完全独立于你们自己的基础设施和基础设施的依赖。举个例子，假如你使用 AWS，那么把故障时可用的通信服务部署在 AWS 上就不明智了。在和你的主系统无关的地方，运行电话网桥或 IRC 服务器是比较好的方案。确保每个人都知道这个通信平台，并练习使用它。
+为了确保你的组织能有效地响应，在服务中断期间，请保证关键技术人员和领导层有办法沟通协调。例如，有一种你可能需要处理的烦人的事情，那就是网络完全中断。拥有故障时仍然可用的通信通道非常重要，这个通信通道要完全独立于你们自己的基础设施及对其的依赖。举个例子，假如你使用 AWS，那么把故障时可用的通信服务部署在 AWS 上就不明智了。在和你的主系统无关的地方，运行电话网桥或 IRC 服务器是比较好的方案。确保每个人都知道这个通信平台，并练习使用它。
 
-另一个原则是，确保监控和运维工具对生产环境系统的依赖尽可能的少。将控制平面和数据平面分开，你才能在系统不健康的时候做变更。不要让数据处理和配置变更或监控使用同一个消息队列，比如——应该使用不同的消息队列实例。在 [SparkPost: DNS 挂掉的那一天][4] 这个演讲中，Jeremy Blosser 讲了一个这类例子，很关键的工具依赖了生产环境的 DNS 配置，但是生产环境的 DNS 出了问题。
+另一个原则是，确保监控和运维工具对生产环境系统的依赖尽可能的少。将控制平面和数据平面分开，你才能在系统不健康的时候做变更。不要让数据处理和配置变更或监控使用同一个消息队列，比如，应该使用不同的消息队列实例。在 [SparkPost: DNS 挂掉的那一天][4] 这个演讲中，Jeremy Blosser 讲了一个这类例子，很关键的工具依赖了生产环境的 DNS 配置，但是生产环境的 DNS 出了问题。
 
 ### 对抗黑天鹅的心理学
 
@@ -83,7 +83,7 @@ Schulman 和 Perot 建议使用一个中心服务来管理规约，限制破坏
 
 ### 了解更多
 
-关于黑天鹅（或者以前的黑天鹅）事件以及应对策略，还有很多其他的事情可以说。如果你想了解更多，我强烈推荐你去看这两本书，它们是关于生产环境中的弹性和稳定性的：Susan Fowler 写的[生产微服务][19]，还有 Michael T. Nygard 的 [Release It!][20]。
+关于黑天鹅（或者以前的黑天鹅）事件以及应对策略，还有很多其他的事情可以说。如果你想了解更多，我强烈推荐你去看这两本书，它们是关于生产环境中的弹性和稳定性的：Susan Fowler 写的《[生产微服务][19]》，还有 Michael T. Nygard 的 《[Release It!][20]》。
 
 --------------------------------------------------------------------------------
 
@@ -92,7 +92,7 @@ via: https://opensource.com/article/18/10/taxonomy-black-swans
 作者：[Laura Nolan][a]
 选题：[lujun9972][b]
 译者：[BeliteX](https://github.com/belitex)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出