数据中心火灾频发的深度反思—有感于对OVH火灾事后报道的思考
数据中心对火灾的管理,也应随着国家战略的落地、数据中心在国民经济中发挥越来越重要的关键作用,而进行更加全面的有效管理,将目前以风险管控和应急预案为主的防火防灾管理,改变为着眼于为各行业,特别是对数据中心高度依赖的行业,提供连续稳定的支撑服务为目标的火灾场景下的服务连续性管理，数据中心应制定详尽的火灾场景下的服务连续性计划。
1、火灾情况
总部位于法国鲁贝的法国独角兽公司OVHCloud(前身为OVH),在全球拥有27个数据中心,OVH是欧洲最大的托管服务提供商,也是世界第三大托管服务提供商,其位于法国斯特拉斯堡的数据中心园区,共包括SBG1、SBG2、SBG3和SBG4四栋数据中心建筑。2021年当地时间3月10日凌晨,一场大火烧毁了法国斯特拉斯堡OVHCloud的钢结构SBG2数据中心,导致其托管的许多网站中某些数据永久丢失。
根据该公司网站上的事件报告称,大火在当地时间凌晨1点在SBG2内的一间房内发生。到凌晨4点左右,大火完全摧毁了OVH的SBG2数据中心,并波及摧毁了SBG1八个服务器机房中的四个房间。OVH创始人和董事长奥克塔夫·克拉巴(OctaveKlaba)在推特更新中表示,SBG3中的所有服务器均完好无损,SBG4不受大火影响。但这些数据中心均由于这次事件停止服务,处于离线状态。
据了解,OVH的上一次重大停机危机也发生在斯特拉斯堡园区。2017年曾导致整个园区停电约40min。Klaba表示,该事件与停电无关,是由于网络设备中的一个无关软件漏洞,导致其位于鲁拜克斯(RoubaiX)的园区失去了与其网络上六个关键点的所有连接。
至于本次火灾原因,目前还没有正式的官方公告,但多种事实指向了UPS设备导致的一系列故障。在火灾发生的前一天,供应商对UPS7进行了维护,Klaba称供应商在UPS7内部更换了某些部件,并在下午重新启动了它。
虽然直流电汇聚成高压时,的确会有失火的风险,Klaba并没有说UPS就是此次失火事件的起因。他说:“我们今天并没有得到所有的答案。”OVHcloud的工作人员在周二晚上11点42分响应火灾警报,但数据中心受影响的部分已经烟雾弥漫:“两分钟后,他们决定离开,因为太危险了。”
2、相关组织和媒体的灾后报道与反思
事发后,国内很多组织开始结合这次火灾的事实,并且不局限于本次火灾扩展开来,分析火灾风险、成因以及对策,希望能够为数据中心行业减少火灾发生,做出一点贡献。
仔细研读后,我发现这些分析文章的观点都集中在起火原因分析,并且大多只分析技术上的起火原因,比如短路、过载、接触不良、漏电、线路老化或散热等,所给出的对策也多集中在针对这些起火原因,减少起火概率和早发现等方面,例如使用极早期烟雾探测技术、增加火灾高风险设施的监控、加强巡检、定期更换老化的元器件、完工验收与检测等等。
然而,仅仅如此分析显然不够。从本次火灾的现有记录来看,在凌晨1点确认SBG2的一间房内发生大火的1个多小时之前,就已触发火警,不可谓发现不及时,然而这么长时间,为什么没有有效处置?直到凌晨4点在外部消防力量介入下才控制火势,防火分区为什么没有发挥足够的作用?为什么数据中心自身的灭火系统没有发挥有效作用?为什么没有受到火灾影响的部分也无法提供服务?说好的多路由呢?这次火灾从故障发烟到起火,从小灾到大灾再到影响众多下游企业和政府部门业务的系统性大灾难,这个演变过程，岂是上面那些原因可以覆盖的?
3、有必要全面地反思火灾成因
火灾一词是由两个字构成的,因火成灾才能被称作火灾。所以我们分析火灾原因的时候,不仅要分析起火原因,还要分析致灾原因。大家都知道,火灾重在预防,但是防什么?不仅仅要防火,还要防灾!
关于起火原因以及对策,如前所述,其他组织和各种媒体多有反思,不再赘述。
虽然这次火灾的原因尚无正式结论,该数据中心的关键数据也未披露,所以致灾原因也无法准确判断,但是这也不妨碍我们就常见的致灾原因进行举例说明。
首先是防火防灾意识淡漠,这是数据中心火灾频发的最根本原因。例如某四大行总行数据中心的总经理就曾经指责手下分管副总经理部署火灾防范工作是做无用功,他的观点非常有代表性,这位总经理说我们数据中心用的都是难燃阻燃的材料,怎么可能着火?持这种观点的人不在少数。甚至在出了这次OVH火灾后,又有媒体说,把数据中心放到海底去,就不会发生火灾了。如果真的是这样,为什么各国海军常有潜艇火灾的报道?以为海底数据仓不存在氧气就不会有火灾,但是你知道不仅只有氧气才可以助燃吗?在极高能量密度的封闭空间,有谁能保证不会起火、甚至爆炸?一旦有了这种意识,自然就不会在防火防灾上下功夫。
其次,数据中心设计上存在缺陷。数据中心的设计应确保数据中心在具备足够高的可用性水平的基础上,还要有足够的韧性,确保数据中心在局部受损的情况下还能够具备可接受的有限服务能力。数据中心的设计师缺乏防火防灾意识,就会体现到数据中心设计上。例如他们以为GB50174数据中心设计规范中对A级数据中心不存在单点故障的原则要求与火灾场景无关,防火的问题仅需要遵循防火规范的要求而不需要为数据中心进行专门的考虑。例如我在即将进入土建施工阶段的一个业主要求建成全球一流数据中心的大型A级数据中心的设计图纸上看到,双路供电的两路本该完全隔离的配电系统、UPS系统被设计进了同一个防火分区,于是只要其中一台设备起火,就会导致整个数据中心完全断电,成为单点故障。
再次,建造瑕疵。例如我已经在不止一个数据中心看到,现场与图纸防火分区不对应、消防点位不对应、防火分区与灭火钢瓶不对应,甚至发现有的气灭分区根本不存在气体管路。
这些给后期运维团队有效处置火险带来了极大的不确定因素,并且通常不易发现不易验证,核对费时费力。前面那位总经理又有经典言论:实际与图纸不符是工程部门的责任，我们数据中心只需按图操作，没必要去核实。
最后,到了运维和使用阶段,往往也因为意识淡漠,不重视消防工作,导致防不了火,防不了灾,小火成灾。比如前面提到的不去做核实工作,不能识别和控制风险;对动火作业的管理缺失,留下起火成灾的隐患;放任包装纸箱等易燃品进入关键区域并处于无人看管状态,留下了火势扩大的隐患;为了维护作业方便,不及时关闭防火门,布线作业破坏防火封堵后不及时修复等导致防火分区失效;灭火器配备不足、灭火器送检期间未补充替代灭火器,不会使用二氧化碳灭火器等,导致初起火险无法扑灭;过渡依赖联动灭火,不会手动操作;组织演练时只演不练,做表面文章,人员不熟悉预案,未验证预案在夜间及节假日只有值班人员时的有效性,系统运行方式调整却不及时更新预案等,导致预案在需要的时候不能使用……
更近一步,我们还应当引导客户合理使用数据中心,引导客户采取措施,减少因数据中心服务中断给客户带来更大的损失。例如对于业务连续性要求高,难以接受业务中断的客户,我们应当引导客户采用灾备、多活等高可用方案,将其系统分布部署到有一定距离的不同地点的两个或者更多的数据中心中;对于业务连续性要求不高,尚可接受一定程度的业务中断,但业务数据价值高的客户,应引导客户进行数据备份并异地保存等。再例如数据中心场地资源分配使用时,可引导客户按照业务系统重要性和业务连续性要求的不同合理分区部署,确保当数据中心部分受损,服务能力不足时，有条件优先保障业务连续性要求高的重要业务系统的正常运行。而现实中，数据中心为了获客，往往宣传一个看似合理的虚高的可用性，使得客户对单体数据中心抱有不切实际的奢望，使数据中心火灾变成了一个牵扯众多的系统性灾难，对给客户造成的损失和声誉影响甩锅给客户：谁让你不做好灾备呢，数据丢了你赖谁!
凡此种种，都可能导致小火成灾，小灾变大难。这还仅仅枚举了一部分，远非火灾原因的全部。
4、新基建背景下,数据中心火灾管理的新要求
当前随着中国制造2025、网络强国战略、国家大数据战略、数字化转型、两化融合、互联网+、一带一路、云计算、大数据、CPS(信息物理网络)等新的一批国家战略制定和新技术如火如荼的发展,数据中心成为支撑这些国家战略落地的关键基础设施,特别是2020年3月4日中共中央政治局常务委员会召开会议,会议强调“要加大公共卫生服务,应急物资保障领域投入,加快5G网络、数据中心等新型基础设施建设进度。要注重调动民间投资积极性。”不仅将使数据中心建设进入了一个高潮期,同时,各行各业也将对数据中心越来越依赖,在银行业后,将诞生更多对数据中心高度依赖的行业。包括火灾在内的数据中心服务的中断不再是数据中心自己的事,将会成为一个系统性的社会风险,必须引起数据中心从业人员的高度的重视(参见图2)。
数据中心对火灾的管理,也应随着国家战略的落地、数据中心在国民经济中发挥越来越重要的关键作用,而进行更加全面的有效管理,将目前以风险管控和应急预案为主的防火防灾管理,改变为着眼于为各行业,特别是对数据中心高度依赖的行业,提供连续稳定的支撑服务为目标的火灾场景下的服务连续性管理(参见图3),数据中心应制定详尽的火灾场景下的服务连续性计划。做好以Reduce(减小)为目标,追求零火险、零灾难和零中断的风险管理与日常运营计划;做好满足快速灭火、减少伤亡、减少损失、业务连续、信息安全、环境影响等多方面目标要求的应急响应(Respond)和业务恢复计划,确保数据中心设施资源能够快速的恢复(Recover)到最低可接受的可用性水平,重续(Resume)数据中心服务;还要事先做好灾后重建(Restore)计划,确保数据中心有可用资源用于重建,尽快将数据中心服务水平返回(Return)到灾前水平。
