下面,为大家带来一篇常见的数据中心运维过程中停机事件起因,分享给各位运营数据中心的同业人员,对初入的行业工程师有提醒作用,如果是多年运维人员,也可以回顾和重温。
一切中断的根源:人为失误导致数据中心机服务停机或业务停止服务
事实上,无论我们在设计阶段考虑到多少内容,考虑多少业务可能发生场景,根据不同的未来业务场景对基础设施的安全等级和设计实施、到链路层至网络层的优化设计实施,都不可避免的会因为认为的失误使数据中心运维留下风险隐患,在这过程中,不论是设计阶段的、还是安装或者维护过程中犯的错误,用户往往都会对数据中心的管理团队提出指责。根据国际上最知名的数据中心行业安全检测服务公司Uptime Institute(Uptime Tier Ⅰ-Ⅳ等级认证机构)统计,全球范围内近70%的数据中心中断服务实质原因都可归咎于人为失误。
在数据中心机房的整个生命周期,特别是后期的实际运维过程中,面临的威胁来自于多个方面,按照我的理解,中断服务的风险如果按照逻辑上来归类,可以分为以下个方面:
1、基础设施层
2、通信链路层
3、网络传输层
4、业务支撑层
5、数据支撑层
6、应用支撑层
(本文不展开讨论,各层之间分属哪些风险内容从其他文章中展开表达)
从导致错误的结果来看,有人为因素导致的数据中心停机事件主要由一些原因:
-
激活了紧急断电开关(EPO只有在大型的数据中心或者运维团队非常专业的数据中心内才会设置,非强制设置的电气产品,因为一旦维护不当,杀伤力巨大)
-
温度调整错误(因为很多数据中心产品都是进口制冷设备,国内的运维团队曽不止一次的有记录将运行参数中的华氏温度调整至摄氏温度单位,1℉=17.7℃,即是说如果有人将空调运行环境温度调整至23℉,那么摄氏度将高达391℃)
-
在维护时因为误操作,将在运行的电源机柜电源插排输入电缆或设备本身的电源拉出设备供电端(这种操作引起的后果很大部分在单电源设施上,如数据中心接入的二层交换机,但是别小看,就算是这样也能干掉很多的应用系统,导致停止服务)
-
线路超载(线路超载在国内可能不是特别容易发生,超载发生的节点在供电的各个段都可能存在,不过根据我们的经验,国内的数据中心在电力的考虑富裕上还是相当多的,这部分的事故可能大部分存在于未经过专业设计的C级甚至更低级别的数据机房内)
-
操作中不遵守标准程序操作(SOC流程,在专业的数中心运维中非常重要,比如在对某个业务系统维护过程中,包括了网络、存储、数据库、应用服务器、负载均衡设备等作为应用系统支撑,维护人员如果没有经过评审的维护计划进行操作,比如在运行环境中将存储池错误的调出存储服务,导致应用连接的数据库无法正常写入数据或调用数据,报出大量错误或直接停止服务,是最常见的维护操作为遵从制定的SOC流程作业,就算给最先进的系统也会发生)
-
安全防范缺失(生产作业的数据中心机房对人员进出管理不严,未经培训的人员过多进入数据中心机房,可能一个随意的动作就会给机房运行带来灭顶之灾,曾经有公开的一起错误是因为参观人员未加限制,在一个冷通道内{未加前柜门}不小心全身被贴到一台提供网络核心服务的重要网络设备前维护面板上,折断了一个存储池连接的光纤跳线,当时无人知晓,存储大量异常信息报错后排查了将近4个小时才检查到了这个网络传输过程中的物理层故障)
那么,为了尽量的减少这些人为错误的机会,我们建议数据中心运维的管理者们可以做几件事情:
-
不管有多忙,请尽量安排出更多的时间进行适当的培训,培训过程要有计划和目的,培训的个人和团队要有成果检测;
-
如果数据中心机房已经承担了一定的业务规模,比如上了私有云计算,或者重要的业务生产系统,数据中心运维机构的管理者务必根据重要程度,影响面影响等级和范围,为业务系统建立团队认可的负责定义,比如谁负责排查基础设施层风险,谁负责排查网路层风险,谁负责排查业务支撑层风险,在发生故障或者需要加强防护的时候就有规矩可寻,而且不同的责任人可以根据自身责任需要,在日常运维中加强某个方面的安全保障方法记录。
-
组织可遵循的合理的停机维护测试演练,这个非常有必要,特别是我们服务的政府行业,几乎都没有这样的停机维护演练,大部分都是上线后一直运行,直到出事那一天也从来没演练过,金融银行业可能做得相对会好一点,也分机构的等级和人员素质。
-
建立操作标准化指南,这点对数据中心运维者提出了较高的要求,要具有非常完整的运维经验,或者能够找到很完整的数据中心运营维护经验团队,能够帮助到你根据业务的不同制定专业的SOC标准操作流程。
-
标签,标签,标签,重要的事情说三遍,请检查你的数据中心机房有没有完整的标识管理系统,标识是否清晰易懂,运维管理人员通过标签和文档是否能快速地的定位故障信息,如果没有,请多用点功夫在这块上做的完善一些。
-