7月11日下午2时，著名的旅行网站艺龙突然无法访问，此后连续二十六个小时，用户纷纷表示无法访问网站，首页均显示系统正在升级。后来证实是存储系统除了问题，导致整体服务停止，系统宕机。因为这一场事故，艺龙蒙受了巨大的客户流失，为此花费了大量维修成本。
这个事故在业界掀起一阵对数据中心灾难防护的争论，在业务时间按秒计算的今天，IT设备一分一秒的浪费，都会给企业带来不可估量的损失。其实今年的宕机事故并非只有艺龙一个，但是这些事故并没有得到应有的重视。为何非要等到出现严重后果，人们才能意识到预防宕机的重要性呢？
我们先复习一下TIA-942《数据中心的通信基础设施标准》中对于数据中心等级的划分。
该表格倒数第二行是指年宕机时间，即该等级的数据中心在一年内能够容许宕机的时间长度，单位为小时。可以看出，对于***等级Tier 4来说，一年仅容许0.4小时的宕机时间，也就是24分钟，对于Tier1来说，也不能超过28.8小时。
但是，大多数数据中心（包括很多知名企业的大型数据中心）都在一次宕机内就完成了一年的“目标”。
结合着这一点，我们来回首一下近期影响较大宕机事故：
4月21日，亚马逊云计算中心宕机
亚马逊在Virginia的云计算数据中心服务由于误操作宕机，导致大量依赖其云服务的企业利益受损，其中包括手机服务网站FourSquare、新闻网站Reddit等等。这次宕机事故，不但让亚马逊及其客户受到惨痛的损失，更带来了人们对云计算服务的信任危机。
8月8日，亚马逊云服务由于雷击再次宕机，不过这次仅持续1个小时。
5月26日， Skype宕机
网络电话服务软件Skype发生宕机事故，很多用户无法登陆软件或者拨打电话。无处发泄的用户只得在twitter上表达不满，更有用户将其怪罪于微软收购Skype的行为，因为主要是Windows版客户端出问题。在同年6月7日，Skype再度发生宕机事故。
6月9日，Twitter宕机
Twitter当天早晨因为不明技术问题，导致API受到影响，但是宕机仅持续了一个多小时就被解决，所以并没有造成太大影响。去年Twitter曾经发生过多起宕机事故，最久持续6小时，而今年情况大为好转，宕机时间较少，而且一旦发生，就能马上解决。
7月14日，艺龙旅行网宕机
今年***的一起宕机事故，事故缘于EMC存储设备，但就其根本，据说是艺龙本身的存储架构不完善，才导致了如此长的修复时间。由于存储灾备的不完善，备份没有起到应有的作用。否则EMC出现故障，也不至于宕机26个小时。
7月15日，谷歌App Engine宕机
谷歌应用引擎Java服务出故障，导致宕机1小时，这个问题日期相近的艺龙宕机事故来说不是特别引人注目，但是故障原因基于云计算，把应用程序转到网络上，出现了一些问题。最近云服务颇受欢迎，但是安全问题还是一把达摩克利斯剑。
8月3日，雅虎邮箱宕机
用户12小时无法访问雅虎邮箱，一开始并没有得到雅虎的重视，随着反映问题的用户越来越多，才开始作出回应。原因不明。
