某金融客户灾备建设探讨

一、灾备建设的背景
不同类型的风险其影响程度、发生概率和造成的损失大小是不同的 , 在讨论银行灾备建设方案之前，可以将银行各信息系统所面临的风险因素、概率、影响和应对手段进行分析，以便于银行根据风险的抵御能力以及应用系统的重要程度，评估如何采取相应的灾备措施来减低各种风险和威胁可能带来的影响和损失。
《商业银行数据中心监管指引》和《商业银行业务连续性监管指引》等制度和规范中明确要求了容灾建设的指标，从商业银行业务连续服务实际需求出发，对应急处理效率和业务连续性提出了更高要求，应急过程中流程控制的精细化要求也变得越来越高，同时为保证整体容灾体系能够发挥真实作用，对于灾备切换演练中的 “ 真实业务接管 ” ，甚至双中心双活运行的要求已呈必然趋势。
容灾体系建设最主要目标是以最快的速度恢复业务，因此设计一套高效、快捷、准确的容灾架构，是防范信息系统运行风险、保障业务连续性的基础。由于 IT 系统技术架构的多样性，需要考虑系统资源、数据一致性、紧耦合、多系统联动等多种因素，加剧了容灾体系建设的复杂度。
二、灾备建设的标准
提到容灾备份，其中有两个关键指标必须有所了解， RTO 和 RPO 。 RTO 和 RPO 是灾难恢复方面的重要参考指标。现在银行客户对业务的连续性有苛刻要求，但故障不可避免，一旦发生了故障就需要启动备份机制，确保业务的连续性，所以现在较为完善的容灾机制， RTO 和 RPO 可以很好地反映出容灾性能如何。这两个参数是在运维过程中，一定要重点关注的指标。这个指标的好与差，是基于现有的各种综合运行情况评估得出的真实结果，反映当前在灾难恢复方面的修复能力。
RTO(RecoveryTimeObjective ，恢复时间目标 ) 是可容许服务中断的时间长度。 RTO 是反映业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间， RTO 数值越小，代表容灾系统的数据恢复能力越强。
RPO(RecoveryPointObjective ，恢复点目标 ) 是指能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间点， RPO 是反映恢复数据完整性的指标。在同步数据复制方式下， RPO 等于数据传输时延的时间，在异步数据复制方式下， RPO 基本为异步传输数据排队的时间。
三、灾备建设的思路

1. 针对银行业务系统特点，按照重要程度、风险等级、技术架构、数据一致性、应用特点等对系统容灾需求进行了普适性分析，在灾备高可用设计标准、等方面建立了一套容灾规划体系模型，使灾备系统部署组件化、标准化、一体化。
2. 自动化灾备调度，实现灾备自动化切换、自动化演练，将实际切换和模拟演练场景进行标准化定义，解决系统切换流程复杂、模拟演练困难等问题，直观展现了切换流程，控制了切换风险，加强了指挥效率，提升了灾备切换能力。
   四、灾备技术实现
   通过对主流灾备技术路线深入研究，结合自身容灾需求，根据系统重要程度、技术架构等不同特点，对所有系统进行了分层分级，参照对应灾备标准纳入灾备体系建设，按照如下思路进行快速部署。
   关键类业务系统：
   此类系统包括核心业务系统、支付类系统等，是银行系统中最关键的系统，对安全性、高可用性、数据一致性、运行性能的要求极高。这部分系统均部署在 K1 Power 平台，本身已重点考量了安全性、稳定性和可靠性，为保证业务连续性，在容灾架构设计时，既要保证数据最少丢失，又要考虑最短时间内恢复系统服务。充分评估各类容灾技术路线的优缺点后，对于此类系统，可以考虑采用如下架构策略：
   （ 1 ）应用层：生产和灾备网络打通，通过负载均衡技术将业务访问进行分流，按比例向生产应用和灾备应用分发，实现应用层生产和灾备双活，同时对外提供服务，提升灾备的设备利用率。
   （ 2 ）数据库层：采用存储同步复制和逻辑日志复制两种灾备架构同时进行灾备数据同步。存储同步复制技术以存储块为单位进行数据复制，存在物理块 “ 一损俱损 ” 导致的生产灾备同时宕机的问题，通过增加逻辑日志复制方案，增加逻辑错误校验机制，补足存储复制方案的短板，双重保障数据的安全。该金融客户核心业务系统数据库采用两台浪潮 K1 Power E950 ，使用 Oracle RAC 技术实现高可用，同城灾备中心采用两台浪潮 K1 Power S924 作为灾备服务器，也使用 Oracle RAC ；核心系统数据库容灾存储复制和 Oracle ADG 方案，并使用备份技术实现数据逻辑保护。
   次关键类业务系统
   此类系统包括柜面系统、信贷管理系统、中间业务系统等，对 RPO 、数据一致性、服务连续性、安全性、稳定性、性能要求较高。在容灾架构设计时，主要以保证最短时间恢复业务，尽可能的保障系统服务的健壮性。对于此类系统，可以考虑如下架构策略：
   （ 1 ）应用层：与关键类业务系统采用同样的技术实现应用层生产和灾备双活，同时对外提供服务。
   （ 2 ）数据库层：与关键类业务系统采用同样技术实现，或者从成本方面考虑，只采用一种技术，比如采用逻辑日志复制，在保证 RPO 接近于 0 的条件下，通过读写分离、应用程序配置双数据源的方式实现数据库双活。一般由生产环境数据库提供读写服务，灾备环境提供查询服务，保证灾难发生时不至于所有交易全部中断。
   人行、银联类业务系统
   此类系统包括二代支付、银联前置等系统，此类系统提供的都是 24 小时不间断业务，且需要与人行、银联等外部机构采用长链接的方式对接，对服务的连续性、系统稳定性、服务准确性要求较高。在容灾架构设计时，尤其要考虑与外部系统对接的容灾性，在应急切换过程中，需外部机构协调配合，应减轻外部操作步骤和复杂度，最短的时间恢复业务。
   五、灾备运营情况
   整体灾备系统运行稳定，生产和灾备提供的业务服务负载持平，灾备数据同步时间与生产保持一致，灾备负载的数据查询交易无延时，整体减轻了生产运行压力，保障了业务连续服务的能力。经过多次真实业务接管切换演练，充分验证了灾备系统的可用性。提高信息科技风险防范能力 , 验证了同城灾备系统有效性，进一步提升了科技管理水平。
   六、灾备经验总结
   对不同系统的重要性和技术特点的分层分级分析，选择合适的灾备技术路线。尤其针对传统集中式架构的业务系统，此类系统非常关键，架构无法轻易变动，需要在基础架构层面去实现高可靠和高可用。
   应用架构改造，使之具备分布式能力，通过应用层集群和流量分发技术构建业务双活，甚至多活能力，同时基于云计算资源池化、统一编排等能力，资源调配可以非常灵活，扩展也会非常容易。
   灾备建设是一个复杂的系统工程，也是一个长期的过程，该银行客户将进一步探索多中心多活容灾方案，加强云计算和大数据架构下的容灾研究，充分选择适合自身需求的新技术，不断完善整体容灾体系