随着企业容灾备份的建设,定期进行容灾系统的切换演练,已成为验证系统高可用和练兵的重要窗口,然而容灾演练的现状却不尽人意。要么存在走过场形式化的演练,要么过度消耗资源。前一种,无法面对真实的灾难环境,后一种,给企业造成人力与物力上的浪费。通过本次关于容灾切换演练的活动探讨,让我们运维人对如何使容灾真正做到有备无患、切换演练做到行之有效,有了新的思路。
在活动中的精彩问题和观点交流时,我们把容灾切换演练的过程与项目管理理论紧密相连,下面就从项目的整体、质量、成本、时间、人力、风险等几个管理领域,对此次活动观点进行整理。
典型问题:
观点总结:
演练的整体规划是要从顶层设计一步步落实到底层实施,越是系统架构不够完善的企业,越要形成容灾的机制。演练,未必一定要选择停机的方式进行,如果之前没有演练过,可以设计好演练的计划和方案,先进行桌面和模拟演练,待系统建设完善和可用性提升后,在进行实操演练。演练,也不是最终目的,目的是进一步完善企业的应急机制。
在选择我们的容灾方案时候,要根据目前我们系统架构的可用性进行分析。按照国际标准SHARE78,从本地磁盘的备份,到将备份的磁带存储在异地,再到建立应用系统实时的切换的异地备份系统。并结合sla要求、建设预算情况、企业信息发展等进行同步规划。
容灾演练的整体标准如下:
企业在加强容灾处理能力、增强应急处置能力时。的确应该形成一整套容灾备份的标准和措施。
标准或者措施的落地,可以通过形成一整套容灾管理体系的文档,其标准应该包括有:
在制定演练整体计划时应该遵循如下原则:
在整体管理方面对如下几个关键点进行掌控:
典型问题:
观点总结:
因人力、成本等各种客观因素,容灾中心的日常运维标准往往不能达到生产中心的水平,下面内容讨论该从哪些方面保障容灾中心日常的运维工作的质量:
以数据库复制架构为例:
其他对容灾演练质量控制的细节:
典型问题:
观点总结:
容灾团队需要有一个包括决策组、执行组、行政组的完整组织机构。需要有团队组织和完成日常管理、预警、演练、测试、培训等工作。
但很多企业建成容灾中心后,维护的工作量增加很多。但却忽视了要增加相应的维护人力资源,致使系统切换的执行人员保障不到位;再者,当发生灾难时,由于决策成员对于容灾中心的关注度不够,无法做出决策;行政组更是形同虚设,诸如人员调配、信息发布和公共关系等工作,都只能由技术部门完善。
企业当面对灾难时,很难严格按照预警流程执行,往往各个部门乱作一团,缺乏响应的预警流程机制,使容灾系统无法起到应有的作用。
结合演练工作将预警流程可以分为以下几个主要步骤:风险上报--风险评估--风险决策--风险告知--发起系统切换。
1、风险上报主要包括风险信息获知、收集、上报。风险获知后,应验证风险的真实性,完整性。
2、风险评估需要容灾团队根据上报资料做出全面评估,必要时形成评估报告,应包括造成灾难的几率、影响程度、发展趋势等。
3、风险决策需要领导组根据风险评估报告决定后续的处理,包括是否提前启动切换,进入风险警备状态。
4、风险告知需要行政管理组将有关风险的信息及时对内对外发布,保持消息沟通顺畅。
5、系统切换过程是在领导组在做出切换系统的决策后,按照应急预案和相关操作手册直接进入灾难恢复启动步骤。
企业没有建立起完善的容灾演练机制,容灾演练利于形式,没有形成针对各灾难场景行之有效的演练模式。
容灾演练不仅要检验灾难恢复流程的有效性,而且也要验证容灾系统是否能够实现正常的切换和回切。容灾演练的主要步骤应至少包括:制定演练计划、审批、演练启动、消息发布、演练切换、业务验证、演练回切、总结等。
在容灾演练切换过程中,应详细记录各个重要环节的时间点,并分析切换演练是否能够达到容灾系统和生产系统的各项指标。在演练后应及时总结经验,对发现的问题应及时解决,修改或优化演练的应急流程,完善演练应急预案。
如果对容灾系统的数据、功能、性能等方面没有充分的测试验证,就难以保证容灾系统实现数据保护和业务接管的功能。
进行测试时,尽可能采用测试脚本,避免人为误操作。测试环境尽可能与生产系统隔离。在不发生系统变更时,最好每月测试一次,否则须即时测试。
通过容灾培训,可确保相关人员及时准确地了解容灾系统结构,熟悉测试、演练、灾难恢复流程,明确自身职责,使沟通、协作顺畅,提高工作技能和灾难应对能力。
培训计划由执行组与人力资源部门共同制订和执行。培训内容主要包括:容灾基础培训、容灾流程培训、容灾技术培训等。
以上所述的五个方面的隐患,任何一个环节的缺失都可能致使容灾中心形同虚设。养兵千日,用兵一时。所以任何一个环节都不能忽视。
其实对于容灾本身来讲,这是不仅仅是一个技术问题,更是一个考验组织、管理、流程的重要场合:
很多企业在运行稳定后逐渐缩减运维部门人员,缩减运维资金投入,一种飞鸟尽,良弓藏的感觉,在这种情况下,在勉强开始把容灾演练推给IT运维部门,主观的认为这是IT运维部门的事,缺少整体团队配合。缺少领导的执行力,最终导致多种问题出现在容灾演练中。
典型问题:
建设初期,无论从用户观念还是项目团队来说都是先要把数据中心稳定运行起来。只有吃过亏的运维人员才会这么重视数据容灾和灾备,从资金投入上初期也肯定会把重点都放在平稳运行上,但在初期有两个事情是要重视的:
对于IDC前期成本的投入:
企业对于容灾中心的态度就并不是过于重视,把容灾中心完全的推给运维,而并没有把有效的资金,人力,执行力持续的投入到容灾中心中。导致容灾中心虽然建立。建立的初期也一切运行正常。但慢慢的开始投入不足。人员不足。容灾中心开始无法与数据中心保持高度的一致和同步。没有足够的人员进行运维,巡检。在突发事件的时候,没有有效的执行力调度所有部门配合,而更多的是应用部门的抱怨和只能部门的不断催促,导致容灾中心运行多年到真正发挥时间无法正常运行。
容灾也好,数据备份也好,我觉得都和买保险一样。很多企业觉得这个保险的费用太高了。所以更多的时候选择不买,靠运气,靠运维。真正让企业的信息管理部门重视数据的重要性,才会让他们下定决心去支持容灾中心的建立和制度的完善。
典型问题:
观点总结
总体来说每个系统1-2次为宜,建议在年初统筹制定演练工作计划,根据维护窗口、重要业务变更日等时间节点,确定好演练次数。
同时,整理好要进行演练的重要系统,根据各系统的高可用建设模式,确定演练的方式,可以先进行桌面和模拟演练,在实战演练前,务必把每一个时间点的操作烂熟于心。
特别是要进行演练的系统较多时,更要做好统筹安排。比如,网络和系统的演练尽量不要安排在一起,如果因停机窗口等原因实在需要一起演练,一定要演练一套,验证一套,避免出现问题后,排查困难。
演练的时间段应尽量选择业务最低谷进行,在做决策时,建议考虑以下几点:
演练时间管理的细节如下:
要有绝对的领导者对应急预案进行指挥,协调。做到遇到突发事件忙而不乱,各司其职,有序进行。不受外界因素摆布而打乱整个计划。
典型问题:
每个单位的信息化部门结构都不太相同,有的信息化部门属于管理部门。有的信息化部门属于服务部门,对于需要协调公司多数业务部门来进行的容灾应急切换演练。各个单位都是有那些部门来牵头组织实施呢。在实施过程中,信息运维部门又担当一个什么角色呢?
麻雀虽小,五脏俱全。容灾演练的组织架构应该不断完善健全。虽然每个单位的组织架构、规模各不相同,但在容灾实施过程中,应至少下设如下组织机构,才能在演练切换工作在组织架构和职责分工上得以明确。
总得来说,组织部门可以是专门的风险合规部门,由他们牵头;但实施和上报是科技部门的责任;业务部门负责验证;后勤部门负责后勤;领导把控大局。
容灾切换演练中人力管理存在的痛点:
信息化运维部门,属于服务部门。缺少管理权限,上层有信息化管理部门。但对业务完全不同。一个空头部门,基本不起作用。在网上的公司管理层对信息化重视程度不够。所以我们的业务变更,切换,都是由我们提出报告,实施,但由于缺少管理权,所以以前就有过业务迁移过程中各个应用部门还在不断催促,询问什么时候恢复业务,其实这个在之前就已经下达过通知,但真正执行的时候还是会受到各个部门的影响,有时候甚至为了迁就重要部门或者领导而不得不临时变更计划。
各个行业不一样,即使同一个行业也不尽相同,有的是科技部牵头,有的是风险管理部,有的是总行组织的,所以切换要看级别,有的就是一个基于科技内部的,有的是演给监管部门看到,有的是演给自己看的。
最后,结合本次活动中会员们提出的精彩观点,对演练流程做一个全面的梳理:
容灾切换演练主要由以下4个阶段构成:
前期准备主要有如下具体工作:
1、演练方案的提交与发布:首先演练项目组要根据本次容灾演练系统 的自身特性,结合硬件资源和容灾中心现状,制定容灾演练方式和技术实现手段,通过与容灾演练应用系统的应用开发商进行访谈沟通,确认容灾演练应用系统对应的容灾场景和技术实现手段,做出详细的演练方案。包括存储系统的切换,应用系统的切换,网络系统及防火墙的切换。
2、演练项目组组织召开方案评审会:请容灾演练领导和专家、容灾中心领导和专家就容灾演练方案进行综合评审,最终确定容灾演练方案。
3、业务验证案例准备:演练项目组要督促本次进行演练的业务部门进行业务验证案例的准备,并和业务专家一起综合评审,最终确定业务验证案例方案。
4、演练项目组要组织相关人员进行人员联系表、分时计划、人员签到表、演练记录表等表的编写和更新,上报本次参演部门及参演人员给演练领导组并得到批准。
这个阶段主要进行当日正式演练开始前的准备工作。当时在较早时间要发“演练通知提醒”,提醒当时参加演练的相关人员进行演练前的准备及准时到岗。演练项目组通知本次演练的系统小组进行应用系统的检查,网络小组进行网络的检查,保证演练正式幵始能进行切换。并将检查结果上报演练指挥组。如果出现检查不通过情况,由演练指挥组请求演练领导组决定是否进行这次演练。
1、系统切换操作
这一阶段为正式演练的开始。当进入正式演练的幵始时间,演练指挥组将发出“演练开始”命令。整个演练将按照“演练计划方案”进行。进行系统的 切换和网络的切换。
2、测试验证
首先由系统组进行各系统的测试验证,业务部门依据容灾演练方案中由应用开发商提供的容灾演练应用系统的业务测试场景和详细测试步骤进行容灾演练应用验证,认真仔细核对业务测试场景得出的结果与测试脚本在生产系统中测试查询结果是否一致,如果结果一致,容灾演练业务场景成功结束,如果不一致需要找出问题的原因,重新进行容灾演练。此阶段的结果决定此 次演练的成功与失败。
3、系统回切恢复
此阶段进行演练恢复阶段。进入此阶段,不管之前演练的成功与失败,为保证不影响第二业务的正常运转。都必须进行业务系统的恢复。系统组和网络组进行系统恢复。
4、回切后业务验证
系统组和网络组进行系统恢复后,业务部门还要进行业务验证。保证生产系统的正常运转。
容灾演练结束后,召开容灾演练总结会,容灾项目组和容灾演练参与人员要就整个演练过程中出现的问题进行总结,针对每个问题都要找到是什么原因引起来的,应该如何解决和避免同样的问题再次出现,汇总问题列表并 提出改进建议和方法。至此整个容灾演练圆满结束。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论1 条评论
2017-04-07 11:54