亚马逊 AWS S3 宕机：一个打错的命令让 S3 和半个互联网瘫痪了 4 小时

2017 年 2 月 28 日早上，亚马逊网络服务（AWS）的一名工程师正在调试一个问题，这个问题导致亚马逊 S3——该公司非常受欢迎的云存储服务——的计费系统响应缓慢。按照标准操作流程，工程师运行了一个命令，本意是让少量 S3 服务器退出服务以便检查。但命令中的一处输入错误，移除了远超预期的服务器，包括运行 S3 两个核心子系统的服务器：一个是跟踪所有数据位置的索引，另一个是分配存储的系统。

索引子系统瘫痪后，美国东部一区（北弗吉尼亚）的 S3 无法响应请求，错误像涟漪一样向外扩散。互联网的很大一部分都建立在 S3 之上——不仅是存储图片和文件的网站，还有其他 AWS 服务，从计算仪表盘到存储卷，再到无服务器函数。随着 S3 出现故障，这些服务也跟着出问题。大约四个小时里，大量热门网站和应用——从 Slack、Trello 到无数其他服务——都出现故障或性能下降，这次宕机在全世界成为热门话题。

AWS 甚至难以向外界说明发生了什么：它自己的服务健康仪表盘也依赖 S3，所以服务宕机时无法发布清晰的状态更新。工程师重启了子系统，S3 在当天上午晚些时候恢复。亚马逊发布了一份坦诚的事后分析报告并道歉，并表示会增加保护措施，确保命令无法将容量降到最低值以下，将 S3 子系统分离开来，使一个错误无法导致全部瘫痪，并将状态仪表盘迁移到它所报告的服务之外。

一次维护命令的错误输入移除了远超预期的服务器，包括核心子系统，而 AWS 自己的状态仪表盘也随 S3 一起宕机。

一次常规维护命令中的错误输入移除了过多服务器，包括 S3 的两个核心子系统。

没有任何护栏阻止该命令将关键子系统的容量降低到安全最低值以下。

S3 的子系统没有充分隔离，导致一个错误在该区域的整个服务中连锁反应。

互联网的很大一部分——以及 AWS 自身——都依赖 S3，因此故障远远超出了存储的范畴，连 AWS 自己的状态页面也随之宕机。

互联网对你的服务依赖越深，一个不受保护的命令就越危险。保护破坏性操作，隔离子系统，绝不能让一次输入导致全盘崩溃。

2017 年 2 月的 S3 宕机成为历史上最著名的云故障之一，也是关于一条不受保护的命令如何在一个互联系统中引发连锁反应的教科书案例。亚马逊的透明的事后分析报告——解释了输入错误、连锁反应和修复措施——本身也常被引为事件沟通的典范。这一事件让业界更加关注对破坏性操作的护栏以及关键子系统的隔离，也让人意识到一个不舒服的事实：当一个服务支撑着互联网的很大一部分时，那里一个糟糕的早晨，对所有人来说都是糟糕的早晨。