当一个 DNS 记录让互联网瘫痪
Source: Dev.to
在2025年10月20日东部时间凌晨 3 点，俄亥俄州郊区的一款 Ring 门铃突然熄灯。与此同时，曼哈顿的 Robinhood 交易员在比特币仓位的交易过程中看到其冻结。伦敦的纳税人发现，服务于 5000 万用户的 HMRC 政府网关已消失。全球各地的交易大厅、董事会议室和数据中心都出现了同一个问题：一个 DNS 记录是如何让如此多的互联网服务瘫痪的？
1. 发生了什么？
| 时间 (PDT) | 事件 |
|---|---|
| 11:48 PM (10月19日) | 两个 AWS 内部 DNS 管理的自动化进程 同时 尝试更新同一条记录。 |
| 结果 | 产生了 竞争条件，导致 dynamodb.us-east-1.amazonaws.com 的 DNS 条目为空——相当于在有人拨号时把电话号码从目录里抹掉。 |
| 12:38 AM | 工程师在问题出现约 50 分钟 后定位到 DNS 故障。 |
| 2:25 AM | DynamoDB 记录恢复。 |
| ≈ 2:00 PM | 所有受影响服务在 约 15 小时 的中断后全部恢复。 |
1.1 技术连锁
- DynamoDB 中断 → 所有尝试连接的应用收到“错误号码”。
- EC2 Droplet Workflow Manager (DWFM) 无法维护服务器租约 → 健康的服务器被标记为不健康。
- 新实例启动 时缺乏网络连通性。
- 负载均衡器 健康检查失败。
- CloudWatch 停止记录指标。
- Lambda 函数 卡住。
- 安全令牌验证 失效。
损坏的状态在 成千上万的相互关联服务 中传播，使得恢复窗口远远超出 DNS 修复本身的时间。
2. 业务影响
- 知名品牌宕机：Snapchat、Reddit、Robinhood、Coinbase、Amazon 零售、United Airlines（值机）、Ring 门铃、众多银行服务。
- 地域覆盖：来自 60 多个国家 的宕机报告，超过 1700 万 条个人报告。
2.1 直接财务损失
| 来源 | 估计 |
|---|---|
| Parametrix（云保险监测） | 5 – 6.5亿美元 的美国直接损失 |
| Gartner（2014） | 每分钟停机 5,600 美元（企业平均） |
| Ponemon Institute（最新） | 大型组织每分钟 >9,000 美元 |
“任何组织的实际数字在很大程度上取决于行业垂直、组织规模和商业模式。” – 作者注
2.2 间接成本
- 信任流失 – PwC 研究显示：32 % 的客户在一次糟糕体验后会放弃品牌。
- 保险缺口 – 大多数网络安全保单仅在 8 小时以上 的停机后才触发。CyberCube 估计潜在索赔在 3,800 万美元 – 5.81亿美元 之间，然而许多公司发现其曝光远超保额。
- 创新停滞 – 工程团队从路线图转向灭火，导致技术债务累积。
- 声誉责任 – 在始终在线的经济环境中，停机成为竞争劣势；韧性已成为市场差异化因素。
3. Government & Public‑Sector Fallout
3.1 United Kingdom
- HMRC’s Government Gateway（5,000 万用户）宕机。
- 主要银行（Lloyds、Bank of Scotland、Halifax）出现同步故障。
- Dame Meg Hillier，英国财政委员会主席，在议会提出质询：
“当弗吉尼亚的一个数据中心就能导致英国税务服务瘫痪时，为什么我们看似关键的 IT 基础设施却托管在海外？”
- 41 项活跃的 AWS 合同遍布英国政府部门，总额 £1.11 billion（来源：Tussell）。
- HMRC 合同单独计：最高 £350 million（2023 年 12 月 – 2026 年 11 月）。
“为什么如此多的关键英国机构——从 HMRC 到大型银行——都依赖位于美国东海岸的数据中心？” – Mark Boost，Civo 首席执行官
4. 为什么 US‑EAST‑1 是中心
- 最早且最繁忙的 AWS 区域 – 估计处理全球 AWS 流量的 35 %–40 %（行业分析师）。
- 位于 弗吉尼亚北部，绰号 “数据中心巷”，是全球数据中心最密集的地区。
4.1 US‑EAST‑1 历史故障
| 日期 | 原因 | 影响 |
|---|---|---|
| February 2017 | S3 维护期间的人为错误 | 全球 S3 延迟，下游服务中断 |
| November 2020 | 电力中断和网络交换机故障 | 该区域的 EC2、RDS 和 Lambda 部分失效 |
| December 2022 | 影响 Route 53 的 DNS 配置错误 | 多个服务的 DNS 解析失败 |
| July 2024 | 网络拥塞与限流 | CloudFront 和 API Gateway 的延迟升高 |
| October 2025 | 内部 DNS 的竞争条件 → 空的 DynamoDB 记录 | 15 小时的全球故障，影响数百万用户 |
模式：大多数大规模 AWS 事故都源自 US‑EAST‑1，凸显了对该区域高度依赖的架构存在 单点故障 风险。
5. 关键要点与建议
- 分散区域依赖 – 在多个 AWS 区域（或多云）部署关键服务。
- 实现 DNS 弹性 – 使用次要 DNS 提供商、带健康检查的 CNAME 故障转移，以及 DNS 更新的自动验证。
- 设计优雅降级 – 断路器模式、后备数据存储和只读副本策略可以在单个服务故障时保持核心功能运行。
- 审计云保险覆盖 – 确保保单在实际的停机阈值触发，并覆盖间接损失（声誉、监管罚款）。
- 定期进行混沌工程演练 – 模拟 DNS 故障、区域性大范围中断以及依赖服务的失效，以验证恢复流程。
TL;DR
AWS 内部 DNS 系统的竞争条件导致 dynamodb.us-east-1.amazonaws.com 记录被擦除，触发了 15 小时、全球范围的连锁故障，直接损失 5‑6.5亿美元，并暴露了 US‑EAST‑1 区域的严重 单点故障 风险。该事件凸显了 多区域架构、DNS 加固 与 完善的云保险策略 对于保护商业和公共部门服务的迫切需求。
调试导致互联网的大量部分宕机，影响了 Netflix、Slack 以及亚马逊自营零售业务等服务。
八年内五次重大宕机，均来自同一地区
- 遗留决策 – 现有架构是在没有替代方案时构建的。
- 为东海岸用户提供更低延迟 – 靠近主要人口中心。
- 功能可用性 – 某些服务仅在特定地区提供。
- 对“多可用区部署”的错误安慰。
问题：多可用区无法防止区域性故障
同一区域内的可用区（AZ）共享基础设施。
当该基础设施出现故障——DNS、DynamoDB、Kinesis——你的多可用区架构会一起失败。
反驳论点：为何集中也能提升弹性
- 规模与投资 – AWS 每年在基础设施上投入数十亿美元，雇佣数千名安全工程师，并以大多数企业内部根本无法负担的水平运营。
- 正常运行时间记录 – 尽管偶有引人注目的宕机，AWS 仍保持 五年滚动平均正常运行时间为 99.95 %，超过大多数组织在本地数据中心能够实现的水平。
碎片化的成本
- 多云架构 运营复杂 且 维护成本高。
- 跨供应商的数据同步带来 一致性挑战。
- 不同的 API 需要 不同的专业技能。
- 管理三个云提供商的运营开销可能超过多数组织所获的弹性收益。
这些都是合理的论点。问题不在于集中是否有益——显然是有益的——而在于 系统性风险是否已经超过了这些好处，以及仅靠市场力量是否能够解决这些风险。
可能导致故障频率上升的因素之一：AWS 工程团队的变动
Corey Quinn，前 AWS 员工、现任 The Duckbill Group 的行业分析师，已在 The Register 上对该问题作了大量撰写。
- 在 2022 – 2024 年间，AWS 进行了 超过 27,000 人的裁员。
- 内部文件显示 69‑81 % 的“遗憾流失”——公司希望保留但最终失去的员工。
“你可以雇佣一群非常聪明的人，让他们从深层技术角度解释 DNS 的工作原理，但有一样东西是雇不来的——那就是记得当 DNS 出现异常时，去检查角落里看似无关的系统，因为它历来在过去的某些故障中起到了促成作用的人。” – Corey Quinn
注意事项
- 前员工可能信息不完整或带有个人不满。
- AWS 并未公开披露工程人员数量或专业分布。
- 人员变动与故障模式之间的相关性并不等同于因果关系。
2025年10月停电的政治与监管响应
| 行为体 | 声明 / 行动 | 含义 |
|---|---|---|
| 参议员伊丽莎白·沃伦（美国） | “如果一家公司能让整个互联网瘫痪，它就太大了。就这么定了。是时候拆分大科技公司了。”（X） | 突显出两党对集中风险和国家安全影响日益增长的关注。 |
| 竞争与市场管理局（CMA）（英国） | 完成了多年调查；发现 AWS 和微软各占英国云支出 30‑40 %；建议在 《数字市场、竞争与消费者法案 2024》 下授予 “战略市场地位”。 | 使监管机构能够施加具有法律约束力的行为要求；承认锁定效应（年度供应商切换率 ≤1 %）。 |
Source: …
弹性不需要无限预算——它需要战略性思考
1. 分层方法
并非每个系统都需要多区域主动-主动架构。
| 工作负载 | 推荐拓扑 |
|---|---|
| 产生收入的交易系统 | Active‑active multi‑region |
| 内部仪表盘 | Active‑passive or single‑region |
2. 为可观测性而设计
- 你无法修复看不见的问题。
- 实施 跨区域监控、复制延迟跟踪 和 合成事务，在客户发现之前检测问题。
3. 持续测试
- 每月演练日。
- 混沌工程实验。
- 未预告的故障转移测试。
- 记录每个发现的问题，修复后再次测试。
4. 逐步构建多区域能力
- 为关键系统启动 active‑passive failover。
- 明确定义 恢复点目标 (RPO) 和 恢复时间目标 (RTO)。
- 仅在业务影响足以证明时，才升级为 active‑active。
数字背后的现实
AWS 的 99.95 % 五年正常运行时间听起来很惊人——直到你意识到 2025 年 10 月的停机事件仅在十五小时内就耗尽了多年 SLA 预算。
- 这十五小时的停机导致 巨大的财务损失、客户信任的侵蚀，以及 运营中断，这些都不是“开票”可以解决的。
“云并不是一个比喻。它是横跨大西洋的光纤电缆。它是弗吉尼亚北部的冷却系统。它是两个自动化流程在周六晚上 11:48 同时争抢更新同一条 DNS 记录。”
结论
- 建筑会倒塌，内部系统也会出故障。
- 问题不在于 是否 会出现下一个停机——而在于 当它发生时，你是否已经做好准备。
参考文献
- AWS 官方事后总结（2025 年10 月）
- Parametrix 经济估算
- 英国 CMA 云服务调查 – 最终决定（2025 年7 月）
https://gov.uk/cma-cases/cloud-services-market-investigation - 英国政府 AWS 合同（Tussell 数据） – 在 The Register，2025 年10 月29 日 中引用
- Gartner 停机成本研究（2014）
https://blogs.gartner.com - PwC 客户体验报告
https://pwc.com - TeleGeography 分析（70 % 声称有争议）
https://cardinalnews.org
免责声明：
本文所表达的观点仅代表本人个人观点，不代表雇主立场。所有 AWS 中断数据均来源于官方事后总结、Parametrix 与 CyberCube 的行业报告、CMA 调查结果以及经核实的新闻报道。经济影响估算基于已发布的行业方法论，鉴于衡量分布式经济效应的复杂性，应视为近似值。