当自动化成为敌人：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 故障分析报告正是良好运营的典范，将一次痛苦的中断变成了每个人的学习机会。
