为了帮助企业避免在云服务中出现故障，本文提供了网站曾经历过的十个最严重的云服务中断故障以及我们能够从中吸取的教训。

　　严重的云中断1：亚马逊Web服务中断。免除你乏味的网络维护工作是在云中做生意的主要卖点。但是他的缺点是：当你的云厂商例行性改变配置让你的业务中断的时候，你会束手无策。

　　这是许多亚马逊Web服务用户在今年4月经历的事情。当时，亚马逊北弗吉尼亚州的数据中心出现故障，完全无法使用。

　　这个故障是在网络升级期间发生的。当时，信息寻找可用的设备把自己作为备份嵌入到这些设备中时，一个错误路线的通讯移动把一连串的亚马逊EBS(弹性块存储)通讯量发送到一个重新镜像的风暴。这是一种反常的现象。这引起了一系列事件，最终导致亚马逊在美国东部地区的许多服务中断。

　　这个故障持续了大约四天时间。但是，在许多企业陷入困境之中的同时，Netflix等其它公司的排除了故障。生存的关键是什么?设计系统的时候就要考虑到这种类型的故障。

　　Netflix工程师在题为“Netflix从亚马逊Web服务中断故障中吸取的教学”的博客中称，我们的架构避免使用EBS作为我们的主要数据存储服务。我们依靠的SimpleDB、S3和Cassandra服务从而没有受到这次中断事故的影响。无国家的服务和可用地区的数据的多个冗余热拷贝是避免亚马逊Web服务云故障的关键。

　　考虑一下你必须是Netflix规模的企业才能保证安全吗?再考虑一下。帮助开发人员把通讯与其Web应用程序集成在一起的Twilio公司利用亚马逊的EC2服务托管其核心的基础设施。尽管如此，4月份的中断故障对它的稳定性几乎没有影响。

　　Twilio共同创始人和首席技术官Evan Cooke称，建立云的前提是假设这个网络将出现故障。我们围绕着主机能够并且将发生故障这个思路建立了一个基础设施。因此，我们不依赖于核心架构本身的任何一台机器或者一个组件。

　　严重的云中断2：Sidekick关闭。智能手机让你很容易在移动中访问自己的数据。但是，某些东西并不能因为名字中有“智能”二字而不会傻。例证：大约在2009年秋季发生的T-Mobile Sidekick中断故障。

　　还记得这次大惨败吗?微软拥有的Sidekick遭受了将近一个星期的服务中断，使用户不能访问电子邮件、日历信息和其它个人数据。后来，微软承认它完全失去了云存储的数据并且也许不能回复这些数据。微软的人员显然忘记了做备份。

　　这个技术从那以后也许已经发展了。但是，教训是相同的：当涉及到重要数据的时候，永远不要假设其他人将自动保护你。要保证你理解你的云提供商的灾难恢复设置。最好是制定独立地备份你的重要数据的计划。

　　AlertSite公司负责监视产品的副总裁Ken Godskind称，同样的运营规则甚至适用于云。使用云的机构不能仅仅假设因为它是在云中，业务持续性计划的全部责任已经交给了提供商。

　　严重的云中断3：Gmail故障。在所有的云服务中，谷歌Gmail是对微软在企业中内部安装的邮件服务堡垒的最大威胁之一。使用Postini支持的便宜的独立的电子邮件服务取代你的维护成本高的Exchange服务器。有什么不一样?

　　许多令人讨厌的中断。最近的中断故障让15万Gmail用户在登录自己的账户之后只看到一个空白页，没有邮件和文件夹，没有任何东西表明他们实际上在看自己的收件箱。值得赞扬的是，谷歌提供了定期的更新并且承诺迅速修复故障。但是，对于某些受影响的用户来说，谷歌修复这个故障用了4天时间。

　　谷歌负责工程的副总裁Ben Treynor当时在博客中称，如果有你的数据的多个副本，怎么会发生这样的事情?在很少出现的情况下，软件瑕疵能够影响几份数据。那就是这里发生的事情。

　　谷歌最后不得不改用物理磁带备份以便恢复数据。最终，谷歌的多层数据保护确实发挥了作用，但是，还是让数千用户在几天时间里无法访问其电子邮件。

　　故障是不使用云连接的东西的一个理由吗?也许不是。但是，这是在紧迫的需求出现之前，认证检查你自己的数据保护和考虑建立备份或者离线访问解决方案的一个理由。

　　AlertSite公司的Ken Godskind称，当你查看广泛的平均状况时，云的运行成功率远远高于你个人的运行成功率。这只是当你进入到Web规模时，故障的影响以更大的方式放大了。

　　严重的云中断4：Hotmail一团糟。当然，微软也为大力推广其云服务提供最好的广告。微软Hotmail在2010年年底出现了数据库错误，导致数万个收件箱在转换到新的一年的时候都被清空。

　　微软称，这个故障是一个脚本错误造成的。这是为自动测试创建的一个删除虚账户的脚本。这个脚本错误地删除了1.7万个真正的账户。

　　微软用了三天时间恢复了大多数用户的账户。大约8%的运气不佳的用户必须再等待三天时间才能恢复自己的数据。

　　严重的云中断5：Intuit两次中断。Intuit去年遭遇一次严重故障。它的基于云连接的服务，包括TurboTax、Quicken和QuickBooks等流行的平台在一个月内发生两次断网事故。最最糟糕的一次是去年6月的一次36小时断网事故。一次电源故障显然导致主要设备使用备用电源，该公司主要的和备份的系统完全断网。

　　更糟糕的是，几个星期之后，又发生了一次明显的电源故障。此外，第二次中断显然引起了人们的大骂。

　　一个用户当时在微博中称，25小时的断网是很难忍受的。Intuit的被动的、不透明的和无法接受的沟通没有帮助。

　　惠普安全优势计划主要战略家Chris Whitener称，事实是，如果你需要绝对的可用性，有比一个云更好的解决方案。你没有必要备份一切，但是，你在那里采取一个额外的步骤(也许仅依靠自己备份重要的数据)就会产生完全不同的结果。

　　严重的云中断6：微软BPOS(商务办公在线套件)故障。当你的基于云的办公套件出现故障时，那是很难有办公效率的。那是几个星期前依赖微软商务云服务的机构发生的事情。在5月10日左右，微软BPOS服务开始出现断断续续地工作的情况。一些用户的电子邮件因此延迟了9个小时才收到。

　　两天后，就在BPOS好像排除了故障的时候，延迟的现象又发生了，向外发出的信息也阻塞了。如果这个事故还不够的话，微软还经历了另一个故障，阻止用户登录基于Web的Outlook门户网站。

　　微软在线服务部门副总裁在博客中称，我要因为这个故障引起的这些不便向你们、我们的客户和合作伙伴表示道歉。

　　严重的云中断7：Salesforce服务中断。一个小时的断网故障听起来也许不严重。但是，如果你的公司拥有数万家企业客户服务业务的关键，许多这样的机构肯定要把这60分钟看作是生命期。

　　当去年1月数据中心关闭的时候，Salesforce.com吸取了深刻的教训。在进入新的一年刚刚四天的时候，Salesforce.com报告了一次全面的故障，也就是说服务、备份等全套服务都中断了。

　　令人厌烦？绝对如此。令人意外？不完全意外。

　　柯尼卡美能达的子公司All Covered的首席信息官Tim Crawford称，现实是基于云的数据中心也中断了。那一直是故障的原因并且总是这种情况。我们对此必须现实一些。

　　Crawford称，成功的云计算需要一个与传统的服务器设置不同的思维方式。你要自己决定你的企业的数据是否能够承受偶尔的断网。如果不能承受，你要保证你的配置有避开断网故障所需要的弹性。

　　当你选择一个云提供商的时候，你需要做家庭作业以理解他们如何提供这些服务，他们是否能够建立比你自己做的还要好的冗余水平。如果答案是否定的，那么，你为什么要使用这些云提供商呢?

　　严重的云中断8：云提供商Terremark可怕的一天。最近，Terremark与Verizon之间的10亿美元的交易也许成为了重要新闻。但是，在2010年年初，主要报道的新闻是Terremark的断网事故。

　　在2010年3月17日的圣帕特里克节，Terremark的运气开始变坏。该公司的vCloud Express服务在那一天急转直下，在迈阿密的数据中心断网了大约7个小时。在这段时间里，用户不能访问存储在这个数据中心的数据。

　　没有得到更多的冗余。但是，这带来的冗余的价值，让你的重要数据提供到不同数据中心的多台服务器，或者最好是提供到不同地区的多台服务器。作为一种故障保险，你还可以采取额外的步骤把数据分散到不同的提供商。

　　IBM云安全战略计划首席技术官Harold Moss称，你可以选择一系列厂商托管一个工作量，一个厂商负责备份或者两个厂商负责备份，然后选择一个厂商作为你的主要提供商。然后，你可以在安全的情况下实施你的工作量，有适当的安全并且开始引进你的弹性能力。

　　严重的云中断9：PayPal断网故障。要一个引起广泛的严重影响的云断网故障吗?设法让PayPal断网几个小时就可以看到。

　　这不是假设的演习：2009年夏季PayPal的断网故障是真的，让全球数百万台机器无法销售商品。这项服务在大约一个小时的时间里完全不可用，在后来的几个小时里仍是断断续续的。PayPal称，硬件故障是事故的原因。

　　毫无疑问，这种中断故障是很少发生的。但是，这个不幸的断网故障使PayPal轻松在云计算的耻辱堂上赢得一个位置。

　　严重的云中断10：Rackspace的坎坷年。当你向TechCrunch和Justin Timberlake等网站提供云服务网的时候，你最好相信当你的服务器停止工作的时候，人们会注意到。

　　Rackspace在2009年吸取了几次教训。这家云提供商在2009年全年遭遇了四次引人瞩目的断网故障，使该公司的客户的断网时间达到几个小时。Rackspace不得不向用户赔偿了将近300万美元的服务费。

　　Rackspace把这些事故称作“痛苦的和非常令人失望的”并且承诺以后在很长时间里都要高水平地提供服务。目前，该公司继续把重点放在运行时间方面，但是还帮助用户制定计划准备应对在云服务中不可避免地出现的混乱局面。

　　Rackspace公司的Lew Moorman称，如果你要建立一个服务集群或者建立地理位置的冗余，现在要比以前容易做到。但是，你必须采取这些步骤。如果你以前在企业内部做过这个事情，这个云不会带来可能出现的弱点。

　　考虑到所有的故障，这里最大的教训是没有一个单个的服务器、中心或者服务是百分之百可靠的。如果你不以这种思路建立你的业务，那么，我的朋友，你就是在不切实际地到处走。