2017 年 2 月 28 日，美国太平洋时间上午 9 点 37 分，亚马逊云服务（AWS）的一位工程师准备处理一件小事。亚马逊的大型在线存储服务 S3 有个计费系统，跑得比预期慢。计划是把计费相关的几台服务器先下线。
这种操作有现成的手册，工程师照着手册敲了命令。其中一个参数敲错了。
结果下线的不是几台计费服务器，而是一大片。被拖下去的机器里，有 S3「索引系统」的那一批：它负责记住存进来的每个对象是什么、放在哪里。索引一倒，北弗吉尼亚区域的 S3 就既取不出文件，也列不出、存不进、删不掉。
成千上万的网络服务把数据放在 S3 上，事情很快蔓延开。Medium、Business Insider、Slack、Quora、Giphy 都出了问题。有人用一个叫 Ifttt 的自动化服务管家里的灯，这下灯也开不了了。连一个叫「is it down right now?」的网站也中了招，它存在的意义，本来是告诉你别的网站是不是挂了。
亚马逊自己的状态页也卡住了。更新状态页的后台同样跑在 S3 上，所以直到上午 11 点 37 分，亚马逊都没法在上面更新各项服务的状态，只能靠 Twitter 和页面顶端的横幅发消息。据《卫报》报道，在工程师能更新之前，那块看板上一路显示一切正常。
恢复花的时间比亚马逊预想的长。索引系统和它的邻居「分配系统」都得彻底重启，而在较大的区域，亚马逊已经很多年没这么干过了，这些年 S3 又长大了许多。离那次敲错过去四个多小时，S3 才回到正常状态。
亚马逊公开的事故说明里，从头到尾没提那位工程师的名字，也没说这个人后来怎样，只说是一位有权限的 S3 团队成员。问题被放在了别处。
亚马逊写道：「所用的工具允许过多容量被过快移除。」于是它改了工具：现在下线服务器会放慢速度，而且只要某次下线会让任何一个子系统低于运行所需的最低容量，工具就拒绝执行。亚马逊说，它正在把其他运维工具也排查一遍，看有没有同样的缺口；还把原定晚些时候做的工作提前，把索引系统拆成更小的块，它管这叫「单元」，好让下一次故障波及得少一些，恢复得快一些。
「这将防止一个错误的输入在未来引发类似的事件。」