前车之鉴：各大云服务那些“成长的烦恼”

导读：本文总结微软Azure、亚马逊AWS等云服务中断故障。

关键词：云计算 云服务中断故障汇总 微软Azure 亚马逊 AWS

 正在加载数据...

【TechTarget中国原创】云计算时代正迎面而来，但在适应这些新型基础设施方面，用户与供应商似乎一样都在摸着石头过河。

　　突发的宕机、意外的服务中断……这些问题随时都会发生。就连当今最大最好的云计算供应商在面对服务中断时都显得束手无策。

　　针对以上问题，我们就云计算服务中断问题进行深入探讨，并揭示隐藏在问题背后的成因，帮助IT管理者与用户从中吸取经验教训。该文总结了各大云服务厂商的宕机事件，并根据故障的严重性给予了不同评级，希望以此来作为用户选择云供应商的依据。

　　微软Azure

　　即使是在测试阶段，云服务也有可能发生意想不到的服务中断故障。2009年3月微软云服务就出现了这种状况，当时Azure中断了近22个小时。幸好只有在试用期的测试应用受到了影响，其他应用都还没有造成重大损失。

　　Azure的服务中断发生在它的成长初期，但是IT管理者学会对灾难与宕机的处理方法将会明智之举。由于Azure尚处在应用早期，还没有人知道这些云计算问题会对IT造成怎样的影响，也不了解这些服务中断会对用户的信心造成多大打击。

• 严重等级：低

　　Rackspace　

　　这家由主机托管商成功转型成云供应商的知名企业，在2009年6月同样遭受了严重的云服务中断故障，当时由于跳闸，备份发电机失效，不少机架上服务器停机。这场事故造成了严重的后果。

　　为了挽回公司声誉，Rackspace更新了所有博客，并在其中详细讨论了整个经过。但用户并不乐意接受。

• 严重等级：高

　　2009年11月，当Rackspace再次发生重大的服务中断后，却没有受到舆论攻击。事实上，它的用户是完全有机会在服务中断后公开指责这位供应商的，但用户却表示“该事故并不是什么大事。”看来Rackspace不是走好运，而是持续提供了充足更新并快速修复了这些错误。

　　在服务中断致使其业务脱机15到20分钟后，博客服务提供商Posterous的创建者之一Sachin Agarwal就发表了自己的观点。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在今年春季引起很大反响，同时Marc Benioff（Salesforce.com首席执行官）在服务中断出现后的一个月内又开始宣称Salesforce.com是“最大的云计算企业”。但是我们觉得他们还应该吸取足够的经验教训。

• 严重等级：中等

　　Heroku

　　2010年1月，以Ruby程序语言构建的PaaS平台Heroku的约4万4千个运行服务中断，原因是其价值2万美元的高性能Amazon EC2实例出现了瘫痪。

　　尽管Amazon在一个小时内重启了该实例，但故障却给Heroku的产品开发者Oren Teich造成了影响。Heroku将其全部运行实例都运行在一个单一的可用区域，这样很容易发生服务中断故障。同时，缺少云计算的最佳实践造成的服务中断将阻碍到公司的发展。

　　“虽然我们有应急计划，但却还是不了解状况。”Teich表示。

　　Heroku吃一堑长一智，对于Amazon的事后处理Teich也并没有挑剔什么。在它看来，在处理云服务问题上，谨慎才是首要的指导方针。

• 严重等级：高

　　Terremark

　　让我们再回到三月，7小时的服务中断使得VMware的合作伙伴Terremark险些将vCloud Express的未来断送掉，受影响用户称故障由“连接丢失”导致。据报道，运行中断仅仅影响了2%的Terremark用户，但是造成了受影响用户的自身服务瘫痪。此外，用户对供应商在此次事情上的处理方式极为不满意。

　　Terremark的企业客户Protected Industries的创立者John Kinsella，在抱怨服务中断让他心灰意冷时称该供应商是“杂货铺托管公司”。Kinsella将Terremark与Amazon做了比较，他抱怨说，Terremark才开始考虑使用的状态报告和服务预警Amazon早已实现。

　　当然，在对vCloud Director的大肆宣传以及VMworld 2010兴奋地揭幕过后，Terremark服务中断事件似乎只留下了很小的余波。

• 严重等级：中等

　　Intuit

　　在今年6月，Intuit的在线记账和开发服务经历了大崩溃，公司对此也是大惑不解。包括Intuit自身主页在内的线上产品在内近两天内都处于瘫痪状态，用户方面更是惊讶于在当下备份方案与灾难恢复工具如此齐全的年代，竟会发生如此大范围的服务中断。

　　但这才是开始。大约1个月后，Intuit的QuickBooks在线服务在停电后瘫痪。这个特殊的服务中断仅仅持续了几个小时，但是在如此短时间内发生的宕机事件也引起了人们的关注。

　　即使一些用户要求“武装”其品牌，Intuit依旧拥有4百万用户并继续进军PaaS和Web服务供应商之路。公司没有Amazon和Rackspace这样的知名度，中断也没有造成很大的影响。Intuit主要因Quicken而闻名。

• 严重等级：高

　　Amazon Web Services

　　相比Amazon Web Services的服务中断，其他的云计算服务中断故障简直就是小儿科。作为所有云服务供应商的“鼻祖”，Amazon在最近几年同样遭受着服务中断以及各种灾难的困扰。

　　2009年6月，一场意外事故导致部分用户尽5个小时不能使用Amazon EC2服务，但是大多数用户把这场故障视为“成长中需要经历的痛苦”，但这些令人鼓舞的舆论并没有持续很久。分布式拒绝服务攻击和邮件失效显现出Amazon在灾难应对处理和用户关系协调方面的缺失。

• 严重等级：高

　　另外还有一场奇怪的事故，由于Amazon位于弗吉尼亚州（Virginia）的数据中心受到雷雨影响，导致系统宕机了近6个小时，但Amazon在对该事故的处理方式上进步不少。Amazon获得了Apparent Networks主席Jim Melvin高度评价，他对Amazon的应对时间给予很高评价，并暗示Amazon从服务中断中积累了不少成果。

• 严重等级：中等

　　随着云计算的发展与扩大，问题会依旧存在。5月份，一系列看似不相关的事故发生在Amazon位于弗吉尼亚州（Virginia）的数据中心，导致一周之内三次服务中断。第一次由于不间断电源（UPS）切换备用电源失败，同时造成整架的服务器停机；第二次服务中断发生在4天之后，当时电力调度平台短路，服务器停机8小时；最后一次发生在两天后，车辆撞上了电线杆，切断数据中心供电达半小时之久。对于任何供应商来说，在如此短的时间段内发生三次服务中断都是大问题。

• 严重等级：高

　　但是经历了这些事件，大部分的用户似乎宽容地接受了Amazon Web Services。他们采纳了Amazon的复杂技术，虽然这将有可能带来未知的问题，最重要的是，他们认同Amazon价格合理的云计算环境下的工作价值。

　　Amazon也的确没有辜负用户的信任。针对2010年4月的服务中断故障，Amazon借助可视化支持展现出它成熟的响应机制。相关的博客推出，AWS状态页面也有服务中断背后原因相关的简讯、信息以及解决方案定期性地更新。

• 严重等级：中等（偏低）

　　总结

　　部分云计算用户可能已经注意到，在前面提到的事故中频繁出现的服务中断大多源自公司的数据中心。差别在于有些是由内部、成熟技术发生事故，有些是非普及、发展中的未知技术（比如云计算）造成的呢。

　　云计算并不是完美无缺的，随时都会有服务中断故障发生。上述这些大企业要做的就是研究这些错误产生的原因，并改正这些问题，以免被后起之秀取代。