常见故障原因

我们说一个系统在不再提供符合其规范的服务给用户时发生了故障^[1]。故障是由故障引起的：内部组件的故障或系统所依赖的外部依赖的故障。一些故障可以被容忍，并且完全没有对用户可见的影响，而其他故障会导致故障发生。

为了构建容错应用程序，我们首先需要了解可能出现什么问题。在接下来的几节中，我们将探讨一些最常见的故障根本原因。到最后，您可能会想知道如何容忍所有这些不同类型的故障。

硬件故障

机器的任何物理部件都可能发生故障。硬盘驱动器、内存模块、电源供应、主板、固态硬盘、网络接口卡（NIC）或中央处理器（CPU）等，都可能因为各种原因停止工作。在某些情况下，硬件故障还可能导致数据损坏。如果这还不够，整个数据中心可能会因为停电或自然灾害而宕机。

正如我们稍后将讨论的，我们可以通过冗余来解决许多这些基础设施故障。您可能会认为这些故障是导致分布式应用程序失败的主要原因，但实际上，它们往往因为非常平凡的原因而失败。

错误的错误处理

一项来自2014年的研究^[2]对来自五个流行的分布式数据存储的用户报告的故障进行了分析，发现绝大多数灾难性故障是由于错误处理非致命错误不正确而造成的。

在大多数情况下，错误处理中的错误可以通过简单的测试检测出来。例如，一些处理程序完全忽略了错误。其他的捕获了过于通用的异常，比如Java中的Exception，并且没有充分的理由就中止了整个进程。还有一些处理程序只实现了部分功能，甚至包含了“FIXME”和“TODO”的注释。

事后看来，这或许并不令人意外，因为错误处理往往是一个事后考虑的问题。这就是Go语言如此强调错误处理的原因。我们将更详细地研究测试大型分布式应用程序的最佳实践。

配置更改

配置更改是灾难性故障^[3]的主要根本原因之一。问题不仅在于配置错误，还在于对有效配置进行更改以启用很少使用的功能，这些功能不再按预期工作（或从未工作过）。

使配置更改^[4]特别危险的是，它们的影响可能会被延迟。如果应用程序仅在实际需要时读取配置值，那么无效的值可能仅在更改后的几小时或几天后生效，从而逃避了早期检测。

这就是为什么配置更改应该像代码更改一样进行版本控制、测试和发布，它们的验证应该在更改发生时预防性进行。我们将在持续部署的背景下讨论代码和配置更改的安全发布实践。

单点故障

单点故障（SPOF）是一个组件，其故障会将整个系统一同带下线。实际上，系统可能有多个SPOF。

人类是很好的SPOF，如果将他们置于一个可以单独导致灾难性故障的位置，那么可以肯定他们最终会这样做。例如，当某人需要按特定顺序手动执行一系列操作步骤而不犯任何错误时，人为故障通常会发生。另一方面，计算机擅长执行指令，这就是为什么应该尽可能地利用自动化。

另一个常见的SPOF是DNS^[5]。如果客户端无法解析应用程序的域名，它们将无法连接到该应用程序。出现这种情况的原因有很多，从域名过期^[6]到整个根级域名宕机^[7]。

同样，应用程序用于其HTTP端点的TLS证书也是SPOF^[8]。如果证书过期，客户端将无法与应用程序建立安全连接。

理想情况下，在设计系统时应该识别出SPOF。检测它们的最佳方法是检查每个系统组件，并询问如果它们故障会发生什么。一些SPOF可以通过引入冗余来进行架构化处理，而其他一些则无法处理。在这种情况下，唯一的选择是减少SPOF的故障范围，即当SPOF发生故障时对系统造成的损害。我们稍后将讨论的许多弹性模式可以减少故障的范围。

网络故障

当客户端向服务器发送请求时，它期望在一段时间后从服务器收到响应。在最好的情况下，它在发送请求后不久即收到响应。如果这种情况不发生，客户端有两个选择：继续等待或使用超时异常或错误失败请求。

引用链接

[1] 故障: https://resources.sei.cmu.edu/asset_files/TechnicalReport/1992_005_001_16112.pdf
[2] 研究: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf
[3] 灾难性故障: https://github.com/danluu/post-mortems#config-errors
[4] 配置更改: https://www.usenix.org/system/files/conference/osdi16/osdi16-xu.pdf
[5] DNS: https://twitter.com/ahidalgosre/status/1315345619926609920?lang=en-GB
[6] 域名过期: [https://techcrunch.com/2010/](https://techcrunch.com/2010/)03/27/foursquare-offline
[7] 宕机: https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20
[8] SPOF: https://www.theverge.com/2020/2/3/21120248/microsoft-teams-down-outage-certificate-issue-status