周二，当AWS的S3存储组件走了几个小时后，AWS消耗了大量热量，这是理所当然的，但今天，他们公布了《死亡后解释》中发生的所有技术细节，以及他们计划如何防止类似事件在未来再次发生。

不出所料，问题的核心是人为错误。一个可怜的工程师，我们称他为Joe，他的任务是输入命令关闭一些存储子系统。在平常的日子里，这不会引起任何问题。这是一项常规任务，但在周二，情况变得非常糟糕。

Joe是授权用户。他根据亚马逊所谓的“既定脚本”输入命令。“问题是，乔应该发出命令关闭S3子系统上的几台服务器，但他犯了一个错误。他删除了一个更大的服务器，而不是只关闭那一小部分服务器。

通俗地说，就是一切都出问题的时候。

亚马逊做了更多的技术解释，但这足以说明错误对北弗吉尼亚数据中心的S3存储有级联效应。长话短说，Joe的错误导致一些关键底层子系统崩溃，删除了大量存储容量，导致系统重启。当这种情况发生时，S3无法满足请求，这甚至可能导致AWS自己的仪表板掉落(你知道，这有点尴尬)。

到目前为止，外界开始感受到冲击，你喜欢的网站、应用、云服务也开始出现问题。

随着下午的过去，公司正在积极尝试让服务恢复在线，但系统的规模对他们来说并不好。当系统关闭时，AWS表示已经很多年没有这样做了，成为自身成功的牺牲品。在受影响的数据中心，S3的容量已经增长到如此程度。当它们重新启动时，运行所有安全检查并验证底层元数据的完整性所需的时间比预期的要长。

为了减少未来类似的人为错误，公司正在进行一些改变。用他们的话说，“我们修改了这个工具，以较慢的速度移除容量，并增加了安全措施，以防止任何子系统在容量低于最低要求的容量水平时移除容量。”这应该可以防止像乔这样的人在未来犯类似的错误。

此外，AWS正在寻找将这些S3子系统(这是问题的核心)分解成更小的块或单元(AWS称之为它们)的方法，他们过去已经尝试过了。显然，子系统被证明太大，无法快速恢复(或者至少不够快)。

他们最终道歉并承诺做得更好。最后，一系列因素导致了这个问题，首先是人为错误，然后是跨系统级联，但这些系统并不是为了应对如此大的错误而设计的。