展会信息港展会大全

北京亦庄某数据中心宕机后的危机7小时
来源:互联网   发布日期:2016-8-3   浏览:3709次  

导读:2016年4月22日11时28分,某数据中心服务商位于北京亦庄的数据中心供电中断,在该机房托管的多家金融机构和73家村镇银行的所有设备宕机,服务全部中断长达7小时以上! 数据中心出故障不算新鲜事,但这次事故的罪魁祸首却有点大跌眼镜:UPS过载…… ......

2016年4月22日11时28分,某数据中心服务商位于北京亦庄的数据中心供电中断,在该机房托管的多家金融机构和73家村镇银行的所有设备宕机,服务全部中断长达7小时以上!

数据中心出故障不算新鲜事,但这次事故的罪魁祸首却有点大跌眼镜:UPS过载……据悉,该数据中心服务商计划对数据中心的4台老旧UPS进行升级。首先更换其中的两台,同时由另外两台进行供电;然后,再更新另外两台,在此期间由柴油发电机供电。

但是,升级过程中,两台老旧的UPS负载过高,切到旁路,很快三台柴油发电机接连出现“失磁”报警,停止运行,导致机房全部设备断电,系统宕机!73家村镇银行的诸多关键业务全部中断,部分服务器损坏,银行业务系统最长的恢复时间长达7小时以上;部分金融机构的开发测试系统、灾备系统、生产业务系统不同时间中断……

failover

缺乏设备更新升级的标准流程

设备更新是所有数据中心都会进行的常用操作,关键设备的升级更新应该有一套标准的流程才能进行升级。在此次事故中, 4台UPS的负载已经达到了不能两台同时下线的程度,这是完全可以通过管理工具测算出来的。操作升级时,没有事先进行调研,就制定了两台一组进行更换的计划,这属于完全可以通过标准工作流程处理能够避免的事故。

缺少应急预案

供电故障是国内数据中心比较常见的灾难产生原因。而当UPS出现过载时,却没有迅速准确的应对措施,应该说是有缺陷的。如果有针对此场景的应急预案,从UPS开始报警到宕机的几十分钟里,迅速应对,完全有机会避免事故的发生。

选择错误的作业时间

更换UPS这样的高风险作业,其实完全可以放在业务量较低的夜间进行。而此次作业安排在白天,并且事前未向银行明确提示风险,银行准备不足,导致业务长时间不能恢复。

违规分包机房主要运维服务

事件责任公司将某村镇银行生产机房的基础设施管理等主要服务内容分包,不符合《银行业金融机构信息科技外包风险监管指引》第三十七条“不得将外包服务的主要业务分包”的风控原则。

2

如何规避灾备的“人祸”?

如何进行灾备、如何对机房和灾备设施进行管理,是企业非常关注的问题。很多企业投入巨资,建设灾备系统,就是为了避免出现灾难时发生重大损失。

但是我们发现,很多用户都认为灾备主要面对的是各种自然灾害,忽略了各种人为错误导致的灾难。而实际上,我们经历的绝大部分灾难,都是人为造成的。软硬件升级、调试、配置等造成的故障要远远多过火灾、地震发生的概率。因此,建设灾备系统时,应该充分考虑人为因素,制订预案和流程管理。

其次,灾备系统的管理至关重要。如何管理?很多用户以为灾备系统建设好了就可以高枕无忧了,几乎不会再去对它进行管理,很多软硬件都陆续升级,而灾备预案从来没有更新过,这样的灾备系统,很难在灾难真正降临的时候发挥作用。

服务商是否值得信赖?很多用户在选择托管服务的时候还认真考察过服务商的服务水平,但是一旦选定之后很少会再去关注他们的运营质量。尤其是很多关键业务托管上云之后,更是如此。这也不奇怪,业务在云之间进行迁移的风险和成本极高,所以一旦完成迁移上线,几乎很少会有用户再去监督服务商的服务质量。反正也迁不出来,即使发现他们有些不合规也只能捏着鼻子认了。这导致了服务商的服务质量得不到监督。长此以往,就很有可能出现服务质量下降的情况。服务商在发生灾难时的损失和客户在发生灾难时的损失往往不在同一个层次上,这也使得服务商没有足够的意愿去保证服务水平。

数据中心的运维具有各种潜在的失控因素,但如果能够尽量排除“人祸”,也许能够尽量降低灾难发生的风险。

赞助本站

人工智能实验室

相关热词:

AiLab云推荐
展开

热门栏目HotCates

Copyright © 2010-2024 AiLab Team. 人工智能实验室 版权所有    关于我们 | 联系我们 | 广告服务 | 公司动态 | 免责声明 | 隐私条款 | 工作机会 | 展会港