【51CTO记者 李玲玲 北京报道】近年，迭代速度明显加快的科技新态势使全社会迈入了一个崭新的商业环境，特别是新金融的快速发展，在加剧传统银行竞争的同时，也使其所面临的科技风险不断攀升。这些变化无疑对保障银行数据中心安全、可靠、稳定运行以及提高银行业务连续性水平的要求更高，也迫使银行需要重新审视过往的灾备建设是否也做到了与时俱进。
从2007年推出《 信息安全技术信息系统灾难恢复规范》(GB/T20988-2007)，到2008年央行发布《银行业信息系统灾难恢复管理规范》、2010年银监会制定《商业银行数据中心监管指引》，我们可以看出，监管层的连续发文对银行业的灾备建设直接设置了多道“政策硬杠”。比如上述条文中明确规定，“商业银行应于取得金融许可证后两年内，设立生产中心;生产中心设立后两年内，设立灾备中心。而总资产规模达一千亿元人民币以上且跨省设立分支机构的法人商业银行，及省级农村信用联合社应设立异地模式的灾备中心，重要信息系统灾难恢复能力应达到《 信息安全技术信息系统灾难恢复规范》 中定义的灾难恢复等级第5级(含)以上;其他法人商业银行应设立同城模式的灾备中心并实现数据异地备份，重要信息系统灾难恢复能力应达到《信息安全技术信息系统灾难恢复规范》中定义的灾难恢复等级第4级(含)以上。”换而言之，能否抵御突发风险，是否具有一定的灾难恢复能力，已经成为银行获取相关经营牌照的必要条件。
基于此，银行灾备建设的目的就是确保其科技基础设施具备应对灾难风险的抵御和控制能力，能够将业务损失降到最低。目前，在各类银行中，灾备建设的主流方案主要采用的是“两地三中心”，即主生产中心、同城灾备中心加异地灾备中心的布局模式。其中，同城和异地灾备中心又有两种模式：大同城小异地和大异地小同城，所谓“大”指的是应用级，“小”指的是数据级。而这两种模式也是各具优势。一般来说，在银行业中大同城小异地模式采用较多。在此模式下，同城应用级灾备中心是按照主生产中心技术架构来建设对应的业务系统和基础设施，可以通过虚拟化或者单机来减少设备投入，但是网络、存储、应用架构必须是一致的。日常主备中心要保持两地存储数据同步复制，关键业务数据的实时同步复制，理论上可达“零丢失”级。而对于异地数据级灾备中心，只需保持数据异步复制，定期恢复数据，并验证其完整性，根据监管规范和异地灾备策略容忍灾难情况下一定几率的数据丢失。对于没有灾备建设经验，且科技投入和人力有限、合规要求迫切的中小银行可以先进行恢复等级要求稍低的异地数据级灾备中心建设，满足一定监管合规要求并积累灾备经验后，再进行同城应用级灾备中心建设，这样项目开展稳妥有序，风险较小。
虽然银行灾备建设项目普遍具有投资高、周期长，各类项目风险多且影响大，而且建成后的维护和持续升级优化成本也非常巨大的特点，但是，一旦灾备中心投入使用，它所能发挥的综合风险控制能力是不可低估的。
原因在于这样的灾备中心不仅仅是一个数据中心的基础设施建设，它还包含了银行内组织建设、流程建设、政策制度建设等多个方面的规划布局，具体在后面的访谈中还将深入谈到。我们这里可以先设想一个具体的灾备运作场景：假设一家银行的主生产中心突发灾难情况，如大楼火灾、供配电系统瘫痪、机房通讯电缆挖断等，数据中心对外服务完全中断并且短时间无法恢复。而此时由于我们具备同城应用级灾备中心，那么就可以将银行业务损失和社会影响极大地降低。“因为是同城两中心，日常一直保持两中心存储之间的数据实时同步复制，设计上可以对关键业务的RTO、RPO设定较低，RPO甚至达到理论上数据零丢失。灾难发生后，可以迅速启动应急预案，启动灾备中心的关键业务系统，将所有分支机构网络路由到灾备中心，就可立即恢复银行的主要业务并持续对外提供服务。在主生产中心故障处理完毕后，再重新同步复制两中心数据，数据一致后，再做同样的业务切换步骤切回到主生产中心。我们在项目实践中经过反复的切换演练已经可以做到关键业务RTO在一个小时左右，RPO 0-15分钟。当然理论上很简单，但实际操作起来涉及了大量科技、业务内容，实施起来难度很大。尤其对中小规模的银行而言，人员资源、管理措施都有局限，就光业务系统的关联性影响分析(BIA)一项全行上下就花费了大量的精力，其他的集成测试、全行培训、模拟演练的困难性更是成倍增长。 ”
综上介绍，尽管国内银行灾备建设起步较晚，但在愈加严格的监管政策和自身日益提高的风控需求激励下，国内银行业灾备建设一日千里，不仅大型国有、股份制银行迅速完成并完善自身灾备体系，广大中小城商行、农商行也快速跟进，积极行动起来，成为我国银行业信息化建设进入新世纪的一道亮色。
当然，随着银行业灾备建设的推进，灾备理论方法也在不断发展。此次仅就灾备建设从规划、到策略制定、实施及后续的管理整个过程中应该注意哪些问题，51CTO记者对曾经作为项目经理全程亲历某银行灾备建设项目的孟小疆(现成都农商行村镇银行基础架构室经理)进行了独家专访。
对此，孟小疆感触颇深。他表示，“银行灾备建设任务重，责任大，风险高，当时作为刚进入灾难恢复领域的新人压力可想而知，光是做灾备演练的那两个月里，我基本上没时间理发，胡子拉碴的，跟野人一样。现在回想，完成项目也是一次身心的磨砺，好在挺过来了!”
能够亲历整个灾备建设，过程虽苦，却让孟小疆对这段过往生出了“不憾此生”的感慨，“回头想想，真心感谢行里给了我这次机会，当时行领导决定尽快建立满足合规要求的灾备体系，按照‘统一规划、分步实施’的项目思路，最终完成了‘两地三中心’的布局，这其中最难的第一步，就是同城灾备中心建设。我既是基础运维团队经理也是项目经理，一人两肩挑，从2011年接手项目到2012年正式上线，干了将近19个月，期间内外协调，专题汇报，监管备案的次数已无法计算，只记得每天都有忙不完的事，可能也是‘初生牛犊不怕虎’吧。加之行领导、科技部同事们的全力支持，和业务部门合作关系也不错，使得整个灾备项目最终顺利上线。虽然过程中也走了一些弯路，但整体上还是达到了行领导的要求，尤其是行里决定以真实切换的方式实现了同城灾备中心的正式上线。这在当时的国内银行里也是不多见的。而且整个项目过硬的技术和组织都给莅临指导的监管机构留下了深刻的印象。”
银行灾备中心建设中的几个关键环节
回顾整个灾备建设项目，孟小疆认为，其中几个关键点对银行灾备系统建设至关重要：
一、项目建设要立足全行业务连续性，需由高层领导牵头多部门协作，整合全行资源。
按照目前通行的业务连续性理论，灾备建设是全行业务连续性策略的组成部分之一，在银行内部往往是先形成较完整的业务连续性策略，再分配到各部门按照统一策略进行落地细化。在灾备建设项目的组织和管理上，由风控部门组织协调各业务主管部门，配合科技部门落地实施是最为理想的项目组织结构。
“银行的业务连续性内容很广，业务部门有业务部门的连续性策略，而科技的业务连续性策略主要就是灾备这一块，但是最终都会统一到全行业务风控的层级上。我们在这个项目建设中走过弯路，即在项目之初由于行内还没有成文的业务连续性策略，科技部的灾备建设成为先行者，有种摸着石头过河的感觉。有段时间出现了冒进求快的思想苗头，与业务部门的配合脱节，造成业务系统风险定级不能完全反映业务实际需求的项目风险，好在我们能及时反思，在科技部内对于灾备建设项目应该‘走出去、纳进来’形成了一致意见，并迅速调整实施，首先主动与风控和业务部门座谈，收集他们的意见。”
“第二个转变就是立即向主管领导逐级汇报，最终组成由多位主管，包括行领导和职能部门领导在内组成的行级项目领导小组直接指导推进项目，领导小组的成立加速了项目进展，使全行资源得以集中。最显著的是相关业务部门积极参与本部门的业务影响分析和RPO、RTO定级。可以说，这是本次项目整体能够得以顺利完成的一个关键转折点。”
二、切换演练方案更要贴近实际、实现跨部门多层级，还要敢于真切实练。
美军有句名言“如战斗般训练，如训练般战斗”，美军发现在真实战场上完成任务的难度实际往往小于训练场的模拟，其高水平训练出高素质作战单位正是美军近二十年来在多场战争中战损率之低的主要原因之一。这个道理其实可以完全移用到我们对待灾备演练的认识上。
灾备中心的设立实质上是对极端灾难情况下科技风险的一种技术应对措施，可能在现实中大多数的生产中心在其生命周期内都不见得会遇到一次灾难事件，但是只要这种风险存在，那么灾备中心就要具备随时可切可用的能力。如同军队在无仗可打时要通过军事演习保持战斗力一样，定期的切换演练同样是保持和验证灾备中心可靠性、可用性的主要方法。
灾备切换演练从形式上大致分为桌面演练、模拟演练、真实演练，难度和风险由低到高，但对于灾备中心的主要职能——灾难情况下的业务接管能力而言，灾备中心的真实切换演练是不可替代的，所有的桌面、模拟演练的目的也是为了完善最终的真实切换演练方案。
“在项目过程中，灾备切换演练往往是项目组花费精力最多，动员并调动全行资源最多的阶段。也是灾备日常运维中的重点、难点。所谓真切，即启动灾备中心业务系统，将原来对主生产中心的业务访问切换至灾备中心，不仅总行而且下面的全部分支行网点也要接入灾备中心做业务。”孟小疆说，“为了实现灾备中心真实切换，我们不仅在网络设计上花了很大的心力，同时在灾备中心应急业务系统上也做了很多细节保障，要确保业务人员能登录正确的灾备业务系统，而科技人员也能发现可能的网络隐患。例如，我们专门给柜面客户端界面做好清晰标识，为柜面人员提前编辑好业务系统访问列表，提前和每个支行网点的会计主管做好灾备环境检查等等大量的细节工作，这些工作大部分技术含量并不高，但别小看这些‘土办法’，实践表明真的是好使管用，基层业务人员也能够快速掌握灾备应急操作步骤。最终全行级真实切换演练这个槛我们是比较顺利地跨过去了。”
此外，在灾备演练的准备和实施过程中，还有三个重要的环节需要注意：
1、 一定要重视灾备的全行培训和动员。这一点往往在银行内是被优先靠后排的。灾备建设最需避免的误区就是项目圈于科技一隅。如何与业务部门配合，获得业务部门的理解和认可是项目成功和后续运维的群众基础，如果没有动员组织，以及进行长期化的培养，这个基础就变成一盘散沙。
2、 切换演练方案的设计可以引入专业咨询公司的帮助。切换演练以什么形式切，切多少次，达到什么目标结果，需要灾备方法论结合实践经验。切换演练方案设计是项目切换演练阶段的核心任务，它涉及了应急预案、场景设计、切换步骤、演练组织等多个方面。“我们有幸与灾备咨询行业的著名企业合作，得到了专业的指导，尤其是在全行演练的组织安排方面获益良多，少走了很多弯路，所以适当引入咨询合作值得大家考虑。”
3、 业务案例验证要全面覆盖。灾备中心能够实现业务系统的切换还只是成功了一半，真正业务能否正确运行并且对外服务一定时间，才能说明灾备中心的切换是成功的。“当时我们先确定第一批十几个关键业务系统的灾备建设，为保证真实切换后业务是否可用，业务部门为此编制了近千个业务验证案例，这些都是业务和风控部门综合考虑又通过多次全行反复演练后筛选出来，具有典型意义的案例。全行灾备演练时，由运管部带领各业务部门进行业务验证，现场气氛紧张但有序，如同流水线一般。每完成一个业务系统验证，归属部门的业务验证人员就要向总指挥部报告，所有过程都是明确记录下来的，作为向银监会、人行的报备材料，备案文件里需要写明业务验证案例内容和验证结果，可见业务部门对演练的严谨态度。”
三、灾备日常运维和持续优化管理的关键是要看灾备管理岗位能否发挥作用
众所周知，灾备中心建成，灾备切换成功并不代表灾备体系的建成，这仅仅是灾备体系建设有了起点，后续还有大量的配套运维和持续优化建设。本文孟小疆结合自己的项目亲身经历分享了他在实践中认为比较重要的几点：
1、项目组织架构如何平滑过渡到常设应急组织
从前面的介绍中，我们知道灾备建设项目往往作为全行重点项目，一般由行领导牵头，各业务部门配合，科技部主导技术落实，通过应急预案、演练方案将所有这些组织、技术、管理要素串联起来，完成灾备基础设施、基本制度、基本流程的建设，并且进行了可用性、可靠性的验证。从中其实已经可以看出一个基本架构完备的灾备体系组织结构雏形，接下来的工作就是在这个基础上更加完善和拓展。
“在项目结束后主动与风控部门对接，将灾备建设中的应急预案部分交由风控部门审核颁布，项目领导小组成员经过适当调整扩充，基本上转变为新的全行应急领导小组，业务部门的项目参与人员转变为业务连续性接口人，科技部项目主要参与人转变为灾备管理岗，在项目过程中锻炼形成的技能、经验和组织结构基本保留了下来，做到了项目成果的最大化利用。”
2、科技部灾备管理岗位编制的设定
由于灾备中心实际上也是一个完备的数据中心，所以对于灾备中心的维护以及后续建设、演练等工作理论上应该是有专职专岗负责较好。但是实际落实起来却有很多的问题，比如岗位设置的部门层级关系到协调力度，编制的多寡涉及到实际的管理范围，考核制度涉及到权责的梳理等等。由于各家银行的科技部门组织结构和管理思路差异很大，只能根据实际情况来决定。
“我们在项目完成后也遇到这个问题，项目建设时领导重视，要什么有什么，项目一结束第一个感觉就是找不到人了，即使找到人也不一定配合你。虽然在项目收尾阶段已经预先制定了相关的管理制度，但是在执行上还是遇到这样那样的困难。尤其受困于人力资源、岗位定级、薪酬等非科技因素困扰，短时间无法实现岗位定编。我们初期就采用生产、灾备团队一体化运维的方针，由一人专职负责，统筹各技术专业人员，对主备中心的日常更新、建设、演练做好计划和协调工作。虽然这只是一个过渡方案，但是因为灾备初期涉及的关键业务系统并不多，也还能运作开，而随着全行业务连续性的进一步推广，这种模式肯定是无法长期维持的，仍需要在更高组织层级、更多岗位编制、更大的管理权限方面做提升。”
3、如何克服对灾备演练的两难心理
在灾备行业内有句名言“不要让灾难演练变成演练灾难”，这句话真实道出了科技人员对于灾备演练的两难态度。随着监管对银行灾备建设愈加规范化，其审计标准也已不再仅限于灾备建设的基础设施条件是否满足要求，而是对灾备中心的例行演练和业务数据的恢复检查频次都做了更为明确的规定，而且有愈来愈强化的趋势。在这种监管政策趋严的大环境下，银行方面自然要按照规定去落实，但另一方面，由于银行业自身的特殊性，以及我国银行业自改革开放以来业务系统快速发展的历史特点，造成了新旧系统之间关联庞杂，架构繁复，配置管理和文档规范化工作又相对滞后，尤其中小银行在人力、物力、管理能力等多方面受限，灾备切换操作的确存在太多的风险点，稍许不慎就会造成业务系统主机宕机，甚至产生因网络冲突引发主生产中心瘫痪的危局。
“可以说每做一次灾备切换演练肝儿都会颤一次。因为真实生产系统很复杂，不可能每个细节都梳理的那么清楚，特别在建设银行的初期，行里业务发展迅速，每个月都有新系统上线，每个星期少则几十个多则上百个系统的变更，整个生产环境还处于不断变化完善的阶段，遗漏情况就更为常见了。另外，对灾备更新的审核机制还牵扯到灾备的管理问题，初期生产、灾备运维团队一体化，灾备环境是否变更的操作复核仍然是同一批人，这是有一定风险的。” 孟小疆提醒说，“所以在项目结束后的一段时间里，大家对切换演练存在畏难情绪，一方面灾备管理要求迟迟不能推下去，要求的反馈也收不上来;另一方面，对上级风控部门的切换要求存在避重就轻的思想。其实‘说一千道一万’，对切换演练畏难的根源还是在日常运维管理存在问题，要想把灾备切换变得例行、顺畅起来，首先还是要把日常生产环境的运维先梳理顺畅，制度落实。”
对此，孟小疆当时所在行有针对性地采取了三点应对措施：
1、 在制度和组织上确保灾备中心和主生产中心运维同等地位。
这体现在制度上，灾备管理办法、应急预案都是全行级制度，科技部制度则凡是涉及灾备的全部进行更新，不留制度死角;在组织上，要求所有专业组必须要有直接对口灾备管理负责人的技术人员，灾备管理负责人可以直接安排其工作。同时，提高灾备管理负责人管理层级，即可以向运维、安全部门经理直接汇报和沟通。
2、 抓好日常运维的规范化，以变更管理为核心确保主备配置一致。
在灾备切换中绝大多数的失败源自于两中心系统软硬件配置不同，通过梳理统计发现造成配置不同的最大来源，是在变更过程中少做甚至没做灾备中心的对等变更，这个不仅是运维习惯问题，也是管理中对灾备的不重视，对流程和风险把控不严格的问题。我们首先从变更流程入手，要求变更人员必须完成灾备变更才能算变更全部完成;其次要求灾备管理负责人定期组织各专业人员对主备中心配置进行比对。当然，如果有一个专职的灾备运维团队，这样的工作就可以固定为每日例行的运维巡检，极大降低风险。
3、 通过桌面、模拟切换来培养运维人员的素质和能力。
为了确保运维人员的灾备技能，我们通过定期的桌面、模拟演练培养他们的灾备意识，克服他们的畏难情绪，让他们掌握灾备运维、灾备切换的主要制度、流程内容，并能熟练操作。其中尤其以桌面演练方式最为便捷和安全，这种方式要经常练，如同演员背台词一般熟练。而模拟演练由于涉及真实环境操作，具有一定的风险，每专业每季度至少要进行一次模拟切换。
四、灾备后续建设要关注技术发展，做好规划，适当引入一些成熟的先进技术。
灾备建设是一个庞大的系统工程，从资金到人员的投入成本都很大，因此项目需求一定要按照监管要求和在行内风控指导下进行，不要好高骛远，追求太先进的目标。谈到目前的技术热点以及对当前灾备建设的技术路线影响，结合过往经历，孟小疆认为，目前正在快速发展的云计算、虚拟化、以及分布式技术在银行业的成熟应用离预期还有一定的距离。银行业的技术发展受限于行业特点、监管规范，如果在安全稳定和先进快捷中选择，无疑更倾向于前者。
因此，孟小疆表示，对于中小银行而言，与其冒这种未知技术路线的选择风险，还不如在已有成熟技术路线上进行挖潜优化，因此他更看好能够开发出包括灾备切换自动化、可视化功能的灾备系统管理平台软件。“目前银行的灾备切换很多还是采用人工指令、手工切换的方式，即大家制定一个操作步骤列表，然后手动输入执行。比如现在大家开始做灾备切换演练了，第一步生产环境停机，依照列表，谁来停主机，执行哪几步命令，非常明确。其实在这个基础上再进一步就可以脚本化，有脚本化就可以形成功能模块，并进一步加入触发条件形成自动化执行的能力。现在有的咨询厂商已经在开发和推广类似的灾备切换系统，中小银行可以加以关注。”
诚然，未来随着智能化、分布式技术的涌现，灾备建设会越来越向着智能化、多中心方向发展，“或许不久的将来主备中心概念也会消失，转而是以全互备的结构来替代都未可知。”但无论灾备技术如何发展，抵御灾难，降低风险，保障业务运行仍然是其主旨，而银行科技人依然会战斗在灾备建设的第一线，有担当有作为。(完)
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
