福岛灾难六年祭:容灾前线,警钟长鸣

3月11日是东日本地震海啸灾难6周年纪念日。在这次人类历史上罕见的浩劫中,福岛核电站事故造成的损失最为惨重。与前苏联的切尔诺贝利核电站事故相比,福岛的灾难最初是由地震和海啸的天灾引起,似乎不应该算作人为事故。

但是,静下心来仔细研究,发现这个事故发生得实在蹊跷:

  • 日本作为一个世界上自然灾难发生最频繁的国家,地震与其说是一种灾难不如说是一种常见的自然现象。就算是这次地震的震级很强,作为世界上最大的核电站,难道没有应对的预案?还是说应对预案不起作用?
  • 相比切尔诺贝利事故从开始到爆炸只有8分钟的时间,这次事故并不是一瞬间发生的。从3月11日的地震和海啸,到3月14日三号机组的爆炸,这么长的时间,难道大家真的已经尽了全力,就是没有办法阻止事故发生吗?
  • 整个事故的根本原因是冷却系统的电力中断造成的。这就更奇怪了。这类问题连所有数据中心的管理员都知道该怎么解决,怎么一个专业的电力机构,反倒被难住了呢?难道不能用多个电力源来解决吗?连数据中心都标配UPS了,难道核电站会没有类似机制来保障电力吗?没有柴油发电机吗?没有第二路电力供给吗?实在不行不能开辆发电车来吗?怎么会活生生地拖死了呢?
  • 日本作为唯一一个遭受过核打击的国家,对核的敏感远超其他国家。难道不能设计一个终极机制来防止核污染吗?
  • 切尔诺贝利发生灾难的时候,前苏联政府第一时间就组织了大规模的疏散撤离;而这次福岛似乎大家都很淡定,事故发生后好几天才开始慢慢陆续疏散。这是因为日本人的高素质,还是另有原因?

实际上,面对灾难,福岛核电站确实启动了预案。而这个预案却仍然没能挽救核电站。核电站也有多道屏障来防止发生电力中断。但是这些屏障竟然在这次灾难面前全部失效了。而且核电站也的确有一个终极的自毁机制可以防止灾难发生,却始终没有使用。疏散早该以最快速度进行,以高效率著称的日本人,居然由于人为的原因,把救命的时间耽误掉了。

所以,这分明不是一场天灾而是人祸。让我们来重新复盘一下六年前究竟发生了什么。

天灾?

2011年3月11日14点46分,日本本州岛东海岸区域发生里氏9级地震。虽然是罕有的大地震,选址严苛、地震监测准确的核电站本来也毫无压力,在第一时间启动了相应的预案,反应堆自动停堆。

停堆之后核电站仍然在产热,在自身无法发电的情况下必须由外部输入电源运转冷却系统。因此,停堆之后最重要的一件事就是如何确保关键的冷却系统能够继续供电。而这就是后来一切麻烦的根源。

像所有设计完善的容灾系统一样,核电站设计了多道屏障来确保在任何情况下冷却系统仍然可以继续供电。首先,第一道屏障是,电站各反应堆之间有很复杂完善的机制来确保可以在各种情况下相互供电。这就和数据中心容灾设计中的双活或者多活是一个道理。但是,预案要求地震时所有的反应堆全部停机,因此这个多活系统现在是个全死的状态,不能再相互供电,于是第一道防护屏障失去了作用。

核电站的第二道屏障是启动应急柴油机,给反应堆核心供电进行冷却。为了防止单点故障,每个机组都有多台柴油机发电。这个机制和很多现代大型数据中心的柴油应急发电的机制是完全一样的。但是,地震带来了另一个恶魔——海啸!

由于疏于对海啸的防御,当时整个核电站几乎都泡在了10米深的水中。而更糟糕的是,大概出于应对战争和恐怖袭击的考虑,核电站的应急柴油发电机都被放在了海平面以下的地下室。海啸一来,直接全部淹掉,无一幸免。同时,应急供电设计的第三道屏障——厂外供电也失效了——海啸将核电站外的输电线路全部毁坏,整个电网瘫痪了。

那么,核电站还剩下最后一道屏障,就是蓄电池组。这跟我们数据中心管理员最熟悉的UPS道理是一样的。核电站的蓄电池能够撑八小时。八小时内必须恢复电力,否则不堪设想。

至此,层层供电保障在“天有不测风云”的情况下,几乎全军覆没。但是,最终争取到了八个小时的宝贵时间。但是在这八个小时的时间里,“人祸”开始彰显威力。

人祸!

首先是问题的严重性在层层信息传递中丢失了。核电站第一时间向东电公司总部求援,而总部因为怕丢面子,再向政府发出求援过程中,严重隐瞒了事态的严重性。

第二是居然遇到了兼容问题。日本各个电力公司的供电系统互不兼容,比如东电使用60赫兹频率,而最先赶到支援的移动发电机组是50赫兹的,根本不能使用。

第三是疏于演练。从前的灾难演练都是在纸面上进行的,生死关头之际竟没人知道如何接入备用电源,最终还是支援人员自己研究图纸,白白耽误了最重要的几个小时的时间。

更令人愤怒的是,为了避免报废反应堆的几亿美元的损失,东电公司还是决定采用向空气中泄压,而不使用大量注入加硼海水的终极手段,以保住核反应堆,结果表明这根本就无法阻止灾难的发生。

2011年3月12日15时36分,福岛核电站一号机组首先爆炸。随后是二号机组的小爆炸。东电仍然试图让奇迹发生,迟迟不肯注入海水,以免损毁正在步其后尘的三号机组。然后就是又一次不可避免的爆炸。至此,东电公司才开始动员疏散。疏散工作进行得不慌不忙,是因为东电公司还在安慰说民众,事故不会对环境产生太大影响。直到日本政府派自卫队接管撤离疏导工作,才意识到了事故的严重性。

警钟!

至此可以得出结论福岛核电站事故,虽然是天灾引起,实际上都是人祸。那么,对于作为为企业信息系统容灾的我们来说,可以学到什么呢?

1.大家应该明白,灾难最可怕的是它的连锁反应,这会导致灾难不断扩大和升级。容灾过程中所有决策的核心,不是去“希望”灾难不会升级;而恰恰相反,是去按照最坏的场景假设,以决策如何避免灾难升级。本来以最快速度不惜代价接入电力就可以确保事故不必发生;当冷却失败后不惜损毁反应堆就可以防止核污染;当核污染无法避免时及时通报尽全力疏散就可以避免更大的损失。但是当事人做出一系列错误的决策,恰恰是因为“希望”灾难不会扩大和升级。

2.不要把所有希望都寄托在双活、多活的架构上。多活可以轻松面对一些灾难,但对另外一些灾难完全束手无策。数据中心的多活更是如此。

3.预案要设想各种灾难的具体情况。福岛灾难最开始的原因是他们执行的预案是针对地震的而非海啸。

4.预想灾难时要充分考虑本地的具体情况。福岛的海堤高度是依据1960年智利大地震的数据设计的。但日本地震调查研究促进会发现因为地质结构不同,福岛很有可能面临高得多的海啸,督促东电公司需加高防护海堤。但是东电以耗资巨大,并且理论中预测的海啸实际发生率太低为由,未采取任何行动。

5.多种手段防止灾难。福岛在灾难设计上用了多道屏障保障电力供应。如果没有这些屏障连最初的八个小时都不会有。

6.必须充分考虑兼容性问题。电力系统还会互不兼容的问题大概只有日本才会出现。但是这正好为我们IT容灾提了醒,因为IT系统上面临的兼容性问题远比电力系统更复杂。

7.充分演练。如果核电站之前有过哪怕一次全面演练,就不会出现备用电力无人能够接入的尴尬。

8.保证真实信息的准确流通。没有完整确切的信息就无法准确决策。试想如果日本政府了解到时间的紧迫性,调动所有资源和力量,在蓄电池耗尽前接入电力应该是可以做到的。

9.真的灾难发生时,我们要考虑的不是系统或者本公司的损失而是整个社会的损失。东电公司恰是由于一次次错误决策尽失人心。

最后,让我们一起努力,而不只是祈祷,不要让这样的灾难再次发生。

本文转自d1net(转载)

时间: 2024-10-26 10:59:16

福岛灾难六年祭:容灾前线,警钟长鸣的相关文章

双数据中心容灾模式的构建

内容提要:数据容灾问题是政府.企业等部门信息化建设过程中面临的一个具有重要理论和现实意义的研究课题.为实现容灾的建设需要在容灾相关技术.业务系统需求分析.容灾的总体方案设计及系统实现等进行设计与研究.本文根据新疆国税业务数据处理的现状以及将来容灾建设的目标,详细阐述了容灾的概念.技术要点,重点对新疆国税的业务数据处理进行分析,提出了具体的容灾解决方案,同时,给出了测试实例. 关键词:双数据中心 容灾 RPO RTO 随着税务系统信息化建设的不断深入,按照"一体化建设"原则,税务系统业务

MaxCompute( 原名ODPS)大数据容灾方案与实现(及项目落地实例)专有云

一,背景与概述     复杂系统的灾难恢复是个难题,具有海量数据及复杂业务场景的大数据容灾是个大难题.     MaxCompute是集团内重要数据平台,是自主研发的大数据解决方案,其规模和稳定性在业界都是领先的.在周边系统众多,业务场景复杂,海量数据存储和计算调度都是一个难题的情况下,需要保证大数据系统在灾难发生时能够尽快切换到备用系统服务,最小限度影响客户使用.     容灾系统及方案的建设有很多种方式,如同城双活,异地多活,冷备容灾等.MaxCompute大数据的容灾方案是在多年集团内部断

灾备行业关于数据保护与容灾备份的常识

谈灾备,就会细谈数据保护与容灾备份.然而,相关的概念经常有人混淆.我们搜集和参考公开资料进行初步梳理. 一.数据保护 在云与大数据时代,海量增长的数据容量,给数据的存储和保护带来新的挑战,从传统熟悉的IT架构到以云架构.虚拟化.超融合为代表的技术升级迭代,使得数据保护的技术手段也要加速. 1.数据保护的重要性 数据是企业重要的生产资料,关键数据的丢失可能会给企业致命一击.比如在911事件中,Bank NewYork在数月后因数据的丢失被迫破产清盘. 为什么后果如此严重?因为数据是计算机系统存在的

大话存储系列19——数据容灾

数据备份系统只能保证数据被安全地复制了一份,但是一旦生产系统发生故障,比如服务器磁盘损坏致使数据无法读写.主板损坏造成直接无法开机或者机房火灾等意外事件,我们必须将备份的数据尽快地恢复到生产系统中继续生产,这个动作就叫做容灾. 容灾可以分为四个级别: 数据级容灾:也就是只考虑将生产站点的数据如何同步 到远程站点即可. 与应用结合的数据级容灾:也就是可以保证对应应用程序数据一致性的数据同步,以及可感知应用层数据结构的.有选择的同步部分关键重要数据的数据容灾: 应用级容灾:也就是灾难发生时,不仅可以

如何实现容灾的最快恢复和最小损失?

 容灾是企业数据管理中的一个重要环节.近年来,国内频频发生的自然灾害事件给企业CIO提出了一个问题,灾难备份到底要做成什么程度才能满足企业的业务连续性要求? 一个适合客户使用的容灾备份系统要保证灾难发生时系统能够做到最快恢复和最小损失.RPO和RTO是衡量容灾系统的两个重要指标.RPO(Recovery Point Objective) 是指灾难发生后,容灾系统能把数据恢复到灾难发生前时间点的数据,它是衡量企业在灾难发生后会丢失多少生产数据的指标.RTO(Recovery Time Object

【知云】第六期:数据级异地容灾如何实现?阿里云帮你打通数据的“任督二脉”

摘要:国家要求网络借贷信息中介机构成立两年内,应当建立或使用与其业务规模相匹配的应用级灾备设施.那么如何规划容灾设施呢?本文中阿里云架构师半农将与大家分享阿里云异地容灾解决方案. 想要看视频版?请点击这里:[知云]异地容灾 目前阿里云拥有一整套异地容灾解决方案,如下图所示为阿里云异地容灾解决方案.容灾是沪金监管八十条文的强需求,条文中明确要求网络借贷信息中介机构成立两年内,应当建立或使用与其业务规模相匹配的应用级灾备系统. 在阿里云平台,通过多方面的产品容灾特性的支持,用户可以非常方便地进行容灾

浅谈IT容灾系统设计的级别和层次

一.容灾的级别 容灾从保障的程度上一般分为三个级别:数据级.系统级.业务级. 数据级别容灾的关注点在于数据,即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏.数据级容灾与备份不同,它要求数据的备份保存在异地,也可以叫异地备份.初级的数据容灾是备份的数据人工方式保存到异地:高级的数据容灾是建立一个异地的数据中心,两个数据中心之间进行异步或同步的数据同步,减少备份数据与实际数据的差异.数据级别容灾是容灾的基本底线,因为要等主系统的恢复,所以也的恢复时间最长的一种容灾方式. 系统级容灾是在数据级

阿里云高可用-容灾解决方案

这两天,一篇名为<IT之家因无法忍受阿里云而迁移至XX云>的文章引起了整个云计算行业的热议.(袋鼠云CTO江枫还专门写了一篇热评:点击阅读原文.) 从目前得到的信息看,其应该是在青岛区域购买了一台云服务器ECS,基于.net和自建SQL Server,并且应用和数据库跑在同一台云服务器上. IT之家,所有应用都部署在单台ECS上,不具备高可用的特性. 即便阿里云产品本身就有容灾.高可用的特征,但是因为一些用户对阿里云产品的不了解和自身应用架构不够合理,也根本无法使其发挥该优势. 其实,IT之家

各保险公司陆续完成基本容灾系统的IT基础架构建设

为提高IT系统的可靠性,IT系统的容灾建设已相当普遍.随着许多企业实施业务系统大集中,针对IT系统的高可靠性和容灾能力的需求日渐突出.对于保险公司来说,其数据的安全性以及业务的连续运营的要求更高.虽然各保险公司十分重视灾备系统的建设,陆续完成了基本容灾系统的IT基础架构建设,但如果没有相应的灾难恢复计划,也没有针对灾难发生后的应对.决策.详细的灾难恢复步骤,容灾系统将难以发挥真正功效.保险业越发展,数据"保险"越重要.相信在保监会的政策支持和引导下,越来越多的保险公司终将为核心业务数据