《金融数据中心容灾建设指引》发布，金融灾备建设如何进行？

近日，中国人民银行发布金融行业标准《金融数据中心容灾建设指引》（JR/T 0264—2024）（以下简称“《指引》”），并于当日实施。该标准提供了金融数据中心容灾建设中组织保障、需求分析、体系规划、建设要求、运维管理5个方面的指引。

作为国家经济发展的基石以及日常生活的坚强后盾，金融数据安全的重要性不言而喻。金融数据中心不仅承载着海量的数据与信息，更成为了国家经济命脉的守护者。然而，风险如同暗流，始终潜伏在数字化的深海之下，对金融数据的安全构成了严重威胁。因此，金融灾备建设显得尤为重要，它不仅是应对潜在风险的必要手段，更是确保金融数据中心能够持续、高效、无间断运行的关键所在。

具体来看，金融灾备建设的特点在于其全面性与前瞻性。它要求构建容灾体系时，不仅要考虑到当前的技术水平与业务需求，还要预见到未来可能面临的各种挑战与变化。通过科学合理的规划与布局，提供一套完整的、可操作的应急方案，确保在风险来临时，能够迅速、准确地做出反应，从而最大限度地保障金融数据中心的安全与稳定。

那金融行业灾备有何特点，建设又该如何进行？为回答这个问题，笔者找出之前发的一篇旧文，供各位参考。（以下内容为英方软件发布，内容略有删减）

金融行业分门别类繁多，不同领域的金融机构或相同机构的不同系统，根据等级保护的要求，RPO 与 RTO 的要求都不尽相同。但金融机构对数据零丢失和业务连续性要求高是冠绝全行业的，特别是银行和证券机构，丢失一个数字0，账面上的金额可能就是天壤之别。

为此，金融机构数据中心要满足《云计算技术金融应用规范 容灾》（JR/T 0168-2018）、《银行业信息系统灾难恢复管理规范》（JR/T 0044-2008）、《商业银行数据中心监管指引》、《云计算技术金融应用规范 容灾》（JR/T 0168-2020）、《银行保险机构应对突发事件金融服务管理办法》、《金融科技发展规划（2022-2025年）》等一系列合规性要求。

其中，以银行架构最为严格，它要求采用两地三中心或主备等多种模式构建灾备系统，在对各个数据中心的基础架构进行规划时，也要做好数据同步复制和数据中心双活的规划，通过裸光纤/DWDN 实现数据中心与各个营业网点的数据同步，同时同城数据中心应距离大于 50 公里，异地数据中心大于 300 公里，保障机房不会因为地震、洪水等区域性灾难受到全面的破坏，确保银行的数据不丢，业务不停。

除了银行，其他金融机构也会依据行业监管要求，构建自身的灾备系统，而金融机构的灾备应用场景也最为丰富。例如，从规模庞大的两地三中心、异地灾备、同城灾备、云灾备，到同机房内的双活、双机双柜、集群高可用、传统备份等场景，可以说是包罗万象。但是这也给运维带来极大挑战，以证券公司为例，各大券商的灾备中心的架构通常采用虚拟化技术，实现生产端物理机+虚拟机，灾备端以虚拟机为主的配置。

其中，生产端物理机和虚拟机存在两种形态：一种是应用和数据是前后端分离部署，如银行三方存管的中间件类型（无状态、无数据），数据存放在专用的数据库系统中；另一种是应用和数据一体化部署，数据在本机或以 SAN/NAS 等形式存储。证券生产中心当前主要以第一种前后端分离部署为主。

如果按照行业法规和监管要求，每增加一个生产系统，灾备中心就对应建立一个备份系统，那么灾备中心最终形成与生产环境主备 1:1 的资源配置策略。这就给运维人员带来极大挑战，据统计，一个中型券商的实际生产应用系统已超过 200 套，按照 1:1 的资源配置，灾备中心的备份系统就堆积成山，并由此带来一系列的运维管理问题。

例如，在备机普遍采用冷备、高可用和组等运营模式下，备机系统已经存在重复建设、冷备虚拟机使用率低，系统处于空转待命状态等问题，日积月累，就造成灾备中心的硬件设备、网络资源浪费严重。同时，根据行业监管的要求，运维人员要进行周期性应急演练确保备机系统的可用性，以保证应急时的业务连续性。

但是，传统的冷备方式，第一在资源上备机会占用跟生产系统一样的资源；第二在实际生产应急或者应急演练时，运维人员需进行一系列复杂操作进行紧急主备切换，此时备机是否可用，以及人为操作失误等问题都会影响整个应急过程以及业务连续性，且生产系统两三百套，其可用性验证如果通过手动操作，那是一个浩大的人力工程。

为此，基于云架构的智能云灾备中心，正在被更多的证券机构所关注，它要解决资源复用、系统备份与恢复、演练自动化、快速搭建测试/ UAT 环境等问题，实现灾备中心的智能运维，减轻运维人员的工作量。

其他的金融机构，也会面临上述问题，但是可能由于底层基础架构不同，所应对的系统规模不一样，而等级保护要求的不同，也会造成系统和数据灾备方案的千差万别。

我们综合分析银行、证券、保险、基金等主要金融机构，发现主要需求包括：

综上，金融机构灾备系统建设，是一项严格且浩大的技术工程，它涉及应用层、网络层和数据层的各种环境架构，因此它对供应商的产品性能、功能、兼容性以及技术服务团队都提出了非常高的要求。

金融机构不断变化的应用场景，将推动灾备技术方案进行持续地创新，这是新灾备方案区别于传统灾备方案的显著特征。但是，对于金融机构而言，业务系统和数据的保护，这个总体目标是不变的，只是业务系统的重要程度会发生变化，这也迫使运维人员重新规划灾备系统的建设方案。

为了解决系统复杂度问题，通常运维人员会先进行系统属性的划分。我们一般会将其划分为业务系统和非业务系统，根据这个属性和等级保护要求进行应用场景的识别和资源配置，并最终落地部署。下面，针对金融行业细分领域对安全等级的不同，以及不同客户生产环境存在的差异化，灾备解决方案也会有所不同，下面列举部分灾备方案系统供大家参考。

首先，银行两地三中心模式，是指有两个数据中心在同城作为生产中心机房，它们之间采用同步数据复制方式，两边数据中心完全一致。但是，由于两个数据中心距离会超过 50 公里，所以即使两边的网络采用了裸光纤/DWDN 的传输模式，还是会存在数据延时的情况，因此也不是距离越远越好，最好不要超过 100 公里，否则同步复制的延时可能超过上限的数值（一般 5 毫秒）时，可能导致数据库系统出现故障。

作为两地三中心的异地数据中心，与生产中心的距离一般超过 300 公里，目的是保障业务数据的多一份保障，为了节省成本，通常可以采用异步数据复制的方式来实现数据的同步。一般情况下，只有发生极端事件才会导致同城双活数据中心停止提供服务，所以异地灾备中心多半不作为关键应用宿主地，某些情况下是完全冷备，即使部分机构的异地灾备中心部署的应用，但通常不对外提供服务，所以用户不会访问到异地的点。原因是数据从生产级数据中心到异地灾备中心是异步数据复制，延时会比较大。相比于其他金融机构，银行在早期的基础架构规划时，就会将灾备作为必选项纳入到方案中，后期更多是以数据同步、数据库读写分离、虚拟机备份等建设为主。英方软件 i2COOPY 实时数据同步软件、i2Move 系统热迁移软件、i2Active 数据库同步软件，可以为用户提供数据实时同步复制和系统热迁移，且适合远距离、窄带宽、跨平台的环境；i2VP则可以提供无代理的虚拟机备份。

两地三中心架构

其次，部分大型银行会采用异地多活的模式，这是一种需要投入巨额费用的灾备模式，个别银行的某些关键应用已经在此模式下得到了验证。异地多活首先是要做到同城双活或者同城多活，就是数据在同城网络环境下进行高速同步。真正的异地多活需要多个跨地域的数据中心，距离达到 1000 公里以上，在这么远的距离下，对技术架构和网络传输是一个巨大的挑战。

智能云灾备中心是近来非常突出的创新方案，它通过在灾备端以虚拟化技术，实现存储和计算资源的池化管理，然后通过构建智能云（VMware）灾备平台，实现生产端物理机、虚拟机以 VMDK 文件备份到 VMware 平台。正常情况下，备份文件只占存储资源，不占用计算资源。当系统需要恢复时，可以通过 NFS 协议挂载瞬时恢复，然后通过虚拟机启动进行接管，为生产持续对外提供服务。

智能云灾备中心架构

它解决了传统备份中心在前后端分离部署的环境下，生产系统与备份系统 1:1 配置所带来的运维难题。同时它提供在隔离网络环境下，进行大规模备份系统可用性验证自动化的功能，以及帮助生产人员快速搭建测试或 UAT 环境，大大地降低了运维人员的工作量，实现了灾备中心资源复用和共享的目标。它通过基于 B/S 架构的管控平台，对灾备中心的设备、系统、状态、资源使用和运行情况做统一的量化管理和资源调配，实现灾备中心的智能化运维。

在智能云灾备中心的运行过程中，英方软件 i2FFO 全服务器备份可以实现物理机到虚拟文件的备份，i2VP 可以实现虚拟机到虚拟文件的备份，i2CDM 则通过块变化实时复制技术，将变化的数据实时同步到灾备中心，确保两边数据的一致性。

证券行情一般是指股票价格、涨跌幅、成交量、成交额、市盈率等股票行情。行情分发传输作为交易市场中的关键一环，直接关系到投资者获取市场信息的及时性、准确性和完整性。

信创行情分发与高可用架构