十起最严重的云故障及教训

由于如今更多的公司企业和应用程序将数据迁移到云端，哪怕小小的故障也会酿成严重后果。如果我们回顾一下近些年来几起最严重的云故障事件，也许能从中汲取一些经验教训，避免将来出现问题。

2009年，T-Mobile Sidekick关闭

以为云故障不可能很吓人？那只能说明你没有一直予以密切关注。

2009年秋季，微软公司的一个服务器故障给T-Mobile Sidekick的手机用户带来了大问题：他们无法访问存储在云端的电子邮件、日历信息、联系人资料和个人数据，这种状况持续了一周之久。

汲取的教训：要是你将重要的数据放在云端，绝不可丢失数据；花点时间在本地备份一下是值得的，确保数据得到妥善保管。

2013年，雅虎邮箱故障

2013年10月雅虎邮箱经历一次大规模的重新设计时，有些用户反映，邮件似乎从帐户丢失了。雅虎最终在2013年12月承认，其1%的电子邮件帐户出现了故障――结果影响到了大约100万人，有些电子邮件数周、甚至数月发送不出去。

汲取的教训：这次故障之所以让人大为沮丧是由于缺乏沟通。雅虎在公开谈论这次灾难事件时试图刻意隐瞒，而首席执行官Marissa Mayer因保持缄默而遭到炮轰。

要是果真发生了故障，公司和主管就要敢于面对。

2012年，桑迪飓风

桑迪飓风导致纽约市地区遭遇长时间的停电和大范围洪水泛滥，让该地区的许多服务器陷入瘫痪。这导致众多知名网站无法正常运行，其中包括《赫芬顿邮报》、BuzzFeed和Gawker。

汲取的教训：许多备用发电机之所以在桑迪飓风来临期间派不上用场，是由于浸了水；另一些发电机出现故障，是由于储备的柴油用完了。制定一项可靠稳健的计划，确保系统在自然灾难期间也能继续正常运行，这点至关重要。

2015年，亚马逊云服务故障

2015年9月，大量用户对DynamoDB的一项新功能发出了元数据请求，亚马逊云服务服务器因不堪重负而出现故障。因而，许多流行的应用服务和网站停运了七个小时，其中包括Reddit、Tinder、Netflix和IMDB。

汲取的教训：大多数亚马逊客户对这起故障毫无防备，但Netflix是个例外。那是由于这个流媒体网站使采用了“混沌工程”技术（chaos engineering），模拟停运，这让它为最糟糕的情形做好了充分准备。

2009年，PayPal

2009年，PayPal遇到了一次全球范围的系统故障，停运时间约5个小时。当时，该公司每秒在处理2000美元的在线电子商务，这意味着这起事件影响了价值3600万美元的个人和公司交易。

汲取的教训：移动支付系统会出故障，而且确实在出故障。可能的话，公司应支持多套支付系统，那样可以在故障期间为客户提供另外的选择。

2012年，GoDaddy

2012年，互联网服务提供商GoDaddy遭到了一次严重的故障，最初还以为是与Anonymous黑客组织有关联的某个黑客的杰作。后来查明，之所以出故障，原因是路由器表数据遭到了损坏。服务停运了6个小时，让无数的网站和电子邮件收件箱形同虚设。

汲取的教训：GoDaddy因糟糕的基础设施、糟糕的支持以及整个危机过程中糟糕的沟通而备受批评。如果你在云端有关键业务型数据，就有必要明智地选择提供商。

2013年，食品券/SNAP

施乐公司数据中心的一次停电严重扰乱了当时美国在17个州开展的一项食品券计划，持续时间超过了11个小时，取消了补充营养援助计划（SNAP）电子福利转账（EBT）卡的消费限制。

由于众多顾客往购物手推车上堆满了商品，这导致许多超市的货架被“洗劫一空”。另外一些超市只好完全停止接受SNAP卡。

汲取的教训：虽然长时间的云故障相对很少发生，但有时也会出现在重要地区。事先部署一项应对这种故障的对策很重要，当时许多商店只是拒绝饥肠辘辘的顾客，因而引发了恐慌。

2013年，纳斯达克故障

2013年8月22日，纳斯达克备用服务器的一个软件错误导致了一场彻底的故障，结果这家证券交易所三个多小时无法正常运行。系统恢复如初后，众多交易员纷纷抛售纳斯达克本身的股票，结果股价下跌了5个百分点。

汲取的教训：故障发生后不久，纳斯达克提议改变其证券信息处理系统的设计，“包括架构方面的改进、信息安全、灾难恢复方案和计算容量参数”。

2010年，Intuit云故障

2010年6月，停电事件导致财务服务公司Intuit（Quickbooks和TurboTax）的主服务器和备用服务器同同陷入瘫痪。众多公司无法查看自己的帐簿，这种状况整整持续了36个小时。雪上加霜的是，隔了不到一个月，Intuit遭到了第二次故障。

汲取的教训：如果你需要万无一失地全天候访问自己的重要财务数据，就要做一套离线备份。

2010年，Hotmail数据库故障

2010年年底，微软运行了一个脚本，删除该公司用来测试的许多虚设的Hotmail帐户。结果，脚本的一个错误却误删了17000个合法帐户。在大多数情况下，恢复帐户和恢复服务花了三天；个别情况下，花的时间更长了。

汲取的教训：我们都有各自偏爱的电子邮件提供商。不过，为了稳妥起见，有必要向第二家提供商申请一个帐户，并做好维护工作，那样万一发生紧急情况，能确保邮件可以正常收发。

新闻来源：ZDnet｜风云榜编译（未经授权谢绝转载）

云头条旗下风云榜

关注风云榜 一榜知天下