/ 中存储网

银行等大型企业集团灾备恢复演练的三点注意事项

2015-02-08 12:08:35 来源:中存储

灾备恢复演练的三点注意事项

第一,领导绝对要从第一次就开始重视

在国企,银行领导要是不重视,你很多东西别想玩起来。这种重视是要在一开始建设数据中心的时候就要提醒领导重视起来,而不是在灾备恢复演练的时候重视,将很多问题和需求都在第一次的时候和领导讲清楚,讲明白,强调灾备的重要性,以及一些惨痛的教训,比你以后再提再改IT 结构要省事的多,这是我的亲身体会。用华为的价值观来说就是第一次把事情做对。很多银行在一开始建设数据中心的生产中心的时候,同城灾备和异地灾备中心就同步建设,并物理同构,系统同构,使用不同的运营商的网络以及不同的电力支援系统。

成功的灾备恢复对成本要求的非常之大,以前也有人也提到过,灾备中心98%的时间都是闲置的,但是2%的时间出现问题,基本就会造成毁灭性的打击。现在银行领导已经不会不重视了,因为银监会,地方的银监局都会督促的。但是我们IT 的兄弟们一定要在第一次就将问题讲足,讲透,让领导明白我们的roadmap 规划。

当然,区域银行在财力上有所不及,就只能考虑能力范围内的灾备恢复,比如重点数据,重点系统等。同构建设,异地建设就要量力而行。

第二,制定完善的规章制度和详尽具体的指导手册

什么是规章制度,就是要所有人都知道你办事有据可查可依,而不是随意办事,就是要所有人都知道各自的角色和任务。规章制度绝对是非常有用的(我之前很轻视的,后来工作让我知道是非常重要)。中国人民银行和银监会对银行的灾备恢复有明确的政策文件,也有国家标准,但是不同企业也要根据各自的实际情况,具体需求,制定各自的规章制度,这就是企业标准(比行标具有更强的约束)。

规章制度制定总体的灾备恢复要求,以及预案的启动,以及负责人,以及流程。比如我们要明确成员:灾备恢复领导小组(行长级别的),管理小组(信息科技,保卫,业务等方面的中层),执行小组(以IT 为主,其他为辅)。我们还要明确每小组的职责,和每个人的任务。成员的名单要根据组织的变动不断刷新,比如北京、上海的数据中心的负责人,比如中间件、网络、业务的负责人,比如对外联络EMC、GDS、IBM 等公司的联络人,和运营商,电力公司的联系人等,都要及时刷新保持最新。经常遇到在演练的时候,找到一个,不好意思,我调走了,或者离职了,这是不可接受的。还有相关权限的获取,流程审批的指导等。

规章制度还要定义明白,业务要恢复到什么程度,多长时间能恢复,RPO,RTO 大家都很明白了,无需多言,总之要有明确的量化指标,不可随意更改。

指导手册要有灾备恢复的具体技术指导。这个一般不能第一次就能确定最优的操作,要多次演练,或者参考别的银行或者公司的经验,厂商一般有一些原厂材料或者案例推荐(比如EMC、万国数据、飞康等),值得学习。指导手册一个重要的信息,就是现有系统的信息,以及灾备系统的信息。比如生产中心的拓扑,数据库的列表,主机的操作系统和软件配置等,IP 地址列表,硬件信息,软件所在位置槽位等。现有系统的信息一定要准确和分门别类,比如按网络、操作系统、数据库、应用、动力等分类,也可以按业务进行分类,比如资金清算、信贷、信用卡等业务进行业务分类。现有系统的信息要有专人维护,并定期巡检。信息的变更要走流程,并报信息科技主管备案。当然灾备中心或者目标库的信息也一定要维护和刷新,根据不同公司的灾备恢复模式而变。

指导手册的灾备恢复的技术指导就不用说了,要指明相关脚本位置,图形界面的操作方式,或者命令行的命令的指导等。相关的脚本位置,软件版本要严格指明,对于关键的动态参数,要有解释。现在一些厂家的灾备恢复做的已经足够简化了。但是如果是一个系统的完整搬迁,涉及不同的厂家和不同层面的系统。还要指明目标系统、网络的开启和重建,SAN 的挂载,应用系统的重配等需要更复杂的工作,还要有营业系统的测试用例等。

对于电信运营商,要选择话务的峰谷时间段,比如凌晨1 点到3 点。银行,业务一直是繁忙的,要选择一个相对事务较少的时刻。最开始可以先尝试的实验数据较少的生产库,之后,再整体切换上百个数据库的系统。演练或者真实恢复,一定要做好网页或者重点客户的通知,防止对重要业务的干扰,造成不必要的损失。我曾经了解过,某运营商,机场选择在业务繁忙时间恢复演练的时候失败,导致整片区域都瘫痪的事件。灾备管理部门要结合业务部门预测好业务高峰期,以及突发时间等,更新容灾恢复的时间窗。

还有对外宣传的指导详细流程,比如不成功会怎么样,成功会怎么样,都要有预案。

第三,容灾演练一定要各种场合都要考虑到

我们要有预案分类。比如网络断了怎么办,动力断了怎么办,数据库宕了怎么办,都要有完善的预案措施,平时技术团队没事的时候多研究,出事的时候就少花时间恢复。这个我国要向美国学习,7000 多种预案,不是盖得。当然我们也没必要搞那么复杂。

具体来说,数据损坏了怎么办,从备份硬盘恢复。主机系统损坏怎么办,HACMP,BCV?一般来说,同城容灾和异地容灾我们都应该演练一下。比如北京同城150 公里,比如上次北京暴雨发大水,导致电力传输系统损坏,导致生产中心断掉。我们可以利用关闭掉光纤通路,或者关闭掉生产中心和灾备中心的连接来模拟。我们可以利用SRDF 来恢复。观察清算系统的运转,恢复花了多少时间等。还有异地灾备恢复等。要考虑异地灾备中心负责人对北京数据中心的了解情况。谈到这里,各种规章制度和技术指导手册最好要分角色来撰写,要充分考虑到负责人员得技术和系统的领悟能力,不要假设他什么都知道。

从系统故障来看,我们应该测试和演练网络故障,主机故障,磁盘阵列故障,应用系统故障等(比如操作人员误操作),SAN 网络故障等。我们要结合规章制度,以及现有情况,决定恢复的时间点和系统等,优先要保证最高优先级的系统的恢复。容灾恢复演练从来都不是仅仅是数据库的事情,而是全套系统的事情,而且涉及到很多操作系统和硬件平台。

其实容灾演练的功夫在平时做好是最省事的。比如我们在架构设计的时候,为生产中心和同城容灾中心准备充足的带宽,比如FCoIP,带宽可以达到数百兆的速率,对于连接的交换机和存储系统主机最好采用双机冗余,互为备份。让生产中心和容灾中心之间的数据尽量做好同步,对于远距离的系统,采取存储层面的磁盘镜像比较合适,异步镜像就可以了。

而且注意采取可以无需主机处理的交换机和存储技术,让平时的数据同步可以较少的占用系统的资源。在容灾系统上,SAN 是当之无愧的选择。

本文作者 DB2 中国社区 sunyangnj