一条输错的容量移除命令，让 S3 的索引与放置子系统整体重启，US-EAST-1 的 S3 请求一度无法处理。 本文是公开报告的摘要与解读，事实以原始报告为准

本文是公开报告的摘要与解读，事实以原始报告为准。

事件概要

2017 年 2 月 28 日（太平洋时间），AWS S3 位于北弗吉尼亚的 US-EAST-1 区域发生故障。当天上午，S3 团队正在排查账单系统进度慢于预期的原因。9:37，一名获授权的团队成员按既有 playbook 执行了一条用于移除少量账单服务器的命令；报告称“其中一个输入被错误填写”，实际移除的服务器数量超过预期。

这些服务器还承载了 index（索引）和 placement（放置）两个子系统。两者都需要完整重启，在此期间 S3 无法处理请求。12:26，索引子系统恢复到足以处理 GET、LIST 和 DELETE 的容量；13:18 索引完全恢复；13:54 placement 恢复，S3 恢复正常。报告按时间点记录过程，没有给出单独的停服时长统计，也没有给出受影响请求比例。

时间线

影响面

故障集中在 US-EAST-1。S3 的 GET、LIST、PUT、DELETE 都依赖索引子系统，PUT 还需要 placement 分配新存储，因此两个子系统重启期间 S3 无法正常服务。报告没有给出受影响请求的比例，也没有给出单独的停服时长，只给出了上述恢复时间点。

依赖 S3 的其他 AWS 服务也受到影响，报告明确列出：S3 控制台、EC2 新实例启动、需要从 S3 快照读取数据的 EBS 卷，以及 AWS Lambda。US-EAST-1 中其他依赖 S3 的服务同样受到波及。

Service Health Dashboard 本身也依赖 S3，导致 11:37 之前无法更新单个服务的状态，AWS 只能用 Twitter 账号和仪表盘横幅传递信息。这个细节说明：状态页如果和被监控系统共享依赖，故障时就会同时失声。

根因

直接触发点是容量移除命令的输入错误。命令原本只想移除少量账单相关服务器，但错误输入使更大范围的服务器被移除，其中包含索引和放置子系统所用的机器。报告没有给出具体命令、工具名或被移除服务器的数量。

索引子系统管理该区域所有 S3 对象的元数据和位置信息，是 GET、LIST、PUT、DELETE 的共同依赖；放置子系统负责为新对象分配存储，并在 PUT 时使用。两者被移除后都必须完整重启，S3 因此在重启期间无法处理请求。

恢复时间超出预期的原因，报告说得很具体：S3 在较大的区域已经多年没有完整重启过索引和放置子系统，按当前规模重启并校验元数据完整性，比预想更慢。报告把触发点归因于容量移除命令的输入错误，并强调恢复慢是因为长期未完整重启；两点叠加，构成了这次故障的完整链条。

处置与恢复

恢复按依赖顺序推进：先重启索引子系统并执行安全检查，12:26 恢复到可处理 GET、LIST、DELETE 的容量，13:18 完全恢复；索引可用后再重启放置子系统，13:54 完成，S3 恢复正常。随后，依赖 S3 的服务逐步恢复，并消化故障期间积压的工作。

沟通方面，AWS 在 11:37 之前无法通过 Service Health Dashboard 更新单个服务状态，改用 @AWSCloud 和横幅通告；11:37 之后恢复状态更新。报告没有描述每一步的内部操作细节，也没有给出客户侧重试或补偿的具体数字。

报告列出的改进包括：修改容量移除工具，让容量“更缓慢地”移除；增加保护，防止容量被降到最低需求以下；审计其他运维工具是否存在类似风险；把索引子系统进一步分区的工作重新排期并立即开始；让 Service Health Dashboard 的管理控制台跨多个 AWS 区域运行。

教训

第一，授权用户加既有 playbook 并不等于安全。只要一个输入错误就能把“移除少量服务器”放大成区域级故障，工具就必须自己限制爆炸半径，而不是依赖操作者每次都输对。

第二，最小容量保护和慢速移除应该成为批量运维工具的默认能力。删除、下线、缩容这类不可逆操作，需要有 dry-run、二次确认、影响范围预览和自动停止条件。

第三，多年没有完整重启过的子系统，不能假设它能在需要时快速恢复。恢复时间必须通过演练测量，元数据完整性校验也要计入恢复预算。

第四，状态页、告警和沟通渠道要独立于被监控系统。S3 故障时仪表盘也不可用，这不是单纯的沟通问题，而是控制面依赖设计问题。

对本站读者的检查清单

• 批量删除、下线、缩容命令是否有 dry-run、影响范围预览和二次确认？
• 工具是否设置最小容量、最大并发或最大爆炸半径，并在越界时自动停止？
• 关键子系统最近一次完整重启或恢复演练是什么时候？实测恢复时间是多少？
• 恢复流程是否包含元数据完整性校验？校验需要多久？
• 状态页、告警通道和沟通渠道是否独立于被监控系统？
• 依赖对象存储的服务是否有重试、退避、降级和积压消化方案？
• 其他高危运维工具是否做过同类安全审计？

恢复手册与同类复盘

• 公开复盘索引 — 按根因查找同类事故，并跳到对应 Runbook。

相关命令

• aws：查看 S3、EC2、EBS 等资源与区域状态，核对依赖关系。
• curl：从客户端验证 S3 API 与应用健康检查的返回码和延迟。
• dig：排查对象存储域名、终端节点和 DNS 解析问题。
• traceroute：确认到区域终端节点的网络路径与异常跳点。
• journalctl：在主机侧查看服务重启、错误和依赖失败日志。
• incident-response-playbook：按“止血、恢复、复盘”的顺序组织处置。
• observability-roadmap：补齐状态页之外的指标、日志与告警覆盖。

参考链接

• AWS 官方报告：Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region
• AWS Builders' Library：Ensuring rollback safety during deployments
• AWS Builders' Library：Automating safe, hands-off deployments

读完自测

合上页面，先回答，再展开对照。

1. 为什么一条“移除少量账单服务器”的命令，会影响整个 S3 的请求处理？
2. index 和 placement 各自负责什么？为什么 placement 要等 index 恢复后再重启？
3. 从这次事故看，批量运维工具和状态页设计各应增加哪些保护？