为什么下次 AWS 中断会比上一次让你付出更高代价（以及该怎么办）

Source: Dev.to

当 AWS US‑EAST‑1 于 2025 年 10 月 20 日宕机时，超过 3,500 家遍布 60 个国家的公司随之停摆。
并不是因为它们的代码出了问题，而是它们的 架构 有问题。

发生了什么？

DynamoDB 的 DNS 管理系统中的竞争条件触发了一连串连锁反应，导致所有依赖它的服务宕机：

• 认证服务
• 路由层
• 即使是在 其他 AWS 区域运行的公司也发现它们的 “多区域” 部署隐藏地依赖于 US‑EAST‑1。

如果你在事故 Slack 频道里观看了整个过程，你已经知道 100 % 正常运行是个神话。真正的问题不是 你的基础设施是否会失败；而是 当超大云服务商解决问题时，你的架构是否还能继续提供流量。

剧透: 大多数架构做不到。

没有人愿意谈论的数学

可用性 是一个简单的比例：

Availability = MTBF / (MTBF + MTTR)

大多数工程团队执着于 MTBF（我们如何防止故障？）。这是错误的问题。

十月的故障持续了 15 小时。AWS 的 SLA 为大多数服务保证 99.99 % 的可用性，这相当于每年大约 52 分钟的停机时间。一次事故就超过了这个时长。

对于大型企业而言，非计划停机的成本现在平均为 每小时 200 万美元——这并不是因为服务器昂贵，而是因为收入停止、客户信任受损，以及像 DORA（将在 2025 年全面实施）这样的法规对无法通过设计展示弹性的金融机构施加处罚。

实际中的 “九”

看到从四位九到五位九的跳跃了吗？这并不是运维纪律提升了 25 %——而是 根本不同的架构。

Source: …

您已经跨越了复杂性地平线

您的后端并不像喷气发动机那样因果关系线性，而是一个生物系统：

• DNS 小故障会触发数千个微服务的激进重试循环。
• 这会使您的数据库连接池饱和。
• 您的负载均衡器将整个区域标记为宕机。

一个小问题出现，整个系统就会以没人预料的方式崩溃。

系统理论家将其称为 Complexity Horizon：当相互依赖密度达到一定程度时，级联故障不再是需要缓解的风险——而是必须规划的数学必然。

造成十月故障灾难的三大模式

上述每一种模式的根本原因都是相同的：对单一供应商基础设施栈的深度依赖。

大多数团队在回避的真正决定

在每一次重大故障后，行动手册都是一样的：

• 更好的监控
• 更严格的运行手册
• 更多的混沌工程

这些都不错，但它们只是 在同一套刚刚失效的架构内部进行的优化。

真正的决定是结构性的：

是继续在单一云基础上加固弹性，还是在代码与基础设施之间加入编排层？

来自电子邮件的类比

• 过去： 每家公司都雇佣 Exchange Server 工程师（至少两名，因为要有冗余）。电子邮件是一个已被解决的问题，却被每个组织单独重新解决——成本巨大。
• 现在： Google 和 Microsoft 提供电子邮件即服务。你按邮箱付费，之后再也不需要考虑它。Exchange Server 工程师并没有消失；优秀的工程师升到更高的层次，去处理真正能让业务差异化的问题。

云基础设施正处于今天的这一拐点。

每一家提供数字服务的公司都在招聘 平台工程团队，将相同的后端关注点串联起来：密钥管理、服务发现、相互 TLS、地理路由、日志、指标、追踪、可观测性。云为你提供了构建块（Kubernetes‑as‑a‑service、对象存储、托管数据库），但这些原语与生产就绪软件之间的集成工作？这全靠你——每一次都是如此。

整个行业的这种重复工作正是大多数组织无法突破四个 9（99.99%）的原因。他们把所有工程预算都花在重建相同的管道上，而不是投资能够真正改变局面的架构。

实际改变计算的因素

要实现 五个九（每年 5.26 分钟的停机时间），需要满足三件在单一云供应商锁定时几乎不可能做到的条件：

1. 即时跨云故障转移 – 当 AWS 宕机时，您的工作负载必须在几秒钟内切换到 GCP 或 Azure 继续提供服务，而不是几小时。不是“我们会启动灾备环境”，而是 从另一个供应商实时产生流量，毫无中断。这可以把 15 小时的宕机变成对客户而言的无事发生。
2. 零隐藏单点故障 – 所有关键控制平面（DNS、IAM、服务网格控制、配置存储）必须在各供应商之间实现复制，并配备健康检查，以在故障传播前将流量路由走。
3. 统一可观测性与编排 – 一个单一的可视化界面，能够跨云观察、触发自动故障转移，并在工作负载运行位置不同的情况下提供相同的指标和日志。

只有在采用抽象底层供应商的 编排层 时，才能实现实现五个九可用性所需的真正弹性。

TL;DR

• 单云架构脆弱——2025年10月的 AWS 故障已经证明这一点。
• 四个九是大多数团队的上限，因为他们仍然依赖单一供应商的技术栈。
• 五个九需要跨云、零单点故障、编排式故障转移——这是一种根本不同的架构方式。

如果你仍在单云基础上拼凑弹性，那么你只是在为下一个 15 小时的宕机做计划。现在就构建编排层，让你的客户永远感受不到下一次宕机。

故障点。 你的身份层、DNS、路由。它们都不能依赖当前“着火”的供应商。这需要真正的抽象层，而不是仅仅在多个地区部署却暗中依赖单一控制平面的做法。

无需重新架构的可移植性。 如果迁出某个供应商需要数月的工程工作，你就没有弹性。你只有一个非常昂贵的备份方案，在压力下根本无法真正执行。

这正是 Control Plane 诞生的初衷。

该平台在 AWS、Azure、GCP、Oracle 以及本地 基础设施上提供单一编排层。你的代码部署一次，即可在任何地方运行。当某个供应商宕机时，流量会自动切换——无需人工干预、无需运行手册、也不必在凌晨 3 点接到警报。

我们称之为 非粘性层。你的工作负载不再绑定于任何单一供应商，因此为了弹性、成本优化或避免锁定而迁移的成本几乎为零。

您的 CFO 真正关心的部分

仅靠弹性本身就很难进行预算对话。 “多花点钱，这样当坏事发生时，影响会小一些” 是一个很难推销的概念。我能理解。

但大多数团队忽视了一点：提供五个九（99.999%）弹性的架构也会从根本上改变您的成本结构。

• 您不再为闲置的计算资源付费。 传统的云计费会对完整的虚拟机收费，无论您是使用了 100 % 的 CPU 还是只有 3 %。Control Plane 按 millicores（千分之一 vCPU）计费。您只为工作负载实际消耗的计算资源付费，而不是为大部分时间处于空闲状态的整台机器付费。客户可实现 40‑60 % 的云计算成本节省。这是真金白银。

• 您获得了无需承诺的预留实例定价。 与其签订三年合约以获取合理的每核费率，Control Plane 提供的按需定价已经低于大多数供应商的预留实例价格。无需承诺，按比例计费。数学上就是划算。

• 您可以缩减或重新部署平台工程团队。 中位数平台工程师的全额成本为 $180‑220 K。大多数中型公司雇佣 4‑10 名工程师来维护 Control Plane 开箱即用的后端管道。这相当于每年 $700 K‑$2.2 M 的人工成本，用于重新解决已经解决的问题——还未算上这些工程师本可以用来构建的机会成本。

把这些加在一起： 更低的计算成本、无需锁定的溢价，以及一个可以最终专注于产品而非管道的平台工程团队。弹性几乎是额外的奖励。

您实际应该接下来做的事

October 事件并非偶然，它是一次预演。随着 AI 工作负载的增长和后端复杂性的提升，连锁故障将会更加严重。以下是提前应对下一次故障的措施。

1. 接受故障不可避免并为恢复速度进行设计。 您的竞争优势不在于防止故障，而在于您的 Resilience Velocity——架构在无需人工干预的情况下恢复的速度。投资于自动故障转移，而不是更大的运维团队。

2. 在架构层面消除单一文化风险。 多区域并不等同于多云。如果您的“冗余”策略完全依赖于单一供应商的生态系统，您在地理上实现了多样化，却没有降低风险。真正的弹性意味着您的工作负载可以在任何供应商上运行，并能够自动在它们之间切换。

3. 停止重建已经解决的基础设施。 您的平台团队每个月用于维护密钥管理、服务网格和可观测性工具的时间，就是他们没有投入到客户付费产品的时间。将电子邮件从本地 Exchange 迁移到托管服务的同样模式正向后端基础设施蔓延。提前完成此转变的公司将交付更快、成本更低、睡得更安稳。

4. 审计隐藏的依赖关系。 十月事件后，数十家公司发现它们的“多云”部署在身份验证或路由上隐藏依赖于 us‑east‑1。绘制出基础设施所依赖的每项服务，并自问：如果它宕机，我们是否也会随之宕机？

Complexity Horizon 并非可以被克服的东西；它是需要在架构上规避的概念。

在十月毫发无损度过危机的公司，并不是拥有最大运维团队的公司，而是其架构使得供应商故障变得无关紧要的公司。

---

Control Plane 在所有主要云供应商上提供生产级后端基础设施，具备自动跨云故障转移、按需计费的计算资源，以及内置的密钥管理、服务网格和可观测性。

See how it works →