当自动化成为敌人:AWS 2025年10月DynamoDB故障的教训

上周,AWS 发布了关于 10 月 19-20 日大规模服务中断的故障分析报告,这次中断导致 DynamoDB 崩溃,并波及 us-east-1 区域的数十个服务。在周末仔细阅读了这份异常透明的报告后,我想分享一些关于这次事件对现代基础设施运营的启示。
高级自动化的讽刺
最让我印象深刻的是,这次事件的问题不在于故障本身,而在于 AWS 的高级自动化系统反而成为了最大的敌人。DynamoDB 团队构建了一个优雅的 DNS 管理系统,具有多个安全机制、独立组件和精心的编排。然而,两个 DNS 执行器之间罕见的竞争条件使这一高级机制自相矛盾,自动化系统实际上阻碍了恢复工作。
仔细想想这一点。本应确保高可用性的系统反而成为了恢复的障碍。这让我想起了分布式系统的一个基本原则:复杂性是可靠性的敌人。有时,我们的聪明解决方案会带来我们从未预料到的问题。
在我的大规模系统运营经验中,我学到了没有逃生门的自动化系统就像定时炸弹。你需要我称之为“打破玻璃”的程序——即在自动化系统失控时,人类可以介入并覆盖自动化操作的方法。AWS 的报告提到他们不得不采取手动干预,但显然,这不是一个演练得很好的程序,从恢复时间上就能看出来。
无人预料的连锁反应
从 DynamoDB 的 DNS 故障到整个区域的崩溃,这一过程读起来就像是一堂关于连锁故障的大师课。首先,DynamoDB 崩溃了。然后,由于 DWFM 依赖于 DynamoDB,EC2 无法启动新实例。接着,Network Manager 由于无法传播配置而积压了大量任务。然后,NLB 开始波动,因为健康检查在未完成网络配置的实例上失败了。最后,Lambda、ECS、EKS 和十几个其他服务像多米诺骨牌一样倒下。
特别值得学习的是,恢复过程本身也带来了新的问题。当 DWFM 尝试同时与数十万个 droplet 重新建立租约时,它陷入了报告中称为“拥塞崩溃”的状态——基本上是自诱导的拒绝服务。我在分布式系统的恢复过程中见过这种模式。药方有时比疾病本身更糟糕。
团队的解决方案虽然可能是出于绝望,但非常聪明:他们选择性地重启了 DWFM 主机以清除队列,同时限制了传入请求。这相当于分布式系统中的“关机再开机”,但具有手术般的精确度。有时,老办法就是最好的办法。
被遗忘的 DNS 服务
DNS 故障特别棘手,因为 DNS 是现代云架构的基础。我们用它进行服务发现、负载均衡、流量管理和故障转移。然而,有多少人真正思考过当 DNS 完全失效时会发生什么?不是返回错误答案,不是响应缓慢,而是根本没有任何响应?
AWS 的架构中,仅在单个区域中,DNS 就管理着数十万个 DynamoDB 记录。这在超大规模操作中并不罕见,但当事情出错时,它确实会带来巨大的影响范围。报告提到,即使在 02:25 恢复了 DNS 记录,客户仍需等待 15 分钟才能重新访问,因为 DNS 缓存过期。这就是 DNS 故障的险恶之处——即使你修复了问题,你还在等待分布式缓存的同步。
在我的基础设施工作中,我开始为关键服务维护静态 IP 备用列表,通过配置管理而不是 DNS 分发。这不优雅,也不完美扩展,但当 DNS 失效时,这些硬编码的 IP 可能是你的唯一生命线。有时,你需要双保险。
健康检查失控
NLB 健康检查的情况特别值得关注,因为它代表了一种我在生产系统中反复见到的故障模式。健康检查的目的是从服务中移除不健康的节点,但如果健康检查系统本身对“健康”产生了误解,会发生什么?
在这种情况下,NLB 正在健康检查那些尚未收到网络配置的实例。实例本身是正常的,负载均衡器也是正常的,但健康检查仍然失败。这导致了一个节点不断被移除和重新添加到服务中的波动情况。健康检查系统试图完成其工作,实际上却使情况变得更糟。
临时解决方案非常务实:他们在 09:36 关闭了自动故障转移。有时,解决一个行为异常的自动系统的最佳方法是让它变得更不自动。这在生产环境中需要勇气,基本上是不带安全网飞行,但这是正确的决定。
从一线恢复中学到的教训
一个引起我注意的细节是,不同服务的恢复速度差异巨大。DynamoDB 在 02:40 基本修复,但 EC2 直到 13:50 才完全恢复。Lambda 在 06:00 清除了积压任务,但在 07:04 又因 NLB 问题导致内部基础设施终止。
这种错落有致的恢复模式表明团队在某种程度上独立运作,各自扑灭自己的火灾。虽然这种并行恢复努力有其优势,但也可能导致一个团队的恢复工作无意中影响另一个团队的系统。当 NLB 问题撤销了 Lambda 团队的恢复工作时,Lambda 团队可能并不高兴。
报告还揭示了客户很少看到的 AWS 内部依赖关系。例如,Redshift 在解析用户组时,所有区域都会调用 us-east-1 的 IAM API。这种隐藏的跨区域依赖关系正是将区域问题转变为全球问题的根源。我敢打赌,AWS 现在正在审计所有服务,寻找类似的反模式。
对我们的启示
那么,我们这些运行较小规模操作的人应该从这次事件中学到什么?首先,我们需要承认,如果 AWS 都能遭受 14.5 小时的中断,那么我们谁都不是免疫的。问题不在于你是否会遇到重大事件,而在于你是否准备好了应对它。
从绘制服务依赖关系开始。真正地绘制它们,不仅仅是显而易见的依赖关系,还有隐藏的依赖关系。你的 A 区域服务是否因任何原因调用 B 区域的服务?你是否有共享命运的服务,因为它们都依赖于同一个底层系统?这些依赖链正是连锁故障滋生的地方。
接下来,思考你的自动化的故障模式。你的自动化系统是否会陷入一种阻止恢复的状态?你是否有手动覆盖程序?你是否真正测试过它们?我想到的是古老的军事格言:任何计划在与敌人的接触中都无法幸存。除非你内置了逃生门,否则你的自动化系统在遇到新的故障模式时也无法幸存。
考虑你的健康检查和自动恢复方法。你是否准备好在这些系统开始行为异常时禁用它们?你是否有足够的可观测性来判断健康检查是否弊大于利?有时,治疗真的比疾病更糟糕。
最后,练习你的事件响应。AWS 显然拥有才华横溢的工程师和坚实的程序,但这次事件仍花了 14.5 小时才完全解决。部分原因是他们操作的规模巨大,但部分原因可能是这种特定故障模式的罕见性。竞争条件可能已经潜伏多年,等待着特定条件的出现。当它最终触发时,团队是在边学边做。
谦卑的真相
这次事件对我们所有从事基础设施的人来说都是一个谦卑的教训。它表明,即使拥有世界级的工程、广泛的自动化和几乎无限的资源,复杂系统仍然会以令人惊讶的方式失败。一个可能已经存在多年竞争条件最终在特定条件下爆发。两个 DNS 执行器以略微不同的速度运行,最终删除了它们本应保护的记录。
从二十年的运营经验中,我学到的一件事是,分布式系统总是在教我们新的故障方式。每次事件都增加了我们的集体知识,每次故障分析都教会了我们一些我们不知道自己不知道的东西。AWS 在分享这些细节方面的透明度是对整个行业的馈赠。
在我撰写这篇文章时,全世界成千上万的工程师可能正在审查他们自己的 DNS 管理系统、健康检查配置和服务依赖关系。他们在问一些令人不安的问题,关于自己的自动化系统是否也潜藏着沉睡的龙。这就是我们作为一个行业不断进步的方式,一次痛苦的教训接一次。
下次有人告诉你现代云基础设施已经解决了可靠性问题时,指给他们看这次事件。我们已经取得了惊人的进展,但复杂系统总是会找到新的、创造性的失败方式。我们的工作不是防止所有故障,而是确保我们能够快速恢复并从每次故障中学习。从这个意义上说,这份 AWS 故障分析报告正是良好运营的典范,将一次痛苦的中断变成了每个人的学习机会。


