| 摘要：突发的宕机、意外的服务中断等，这些问题随时都会发生。就连当今最大最好的云计算供应商在面对服务中断时都显得束手无策。 |
突发的宕机、意外的服务中断……这些问题随时都会发生。就连当今最大最好的云计算供应商在面对服务中断时都显得束手无策。
针对以上问题，我们就云计算服务中断问题进行深入探讨，并揭示隐藏在问题背后的成因，帮助IT管理者与用户从中吸取经验教训。该文总结了各大云服务厂商的宕机事件，并根据故障的严重性给予了不同评级，希望以此来作为用户选择云供应商的依据。
微软Azure
即使是在测试阶段，云服务也有可能发生意想不到的服务中断故障。2009年3月微软云服务就出现了这种状况，当时Azure中断了近22个小时。幸好只有在试用期的测试应用受到了影响，其他应用都还没有造成重大损失。
Azure的服务中断发生在它的成长初期，但是IT管理者学会对灾难与宕机的处理方法将会明智之举。由于Azure尚处在应用早期，还没有人知道这些云计算问题会对IT造成怎样的影响，也不了解这些服务中断会对用户的信心造成多大打击。
严重等级：低
Rackspace
这家由主机托管商成功转型成云供应商的知名企业，在2009年6月同样遭受了严重的云服务中断故障，当时由于跳闸，备份发电机失效，不少机架上服务器停机。这场事故造成了严重的后果。
为了挽回公司声誉，Rackspace更新了所有博客，并在其中详细讨论了整个经过。但用户并不乐意接受。
严重等级：高
2009年11月，当Rackspace再次发生重大的服务中断后，却没有受到舆论攻击。事实上，它的用户是完全有机会在服务中断后公开指责这位供应商的，但用户却表示“该事故并不是什么大事。”看来Rackspace不是走好运，而是持续提供了充足更新并快速修复了这些错误。
在服务中断致使其业务脱机15到20分钟后，博客服务提供商Posterous的创建者之一SachinAgarwal就发表了自己的观点。Agarwal对此并不生气，相反，他表示Rackspace在这件事上做得“很透明”，处理问题也很及时到位。
看来，一次“温和”的服务中断不会让用户怨声载道，也为公司在公共领域上带来了不错印象。如果没有严重数据的丢失，并且服务快速恢复，用户依旧保持愉快的使用体验。对于所谓的“100%正常运行”，大多数用户似乎不会因为偶尔的小事故而放弃供应商，只是不要将问题堆积起来。
严重等级：低
Salesforce.com
在2010年1月，几乎6万8千名的Salesforce.com用户经历了至少1个小时的宕机。
公司称，由于自身数据中心的“系统性错误”，包括备份在内的全部服务发生了短暂瘫痪的情况。这也露出了Salesforce.com不愿公开的锁定策略：旗下的PaaS平台、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出现问题，Force.com同样会出现问题。所以服务发生较长时间中断，问题将变得很棘手。
这场服务中断还没有对公司造成很大影响，它同VMware合作的VMforce在今年春季引起很大反响，同时MarcBenioff（Salesforce.com首席执行官）在服务中断出现后的一个月内又开始宣称Salesforce.com是“最大的云计算企业”。但是我们觉得他们还应该吸取足够的经验教训。
严重等级：中等
Heroku
2010年1月，以Ruby程序语言构建的PaaS平台Heroku的约4万4千个运行服务中断，原因是其价值2万美元的高性能AmazonEC2实例出现了瘫痪。
尽管Amazon在一个小时内重启了该实例，但故障却给Heroku的产品开发者OrenTeich造成了影响。Heroku将其全部运行实例都运行在一个单一的可用区域，这样很容易发生服务中断故障。同时，缺少云计算的最佳实践造成的服务中断将阻碍到公司的发展。
“虽然我们有应急计划，但却还是不了解状况。”Teich表示。
Heroku吃一堑长一智，对于Amazon的事后处理Teich也并没有挑剔什么。在它看来，在处理云服务问题上，谨慎才是首要的指导方针。
严重等级：高
评论表单加载中...
