摘要
2017-02-28，一名 AWS S3 工程师在执行一条用于移除少量 S3 计费子系统的维护命令时，因输入错误导致 S3 的 index（索引）和 placement（位置）子系统大量服务器被误删。由于 S3 控制台及多个 AWS 服务都依赖 S3 存储，故障沿依赖链向外扩散，us-east-1 大量服务中断数小时。
# 一条本应小范围的维护命令，删掉了底层存储的心脏。
时间线
09:37工程师运行带错误的命令，开始删除 S3 子系统服务器
09:43S3 团队收到大量告警并开始调查
~10:00S3 控制台及依赖 S3 的服务出现错误
中午前后确定根因为误删，逐台重启并做数据完整性校验
~13:00多数 S3 功能恢复
~14:00受影响的依赖服务陆续恢复
根因
一名 AWS S3 工程师在执行维护命令时，本意是移除某个与计费流程相关的小范围子系统，却因命令参数覆盖了过大的匹配范围，误将大量 S3 节点的 index（索引）与 placement（位置）子系统服务器一并删除。index / placement 负责对象的查找与位置分配，被移除后 S3 请求无法被路由；更隐蔽的是，一个底层依赖系统此前依赖缓存、认为「移除是安全的」，从而掩盖了真实影响面。
- 维护命令缺影响范围护栏：本应命中计费子系统的窄匹配，实际匹配并删除了更大范围的 index / placement 服务器。
- 控制台等控制面自身依赖 S3 存储，故障后排障通道随之失效，形成盲区。
- 底层依赖系统误判移除安全（基于过期缓存），推迟了根因暴露。
- 恢复依赖逐台手工重启 + 数据完整性校验，缺乏快速自动重建机制。
放大因素
区域内服务高度依赖 S3 这一底层存储，单点失效半径极大；恢复靠人工重启与校验，速度慢；S3 控制台依赖 S3 本身，故障初期工程师难以通过正常通道排障。
缓解措施
- 为高危维护命令增加强制二次确认与影响范围预估。
- 关键子系统支持快速自动重建，而非逐台手工恢复。
- 控制面与底层存储解耦，避免「排障工具依赖被排障系统」。
经验教训
任何能删除生产基础设施的命令都必须有护栏；底层依赖（如 S3）的故障半径必须被显式评估并加固，不能假设它永远可用。
检查清单
- 确认故障窗内是否有内部维护 / 删除命令执行
- 核对受影响服务与 S3 的依赖关系
- 检查 index / placement 子系统健康与重建进度
- 验证控制面是否依赖被排障的存储
- 复盘高危命令的审批与二次确认流程