今年 5 月初，AWS us-east-1 的 use1-az4 机房大厅里，多台制冷单元先后失效，温度爬过安全阈值，服务器自动断电保护硬件。硬件是保住了，可必须等温度降回阈值以下才敢重新上电——于是这场事故从"几个小时的事"拖成了约 28 小时。最近把 shattered.io 上的完整复盘翻了一遍，值得记的细节不少。

时间线粗一点看：美西 5 月 7 日下午 5:25 制冷失效、错误率开始爬；夜里自动断电，EC2 实例和 EBS 卷下线，一串依赖服务跟着降级；到第二天下午 1:50（约 20 个小时后），制冷才恢复到事件前水平，多数 EC2/EBS 回来；数据密集型服务磨蹭到周五晚上才算齐活，全程约 28 小时。

外面的世界更热闹：Coinbase 交易系统停了约 7 小时，核心撮合停了 5 个多小时；FanDuel 赶在湖人对雷霆的季后赛直播当口取不了现；CME Direct 报错；KoboToolbox 从 00:32 UTC 起整个下线——顺带一提，它家欧洲区的实例全程正常。连锁降级的名单拉出来老长：ELB、EKS、Redshift、MSK、ElastiCache、OpenSearch、SageMaker、IoT Core、NAT Gateway。

最该记的是这个：us-east-1 从 2021 年到现在第三次大故障，三次死法完全不重样。2021 年 12 月，扩容 bug 打爆内部网络设备；去年 10 月，DNS 自动化竞态条件把关键端点记录抹掉，半个互联网瘫了 15 个小时（那篇在这）；这回，物理制冷失效。有数据显示 2025 年 us-east-1 的宕机时长约是其他 AWS 区域的 3 倍；去年那次的保险损失估算在 3800 万到 5.81 亿美元之间，SLA 赔付根本盖不住。一句话：你为一种故障模式建的冗余，会被另一种故障模式击穿。

给运维的启示没有新鲜事，但值得再抄一遍：

  1. "多可用区"不等于容灾——同一个 region 里的 AZ 会一起死给你看；
  2. 真在乎可用性，就跨 region、甚至跨云，数据同步的麻烦提前算进成本；
  3. 预案里加一条"物理层"：断电、制冷、光纤，这些不出现在控制台里；
  4. 依赖清单要拉到服务级，别只写一句"我们用 AWS"。

我平时管几十台机器做例行巡检和推变更，用的是七亿批量远程管理工具；机器分散在不同机房时，越能体会"分布"两个字的分量。跨机房的批量巡检怎么排，官网教程页里有现成做法——批量远程工具这层功课做在平时，出事那天才有得选。

0.png