云服务是很讨人很喜欢的概念。毕竟，丢弃那些笨重的服务器，只要给自己弄一只大容量的云硬盘就可以了。反正别人会负责维修；你想把数据放在哪里，就可以放在哪里。
当然，现实情况是喜忧参半。一方面，你可以避免维修；但另一方面，你丧失了控制。另外还需要考虑安全问题。但是一旦云服务宕机，那真的是一个活生生的噩梦。
那只要问一问今年4月受到亚马逊网络服务的重大宕机事件影响的随便一家公司。
Nick Franci说：“当时我们完全给搞蒙了；我们绝对是毫无防备。”就在亚马逊出现问题一周前，他的新兴公司Help Scout才开业。
措手不及的并非只有Francis一人。当亚马逊的云服务出现故障时，像Reddit和Foursquare这些大牌公司同样动弹不得。
Lew Moorman是Rackspace的首席战略官，这家云服务提供商也遇到过宕机事件。他说：“人们觉得云计算是一项切实可用、完全可靠的神奇技术。事实上，通过云来购买是另一种购买计算的方式，而计算本身是有缺陷的。如果你想确保那些缺陷不会影响到自己，就必须未雨绸缪。”
为了帮助贵公司在云环境下高枕无忧，我们分享了这些来之不易的经验教训，它们源自互联网经历的十大云服务宕机风暴。
第一大云服务宕机事件：亚马逊网络服务完蛋
可以摆脱繁琐的网络维护工作是在云环境开展业务的一个主要卖点。那有什么缺点吗？当云服务提供商的日常配置变更导致贵公司的业务陷入停顿时，你会有一种孤立无援的感觉。
亚马逊网络服务的许多客户在去年4月就经历了这一幕，当时亚马逊建在北弗吉尼亚州的数据中心遭到了一个故障，最后彻底歇菜了。
这个错误在网络升级升级中开始出现了，当时流量转移到错误的路径上传送后，亚马逊的一组弹性块存储（EBS）卷不断地重新映像，于是它们寻求可用的设备以便对自己进行备份。结果就引发了一连串事件，最终导致该公司在美国东部地区的服务大部分瘫痪。
这个问题持续了大约四天。但是就在许多公司苦苦挣扎的同时，Netflix等其他公司顺利渡过了难关。存活下来的关键是什么呢？那就是在设计系统时要考虑到这些类型的故障。
Netflix的几名工程师在《Netflix从亚马逊网络服务宕机中汲取的经验教训》博文中写道：“我们的架构避免使用EBS作为我们的主数据存储服务，我们实际上依赖的SimpleDB、简单存储服务（S3）和Cassandra服务没有受到这次宕机的影响。”无状态服务和数据的多个冗余热副本分散在多个可用区是避免云服务故障的关键。
是否认为自己非得像Netflix这等规模的公司才能保持安全？那你就错了。Twilio公司专门帮助开发人员把通信功能集成到自己开发的Web应用程序中，它使用亚马逊的弹性计算云（EC2）来托管其基础架构的核心部分——不过亚马逊的宕机事件对于该公司的稳定运行几乎没什么影响。
Twilio的联合创办人兼首席技术官Evan Cooke说：“将业务建立在云环境上的基本前提是，要假定网络会有这样那样的故障和毛病。我们在建立基础架构时就设想主机可能会出现故障，于是我们没有依赖核心架构中的任何一台机器或任何一个组件。”
第二大云服务宕机事件：Sidekick宕机
智能手机让你出门在外时很容易访问自己的数据，但就因为某样东西的名字里面有“智能”（smart），并不意味着它就万无一失。一个典型例子就是：T-Mobile的Sidekick在2009年秋天前后搞砸了。
还记得那次惨败吗？微软旗下的Sidekick遭遇了服务将近一周宕机的尴尬，导致用户们无法访问电子邮件、日历信息及其他个人数据。后来雪上加霜的是，微软承认自己完全丢失了存储在云环境中的数据，自己无力恢复。显然，来自雷德蒙的那群技术精英们之前忘了备份数据。
也许此后技术有所发展，但教训仍然一样：说到关键数据，千万不要想当然地以为别人会自动保护你。确保你了解云服务提供商的灾难恢复系统；如果你自己作了安排，独立备份重要数据，那就更好。
SmartBear旗下AlertSite公司的监控产品副总裁Ken Godskind说：“同样的操作规则甚至适用于云环境。使用云服务的企业千万不要想当然地以为，就因为数据在云环境中，业务连续性规划方面的全部责任可以一股脑儿地扔给提供商了。”
第三大云服务宕机事件：Gmail故障
在所有云服务iv 中，谷歌的Gmail是比较有可能在企业领域危及微软预置型软件的劲敌之一。把需要精心维护的Exchange服务器换成由Postini支持的一种廉价而可靠的电子邮件服务。谁不喜欢呢？
此后出现了一连串令人恼恨的宕机事件，最近一次是15万个Gmail用户登录进入到帐户，结果却发现里面空空如也：没有电子邮件，没有文件夹，没有什么可以表明他们看到的就是自己的收件箱。值得肯定的是，谷歌定期提供更新版，承诺很快会拿出权宜之计。但对于一些受到影响的用户来说，维修过程前后长达四天。
谷歌工程副总裁Ben Treynor当时在一篇博文中问道：“如果我们将客户数据的多个副本放在多个数据中心，怎么可能会发生这种事？在一些罕见的情况下，软件缺陷会同时影响数据的数个副本。这种事偏偏落在了我们头上。”
谷歌最后不得不使用实际的物理磁带备份来恢复数据。最终，这家公司的多层数据保护体系确实发挥了效果，却使得成千上万个用户在数天内无法使用电子邮件服务。
那这是不是可以成为对任何云服务避而远之的理由？恐怕不是。但确实有必要认真关注你自己的数据保护措施，考虑立即着手制定一套备份或离线访问解决方案。
AlertSite公司的Ken Godskind说：“从总体上来看，云成功运行的机率比个人运行要大得多。只不过面对互联网时，故障造成的影响会被放大好多倍。”
第四大云服务宕机事件：Hotmail乱成一团糟
当然，尽管微软大力推行云服务，但它并非总是能够给出最好的例子。以微软的Hotmail服务为例：这项服务在2010年底同样遭到了数据库错误，导致成千上万个收件箱在辞旧迎新之际空空如也。
据微软声称，这个错误归咎于一段脚本，这段脚本原本用于删除为自动测试设立的假设帐户。但结果这段脚本误把17000个真实有效的帐户当成了虚设帐户。
微软花了三天的时间才为大多数受影响的用户恢复服务。遗憾的是，8%受影响的电子邮件用户不得不多等三天，之后数据才恢复如初。
面对这样的棘手问题，连Office助手Clippy都笑不出来。
第五大云服务宕机事件：Intuit接连两次宕机
Intuit在去年很不走运：在短短一个月内，其基于云的服务接连宕机了两次，包括TurboTax、Quicken和QuickBooks等大受欢迎的平台。最糟糕的情况是6月份宕机了整整36个小时。电源故障显然导致服务出了毛病，该公司的主系统和备用系统从电网完全断开。
屋漏偏逢连夜雨，几个星期后Intuit遇到了另一次明显的电源故障。除了带来其他问题外，第二次宕机似乎还引起众多用户在网上大爆粗口。
一个用户当时在Twitter上发送了这样的消息：“宕机25个小时让人很难接受。Intuit的一套被动的、缺乏透明的、死板的沟通方法无助于事。”
真是要命。
惠普Secure Advantage计划的首席战略师Chris Whitener说：“现实情况是，如果你需要绝对的可用性，现在有比选择单单一家云服务提供商更好的解决方案。你没必要什么都复制，但是如果另外采取一个步骤（可能是你自己备份关键数据），情况就完全不一样了。”#p#
第六大云服务宕机事件：微软的BPOS致歉
如果你那基于云的生产力套件无法使用，工作效率就很难有保障。仅仅几周前，依赖微软商业云服务解决方案的公司企业就遭到了这种情况：名为微软商业生产力在线标准套件（BPOS）的这项服务在5月10日前后开始停顿。结果，付费客户的电子邮件被延迟了长达9个小时才发送。
两天后，就在看起来BPOS没有故障时，邮件延迟发送的毛病又来了，发出去的邮件开始堆积如山。好像嫌这个问题不够糟糕，微软遇到了另一个问题：用户们还无法登录到微软基于互联网的Outlook门户网站。
微软在线服务部企业副总裁Dave Thompson在博客中写道：“对于这些问题明显带来的不便，请允许我向诸位、我们的客户和合作伙伴深表歉意。”
第七大云服务宕机事件：Salesforce的不幸事故
宕机一个小时听起来似乎没什么大不了，但是当成千上万家公司的客户服务运营与贵公司息息相关时，那些客户势必会认为那60分钟漫长得要命。
当Salesforce.com的数据中心在去年1月宕机时，它对此可是深有体会。新年过后才四天，Salesforce.com就宣布遇到了彻底的故障——这意味着服务、备份和其他一切都完蛋了。
令人抓狂？绝对如此。令人惊讶？不完全是。
柯尼卡美能达公司旗下All Covered部门的首席信息官Tim Crawford说：“现实情况是，基于云的数据中心同样会停止运行。过去一向如此，将来也是如此。我们一定要从现实的角度看待这个问题。”
Crawford表示，成功的云计算需要有一种不同于传统服务器环境的理念：他认为，决定着贵公司的数据能不能经受得住偶尔宕机的是你自己，而不是别人；你要确保自己的配置具有避免宕机所需的弹性。
Crawford说：“你在选择一家云服务提供商时，必须事先做好功课，了解对方如何提供这些服务；是否能够提供与你自己能够实现的冗余级别一样好或更好的冗余级别。如果答案是否定的，那干嘛还要使用它们？”
第八大云服务宕机事件：Terremark的可怕一天
近期，Terremark可能因被韦里逊（Verizon）斥资数14亿美元收购的交易而见诸报章；但是在2010年初，一起长时间的宕机事件却让这家云服务提供商成为被媒体竞相报道的对象。
Terremark在2010年3月17日的圣帕特里克节走了霉运。这家公司的vCloud Express服务在那一天一蹶不振，建在迈阿密的数据中心宕机了将近7个小时。在这整段期间，广大用户无法访问该数据中心里面存储的数据。
不要过于追求冗余，但这起事件表明了冗余机制的重要性——要将你的关键数据放在不同数据中心的多台服务器上；或者更安全的做法是，放在不同地区的多台服务器上。还可以采取进一步的措施：将关键数据分散在多个提供商之间，作为一项保险措施。
IBM公司的云安全策略项目首席技术官Harold Moss提议：“你可以选择一系列提供商来托管工作负载——某一两家提供商充当后备提供商，另一家提供商充当主提供商。然后，你以一种安全的方式将工作负载部署到那里，确保合适的安全机制，随后开始添加你的弹性功能。”
第九大云服务宕机事件：PayPal遭遇宕机
想体验一把带来很严重的深远影响的云宕机事件？不妨试试几小时无法使用PayPal服务的感觉。
这可不是假设性的演练：PayPal在2009年夏天确实遭遇宕机，导致世界各地的数百万商家根本无法销售产品和服务。大概有一小时的光景，其服务完全无法使用；接下来的几小时，服务仍然时断时续。PayPal表示，问题出在了硬件故障。
毫无疑问，这种宕机很罕见——但由于所有生意都错失了，这次不幸的服务宕机在云计算的耻辱柱上轻松占得一席之地。
第十大云服务宕机事件：Rackspace的不顺年
如果你为像美国科技博客TechCrunch和流行音乐天王Justin Timberlake这样的知名网站和网络红人提供云服务，最好还是相信这一点：一旦你的服务器停止运行，人们肯定会注意到。
Rackspace在2009年数次汲取了这个教训。这家云服务提供商在那一年前后遭到了四次重大的服务故障，使得这家公司的众多客户的停机时间共长达数小时。一次故障就足以让Rackspace不得不向用户支付相当于近300万美元的服务折扣。
Rackspace称这些事件“让人痛苦不堪，非常失望”，并承诺之后会“提供长时间的高级别服务”。今天，这家公司继续关注正常运行时间，但同时也在努力帮助用户为不可避免的云服务故障作好防备。
Rackspace的Lew Moorman说：“如果你想建立服务器集群或建立地区冗余机制，那么现在比以前更容易做到，但你必须切实地采取那些步骤。如果你以前在企业内部做了这些步骤，你也不用担心云服务故障了。”
从各方面考虑起来，云服务方面最大的教训也许就是，没有哪一台服务器、哪一个数据中心或哪一项服务是绝对可靠的。如果你使用云服务开展业务时没有考虑到这一点，那么我的朋友，你在完全无视实际存在的危险。
