这是一篇长文，是我在过去几十年构建大规模数据库和存储系统的经验总结和随想。

在超大規模（例如，超过10,000个节点）的系统中，故障随时都在发生。关联性故障（Correlated failures）甚至更为常见。在这样的规模下，要实现所有客户集群的零宕机时间是不切实际的。因此，所有的焦点都应该放在如何减小“爆炸半径”（blast radius）上。

所谓的“爆炸半径管理”（blast radius mgmt），指的就是减少受影响的客户数量，或降低某个特定客户受影响的操作百分比。

当您设计容错系统时，可以思考以下一些技术：

💥 实例崩溃（低爆炸半径）：您通常会故障转移（failover）到另一个实例。对于有状态系统，这通过复制（replication）来实现。对于无状态系统，则是将连接重新平衡（rebalancing）到其他可用实例。如果连接本身是有状态的，那么重新建立连接会变得很棘手。此外，如果一个实例正在为多个客户提供服务，您不会希望将所有负载都转移到另一个实例上，从而导致该节点饱和。您需要将负载重新分配到多个实例上。

⚙️ 实例的某个子系统故障（低爆炸半径）：例如，某个特定的卷（volume）可能会失败。在这种情况下，您通常也会选择直接关停整个实例并故障转移到另一个。因为处理局部故障（partial failures）比处理完全故障（full failure）更麻烦。这里适用第一点中的故障转移规则。

⚠️ 多个实例同时故障（中等爆炸半径）：对于有状态系统，这归结为您愿意设置多少个副本（replica）。这变成了一个成本与可用性之间的权衡问题。同时还存在延迟问题。通过复制，您的写入延迟将取决于写入法定数量（write quorum）中最慢的那个副本的延迟。副本越多，法定数量中至少包含一个慢副本的概率就越大。对于无状态系统，您需要有足够的容量来承接故障实例的负载。一个好的系统建模方式是，预先决定系统应该能够承受多少个关联性故障。例如，N<=2意味着系统在最多2个实例故障时仍能保持可用。
这里有一个有趣的观点是，您可以在云上应用一些巧妙的爆炸半径技术来确保最小化关联性故障。例如，AWS EC2提供放置组（placement groups）。您可以将副本放置在不同的放置组中，这能确保所有副本都位于不同的物理硬件上。

🏢 物理机（Bare metal machine）故障（中等爆炸半径）：为了成本效益，您可能会在一台物理机上托管多个虚拟机（VM）。当物理机发生故障时，爆炸半径会大得多。您需要具备将负载故障转移到不同物理机上的不同虚拟机上的能力。能够吸收负载的机器越多，故障转移就越容易。这需要在使用率和您希望为每台物理机维持的稳态（steady state）利用率之间进行权衡。

🌍 整个可用区（zone）和区域（region）故障（高爆炸半径）：这需要可用区级别和区域级别的故障转移。通过跨区域同步复制（sync replication）可以实现无数据丢失的区域故障转移，但在大多数情况下这并不现实。对于跨可用区复制，您通常希望客户端也一同转移到相同的可用区，以避免跨可用区网络成本。如果您处理的是像Kafka这样的高带宽服务，这个问题会更加突出。

🌐 网络的部分或完全故障（高爆炸半径）：网络的部分故障或网络分区（network partitions）是设计中最难应对的情况之一。您内部的健康检查可能认为一切正常，而客户却无法连接。因此，您总是需要一个从外部进行连接的健康检查。当网络发生故障时，困难的部分是快速检测到它。一旦检测到，标准的故障转移机制就是处理流程。

📡 DNS等全局系统故障（高爆炸半径）：这类故障非常可怕，常常导致一些最大规模的服务中断。您通常需要为这些全局系统设置冗余，以确保您的系统能够抵御这些故障。

🔧 配置、软件和维护变更（爆炸半径可低可高，取决于您的系统设计）：到目前为止，导致服务影响的最常见原因是发布新变更。您需要将您的集群划分为多个单元（cell），并严格控制部署的顺序以及在每个单元升级后如何进行测试。在我过去工作过的几乎所有公司中，我们都必须构建一个大规模的集群管理器（fleet mgr），以自动化地逐个单元地推送新配置、新软件或执行维护（如安全补丁、操作系统升级）。您还需要具备回滚（rollback）的能力。最关键的是，任何变更的回滚都不能有兼容性问题，以确保故障时间最小化。

☸️ Kubernetes故障（爆炸半径可低可高，取决于您打包了多少应用）：K8s管理着成千上万的虚拟机（或物理机），单个K8s集群的故障无疑会影响大量客户。您通常需要进行K8s的健康检查并执行故障转移。这有点棘手，因为您需要构建一种能力，能将一个K8s集群中的实例故障转移到多个其他的K8s集群中，以实现良好的负载管理。您可以保留一些空的K8s集群，以便在这类故障发生时接管工作。

🧩 外部系统（爆炸半径可低可高，取决于您的设计）：您的系统会依赖许多外部系统，如认证、存储、证书、指标等。您必须设计您的系统，使得非关键外部服务的故障绝不影响您的服务质量。例如，用量追踪服务的失败不应影响您的核心服务。您还应该将外部系统依赖的数量保持在最低限度。对于关键的第三方系统，您需要有冗余，并确保第三方提供高可用性保证。

🚦 数据平面（Data plane）与控制平面（Control plane）：控制平面操作是辅助系统管理的元数据操作。数据平面操作是实际的业务数据读写。例如，对于数据库来说，配置一个数据库是控制平面操作，而写入和读取数据是数据平面操作。控制平面操作本身也分层级（层层嵌套）。有全局控制平面操作、区域控制平面操作和单系统级别的控制平面操作。将它们隔离开来，并确保它们的故障不影响数据平面操作，是至关重要的。

这里可能还有很多我没有涵盖到的内容，但重要的是要理解，将一个系统简单地归类为“可用”或“不可用”是非常困难的。故障有许多级别，而爆炸半径决定了受影响的客户数量。构建出色的弹性系统，并理解您在成本、时间和可用性之间所做的权衡。

5月8日第二只金钱豹被捕获后，对第三只金钱豹的抓捕工作持续了一个月的时间，并采取了监控、诱捕、巡山等措施，但仍没有找到金钱豹的消息。搜捕工作一个月后，停止了对第三只金钱豹的搜捕工作。