摘要
2025-10-19 23:48 PDT，AWS us-east-1 区域 DynamoDB 的自动化 DNS 管理系统触发潜伏竞态条件，生成空白 DNS 记录且无法自愈，导致依赖 DynamoDB 的 141+ 项 AWS 服务（含 EC2 启动、Lambda、NLB、IAM Identity Center 等）连环中断，约 14.5 小时后才完全恢复。这是一次典型的「自动化清理逻辑 × 分布式竞态」引发的依赖链大崩溃。
# 一个 DNS 端点被清空，141 个服务跟着躺。依赖半径比服务本身大得多。
时间线
23:48竞态触发，DynamoDB 区域端点 DNS 清空，连接失败（PDT 10/19）
00:38工程师确认 DynamoDB DNS 是根源
01:15临时缓解，部分内部服务恢复连接
02:25DNS 信息全部恢复，全局表完成同步
02:40客户缓存 DNS 过期，可正常解析（主中断结束）
05:30NLB 健康检查失败连锁开始
14:20所有 AWS 服务恢复正常（PDT 10/20）
根因
DynamoDB DNS 管理分两个组件：DNS Planner（生成计划）与 DNS Enactor（在 3 个 AZ 独立把计划部署到 Route53）。Enactor A 更新端点时遭遇高延迟反复重试；Enactor B 快速完成新计划并启动清理，误删了 A 正在部署的过时计划 → 区域端点所有 IP 被移除、DNS 变空白、系统陷入不一致、后续任何 Enactor 都无法应用新计划 → 必须人工干预。
- Enactor 在应用前只做一次「新旧计划」校验，因延迟过期失效，未能阻止旧计划覆盖新计划。
- 清理流程把「比刚应用计划陈旧得多」的旧计划删除，却未感知「正在进行中的部署」。
- 一次竞态就清空了全区域 DNS——自动化系统的自我修复反而成了破坏者。
放大因素
AWS 核心服务高度依赖 DNS 做扩展 / 故障隔离 / 低延迟，DynamoDB 单点 DNS 故障通过依赖链放大到 141+ 服务；三阶段（DynamoDB / NLB / EC2）级联，EC2 启动依赖 IAM 与内部网络，恢复缓慢；监控在事件开始后约 22 分钟才察觉，延长了影响。
缓解措施
- 人工干预纠正 DNS 状态，重新注入正确计划。
- 修复 DNS Enactor 的旧计划清理逻辑，避免误删正在部署的计划。
- 强化新旧计划校验的时效性（基于实时版本而非过期快照）。
- 提升依赖 DynamoDB 的控制面韧性，降低单点 DNS 爆炸半径。
经验教训
自动化系统的「清理旧资源」操作必须感知「正在进行中的部署」，否则竞态会自我毁灭；分布式 DNS 管理需有全局一致性与防呆。核心依赖的单点故障半径要用依赖拓扑评估，而非只看服务本身——DynamoDB 的健康不等于上层 141 个服务的健康。
检查清单
- 拉取 DNS Enactor 三 AZ 操作日志，还原竞态窗口
- 确认区域端点 DNS 记录是否被清空 / 变空白
- 查依赖 DynamoDB 的服务清单，评估爆炸半径
- 验证清理流程对新旧计划的时间戳 / 版本校验
- 评估控制面是否仍依赖受损数据面（循环依赖）