一个参数敲错，S3 带崩半个互联网：连 AWS 状态页都没法更新

配图：AI 生成的概念示意图，非论文原图、真实现场或实验数据。

TL;DR：2017 年 2 月 28 日，AWS 一名授权的 S3 团队成员执行命令时，有一个输入敲错，下线的服务器远多于预期。S3 美东（us-east-1）区域的两个核心子系统被迫重启，服务中断约四个多小时。AWS 官方复盘说明的是“输入错误加工具缺少保护”，没有披露命令原文和具体台数。

这是 2017 年的旧事，不是今天的新闻。

当天上午太平洋时间 9 点 37 分，S3 团队在排查计费系统变慢的问题，按流程要从一个计费用的子系统里移除少量服务器。命令里有一个输入写错了，结果被移除的服务器比预期多得多。

被误伤的服务器恰好支撑着 S3 的另外两个子系统。一个是索引子系统，它管着该区域所有对象的元数据和位置信息，GET、LIST、PUT、DELETE 都离不开它。另一个是放置子系统，负责在 PUT 时给新对象分配存储，又依赖索引子系统。容量被抽走一大块后，两者都得完整重启，重启期间 S3 无法响应请求。

S3 是太多服务的底座。AWS 自己列出的受影响服务就有 S3 控制台、EC2 新实例启动、依赖 S3 快照的 EBS 卷，以及 Lambda。

最讽刺的是状态页。从事故开始到太平洋时间 11 点 37 分，AWS 服务健康仪表板没法更新各服务的状态，因为它的管理控制台本身依赖 S3。AWS 只好靠 @AWSCloud 推特和仪表板顶部的横幅文字通知用户。

恢复比预想慢。AWS 说，大区域里的索引和放置子系统已经很多年没有完整重启过，而 S3 早已今非昔比，规模大了很多，加上元数据完整性的安全检查，耗时被拉长。12 点 26 分索引子系统恢复到能处理 GET、LIST、DELETE，13 点 18 分完全恢复，13 点 54 分放置子系统也恢复，距离那条命令约 4 小时 17 分。依赖 S3 的服务还要消化积压的请求，才算彻底缓过来。

AWS 事后的整改主要有这些：

• 该工具改为更慢地移除容量；
• 增加保护，若移除会让子系统低于最低所需容量就直接拒绝；
• 审计其他运维工具是否有类似的安全检查；
• 提前启动索引子系统拆分成更小单元的计划，缩短未来的恢复时间；
• 状态仪表板的管理控制台改为跨多个区域运行。

这件事常被概括成“一个手误”，但复盘更像是在说：人迟早会输错，真正的问题是工具允许一次移除太多、太快，系统又多年没演练过完整重启。

来源：Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region