2月28日，亚马逊的简单存储服务(S3)中断关闭了许多知名网站和网络服务。要了解Amazon Web Services (AWS)的完整事后分析，请阅读这篇冗长的解释问题出在哪里，AWS正在做什么来解决这个问题。
如果完整的解释太长太复杂，这里有一个简短的版本:
- 管理员打算在一组S3服务器上执行维护。
- 他错误地输入了让一组服务器下线的命令，下线的服务器比预期的要多
- 这使得美国East Zone的整个S3环境的容量接近系统设计的极限，并在依赖S3环境的web服务中造成了广泛的可用性问题。
更有意义也更令人担忧的是，亚马逊为防止这一问题再次发生而采取的措施:
- 将服务器脱机的工具进行了修改，以防止它同时脱机太多的服务器。
- 整个S3系统被重构为更小的单元，因此如果任何一个单元发生故障，它将影响更少的系统。
- 对其他工具进行审计，以确保它们不会受到与导致停机的工具相同的缺陷的影响。
为什么这引发了与公共云供应商的信任问题
毫无疑问，亚马逊AWS是一项突破性的云服务，无论是在规模上还是在为市场带来新的创新服务方面，亚马逊都将继续引领公共云市场。然而，在这种规模的操作系统的同时，不断地改变它以提供新的服务，这在计算机行业是没有人做过的。
相比之下，公共云服务的早期倡导者说，计算应该像电力一样是一种公用事业。可能有多个电力供应商，但它应该是可靠的和简单的消费。事实上，电力在美国是一种商品，而且非常可靠(通常只受天气事件的影响)。尽管在发电方式方面进行了创新，但这并没有导致每年都有大量新的电力服务推出。
所以,如果有人要运行一个服务像一个公共云,人们应该能够指望,而改变它下罩在一个连续的基础上,不断释放的改进,他们花了一个管理负担自己没有其他人在计算机行业承担。这就产生了一些非常棘手的问题，但没有一个公共云供应商愿意回答这些问题:
- 你用什么指标来衡量性能(正在)多长时间,吞吐量(单位时间)做了多少工作,能力(容量多少的存在),利用(使用多少的能力),和争用(队列有多长)在每一层的每个子系统构成你的服务呢?
- 对于每一个指标和每一个关键服务，你认为什么是正常行为，在什么情况下你认为有异常行为?
- 您是否愿意与您的客户分享和透明您的环境的运行状态?请不要告诉我们这个问题的答案是CloudWatch，因为正如你所知道的，这并没有告诉我们在引擎盖下发生了什么。
- 在环境的操作中存在何种程度的自动化?换句话说，什么行为是在没有人类参与的情况下自动发生的?
- 您的管理员使用哪些工具来管理环境，并采取了哪些控制措施来防止这些工具造成广泛的破坏?这是一个至关重要的问题，因为很明显，在资源组上执行操作对于大规模运行公共云这样的环境是必要的。
- 您的环境中是否存在单点故障(SPOFs)。如果有，他们在哪里?你有什么计划消除他们?这一点很重要，因为在对这次宕机的详细解释中，S3的索引子系统似乎是一个SPOF。
公共云供应商最关心的一个问题
AWS已经有10多年的历史了(在2006年推出)。如果AWS花了11年的时间才弄明白，那些可以让一组资源下线的工具应该有内置的限制，以防止它们一次下线太多的东西，那么还有什么问题有待解决?换句话说，在如此大规模的快速创新环境下，亚马逊还没有弄明白什么?对于幕后情况的缺乏透明度加剧了这种担忧。
企业如何在云中保护自己?
毫无疑问，将计算基础设施的管理外包给公共云供应商的想法对许多企业来说是一个有吸引力的商业想法。但是，如果您的服务和应用程序需要一直良好地工作和执行，那么您的应用程序需要对外包基础设施中的问题具有弹性。
这导致了以下潜在的建议:
- 将弹性构建到云托管应用程序中。首先，让它们在应用程序本身中分布并对SPOFs具有弹性。
- 这也意味着许多现有的应用程序不能扩展，也没有弹性，可能不适合迁移到公共云。
- 在部署中构建弹性。这意味着要跨多个Amazon Availability zone部署，甚至可能跨多个云提供商部署。
- 将容灾站点保存在搭配设施、混合云或私有云中。
- 将整个应用程序保持在您自己的私有云中。
总结
亚马逊2月28日的宕机引发了一个“还有什么是我们不知道的”时刻。亚马逊不能仅仅通过分析和修改其内部工具和流程来解决这些问题。Amazon需要在其系统的操作状态和管理这些系统的流程方面变得透明。