【摘要】本文站在某银行灾备项目负责人的视角，以农商行业务接入平台的灾备建设为典型案例，详细介绍了重要系统灾备建设的主要过程，包括：生产端的待建设系统架构梳理、“同城双活”模式的灾备架构如何设计、服务器和网络设备的选择和使用、灾备演练的组织过程等。最后，基于多年的灾备经验，作者对灾备建设中的一些难点进行归纳和总结。

【作者】都市稻草人，男，硕士研究生学历，大师级业务连续性管理专家认证（MBCP），就职业于某农信10余年，先后担任：系统管理员、中间件管理员和灾备项目负责人，具备丰富的灾备和业务连续性管理经验。

1990年，一种划时代的商用服务器诞生了，那就是基于RISC的产品的RS/6000系列小型机，运行AIX操作系统。中国人送给这种高性能高稳定性的服务器一个响亮的名字—小型机。作者本人第一次听说“小型机”这个词是在广州读大学时期。当时上“计算机英语”时候，这门课的女老师是外语专业科班出身的，自称“电脑爱好者”。她在课堂上翻译课文的时候反复提到“威力服务器”这个词，大家觉得这个词很奇怪是因为当时有一款洗衣机的品牌是“威力”。直到后来上计算机操作系统课的时候，任课老师捧腹大笑说“威力服务器”就是小型机服务器。

作者本人真正接触到小型机是在工作之后。当时单位机房的宝贝就是两台P595型号的小型机。作为高可用互备，其上运行着我们银行的核心系统。小型机的高可靠性和高性能早已深入单位每个科技人员的内心，这也是10多年后我们建设灾备的时首选Power小型机服务器作为硬件基础环境的原因。本文以“农商行业务接入平台”的灾备建设为例，应用系统和数据库均采用浪潮K1 Power小型机作为服务器，详细介绍该平台的同城灾备建设及切换过程。

一、建设背景

作为省级农村信用社，全省的核心业务系统、图形前端、综合前置、信贷、网银、手机银行等系统部署在日新中路省联社的数据中心。但是每个州级农商行都有一些根据本行特色业务而建设的特色系统。这些州级农商行的特色系统（甚至某些电子渠道的重要系统）接入省联社的数据中心是通过“农商行业务接入平台”来完成核心系统记账。省联社在开展同城灾备建设的时候，不得不考虑“农商行业务接入平台”的同城灾备建设。

根据银保监会印发的《商业银行业务连续性监管指引》和人民银行发布的《银行业信息系统灾难恢复管理规范》等文件规定，省联社制定了《业务影响分析报告》，将“农商行业务接入平台”列为省联社业务连续性管理的重点系统，随后省联社科技部门和某州级农商行（试点单位）信息技术部以“数据实时复制、应用集群双活”为技术目标对“农商行业务接入平台”在锦中路同城灾备中心开展灾备建设。

二、建设前架构

农商行业务接入平台”在省联社同城灾备中心无相应灾备系统部署，在省联社生产中心由2台“农商行业务接入平台”AFA、2台“农商行业务接入平台”AFE、2台PowerHA的数据库服务器组成。硬件环境部署则遵循这样的方式：为保证该系统的高可用性、消除单点隐患，需保证集群应用和做PowerHA的数据库在物理上要隔离开，不能部署在相同服务器和机柜中；另外考虑到Power小型机的逻辑分区DLPAR技术具有资源隔离和在线动态扩展资源的优势，生产端这些系统均部署为LPAR。硬件配置情况如下表1所示。

表1 生产端硬件配置表

从某州级农商行发往省联社系统的实时交易流向图如下图1所示。交易的转发处理流程按照图中的顺序“1—>2—>3”,再由cics transaction gateway(简称CTG)集群将交易发送给核心系统（使用CICS交易中间件）。

图 1

从某州级农商行发往省联社系统的批量交易流向图如下图2所示。

图2

相关网络配置信息如下表2所示。

表2 生产中心“农商行业务接入平台”网络配置表

三、同城双活灾备建设

为实现“数据实时复制、应用集群双活”的技术目标，省联社在锦中路灾备中心为“农商行业务接入平台”搭建一套数据级灾备，即冷备的灾备数据库且所用磁盘与生产中心的数据库实时同步，保证数据零丢失。同时按同等配置搭建应用级灾备，即在灾备中心搭建2台“农商行业务接入平台”AFA和2台“农商行业务接入平台”AFE。投产后灾备中心的2台“农商行业务接入平台”AFA和2台“农商行业务接入平台”AFE与生产中心对应的服务器一起进行交易处理。由于平台应用采用的是同城双活方案，灾备端同样承载生产业务，所以其分配的硬件资源应尽量考虑与生产端相当，并沿用生产端LPAR的部署方式。锦中路灾备中心的灾备服务器的应用配置表入下表3所示。

表3 灾备端硬件配置表

改造后从某州级农商行发往省联社系统的实时交易流向图如下图3所示。

改造后从某州级农商行发往省联社系统的批量交易流向图如下图4所示。

图4

改造后，生产中心的网络配置信息不变，灾备中心相关网络配置信息如下表4所示。

表4 灾备中心“农商行业务接入平台”网络配置信息表

此外，农商行业务接入平台的数据级灾备建设时，没有采用数据库层面来保障业务数据的实时复制，而是采用更底层的基于磁盘级的数据同步技术来实现。即采用SVC技术将农商行业务接入平台生产端和灾备端的Db2数据库服务器所依赖的存储进行实时同步来保障数据零丢失。

四、投产及切换演练流程

4.1 时间

本次演练的计划开始时间为2020年x月N日23:00，计划结束时间为2020年x月N+1日01:00。

4.2 参与人员

省联社参与的人员涉及：运维部门科技人员、研发部门科技人员，以及信贷部、电子运营部的业务专家。某州级农商行参与的人员有：系统组、电子渠道组、信贷组和部分网点业务员。

4.3 涉及业务

本次切换涉及到某州级农商行56种联机和批量业务，包括：票据业务、国际结算业务、呼叫中心业务、信贷业务、微信业务、手机银行业务、网银业务、少数民族特色扶贫业务等。

4.4 投产及切换演练流程

本次切换演练的计划流程如附件1所示，具体执行过程如下：

（1）x月N日 18:00-23:00：某州级农商行开通相关防火墙策略：灾备中心“农商行业务接入平台”2台AFA和2台AFE的IP地址、F5虚地址、DNS服务器地址；

（2）x月N日 21:00-23:00：省联社启动灾备端“农商行业务接入平台”的AFA和AFE应用，检查有无报错信息，无问题后停止灾备中心的AFA和AFE应用服务；

（3）x月N日 23:00-23:10：某州级农商行使用“业务集成平台”与省联社的“农商行业务接入平台”。某州级农商行将“业务集成平台”连接“农商行业务接入平台”的方式由“虚拟IP+端口”改为“域名+端口”模式，并配置业务集成平台的DNS服务器为DSN1（主）和DSN2（备）；

（4）x月N日 23:10-23:20：某州级农商行重启业务集成平台；

（5）x月N日 23:20-23:50：业务验证；

（6）x月N日 23:50-x月N+1日00:00：省联社停止“农商行业务接入平台”生产端AFA和AFE，启动灾备端AFA和AFE应用；

（7）x月N+1日 00:00-00:30：业务验证；

（8）x月N+1日 00:30-00:40：省联社启动“农商行业务接入平台”生产端AFA和AFE集群；

（9）x月N+1日 00:40-01:00：业务验证。

4.5 法规及标准依据

本次投产及切换等工作，所参考的法规和标准如下：

（1）2008年，人民银行《银行业信息系统灾难恢复管理规范 》；

（2）2011年，银监会《商业银行业务连续性监管指引》；

（3）2013年，ISO标准委员会《公共安全 演练指南》；

（4）2018年，国家标准化委员会《信息安全技术 灾难恢复服务要求》。

五、难点总结

农商行业务接入平台的灾备建设顺利完成后，对整个灾备建设的过程进行回顾和总结，主要有以下几个方面的难点：

5.1 硬件选型

农商行业务接入平台的硬件基础平台的选型是第一个难点。银监会在《商业银行业务连续性监管指引》（银监发2011【104】号文）中明确要求商业银行为保障重要业务的业务连续性而开展业务连续性管理，同时在做业务连续性建设或灾备建设的时候要兼顾业务连续性管理成本与效益。农商行业务接入平台的定位是农商行信息系统接入省联社的一座桥梁，它的稳定性和健壮性关系着省联社对农商行的服务质量，虽然没有核心系统重要，但也非一般系统能比。相比于X86架构的硬件解决方案，浪潮K1 Power小型机有着安全性、稳定性以及性能等优势，这也契合了企业对于关键业务系统的服务质量需求。鉴于此，我们慎重地选择了稳定可靠的浪潮K1 Power小型机服务器作为应用系统和数据库的硬件基础环境，而没有采用x86架构的服务器。

5.2 沟通协调

第二个难点，也是各家银行在开始灾备建设时所共同面对的大量的沟通协调问题。比如灾备切换演练的人员有哪些？省联社需要参与的部门有运维部门、研发部门，这还远远不够。省联社业务主管部门有哪些需要参与？也就是农商行业务接入平台承接的交易涉及哪些业务？怎么开展业务验证？具体验证的交易有哪些？什么时候能做哪些业务的验证？有哪些分行哪些支行需要参与业务验证？每家支行需要派多少柜员和客户经理参与？这些统统都要考虑在内。参与的人多了，后勤保障怎么安排？当这些问题由业务人员或行政人员提出来，摆在一个灾备项目牵头人（科技人员）的面前的时候，你需要花费很多的精力和时间去了解和学习，才能进行有效的沟通协调，去避免可能发生的风险。

5.3 技术验证

按照国际标准《ISO 22398-2013公共安全演练指南》中规定，为了控制演练中可能发生的风险，在进行大规模演练前需要先开展技术验证，通过一次次小的切换技术验证来迭代风险，发现问题并解决问题，最后再开展一次大型的灾备切换演练。但是在实际执行中，最危险的其实就是那些所谓的“一次次小型的”灾备切换技术验证。在大型灾备演练中，很多大领导也会莅临指导，人力物力都很充足，各个条线的专家都会提前到场进行保障。但是在几个月前的“一次次小型的”的切换技术验证中，往往只是几个技术人员晚上加个班去做，准备时间不可能像大型演练一样充足，很多细节如果考虑不到会引发大事故。尤其是对数据库切换相关的一些灾备技术验证，在开始前一定要注意备份，技术验证要尽量利用停业务窗口，提前本单位领导乃至监管部门进行报备，并提前通知外联单位（如银联、农信银、外汇管理局、票交所等）。

5.4 同城双活

在国家标准《信息安全技术 信息系统灾难恢复规范》（GB/T 20988—2007）里对灾备等级进行了划分，最高为第6等级，银保监审计的时候事实上以第5等级（含以上）为不扣分的要求标准。我们所说的“同城双活”，也就是说在灾备中心的应用系统和生产中心一样进行业务处理，是第6等级（最高等级）的所要求的标准。而第5等级要求灾备中心的应用系统至少处于“就绪状态”。交易在生产中心和灾备中心进行分发的时候，常用的手段就是“DNS + F5虚地址”。即该应用系统暴露给外部系统的地址不是IP，而是一个DNS域名。此域名后跟生产中心应用集群的F5虚地址和灾备中心应用集群的F5虚地址。外部系统将交易分发给该系统时，DNS可以按一定策略和比例将域名解析成生产中心应用集群或灾备中心应用集群F5的虚地址给交易发送方。这样既实现了系统的同城双中心集群双活，又可以控制交易在双中心集群之间的分发比例。

六、建设成效

“农商行业务接入平台”同城双活建设取得的成效主要表现在以下几个方面：

（1）满足业务连续性监管要求：近年来，监管机构针对业务连续性进行的监管越来越严格、越来越细致。自银保监发布《关于开展中小银行机构业务连续性相关风险整治工作的通知》以来，业务连续性监管的机构范围，从大型银行也扩展至全国数千家中小银行。建设了信息系统灾备，提高了自身业务连续性管理能力，对商业银行的业务连续性管理第一责任人（行长）来说，是最现实的成效。

（2）提高灾备中心资源利用率：“农商行业务接入平台”的灾备模式是同城双活，即灾备端与生产中心同时进行业务处理。相对于仅在灾备切换后才处理交易的“冷备”模式，同城双活模式提高了灾备中心的服务器、网络、存储设备及机房环境的有效利用率，还能在业务高峰期间缓解生产中心系统处理的压力。

（3）支撑了关键业务系统的稳定运行：能支撑“农商行业务接入平台”的稳定运行，也是本项目的重要目标之一。Power小型机的逻辑分区技术是通过固件层实现物理设备的虚拟化，并将服务器资源划分成不同的逻辑分区来承载应用。由于逻辑分区之间接近物理隔离，大大提高了安全性和可靠性；另外，逻辑分区还可以动态调整分区资源，也符合了关键业务的连续性要求。在本项目中，无论是生产端还是灾备端均采用了Power小型机的逻辑分区技术，保证了关键业务系统的稳定运行。

（4）锻炼了应急处置能力：对于灾难的发生，身处灾难之外的人往往以为和自己完全没关系，以至于灾难来临时毫无准备。灾备能所以在“911事件”后发展起来，就是因为能在一定程度上解决该问题。在“农商行业务接入平台”的灾备演练中，全行从领导层至基层网点柜员全部调动起来，大家按照预案去执行，执行中发现问题进行记录，演练后进行研究和改进。这无疑锻炼了整个组织的应急处置能力，也加深了各级员工内心对应对预案的印象。

附件一、投产及灾备演练流程图