今天要谈到的都称得上是“随机事件”，而数据中心运维人员将会因它们的出现而彻夜无眠。在慨叹之余，大家不妨扪心自问，您的灾难恢复方案是否足以应对这些罕见的意外状况?
洪水、火灾、太阳耀斑以及四驱汽车造成的车祸：这一切都是数据中心运维人员根本无法想象，但却能够切实带来风险的潜在灾难。接下来，我们将一同了解相关情况。
现任OpenStack基金会执行董事的Jonathan Bryce二十多岁时曾是达拉斯沃思堡的Mosso Cloud公司的创始人。令他毕生难忘的是2009年12月18日这家公司所遭受的突发事件。
这次事故源自某位身患糖尿病的司机。他当时在Rackspace数据中心——也就是Mosso业务托管所在位置——附近突然陷入昏迷，他的SUV就直接撞上了该数据中心的电力变压设备。在车祸出现之后，Mosso的业务仍然能够正常运转，但这仅仅是接下来一连串最终导致服务停机的小机率事件的前奏。
我们要如何为这样一种看似不可能发生的状况作好灾难恢复规划?“这仅仅是大家需要了解，且确实可能发生的故障根源的其中一种，”Bryce表示。
Robert von Woffradt身为爱荷华州州政府CIO也结合自身发表了看法，该州主要数据中心遭遇意外火灾后他在博客当中谈论了此事。相信2012年遭遇了由飓风桑迪引发的洪水的下曼哈顿办公楼群与各医院也会对此表示认同。
即使大家自认为已经针对地震、洪水与火灾作好了万全的准备，那么我们提醒一句——您有没有考虑到偶尔出现的太阳耀斑?就在2012年，一次强大的太阳耀斑现象差一点就破坏了地球上的众多电力传输系统。如果这次爆发的出现再早一周，地球将受到直接影响，科罗拉多州大学的Daniel Baker在2014年接受NASA科学新闻采访时指出。耀斑的影响力将冲破地球大气层，进而导致意外之外的严重输电线路电压震荡。
大家可能会认为这样的风险离自己非常遥远，但事实会给我们实实在在的教训。就在1859年，太阳耀斑的干扰在地球上引发了所谓“卡林顿事件”，电报局所部署的线路由于电压瞬间增高而全面失控，一些办公室甚至直接起火。
亲身经历过灾难事态的CIO与数据中心管理者们纷纷指出，大家所能拿出的***应对措施就是提前做好准备。“至少每年对系统进行一次全面崩溃测试。不要相信什么模拟结果，直接将其离线，”Wolffradt在爱荷华州政府遭遇火灾危机后所发表的一篇博客中建议道。
下面我们就一同来看实际发生过的各类数据中心灾难事故——其中一些非常可怕，另一些则有些匪夷所思——当然，也欢迎大家在评论栏中分享您自己的灾难应对故事。
#p#
爱荷华州火灾
2014年2月18日下午，当时爱荷华州政府正像平常一样组织生产生活——但其主数据中心突然爆发电气火灾。考虑到当地天气预报的提醒，IT运维团队当时正在积极准备应对当晚可能出现的暴雪天气，因此火灾的发生简直令人始料未及，爱荷华州政府CIO Robert von Wolffradt在2014年3月25日发布在GovTech.com网站上的一篇博文中回忆道。
火灾警报出现在当天下午3点钟，数据中心陷入电力中断状态，建筑物内浓烟四起，工作人员则开始快速撤离。警报触发了数据中心内的FM-200烟感灭火系统，好在喷淋的及时起效将火灾范围控制在了设施中的瞬态电压抑制箱内部(如上图所示)。作为数据中心内的电流控制装置，这套电压抑制单元由于过热而熔化。州政府的公共服务小组立即开始构建备用线路，而电力也在几个小时之后得以恢复。
随着电力传输再度起效，数据中心内的门扉、风扇以及换气装置开始重新工作，不过警方及消防人员仍然要求IT工作人员待在大楼之外。直到事发后的三个半小时，州政府方面才确定数据中心已经适合工作人员进入。
Wolffradt必须快速决定如何采取进一步处理措施，而与市民、供应商以及员工工资相关的开销损失很可能高达1.62亿美元。工作人员迅速对数据中心进行了残留清理，而IT团队则在当天晚9点恢复了存储区域网络、防火墙与网络核心。快速恢复现有功能意味着整套设施面临着没有瞬态电压抑制单元的保护。但Wolffradt仍然决心以再次上线为***要务，不过他手上还有备用数据中心作为***的底牌。
到当晚11点，其它额外系统也开始陆续上线，其中包括服务咨询台以及暴风雪即将到来前各桥梁及高速公路必不可少的交管监控摄像头。
一同得到恢复的还有财务系统与各虚拟化应用程序。其它系统在当天夜间依次恢复正常，到第二天晚上备用数据中心将接管州政府的各项处理任务。“当天晚上，我们两度利用国土安全体系中的语音通知系统向各部门负责人及核心工作团队通报***动向，”Wolffradt回忆道。他同时指出，当时关于数据中心发生火灾的种种谣言可谓甚嚣尘上，而他作为CIO则必须频繁与其它各责任方进行沟通。在事件发生后，他甚至需要亲自向州长及其他州政府官员汇报重要信息。
Wolffradt在他的博客当中分享了这样一条关键性教训：一定要将各大型企业系统彼此分离，例如将电子邮件系统安置在独立的设施当中。另外，在火灾当中，公共服务与人力资源部门“是***的朋友”，他们将帮助大家完成各项后续任务。恢复运作的***障碍是说服警方及消防人员允许IT团队重新进入数据中心，他在博文中写道。数据中心所在的建筑物中共有上千名政府工作人员，其中大部分都是在IT团队重返现场的很长一段时间后才再次回归工作岗位的。
三星火灾
不，这不是三星公司的什么新型智能手机代号——就是字面的意思，三星，着火了。
2014年4月20日，一场大火侵袭了三星公司位于韩国果川的办公大楼。大火从三星SDS数据中心所在的建筑物开始燃起。至顶网韩国分站的作者Jaehwan Cho在他的Twitter上发布了从韩国联合通讯社获取到的图片资料，可以看到浓烟与火光正从大楼的一侧喷涌而出，猛烈的热流挟带着燃烧残片一同掉落在楼体外部。
根据Data Center Knowledge网站的报道，三星公司的IT人员及该建筑物内的其他人员被快速疏散，过程中只有一位员工因被坠落的碎片划伤而挂彩。
这场火灾给众多三星设备用户造成了影响，相当一部分智能手机、平板设备以及智能电视用户无法正常进行数据检索。在为期数小时的整个过程中，设备用户始终无法正常访问相关内容，直到果川备用数据中心的恢复系统起效后一切才重归正常。三星官方在一篇博文当中就此作出了道歉。
#p#
关注管线检查工作
2009年7月3日西雅图费舍尔广场的电气室发生了火灾，这直接导致Authorize.net支付门户、微软必应旅游服务、Geocaching.com服务、Dotster域名注册服务以及Web托管供应商AdHost等数十个站点瞬间陷入瘫痪。直到第二天早晨，电力供应才得以恢复。
根据《普吉特海湾商业杂志》的报道，Geocaching与AdHost两个网站分别于次日上午10点重新上线，而其它各服务的恢复过程则更为漫长。此次火灾显然始于传输线缆管线(如上图所示)，而据该杂志的估算，此次费舍尔广场用于维修及更换设备的成本大约为1000万美元。
飓风桑迪引发发电机故障
与东海岸类似，2012年10月底肆虐一时的飓风桑迪在陆续袭击了弗吉尼亚州、特拉华州、马里兰州以及新泽西州后最终将矛头指向了曼哈顿。伴随着一波猛烈的海水潮涌之后，巨浪扑上纽约市头并导致下曼哈顿地区的多家站点陷入瘫痪。
位于下曼哈顿75街区的Peer 1托管设施因此成为灾难恢复工作人员的噩梦。虽然该栋建筑物的十八层摆放有用于持续提供电力且不至于受到洪水影响的多台备用发电机，但风暴来袭时直接灌满了该建筑物的地下室，并且摧毁了应急发电机的燃油泵送系统。一旦遭到海水浸泡，整套电路立刻失去了作用。(考虑到911事件，纽约地区要求各办公楼管理方控制楼内所储存的燃油量)。因此，发电机只能依靠非常有限的一点燃料强行启动，而工作人员根本没办法为其提供充足的补给。Peer 1建议客户以数小时为周期实施系统关闭计划，并排遣几名员工到现场帮忙以防止出现数据丢失状况。
为了避免系统停机，Peer 1的工程技术团队决定扛起水桶为楼上的发电机输送燃油供给。燃油被运抵街区后，再以人力方式被慢慢抬上十七层——那里正是发电机的油箱所在，负责为楼上的发电机提供动力来源。Peer 1公司的托管服务客户们——其中包括网站开发企业SquareSpace以及在线项目管理供应商Fog Creek软件公司——组织起由25位员工构成的队伍，帮助现场人员进行燃油输送。从10月30日晚到10月31日晚，他们一刻不停地承担起了原本应由泵机完成的工作。
到10月31号的午饭时间，他们已经顺利加满了油箱并终于能够休息一会儿。为了吃上午饭，他们需要徒步走过布鲁克林桥——因为当时曼哈顿街道已经被彻底堵死了。很明显，在Peer 1的灾难恢复规划中既没有人力送油方案，也不包含徒步就餐计划，但正是在这些奋战在现场的工作人员的努力之下、系统并没有因为飓风的肆虐而陷入停机。
#p#
一辆SUV引发的惨剧
Rackspace公司的主机托管业务及由其承载的Mosso Cloud运行在位于达拉斯的同一座数据中心内部，但2007年11月13日一场无妄之灾使其在数小时内陷入了瘫痪。
一位大型四驱车司机——同时也是一位糖尿病患者——由于病发而出现短暂昏迷。他没能正常转向邻近的街道，而是一路向前直冲，并从丁字路口处奔向路边外侧的护堤。护提这样的斜坡令疯狂突进的SUV越过一排停放的车辆而冲向空中，并在落地时撞上了一栋容纳着Rackspace基础设施供电装置的建筑物——一阵火光带闪电之后，电力供应中断了。
由于需要切换至备用供电线路，这栋建筑物的冷却系统出现了暂时性停顿。不过业务运作过程并没有被打断，因为这套计算设备能够在遭遇此类紧急情况下利用应急电池继续工作。该设施的工作人员立即通过重启规程帮助该建筑物的冷却机制重新运转，而紧急处理人员则努力将闯入的车辆清理出去并接入新的电力变压装置、关闭设施的全部供电体系并从辅助供电装置切换回主供电装置。
在其灾难恢复规划当中，电池电源与应急发电机再次立下大功。数据中心到这时仍没有发生运行中断现象，事故只不过让供电网络的运转功率有所下降。不过冷却系统中的大型水冷机组在分步重启过程中出现了问题。其在重启中再度陷入瘫痪，而且工作人员发现已经没办法在不进行深入排查之前让其重新恢复工作。
Rackspace公司总裁Lew Moorman在事故之后的一篇博文当中提到，“两套冷却机组无法重新启动，这使得数据中心出现了过热。”由计算设备产生的热量足以使现场气温急剧上升，而Rackspace公司的现场管理人员决定“分阶段关闭设备以***程度降低硬件受损”与客户数据丢失的可能性。
这次中断一直持续到当天晚间10点50分，也就是事故发生后的五个小时。软件即服务供应商37signals——Rackspace托管下的企业客户之一——向客户发布了评论意见：“这次接连出现的意外事件击垮了我们为数据中心建立的复杂备份系统。我们将努力工作，从而进一步对系统加以分散，并最终得以应对此类极为罕见的外来因素所导致的停机事故。”除了增加客户流失的风险之外，据报道称Rackspace公司还为此次事故向客户支付了350万美元赔偿金。
焊接工作惹麻烦
2015年1月9号，一座将被作为Amazon.com数据中心的大型建筑物发生火灾，起因则是一名焊工不慎点燃了现场的建筑材料。此次火灾触发了弗吉尼亚州阿什本当地的三级警报。浓烈的黑烟在几英里之外都清晰可见。Amazon公司发言人在接受当地ABC新闻媒体采访时指出，此次火灾造成了大约10万美元损失，但同时补充称“并没有对Amazon业务运营带来任何影响”——因为当时该数据中心尚未投入使用。
#p#
太阳风暴
也许洪水、火灾以及车祸已经足够令人头痛了，但真正可惜且避无可避的还是要数太阳风暴侵袭地球大气层这类大事件。太阳耀斑有时候会引发所谓的太阳风暴，在这种情况下太阳表面的日冕物质会由于剧烈活动而沿爆发前的轨迹被直接抛射出去。
这种案例确实非常罕见，但一旦真正发生，太阳表面溅出的物质会冲破太空直接向四面八方砸去。而当这些带电粒子接近地球大气层时，极高的前进速度会创造出强大的磁力空间。在此空间内，导电材料会自动产生电流——正如通电线缆一样。而管线及电话系统这类长度可观的导体甚至会迎来巨大的瞬态电压。
这种威胁确实是真实存在的，伦敦的Lloyds网站甚至专门发布过一篇《太阳风暴或将威胁北美电网》的风险评估报告。
根据这篇报告所言：“电网体系可靠性的一大威胁正源自地磁风暴——而这会由太阳风暴在大气层上方快速通过而引发。……由此带来的过载电压将使电网系统陷入崩溃，更糟糕的是，昂贵的超高压变压器亦有可能因此而发生大规模损坏。”
1989年，这样的风暴就直接袭击了加拿大，瞬态电压升高导致魁北克省的水电电网变压器出现损坏。据估计，这次事件造成的破坏相较于1859年美国的太阳风暴灾害还算比较轻微——当初被称为“卡林顿事件”的耀斑活动直接导致美国多位报务员遭受电击，另有几处电报局发生火灾。1989年的这场事故直接触发了东北电力协调委员会及中大西洋地区委员会所布设的断路器及过载保护设备，如果不是这样、美国的整体电网几乎全面遭到毁灭。新泽西州的一处核电站就在升压变压器发生损坏后被迫切断了与电网间的传输通道。
再把目光投向近期，2012年太阳风暴曾与地球公转轨道相交于一点——或者说几乎相交于一点。此次风暴在地球抵达前九天刚刚通过，从天体规模来看这样的微小间隙简直称得上险过剃头。
总结陈词
前面提到的各类场景确实让人始料未及，而且即使是身经百战的数据中心运维人员也没把握将其妥善解决。不过好消息是，相关企业机构快速公布了其恢复方案，且足以成为我们在规划未来灾难恢复机制时的宝贵借鉴。
大家有没有亲身经历了这类堪称挑战想象力的特殊事件?而处理过此类灾难恢复工作的您又有什么经验愿意与大家共享?另外，您心目中最恐怖的灾难噩梦是怎样的?请在评论栏中留下您的真知灼见。
原文标题：7 Data Center Disasters You'll Never See Coming
