专为在部分组件失效时持续运行而设计。

Clavitor 基础设施的每一部分在设计时，都针对每个依赖项、每个供应商、每一层提出了同一个问题：如果它发生故障会怎样？ 我们在整个技术栈中推演了这个问题，并对架构进行了设计，以确保答案始终如一：保管库持续提供服务。

本页列出了我们考量过的内容。具体机制——即我们如何解决每个问题——保持保密；专业客户可在保密协议下获取这些细节。公布威胁列表是对工程设计的坦诚。公布防御措施则是为对手提供免费的架构图。

我们的设计目标

大型云提供商会发生宕机。虽然不常发生，但一旦发生便引人注目，并会导致互联网的大片区域随之瘫痪。我们在设计时假设，任何单一超大规模云服务商最终都会遭遇全球性的严重故障。当这种情况发生时，Clavitor 会继续提供凭据服务。

区域性事件——如数据中心遭无人机袭击、海底光缆被切断、自然灾害或地区战争——可能导致整个云区域离线。2026 年 3 月 1 日，AWS 中东的两个区域在同一起事件中同时瘫痪。我们将其视为前车之鉴，而非假设情况。该架构将区域性事件视为一种客户无感知的常规故障模式。

如果托管您 DNS 的公司发生宕机，即使您技术栈的其他所有部分都运行正常，您的服务也会陷入瘫痪。无论是 Cloudflare、Route 53 还是其他任何主要 DNS 提供商，情况皆是如此。我们考量了当我们的 DNS 提供商遭遇严重故障时会发生什么。

如果在证书需要续期时无法访问您的证书颁发机构，您的 TLS 就会失效。如果证书颁发机构被攻陷，其颁发的所有证书都会失效。我们考量了当 CA 基础设施出现异常时，TLS 会受到什么影响。

如果您的注册商暂停了您的账户或遭到攻陷，无论 DNS 托管在何处，您的域名都会消失或被重定向。我们考量了如果我们的注册商发生故障会怎样。

运营顶级域名（.com、.ai、.io）的组织本身就是一个单点故障。较小的顶级域名由运营深度较浅的小型组织运营。我们考量了如果顶级域名运营商遭遇长达一周的严重故障会怎样。

如果您的电子邮件提供商宕机，账户恢复代码无法送达，注册确认邮件无法送达，客户支持收件箱也会瘫痪。我们考量了当我们的电子邮件提供商无法访问时，身份验证和恢复会受到什么影响——更关键的是，在电子邮件中断期间，产品的其余部分会怎样。

许多服务在电子邮件中断时会退而求其次，使用短信进行验证。我们考量过这一点，但决定不这么做。要求提供手机号码会增加一类我们不想收集的个人数据，使客户面临 SIM 卡劫持攻击的风险，并增加对另一个供应商的依赖。我们选择了更好的路径。

我们用于管理自身基础设施的工具本身也可能宕机：编排网格、协调层、部署流水线。每一项都是一种可能失败的供应商关系。我们考量了每一项的后果，并逐步减少了对供应商运营的控制平面的依赖。

导致全面中断的最可能单一原因是我们自身软件中的缺陷，且该软件同时部署在所有地方。当每个运行副本都以相同方式崩溃时，再多的地理分布也无济于事。我们考量了这一点，并相应地设计了我们的部署实践——金丝雀发布、快速回滚、紧急停止开关。

账户暂停、账单争议、监管扣留和服务条款执行可以一举禁用任何单一供应商关系。我们考量了每个关键供应商关系被单方面终止的后果，并在每一层都进行了防止单一供应商锁定的设计。

某些事件会同时导致多个系统瘫痪——影响多条路由的重大光缆切断、跨服务的协同攻击、同时袭击主系统及其备用系统的自然灾害。我们专门考量了关联故障模式：即在主系统宕机的同时“备用系统”也发生故障。该架构的设计确保没有任何单一事件会同时导致主系统及其故障转移系统瘫痪。

保管库客户不应被迫在安全性与自身数据的可恢复性之间做出选择。我们考量了用户的保管库依赖于他们可能丢失的其他事物的所有环节：他们的手机号码、电子邮件账户、单一设备、单一密码。这些依赖项要么被消除，要么通过工程设计进行了规避。

在发生事故期间，保管库公司需要能够被其自身团队联络到。我们考量了当我们运维人员周围的互联网质量下降时，我们的响应能力会受到什么影响。

密码学并非一成不变。我们考量了我们所依赖的每个密码学原语的长期迁移路径，包括后量子密码学。

我们明确说明了基础设施工程所能实现的极限。

卡林顿级太阳事件

会导致全球互联网瘫痪数天。基础设施层面的任何措施都无济于事；反正客户也无法访问任何服务。

针对 Clavitor 自身的跨司法管辖区协同国家级行动

这类事件是任何商业基础设施都无法单方面防御的。

我们对这些情况保持坦诚——并在假设它们不会发生的前提下，将其他所有系统设计为具备韧性。

上述列表是我们考量过的内容。关于每项防御措施如何设计的细节——具体拓扑、供应商选择、切换程序、密码学协议——会在采购过程中，通过保密协议与企业客户及其安全团队共享。