示范实践第2号—证券公司基于行业云的信息系统备份能力建设
示范实践第2号—证券公司基于行业云的信息系统备份能力建设
(2021年3月12日发布)
第一部分总体说明
1 前言
证券公司信息系统是证券公司的核心，也是各类业务运行的重要基础，为在信息系统发生故障、灾难或重大灾难时，有效保障业务的连续性，证券公司应严格遵循《证券基金经营机构信息技术管理办法》(以下简称《办法》)、《证券期货经营机构信息系统备份能力标准》(以下简称《标准》)等文件的要求，为自身的信息系统建立有效的备份能力。
《标准》规定，证券公司的信息系统备份能力包括数据备份能力、故障应对能力、灾难应对能力和重大灾难应对能力。其中，数据备份能力包括备份频率、保存方式和恢复验证等三个方面的要求，故障应对能力、灾难应对能力和重大灾难应对能力，包括恢复时间目标(RTO)、恢复点目标(RPO)和性能容量等三个方面的要求。
《标准》共定义了六个等级的备份能力，从低到高依次从第一级到第六级。其中，第一级为数据备份级，包括对数据备份的要求；第二、三、四级为故障应对级，包括对数据备份和对故障应对的要求；第五级为灾难应对级，包括对数据备份和对故障应对、灾难应对的要求；第六级为重大灾难应对级，包括对数据备份和对故障应对、灾难应对、重大灾难应对的要求。
《标准》对证券公司需要建设备份能力的重要信息系统的范围进行了明确界定，指出重要信息系统是指支持证券公司关键业务功能、如出现异常将对证券期货市场和投资者产生重大影响的信息系统，包括集中交易系统、投资交易系统、金融产品销售系统、估值核算系统、投资监督系统、份额登记系统、第三方存管系统、融资融券业务系统、网上交易系统、电话委托系统、移动终端交易系统、法人清算系统、具备开户交易或者客户资料修改功能的门户网站、承载投资咨询业务的系统、存放承销保荐业务工作底稿相关数据的系统、专业即时通信软件以及与上述信息系统具备类似功能的信息系统。
《办法》要求，证券公司应当确保备份系统与生产系统具备同等的处理能力，保持备份数据与原始数据的一致性。在上述重要信息系统中，在数据备份能力方面，实时信息系统、非实时信息系统均应当达到第一级；在故障应对能力方面，非实时信息系统应当达到第二级，实时信息系统应当达到第四级；在具备灾难及重大灾难应对能力方面，实时信息系统、非实时信息系统均应达到灾难应对能力第五级、重大灾难应对能力第六级；灾难应对能力可以通过重大灾难应对能力体现，但重大灾难应对能力相关技术指标应当达到灾难应对能力第五级。
对于证券公司而言，遵循《办法》与《标准》的要求，建设信息系统备份能力的工作，具有多种实施模式，包括两地两中心模式(主中心+异地灾备中心)、两地三中心模式(主中心+同城灾备中心+异地灾备中心)等。证券公司可根据自己的实际情况，选择符合自身实际的模式，以达到《办法》与《标准》的要求，从而确保信息系统具备足够的应对故障、灾难或重大灾难的能力，为业务的连续性提供有效保障。
本文所收录的山西证券、东吴证券、南京证券三家公司的备份能力建设工作实施案例，在严格遵守《办法》与《标准》的前提下，在方案设计上采用了相同的思路，具有以下特点：
·以行业核心机构的云平台作为备份能力的承载平台；
·采用两地两中心模式(主中心+异地灾备中心)；
·灾难应对能力通过重大灾难应对能力体现，且重大灾难应对能力相关技术指标达到了灾难应对能力第五级标准；
·备份系统与生产系统具备同等的处理能力；
·基于可行性、安全性等方面的考虑，根据信息系统的重要性，制定了分布建设的实施策略。
这种模式的优点在于总体结构较为简单，建设速度较快，切换策略明确，并且可以借助行业核心机构的力量，保证备份能力所依托基础环境的安全可靠。但由于灾难应对能力通过重大灾难应对能力来体现，因此对于远程数据同步和切换操作等方面的规划，都具有较高的要求。
符合规范要求的备份能力建设方案，并不局限于上述这种模式。各证券公司可以根据自身业务规模、系统复杂度、现有备份能力实现状况等实际情况制定合规、科学、完整、可行的方案，以保证自身信息系统的备份能力严格符合《办法》与《标准》的规定。协会信息技术委员会将密切关注行业推进此项工作的指导性意见及具体情况，不断推荐更多的案例，以促进全行业的信息系统备份能力合法、合规、合理地达到规范要求。
2 项目背景
2.1 项目目标
证券公司为保证各类业务运行的连续性，必须做好信息系统备份能力的规划及建设工作。信息系统备份能力的规划建设，需要综合考虑建设模式、机房选址、系统覆盖范围及处理能力、建设及后期维护成本等各方面因素，以满足行业相关规范要求，保障业务连续性，有效降低故障、灾难及重大灾难给证券公司造成的损失及影响。
(1)行业监管要求
根据《证券基金经营机构信息技术管理办法》(以下简称《办法》)要求，重要信息系统应当具备灾难及重大灾难应对能力，确保在发生故障后，有较快的系统恢复能力，并尽量减少丢失数据。重要系统分类如下：
| 系统分类 | 重要信息系统 |
| 实时信息系统 | 集中交易系统、第三方存管系统、内存交易系统、QFⅡ交易系统、股转做市商系统、期权交易系统、场外市场交易系统、PB业务交易系统、账户管理系统、非现场开户系统、网上业务办理系统、移动终端业务办理系统、投资交易系统、短信系统、网上交易系统、手机证券系统、呼叫中心系统、融资融券系统等 |
| 非实时信息系统 | 估值核算系统、法人清算系统、财富管理系统、私募基金托管外包系统、私募基金法人清算系统、投行业务管理系统、资管份额登记系统等 |
《办法》要求实时信息系统的故障应对能力应达到四级，非实时信息系统的故障应对能力应达到二级，所有信息系统的灾难应对能力应达到五级，重大灾难应对能力应达到六级。
(2)灾备系统建设标准
异地灾备中心应提供与主生产数据中心同等处理能力，灾备环境能完全承受生产切换时的所有业务负载，以确保实施灾备切换后，业务能依托异地灾备中心正常运行。
同等能力指异地灾备中心所部署的所有系统，其性能指标(如TPS、响应时间等)具有与生产环境同等的水平。同等处理能力不要求异地灾备中心具备与主生产数据中心完全一致的物理设备和系统架构。如果具备弹性条件，异地灾备中心可以在日常运行时采用最小资源运行模式，当实施灾备切换时，可在RTO时间内迅速完成资源弹性扩容，以达到同等能力处理要求。
异地灾备中心系统建设参照《证券期货经营机构信息系统备份能力标准》及《信息安全技术信息系统灾难恢复规范GB/T 20988—2007》。
2.2 应急切换组织
证券公司应制定《信息安全事件应急处置流程》等制度，保证事件发生时公司能够快速响应，妥善应对，尽快恢复信息系统，降低信息安全事件对业务的影响，保障业务持续对外服务和运营。
2.3 覆盖范围
建议异地灾备中心的应用系统建设分三期进行，并以确保经纪业务(特别是零售业务)的连续性为一期建设目标，逐步积累云环境下异地灾备系统的建设和运维经验，待条件成熟后再逐步扩大系统范围，分期建设涉及的系统清单建议如下：
| 批次 | 类别 | 系统实例 |
| 一期 | 实时信息系统中涉及核心业务的系统 | 集中交易系统、PC网上交易系统、APP手机交易系统、行情及资讯系统、结算系统、账户管理系统、非现场开户系统等 |
| 二期 | 实时信息系统中涉及其他业务的系统 | PB系统、自营交易系统等 |
| 三期 | 非实时信息系统 | 估值系统、托管及外包系统、TA系统等 |
3 总体技术方案
3.1 基础平台概述
证券公司异地灾备中心需要与主中心、分支机构，以及交易所、证联网、基金公司等外部机构间建立通讯线路，实现互联，中心间互联关系图如下：
3.2 网络架构与通信
(1)网络功能分区
按照业务的重要程度、业务的特点及类别、业务的等级保护要求，宜将异地灾备中心的网络分成多个功能区域，部分功能区域之间实现安全隔离，区域建设建议如下：
| 分区 | 说明 |
| 网络总线区 | 通过交换核心实现各区域之间的互连，保障交换核心高可用和高性能对整个数据中心网络至关重要。 |
| 核心交易区 | 与其他网络功能区域之间通过安全措施进行物理隔离，主要部署核心交易系统，承载核心交易业务，业务网络和组播网络宜独立部署。 |
| 核心业务区 | 提供服务器的接入以及负载均衡、防火墙安全隔离等功能。采用标准化架构设计、网络资源池化的方式，实现服务器的灵活接入；通过网络设备虚拟化，打破相互物理隔离的架构限制，最大限度的提供灵活性。核心业务区承载无等保要求的业务，可以由多个三层网络域组成，各个不同三层网络域之间无安全措施。 |
| 内联区 | 与网络系统的运维处于自主可控的机构进行互联的功能区域，包括分支机构、主数据中心、同城灾备数据中心、其他存在互联需求的站点等。 |
| 外联区 | 提供外联相关应用的前置服务器接入，及服务器分别到数据中心内部和外联单位的连接和安全控制。同时提供外联单位的线路接入，并提供外联区DMZ服务器与外联单位服务器的数据交互。该网络区域提供与交易所、证联网、登记公司、基金公司、银行等外部机构的互联通信。 |
| DMZ区 | 提供外联互联网、内联核心业务区的网络缓冲区域，该区域服务器采用双网卡设计，内网网卡连接到其他网络功能区域，实现互联，外网网卡连接互联网，实现应用对互联网发布以及应用访问互联网。该区域与其他网络功能区域互联时采用安全措施进行隔离。 |
| 网络管理区 | 独立于业务区域，提供网络运维相关系统的服务器的接入的网络区域。 |
| 测试区 | 如需要，可规划建设专用的开发测试环境，提供开发测试相关设备的接入，避免风险传导。该区域为可选网络区域。 |
(2)通讯线路
根据业务需求和系统部署要求，与内联机构和外联机构之间采用数据专线或VPN的通信方式。采用双线路冗余设计时，可采用不同运营商的数据专线或数据专线和不同运营商VPN的方式实现互备。
为降低通讯成本，可在外联单位或内联单位较为聚集的城市设立专门的通信中转点，由该站点实现与异地灾备中心的通信。下表给出了异地灾备中心主要通讯线路的建议。
| 类别 | 用途 | 起点 | 终点 |
| 内联 | 数据同步 | 主中心 | 异地灾备中心 |
| 内联 | 业务办理 | 异地灾备中心 | 分支机构 |
| 外联 | 行情转发 | 异地灾备中心 | 沪深交易所行情源 |
| 外联 | 中登业务 | 异地灾备中心 | 中登 |
| 外联 | 三方存管 | 异地灾备中心 | 证联网接入 |
| 外联 | 上交所报盘 | 异地灾备中心 | 上交所 |
| 外联 | 深交所报盘 | 异地灾备中心 | 深交所 |
3.3 云平台系统性风险防范
当券商采用租赁可信机构云服务的方式构建异地备份能力时，其异地备份的可靠性高度依赖于云平台自身的安全性与连续工作能力。因此云平台的供应商，应采取多种措施，防范因云平台故障给券商造成系统性风险。以两家行业核心机构(上交所技术、深证通)为例，作为向行业提供云平台服务的供应商，两家公司在云平台的规划、部署与管理等各层面，对此均有较为完善的考虑。
3.3.1 多数据中心部署
两家核心机构均采用多数据中心部署的模式，以避免单一中心造成的风险集中；每个数据中心不仅具有T3+的高建设级别，而且均配备有经验丰富的运行管理团队，以保障运行安全。
3.3.2 云平台安全体系
两家核心机构均从物理安全、基础平台安全、虚拟数据中心安全、内部网络隔离安全、边际网络防护安全以及运维安全等六个方面，构建了较为完善的安全体系，对云平台进行安全保障。
(1)物理安全
物理数据中心具有T3+及以上级别，并且建立了严格的管理制度，对人员出入、值班、监控、入侵监测等方面进行全面管理。
(2)基础平台安全
云平台软硬件部署采用全冗余、多活的集群架构，服务器和网络设备无单点故障；通过高可用的平台架构和软件定义网络架构，有效降低平台的运营风险，保障平台的安全稳定运行
(3)虚拟数据中心安全
云平台支持虚拟网络，用户可自定义网络，部署第三方安全设施，并将流量导向安全设施；用户可在其虚拟网络内部署堡垒机，以及防火墙、IPS、WAF等安全设施，进行自主控制。
(4)内部网络隔离安全
云平台内部采用VRF等技术手段有效隔离租户的虚拟网络，基础设施平台内部各节点间使用有效技术手段封装，隔离平台侧和租户侧的虚拟网络流量；基础设施互联网络部署BGP VPN，以隔离网络流量；云平台与外部网络之间部署防火墙及软件定义的IPS和WAF等安全措施。
(5)边际网络防护安全
云平台用户灾备数据中心与用户生产数据中心之间部署防火墙，以实现区域间安全隔离；云平台互联网出口部署防火墙及IPS、WAF、流量清洗平台，以提供互联网防DDOS攻击服务、安全防护和WEB应用防护。
(6)运维安全
云平台用户通过专线或SSL VPN接入运维，登录过程中采用双因子认证，运维操作通过堡垒机，堡垒机记录运维人员全部操作。
3.3.3 云平台应急保障
两家核心机构的云平台均制定有电力、空调、网络、主机等各种故障的应急保障方案，每年在非交易时间内，模拟各种故障情况，按照应急保障方案进行应急演练，并根据演练情况，及时升级应急方案。
3.4 系统维护责任边界的划分
云平台供应方(上交所技术、深证通等核心机构)提供异地灾备系统部署所需要的基础资源，负责保障基础资源平台的安全稳定运行和网络接入，券商负责保障灾备应用系统的稳定运行，具体分工见下表。
| 职责 | 内容 | 责任方 |
| 基础资源平台保障 | 提供计算、存储、网络、外联线路等基础资源，保障基础资源平台稳定运行；保障基础资源平台层面系统安全、数据安全；机房环境、硬件设备、基础网络的管理、定时检查和监控、异常和故障处理 | 云平台供应方(核心机构) |
| 软件运维 | 操作系统、数据库、中间件、业务应用等软件的日常规定项目的定时检查和监控、系统定期全面巡检、异常和故障处理；系统初始化流程、数据备份和恢复、数据和文件处理及传送等 | 券商 |
3.5 项目一期系统及设备配置
根据项目覆盖范围的规划，异地灾备中心项目一期建议以实时信息系统中涉及核心业务的系统为主。
系统部署需具备有效可行的弹性扩展方案，并制定针对弹性扩展的镜像制作、镜像更新、测试管理及应急启动的管理制度和操作流程。
3.5.1 集中交易系统
(1)部署参考示意图
集中交易系统主要包括交易管理、证券申报回报、银证申报回报、行情处理、接入管理等系统模块，部署示意如下图。
(2)程序清单、设备清单及配置参考示例
| 程序清单 | 资源配置 | 操作系统 | 初始安装台数 | 配置参数 |
| 外部接入 | 4C/16G/200G | REDHAT AS6.8 | 2 | |
| 行情处理 | 16C/32G/200G | WINDOWS 2008 | 2 | |
| 银证申报回报 | 8C/16G/200G | WINDOWS 2008 | 4 | |
| 证券申报回报 | 16C/32G/200G | WINDOWS 2008 | 6 | |
| 统一接入 | 16C/32G/200G | REDHAT AS6.8 | 2 | |
| 业务处理 | 16C/32G/200G | REDHAT AS6.8 | 10 | |
| 数据库 | 32C/256G/1T SSD | REDHAT AS6.10 | 6 |
3.5.2 网上交易及手机接入服务
(1)部署参考示意图
网上交易及手机接入服务主要包括委托主站和委托接口等系统，部署示意图如下：
(2)程序清单、设备清单及配置参考示例
| 程序清单 | 资源配置 | 操作系统 | 初始安装台数 | 配置参数 |
| 委托主站 | 32C/32G/300G | Centos 7.3 | 2 | |
| 委托接口 | 32C/32G/300G | Centos 7.3 | 2 | |
| 委托认证网关 | 32C/32G/300G | Centos 7.3 | 2 |
3.5.3 行情资讯系统
(1)部署参考示意图
行情资讯系统主要包括资讯主站、行情主站、数据转发等系统，部署示意图如下：
(2)程序清单、设备清单及配置参考示例
| 程序清单 | 资源配置 | 操作系统 | 初始安装台数 | 配置参数 |
| 行情接收 | 32C/32G/1T | Centos 7.3 | 2 | |
| 行情发送 | 16C/16G/1T | Centos 7.3 | 2 | |
| 行情主站 | 16C/16G/1T | Centos 7.3 | 2 | |
| 资讯接收 | 16C/16G/1T | Centos 7.3 | 2 | |
| 资讯发送 | 8C/16G /1T | Centos 7.3 | 2 | |
| 资讯主站 | 8C/16G /1T | Centos 7.3 | 2 | |
| 监控系统 | 8C/16G /1T | Centos 7.3 | 2 |
3.5.4 外部接口服务
(1)部署参考示意图
外部接口服务是指由外部接入程序组成的支持交易、行情、清算等相关业务的接入服务， 有沪深报盘、沪深行情、沪深登记公司、深证通等业务类型，部署示意图如下：
(2)程序清单、设备清单及配置参考示例
| 业务类型 | 程序名称 | 资源配置 | 操作系统 | 初始安装台数 | 配置方参数 |
| 沪市报盘 | EzOES | 4C/8G/160G | Windows2012 | 2 | SystemConfiguration.ini(链路、PBU) |
| EzStep | 4C/8G/160G | Windows2012 | 2 | ezstepuser.ini(链路、PBU) | |
| EzDA | 4C/8G/160G | Windows2012 | 2 | fisp_interf.ini(链路、用户) | |
| RptGet | 4C/8G/160G | Windows2012 | 2 | RptGet.ini(链路、用户) | |
| EzTrans | 4C/8G/160G | Windows2012 | 2 | EzTransUser.ini(链路、用户) | |
| 云盘 | 4C/8G/160G | Windows2012 | 2 | application-config.yml(链路) | |
| 深市报盘 | TGW | 4C/8G/160G | Windows2012 | 2 | config.xml(链路、网关) |
| 股转交易网关 | 4C/8G/160G | Windows2012 | 2 | tw.ini(链路、用户) | |
| B转H交易网关 | 4C/8G/160G | Windows2012 | 2 | hgjy.ini(链路、用户) | |
| 沪市行情 | UT5 | 4C/8G/160G | Windows2008 | 2 | utconfig.xml(链路) |
| EzSR | 4C/8G/160G | Windows2008 | 2 | EzSRUser.ini(链路) | |
| Mdgw_上海 | 4C/8G/160G | Windows2008 | 2 | config.xml(链路) | |
| 深市行情 | Mdgw | 4C/8G/160G | Windows2008 | 2 | config.xml(链路) |
| Fxclient | 4C/8G/160G | Windows2008 | 2 | fxclient.ini(链路) | |
| 股转行情网关 | 4C/8G/160G | Windows2008 | 2 | NQClient.cfg(链路) | |
| B转H行情网关 | 4C/8G/160G | Windows2008 | 2 | 同股转 | |
| 开放式基金小站 | 4C/8G/160G | Windows2008 | 2 | JIJIN.ini(链路、用户) | |
| 上海登记公司 | PROP | 4C/8G/160G | Windows2008 | 2 | gateaddr.conf(链路、用户) |
| 深圳登记公司 | DCOM | 4C/8G/160G | Windows2008 | 2 | DCOMConfig.Cfg(链路、用户) |
| CCNET | 4C/8G/160G | Windows2008 | 2 | 同DCOM配置。 | |
| 深证通 | FDEP消息传输 | 4C/8G/160G | Windows2008 | 2 | mr.ini(链路、用户) |
| FDEP文件传输 | 4C/8G/160G | Windows2008 | 2 | 同Fxclient |
3.5.5 清算结算系统
(1)部署参考示意图
清算结算类系统主要包括法人清算管理、资金结算管理、结算文件管理和银企划付/网银等模块。银企划付负责资金交收的银行资金划拨，可使用银行网银替代。结算文件管理负责对交易所、登记公司、基金公司等外部机构发送的结算数据进行管理清分，提供给各交易系统、清算系统进行结算处理。法人清算管理进行法人清算处理并负责与交易系统清算结果核对。资金结算管理负责各类交收资金的核对及收付款管理。此外，还要计划数据存储方案，负责对结算过程中产生的数据进行保存。部署示意图如下：
(2)程序清单、设备清单及配置参考示例
| 程序清单 | 资源配置 | 操作系统 | 初始安装台数 | 配置参数 |
| 结算文件管理中间件 | 16C/64G/1T | WINDOWS 2008 R2 | 1 | |
| 结算文件管理数据库 | 32C/128G/1T | REDHAT AS6.8 | 1 | |
| 法人清算中间件 | 16C/64G/1T | WINDOWS 2008 R2 | 1 | |
| 法人清算数据库 | 32C/128G/1T | REDHAT AS6.8 | 1 | |
| 资金结算管理中间件 | 8C/16G/200G | WINDOWS 2008 R2 | 1 | |
| 资金结算数据库 | 16C/32G/500G | REDHAT AS6.8 | 1 | |
| 银企划付 | 4C/8G/200G | WINDOWS 2008 R2 | 2 |
3.6 系统安全策略
异地灾备中心在系统安全基础设施层应标准化提供服务并开展运营，例如提供统一的Windows补丁源，统一的NTP服务器。由使用方选择使用并开展个性化配置，例如选择性屏蔽相关补丁。另一类服务属于“可配置服务”。例如防病毒软件、日志服务。由于应用和数据敏感性的差异，每个租户的配置都有差异，应提供基础性服务并提供个性化配置页面。日志服务应避免收集用户应用层日志，仅当用户授权时，方可采集相关日志。应具备DDOS预警及基本防御能力，当大规模DDOS攻击时，应具备应急方案。异地灾备中心的态势感知能力、安全基线均属于可选项目。用户可根据其需求进行选择。
(1)网络时钟授时服务
按照《证券期货业网络时钟授时规范》JR/T 0084—2012，证券公司实时系统应采用网络授时服务进行对时，向云服务商明确其网络授时服务的基本要求：
时间来源可以为以下类型：
ü 自守时时钟(如铷钟)；
ü 北斗卫星系统授时服务；
ü 国家授时中心长短波授时服务(长波授时信号简称BPL，短波授时信号简称BPM)；
ü 其它时钟源服务商提供的授时服务(如GPS)；
ü 如交易所许可，且网络条件支持，可采用交易所提供的网络时钟授时服务。
云服务商提供的网络时钟授时精度应达到100毫秒以内。证券公司在使用网络授时服务时，应注意以下技术要求：
ü 证券公司应根据实时系统的特点，将系统分为可以实时同步的系统和不可实时同步的系统，按照分类，分别设计时间同步周期，满足行业规范的累积延迟要求；
ü 证券公司应对实时系统的时间进行持续监控，出现时钟不准确等现象时，及时生成告警；
ü 证券公司应充分考虑时钟校正可能发生的情况及规避措施。
(2)操作系统补丁升级服务
证券公司应建立操作系统补丁升级规范，在充分评估的基础上，使用云服务商提供的补丁发布服务，及时补丁升级，加固系统。
证券公司应建立操作系统重大补丁应急响应机制，对重大补丁，指定专人组织补丁升级活动。
证券公司应使用云服务商提供的补丁更新统计数据，对补丁是否及时更新进行审计。
异地灾备中心补丁升级服务示意图如下：
(3)防病毒服务
证券公司应建立基于“主动防御”思路的防病毒技术体系。充分使用云服务商提供的安全防护工具和服务，建立防病毒响应机制。防病毒技术体系如下图所示。具体包括：
ü 防火墙：基于白名单策略，仅允许必要的端口访问。
ü 漏洞入侵防护：基于云服务商或其他渠道获取的安全情报，针对公布的漏洞，按计划快速进行漏洞防护方案的实施。
ü 终端加固：按照《证券期货业信息系统安全等级保护测评要求》JR/T 0067—2011主机安全评测要求进行建立安全基线，进行终端安全加固。
ü 防病毒扫描：定期对操作系统进行全面病毒扫描；基于已知病毒特征，利用传统病毒防护技术，具备对已知病毒的主动查杀，隔离，恢复能力。
防病毒技术体系如下图所示。
(4)虚拟主机防火墙
通过SDN和NFV技术对虚拟主机的流量进行牵引，实现租户内部虚拟网络中虚拟主机的访问控制，为每个虚拟主机定义访问规则和访问策略，切断病毒、木马等攻击行为在虚拟主机之间的蔓延和传播，避免利用已经攻陷的虚拟主机作为跳板攻击其他的虚拟主机。虚拟主机防火墙提升了虚拟网络中虚拟主机的访问控制，实现虚拟网络内部的精细化访问控制管理，加大被攻击的成本。
(5)抗DDoS
DDoS高防IP是针对互联网服务器在遭受大流量的DDoS攻击后导致服务不可用的情况下，推出的付费增值服务，租户可以通过配置高防IP，将攻击流量引流到高防IP，确保源站的稳定可靠。
(6)虚拟主机入侵检测
深证云为每个虚拟主机定制入侵检测防护措施，通过检测虚拟主机的访问流量，发现来自内外部针对虚拟主机的网络攻击行为，并对包含有恶意攻击行为的网络流量进行过滤，提升租户每个虚拟主机的安全防护能力。
3.7 数据同步策略
数据同步技术是异地灾备中心建设的核心技术，通过将生产业务系统中产生的数据，实时同步到异地灾备中心，从而在出现生产系统故障、灾难、或重大灾难时，保证业务连续性，是异地灾备中心建设的主要技术组成，数据同步的可靠性、延时等指标，会直接影响异地灾备中心建设的RTO及RPO。
数据同步技术可分为基于存储的数据同步技术、基于主机的数据同步技术和基于应用层的数据同步技术。基于存储和基于主机层的数据同步技术与应用无关，其优点是数据复制准确、可靠，缺点是不能保证上层应用IO的事务性。基于应用的数据同步技术是与应用强相关的数据同步技术的统称，包括应用层的双写(如图像视频文件等)，以及数据库之间的数据同步等，其优点是可根据IO操作的事务性在生产及异地灾备中心执行或回滚事务，不会产生因IO不一致导致的脏数据或应用系统及数据库无法启动等问题，缺点是由于数据同步技术与应用系统紧密相关，对数据同步的技术要求较高，因此可靠性是比较大的挑战。
数据同步技术还可分为同步和异步两种，同步主要适用于对业务系统IO相应要求较低、主备距离较短的情景。异步主要适用于业务系统IO要求较高的场景。由于同步会较大的牺牲生产环境业务系统的IO响应和吞吐，异步数据同步技术被应用于大多数场景。此外数据同步技术的选型考虑因素还有可靠性、延时、带宽消耗、异地灾备中心是否可读写、配置是否灵活等因素。异地灾备中心的应用场景，主要关注可靠性、延时、备库是否可读写等要素；对于跨云或云上云下部署场景，带宽资源比较宝贵，则还需重点考虑带宽消耗因素。综合而言，主中心与异地灾备中心之间的数据同步，以异步方式更为合理。
3.8 日常运维监控策略
(1)日常监控策略
为了保障日常灾备数据中心的正常运转，灾备数据中心内应建立等同生产数据中心的日常监控体系，并可独立运行。
灾备环境应至少具备网络监控、主机监控、进程监控、端口监控、日志监控、数据复制监控，以实时掌握异地灾备中心的基础运维环境、系统运行状况、数据复制时延，为灾备应急切换决策提供依据。灾备环境切换接管后，需具备必要的业务监控及告警能力，为正常业务运行提供必要的监控保障，保障业务的正常开展。
监控指标可分为网络及网络设备、服务器及操作系统、中间件和数据库、应用系统、业务逻辑等5个层级，监控指标主要有CPU/内存使用率，网络、存储IO流量、进程与端口可用性、数据库的性能、业务成功率等。灾备环境日常运行时，监控系统一般监控网络及网络设备、服务器及操作系统、中间件和数据库、应用系统等4个层级的指标。当发生灾难时，监控所有5个层级的指标。
(2)灾备切换方案
券商在生产中心和异地灾备中心各部署一套监控系统，并采用关联运行和独立运行两种模式。
关联运行模式下，日常生产时，生产中心的监控系统同时采集生产中心和异地灾备中心内监控对象的信息，券商通过DNS访问该系统，以实现对应用系统的监控。生产中心的监控系统定时将监控数据同步至异地灾备中心的监控系统中，同步频率依据监控系统的RPO进行设置，券商在灾备中心部署与监控告警相关的信息发送渠道(如短信网关、邮件网关等)。灾难发生时，先启动灾备中心的监控系统进行数据采集，再调整灾备中心内备用DNS的监控系统IP设置，指向灾备系统。实际切换时应注意操作风险，并在操作完成后及时验证。注意监控数据的同步频率不可设置得过于频繁，以免影响生产数据库性能；在启动监控服务前，应先检查各内部服务间的访问关系，并注意避免因网络隔离造成无法访问。
独立运行模式下，券商在生产中心和和异地灾备中心分别独立部署监控系统，各自独立运行，分别对主备中心进行监控，灾备切换时无需切换监控系统。
4 业务连续性管理
4.1 异地灾备中心管理
4.1.1 人员管理
(1)人员要求
按照《证券基金经营机构信息技术管理办法》第四十三条的规定(“证券基金经营机构借助信息技术手段从事证券基金业务活动的，可以委托信息技术服务机构提供产品或服务，但证券基金经营机构依法应当承担的责任不因委托而免除或减轻。证券基金经营机构应当清晰、准确、完整的掌握重要信息系统的技术架构、业务逻辑和操作流程等内容，确保重要信息系统运行始终处于自身控制范围。除法律法规及中国证监会另有规定外，不得将重要信息系统的运维、日常安全管理交由信息技术服务机构独立实施”)，证券公司应在异地灾备中心设置主管或项目经理，主导异地灾备中心的规划、建设、日常运维等工作，不得由信息技术服务机构独立实施。
(2)外部服务机构人员管理
外部服务机构人员(下称驻场人员)入场前经过审批并签署保密协议，涉及重要信息系统的驻场人员，需进行相关技术背景调查和能力评估。
驻场人员笔记本电脑等个人设备必须安装杀毒软件，入网前需经批准。
驻场人员应严格遵守证券公司安全管理制度，严格按照规范化的日常操作流程操作，严禁进行未经批准的操作。
驻场人员需对日常操作记录日志，日志填写应准确、及时、详细，随时可供安全人员检查和审计。
驻场人员需要远程诊断和调试信息设备需经网络管理员和系统管理员批准，并且在维护结束后立即收回权限。
驻场人员提供运维服务过程中接收、获得或了解的关于证券公司及关联公司的任何数据，不得违规收集、存储、使用、泄露，一经查出将追究当事人及外部服务机构的责任。
(3)工作职责边界
可信机构云服务提供商负责园区管理和机房管理，保障机房环境物理安全，内容包括：园区安防，机房访问控制，风火水电防护及保障，温度控制和设备安全等措施。
云平台的建设及日常运维，涉及证券公司、云平台供应方(上交所技术、深证通等核心机构)及外部服务机构，对三方各阶段工作边界和职责提出以下建议：
建设阶段 | ||||
| 项目 | 工作分项 | 规划职责 | 实施职责 | 验收/使用职责 |
| 基础环境 | 云平台基础环境 | 云平台服务商 | 云平台服务商 | 云平台服务商 |
| 云平台扩容 | 云平台服务商 | 云平台服务商 | 云平台服务商 | |
| 云平台备份 | 云平台服务商 | 云平台服务商 | 云平台服务商 | |
| 主机操作系统 | 证券公司 | 证券公司 | 证券公司 | |
| 主机补丁 | 证券公司 | 证券公司 | 证券公司 | |
| 应用软件 | 系统部署 | 证券公司 | 外部服务机构 | 证券公司 |
| 系统功能测试 | 证券公司 | 外部服务机构证券公司 | 证券公司 | |
| 系统性能测试 | 证券公司 | 外部服务机构证券公司 | 证券公司 | |
| 系统上线 | 证券公司 | 证券公司 | 证券公司 | |
| 网络安全 | 主机安全基线 | 证券公司 | 证券公司 | 证券公司 |
| 主机防病毒 | 证券公司 | 证券公司 | 证券公司 | |
| 入侵监控(HIDS) | 云平台服务商 | 云平台服务商 | 证券公司 | |
| 云防火墙 | 云平台服务商 | 云平台服务商 | 证券公司 | |
| 安全审计 | 云平台服务商 | 云平台服务商 | 证券公司 | |
| WAF | 云平台服务商 | 云平台服务商 | 证券公司 | |
| KMS | 云平台服务商 | 云平台服务商 | 证券公司 | |
日常运维阶段 | ||||
| 项目 | 工作分项 | 规划职责 | 实施职责 | 协助/验收职责 |
| 基础环境 | 云平台基础环境持续优化 | 云平台服务商 | 云平台服务商 | 证券公司 |
| 云平台容量监控 | 云平台服务商 | 云平台服务商 | 证券公司 | |
| 云平台运行监控 | 云平台服务商 | 云平台服务商 | 证券公司 | |
| 云平台升级变更 | 云平台服务商 | 云平台服务商 | 证券公司 | |
| 主机运行监控 | 证券公司 | 证券公司 | 证券公司 | |
| 应用软件 | 应用系统升级 | 证券公司 | 证券公司外部服务机构 | 证券公司 |
| 应用系统升级功能测试 | 证券公司 | 证券公司外部服务机构 | 证券公司 | |
| 系统性能测试 | 证券公司 | 证券公司外部服务机构 | 证券公司 | |
| 镜像制作 | 证券公司 | 证券公司外部服务机构 | 证券公司 | |
| 网络安全 | 防病毒监控 | 证券公司 | 证券公司 | 证券公司 |
| 入侵日常监控 | 证券公司 | 证券公司 | 证券公司 | |
| 云防火墙监控 | 证券公司 | 证券公司 | 证券公司 | |
| 安全审计监控 | 证券公司 | 证券公司 | 证券公司 | |
| WAF监控 | 证券公司 | 证券公司 | 证券公司 | |
| KMS监控 | 证券公司 | 证券公司 | 证券公司 | |
4.1.2 值班管理
(1)值班制度
异地灾备中心应指定运维主管，专人负责日常运维部署、检查、风险控制、业务衔接等工作。
异地灾备中心应实行值班制度，规定值班要求和工作流程。值班操作实行双人作业制度，并形成详细的操作记录。
应设置运维值班电话。
(2)值班资格
值班人员应经过培训合格后上岗，培训应包含基本的运维流程规范、应用系统、信息安全等必备技能和要求。
定期针对不同专业开展专项培训工作，提升运维管理能力水平，确保运维管理工作的质量。
(3)值班管理
异地灾备中心运维涉及的文档管理、保密管理、信息安全管理等要求遵循证券公司统一的规范执行。
运维主管应定期和不定期对相关制度的执行情况进行检查。
4.1.3 办公场所管理
办公场所是员工进行值班检查、应用升级测试、数据库维护、应急切换等工作的场所，异地灾备中心整体规划包括办公场所选址和日常管理等内容。
(1)办公场所选址
异地灾备中心办公场所的电力、空调、消防、通信等基础设施符合行业信息安全管理的有关要求，确保在主中心灾难情形下可用。从建设成本和技术保障等因素考虑，与异地灾备中心就近选址。
(2)办公场所日常管理
在办公场所配备监控大屏、堡垒机、摄像头、传真机等设施设备，部署运维监控系统，为异地灾备系统的日常运维管理提供必要的工作条件。
制定管理制度，保证正常办公秩序，确保人员和信息安全。
4.1.4 网络安全管理
在网络安全管理方面，异地灾备中心应统一开展网络安全等级保护工作。该项工作并不能替代异地灾备中心相关应用的网络安全等级保护工作，仅在测评时部分领域可以引用异地灾备中心主体的测评结果。
在开展网络安全检测时应针对异地灾备中心承载的相关资源开展检测，发现问题后需通知应用方。信息系统的安全策略、管理规范应以网络安全法及网络安全等级保护条例为基础。
4.2 变更与发布管理
4.2.1 变更来源
变更来源主要来自于两种：一种是主动变更，即因程序升级、配置变化、硬件部署结构发生变化所引发的变更；二是因外部市场环境发生变化所引发的被动变更。证券公司监控市场和业务的变化，及时制定主系统和灾备系统的变更预案。
灾备环境的升级更新应与生产环境保持同步，并制定升级管理规范，明确初期部署部分、弹性扩展部分的升级操作步骤，并在升级后进行必要的验证测试，以保证灾备环境的可用性。
4.2.2 异地灾备中心变更管理要求
(1)变更策略制定
该制度属于变更的纲领性文件，变更策略包括但不限于变更分类和分级标准，变更前的测试要求和相关方的沟通要求。服务新增或变更要求的落实应参照变更管理执行。对紧急和重大变更的授权和实施，应建立独立的策略和管理要求。
(2)变更受理与评估
所有变更都应被记录，评估变更的影响、风险和需要的资源。
(3)变更方案制定
应制定变更实施方案、实施变更发布计划，明确相关的部署和操作任务；应全程推进、协调变更的实施，并制定变更验证方案；应更新配置项信息，并根据需要更新操作手册、实施必要培训；应制定变更回退方案或应急措施。
(4)变更发布
须明确变更发布实施人员并对其授权；根据变更发布计划，跟踪发布进展；当发布过程中发现故障，应及时根据变更发布操作手册实施回退操作；应对发布进行总结和回顾，确认发布成功并反馈。
(5)变更验证
应根据变更验证方案对变更发布结果进行验证，进行变更点的专项功能验证；在大版本发布或外部环境发生重大变化时，应进行全量回归验证测试，确保灾备系统的可用性。
(6)变更回顾与关闭
应回顾变更实施的过程和结果，明确变更关闭规则。
4.3 系统备份管理
异地灾备中心按照行业要求和业务开展实际情况设计系统处理能力，满足业务连续性要求。
运行的各类系统按照《证券期货经营机构信息系统备份能力标准》制定不同等级的数据备份方案，在本地和异地分别保存系统数据，以确保在人为破坏、软硬件故障、灾难灾害或突发公共安全事件等情况下，数据依然完整、可用，保证业务连续性。
制定配套制度和操作流程，采取监控手段确保备份的有效性和及时性。
4.4 演练与恢复管理
异地灾备系统应定期进行应急演练，并制定演练管理规范。规范至少应包含：
(1)演练组织与准备
演练目的：明确演练目标，检验设定场景是否达到预期效果；
演练时间：必须在非交易日开展；
演练人员：由信息技术管理部门、业务部门、风险管理部门人员组成；
参演系统：根据演练目标决定参演系统；
参演业务：根据演练目标及系统范围确定业务范围；
影响范围：根据参演系统、参演业务，明确可能涉及的内部上下游系统及业务范围、外部机构及业务范围。
(2)演练执行与评估
演练实施：根据应急预案实施演练操作，检查操作流程的可行性；
业务验证：演练实施后，演练人员通过人工或自动化手段验证灾备系统的业务运行情况是否符合预期；
监控验证：验证演练实施后，灾备系统的监控是否正常生效；
(3)演练恢复与总结
演练恢复：对演练涉及的应用变更进行恢复，演练产生的数据完成清理，避免对生产系统带来影响；
演练总结及改进：演练组对演练的组织准备、实施过程、演练效果进行总结，并提出改进意见。
4.5 应急管理
证券公司应成立信息安全事件应急指挥组(以下简称“指挥组”)，负责公司信息安全事件的应急指挥与决策。信息安全事件应急处置应遵循“统一指挥、分类管理、分级处置、快速响应”的原则，建立信息安全事件的分级响应机制，明确内部处置工作流程，根据事件影响实施差异化处置。对于较大、一般信息安全事件，建议由信息技术部门直接组织相关业务和管理部门开展应急处置。证券公司总部因供电、通讯、网络等故障造成生产主机房不可用或者集中交易系统等核心系统发生软、硬件故障，可能导致或者已经造成全公司交易中断或严重缓慢的，应立即启动公司信息安全事件应急处置流程。经应急指挥组组长或授权信息技术部负责人批准，立即进行异地灾备中心切换。
应针对异地灾备中心业务及技术特点，制定《灾备切换应急管理办法》，办法中应至少包括：
(1)应急触发条件：明确灾备应急切换触发的条件，如主中心发生重大自然灾害、网络故障、无法恢复的电力故障等；
(2)应急组织与分工：明确应急指挥组的组成、相关角色的权责分工；
(3)应急处置流程：应急指挥组下达灾备切换指令后的主要工作步骤见下图所示：
(4)应急切换后的后期处置：主中心生产恢复、事件不利影响消除、市场舆情监控及引导、向监管报送处置进展等。
证券公司应根据系统变更、业务变化等情况，持续更新应急预案。
5 系统测试方案
5.1 测试环境
异地灾备中心完成后应部署测试环境，开展功能和性能测试。异地灾备中心测试应注意以下事项：
(1)隔离主备中心：异地灾备中心部署的信息系统，在测试之前与主生产数据中心完全断开，保证测试过程不影响生产系统运行，保证测试过程产生数据不流出异地灾备中心。在测试结束后，应清除所有测试日志和测试数据，保证异地灾备中心没有测试数据。
(2)部署测试服务器：为在异地灾备中心做功能测试和性能测试，需要部署和异地灾备中心服务器网络连通的测试服务器，并安装测试工具和必要的应用系统软件。为了保证测试不影响生产系统，应只在测试期间开启测试服务器，其它时间段必须保持关机状态。
(3)模拟外部环境：为使测试场景形成闭环，保证测试结果的有效性，对被测系统进行功能和性能测试会依赖交易所、登记结算、银行等机构的相关系统。可以采用这些机构提供的测试环境也可以采用对应系统的模拟器代替。
5.2 系统功能测试方案
对实时交易类系统，验证交易、行情、持仓、资金、账户等功能的正确性，应该覆盖全交易时段、全业务类别。全交易时段包括集合竞价、集合竞价撮合、连续竞价、盘后交易等。
全业务类别包括沪深两市及股转系统的竞价业务、融资融券、场内基金、大宗交易、港股通、非交易业务、综合业务、固定收益业务等。
| 序号 | 交易时段 | 业务类别 | 是否通过 |
| 1 | 集合竞价 | 竞价交易业务 | |
非交易业务 | |||
综合业务 | |||
固定收益业务 | |||
港股通业务 | |||
三方存管业务 | |||
| 股转业务 | |||
| 2 | 集合竞价撮合 | 竞价交易业务 | |
非交易业务 | |||
综合业务 | |||
固定收益业务 | |||
三方存管业务 | |||
港股通业务 | |||
| 股转业务 | |||
| 3 | 连续交易 | 竞价交易业务 | |
非交易业务 | |||
综合业务 | |||
固定收益业务 | |||
港股通业务 | |||
三方存管业务 | |||
| 股转业务 | |||
| 4 | 盘后交易 | 竞价交易业务 | |
非交易业务 | |||
综合业务 | |||
固定收益业务 | |||
港股通业务 | |||
三方存管业务 | |||
股转业务 |
5.3 系统性能测试方案
对异地灾备中心进行性能测试，评估异地灾备中心的性能容量，以保证异地灾备中心具有与生产数据中心有同等的处理能力，确保实施灾备切换后，各项业务能正常运行。
性能测试实施关键点包括：
(1)测试数据：建议使用生产平均日活量级的账户进行构造各个业务类别的性能测试数据，要求测试数据发送至系统返回应答的成功率在90%以上，保证测试数据的有效性。
(2)业务类别：包括竞价交易业务、非交易业务、综合业务、固定收益业务、港股通业务、股转业务，测试功能包括买入、卖出、撤单、委托查询。
(3)测试过程：使用生产配置的并发度将测试数据持续同步发送至被测系统，发送速度应该稳步逐渐提高，同时监控系统的基础资源使用率、报盘的挤压情况、系统的报错情况。当CPU、内存、网络基础资源平均使用率超过生产报警阈值，或者系统吞吐量出现大幅抖动呈现不稳定趋势，或者应答平均成功率大幅下降，此时，异地灾备中心出现过的最大吞吐量即为最大性能容量值。
| 业务类别 | 主中心性能(TPS，笔/秒) | 异地灾备中心性能(TPS，笔/秒) | 比对结果(异地灾备中心性能是否达标) |
| 竞价交易业务 | |||
| 非交易业务 | |||
| 综合业务 | |||
| 固定收益业务 | |||
| 港股通业务 | |||
| 第三方存管业务 | |||
| 股转业务 | |||
| 性能测试结论： | |||
5.4 数据同步校验方案
异地灾备中心的数据同步技术核心指标包括可靠性、延迟、带宽消耗、异地灾备中心是否可读写等。测试场景需涵盖：
(1)全业务功能性测试：全业务功能测试下，数据同步是否正常运行，异地灾备中心端数据是否完整、并测试数据同步的延迟。
(2)模拟业务交易高峰，进行压力测试：测试不同交易压力下，数据同步的延迟曲线，以及带宽消耗，以确定在满足业务系统建设RPO的前提下，数据同步技术可支撑的最大业务吞吐量。
(3)模拟生产环境业务层故障，进行切换演练：测试业务层发生切换后，数据同步切换时间，记录业务系统切换时间。
(4)模拟生产环境数据库层故障，进行切换演练：模拟生产环境数据库层(包括存储数据的主机、存储、数据库等)的故障，测试验证切换是否正常，并记录生产数据丢失时间及业务系统切换时间。
数据同步工具测试示例报告 |
| 业务场景数据同步测试指标 | 全功能型测试 | 模拟业务高峰测试 |
| 业务吞吐量 | 100tps | 5000tps |
| 数据同步是否正常 | 是 | 是 |
| 异地灾备中心数据完整性 | 数据完整 | 数据完整 |
| 数据同步最大延迟 | 10s | 50s |
| 数据同步平均延迟 | 3s | 15s |
| 数据同步占用最大带宽 | 10Kbps | 20Mbps |
| 数据同步占用平均带宽 | 3Kbps | 15Mbps |
| 业务层故障切换演练，验证数据丢失时间： | 0s | 0s |
| 数据库层故障切换演练验证，验证数据丢失时间： | 3s | 16s |
注：表中数据为示例数据。
5.5 平行清算测试方案
对异地灾备中心进行平行清算测试，目的为检验各结算相关系统日终处理的准确、可靠性及量化评估异地灾备中心最大规模下的清算效率，比较异地灾备中心与主中心的清算耗时。
5.5.1 平行清算测试关键点
(1)测试系统：应涵盖外部接口服务程序、结算文件管理、法人清算、集中交易系统、资金结算系统。
(2)测试数据：各参测系统使用生产环境清算前时刻的镜像数据进行测试，以便于进行比对。
(3)测试过程：模拟从外部接口服务程序接收结算数据开始，按照生产操作流程，依次在灾备环境执行各个步骤，记录每一步骤耗时，最后将各系统中清算结果与生产环境清算后数据进行比对，验证清算过程的正确性和清算效率，并观察清算过程中各系统数据存储容量配备是否满足清算要求。
(4)测试结论：平行清算测试结果需满足以下要求：
·各系统清算处理结果、系统初始化结果与生产环境一致；
·清算耗时与生产系统相当，清算效率达到要求；或者在清算效率降低的情形下，仍然可满足在特定时间点完成相应清算步骤(21:00前完成交易所相关报送、23:00前完成银行数据报送)，对业务的正常开展不产生影响。
5.5.2 清算测试评估表格
(1)正确性验证
| 系统 | 核对项目 | 验证结果 | 备注 |
| 外部接口服务 | 结算文件接收 | ||
| 结算文件管理 | 结算文件清分 | ||
| 法人清算 | 一级清算结果 | ||
| 集中交易 | 资金核对 | ||
| 证券核对 | |||
| 交割核对 | |||
| 报表核对 | |||
| 初始化处理 | |||
| 资金结算管理 | 资金结算 | ||
| 清算正确性测试结论： | |||
(2)效率比较
| 核对项目(系统) | 主中心耗时 | 异地灾备中心耗时 | 比对结果 |
| 外部接口服务文件接收 | |||
| 结算文件清分 | |||
| 法人清算 | |||
| 集中交易清算 | |||
| 集中交易归档 | |||
| 集中交易初始化 | |||
| 清算测试效率比对结论： | |||
5.6 备份系统切换测试方案
备份系统切换测试目的为检验灾备应急切换操作有效性，满足证券期货经营机构信息系统备份能力标准中的RTO、RPO要求，并根据测试结果制定《应急切换操作手册》。
RPO测试，必须模拟生产环境实际业务性能和容量场景下，当故障中断时，检查灾备数据中心数据实时同步的效果，验证RPO是否符合要求。
RTO测试，从主中心系统出故障开始计时至业务恢复正常停止计时，关注各个切换步骤的有效性、切换步骤时长，以保证整体切换步骤可靠、稳定、高效，验证RTO是否符合要求。
5.7 主系统恢复方案
实施灾备切换后，生产业务实际由灾备系统进行承接，在主系统恢复服务能力后，需要将业务回切至主系统运行，并将灾备系统运行期间产生的业务数据、日志数据迁移合并入主系统。
主系统的恢复方案需要明确系统回切前提、回切时间窗口、数据迁移步骤、数据核对方式、回切验证方式等内容，并在主系统成功恢复后将异地灾备中心调整至灾备模式。
主系统恢复验证要点示例：
| 恢复类别 | 系统 | 验证内容 | 操作人 | 验证人 |
| 业务数据回迁 | 交易系统 | 账户数据(用户、密码、账号) | ||
| 业务数据回迁 | 交易系统 | 资产数据(资金、证券、理财) | ||
| 业务数据回迁 | 交易系统 | 流水数据(归档历史流水) | ||
| 业务数据回迁 | 结算系统 | 结算系统业务数据 | ||
| 业务数据回迁 | 结算系统 | 结算文件 | ||
| 日志数据回迁 | 交易系统 | 客户接入日志 | ||
| 日志数据回迁 | 网上交易 | 客户交易日志 | ||
| 日志数据回迁 | 手机交易 | 客户交易日志 | ||
| 业务数据回迁 | 资讯系统 | 资讯信息 | ||
| 业务数据回迁 | 行情服务 | 行情数据 | ||
| 数据实时同步 | 交易系统 | 主中心数据实时同步至异地灾备中心 | ||
| 数据实时同步 | 结算系统 | 主中心数据实时同步至异地灾备中心 |
6 项目实施要点
6.1 总体进度规划
为保证灾备数据中心建设工作的顺利完成，建议成立领导小组和工作小组，并设立总指挥，统筹指挥协调，保证人员、资金、设备及时到位，并及时制定或更新相关工作制度。
整体工作分为业务目标分析、方案制定、公司审批、商务采购、部署实施、测试验证、上线运行等阶段，工作计划需考虑到商务进程、工程施工等因素的影响，同时，工作安排需通知到所有相关部门及岗位人员，加强沟通和协作。异地灾备中心建设参考工作计划表如下：
| 工作内容 | 工作子项 | 完成时间 | 主要完成事项 | 责任部门及人员 | 配合部门及人员 |
| 灾备系统业务目标分析 | 分析报告 | 经纪业务总部信息技术部 | 经纪业务总部信息技术部 | ||
| 制定方案 | 灾备建设整体方案 | 信息技术部 | 信息技术部经纪业务总部、清算中心 | ||
| 方案报审 | 评审报告 | ||||
| 岗位设置及人员计划 | 岗位职责 | ||||
| 管理制度和操作规划编制和发布 | |||||
| 发起商务流程 | 立项报告 | ||||
| 采购 | 采购申请 | ||||
| 系统部署 | 线路及网络 | 实施方案 | |||
| 集中交易系统 | 部署方案 | ||||
| 渠道系统 | 部署方案 | ||||
| 其它系统 | 部署方案 | ||||
| 测试验证 | 测试报告 | ||||
| 系统验收 | 验收报告 | ||||
| 试运行 | |||||
| 正式运行 |
6.2 配套商务流程
根据灾备数据中建设方案确定采购内容和商务对象，主要有云平台服务提供机构、线路运营商、软件供应商等，根据整体工作计划安排商务进程。灾备数据中心参考建设商务计划表如下：
| 采购内容 | 供应商情况说明 | 计划第一轮商务日期 | 计划第二轮商务日期 | 机动时间 | 备注 |
| 云服务商 | |||||
| 通讯线路 | |||||
| XX特殊设备 | |||||
| 数据库 | |||||
| XX系统授权 |
6.3 建设预算及人员安排
异地灾备中心建设使用行业核心机构的云平台，借助云计算特有的快速伸缩能力，券商的设备资源使用可以按需获取，随时调整，在满足实际需求的同时，避免设备闲置造成的浪费。在基础环境的管理上，可以委托给经验丰富的核心机构专业团队负责，得到专业化的保障的同时也节省运维人员。因此，在预算和人员安排方面应合理评估，集约安排。
预算方面，根据异地灾备中心建设覆盖业务范围和涉及的系统，以及设备选型、网络等方案进行预算评估，涉及项目主要有云资源、线路、软件授权等，编制预算表，发起公司内部预算申请流程。灾备数据中心参考建设预算评估表如下：
| 预算项目 | 项目建设内容 | 部署数量 | 单价(万元) | 金额(万元) |
| 集中交易系统 | 数据库服务器 | |||
| 中间件 | ||||
| 报盘中 | ||||
| 网上交易 | 委托主站 | |||
| 接入服务器 | ||||
| 清算工作台 | ||||
| 合计 |
人员方面，异地灾备中心建议安排4到5人开展相关系统的基础设施运维和业务系统运维工作，具体工作内容如下：
| 工作 | 内容 | 人员 |
| 负责人 | 领导协调异地灾备中心的日常工作 | 1 |
| 基础设施运维 | 日常巡检及故障快速处理/系统资源监控，出具巡检报告、云平台租户资源日常维护(ECS资源申请、云盘扩容、网络维护、安全策略调整等) | 1-2 |
| 业务系统运维 | 负责日常业务系统运维，每天定时检查系统运行状况，并出具巡检报告、日终清算、故障分析及快速定位。 | 2 |
应制定运维保障和测试等岗位的上岗要求和工作职责，确定人员计划，安排上岗培训。
6.4 系统验收
灾备系统验收包括云资源、网络线路、系统功能和性能、操作演练等内容：
| 序号 | 验收条目 | 验收要点 |
| 1 | 基础平台云资源申请情况验收 | 内外联网络线路已全部搭建完成并连通；集中交易系统、网上交易系统、APP手机交易系统等所需基础资源均已如需发放并具备部署条件。 |
| 2 | 集中交易系统部署验收 | 集中交易系统中间件、证券接入、数据库、数据同步等均有效部署完成并满足测试条件。 |
| 3 | 网上交易系统部署验收 | 网上交易系统的客户端接入、中间件、服务器端需有效部署完成并满足测试条件。 |
| 4 | APP手机交易系统部署验收 | APP手机交易系统的客户端接入、中间件、服务器端需有效部署并满足测试条件。 |
| 5 | 功能验收 | 功能测试中所有业务功能点均已测试通过。 |
| 6 | 数据同步测试 | 异地灾备中心的数据同步技术核心指标包括可靠性、延迟、带宽消耗已测试通过。 |
| 7 | 平行清算测试 | (1)交易系统灾备环境清算及初始化的正确性及效率满足要求；(2)连续多日运行情况下清算系统的可稳定高效运行。 |
| 8 | 性能验收 | 异地灾备中心关键性能指标达到主中心水平。 |
| 9 | 灾备切换验收 | (1)灾备切换演练成功，全国各区域在发生灾备切换后能够和异地灾备中心联动正常工作；(2)RTO、RPO须满足监管要求，系统弹性扩容可在既定时间内完成。 |
7 制度与文档
7.1 管理制度
为规范异地灾备中心的日常管理行为，应结合异地灾备中心的工作特点，制定相应的工作制度，参考制度清单和内容如下：
| 序号 | 制度 | 制度描述 |
| 1 | 《异地灾备中心日常运行管理规范》 | (1)制定每日早间、日结、清算、数据同步、监控巡检等运维活动规范；(2)系统升级变更管理规范；(3)灾备切换应急处置活动规范；(4)每日交班人员和接班人员严格按照交接班制度进行交接班，做到系统故障可追溯、维护责任可追溯。(5)每日形成异地灾备中心运行情况日报，内容包括重要故障报告、性能总结报表、设备变更报告、配置变更报告、巡检记录等 |
| 2 | 《异地灾备中心运行质量月度分析报告制度》 | (1)重要故障报告、性能总结报表、设备变更报告、提供客户设备的运行质量报告、分析建议报告等；(2)每月至少对网络设备的工作环境、硬件状况、通讯线路、各类连接线路进行一次检查和维护，主要包括通讯线路、机房环境、设备硬件状态、设备和线路标签、备品备件等；(3)每月至少对网络设备、主机设备和存储设备的配置参数、工作状况、设备性能、带宽占用情况、网络通讯状况、应用系统运行质量等内容进行一次检查和维护，确保参数配置的正确、设备运行可靠，同时要做好设备参数配置的备份。 |
7.2 工作文档
为保证异地灾备中心建设工作的有序开展，各阶段应有完整的文档输出，参考文档清单如下：
| 序号 | 步骤 | 步骤描述描述 | 输出成果 |
| 基础平台资源申请阶段 | |||
| 1.1 | 灾备链路建设 | 主中心到异地灾备中心的网络链路，包括不同运营商或不同介质的线路 | 《网络部署报告》 |
| 1.2 | 云管平台VPN账号申请 | 《基础资源申请及部署报告》 | |
| 1.3 | 云管平台VPC建立 | ||
| 1.4 | 云内安全组划分 |
| 1.5 | 云资源申请 |
| 1.6 | 沪深交易所交易网关申请 |
| 1.7 | 云内VPN部署 |
| 1.8 | 堡垒机部署 |
| 1.9 | 软件正版化审批 |
| 1.10 | 安全基线检查 |
应用系统部署阶段 | |||
| 2.1 | 集中交易系统数据库部署 | 包括数据库和数据库同步工具的部署 | 《集中交易系统部署报告》 |
| 2.2 | 集中交易系统中间件部署 | ||
| 2.3 | 报盘机、转码部署 |
| 2.4 | 行情源部署 |
| 2.5 | 沪深交易所交易网关部署 |
| 2.6 | 三方存管系统部署 |
| 2.7 | 网上交易系统部署 | 《网上交易系统部署报告》 | |
| 2.8 | 移动APP系统部署 | 《APP手机交易系统部署报告》 | |
| 测试及上线阶段 | |||
| 3.1 | 功能测试 | 主要验证场内交易所涉及的交易、行情、账户功能的正确性，应该覆盖全交易时段、全业务类别。 | 《功能测试报告》 |
| 3.2 | 性能测试 | 依赖交易所模拟，评估灾备系统建设是否能达到设计能力，评估系统性能。 | 《性能测试报告》 |
| 3.3 | 全网测试 | 组织营业部开展测试，评估全国各区域在发生灾备切换后能够和异地灾备中心联动正常工作 | 《全网测试报告》 |
| 3.4 | 数据同步测试 | 验证主中心到异地灾备中心的数据同步功能和性能是否能够达标 | 《数据同步测试报告》 |
| 3.5 | 平行清算测试 | 验证异地灾备中心在承接主中心运行后是否可以支持连续多日的清算运行，包括功能和性能是否达标 | 《平行清算测试报告》 |
| 3.6 | 灾备系统切换测试 | 模拟主机房发生故障，将渠道端系统和集中交易系统全部切换至异地灾备中心，验证切换步骤是否合理、云资源弹性扩容是否能在既定时间内完成、 | 《灾备演练总结报告》 |
第二部分问题解答及建议
1 常见问题简答
一、金证系统
1、金证U版柜台数据库如何上云？
1)如果生产中心数据库是运行在AIX平台，可以考虑采用AIX到Linux异构平台，灾备中心安装与生产中心相同的数据库版本，并由金证实施工程师完成相应的数据库调优工作。如果是非AIX平台，灾备中心需采用与生产中心相同的操作系统版本，配置参数与生产中心保持一致。
2)云上数据库选择SSD盘，提高数据库读写性能。
2、金证KCBP中间件如何上云？
1)如果生产中心KCBP是运行在AIX平台，灾备中心KCBP可以选择安装在Linux平台，Linux版KCBP并做相应的调优；如果是非AIX平台，灾备中心采用与生产中心相同的操作系统版本，配置参数与生产中心保持一致。
2)KCBP部署的数量可以根据测试情况，进行动态调整。
3、如何确认云服务器可提供的操作系统版本？
对金证U版柜台，操作系统版本选择以主中心在运行的为准，需要确认云服务器提供的操作系统版本是否与业务系统运行的操作系统版本保持一致；AIX平台迁移到LINUX平台，版本、程序也要参考生产系统在用的版本。
4、如何实施异地灾备中心与营业部网络连接？
1)采用VPN作为主用方式，适用场景为灾备切换时主中心和同城中心全部异常。各营业部使用本地互联网线路，通过本地VPN网关建立与异地灾备中心的网络连接。在方案设计时，采用尽量减少营业部段变动策略。异地灾备中心可以采用与主中心相同的VPN服务端设备，营业部端VPN客户端设备不需要更换或增加，仅做配置变动。这样能减少营业部工作量，降低切换复杂度，减少切换时间。
2)使用数据复制线路作为备用方式。适用于灾备切换时主中心或同城中心网络系统正常的情况。营业部通过原有到主中心或同城中心线路，经复制线路，建立与异地灾备中心网络连接。这种方式营业部变动最少，但启用时受灾备切换场景限制，比如灾难发生时，主中心网络设备或网络系统故障，或复制线路故障，或主中心整体不可用等，需根据实际情况进行判断。
5、数据同步方式和复制带宽如何选择？
1)数据同步软件(方式)选择，可采用与主中心到同城中心相同的数据同步软件(方式)，也可以考虑使用新的数据同步软件。
2)根据需同步数据库大小和每日数据变化量，参照主中心到同城中心数据同步带宽，并为未来数据增长预留一定带宽余量。
3)进行实际数据同步测试，根据测试情况进行调优。
二、顶点系统
1、顶点交易系统Oracle数据库如何上云？
交易系统的Oracle数据库，在系统高并发压力的情况下，其系统瓶颈在磁盘的IO能力上，应重点调优数据IO磁盘的读写性能，在云端采用SSD盘的同时、特别是日志切换等方面进行重点调优。
2、顶点A2/A3中间件在云平台如何优化？
顶点A2/A3中间件的服务名有唯一性的要求，所以应在灾备机房以统一的前缀进行标识、整体服务名与主机房相似，确保切换时操作的一致性。在升级过程中，通过统一的升级服务器确保主备机房程序的一致性。另外如果采用远程桌面启用应用系统，建议严格控制远程桌面用户注销对系统造成的影响。
顶点A2系统中核心中间件在Windows平台上运行，在保持操作系统版本一致的同时，应对部分微软官方补丁采用灰度升级策略，杜绝全局性风险。
顶点A3系统中，除了Linux平台外，核心中间件在Windows平台上运行，在保持操作系统版本一致的同时，应对部分微软官方补丁采用灰度升级策略，杜绝全局性风险。
3、顶点A2集中交易系统在云端UDP通信如何实施？
A2集中交易系统在服务器集群上采用了UDP广播，在行情服务上支持组播通信。由于上证云平台在Windows平台下不支持广播或组播通信，但支持单点UDP通信，所以在服务器集群上通过服务配置修改的方式，将UDP广播改为在一定范围内的单点UDP通信；在行情服务的组播上，在云端部署时直接采用TCP订阅发布方式来解决。
4、异地机房报盘如何设置？
以上海报盘为例，上海报盘系统的SQLServer服务器地址数据存放在数据库中，在切换到灾备机房时，由于机房间IP地址的差异，造成SQLServer数据库连接的问题，建议改成使用本地host定义的连接方式、这样可以实现上海报盘的实现无缝切换，深圳报盘也应该类似处理解决。另外，部分系统间的连接也要求采用此方式进行优化。
5、前端交易接入的整体布局如何优化？
应用系统在向异地灾备中心切换的过程中，为实现各类前端交易接入的快速切换，并且透明无感，券商可根据自己的实际情况，在主备中心同时部署前端交易接入中间件。即在主中心配置接入通信中间件RS1，在灾备中心部署两套相同的接入通信中间件RS2与RS3，其中 RS2连接主系统的核心服务，RS3连接灾备系统的核心服务。两套中间件部署在同一机器上、并且服务端口一致。
在日常运行过程中，只启动RS2，RS3处于停止状态。前端交易平台连接主中心的通信中间件RS1与异地灾备中心的RS2，通过权重分配将大部分的请求通过连接1来转发业务。当主系统正常，前端交易平台与主机房的通信线路出现故障的情况下，系统自动通过线路2来转发请求，无须运维干预处理。当需要实施异地灾备切换时，需停止灾备中心的RS2，启用RS3接入服务，这时交易终端接入平台会自动切换到RS3，实现整体系统切换。
三、恒生系统
1、如何进行Oracle安装？
参照恒生电子相关安装规范部署oracle数据库，并创建oracle数据库实例，配置监听服务；检查数据库服务状态、数据库进程状态、监听状态、端口状态是否正常；通过任意一台ls或as服务器，检查并确认数据库连接状态正常。
2、应用系统Oracle数据库如何导入？
从生产数据库备份dmp文件，传输至灾备数据库服务器，在灾备数据库服务器创建对应数据库表空间，导入数据并检查导入日志，确认数据导入正常。
3、如何准备UF20系统环境？
灾备中间件服务器创建hundsun以及oracle用户并设置密码，创建/U01及/U02目录并授权，修改时间同步指向上证云时间同步服务器，修改主机名，配置镜像拉起主机名不变，安装oracle client服务并配置tnsnames.ora指向到灾备数据库。
4、UF20应用部署应注意什么？
应用部署应在闭市后进行，因上证云上ECS云主机限制不能上外网，需要挂载EIP地址到对应的ECS云主机上，其他工作按恒生电子标准文档进行。
5、如何封装镜像并批量生成灾备中间件？
首先针对单台部署并调试完毕的中间件服务器，通过云管平台封装成镜像，再通过镜像拉起并生成全部的LS/AS/BAR/JAR中间件ECS云主机，并指定IP地址，最终启动全部ECS中间件云主机，并根据部署规划更新配置文件，启动运行中间件服务。
6、UF20应用调试有哪些要点？
在安装准备工作完毕后，应安装压测工具进行压力测试，根据用户生产环境业务功能号配比及灾备环境处理能力规划要求，不断调整压测工具模拟的并发用户数，给予UF20业务系统性能压力，同时监测中间件及数据库状态，在发现tps不再上升后，检查瓶颈点。
主要瓶颈点一般为中间件性能(例如中间件cpu负载，中间件积压状态等)、数据库性能，针对实测瓶颈，根据原子组积压和系统负载情况，扩容或提升对应ECS云主机规格。
四、共同问题
1、如何实施时钟同步、操作系统补丁、统一防病毒？
1)当云上主机时间存在不准情况时，采用网络授时，实现所有云主机时间校对和同步。
2)建立操作系统(重大)补丁升级服务器，对云主机统一升级；
3)建立防病毒升级服务器，云主机防病毒客户端统一升级，保持各云主机防病毒库及时更新。
2、灾备中心运行一段时间后，如何确保其程序版本、配置与生产中心一致？
1)生产中心把灾备中心当作变更流程的一部分，变更生产中心系统程序时，及时通知灾备中心，并跟踪灾备中心变更完成后才关闭整个变更；
2)灾备中心每周进行变更询问，每月进行变更核对，避免版本和配置遗漏。
3、灾备中心系统长期处于非生产状态，如何保证灾备应用的可用性？如何保证灾备中心运维人员操作的熟练程度？
1)灾备中心周末积极利用交易所测试平台，组织人员参与交易所各业务测试，充分利用交易所、中登各核心机构的测试窗口，对交易所报盘、ccnet、Dcom、Prop等应用进行通道测试和业务测试，验证灾备系统的可用性。
2)积极参加交易所各业务测试，定期组织灾备系统可用性测试，组织灾备系统演练，可以提升项目成员操作熟练度。
2 工作难点及对策建议
难点1:灾备系统通信接入成本。
描述：相关成本具体包括；1)沪深交易所、中登公司、股转公司等核心机构接入；2)银行第三方存管、基金代销等业务接入；3)生产中心与灾备中心数据同步；4)证券营业部灾备接入等等。
建议：1)核心机构已为券商提供以下条件，以降低券商通信接入成本：
·提供到沪深交易所报盘行情的共享通道，券商可通过共享通道免费接入沪深交易所；
·提供FDEP接入点和证联网接入点，券商可以通过接入点与银行、证券和基金等金融机构建立连接；
·通过与运营商的线路框架协议，以及协助券商与运营商进行价格协商，可以进一步降低数据同步线路和互联网带宽成本。
2)券商还可使用一些成熟的通信技术，以进一步降低成本：
·对于中心间通信，使用SD-WAN(软件定义广域网)技术，同时利用数据专线的稳定性和互联网线路的经济性，并根据系统特点和所在地线路的价格情况，合理制定数据专线和SD-WAN的使用策略，实现链路聚合、链路均衡及可信数据传输通道，并且实现不同运营商及两种不同介质线路的互备。
·对于营业部接入，在结合使用SD-WAN技术实现高速通道的基础上，结合采用VDI技术，将营业部应用进行总部集中化，营业部仅需使用普通互联网通道即可安全高效的访问相关资源。
难点2:证联网第三方存管切换。
描述：证联网只允许券商的两个中心接入证联网同一组接入点，第三方存管主备系统可使用同一个IP。第三个中心只能接入证联网另一地的接入点，且其第三方存管系统不可使用主中心及同城中心的IP，实施异地灾备切换时，券商必须向证联网提出IP迁移申请，这一过程耗时超出了RTO指标的规定标准。
建议： 两地两中心布局的券商，采用在异地灾备云平台所在地，建立与证联网直接通信的线路，并选择对主中心网络与该接入点子网进行二层或三层的打通的策略，可以实现证联网第三方存管系统的通信链路级及应用级的异地快速切换，确保异地灾备切换的RTO指标达标。
两地三中心布局的券商，可撤除同城灾备的证联网通信线路，保留主中心和异地灾备中心与证联网同一组接入点的通信线路，选择对主中心网络与该接入点子网进行二层或三层的打通的策略，以实现证联网第三方存管系统的通信链路级及应用级的异地快速切换，确保异地灾备切换的RTO指标达标(调整只涉及证联网通信，不影响券商两地三中心布局的其他方面)。
难点3:完整的测试环境与测试内容。
描述：异地灾备系统建设过程中的测试工作，需要较为的完整的外部环境，包括证联网以及外部机构(如银行)的支持；测试内容也应较为完整，以确保达到上线的要求。
建议：1)在对异地灾备系统进行建设及测试的过程中，券商应充分利用交易所、中登公司、股转公司及其他市场相关机构的日常测试环境，将日常测试工作和灾备系统的测试工作有机结合起来，确保所有灾备系统都经过测试。
2)异地灾备系统的测试内容，包括功能测试和性能测试两方面。功能测试主要包括灾备系统业务功能测试、主备系统平行清算测试、主用系统恢复测试等；性能测试主要包括切换RTO/RPO指标测试、系统处理能力指标测试、系统运行稳定性测试等。
上交所已对PBU登录管理策略进行了全面优化，在券商端报盘系统出现故障时，经实测，PBU的重新登录可以瞬时完成，券商可在测试中进行专门验证。
券商实施灾备切换的决策过程，其耗用时间也属于RTO/RPO指标的统计范围，券商必须按照《异地灾备建设行业最佳案例》的要求，优化自身的决策流程，确保不因决策速度过慢而导致RTO/RPO指标超出标准要求。
难点4:主备中心间数据同步策略。
描述：数据同步策略不仅影响主备中心间通信线路的带宽，也影响券商灾备切换工作的复杂度。券商应根据系统的重要性和同步内容的特点，选择合理的备份方式。
建议：1)核心交易系统的数据库，以及主备两端操作系统不一致的数据库，使用RTO指标较优且适应性较强的基于逻辑复制的同步工具进行同步；
2)其它生产系统(如账户管理系统)数据库，以及数据量规模适中的OLAP类系统数据库，使用基于物理复制的同步工具进行同步；
3)客户影像资料、业务系统附件等重要文件，使用文件同步工具进行同步，如券商计划在灾备中心配置物理存储设备，也可使用NAS同步、备份一体机等方式进行同步；
4)体量较大且没有历史数据归档机制，主要用于依据原生业务数据进行各类指标计算及管理的OLAP类系统数据库，将其数据源设置为灾备中心的对应系统，在当地完成数据的采集、清洗、计算工作，不进行主备中心间的数据实时同步；并需定期进行主备中心间的数据库全同步，以确保数据库内容一致。
难点5:券商私有云与核心机构云平台的对接。
描述：券商采用CTRIX公司技术自建的私有云平台与云平台进行对接时，在虚拟桌面(VDI)的电源管理和分配控制上存在一定的技术难度，且云桌面发布时所需的一些虚拟化优化组件在云环境中无法直接使用。
建议：1)在云平台上同时开启多个桌面虚拟机，并对使用桌面云的分支机构提供一对一常开模式的虚拟桌面(即用户专有自己的虚拟桌面VDI)，这种部署模式在用户体验上没有明显区别；
2)在云平台所在地部署一台单独的硬件应用交付设备，并将应用交付设备与云平台上部署的虚拟桌面VDI区域打通，利用此应用交付设备实现桌面云协议发布过程中的优化，以及与AAA(验证、授权、记账)对接等功能。
难点6:云平台配套的灾备演练与运维场所。
描述：为保证异地灾备系统的正常工作，尤其是保证异地灾备切换工作的顺利流畅，券商需要核心机构在提供云平台的同时，配套提供必要的工作场所，供券商进行灾备系统运维，以及实施灾备切换演练与实际操作时使用。
建议：核心机构在通过其云平台为券商提供异地灾备服务的同时，配套建有有灾备系统的驻场运维场所，券商可派运维人员驻场运维系统。
上证云依托自建及租用的第三方数据中心，在上海及北京站点设立了运维及应急中心，提供办公及应急接入、演练服务，配合行业用户进行灾备应急与切换演练。
深证云在北京、上海、凤岗设有应急中心，各应急中心的设施齐全，包括坐席、办公配套和灾备接入环境等设施。深证云租户可到就近的应急中心，进行灾备演练。
难点7:灾备中心人力成本高，管理难度大。
描述：为保证灾备中心的高可用性，需要配备足够的系统运维管理人员队伍，由此将产生较高的人力成本；由于灾备中心平时只是备用状态，技术人员队伍的管理难度较大。
建议：1)对生产系统在主备中心间实施交叉部署，生产系统运维人员同时兼顾灾备管理，做到人员的复用，可间接降低了整个灾备人力成本。
2)考虑总部和本地人力相结合的模式。总部人力实行轮岗制，到灾备中心进行短期轮换；从本地适当招聘部分运维人力，先期在总部培训，培训并考察合格后派驻灾备中心。在运维过程中，本地运维人员，亦需定期到总部进行短期轮换、培训，以便于加强灾备本地人力对总部的集体认同感。
（文章来源：中国证券业协会）
东方财富证券股份有限公司
公司官网：http://www.18.cn
客服电话：95357
东方财富证券微信公众号
东方财富证券投教园地