招商银行股份有限公司信息技术部 张春林

　　由于银行业务对信息系统的高度依赖，业务部门和监管机构都对信息系统的可用性和连续性提出了很高要求。随着招商银行经营规模和品牌影响力的不断提高，如何继续提升信息系统的连续性，为业务的可持续发展保驾护航，成为招商银行信息技术部门面临的最迫切的问题之一。从信息技术部门的角度来看，当前IT 建设所面临的挑战包括以下两个方面：一是如何加强与业务部门的合作，共同推动业务连续性管理水平的提升;二是如何继续提升信息系统的连续性管理水平，为业务连续性打造更加坚实的基础。

　　为了应对挑战， 近年来， 招商银行不断加大灾备建设方面的投入，实施“双中心运行”战略。随着2012 年上海数据中心的正式投产， 招商银行初步形成了由深圳数据中心、上海数据中心组成的“ 两地双中心” 的容灾体系，为实现“ 百年招银” 奠定了坚实的信息科技基础。

　　一、灾备建设历程

　　在招商银行的灾备建设历程中有两个重要的里程碑，分别是2002年南京灾备中心成立和2012 年上海数据中心投产，两者之间的时间跨度正好是十年。

　　2002 年，招商银行南京灾备中心成立，正式拉开了招商银行灾备建设的序幕。初期，招商银行完成了主机系统的灾备建设，具备了核心业务系统的异地数据备份和灾难恢复能力。2007~2010 年， 招商银行陆续完成了开放平台重要系统的灾备建设，同时开展了大量异地真实切换演练，初步实现了重要业务系统的灾备建设目标。2012 年，招商银行上海数据中心投产，彻底解决了困扰南京灾备中心的基础设施不足、发展空间受限的问题，为招商银行的灾备建设奠定了良好的基础，标志着招商银行的灾备建设进入了全新阶段。

　　二、灾备模式选择及战略目标

　　任何一家金融机构在进行灾备建设之前， 首先要面对的就是数据中心选址和主备模式选择的问题。在业界所熟知的“两地三中心”的灾备架构体系中，采用“大同城、小异地”还是“小同城、大异地”是一个非常重要的策略问题。在“大同城、小异地”模式下，同城灾备中心具备完整的应用处理能力，而异地灾备中心只有数据备份能力和基本的应用处理能力。由于同城灾备中心与生产中心距离较近，网络延时较小，很多厂商的产品可以支持双活，这样就能很容易地实现RPO=0 和RTO=0。但该模式最大的弊端在于无法应对区域性的灾难，且在这种模式下，异地灾备中心在灾难发生时是否能够如期发挥作用也是未知数。

　　在“小同城、大异地”模式下，异地灾备中心具备完整的应用处理能力，同城灾备中心只为核心系统提供数据备份和快速恢复的能力。“小同城、大异地”模式最主要的优点是应对区域性灾难的能力强。其缺点也很明显，如无法实现异地数据双活，灾难发生时存在数据丢失的风险， 而且该模式对运营管理的要求很高， 由于两地员工的办公地点不在一处， 存在沟通和交流上的困难， 两地一体化运维的问题凸显。

　　招商银行权衡优劣，从抗灾能力、投资保护、自身核心系统的技术特点等多个角度综合考虑，确定了“双中心运行”的灾备模式，该模式有别于“两地三中心”的惯常做法，只建异地灾备中心，不建同城灾备中心，并且将异地灾备中心定位于“第二生产中心”。

　　为了实现两地一体化运维，招商银行从流程、技术、资源、人员多个方面同时入手。在日常运维流程方面，两地遵循同一套ITIL 流程和ISO20000 标准。在应急管理流程方面，所有系统的应急或灾备演练均由两地人员共同参与，并跨两地设定了AB 角。在技术方面，制定了高可用架构标准，所有系统均按照该架构改造，确保两地的主备系统架构和资源配备完全一致，当灾难发生时，上海数据中心可以100%接管交易。在工具方面，监控系统、自动化工具、登录工具等两地均统一部署，使用相同的用户界面，做到两地视角和体验的一致性。在人员方面，为培养上海数据中心员工，上海数据中心新员工均要求先在深圳学习至少一年。为提高两地员工的沟通效率，启动了“双中心通讯”项目，建立了高清视频会议系统、桌面视频系统、即时通讯系统、IP电话系统等集消息、语音、视频于一体的双中心通讯平台。

　　为了实现“双中心运行”，招商银行信息技术部确定了“主机系统每年在上海运行一段时间，开放系统均衡运行在两大数据中心”的终极目标，并为此制定了灾备建设路线图(见图1)，将终极目标分解为每年可执行的具体目标，循序渐进，逐年提升。

　　三、灾备建设概况

　　1. 数据中心布局

　　目前，招商银行采取“两地双中心”的布局，两大数据中心之间的距离约1500 公里，其中生产中心位于深圳，数据中心功能用房建筑面积约11 000 平方米，灾备中心位于上海，数据中心功能用房建筑面积约15 000 平方米。分支机构均通过网络专线同时连接深圳和上海两大数据中心;上海数据中心配备与深圳数据中心基本相当的计算、存储、网络资源，提供相同的运行支撑能力;具备所有重要系统的应用级灾难恢复能力。

　　2. 应用主备模式

　　招商银行两地双中心采用分应用主备模式，深圳数据中心为第一运行中心，上海数据中心为第二运行中心，双中心均需要完成生产任务。目前多数系统运行在深圳，部分系统两地同时运行;未来逐步实现重要系统均衡分布在两地运行,如图2 所示。

　　(1)通过数据复制技术将数据异步复制到对方。

　　(2)通过负载均衡技术将交易分配到不同的中心。

　　(3)平时主要的处理能力均分配给生产应用系统使用，出现灾难时，根据需要接管的方式，动态调度资源给备份系统使用。

　　3. 灾备建设情况

　　根据业务影响分析(BIA)结果，2012 年招商银行发布了全行重要系统清单，信息技术部以此为基础拟定了TOP 系统清单，2013 年的建设目标即为实现“TOP 系统的全灾备，特别重要系统的快切换”。截至2013 年7 月底，除个别系统外，基本完成了TOP 系统的灾备系统建设，其中部分系统实现了两地准双活，特别重要系统均已实现了异地快速切换。

　　在灾备技术方面，招商银行在多年的灾备建设实践中逐步摸索出了一套成熟的高可用架构。在站点选择技术方面，招商银行根据互联网和行内网的不同特点，分别采用了动态域名解析和路由健康注入两种不同的技术;在数据备份技术方面，主要使用了数据库层和存储层的数据备份技术;在灾备自动化方面，一是通过应用的异地双活减少切换环节，二是通过标准化数据库层架构压缩切换步骤，基本实现了异地“一键切换”。

　　四、业务连续性管理

　　1. 组织架构

　　招商银行在业务连续性日常管理的实践中发现， 由风险管理部门或综合管理部门牵头业务连续性日常管理具有由信息科技部门牵头管理不可比拟的优势，因此招商银行在2011 年对业务连续性的管理架构进行了调整，将全行业务连续性管理的牵头工作划归总行办公室， 操作风险管理部、信息科技部、各业务部门、各分支机构为执行部门， 理顺了业务连续性的管理框架。

　　在业务连续性应急管理方面，招商银行在总行和分行都成立了应急领导小组、应急协调小组、应急执行小组和应急保障小组。总行应急领导小组是全行信息系统突发事件应急的最高管理机构。分行应急协调小组、应急执行小组和应急保障小组除了受分行领导小组管理外，也接受总行相应小组的垂直条线管理(组织架构如图3 所示)。

　　在信息技术部门内部，业务连续性管理工作由深圳数据中心、上海数据中心、开发中心共同参与，每套重要系统均设置“服务经理”为第一负责人，应急小组成员则由两个数据中心和开发中心人员共同组成。应急小组成员参与系统日常运维、故障处理、灾备演练、培训学习等活动，做到平战结合，将应急和灾备融入日常运维工作中。

　　2. 流程和制度建设

　　目前，在全行业务连续性管理

　　体系的总体框架下，招商银行信息技术部初步建立起了完善的信息科技连续性管理体系。

　　(1)完善了应急文档体系，修订了信息科技应急管理制度，编写了涵盖招商银行重要业务系统的应急预案。为了能快速有效处置信息系统突发事件，总行信息技术部对可能影响全行业务和总、分行重要业务的信息系统制定了详细的应急预案。目前有效预案总数56 个，基本覆盖了招商银行重要信息系统和信息安全保护等级二级以上的信息系统。同时以实际演练检验应急预案的有效性，做到应急预案 “能用管用”。此外，统一制定了应急预案模板，要求各部室按照模板更新应急文档，实现了应急文档的规范化管理。

　　(2)完善了应急处置流程。招商银行根据信息系统的重要性和突发事件对业务、服务的影响范围、影响程度及事件发生时间段，对信息系统突发事件进行分级(目前共分五级)，并对不同级别事件采取不同的处置流程。

　　(3)建立了连续性日常管理流程。

　　(4)开发了一套业务连续性管理系统，通过该工具可实现应急预案和日常工作的集中管理，提升了全行业务连续性管理水平。

　　3. 灾难恢复演练

　　2012 年借南京灾备中心向上海数据中心搬迁时机，招商银行先后对渠道类系统、支付类系统、银证类系统进行了异地灾备演练，验证灾备方案的有效性。

　　招商银行高度重视灾备演练工作，演练工作由信息技术部门单独完成转变为业务部门和信息技术部门多部门联合参与。演练参与部门包括总行办公室、零售银行部、现金管理部、运营管理部、信用卡中心、远程银行中心、监察保卫部、行政部、上海分行、深圳分行，通过演练提升了应急组织的指挥、处置、通讯、协调和保障能力。

　　五、“双中心运行”的主要挑战和应对措施

　　与“两地三中心”的“小同城、大异地”模式面临的问题类似，招商银行在采用“双中心运行”的灾备模式时也面临着不少挑战。

　　1. 两地系统一致性问题

　　在生产中心和灾备中心各自为战的运维模式下， 灾备系统与生产系统的一致性难以保障， 导致灾难发生时灾备系统无法接管或需要耗费很长时间才能接管生产系统。招商银行在灾备建设过程中也遇到了相关问题，如两地的操作系统版本不一致、灾备系统因网络限制无法访问生产中心的关联系统、异地数据库用户过期等。为了解决上述问题， 招商银行采取了如下措施。

　　(1)推行应用双活。在多年的灾备建设实践中， 招商银行大部分重要系统均按照应用两地双活的要求进行了程序改造， 目前均能支持负载均衡技术和跨广域的数据库访问。实践证明， 采用应用双活模式的系统在日常运维中不容易忽视灾备系统的更新，因为一旦更新不及时交易会立即报错，而采用主备模式的系统由于灾备系统平时不承担交易， 很多问题平时很容易被忽视。(2)采用统一架构。以往出于节省成本的考虑，灾备系统的资源配置往往会被压缩，导致灾备系统高可用性难以保障。近年来，一方面随着虚拟化技术的广泛采用，灾备资源利用率低的问题有所缓解;另一方面，按照招商银行“双中心运行”目标，灾备系统的架构应与生产系统保持一致。基于上述因素，招商银行确定了两地采用完全一致的系统架构和资源配备的策略，为重要系统在两个数据中心间常态化切换和长期运行创造了条件。

　　(3)使用同步工具。为确保两地配置文件、应用程序的一致性，招商银行采用了同步工具定时从生产系统向灾备系统同步配置文件、应用程序，并且对同步工具的执行情况进行监控，确保两地的配置文件、应用程序版本的一致性。

　　2. 灾难恢复和应急的协同在传统观念中，高可用性一般指本地系统的可用性，通过架构设计、应急预案，优先在本地解决故障，而对灾备系统只要求在灾难发生时提供最主要的功能即可，对其高可用的要求较低。但在“双中心运行”的模式下，重要系统经常在两个数据中心之间来回切换并长期运行，生产系统和灾备系统的角色经常互换，因此两地的系统都必须设计为高可用架构。在两地的架构统一以及异地切换变得简单快捷之后，应急就不再如往常一样限于本地，而是随时都有可能向异地切换。因此，灾难恢复不再是一件繁琐浩大的工程，而是融入了日常的应急处理中，作为一种常见的应急手段而存在。

　　在实践中，招商银行并未将灾难恢复预案与应急预案分开，而是将灾难恢复作为一种常规的应急手段并入了单套系统的应急预案中。在进行应急演练的场景设定时，不仅包括本地场景， 也包括异地场景，并且两个中心的应急小组成员均参与演练。在日常的故障处理中，除了需要物理操作的故障外，逐渐打破地域限制，实现与地域无关的故障处理。今后将通过重要系统的两地交换运行，逐步形成互为主备的运维模式，真正实现“双中心运行”。