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 年，你们认为国内有哪些网站的故障可以进入前十五名吗？欢迎在评论中留言。