云计算宕机警示录

谈到云计算，用户和厂商在采用新的基础架构时，都仍在探索一种未知领域。故障问题以及意料之外的宕机都会不可避免地发生。即便是最大且最好的云厂商，在其服务偶尔的“停转”时，之前万全的计划也是徒劳。

那么，在云宕机发生时，到底什么地方出错了？IT经理和用户可以从每一次的事件中学到什么？为了帮助读者更好的运转自己的服务，这里根据宕机事故的严重程度对一些宕机事件进行了排序。

微软

即便是在测试时期，云服务都会遭遇意外宕机。微软在2009年三月就发生了这样的事情，Azure宕机22小时。试用期中只有试验的应用程序受到影响，因此没有什么大的损失。

在云计算的发展历程中，Azure宕机相当早了，但是IT经理已经知道在云端的灾备和故障时间计划是明智的第一步。然而，Azure处于初始阶段，没人知道它会对云计算产生多少影响，或者说它会如何影响宕机对于人们对于云计算的信心。

严重程度：低

太平洋时间2012年2月28日，下午5:45,全球很多Azure用户经历了Azure服务管理功能电力中断。对于大多数用户，电力中断没有影响他们的服务交付，而且他们能够对其进行管理。微软声明大多数客户在闰年2012年的宕机中，在十二小时之内进行了管理功能修复，尽管对于很多用户来说，在电力中断开始之后并没发生什么，平稳度过24小时。

严重程度：低

Rackspace
　　
2009年6月，主机托管转变成云厂商的RACKSPACE经历了一次严重宕机，当时电源跳闸，一系列的发电机备份失败，多数服务器机架安静了，这可不是危言耸听！

为了该公司的信誉，RACKSPACE在官方博客上报道了整个事件，并且在微博（推特）上就整个经历现身说法，但是评论家还是# rackspacefail #的标签满天飞。

严重程度： 高

但是在2009年11月份Rackspace又发生了一次严重宕机，糟糕的回复就没有满天飞了。实际上， Rackspace的客户有机会公然地重伤厂商的宕机时，他们却将其描述为“没什么大不了的。”这就意味着Rackspace逢凶化吉，继续提供了合适的升级和快速修复。

客户表示，在其业务脱机15-20分钟后，Rackspace非常透明且快速地处理了这个问题。这次事件，为该公司带来了保证，还解决了其公关危机。要是没有重要的数据丢失，服务也能快速复原，客户该满意还是满意的。其实那些满口“100%正常运行时间”的厂商，大多数客户似乎还是不会因为一次偶然的事故而放弃。

严重程度： 低

Salesforce.com

2010年一月，Salesforce.com的68,000名客户遭遇了至少一个小时的宕机时间。

该公司在其数据中心中报告“系统失败”,所有的一切，包括备份在这一时期都歇菜了。这样招致了一些负面关注，Salesforce.com的锁定策略Force.com成为众矢之的，这是一种平台即服务（PaaS）产品，在Salesforce.com之外就不能使用了。因此当Salesforce.com有问题了，Force.com也就挂了。

尽管此次宕机并没有对该公司造成多大伤害，其同VMware 的VMforce合作在童年春天引得热议纷纷，马克贝尼奥夫在宕机后不到一个月的时间，还夸夸奇谈Salesforce.com“是最大的企业云计算公司。”他们好像对这个不太在意。

严重程度：中

HEROKU

Heroku是一家为Ruby编程语言服务的PaaS企业，预估有大约44,000个应用安装在上面，2010年一月，价值两万美元的高容量亚马逊EC2实例在这上面挂了。

亚马逊在一小时之内让这些实例由“复活”,但还Heroku产品开发者还是受到了打击。Heroku在一个单一的可用性局域运转其所有的实例，这就导致他们主要的完整服务中断，缺少云计算最佳实践，意味着这样的宕机会阻碍其继续发展。

Heroku以这种方式喝了一壶，他们认为处理云服务时，这次事件就是“最高指令”.

严重程度： 高

TERREMARK

回顾三月份，VMware合作伙伴Terremark在七小时的宕机后，把vCloud Express的未来至于危险之地，这次事件导致了连接性没了。这次宕机据报告只有2%的客户受到影响，但是那些收到影响的人就厂商如何处理这件事上，表达了极为强烈的不满。

Terremark发言人在客户咆哮时称该公司是个“老妈子”托管公司。最厉害的是他居然把Terremark的响应和亚马逊作对比，这简直就是告诉客户，在挣扎这选谁的时候，把状态报告和服务预警都算进去吧……

当然，vCloud Director持续了一段时间，VMworld 2010上这种兴奋劲也就退去了，Terremark宕机似乎没留下多少话柄。

严重程度： 中

亚马逊

似乎所有的其他云计算宕机和亚马逊的Web服务宕机相比都是小儿科。所以云服务厂商的鼻祖，亚马逊在过去数年中遭遇的服务中断和实际的灾难均匀分布。

2009年六月，一次罕见的事故让一些客户失去亚马逊EC2服务5小时，但是大多数客户都将其看做是成长之痛。这种有点奇怪的回应方式部没有持续，在一次分布式阻断式服务攻击和漫长的电子邮件管制之后，亚马逊的灾难响应协调和客户关系开始缺失。

严重程度： 高

另外一起事件涉及了亚马逊弗吉尼亚的数据中心，遭遇了雷雨，导致系统宕机6小时，但是也从一个侧面显示了该公司的发展；亚马逊的响应时间值得肯定。

严重程度： 中

随着云计算持续发展和扩展，问题也接踵而来。五月份，一些列表面上看起来不相关的事故在亚马逊弗吉尼亚数据中心再次上演，在一周的跨度内导致了三次不同的宕机。第一次是不间断电源（UPS）转换到备份电源时失败，一机架的服务器挂了；第二次发生在四天之后，一个电源分配箱短路，导致服务中断8小时。最后两天后，一辆汽车撞击了电线杆子，切断了数据中心的电源，导致半小时宕机。不管有关系没关系，是不是大事件，这么短的时间发生这三次宕机对于任何厂商来说都不可能是个小事。

严重程度： 高

有意思的是，大多数客户似乎对于亚马逊Web服务都持有一种开放的态度。他们接受了亚马逊技术的复杂性，以及可能导致的意外问题，最重要的是他们认同亚马逊云环境的合理价格，提供了他们想要的工作价值。

亚马逊也没辜负客户的“期望”,继续宕机；当然也展示了期完美价格下的成熟度，在2010年四月份的宕机中快速做出相应。一篇超长博客发布，AWS的状态页面也定期更新，一则则简讯报告了宕机背后的原因以及如何解决的。

严重程度： 中

2011年四月，由于亚马逊在北弗吉尼亚州的云计算中心（这是块福地啊~）宕机，包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。

令人吃惊的是，亚马逊云服务中断将近4天却没有违反亚马逊EC2服务的服务等级协议（简称SLA）。亚马逊FAQ问答解释说，“它确保在365天的服务期 内一个区域拥有99.95%的服务利用率。”而这一次，几位受到影响的用户抱怨，在服务中断期间，亚马逊并没有及时公布最新的信息。退化了难道？

严重程度：高

总结

随着大多数云计算用户注意到上述的这些事件，这样的宕机在企业数据中心中频繁发生。我们所罗列的并不完全，其他的内容可自行参考其他报道。云计算并不完美，更多的宕机事件一直会发生下去。所有的顶尖厂商能做的就是学习哪些地方出错了，并修正这些问题，以免一些黑马企业通过更好的追踪记录，篡夺了其云厂商的领头羊地位。