summary
2017-02-28 太平洋时间早晨，一名 Amazon S3 工程师在调试账单系统（因 S3 计费流程的一个小增长）时，本应移除少量索引/位置子系统（index/placement subsystem）服务器，却因一条命令输错，移除了过于大量的此类服务器。由于 S3 依赖这组子系统来管理和路由请求，系统在 us-east-1 出现 API 错误率飙升与延迟，并连带影响大量依赖 S3 的 AWS 服务（EC2、EBS、Lambda、状态健康看板等）。
timeline
约 09:37 PST 错误命令执行，S3 控制面与数据面请求开始失败。工程团队花费数小时逐一重启被误删的索引/位置子系统服务器并让其重新加入集群（这些服务启动需做完整检查，耗时较长）。约 12:26-13:18 PST 起 S3 及依赖服务逐步恢复。
root_cause
人为操作命令中的目标参数错误，导致批量移除关键子系统服务器；且该子系统服务启动/重新加入集群的代价高（需完整性检查），放大了恢复时间。
amplifiers
① 人员操作无强制确认/范围校验：一条输错命令可移除大量核心服务器。② 子系统重启代价高：索引/位置服务启动慢，拖长恢复。③ 依赖面广：S3 是大量 AWS 服务的基础，单点故障连锁。④ 状态看板本身依赖 S3，初期通报受阻。
mitigation
逐一重启被误删的索引/位置子系统并完成重新加入；恢复后 AWS 移除了该调试/运维命令的使用，并改进 S3 子系统重启机制使其更快。
lessons
高危运维命令必须带目标范围确认与速率限制；核心子系统应支持快速、并行、安全的重启；避免状态/健康系统依赖其监控的对象存储。
checklist
① 批量移除类命令强制二次确认与数量上限。② 核心子系统增加快速重启/预热能力。③ 健康看板去依赖化。④ 运维操作留痕+自动审计。