7月11日下午2点，著名旅游网站携程突然变得难以访问。此后，连续二十六小时，用户表示无法访问网站，首页显示系统正在升级。后来否认不仅仅是存储系统的问题，导致整体服务停止，系统宕机。因为这次车祸，艺龙损失了巨大的客户，产生了大量的维修费用。

这起车祸，引发了业界对于数据中心防灾的争议。明天业务时间以秒计，IT设备每一分一秒的浪费，都会给企业带来不可估量的损失。事实上，去年的崩盘并不是携程唯一的一次宕机事件，但这种崩盘并没有得到应有的重视。为什么要等到出现严重后果时，人们才能意识到防止停机的重要性？

我们来看看TIA-942《数据中心通信基础设施标准》中对数据中心级的定义。

表的倒数第二行是指每年的停机时间，即该级别的数据中心一年内只能允许停机的时间宽度，以小时为单位。可以看到，对于最高级别的Tier 4，一年只允许0.4小时的宕机时间，也就是24分钟，对于Tier1，不能超过28.8小时。

然而，大多数数据中心（包括许多知名公司的小型数据中心）都在一次停机时间内完成了一年的“目标”。

结合这一点，让我们回顾一下最近产生重大影响的崩溃：

亚马逊云计算中心于 4 月 21 日宕机。

亚马逊在弗吉尼亚州的云计算数据中心服务因误操作而宕机，导致大量依赖其云服务的公司利益受损，包括手机服务网站FourSquare、新闻网站Reddit等。此次崩盘不仅给亚马逊及其客户造成了惨痛的损失，也引发了对云计算服务的信任危机。

8 月 8 日，亚马逊云服务因雷击再次宕机，但这次只持续了一个小时。

Skype 于 5 月 26 日关闭

互联网电话服务软件Skype遭遇车祸，许多用户无法登录软件或拨打电话。无处发泄的用户只好在推特上表达不满，也有用户将其归咎于谷歌竞购Skype宕机事件，因为主要是Windows版本客户端的问题。同年6月7日，Skype再次崩溃。

Twitter 于 6 月 9 日关闭

Twitter 的 API 当天早上受到一个未知技术问题的严重影响，但停机仅一个多小时就解决了，所以没有造成太大影响。去年 Twitter 上出现过多次宕机崩溃，持续时间长达 6 小时，但去年情况有了很大改善，宕机时间减少了，一旦发生，可以立即解决。

7 月 14 日，elong 旅游网宕机了。

今年最大的崩溃是由EMC存储设备引起的，但归根结底，据说携程自己的存储结构不健全，导致维修时间如此之长。由于灾备存储的不完善，备份没有发挥应有的作用。否则，EMC 将发生故障，并且 26 小时内不会停机。

Microsoft App Engine 于 7 月 15 日关闭

Google App Engine Java 服务失败，导致停机 1 小时。这个问题对于类似日期的同一次崩溃来说不是很明显，但是失败的原因是基于云计算和应用程序转移到互联网上。出现了一些问题。云服务最近开始流行，但安全问题仍然是一把达摩克利斯剑。

Yahoo Mail 于 8 月 3 日关闭

用户访问雅虎邮箱长达 12 小时很困难。雅虎一开始并没有关注它。随着越来越多的用户报告这个问题，他们开始做出回应。原因不明。