数据中心火灾频发的深度反思

右，大火完全摧毁了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火灾后，又有媒体说，把数据中心放到海底去，,就不会发生火灾了。如果真的是这样，为什么各国海军常有潜艇火灾的报道?以为海底数据仓不存在氧气就不会有火灾，但是你知道不仅只有氧气才可以助燃吗?在极高能量密度的封闭空间，有谁能保证不会起火、甚至爆炸?一旦有了这种意识，自然就不会在防火防灾上下功夫。

其次,数据中心设计上存在缺陷。数据中心的设计应确保数

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!