前一段时间有同业专家在讨论数据中心的灾备建设，各位专家们对这个话题讨论度很高，对灾备系统的定位和建设目标都有各自的理解和见解。作为灾备系统，如果只是一个热备份系统应付监管、每年一次的切换演练任务，是否有必要花费大量的精力去建设，投入成本和收益产出是不可比的。如果将其的定位和功能扩大化，建立多地多活的数据中心，又将如何建设。本文是对异地灾备中心建设的一些思考和讨论。
1、灾备建设的必要性
对于大中型的金融机构而言，一般通过自建数据中心和机房的方式实现对基础设施硬件和网络的统一管理。这其中对数据中心的定义又分为生产中心、同城中心和灾备中心，灾备顾名思义是灾难备份，通常与生产和同城中心在不同的地理位置，用于在灾难时候能够接管生产业务。根据最新监管机构发布的《金融数据中心容灾建设指引》，其中指出了
同城容灾中心与生产中心应在不同园区、动力应来自不同变电站，避免同一城市内的小范围停电、建筑物火灾、基础设施设备故障、通信线路设备故障、软硬件故障以及其他突发事件可能造成的局部交通封锁或中断等小范围灾难的同类风险，且直线距离宜大于10公里。异地容灾中心在位置选择上与生产中心不在同一个江河流域、地震带、台风等自然灾害隐患区，避免大面积的停电、地震、洪水、海啸等较大规模的区域性灾难的同类风险，且直线距离应大于300公里。
本文主要讨论异地容灾建设相关的内容。
1.1 监管要求
在强监管和信息安全形势加剧之下，金融行业关乎国民经济支柱，其稳定性和安全性直接关系到国家经济的健康发展。在灾备建设管理方面，金融机构有一系列的监管要求和规范指引，包括《商业银行数据中心监管指引》（2010）、《银行保险机构应对突发事件金融服务管理办法》（2020）、《分布式数据库技术金融应用规范 灾难恢复要求》（JR/T 0205 -2020）、《金融数据中心容灾建设指引》（JR/T 0264-2024）等。这些监管要求明确了金融机构在灾备建设中的组织保障、需求分析、体系规划、建设要求和运维管理等方面的具体标准。通过这些规范标准的严格落实，确保在面临各种灾难性事件时，在灾备站点能够迅速接管并恢复业务，保障金融服务的连续性和稳定性。
同时针对一些信息科技风险管理不到位的，监管机构也会开出罚单，比如2024年1月份中国银行因为“部分重要信息系统识别不全面，灾备建设和灾难恢复能力不符合监管要求”等问题被罚款430万元；中信银行也因为“部分重要信息系统应认定未认定，相关系统未建灾备或灾难恢复能力不符合监管要求”等问题被罚款400万元。
1.2 业务连续性保障
金融行业的业务连续性对于维护市场稳定、保障客户权益和推动经济发展具有重要意义。灾难性事件，如地震、洪水、火灾等，可能导致金融机构的业务系统瘫痪，造成数据丢失和业务中断。这不仅会给金融机构带来巨大的经济损失，还可能引发社会恐慌和信任危机。因此，金融机构需要建立完善的灾备体系，确保在灾难发生时能够迅速切换至备用系统，保障业务的连续性。通过灾备建设，金融机构可以降低业务中断的风险，提高应对突发事件的能力，从而确保金融服务的稳定性和可靠性。这一类突发性的灾难在同业是时有发生的，2024年9月阿里云新加坡地区的机房出现火灾，据悉是锂电池爆炸引发，火灾持续30多个小时，关键云产品受到影响，包括云数据库、Redis等。试想一下，如果此类故障发生在金融机构，并且没有灾备站点将业务及时的切换过去，所带来的影响是无法估量的。
1.3 业务增长的需求
随着金融行业的快速发展和业务规模的不断扩大，金融机构面临着越来越多的挑战和机遇。一方面，业务量的增加对系统的性能和容量提出了更高的要求；另一方面，新业务和新技术的不断涌现也推动了金融机构的数字化转型和创新发展。尤其是一些大型金融机构，在数据大集中时代单个站点的基础算力设施已经存在着网络、计算、存储和机房等基础设施资源的性能和容量瓶颈，需要同城站点来分担这部分业务访问。同时随着信创改造和业务云化的深入，原来单台Z主机的计算能力需要几百台信创服务器来维持等量的算力，再加上高可用架构需要保证的多副本，这些无疑增加了基础设施的扩容成本。
2、灾备建设思路
2.1 容灾建设路线
上文提到了灾备建设的必要性，既有金融监管的强要求，又有业务连续性的可靠性服务保证，那么在容灾系统的建设过程中，需要遵循怎样的实施路线。
1）明确容灾系统的建设需求与目标
金融机构运行有多种业务系统，这些系统有面向客户的对客业务系统、也有业务支撑类的中后台系统，还有内部管理类系统，首先需要对这些业务系统的重要性进行分类分级，不同级别的应用系统对应的容灾建设目标也是不同的。对生产系统风险、基础设施风险、业务影响等进行综合分析，确定灾备建设的优先级和重点，制定不同的RTO和RPO恢复点目标。
2）制定灾备的策略与规划
根据容灾系统的建设目标，制定适合的灾备系统和灾备方案，比如同城容灾、灾备容灾，为不同业务连续性需求提供差异化容灾保障能力。同时要综合考虑建设成本和建设目标，同城和生产是等比例规划，灾备的建设比例是最小化还是等比例等。另外在规划过程中需要从系统群集和业务场景横向和纵向的角度考虑关联的系统，因为在容灾接管的时候如果只有核心业务系统完成切换，而支撑类业务系统不具备，整个业务流依旧是无法完成整体切换的。
3）灾备系统的建设实施
容灾建设实施包括基础设施环境、网络和硬件、软件和应用等各个层面，需要在不同的数据中心搭建等比例或者最小化的软硬件和网络资源，实现应用层的双活或者多活、数据库层的高可用。另外要实现生产系统与灾备系统之间的数据实时或异步同步，确保灾备系统数据的完整性和最终一致性。因此也需要灾备中心与生产中心之间的数据传输带宽充足，尤其是同城容灾的复制带宽，在大多数保证数据库层同城RPO=0的场景下，同城复制带宽瓶颈会影响到交易的性能。
4）灾备测试与演练
灾备测试演练是模拟灾难场景测试生产系统与灾备系统之间的切换流程，验证切换的可行性和效率，从演练过程中优化切换流程，发现流程中的问题和潜在风险。灾备系统需要制定详细的测试和演练计划，以验证系统的可用性和有效性，确保在灾难发生时能够迅速切换至灾备系统，保障业务的连续性。监管层面在这一块也做了明确的规定，对于核心业务系统三年内必须完成一次灾备切换演练，对于金融机构还有业务连续性的压力测试演练，这些演练是对灾备系统可用性的最好测试验证。
5）灾备应急预案与处置
灾备应急预案明确在灾难发生时的处置流程和责任分工，并且建立应急响应机制，确保在灾难发生时能够迅速启动预案，进行有效的处置和恢复。应急预案包括灾难识别、应急响应、系统切换、数据恢复等步骤，明确灾难发生后的处置流程，包括报警、决策、执行、监控等关键环节。
6）合规与审计
根据监管要求，对灾备系统建设和灾备测试验证过程进行合规性检查和审计，确保各项措施得到有效执行。同时根据外部和内部审计的结果，对于不符合监管要求的情况，及时进行整改和纠正。审计是监督改进的过程，在灾备系统建设过程中需要保证建设方案的完整性、测试验证记录和文档的准确性。
7）持续优化与改进
灾备建设是一个持续优化的过程，随着监管要求和业务连续性目标，以及技术架构的迭代发展在不断改进。以前可能数据库的冷备在灾备站点恢复就可以满足要求，现如今要做到业务灾备实切，需要在灾备中心实际承载生产业务。而灾备系统的建设又是一个成本和收益权衡的过程，根据业务需求合理配置资源，否则如果只是作为一个热备的灾备系统，没有承载实际的业务流量，过多的投入会增加建设成本。
2.2 容灾部署架构
在《金融数据中心容灾建设指引》中将容灾体系分为同城容灾、异地容灾和极端容灾，同城容灾是将同一城市中的2个数据中心形成“生产中心+同城中心”格局，也就是广义上的生产同城双中心概念；异地容灾选择一个异地的城市作为容灾中心对外提供连续服务，也就是广义上的异地灾备中心。对于容灾系统部署架构，指引中也给出了两种架构参考。
2.2.1 两地三中心架构
在两地三中心的架构中，生产同城双中心为双活的数据中心，同城站点会承载部分业务流量，而灾备中心多为热备架构，以在生产同城站点异常时具备可切换能力。这种架构在应用层实现多活，应用在多中心部署，无数据中心级单点故障，单中心应用异常时可以及时的进行流量切换；数据层同城实现同步保证RPO=0、异地异步复制，保证了同城站点数据不丢，多由数据库层实现高可用。异地灾备站点由于地理位置的特殊性，应用层从灾备站点访问回生产站点网络时延较大，不适合低时延高并发的业务系统。因此，在两地三中心部署架构中，生产同城双活中心支持服务级别的可切换能力，而异地灾备中心更多的是承担热备份的功能，会有少量的对时延不敏感的业务。
2.2.2 多地多中心架构
以三地六中心架构为例，在3个城市建设6个数据中心，每个城市分布2个同城双活数据中心，这种一般适合于大型金融机构，建设成本相对较高，对系统可用性达到极高的要求。在接入层根据地域、业务场景进行分流，比如京津冀地区、长三角、大亚湾地区等；应用层多地多中心部署，没有单点故障风险；数据库层在每个城市互为主备，实际上是在业务层做了数据拆分，这部分的读写业务数据在A站点、另一部分的读写业务数据在B站点。基于多地多中心的部署架构，能够最大限度的保障业务连续性，不会出现全局性的业务不可用的问题。
3、上云是最佳的解决方案吗？
随着金融行业向数字化转型深入，分布式、容器化、微服务等诸多新技术和新理念得到了广泛应用，云平台作为上述技术的基础底座成为金融行业应用系统的新型“数字生产力”，应用系统上云也成为了必然趋势。金融行业对云原生技术应用较早，从非核心业务系统逐步向核心业务系统拓展，逐步构建了支持全面云化/容器化的统一的云架构底座、多中心的容灾规划设计、大规模可扩展、一云多芯多池能力、安全合规以及资源敏捷弹性等关键规划和建设要素，以满足各类业务对基础设施的定义与适配。
结合金融机构的数据中心位置和资源部署特点，以及业务和监管对RPO/RTO的要求，规划了匹配业务场景的同城双活、两地三中心、多地多活等容灾方案。通过引入分布式应用架构和分布式数据架构，建设多活的应用系统平台，实现服务对等、高性能和高可用性。各中心同时对外提供服务，资源使用均衡，流量在不同中心之间快速切换。
应用系统和基础设施上云利用了云平台的基础底座能力，提供资源的统一管理和调度；分布式技术平台的服务和管理能力，提供标准化、组件化和服务化的接口；数据的单元化拆分和数据集成和流转设计，实现数据的关系网和血缘关系网格化；系统运维管理的一体化能力，提供统一视图、统一平台、统一流程和端到端的可观测能力。所以，未来金融机构的应用系统灾备建设过程中，全面云化将是灾备建设的最终目标，尤其是大中型的金融机构，将以两地三中心或多地多中心的云上部署架构为蓝本去打造数据中心。
总而言之，灾备建设要综合考量成本和收益，毕竟容灾系统的建设是以应用为维度结合关键的业务场景建设的，而不是说所有的系统都需要建立容灾环境。比如内部管理类应用，生产主站点故障了，并不会对实际的业务连续性造成影响。
以上是对灾备建设的一些思考，受限于个人理解，不当之处请指正。
参考资料：
金融数据中心容灾建设指引（JR/T 0264-2024）
现代化金融核心系统白皮书，FIFI，2024
