从此次事故开始直到上午11：37（太平洋时间），AWS服务运行状态仪表板（简称SHD）上一直无法更新各项个别服务的运行状态，这是由于该仪表板的管理控制台运行依赖于Amazon S3。因此，AWS转而使用AWS Twitter Feed（@AWSCloud）与SHD横幅通知文本发布状态更新，直到重新恢复在SHD之上更新个别服务状态的能力。AWS表示其了解SHD在业务运行期间为客户提供提示信息的重要意义，因此目前已经将SHD管理控制台调整为跨多个AWS服务区运行。

　　改进措施？

AWS在此次官方声明中不仅公布事故起因、解决过程，而且分析了技术问题并决定了改进措施。大致分为以下两个方面：

　　事故的发生：大量移除操作不应该如此容易

AWS称其正在根据此项事故进行数项调整，尽管移除容量属于一项关键性操作实践；但在目前的情况下，AWS使用的工具在移除容量时的执行速度过快，已经对此工具进行了修改以更慢进行容量清除。同时，AWS增加了安全措施以防止任何子系统在容量移除后遭遇现有容量低于最低容量需求的情况。此外，AWS也在审查当前使用的其它操作工具，以确保在其中引入类似的安全检查机制。

　　事故发生后：恢复时间不应该如此漫长

AWS会采以多种技术以确保服务能从任何故障中迅速恢复，其中最为重要的举措之一在于将服务拆分成更小分区（AWS将其称为Cell）。通过将服务进一步分解为Cell，工程技术团队能够评估并全面测试各类大规模服务或子系统的恢复流程。

　　7吃瓜群众应该从中学到什么？

AWS的官方声明最后一段写到：“最后，我们要对此次事故给客户造成的影响诚挚道歉。虽然我们对于Amazon S3长期以来的可用性表现感到自豪，但我们清楚这项服务对于我们的客户、其应用程序、最终用户以及业务的重要意义。我们将尽一切努力从这次事件中积累经验教训，并以此为基础进一步提升我们的服务可用性。”

那么，对于其他人而言，从这次事故中我们能学到什么呢？InfoQ收集整合了三位技术专家陈皓、陈天、Nick Kephart给出的思考整理如下：

　　要注意Error Handling

当问题出现时，一个普通的 S3 GET 返回什么：

所以AWS 告诉你Internal Error 了。

从 error handling 的角度，陈天认为在写代码的时候都应该捕捉这个异常，然后做合适的错误处理。很遗憾的是，S3 这样的服务是如此基础，就像互联网的水和电一样，大家默认为它永远不会出错。因此，好多工程师干脆不做错误处理。

除了代码编写层面的处理，当云服务商的宕机发生时，开奖，尽量控制它影响面。像 Trello连 landing page 都一并挂掉实在不可取，因为起码 S3 影响不到的页面，如 landing page，用户注册 / 登录页面，应该还保持正常服务；而像 Quora的服务，其实是可以准备一个静态化的镜像，一旦出问题，起码让读者可以无障碍地阅读。

　　尽可能地把动态内容缓存起来，甚至静态化

Redis cache、Nginx cache、HAProxy、CDN 都是把内容缓存甚至静态化的一些手段。陈天认为：尽管多级缓存维护起来是个麻烦，但当底层服务出现问题时，它们就是难得的战略缓冲区。cache 为你争取到的半个小时到几个小时几乎是续命的灵芝，它能帮你撑过最艰难的时刻（这次 S3 宕机前后大概 4 小时，最严重的时候是 11点到1点），相对从容地寻找解决方案，紧急发布新的页面，或者迁移服务，把损失降到最低。否则，只能像这次事件中的诸多公司一样，听天由命，双手合十祈祷 AWS 的工程师给力些解决问题。

　　云用户应检查核心依赖关系，提升关键性服务的冗余水平

S3是多种Amazon服务的核心组成部分之一。无论是利用其进行简单文件存储、对象存储抑或是用于存储网站或者应用程序中的内容，其间复杂的依赖性都必须会引发级联效应。S3能影响到的组件包括用户会话管理、媒体存储、内容存储、用户数据、第三方对象和自动化机制等。

在Thousandeyes公司的Nick Kephart看来，云用户应检查核心依赖关系，提升关键性服务的冗余水平。AWS的系统在构建当中具备冗余特性，能够实现跨数据中心自动复制存储对象与文件。而作为另一种冗余层，云用户需要利用额外AWS服务区或者其它云服务供应商以彻底避免此类事故；不过这会增加大量管理复杂性与成本支出，因为跨环境间的数据同步工作需要由云用户负责打理。大多数企业并没有选择上述选项，开奖，可是单纯的数据备份在数小时的短周期内并不能发挥作用。