AWS花了大量的热量,当其S3存储组件周二走几个小时,理当如此,但今天他们发表post-mortemexplaining究竟发生了什么完整的技术细节,以及他们如何计划,防止将来类似事件再次发生。

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

Joe是一个授权用户，他根据Amazon所谓的“已建立的剧本”输入命令。“问题是Joe本应该发出一个命令来关闭S3子系统上的一小部分服务器，但是他犯了一个错误，他没有只关闭那一小部分服务器，而是删除了一个更大的服务器。

用外行人的话来说，那就是一切都乱了套的时候。

Amazon在技术上做了更多的解释，但足以说明错误对北弗吉尼亚数据中心的S3存储产生了级联影响。长话短说，Joe的错误导致了一些关键的底层子系统的崩溃，这些子系统删除了大量的存储容量，导致系统重新启动。当这种情况发生时，S3无法服务请求，这甚至导致AWS自己的仪表板下降(您知道，这有点令人尴尬)。

到目前为止，外部世界开始感受到影响，你最喜欢的网站、应用程序和云服务开始出现问题。

随着下午时间的推移，该公司正积极努力让服务重新上线，但系统的规模对他们不利。当系统关闭时，AWS说它已经多年没有这样做了，它成了自己成功的受害者。S3的容量在受影响的数据中心中增长到这样的程度:当它们重新启动时，运行所有的安全检查并验证底层元数据的完整性所花费的时间比预期的要长。

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

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

他们以道歉和承诺做得更好来结束。最后，是一系列因素导致了这个问题，首先是人为错误，然后是跨系统的级联，而这些系统的设计初衷并不是为了处理这么大的错误。