我们从亚马逊(Amazon)云事故上能学到什么教训

不管你称它为“云关”，“云终结”，或其它你喜欢的名词，总之，亚马逊的Elastic云计算服务持续的事故既可以被当作云计算的一次挫折，也可以被当作让我们知道如果防止它再次发生的契机。

对于Amazon来说最出名的还是它的电子商务网站，但它的云计算服务同样是占有相当大的份量。它为各种公司提供了一个可扩展的、灵活的、非常高效的存储和传输它们大量数据的解决方案。它的这种从2006开始的按需购买的模式是一个全新的革命。

实际效果上，Amazon的Web Service是如此的经济和可靠，以至于有成千上万个像Foursquare 和Netflix 这样的公司都利用它们的云计算技术和服务来运营自己的业务。它们把自己的命运交给了Amazon的云服务，因为没有任何理由相信这个大厦会动摇一下。云计算的一个关键信条就是通过服务器和数据的双冗余来保证可靠性。

然而，在周三，Amazon的弗吉尼亚州北部数据中心开始出现问题，导致用户访问严重延迟和连接问题。这个问题显然是由于过度的重镜像它的Elastic Block Storage (EBS)造成的——它事实上致使 EBS产生了无数的备份，最终耗尽了Amazon的存储空间，触发了一连串的连锁反应，导致了数以百计(很有可能上千家)网站最多时长24小时的宕机。

很多公司成了这次事故牺牲品。这其中最著名的受到影响的公司有Foursquare, Quora, Hootsuite, SCVNGR, Heroku, Reddit 和 Wildfire，还有很多其它大大小小的公司。幸运的是，Amazon的一个最重要的客户，Netflix，并没有受多大的影响，因为它们有自己的应付整个数据中心的数据丢失的备份。同时依赖于Amazon的其它四个全球数据中心的客户并没有收到多大影响。

反省时间

FathomDB的创始人Justin Santa Barbara在他的博客了发布了一篇文章详细的讨论这次事故引出的最大的问题：Amazon的云冗余并不能阻止大规模的宕机。Amazon的Availability Zone原先被人们认为是可以阻止由于个别的问题而导致整个系统崩溃的。而现实情况却相反。

这次的云服务的灾难对于中小创业公司是个提醒，他们应该在自己的系统里做好冗余备份，但Santa Barbara 指出，大多数的小公司没有时间和资源做这种技术上的多套云系统(Amazon的各全球区域/数据中心都有其各自的规则和特点，在各中心之间做简单的转移是困难的)。这些公司都信任Amazon能保持他们的数据时刻有效，而Amazon却没有做到。

灾难是避免不了的，但在云计算之前，宕机只会影响一个计算机或网站。如今，灾难会拖垮成千上万的网站，致使数百万甚至数亿美元的损失。

当然，我们不会因为这次事故就拒绝云计算。云计算的益处(可扩展，成本低，设备独立，性能高等)大大盖过它的弊处。我们需要下功夫研究如何构建我们的云基础设施，找到新的方法，要么阻止单点引起的事故，要么能迅速的把数据移出有问题的云服务。这在如今世界上的云计算力量越来越集中到少数几个系统之上的情况下更显的重要。

云计算仍处在探索期，这次事故让我们更清楚的看到我们还有很多工作要做。如果我们不进行准备，下次可能会更严重。

:)