2025年10月19日亚马逊us-east-1宕机事故反思
本周一，AWS us-east-1区域遭遇十余年来最严重的停机事故。此次故障持续超过14小时，影响140项AWS服务，其中关键的EC2服务也未能幸免。服务等级协议(SLA)全面失效，预计将造成八位数收入损失。在此之前，我在行业工作约7年，从未亲历过公共云故障导致生产环境彻底瘫痪。我始终认为AWS的可靠性堪称卓越，处于行业领先地位。
究竟发生了什么？
众多优秀工程师面对这场重大事故，纷纷用简单解释来掩盖真相：人才流失；竞争条件；总是DNS问题；云不可靠，还是本地部署吧。若试图用网络评论概括如此规模的故障，你永远无法理解软件可靠性的本质。坦白说，即便读完AWS长达4000字的总结并思考数小时，我仍未能完全参透。但我将暂缓发表热议观点，尝试深入剖析。
在AWS发布《服务中断总结》https://aws.amazon.com/message/101925前，我已撰写了Modal公司关于us-east-1区域事故的内部事后分析。由于我们的控制平面位于us-east-1区域，此次故障对我们造成了严重影响。与数百家受影响企业一样，我们渴望一窥所依赖的IaaS底层运作机制。
这份在故障发生数天后发布的公开总结，为我们打开了一扇窥探全球最成熟超大规模云服务商工程运作机制的小窗。我将剖析此次故障的三个阶段，指出关键特征，并尝试在有限信息下提炼出本次大规模故障的若干教训。继续阅读前，建议仔细研读总结报告。
一次服务故障，引发百余次连锁崩溃
为何10月20日UTC时间6:48发生的DynamoDB服务故障，最终演变为140项服务的连锁崩溃？
AWS将总结报告拆分为DynamoDB、EC2和网络负载均衡器(NLB)的独立章节，并在末尾合并列出其余137个受影响服务(包括Lambda、IAM、STS、Elasticache、ECR、Secrets Manager)。
这种文档结构恰好契合了故障的蔓延路径。
DynamoDB引发了所有后续服务故障：其一，EC2依赖DynamoDB运行，导致EC2瘫痪；其二，部分服务直接依赖DynamoDB。由于EC2和DynamoDB在AWS内部服务实现中被广泛使用，这场“野火”迅速蔓延至us-east-1区域约70%的AWS服务。
众所周知，AWS采用“自家云服务自用”模式，例如DynamoDB既用于Amazon.com的构建，也支撑着其他AWS服务。DynamoDB和EC2是AWS架构中的“第一层”1基础服务。一旦它们瘫痪，基本所有其他服务都会随之停摆。
简单的竞争条件
此次问题的根本原因在于DynamoDB DNS管理系统中存在潜在的竞争条件，导致服务区域端点(** dynamodb.us-east-1.amazonaws.com **)的DNS记录错误地清空，而自动化修复机制未能及时处理。
AWS DynamoDB为dynamodb.us-east-1.amazonaws.com维护大规模自动化DNS负载均衡系统实属必然——该端点可能是仅次于s3.us-east-1.amazonaws.com的SaaS领域最受冲击的节点。
真正令人惊讶的是，一个典型的检查时与使用时不同步(TOCTOU)缺陷竟在系统中潜伏至本周一才暴露。或许我太天真，但本以为AWS这样一家*平均处理1亿次RPS的服务商，早已从关键服务中清除了TOCTOU漏洞。
在长达786字的冗长段落中，他们阐述了问题根源，我尝试简要总结如下：
为维持dynamodb.us-east-1.amazonaws.com所有DNS条目的更新，他们运行着三个DNS执行器，分别部署在us-east-1a、us-east-1b、us-east1c可用区。这三个执行器在执行数据变更时 未 进行协调。
为确保弹性，DNS执行器在三个不同可用区(AZ)中冗余且完全独立运行。
其中一个执行器(例如us-east-1a)出现 极端延迟。虽然未说明延迟原因，但据我判断其严重程度(10-100倍)是基于系统设计允许一定平均延迟偏差的设定。
他们采用典型的“保留最近N个”垃圾回收机制来清除过时的DNS计划。Modal也采用此机制回收旧机器镜像。关键在于，最近N个计划中 绝不能 包含活跃资源。我推测DynamoDB团队选择了较大的N值以确保“永不”删除活跃计划，这意味着Enactor在us-east-1a区域的延迟极其严重。
粗略而言，事故几乎总是源于对某项或多项事件发生概率的错误预判。——《为何应阅读事故报告》，C·迈克尔·霍洛威
缓慢执行器的计划超出了N代安全窗口期，成为可删除的过期计划。正是该过期计划的删除，将“DNS计划过时”的性能退化演变为“DNS条目清零”的全面故障。
现在回到TOCTOU问题：为何执行器在N次计划变异中仅允许进行一次计划过时检查？我推测原因在于：向DNS规划器查询过时状态的开销远高于执行计划变异操作。若针对N次快速计划变异执行N次检查，不仅性能低下，且 看似 毫无必要*。2
若无此TOCTOU漏洞，就不会出现“过期DNS计划”导致的性能退化，也就不会误删活动计划的情况。3
目前已发现两处缺陷，但问题不止于此。运用事故成因的瑞士奶酪模型，我们还能穿过更多埃曼塔奶酪般的漏洞。
删除活动计划本是灾难性操作，但执行器的清理阶段却未对此进行检查。这种缺失的防护机制显然构成另一项缺陷。
有人质疑执行器删除规划器的计划设计怪异，但我认为这完全合理。规划器被设计为纯粹的只追加输出系统。执行器依据计划日志推进工作，并维护活动DNS记录的窗口。若规划器删除计划，则同时对Route53进行写入操作。4
删除“活动”计划后，执行器的状态遭到破坏且无法恢复，必须通过“人工干预”才能修复，耗时超过2小时。
令人惊讶的是，这种破坏和DNS“空状态”竟未被自动恢复。dynamodb.us-east-1.amazonaws.com关联的IP地址数量为 零。在生产环境中这堪称灾难性故障。执行器难道不能回退到某个非空的可用状态以恢复部分服务吗？
对于DynamoDB团队之外分析此次系统故障的人员而言，不仅要面对事后偏见的困扰，还需克服“窥孔观察”的局限性。我不敢妄言补救方案或断言根本原因，但此次DynamoDB DNS故障中存在诸多熟悉的模式，未来在设计文档中我将重点关注这些迹象。
根本原因
事件链中包含哪些事件取决于所采用的停止规则——该规则决定了解释性事件序列追溯的时限。尽管链首事件常被标记为“触发事件”或“根本原因”，但触发事件的选择具有任意性，此前事件与条件始终可被追加。——构建更安全的世界
阅读摘要中关于DynamoDB的部分后，有人试图宣称发现了根本原因：竞争条件。
当今软件行业将根本原因分析(RCA)视为事后分析文档的核心环节。搜索“事后分析模板”，几乎所有模板都包含根因分析章节。排名首位的Atlassian模板亦不例外。几年前我正是参考Atlassian模板，将其复制为Modal的内部标准模板。
但顶尖可靠性工程师已不再执着于根因分析。这种模型虽有用，却无法完整解释事件发生机制。
最明显的问题在于RCA存在无限递归困境。某可用区内Enactor极端延迟的成因虽未明确，但作为竞态条件的前置事件可视为根本原因。然而若该延迟由高数据包丢失率引发，那么 丢包率的成因 又是什么？如此循环往复，犹如逆流而上的船只——
更有趣的是，RCA引发的短视现象。没错，极端延迟确实触发了竞争条件漏洞——这只是一个 诱发事件，但它只是DynamoDB系统动态中可能出现的众多潜在故障之一。正如上文瑞士奶酪分析所示，一旦延迟出现，多重控制机制便会叠加成不可恢复的故障。
当今顶尖的分布式系统工程师(包括谷歌的SRE团队)将故障分析视为控制问题。
我们不再追问“哪个软件服务故障了？”而是探究“系统各部分间的交互控制是否存在缺陷？” ——谷歌SRE的演进
追溯控制问题时，我们不仅看到竞态删除，更需审视延迟、垃圾回收、守护机制(或其缺失)、状态损坏、告警系统及人工操作环节。
拥塞性崩溃与亚稳态故障：EC2加入这场灾难
本次事件摘要可能包含首个公开提及 AWS Droplet 及Droplet工作流管理器(DWFM)的记录。Droplet是所有EC2实例运行的物理服务器。
DWFM依赖DynamoDB完成“状态检查”，即DWFM与每台受管物理服务器之间的心跳通信。若某台服务器的心跳停止，DWFM对该服务器的控制权即告中断。失去控制权后，EC2实例将无法创建或进行状态转换，导致UTC时间6:48至20:50期间所有实例未设置为RUNNING状态的用户均受影响。天啊。
DynamoDB作为DWFM的关键依赖项，直接引发了EC2服务故障。但真正耐人寻味的是：当DynamoDB于UTC时间9:40左右恢复后，EC2服务竟持续 瘫痪或降级长达11小时。
经历亚稳态故障的系统状态与转换。摘自《分布式系统中的亚稳态故障》。
在EC2正常运行时，DWFM管理着大量(约10^6)与物理服务器关联的有效租约，以及极少量(约10^2)已断开租约——后者正由管理器积极尝试重建。
此次持续近3小时的DynamoDB故障导致大规模心跳超时，造成数千条租约失效。据估算，失效租约数量至少达到10^5条，是正常值的三倍。
面对庞大的待重建租约队列，DWFM系统存在两种可能的演变路径：其一是缓慢渐进地消减租约积压(恢复状态)；其二是 拥塞性崩溃——租约队列持续高位运行(形成“持续效应”)，直至人工干预。
不幸的是，DWFM系统最终陷入了拥塞性崩溃。
…由于实例数量庞大，建立新实例租约耗时过长，导致工作在超时前无法完成。——AWS总结
最值得探讨的是崩溃成因：工作单元完成是否存在O(队列深度)的复杂度？即数据仓库管理框架并非逐个处理租约，而是采用全有或全无的批量处理模式？抑或该框架演变为“雷鸣般的大群”，导致其与Droplets之间的下游组件不堪重负？
EC2的拥塞性崩溃只能通过工程师手动干预恢复——他们重启DWFM服务器，推测是为了清空内存中队列的租约任务，从而恢复系统吞吐量。
我长期关注AWS杰出工程师Marc Brooker的公开博客，他在Lambda、EBS和EC2领域均有重要贡献。这次故障后他肯定很兴奋，毕竟他多年来一直在宣扬亚稳态故障分析。
亚稳态故障状态的存在及其危险性，在AWS工程领导层内部可能已广为人知约四年之久。然而这次故障竟在他们引以为傲的EC2上爆发。我正热切期待Marc的博客文章。
NLB
协调世界时16:00左右，在如今内部闻名的#incident-41-hfm_failures事件频道中，我开始调查Sandbox产品性能下降的问题。经查发现，AWS NLB故障导致Modal客户端无法与api.modal.com建立gRPC连接(该域名指向NLB负载均衡器)。
NLB服务中断的原因在于：当创建新EC2实例或实例发生状态转换(如停止)时，EC2的 网络管理器 负责传播网络配置，而该管理器因积压工作量过大而处理滞后。
此次NLB服务中断最值得关注的是：由于网络配置滞后导致健康检查系统接收错误反馈，进而错误执行了可用区故障转移。
反复变化的健康检查结果加剧了健康检查子系统的负载，导致其性能下降，进而引发健康检查延迟并触发自动可用区DNS故障转移。
根据控制系统分析，这种恶性反馈正是设计中需要规避的典型问题。健康检查系统完全按预期响应接收到的输入——它作为可靠组件，在与故障环境交互时采取了不安全的操作。
在修复方案讨论中，针对NLB的措施正是控制不良反馈的关键：
针对NLB，我们将添加速度控制机制，限制单个NLB在健康检查失败触发可用区故障转移时可移除的容量。
谦逊的反思
职业生涯中能遇到的重大AWS事件屈指可数，因此更应珍惜这些经历。AWS的可靠性堪称全球之最。多年来我使用过所有主流美国云服务商，直至本周一us-east-1区域故障前，AWS始终是 毫无疑问 最可靠的选择。此次事件或许是其十年来的最大可靠性失误，我们应当从中汲取教训。
我不同意流行的早期解释。所谓人才流失理论缺乏有力证据支撑。人才流失或许延缓了修复进程——此次故障持续14小时——但我们无从知晓其响应时间线。同样缺乏证据表明us-east-1区域因历史最悠久而受其影响。5 涉事系统(DynamoDB、DNS Enactor、DWFM)很可能在全球范围运行。此外，那些声称AWS可靠性已落后于竞争对手的论断过于草率。谷歌云平台去年六月才遭遇过严重全球性故障。
我的核心结论是：在我们这个行业，生产系统的设计、实施和运维仍经常达不到我们自认的能力水平。DynamoDB遭遇了相当简单的竞态条件，导致不可恢复的数据损坏；EC2陷入拥塞崩溃；NLB的健康检查系统被错误数据误导。这些问题我们以前见过，将来还会再见。云计算仍处于早期阶段。
软件系统的复杂性和缺陷远超我们的认知。像EC2这样的实用软件系统，始终处于降级运行状态，伴随着数十个显性或潜在的缺陷与故障。持续的安全保障——即珍视的“五个9”(99.999%可用性)——并非奇迹，而是极具挑战性的设计与运维成果。
周一对于超大规模分布式系统而言是糟糕的一天。但从长远看，公共云行业终将根除其不健全的设计与运营模式。当今的先进正确性与可靠性实践终将成为常态。
- 我最初使用“零层”一词，但前AWS员工Brad Knowles对此进行了修正 NTP 和 DHCP 属于第零层，而非 EC2 和 DynamoDB。↩
- 写完这段后我开始怀疑了。TOCTOU漏洞也可能毫无缘由地存在。↩
- 部分事件评论指出，采用锁定与隔离令牌即可规避过期写入问题，但AWS明确指出为确保“容错性”，执行者不得通过分布式锁服务进行协调。↩
- 自发布以来，有AWS工程师的说明指出，Enactor清理操作并未直接从Route53中删除任何内容。实际操作是：清理程序删除了低效Enactor的配置方案，使其状态从“缺失”(
None)变为“空”([])。随后该低效Enactor应用了此空配置方案，导致DNS记录被删除。↩ - 不过我认为us-east-1区域的故障频率明显高于其他区域(如us-east-2)，应尽可能避免使用。值得注意的是，us-east-1是目前规模最大、架构最复杂的AWS区域。未来在容量和新功能非关键需求时，我将避免使用us-east-1区域。↩
本文文字及图片出自 More Than DNS: The 14 hour AWS us-east-1 outage
我对此事(以及许多其他事情)简直像张烦人的破唱片，但如果你还没读过理查德·库克的这篇文章，我强烈建议你 停下 阅读这份事后分析，先去读库克的文章。不会花你太多时间。这是我读过关于该主题最出色的文章，也是改变我技术思维方式最深远的技术著作：
https://how.complexsystems.fail/
你完全可以对照库克文章中的观点逐条验证其在本事件中的适用性。另：撰写此评论时，多数讨论聚焦于DNS故障的根本原因，但我认为这并非此次停机事件的核心问题。(库克完全否定了“根本原因”的概念，我确信他的观点完全正确。)
这份面向公众的简化版事后分析，描述的系统听起来像鲁布·戈德堡装置，而现实情况恐怕更为复杂。我完全认同：若想探究“根本原因”，更关键的是理解这类系统为何会被构建/信任/演变至此。
库克的文章尚可，但基本只是罗列论断(无论真伪，多数确实符合直觉)。或许该深入研究文末那些参考文献才能知晓细节？总之这是个古老话题，我怀疑我们至今仍未找到所有根本原因的答案。麻省理工学院系统课程6.033历史上仅数次指定阅读一篇发表于Hacker News的论文：https://news.ycombinator.com/item?id=10082625 以及 https://news.ycombinator.com/item?id=16392223 这段文字出自1962年，距今已逾60年，但其启示性与发人深省之处或许远胜于事后分析。我个人怀疑这可能属于https://en.wikipedia.org/wiki/Wicked_problem的典型案例，但仅在规模达到一定程度后才会显现。
我得赶去参加住房维权活动聚会，但容我快速补充：这类问题对我日常工作而言绝非抽象概念。早年工作时读过这篇文章却未曾触动，去年重读时却恍然：“这不就是更聪明的自己吗？” 读到这里我的瞳孔大概像《梦之安魂曲》里的角色那样戏剧性地扩张了，我觉得作者提出的多数观点都比初读时显得的更微妙深刻。
或许需要带着个人创伤阅读才能体会这篇文章的全部效果。
哦，没关系。你方便时再看。我并非要反驳这些论断本身，而是想指出它们“缺乏论证”的特性和常常草率的呈现方式。就连西蒙那篇文章也充斥着这种问题，总爱用“根据'复杂性'的定义”或“未经阐释的观察”这类说法。
在工程系统中，个人/小规模的“保持简单”原则与大型组织运作模式之间存在根本断层，这种断层还会随时间演变。这才是真正根源所在，但我不确定能否解决。或许部分问题可被缓解。
有一点或许会让你忧心忡忡：无论是西蒙的理论，还是更广泛的学术界(无论过去还是现在)，都将生物系统(如人体)奉为“复杂性”的典范范例。除了医疗失误，生命主要依靠这一招——制造大量复制品，只要它们在自身复制前未全部失效，便能形成相对稳定的模式。
稳定种群规模加上“繁殖数量/复制因子”，本质上意味着平均失败率。对多数物种而言，这数字堪称恐怖。在大卫·阿滕伯勒的纪录片里，总会配着哀伤的音乐告诉你：X%的后代永远无法活到繁殖年龄。而替代方案并非https://en.wikipedia.org/wiki/Gray_goo末日，而是“该物种特有的生物末日”。抱歉——深夜时分我的幽默回路可能短路了。所以无论是大写的“L”还是小写的“l”，生命本质上都“处于临界点”，这只是结构层面的事实。
https://en.wikipedia.org/wiki/Self-organized_criticality(涉及沙堆等概念)曾被统计物理学寄予厚望，试图用其解释此类现象的万物理论，但始终未能实现。事物看似“浅层临界”，深入探究却并非如此。或许这种近似模型终究不够实用。
总之，祝你的住房聚会顺利！
作为一名按待命排班工作的承包商，我从未遇过真正重视待命机制的公司。仅有两家企业需要待命服务，故我的看法难免有失偏颇。纸面上它们都宣称重视待命，并建立了完整的服务等级协议(SLA)，但实际支持力度严重不足。
问题在于，值班本质上是项全职工作。无论是否出现问题，值班工程师都必须全神贯注。两家公司都把值班当作附带产物——既然必须做，就塞进冲刺计划里。第一家公司稍显认真些，要求我们在JIRA中创建2-3点的值班任务；第二家公司连这都不做。
两家公司都不鼓励工程师研读他人编写的复杂代码，即便我们负责这些产品的值班。首家公司稍好些，要求创建频道并拉人参与，因此对代码一无所知尚可接受。第二家公司则放任值班人员自生自灭。两家公司都未为工程师分配足够时间深入阅读源代码，且缺乏完善的值班文档。
我不了解AWS的企业文化，但非常渴望在重视值班制度且鼓励学习的环境中工作。
我在谷歌担任SRE期间，值班制度极为严谨(若服务中断，谷歌将无法展示广告、记录广告曝光量或进行广告结算)。值班采用轮换制，持续一周(据我记忆是上午9点至晚上9点，另有时区覆盖剩余12小时)。值班人员拥有几乎所有必要权限来保障服务运行，包括取消计划停机、暂停部署更新、终止异常任务、制止违规开发者，甚至在与重要团队发生冲突时可直接联系高级副总裁。
我们定期发送测试页面以确保呼叫器正常响铃。参与轮值可获得额外报酬。管理层深知这是关键环节。遗憾的是，当时多数工具极其糟糕，频繁引发虚假呼叫或导致关键操作失败。
后来我加入的软件工程团队对开发人员轮值并不重视。现职虽设有值班制度，但仅限于工作时间内的尽力响应。
>被赋予几乎所有必要权限以保障服务持续运行
这难道不常见吗？我曾在多家企业及各类机构担任值班人员，至少记忆中从未被限制过任何系统恢复操作。这不就是本职工作吗？
值班的严肃程度应该与薪酬成正比。谷歌给得起。要是小公司只付我基本工资，那我肯定要等到早上9点上班才处理凌晨2点的工单。
这还不错。我们实际是每周24小时轮值。纸面上看起来很严苛，但即便是顶尖技术人员也无法通晓一切，问题往往拖到次日早晨才处理。而且我们没有任何额外补偿。有人熬过糟糕的夜晚后，第二天仍需继续登录系统。不过有个不成文的默契：如果夜班实在太糟，可以稍微放松些。
我做过十年以上的每周24小时轮值，强烈不推荐。
SRE团队采用12小时轮班制对人更合理
遗憾的是每周24小时轮值如今似乎成了行业默认标准，这对严肃经营的企业根本不现实。这恰恰反映了企业对系统可用性的重视程度。
深有同感。这种制度糟透了。我们实际是每五周轮值两周，其中一周是次要值班，另一周是主要值班。
在谷歌值班时处理首个非生产环境警报故障，真是大开眼界 🙂
这次经历让我深刻体会到精心维护的低级环境能带来多大价值。
亚马逊通常将值班视为全职工作。值班工程师通常只负责值班，不参与功能开发。
这很大程度上取决于团队/组织，我认为通常并非如此。六年间我只遇过三个团队中有一个是这样。另外两个团队都要求我同时兼顾功能开发和值班工作。我接触过的多数团队也是如此。
有意思，我在这里待了差不多这么久，合作过的每个团队基本都符合我描述的情况。工程师总是这样吗？不。但这是普遍预期。
这其实挺好的。
引用辛普森爷爷的话：“刚才所有人说的要么显而易见，要么根本错误”。
指出“复杂系统”具有“多重防御机制”既非真知灼见也毫无价值，纯属老生常谈。断言特定复杂系统中所有故障都缺乏根本原因，这种说法是错误的。
库克用大量辞藻却毫无实质内容。《复杂系统如何崩溃》一书中没有任何可采纳的具体建议，更谈不上带来改变。没有任何事故处理流程或事后调查机制会因此改变半点措辞。纯属空谈。
“有机成长”与“设计使然”之间存在本质区别。经验丰富的从业者从系统设计之初便会清醒认知实际运行状态，而新手则不然——他们只会不断拼凑权宜之计，任由系统屡屡崩溃。库克的概括性论断虽具有广泛适用性，但将其映射到具体情境仍需付出努力。
另一个绝佳的观察视角是“正常事故”理论，该理论指出最危险的系统往往具有三大特征：组件间耦合度极高、交互复杂且不可控、故障后果极其严重。
https://en.wikipedia.org/wiki/Normal_Accidents
阅读上述列表时，我不断质疑：“为何感觉这并非普适真理？”
随后我意识到：互联网；电力网络(至少在多数发达国家)；某些事物即便极其复杂，且并非总由高效组织构建，却并未发生灾难性崩溃。针对此论点该如何反驳？
它们确实会发生灾难性故障。例如2003年北美大停电
我认为亚马逊云服务(AWS)的复杂度可能超过电网，但即便不然，电网已有数十年时间来消除缺陷，而AWS尚未经历这个过程。AWS每年除了扩容外，还会新增大量全新服务。例如，我敢说这些DNS解析器数量已大幅增加，其规划规模也远超最初设计，这大大增加了此类问题发生的概率。
好吧我承认电网是个糟糕的类比，但互联网显然不是。至今无人提出反驳互联网的论据。
最严重的故障往往源于BGP泄露/劫持。例如：https://www.ripe.net/about-us/news/youtube-hijacking-a-ripe-…
近年来情况已显著改善，但过去单个行为异常的自治系统就可能引发全球性问题。
电网绝对可能发生灾难性崩溃，其脆弱程度远超人们想象。
几年前得克萨斯州大停电事件就险些触发这种灾难——当时电网距离彻底瘫痪仅剩几分钟，届时将不得不启动黑启动程序，据我所知这种操作从未成功实施过。
格雷迪对此有精辟阐释，其撰写的报告也值得一读。
https://youtu.be/08mwXICY4JM?si=Lmg_9UoDjQszRnMw
https://youtu.be/uOSnQM1Zu4w?si=-v6-Li7PhGHN64LB
电网会发生灾难性故障。今年葡萄牙、西班牙及周边国家就曾遭遇此类事件？但不妨将电网类比为DNS系统——规模庞大却原理简单且广为人知。故障定位迅速(即便无法追溯根本原因)，修复也高效(尽管恢复同步运行需时且非易事)。当前云基础设施则截然不同：每种实现方案都独一无二，服务各具特色，知识体系难以通用。世上既无阐述AWS基础设施基础的专著，也无管理AWS云服务的指南。
电力系统已成为多个西方主要国家面临的重大风险。
> 互联网
https://www.kentik.com/blog/a-brief-history-of-the-internets…
> 电网
https://www.entsoe.eu/publications/blackout/28-april-2025-ib…
航空业同样是绝佳范例，展现了我们如何管理复杂系统的故障，以及如何随时间推移追踪并修复更少见、更罕见的故障。
精彩链接，感谢分享。下面这点让我印象深刻——换种说法，为应对事件而“修复”系统以提升安全性，实际上可能使其安全性 降低。
>>> 对“原因”的认知会限制防御未来事件的有效性。
>>> 事故后针对“人为失误”的补救措施，通常基于阻断可能“引发”事故的行为。这类末端措施对降低后续事故概率收效甚微。事实上，相同事故重演的概率本就极其微小，因为潜在故障模式始终处于动态变化中。事故后补救措施非但未能提升安全性，反而加剧了系统的耦合度与复杂性。这既增加了潜在故障的数量，也使事故轨迹的检测与阻断更为困难。
但这种说法听起来像是缺乏证据的断言，且低估了所有参与设计和维护这些复杂系统的人员的专业能力。
以航空安全为例——难道我们要相信，根据上述断言，每起航空事故及其后续的根源性补救措施，反而使航空旅行变得更不安全？这在客观上显然是站不住脚的。
真正复杂的系统如生态系统和气候或许符合这种说法——人类虽常怀善意介入，却引发了超出人类控制能力范围的意外后果。
我认为航空安全是个特例——美国国家运输安全委员会(NTSB)的工作堪称卓越，其建议始终旨在提升整体安全性，而非仅降低特定故障概率。
但能想到许多案例：针对不幸却极其罕见的事件所采取的应对措施，反而会降低整体安全性。疫苗罕见副作用的应对措施便是典型例证。
我承认没通读两份文件，但无法认同“仅因系统复杂且需多点故障叠加才引发灾难性后果，就无法追溯根本原因”的论点。
这就像在体育比赛中辩称无人能独得一分，因为得分前总有一系列复杂动作将球员推向得分位置。这种说法在技术上成立，但毫无实际意义。纵观全局固然重要，但像这样直指失败症结的做法并无不妥。
航空领域正是最佳例证。从机器到流程、情境到人员，所有环节都错综复杂且相互关联。但我们仍坚持进行“根本原因”分析，并据此改进系统中所有失效或助长失效的环节——这正是航空业日益安全的基础。事实证明这种方法卓有成效。
这种方法在体育领域同样极具价值。我们用OPS(上垒率+长打率)而非打点数评估击球手，从未有人仅依据其偶然得分来评判。我们总强调四分卫与锋线球员、接球手的协同配合——若只关注直接成因，这些关键协作将被忽视。
我并非主张体育分析应忽视其他因素，而是认为刻意否认“某个人”击出本垒打或达阵得分的做法毫无意义。虽然通常是团队协作，但我们仍会将得分归功于个人。
恕我直言，这篇文章毫无实质价值。充斥着空洞的陈词滥调(平庸文字罗列着无法付诸实践的真理)。
更优质的参考资料当属迈克尔·奈加德的著作《释放它！》。书中针对本次故障的诸多问题提供了实用建议。例如，此次事件中断路器和隔离墙模式显然使用不足。
摘录：https://www.infoq.com/articles/release-it-five-am/
了解这些知识如何帮助你避免问题？面对复杂系统时，它似乎并未提供任何应对指导。
他写的是三里岛核电站事故。对于分布式DNS管理系统该采用何种并发原语，他根本无从谈起。
但：在资源有限的情况下，你该如何应对此次事件？是审计DNS管理系统(或所有系统)的竞争条件？还是设法让Droplet Manager在与DynamoDB发生分区时(以某种降级状态)避免陷入拥塞性崩溃？正确的应对方案是识别“最易故障组件”并制定改进计划？还是弥补人为专业知识/流程缺口——正是这个缺口导致他们未能及时限制DWFM运行长达4.5小时？
库克并非在传授解题方法，而是要求你转变问题思考方式，避免陷入局部极值的死胡同，而应以全局视野为指引。
我完全不确定像AWS这样规模庞大的系统能否运用这些原则进行重构，并成功彻底改造所有流程以降低故障率。这个系统历经多年发展，由数千名开发者共同构建，必须解决足以让业务停摆的关键扩展问题(远比这次故障严重得多)。
另需注意的是，DWFM很可能运行在特权隔离网络中，因为它需要深度访问核心控制平面。毕竟，我们绝不允许恶意服务向客户的VPC植入恶意代理。
由于该网络属于特权网络，可观测性工具、调试支持甚至访问权限都更为复杂。即便仅限于拥有访问权限的工程师群体，其规模也可能更为有限——尤其在凌晨两点。
AWS是否应放宽这些管控以简化恢复流程？但此举将导致系统安全性降低。这又是一次权衡取舍。
这两份文件都是“为工程师人格设计的仪式”。
连你都控制不住——“罗列问题清单”正是工程师的典型做法。
普通人不会这样说话或思考。库克要求我们“思考问题”的方式，恰恰与优秀领导力的特质背道而驰。思考如何思考问题，简直错得离谱。相反，要更情绪化、更简单直接。
我不太理解你的建议。正如文章所述，若系统本就复杂且持续演变，任何专业流程的缺口都无法填补。降级状态的运行或许早已内置其中，这只是他们未曾预料的降级情形。你不可能预设所有降级状态的应对方案，因为系统本质上就是复杂的。
读着读着就想起《打造更安全的世界》这本书，开篇就剖析了多起重大灾难(渡轮沉没、化工厂泄漏等)，并从系统思维框架探讨了事故成因。虽未读完，但开篇部分已让我对“根本原因”的概念产生质疑，这更像是“涌现行为”。
感谢分享，今天我算是万分之一的幸运儿。
讨论这个问题的人根本没人理解它。
这篇文章在我身边被反复转发过——无论是这次AWS大故障、上次AWS大故障、非AWS故障还是其他事件。每次阅读时，我总觉得自己隐约认同作者观点，却又觉得这些内容毫无实际操作价值。即便库克说得对，那又如何？我的工作方式根本无法据此做出实质性改变。
[已删除]
我随机点开第9条要点阅读，确信这是彻头彻尾的胡说八道。这根本不是防御性行为引发新问题的例子。
这种做法毫无意义。
编辑：哎呀我看了第8条，同样错误——执行者制定计划时 并非 基于局部理性，而是明显犯了错误。而且该论断与段落其余内容毫无关联！这输出质量太差了。
这纯属浪费我的时间。
我强烈建议你停止推荐那些因论著未尽之言而实用价值受限的读物：
《复杂系统如何崩溃》的价值在于其 概念清晰度 及对复杂系统行为的永恒洞见。其核心理念是现实主义——承认任何复杂系统都无法实现100%安全——并主张信赖人类技能与系统性防御而非简单粗暴的解决方案。理性批评指出：这种理念虽具洞见，但 需结合具体策略与主动思维方具实践价值。
本书本身不会告诉你如何设计新型飞机或更安全地运营数据中心，但它能塑造你的思维模式，助你规避常见陷阱(如追查单一根本原因或归咎操作人员)。要真正“预防”或减轻故障，必须将库克的理论延伸至具体的工程实践与组织管理中。换言之，库克揭示了事物为何以复杂方式失效；而如何将这些启示应用于系统构建与运营，则取决于我们——工程师、管理者、监管者及一线实践者——自身。
公平地说，在撰写本文时(1990年代末)，库克的论著通过向广大读者清晰阐述这些概念而开创了先河。其目的很可能在于引发思考、转变思维模式，而非作为操作手册。
如今，我们受益于韧性工程领域二十余年的研究与实践积累，这些成果正是基于库克的观点发展而来。如今从业者更注重构建韧性系统，而非单纯预防故障。他们将库克的洞见转化为实践依据，用于混沌工程、优化事件响应及培育持续学习文化等领域。
我尤其欣赏文中对操作时间线的精准梳理，以及揭示时间线叠加产生的意外效应。我最钟爱的分布式系统理论源自GDC那场传奇演讲《我先开枪》[1]——演讲者通过倾斜箭头绘制序列图来表现时间流向，并追问“延迟出现在何处？”。这种方法在我整个职业生涯中屡次救我于危难：从游戏开发到直播点播服务，直至如今的金融科技领域。进行分布式操作时务必考虑时间流向——时间之箭永不停歇，而你的系统可能滞后。
但相比之下，这段引文才真正令我胆寒：
任何人都可能犯分布式系统错误(这类系统本就复杂)。但令我意外的是，管理EC2物理节点租约的核心服务竟未配置恢复流程。或许我过度解读了——他们可能指的是“此特定场景”缺乏恢复方案，即便如此仍令人忧心。EC2作为AWS的元老级服务，按理说早已历经千锤百炼，极端异常情况理应被尽数识别。但此次EC2故障的影响似乎更为深远——它引发了连锁反应，波及更多服务(如NLB和Lambda)，且耗费更长时间才完全恢复。我很好奇他们将采取何种措施来进一步增强系统韧性。
[1] https://youtu.be/h47zZrqjgLc?t=1587
这不该令你惊慌。它应当引发认知。这种元故障模式存在于所有复杂技术系统中。你应该恍然大悟：“啊，原来如此，现在明白了”。潜在故障具有分形普遍性，其组合效应可能引发灾难性故障。没错，这确实是他们必须拥有的运行手册，但我们都该明白：他们需要却尚未制定的运行手册还有无数！
真正令我担忧的是，AI永远无法诊断从未遇见过的问题。若缺乏运行手册，就无法进行模式识别。我已就此呼吁两年之久；希望此次事件能让AWS管理层明白，当前世代的AI永远无法取代人类工程师。
我对这种论断持保留态度。我不看好AI系统独立接管人类运维工作，但灾难性故障往往由次级故障叠加形成，而次级故障又源于潜在缺陷的组合。当潜在缺陷易于表征时(如当前案例！)，大型语言模型在组合分析方面确实能展现惊人能力。
我倒不打算以此创立公司(毕竟基础模型公司会吞并这类业务)，但若能开发出能处理遥测数据和故障模型信息的智能体，据此提出需关注的疑点或干预方案，应该能实现相当有价值的应用。
不过以上都偏离了我的核心观点：我想说的是，仅靠运行手册无法确保像AWS这样复杂的系统安全运行。此类系统的安全性本质上是更复杂的进程，这是不可避免的。比如：我认为大型语言模型根本无法解决“分形运行手册需求”问题！
AI远不止于LLM。梳理AWS这类相互依存系统构成的复杂网络，恰恰是符号AI的专长领域。
不过我认为数百万系统都曾因DNS记录缺失而崩溃。
这同样令我震惊，但并不意外。规划失败往往由多重因素叠加引发，我在众多企业中都见过类似模式重演。
我敢打赌，最初的工程师们肯定预见了这种冷启动情况，并设计了具备抗干扰能力的系统。但随着时间推移，那些工程师离职了，新团队接手了——他们并未完全理解和重视系统的复杂性，可能也对各种边界情况不太在意。随后，在管理层追求与可靠性相悖的目标(如成本优化等)的压力下，大量次优的变更接踵而至，最终催生了这个新的故障场景。结果正如我们所见——一场灾难性故障让所有人措手不及。
当财务人员掌权时，这类事件就会反复上演。
> 但我未曾料到，连管理物理EC2节点租约的核心服务竟未配置恢复机制。
我猜他们对“拥塞性崩溃”这种边缘情况也未作准备。我见过类似案例，所以对此倒不至于皱眉。
不过有两处警示信号：
1. 该DWFM服务明显缺乏负载卸载支持，导致必须重启服务器。需借鉴https://aws.amazon.com/builders-library/using-load-shedding-…案例
2. 该DWFM服务依赖DynamoDB而非Chubby这类基础组件。需从https://www.youtube.com/watch?v=QVvFVwyElLY深入学习分布式系统基础原理
因此DNS记录的 过期即需更新 机制，本质上是 “计算机科学两大难题——缓存失效” 的变体。摘自长段落：
>[…] 事件发生前，某DNS执行器遭遇异常高延迟，需在多个DNS终端重复更新操作。当它缓慢处理终端时，其他事件同步发生：首先，DNS规划器持续运行并生成多代新方案； 其次，另一台DNS执行器开始应用新计划并快速推进所有端点更新。这些事件的时序触发了潜在的竞争条件：当第二台执行器(应用最新计划)完成端点更新后，随即触发计划清理流程——该流程会识别显著早于当前计划的旧版本并予以删除。就在清理过程启动的同一时刻，首个执行器(因异常延迟)将其旧计划应用到区域DDB端点，覆盖了新计划。由于执行器处理过程中的异常高延迟，计划应用流程初始阶段的验证机制(确保新计划优于先前应用计划)此时已失效。[…]
该说明概述了部分机制，但有人可能认为这仍非“根本原因分析”，因为未能令人信服地解释_为何_会出现 “Enactor处理异常延迟”。硬件故障？！人为配置错误导致Enactor行为意外延迟？！要么是导致该问题的先前事件序列被视为无关紧要，要么是亚马逊仍在调查Enactor行为失控的根源。
此为公开声明，旨在阐明整体问题，并非真正的事件后分析。
在活跃事件“解决”前，需评估可能/可预见的复发风险。通常我们/他们会预先准备潜在缓解方案和恢复运行手册，以便快速应对复发情况。任何可能存在的风险都会在当前问题解决前积极化解，包括开发团队全天候工作以实施最佳缓解路径。
接下来，所有可能导致“复发风险”的途径都将成为开发团队的工作优先级(工作时间内)，直至相关行动项完成部署。这可能涉及其他采用类似DIY DNS管理的团队、遭遇影响较小的队列深度问题的团队，或其他类似“险情”发现。服务团队的技术负责人与业务负责人(PE、高级PE、总经理、副总裁)将每日跟踪进展直至解决。
随后在未来数周内，组织层级与AWS层级的“运维会议”将深入探讨本次事件、响应措施及根本问题等，旨在实现组织学习并广泛传播经验教训、行动项及最佳实践。
> …至今仍无法令人信服地解释_为何_Enactor处理出现“异常高延迟”。硬件故障？
虽无法断言本次事件成因，但类似“机器运行缓慢”问题曾导致我们BigCloud服务受挫(所幸未酿成重大事故)，根源在于故障硬件引发的JVM垃圾回收长时间暂停。
我的结论是竞争条件才是根本原因。消除这个漏洞后，即使存在处理延迟，事件也自然消失。
没错。这听起来像是“自行开发分布式系统算法”的案例，却未在前期投入构建真正健壮的分布式系统。
网络工程师往往忽视分布式系统研究过去五十年解决的复杂问题，因为相关算法晦涩难懂，而启发式方法通常效果不错——直到失效的那一刻。但我猜测AWS会对系统进行重大重构，希望更新能建立在严谨的算法基础上。
谨以此文提醒所有设计大规模容错分布式系统的工程师：务必深入研究问题领域，明确各类算法的适用场景。
> 对系统进行重大重构，希望更新能建立在严谨算法基础上
读到这段话我冷汗直冒 🙂 真希望他们别这么干
这显然是DNS的滥用。它本不该被设计成可快速更新的一致性分布式数据库。
若以CAP定义衡量一致性，此言确属实。但若换个角度看，我认为DNS设计满足了所有条件：
– “快速可更新性”取决于具体实现，但设计允许20亿个变更集在传输中，镜像才可能与主数据库不可逆地失调。DNS规范包含快速更新所需的所有组件：基于推送的通知机制和增量传输。
– DNS采用最终一致性设计，每个副本都应提供内部一致的数据。两个镜像对同一查询返回不同响应的情况完全可能发生，但最终一致性并不排除这种可能性。
– 分布式特性：DNS系统无疑是分布式数据库，事实上它专门设计为支持跨组织边界的复制——这是其他分布式系统鲜少具备的能力。DNS未提供多主节点操作，但Postgres或MSSQL等数据库同样不支持此功能。
我认为历史上的DNS属于“尽力而为”模式，但借助RAFT等共识算法，完全一致性的DNS系统是可实现的。
此外，请不要止步于RAFT。RAFT之所以流行，是因为它易于理解，而非因为它是实现分布式共识的最佳方案。它具有非确定性(因此需要奇数个选举人)，需要超时机制来保证活性(因此延迟可能致命)，而且我认为它并不适合通用型共识场景。
为何将“DNS规划者”与“DNS执行者”分离？若整合为单一组件，相关人员岂不更易察觉此竞态条件？这是否源于微服务架构过度使用导致的复杂性爆炸？
> 为什么“DNS Planner”和“DNS Enactor”要分开？
对于大型系统，这种拆分在实践中非常合理——一个组件只负责读取数据并输出计划，另一个组件则仅接收计划并执行。
这种设计更易于测试(仅需处理单一数据结构的生成与消费，规划器甚至不尝试修改任何数据)，更易于权限管控(单侧仅需读取全局数据！)，更便于升级(双方互不依赖对方的存在甚至语言类型)， 运行更安全(规划器可随时丢弃，即使崩溃或被终止也仅影响更新延迟)，更易于理解(人类可检查包含完整计划状态的规划器输出)，更易从异常状态恢复(极端情况下可直接修改计划)等等。随着系统规模扩大、复杂度提升，这些优势会愈发凸显。
> 若问题仅此一处，难道参与开发的团队不该更早发现这种竞争条件吗？
不
> 这是微服务架构过度使用导致复杂性爆炸所致吗？
不是
事后诸葛亮地评判他人服务拆分方式极其容易——毕竟网络上的陌生人既看不到实际复杂性也无从知晓细节，自然能轻描淡写地建议“改成这样更好”，却无需承担任何想象中替代方案的弊端。
同意，这是常见的分工方式，能简化流程。事后分析中虽未明确指出，但我推测职责混淆(即执行者同时承担过期计划的清理职责)可能是诱因之一。
Oxide and Friends团队介绍过他们构建的类似拆分架构的更新系统，其中列举的优势与您提到的多项一致：https://oxide-and-friends.transistor.fm/episodes/systems-sof…
我建议将这些功能拆分到单体可执行文件内部。最多通过“—whatif”可选路径将计划输出到磁盘文件。
以文件作为通信媒介的分布式系统远比程序员想象的复杂，其故障模式也超出他们的认知范畴。
比如…这个案例就让整个云平台瘫痪数小时！
将功能封装在单一二进制文件中，会丧失拆分后“免费”获得的可观测性优势，反而可能大幅增加复杂性(更多代码路径、“不生成计划直接用上次计划模式”的运行参数、“使用人工生成计划模式”的参数)。世上没有免费的午餐，但我多次采用这种模式且深感其价值。我曾管理过采用MIP模型进行容量规划的系统，将规划与执行分离对我们极具实用性。
我认为通信机制取决于周边可用的系统架构，这种规划器/执行器极少完全独立存在。有些公司拥有大型分布式文件系统(具备成熟语义规范)，或配备文件出现时自动启动任务的调度器，甚至能自由访问具备严格可串行性的数据库来存储计划序列化版本等。
我的意思是，任何规模仅为AWS百分之一的系统一旦出现故障，就会涌现出大批毫无领域经验的“键盘侠”指手画脚。根本不值得花时间回应。真正有价值的意见早已在内部提出。
> 真正有价值的意见早已在内部提出。
有趣的观点，考虑到AWS近年经历的人才流失潮。外部意见或许有参考价值——但或许人才流失已如此严重，以致留任者尚未察觉？
我猜这要看具体情况。考虑到AWS的庞大规模，采用Desired state vs. reconciler架构通常能提升运维韧性，更易定位隔离问题。但反过来说，若错误处理机制失效，就会出现这种情况。此外，他们似乎没考虑到过期计划可能被优先采用的问题，或许是我对事件/架构理解有误。
这脚本很可能原本是单线程Python程序，直到有人发现能从中获取促销码。
我们讨论的是亚马逊，那脚本八成是Perl写的。
我也有同感。根本无需提及“竞态条件”，RCA报告开篇就昭示着这个词。
两个DNS组件构成单体架构：彼此缺一不可，设计图上仅有一条箭头将它们耦合。
若它们本是单一组件，这一切本可避免。
还有版本检查？认真的吗？
为何不直接比对当前状态与预期状态，采取必要措施实现一致？
最后但同样重要的是，如此激进地删除旧配置文件是“因小失大”的设计。我建议永久保留这些文件，至少保留一个月！这显然比任何可能的配置步骤耗时都要长得多。
确实，所有DNS条目都不应被如此彻底地删除。
另外，我可能漏看了，但他们是否制定了预防措施？若再次出现异常延迟时如何避免服务中断？
解决方案在文末：他们已禁用相关DDB DNS自动化功能进行修复，待修复后再启用
如果重新启用(且未作修改？)，异常高延迟难道不会再次导致故障？
他们怎么可能在未修复问题的情况下启用？
事后分析明确指出，在解决此问题前不会重新启用该功能。但任何具备基本能力的机构，理应首先修复已知故障——毕竟他们正是因故障才停用的。
执行器似乎应在应用新值前检查当前记录的版本/生成代数，确保不会将旧计划覆盖已由新计划更新的记录。效率虽会降低，但这是基本原则。这本质是基本的比较交换操作，完全可在存储这些记录的DynamoDB内部轻松实现。
事后分析随你便——互联网正经历剧烈崩溃。
互联网诞生于冷战时期对分布式网络的需求——旨在减少集中式故障点，堪称一种对冲机制。
如今它已整合为日益缩小的单一网络。单一部署中的一个简单失误就可能导致全球银行业务、购物和旅行陷入瘫痪。一旦涉及网络战争，这种风险只会急剧加剧。
个人认为，云计算的比喻早已过度延伸且早已破产。
对于研发、初创企业及间歇性/季节性计算需求，云服务运作完美(类似于昔日分时系统的运作模式)。
但成熟企业、成长型公司及政府机构，最好实现技术自主：拥有实体服务器+自有云平台+核心服务(数据库、消息传递、支付系统)。
当前技术、专业知识和劳动力资源并不匮乏。
> 互联网诞生于冷战时期对分布式网络的需求——旨在减少集中式故障点，堪称一种风险对冲机制。
我认为其初衷并非确保系统在灾难(包括核攻击)中维持正常运转，而是保证其持续运行。而互联网作为系统，在此次AWS故障期间确实持续运转——虽处于降级状态，但仍在运行并最终恢复。
我更关注早期公共互联网曾承诺的另一种去中心化形态——经济、权力与思想的去中心化——如今却如何演变为高度集中化。AWS和亚马逊恰恰是绝佳例证。作为系统的互联网，今天确实还在运转，但可以说处于降级状态。
防止灾难是ARPA的缓解策略。关键在于它的发展方向，而非现状。问题不在于AWS本身或任何单一企业，而在于这种整合趋势。AWS的诞生实属偶然——巧妙利用了amazon.com闲置的服务器资源。
在构想之初，互联网(而非万维网)并非作为经济媒介而存在——其商业成功实为美妙的附带效应。
>互联网正在崩溃，而且是彻底崩溃。
我并不认同这种说法，只是更多人希望通过互联网获取服务，而提供服务的三大平台却时常出现故障。
据我观察，互联网基础设施正在持续优化。
最近那次BGP重大故障引发的讨论量仅为AWS故障的十分之一，且命名也远不那么惊悚(哦哦哦路由不稳定)。
https://news.ycombinator.com/item?id=44105796
>互联网诞生于冷战时期对分布式网络的需求——旨在减少集中式故障点，堪称一种风险对冲机制。
与其争论互联网诞生的必要性，不如直言它至今仍以高度分布式模式运行。您指的是Web而非互联网？
关键在于“互联网”不等同于“你在互联网上可能访问的内容”。此次事件中互联网表现优异，据我观察其始终正常返回404和502错误码。分布式网络实现了真正的分布式互联——若你希望与任何联网用户直接交换数据包(而非依赖AWS托管应用)，这种能力依然完好无损。
>单次部署中的一个简单错误就可能导致全球银行业务、购物和旅行陷入瘫痪。
没错，但瘫痪会持续多久？影响多少人？过去二十年对许多依赖劣质基础设施的行业而言，无异于一场严酷的烧机测试。看起来几乎所有人都在抗拒中被拖入了未来。
我指的是整个航运业在过去十年间就已完成转型。
https://www.zdnet.com/article/all-four-of-the-worlds-largest…
>个人认为，云计算的比喻早已过度延伸，早已破产。
它从来都不太实用。
>对于成熟/成长型企业和政府机构，最好实现自主技术独立
这类企业只需主动构建区域/供应商冗余方案。此次故障导致大量应用崩溃，但许多团队因设计出稳健系统而免受波及，正获得内部赞誉。
>经济实惠的技术、专业知识和劳动力并不匮乏。
确实如此，这些人才往往懂得如何设计云基础设施来规避问题，或足够明智地警示他人：若区域及其依赖项在无冗余保护下故障，业务将直线坠落。企业终将做出商业决策，并在公开受挫后重新审视这些决策。
我指的不是www，那是另一回事。我说的是分布式网络，就像www出现之前那样。这其实与AWS本身无关，也无关云计算是否进步——进化未必因进步而进步。
计算的集中化正在扭曲互联网的核心优势，即分布式网络(而非AWS/Azure/Gcloud区域)。
新冠疫情若有什么启示，那就是政治、经济和战争已进入全新时代——几乎是全球性的转变。
>我指的是分布式网络
那么究竟哪些网络失效了？报告未提及任何网络层问题，我也未察觉大规模网络层故障。
我认为使用非UTC时区的报告是犯罪行为。
纪元错误？
我认为此处做法合理。由于故障发生在us-east-1区域，绝大多数受影响客户位于美国。对多数人而言，从太平洋时间转换比从UTC转换更便捷。
但us-east-1本就在东部时区，既然不用UTC，为何不直接采用当地时间？
我推测选择PT是因为撰写报告的人员位于PT时区(亚马逊总部所在地)。
us-east-1是亚马逊的特殊区域，不仅托管众多全球服务，还承载着其他区域尚未开放的服务。全球大多数AWS客户可能都间接依赖于us-east-1。
我认为选择PT时区是为了强调：对多数响应的运维人员而言，事件发生在深夜时段。
(纯属猜测，不知内情，只是推测选择原因)
他们总部在西雅图(太平洋时区)。不过确实，我讨厌时区。
我有点意外的是，他们没有采用基于端点的版本控制方案，也没有通过双重事务确认(2PC)或单写入者租约等机制拒绝过期写入。
这绝对是个痛苦的教训，但值得称赞AWS如此透明详尽地分享：hugops:
参见https://news.ycombinator.com/item?id=45681136。实际的DNS变异API确实实现了CAS机制。他们存在多个未同步的写入者，在缺乏逻辑约束或变更排序的情况下发生竞争。若未深思熟虑，他们本可通过更新区域序列号或另一种“哨兵记录”来实现类似向量机制——该记录专用于处理影响该标签/区域的ChangeRRSets，例如包含序列化变更集编号或新旧状态“校验和”的TXT记录。
我猜“计划”环节跳过了这步，直接应用预期状态而未作序列化处理。最终采用“最后写入者获胜”原则——直到该机制失效。
哦，我明白了。AWS内部在任务编排方面存在问题。我敢打赌执行器完全可以重写为规划器中的goroutine/线程，通过合理加锁和排序实现。
但这太复杂且会增加代码量。所以他们很可能直接用了SQS队列配合消费者读取。
他们是不是故意写得晦涩复杂，想让大家懒得读下去？
单段落776个单词
亚马逊式的写作“文化”
从元分析层面看：缺陷必然存在，形式化验证困难重重，有时只是运气不佳导致多年未现(我曾遇到十余年前埋下的缺陷，因触发概率极低而长期潜伏)。
若预设系统终将失效，我认为更合理的思路是限制故障影响范围。实践中这意味着采用单元化架构、分阶段部署及隔离区域策略。
据我所知，AWS确实尝试实施单元化架构，但受历史遗留问题影响，尤其us-east-1区域存在跨区域依赖关系。真正的长久之计是设计相互独立的区域架构。
这虽是艰巨任务，但并非不可实现。我曾参与灾难测试，当时某区域被刻意与其余基础设施隔离。这种操作能迅速暴露跨区域依赖关系，其中许多存在于意想不到之处。
通常这类工作因缺乏高层副总裁支持和资金而搁置，毕竟埋头装睡祈求厄运不降临更为轻松。这项工作的最强支持者将是那些着眼长远的股东。若因灾难测试不当导致公司崩盘，股东将成为主要损失承担者。让董事会意识到风险及可能引发公司根本性危机事件的概率，有助于为这项工作争取资金支持。
看到这份详细总结很欣慰。从客户角度看，令人沮丧的是AWS持续存在跨区域问题，且对这些单点故障的具体位置始终讳莫如深。
当其他区域的核心服务依赖US-East-1运行时，区域模型就显得脆弱得多。这在以往停机事件中已暴露问题，本周似乎再度重演。
事实就是如此，但AWS始终过度宣传各区域完全独立的健壮性，而像周一这样的事件恰恰揭示了事实并非如此。
>关于这些单点故障的位置。
通常发现单点故障后会立即修复，而最常见的发现方式正是故障发生时。在如此规模的系统中，保留单点故障并非行业标准做法。
> 由于缺乏既定的运维恢复流程，工程师们谨慎尝试通过“直接修复故障”(DWFM)解决问题，避免引发连锁反应。
有意思。
> DynamoDB等服务需维护数十万条DNS记录，才能在每个区域管理庞大的异构负载均衡器集群
这是否意味着对dynamodb.us-east-1.amazonaws.com的DNS查询可能解析到十万个IP地址中的任意一个？
太疯狂了！
这完全超出了Route53的承载极限。
我猜他们可能通过持续更新Route53的小型子集记录，并采用低TTL值来变通实现。
基于DNS的CDN本质上也是如此：从数据存储中收集系统使用指标、数据包丢失率、延迟等指标，计算出观众网络与优先节点(PoP)的映射表。
遗憾的是难以提供硬性文档，但这正是我曾任职公司CDN的运作方式。另有另一家CDN[1]以更华丽的措辞阐述了相同原理。
[1] https://bunny.net/network/smartedge/
Akamai早在2000年代初就提出过类似方案。Facebook内容团队约在2011年发表过一篇不错的论文，描述了延迟采集与实时路由机制，我记得叫“pinpoint”之类的名字。不过正如你所说，这在当时已是行业惯例。
细节上有些不同，但基本原理确实是所有AWS DNS的运作方式。你可能忽略了标签、区域和域名的关联性与独立性。R53是基于资源记录集合(SETS)运行的，集合关系本身就提供了构建树形结构和选择合适集合的逻辑支持(例如健康检查、延迟检测)。
> 这已远超Route53的限制
事实上R53完全能胜任此任务。你以为所有公共EC2、ELB、RDS、API网关等资源的记录都是在哪里管理和服务的？
我虽未测试DynamoDB，但曾对S3进行循环DNS查询，短短几秒就获取数百个独立IP地址。这仅是单一区域、单一源IP的测试结果。
> 这也远超Route53的限制。
内部限制与面向客户的限制是两回事。
某些硬性限制其实比表面看起来更宽松。
一方面，这促使人们转向更小规模的自主管理模式——例如个人用户只需运行一台DigitalOcean VPS即可。但另一方面，大型企业评估时需权衡：偶发性故障的容忍度与自主运营的巨额成本孰轻孰重。究竟谁会留下、谁会迁移、谁会尝试多云故障转移，终究要具体情况具体分析。这绝非那种能简单断言“太糟糕了，太愚蠢了，绝不该发生，赶紧离开AWS”的局面。人们对珍视之物的依赖是缓慢积累的，这种依赖不会迅速改变，甚至可能永不改变。银行界“大到不能倒”的信条同样适用。后续发展本质上相当平淡——换言之，不会有实质性变化。
多区域部署的AWS本应足以应对此次故障。
《The Register》的分析颇有见地https://www.theregister.com/2025/10/20/aws_outage_amazon_bra…
日前讨论：
今日亚马逊人才流失导致AWS彻底崩溃(644条评论)
https://news.ycombinator.com/item?id=45649178
https://newsletter.pragmaticengineer.com/p/what-caused-the-l… 的解释比AWS那堆文字更清晰
不过仅在DNS章节中，我就发现他至少有一处错误……
所以根本原因基本上就是竞争条件101——过期读取？
竞争条件和数据验证失效。
用“Route53事务”来描述一项没有硬性事务保证的操作，这种说法很有意思。尤其考虑到正是缺乏事务性更新导致了此次故障…
我认为你误解了故障场景。ChangeResourceRecordSet操作 具有事务性(至少在我参与该服务开发时如此)https://docs.aws.amazon.com/Route53/latest/APIReference/API_…。
故障源于两个目标状态相悖的客户端：
– 某台(“旧版”)DNS执行器遭遇异常高延迟，需对多个DNS端点重复更新操作
– DNS规划器持续运行并生成大量新版计划[注：关键点在于其产出的是 期望状态 的“计划”，不包含 包含历史状态+变更的完整事务(如日志或区块链)]
– 另一台(“新”)DNS执行器开始应用新版计划
– 随后(“新”)执行器触发计划清理流程，识别出显著早于当前应用计划的旧计划并予以删除[注：此处暗含关键竞态。旧执行器正在读取“当前状态”(即新执行器的输出结果)，却在此基础上叠加应用其期望的“旧”状态。差异源于 表面上 规划器与执行器并未采用链表/向量时钟/序列化变更集编号等机制]
– 与此同时，首个(“旧”)执行器…将其更早的计划应用于区域DDB端点，覆盖了新计划。[注：此时“旧”Enactor生成有效的ChangeRRSets调用，将“new”替换为“old”]
– 计划应用流程初始阶段的校验机制(确保计划比先前应用的计划更新)此时已失效[注：哎呀！]
– 第二个执行器的清理流程随后删除了这个旧计划，因为它比刚应用的计划早了多代。
讽刺的是，Route 53 确实 具备API变更的强事务性，同时 进行序列化处理，还 拥有闭环观察者机制，能在每个数据平面主机上全局验证变更集。其他AWS服务亦然。甚至存在构建此类复制或变更集链的内部基础组件。但这过程极其麻烦且耗费大量精力，一旦失败就会导致全局死锁，客户因DNS变更无法生效而 暴跳如雷。
说来也巧，我们这些被WHU sev2折磨过的人还有个互助小组呢……
老兄，我向来讨厌这种表述；总想让大家用更精确的术语，比如“客户变更传播”。不过话说回来，谁没被查询计划变更或东南亚的随机连接问题惩罚过呢！
听起来这次设计是可用性优先于正确性，但问题在于：如果基础架构配置本身就不正确，那连可用性都无从谈起。
在他们宣布“全部恢复正常”整整一天后，我系统仍受SQS延迟影响。这份总结充斥着警示信号，尤其令人震惊的是他们竟没有恢复操作流程。这在超大规模云服务商中简直不可思议——你们从未考虑过这种故障场景吗？还是说那些掌握方案的工程师都离职了？
不过这份报告的坦诚描述还是值得肯定的。
> 由于该计划被删除，区域端点的所有IP地址立即被移除。
我感觉这里漏了关键信息…他们描述的DNS执行器似乎只是将当前DNS状态与预期状态进行差异比对，然后提交所需的添加/删除操作使DNS达到预期状态。
但存在写入竞争时，这难道不会让DNS回退到旧状态吗？为何要彻底移除所有IP？
1. 读取状态，哦，我需要删除所有这些。
2. 读取状态，哦，我需要写入所有这些。
2. 写入操作
1. 删除操作
或者类似的变体。任何存在并发读写且无锁机制的系统都会发生这种情况。
没想到Dynamo竟与整个AWS架构如此深度耦合。
确实，无论好坏，AWS都是个超级内部用户。他们对自家产品足够信任以至于自用其服务固然可喜，但想到任何单一服务故障的破坏范围可能极其巨大，又令人不寒而栗。
这篇报告完全无法阅读，格式糟糕透顶。
说真的，这就是所谓“行业领先”企业发布的事故报告？他们该羞愧得脸红。天啊，段落分隔？标点符号？
亚马逊的基础似乎开始出现裂痕了。
说真的，这就是所谓“行业领先”公司发布的事故报告？他们该羞得满脸通红才对。天啊，段落？标点？
我写网络评论都比这用心，虽然那些评论不会被数百万读者看到。
> 如同近期推出的IPv6端点和公共区域端点的情况
虽然RCA报告未明确说明，但这些新端点很可能就是压垮DynamoDB负载均衡器DNS自动化的最后一根稻草
据我理解，根本原因 在于DynamoDB DNS管理系统中潜伏的竞争条件，导致过时的DNS计划覆盖当前计划，最终使区域端点的DNS记录清空。
正确吗？
我认为“根本原因”这类说法需谨慎。他们经历了亚稳态拥塞崩溃。此次故障的重要成因在于缺乏运行手册，无法安全恢复其滴管管理服务至正常运行状态。
诱发事件 是DynamoDB规划/执行系统中的竞争条件。
https://how.complexsystems.fail/
为何不能将竞争条件漏洞视为单一根本原因？诚然存在加速崩溃的其他因素，但这些属于DNS固有特性，超出本次总结范围。
因为DNS竞态条件只是系统中的一个缺陷。更关键的潜在缺陷†可能是Droplet Manager的亚稳态故障模式——当其与Dynamo断开连接时，会逐渐丧失与Droplet的通信能力，直至达到临界阈值，此时必须手动限制Droplet Manager并进行恢复。
关键点在于：DNS问题在1小时15分钟内得到缓解(降级状态)，2小时30分钟后完全解决；而Droplet Manager问题耗时远超此数！
这正是复杂故障分析的核心价值，也是该学派主张“追根溯源”反而适得其反的原因——必然 存在其他诱发事件！
† 而该问题本身很可能只是更深层潜在问题的次生效应，解决后者才更具价值！
Droplet Manager故障属于更易被原谅的情形。其发生源于“必须持续运行”的服务长时间中断，海量恢复操作导致系统不堪重负。
而最初的DynamoDB DNS故障则严重得多。这是典型的TOCTTOU(任务执行时间超过预期)问题——预设为“即时执行”的定时任务，因缺乏控制机制导致单个任务就炸毁了基础服务中的关键组件。
多年前我在AWS任职时，曾有人提议采用单元架构对关键服务进行垂直切片，以限制故障波及范围。可惜这个方案最终被彻底搁置了。
https://en.wikipedia.org/wiki/Swiss_cheese_model
这里涉及两个不同问题：
1. 故障如何发生？
2. 系统为何崩溃？
A1：竞争条件
A2：正如你所说
在此模型中识别“根本原因”的意义何在？内存损坏漏洞的根本原因在于持有指向已释放值的过期指针，还是源于内存安全机制的缺失？AWS在以下哪个方面更具优势：识别并缓解EC2中的亚稳态故障模式，还是试图找出DNS可能导致DynamoDB崩溃的所有途径？(后者其实并非易事，但这正是关键所在！)
对听众而言，两点都可能重要。对多数人来说，重点在于竞争条件的教训。锁的存在自有其道理。对AWS而言，则是稳定性教训。DNS确实能让整个帝国瘫痪数小时，且已然发生过。
究竟是 DNS 导致崩溃，还是潜在故障模式引发崩溃？DNS恢复得相当迅速！
没人否认锁机制的趣味性与重要性。
Droplet租约超时是加剧事件严重性的因素，但并非根本原因。若无触发条件，Droplet租约永远不会发生拥塞性故障。
竞态条件是系统崩溃的必要且充分条件。若无纠正措施，它必然导致AWS瘫痪。即使采取纠正措施，在无其他加剧因素时故障严重性也会降低，但竞态条件始终是此类故障的根源。
这其实无关紧要。此类错误需进行完整五问分析，每个问题都必须解决。两个问题都必然会产生行动项。
我并非指AWS会处理不当，只是说这个讨论线程处理不当。
这绝不是DNS问题
不可能是DNS问题
但它确实是DNS问题
听起来DynamoDB将继续成为EC2等服务的硬性依赖。至少我欣赏这种透明度，能了解到他们的内部系统名称。
我认为是时候让AWS揭开面纱，发布一份JSON文档，列出每个AWS服务的所有内部服务依赖关系。
这重要吗？你会根据依赖关系图来决定是否使用他们的产品吗？
这能让你明白：若服务A和B都依赖服务C，就无法通过A和B组合来提升可靠性。
是的。
若真如此，恕我直言——你根本不会用AWS(或其他云服务商)！
我既不用AWS也不用其他云服务商。自2012年起就使用裸机。记得2012年(我记得没错的话)某个关键日子，我们关掉裸机转投AWS全线服务。当天下午，AWS就遭遇了首次大规模故障。在那之前，老板随时能进来质问我们如何处理故障。而那天，我们只能干瞪眼，要么启动早已过时的数据库副本。AWS总不会停机数小时吧？对吧？对吧？使用裸机服务器时，你可能停机数小时，但无论发生什么都能快速恢复到降级状态。而使用AWS，你只能被动等待他们优先修复的问题。
与此同时，我曾经历过裸机服务器完全瘫痪超过一天的情况——只因一台挖掘机决定“品尝”通往我们大楼的光纤线路。当时我只能干瞪眼，因为我们只能等待另一家公司修复故障。
我们能否设置异地故障转移站点？从技术角度看当然可以。就像你可以采用多区域部署、多云架构，或在Hetzner等供应商启动服务器。云计算在此事上并无优劣之分——只要不发生互联网整体崩溃，你始终能设计出应对各种突发状况的弹性方案。
我在AWS工作过两年，若记忆无误，其中一个问题是循环依赖。
许多AWS内部服务的命名对外用户完全不透明。因此这类文档实际价值有限。
+1，SRE人员入职初期往往要花数月时间研读设计文档，才能了解周边服务。
除非公开所有内部文档，否则很难让外部人员清晰理解AWS基础设施。若无法实际访问源代码和可观测性工具，阅读理解这些文档也毫无意义。
至少应为DynamoDB拆分专用隔离实例以降低影响范围。我建议每个使用它的内部AWS服务至少配备两个实例。
毕竟总得有个基础数据存储层。比起那些未被大量客户深度验证的方案，我更倾向于选择DynamoDB。
DynamoDB的实际存储层设计精良，并具备正式的数学证明。
读到第十行时我才恍然大悟——这根本不是事故分析报告，而是精心设计的AWS营销文案。
> 众多核心AWS服务深度依赖DNS实现无缝扩展、故障隔离与恢复、低延迟及区域化特性…
还没读完十行我就意识到，这堆文字里不可能藏着真实原因。背后肯定有个工程师在说：“我们搞砸了，删掉了DynamoDB的DNS记录”
条件读写能解决这个问题吗？看起来像是某种过期读取
这是其他人使用的内部DynamoDB吗？
用TLA+(我以为他们用了)
DynamoDB运行在EC2上吗？如果我没看错，EC2依赖于DynamoDB。
AWS内部存在循环依赖关系，但也有应对机制(尤其针对冷启动场景)。
实际上并不存在统一的AWS，每个区域都是独立的(如今这种情况比以往更明显，部分系统原本并未为此设计)。
776字的段落配上28字的屏幕宽度，这简直无法阅读。
确实是相当不友好的排版方式 -_-
我已请Claude重新排版以提升可读性：https://claude.ai/public/artifacts/958c4039-d2f1-45eb-9dfe-b…
若需100%准确性，请务必自行与原文交叉核对。
简而言之：DNS自动化漏洞清空了所有区域端点的IP地址。本应协助恢复的工具依赖于需要恢复的系统本身。这堪称AWS规模下经典的“误删生产环境”故障模式。
Bind解析器要求每个区域的序列号必须递增。
因此每次修改区域文件时必须递增序列号，通常采用时间戳格式如20250906114509(该序列号小于20250906114702)，以便快速识别最新数据的区域文件。
该系统似乎采用了类似机制，但对加载旧文件的限制较宽松。