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

阅读数:1561 2013 年 2 月 17 日

话题:FacebookAWSDevOps

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