按照重大服务中断后的惯例，亚马逊网络服务(Amazon Web Services)今天发布了一份事后分析报告，解释了其简单存储服务(Simple Storage service)出现高错误率的原因，导致许多网站在周二运行速度变慢或停止工作。
+更多关于网络世界足球竞猜app软件：从AWS S3宕机中获得的5个教训以及如何将自己从下一次宕机中隔离出来|供应商发现，在S3中断期间，前100家零售网站中有一半的加载速度很慢+
“太长，没读”(TL;DR)版本是指S3团队中的一名AWS工程师试图调试一个导致S3计费系统变慢的问题。在此过程中，一小部分支持S3子系统的服务器被离线。意外的是，脱机的服务器数量超出了预期。这导致其他子系统重新启动，使得S3 API在短时间内不可用。其他依赖于S3 api的AWS产品，如虚拟机、块存储和Lambda也受到了影响。
AWS已经安装了防护措施，以确保不会有太多的产能一次性下线，而且它正在将其产品管理系统分解成更小的部分，以减少任何故障的爆炸半径。AWS尚未表示是否将退款给客户。
找到博客文章的链接在这里，或查看报告全文如下。
北弗吉尼亚(US-EAST-1)地区的Amazon S3服务中断摘要
关于2月28日上午发生在北弗吉尼亚(US-EAST-1)地区的服务中断，我们想提供一些额外的信息。Amazon Simple Storage Service (S3)团队正在调试一个导致S3计费系统进展比预期更慢的问题。在太平洋标准时间上午9:37,S3团队的一名授权成员使用一个既定的剧本执行了一个命令，该命令旨在删除S3计费过程使用的一个S3子系统的少量服务器。不幸的是，该命令的一个输入错误，并且删除了比预期更大的服务器集。无意中删除的服务器支持另外两个S3子系统。索引子系统是这些子系统中的一个，它管理区域中所有S3对象的元数据和位置信息。这个子系统是服务所有GET、LIST、PUT和DELETE请求所必需的。第二个子系统，放置子系统，管理新存储的分配，并要求索引子系统能够正常运行。放置子系统用于PUT请求期间为新对象分配存储。删除很大一部分容量会导致这些系统都需要完全重新启动。 While these subsystems were being restarted, S3 was unable to service requests. Other AWS services in the US-EAST-1 Region that rely on S3 for storage, including the S3 console, Amazon Elastic Compute Cloud (EC2) new instance launches, Amazon Elastic Block Store (EBS) volumes (when data was needed from a S3 snapshot), and AWS Lambda were also impacted while the S3 APIs were unavailable.
S3子系统的设计目的是支持删除或失败重要的容量，对客户的影响很小或没有影响。在构建系统时，我们假设系统偶尔会出现故障，我们依赖于移除和替换容量的能力，这是我们的核心操作流程之一。虽然自从S3启动以来，我们一直依靠这个操作来维护我们的系统，但是我们已经很多年没有完全重新启动大区域的索引子系统或布局子系统了。S3在过去几年中经历了巨大的增长，重新启动这些服务和运行必要的安全检查以验证元数据的完整性的过程比预期的要长。索引子系统是需要重新启动的两个受影响的子系统中的第一个。在PST时间下午12:26，索引子系统已经激活了足够的容量来开始服务S3 GET、LIST和DELETE请求。在下午1:18 PST时，索引子系统完全恢复，GET、LIST和DELETE api正常运行。S3 PUT API也需要放置子系统。放置子系统在指标子系统正常工作时开始恢复，并在太平洋标准时间下午1:54完成恢复。此时，S3运行正常。 Other AWS services that were impacted by this event began recovering. Some of these services had accumulated a backlog of work during the S3 disruption and required additional time to fully recover.
由于这个操作事件，我们正在做一些更改。虽然删除容量是一个关键的操作实践，但在本例中，所使用的工具允许过快地删除过多的容量。我们已经修改了这个工具，以更慢地删除容量，并添加了保护措施，以防止在任何子系统的容量低于其最低所需容量水平时删除容量。这将防止错误的输入在将来触发类似的事件。我们也在审计我们的其他操作工具，以确保我们有类似的安全检查。我们还将进行一些更改，以提高关键S3子系统的恢复时间。我们采用多种技术，使我们的服务从任何故障中快速恢复。其中最重要的一种方法是将服务分割成小块，我们称之为单元。通过将服务分解到单元中，工程团队可以评估和彻底测试即使是最大的服务或子系统的恢复过程。随着S3的扩展，团队已经做了大量工作，将服务的部分重构为更小的单元，以减少爆炸半径并提高恢复。 During this event, the recovery time of the index subsystem still took longer than we expected. The S3 team had planned further partitioning of the index subsystem later this year. We are reprioritizing that work to begin immediately.
从事件开始到太平洋标准时间上午11:37，由于SHD管理控制台对Amazon S3的依赖，我们无法在AWS服务运行状况仪表板(SHD)上更新各个服务的状态。相反，我们使用AWS Twitter feed (@AWSCloud)和SHD横幅文本来交流状态，直到我们能够在SHD上更新各个服务的状态。我们理解SHD在操作事件期间为我们的客户提供了重要的可见性，我们已经更改了SHD管理控制台以跨多个AWS区域运行。
最后，我们要为这次事件给我们的顾客造成的影响道歉。虽然我们对Amazon S3的长期可用性记录感到自豪，但我们知道该服务对我们的客户、他们的应用程序和最终用户以及他们的业务有多么重要。我们将尽一切努力从这次事件中吸取教训，并利用它进一步提高我们的可用性。