Yottaa回顾2012年最糟糕的15次网站故障

Yottaa是一家专门提供网站监控和分析优化服务的公司，其客户包括Answers.com等知名网站。前不久，他们回顾2012年，评选出了这一年最糟糕的15次网站故障。

第15名：Google App Engine

时间：10月26日，星期五

原因：峰值流量

10月26日美国东部标准时间上午10：30至下午2：30，Google App Engine有50%的请求都处理失败。因为有数十万开发者用其创建应用，这次故障对整个互联网打击很大。故障源于流量路由器无法承受增加的负载。

第14名：Tumblr

时间：10月18日，星期四

原因：网络问题

Tumblr是我们无法访问的网站。它在美国东部标准时间上午8：30开始，遭遇故障，原因是：

网络故障，以及随之而来的上行链路提供者出现问题

持续了大约6个小时候，下午2：15分恢复正常。

第13名：Salesforce

时间：7月10日，星期二

原因：电源故障

在早上，Salesforce遭遇严重故障，影响了公司6个地区。后来发现，导致故障的，是硅谷一个Equinix的数据中心出现电源故障。尽管电源故障只出现1分钟，但是完全恢复服务却用了9个小时。这次故障发生几周前，刚刚有一次小事故。

第12名：Twitter

时间：6月21日

原因：级联bug

Twitter因其故障之严重而声名狼藉，在6月21日中午再次无法访问。故障持续3个小时，此后Twitter认为问题在于：

我们的一个基础架构组件中出现级联bug

本次故障实在太严重，以至于著名的“失败的鲸”页面都无法加载，网站只是给出超时提示。本次故障也是Twitter8个月以来最长、最糟糕的一次崩溃。

第11名：Github

时间：10月16日，星期二 —— 10月18日，星期四

原因：DDoS攻击

在周二和周三，Github遭遇了多次故此，有26分钟因为网络问题，有24分钟因为其搜索访问出现错误。在周四，Github遭受DDoS攻击达5个小时之久。很多公司的开发者和世界各地的创业公司的工作都陷于停滞，他们无法pull或是push任何代码。总的来说，这对Github是艰难的一周。

第10名：Kohl's

时间：11月21日，星期四

原因：流量峰值

Kohl's为黑色星期五的顾客们举办了一次大型的在线特别抢购活动，提供超过500个早到者（early bird）特惠、20%折扣价、还有超过50美元的免费送货。本次促销在感恩节前一天开始，到黑色星期五下午3点结束。然而，由于突然出现的网络流量，在感恩节晚上，Kohl's的网站经历了多个小时故障。作为当年在线流量最大的一周，几个小时宕机对在线零售商来说有着不可估量的损失。

第9名：超级碗（可口可乐、Acura、《勇者行动》）

时间：2月5日，星期日

原因：峰值流量

与 2013年的超级碗一样，2012年，同样有不少广告主的网站因为峰值流量遭遇严重故障。

第8名：Facebook

时间：6月1日，星期四 —— 6月2日，星期五

原因：“Like”按钮

在6月1日和6月2日，Facebook的大多数用户感到网站很慢，甚至完全无法访问。对于拥有10亿全球用户的Facebook来说，任何故障对它都是严重的损害。更糟糕的是：Facebook这次故障影响了数千家零售和内容提供网站。为什么？因为“Like”按钮。类似“Like”按钮这样的第三方widget，依赖于提供该widget的第三方的服务器和性能（第三方widget也是造成性能低劣的主要罪魁祸首之一）。因此，当Facebook出现问题时，集成了“Like”按钮的网站就会出现5至20秒不等的性能低下。

第7名：美洲银行（Bank of America）

时间：9月14日，星期五 —— 9月19日，星期三

原因：服务升级、峰值流量

9月14日，美洲银行在主页上给出信息：“我们有些页面暂时无法访问”。问题在周六不时出现，但在周一进一步恶化，出现无法访问的页面。从周二上午十点开始，绝大部分用户无法链接到美洲银行网站，因为缓慢或超时失败。问题直到周三早上才解决。有人推测问题源于DDoS攻击，但美洲银行否认该指控。他们将故障原因归结于月底的流量暴增，以及新代码的发布，将老客户迁移到新平台上。

第6名：Hosting.com

时间：7月27日，星期五

原因：电源故障

Hosting.com早上的故障造成1100家客户网站宕机长达5个小时。根据CEO Art Zeile的说法：问题来自人为错误，一个工程师在维护服务器时，错误切断了设备电源。尽管只切断了几分钟，但是所有的服务器都需要重新启动，延长了客户的宕机时间。大部分网站所有者没有备份托管，也没有对这样的故障有所应对。

第5名：飓风桑迪

时间：10月29日，周一 —— 11月5日，周一

原因：自然灾害

飓风桑迪打击东海岸，导致纽约和新泽西州多家主要数据中心出现问题，影响很多热门网站，包括Gawker Media、Huffington Post和BuzzFeed。飓风不时造成故障，直到一周之后，数据中心才能恢复电力，重新启动。

Yottaa特别表扬了Squarespace，因为他们在3天内每天都将油拎上17层楼，这都是为了给超过1百万家网站提供100%的正常运行时间。

第4名：闰秒bug

时间：7月1日，星期日

原因：闰年导致原子钟要加上额外的一秒

闰秒Bug导致很多常用服务出现故障，包括Reddit、LinkedIn、Yelp Gawker Media、Foursquare、StumpleUpone、Mozilla和微软的Windows Azure。简单解释下闰秒：每18个月，因为地球自转放慢，要为原子钟加上一个闰秒。从1972年到现在，已经整整加上了24个闰秒。小小的一秒，导致Java和数字证书应对新时间戳出现问题，从而导致这些服务故障。

第3名：苏格兰皇家银行

时间：6月19日，星期二 —— 8月2日，星期四

原因：批处理作业

这次故障影响了苏格兰皇家银行（Royal Bank of Scotland，简称RBS）、NatWest和Ulster Bank的1千7百万客户，IT人员要承担主要责任。问题发生在系统维护过程中，这次维护导致他们的自动化批处理调度器和处理器出错。导致数百万顾客无法收到或完成付款，并持续超过1周！本次故障为RBS造成损失高达1.25亿英镑！

第2名：GoDaddy

时间：9月10日，星期一

原因：DNS失败

在美国太平洋标准时间上午11点，GoDaddy声明：他们在经历间歇性故障，此后将其归因于DNS失败。臭名昭著的黑客组织Anonymous最初声明对此负责，并说这是他们发起的DDoS攻击；此后又撤回该声明。GoDaddy托管超过500万个网站，因此数千、甚至可能数百万网站都经历了这次问题。在晚上8点，大部分用户的服务得以恢复，但是GoDaddy这次故障的巨大量级和影响范围，让此次事故成为当年最大、最广为传播的故障之一。

第1名：Amazon Web服务（AWS）

时间：6月29日，星期五；10月22日，星期一；12月24日，星期一

原因：自然灾害；内存泄露；弹性负载均衡ELB失败

三次重大事故，让AWS经历了艰难的一年。第一次由于大型暴风雨，导致Instagram、Pinterest和Netflix受影响，直到第二天才恢复。10月22日，内存泄露和失败的监控系统，导致Reddit、Foursquare、Minecraft、Airbnb、Heroku、Github、imgur、Pocket、HipChat、Coursear和其他众多热门服务宕机。此次故障持续6个小时。最后一次，在圣诞前夜，Netflix宕机，直到圣诞早晨才恢复，因为AWS的弹性负载均衡ELB失败。

InfoQ中文站的读者们，在过去的2012年，你们认为国内有哪些网站的故障可以进入前十五名吗？欢迎在评论中留言。

相关厂商内容

个性能测试专家，7dtest.com创始人高楼（Zee）主持出品2013北京QCon“优秀测试实践分析”专场

InfoQ《深入浅出Node.js》专栏作者，CNode社区朴灵确认主持并参与分享QCon Node.js专题

您可能也会喜欢