人为失误导致 AWS S3 的 US-EAST-1 区服务宕机

由一次失误引发的连锁反应导致了很多 S3 服务器宕机，其中包括两个影响 S3 运行的关键子系统。由此导致了 S3 的故障，影响到了不仅 S3 本身还有其他一些依赖 S3 的服务。四个小时后 S3 才重新恢复正常。

Amazon AWS 故障十分罕见，一旦发生整个因特网都能感受得到，不少服务会直接受到影响。近期这次故障于 2 月 28 日发生在北弗吉尼亚地区（US-EAST-1）。不仅 S3 运行瘫痪了，而且波及一系列依赖 S3 的 AWS 服务，包括 EC2、EFS、API Gateway、Athena、Cloudsearch、MapReduce 等。这些服务要么是在功能上出现大量错误，要么是完全无法工作。

在四个小时的瘫痪期间，据报告有不少企业服务下线或是受到严重干扰，包括 Expedia、GitLab、GitHub、GroupMe、IFTTT、Medium、Nest、Quora、Slack、The Verge、Trello、Twitch、Wix 等。就连 Amazon 自身的 Alexa 也出现故障了，导致 AWS 状态仪表盘有两个小时未实时更新。Amazon 借助 Twitter 发布错误报告，期间他们只得为状态页面临时添加一个手工编辑的横幅。

Amazon 事后给出了对该次事件分析的诊断报告。当时有一个Amazon 团队正在调试S3 的计费问题，有人想要输入一条命令，从S3 的一个计费子系统中删除一小部分服务器。但是这个工程师输入了错误的命令，导致了大量的S3 服务器关闭，包括两台在另外两个子系统中起关键作用的S3 服务器。其中一个子系统是为整个区域的S3 提供索引服务的，影响到GET、PUT、LIST 和DELETE 命令；另一个子系统用于S3 部署，涉及新对象的空间分配。因为这两个子系统停止工作，S3 的功能产生了大量错误，影响到很多用户。

虽然AWS 具备快速恢复单个子系统故障的操作规程，但是由于索引子系统已经有数年从未重启过，索引已增长得十分庞大，因此还是需要相当长的重启事件。虽然功能最终得以恢复，但是比预想的要慢。Amazon 已经计划今年稍后会对索引子系统进行分区，将索引分区为更小的块，使得重启更加快速。现在他们已经立刻着手进行分区，为将来可能发生的瘫痪情况做好准备。他们对工具做了修改，限制了每条命令可以关闭的服务器数量，还限制使用单个命令关闭整个子系统。他们还将在多个区域实现分布式的S3 仪表盘，以确保在一个区域停止服务时仪表盘依然保持工作。

Amazon 在 2011 年曾经历过一次瘫痪，也是发生在 US 东部区域，那一次瘫痪了 4 天时间。从两次故障中学习到的并得以应用的基本经验教训是，系统创建不应仅依赖在单一区域上，如果当前区域发生故障，可以切换到其他区域。Netflix 已经这样部署了，其他系统同样也可以。但是这会增加网络主机服务费，企业总是倾向于尽量地降低费用。总体来说，Amazon AWS 是可靠的，但是服务总不可避免会有瘫痪情况。所有云服务提供商皆是如此。

查看英文原文： A Human Error Took Down AWS S3 US-EAST-1

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。