交易技术前沿

49

户系统开发的工具包，该工具包首先通过 Restful

请求从网关处获取到服务器所对应的二级代理信

息，然后创建 Netty 客户端与二级代理建立连接，

二级代理客户端采用零拷贝的方式作为用户端和

服务器间的桥梁将文件进行分片传输。其中零拷

贝是一种使用在 NIO 和 Epoll 传输时使用的特性，

它可以快速高效的将数据从文件系统移动到网络

接口，而不是将其从内核空间复制到用户空间。

2.3 部署方式

自动化代理平台作为运维系统的操作处理

平台，对接了多个运维子系统并且面临大量的

QPS，同时还管理着近万台服务器，因此高可靠、

高可用的部署方案是不可或缺的。

自动化代理平台的微服务均采用集群方式

部署，其中网关层使用 Nginx 和 Zuul 集群组合的

方式对外提供稳定的网络服务。利用 Eureka 搭

建微服务集群的注册中心，EurekaServer 提供服

务注册和发现，这使得系统中的微服务可以方

便的进行动态扩缩容，当业务量增加导致微服

务出现性能瓶颈时，通过新实例的上线便可被

EurekaServer 自动将其扩容到服务列表中并将节

点信息实时同步到网关层，网关层将新增节点加

入到负载均衡循环列表中路由网络请求。对于不

同物理机房的二级代理服务，虽然从业务和开发

角度属于相同的服务，但在自动化代理平台中我

们将其划分为不同的微服务，网关层对不同的微

服务创建不同的 Ribbon（一个基于 HTTP 和 TCP

的客户端负载均衡工具），对指定的微服务集群

使用 Ribbon 进行负载均衡的路由分发。

二级代理场景中服务器和二级代理通过

Netty 进行长连接，由于二级代理属于集群化的

可动态变化的微服务，因此服务器需要动态的感

知二级代理的实例，并分别与其建立 Netty 长连

接。二级代理各实例通过共享的数据库中同步比

对服务器的连接状态，保证所有实例与服务器的

连接状态是一致的。在文件传输场景，用户端创

建 Netty 客户端与二级代理建立连接，在完成文

件传输时断开连接，释放冗余的资源占用。

缓存数据库是维持自动化代理平台工作的重

要环节，采用“一主二从三哨兵”高可用解决方案，

其部署架构主要包括两部分 ：Redis 哨兵集群和

Redis 数据集群。如果主实例宕机，哨兵主动将

一台从机升级为主机继续对外提供数据服务。在

业务层面，缓存数据库除了提供二级代理场景下

的实例间数据共享外，还提供了实例间的分布式

锁，保证 Netty 连接数据的最终一致性。

3、系统分析与实践建议

3.1 系统分析

中信建投证券在自动化代理平台持续探索，

在系统架构和功能模块上不断演进与扩展，取得

了一定的成效。目前的自动化代理平台能够大大

降低运维系统的使用难度，释放运维人员的繁琐

劳动，从架构设计上能够有效改善系统的运行效

率与稳定性，具体体现在以下几个方面。

（1）安全性

自动化代理平台运行在系统的内网环境，只

有网关层提供内网其他系统的访问，避免了业务

服务被直接访问攻击的风险。网关层采用用户认

证以及 token 校验，对恶意访问的用户或 ip 地址

进行黑名单处理并上报告警。

（2）可靠性

采用无状态化的集群部署方式，保障系统有

效的利用服务器资源，多实例的服务模式以及主

备容灾的数据模式有效分担了系统的计算压力，

避免出现 CPU 或内存资源出现满负荷的状况。

微服务在微服务注册中心注册后由网关进行服务

转发，并且具有降级、熔断和限流等功能保障系

统持续提供服务。高可用的数据库与中间件提供

完善的数据备份和可靠机制，系统可靠性增强显

著。

（3）稳定性

探索与应用

50

对外网关采用 Zuul 集群的形式，有效提升

外部的访问吞吐量，系统内使用负载均衡的消息

分发策略，将计算压力分流到多实例服务中。将

热点数据存贮到缓存数据库中，降低了外部访问

对系统的压力，提升了请求相应速度。微服务的

功能单一、业务独立使得整个系统耦合性极低，

模块间调用关系更清晰，并可进行链路跟踪与分

析，显著提高开发效率与系统运行监控能力。

（4）易用性

统一的对外网关，有效了屏蔽了用户层和服

务层直接的状态感知，用户只需关注自身的业务

请求指令，无需关注服务器的物理位置，网关层

会通过自定义过滤器功能将业务请求指令路由到

对应的服务层。为了便于用户系统对接，我们提

供了封装完善的工具包，用户系统可以很容易的

集成，并直接通过 API 指令完成自动化代理平台

提供的业务功能。

3.2 实践建议

自动化代理平台作为运维系统的核心服务之

一，是简化运维复杂度、降低人工干预风险、提

升运维人员工作效率的重要环节。如何更切实的

完成这些目标是我们努力探索的方向，在实践过

程中总结了几点建议，并规划进一步完善自动化

代理平台。

（1）数据可视化

可视化数据报表比传统的数据报表更有表现

力，借助 Web UI 的窗口将系统中的服务器关系

以及运行状态转换成视觉或表格的格式，以便可

以分析数据和数据项或属性之间的关系与特性，

方便用户直观分析大量视觉信息，检测一般规律

和趋势。

（2）异地容灾

自动化代理平台拥有大量的运维系统对接，

对自身的容灾要求更为严格，通过异地容灾的部

署方式将主备两个物理站点隔离开来，预防自然

灾害等造成的系统瘫痪。将自动化代理平台分别

部署在不同站点，主站点对外提供服务，备站点

定时从主站点同步数据备份，在主站点心跳停止

后自动升级为主站点并向运维系统发送主备倒换

通知，进而接管自动化代理平台业务。

（3）智能化改造

随着业务量的不断增加，运维人员的操作请

求也会不断增加，系统智能化是提升业务精准度

和降低人力成本的有效途径。使用自动化任务流，

对于异常任务进行智能化回滚或重试，探索智能

机器人与人工的协同工作模式，以最大化用户满

意度，同时提高处理效率。

4、总结与展望

为提升用户的满意度，应对快速增长的业务

请求，中信建投证券以自动化为导向，微服务架

构为标准，针对自动化代理平台不断探索。本文

针对中信建投证券在自动化代理平台的探索与实

践进行阐述，对系统架构演变进行详细介绍。此

外，本文还介绍了自动化代理平台建设的成果，

从系统功能设计角度阐述系统的模块设计与架构

调优。最后，本文分析了自动化代理平台所带来

的成效，并介绍了系统建设的实践经验。

未来自动化代理平台还有广阔的探索空间，

一方面随着人工智能技术在证券行业的应用逐步

深化，运维系统将逐步向智能化、自动化方向演

进。另一方面，随着证券业务越来越多，系统间

交互越来越复杂，搭建完善的自动化代理平台的

诉求将更加强烈，自动化代理平台作为很好的切

入点，在提升用户服务体验以及构建开放生态上，

将发挥出更大的价值。未来自动化代理平台将以

云原生和智能化为方向持续改进优化，以为用户

提供高质量服务为最终目标不断努力。

交易技术前沿

51

随着金融领域不断对外开放，我国已全面取消外资持有境内证券、基金公司股权比

例限制，外资金融机构正加速进入中国市场，随之而来的数据跨境流动问题也日益凸显。

因此，如何安全、合规地进行数据跨境流动已成为外资金融机构以及监管部门关注的核

心问题。本文在研究数据跨境流动国内外政策以及现状的基础上，探索一种基于“上证云”

的数据跨境流动管理解决方案——虚拟数据室，即通过数据加密、权限控制、操作留痕、

关键字检索等技术手段，解决外资金融机构日常数据跨境流动涉及的相关问题，同时利

用统一日志、数据接口等技术手段便利监管与审计。

基于上证云的数据跨境流动

管理方案研究与实现

操浩东1

、刘政言1

、何雷2 / 1 上交所技术有限责任公司 云基础设施运营部 上海 200120

2 中金所数据有限公司 数据研发部 上海 200120

E-mail ：hdcao@sse.com.cn

1、概述

随着数字经济及全球化的深入发展，数据已

成为全球经济的基础性生产要素，同时也是国家

重要的战略性资产。在数字化时代，数据作为新

的关键生产要素，只有实现在更大范围的流动共

享，才能更好地发挥对经济增长、社会发展、全

球化进程的推动作用。

我国自 2020 年取消境外金融机构持股比例

限制后，境外金融机构在境内控股证券、基金管

理公司逐渐增多，客观上有基于并表管理、业务

协同、统一风险控制等目的开展数据跨境流动及

信息系统跨境部署（以下简称“双跨”）需要，

也需要通过“双跨”落实对外开放的目标。同时，

伴随着全球普遍加强网络数据安全、个人隐私保

护以及我国陆续发布数据安全有关法律法规，对

探索与应用

如何在安全、合规前提下支持外资机构数据跨境

流动需求提出了更高要求。

1.1 国内外相关政策

目前，全球正积极推进网络空间主权、数据

安全、个人隐私保护等相关立法进程，但各国立

法纷繁复杂，针对数据跨境流动也尚未形成统一、

对等的监管协作机制。

2018 年，美国发布《澄清域外合法使用数

据法》（CLOUD Act，以下简称《云幕法案》），

赋予美国政府调取存储于他国境内数据的法律权

限，无论数据是否存储在美国境内，服务提供者

需依法进行信息披露。他国政府想调取存储在美

国的数据，须通过美国“合格外国政府 ”的审

查（大部分国家都不满足审查标准）。

2018 年 5 月，欧盟发布《通用数据保护条例》

（GDPR），对通过“充分性认定”国家（大部分

为欧盟成员国）的数据跨境流动实行统一、对等

的监管要求，减少或取消成员国内对数据流动的

地域限制，从而推动欧盟范围内数据的自由共享。

对于未通过“充分性认定”的国家，在数据共享

过程中则需满足欧盟颁布的标准合条款（SCC）、

集团企业规则（BCR）等诸多法律法规限制。

俄罗斯等国家基于维护国家安全的历史传统

和现实中的网络数据安全威胁，明确提出公民数

据的存储和处理必须在俄罗斯境内进行。

我国基于“维护国家安全及公众利益、保护

个人隐私”等目的，在服务对外开放大局的前提

下，高度关注与国外监管机构划分合理监管边界，

防范“长臂管辖”。在现行的法律中，《网络安全法》

将“网络空间主权”置于国家安全同等重要的地

位，同时提出了重要数据本地化存储等有关要求，

通过强化地域管辖实现对数据主权的保护 ；本次

修订的《证券法》，提出了数据出境需经国务院

有关机构或部门同意等要求 ；《反洗钱法》提出

了非依法律规定，不得向任何单位和个人提供反

洗钱相关客户身份和交易信息等有关要求 ；《个

人信息保护法》进一步明确了个人信息、重要数

据的定义以及数据出境需经严格的评估等要求 ；

《数据安全法》，提出了数据分类分级管理、数据

出境评估、加强国际合作等一系列要求，保障数

据依法有序自由流动 ；新出台的《数据出境安全

评估办法》提出了数据出境安全评估的具体要求，

规定数据处理者在申报数据出境安全评估前应当

开展数据出境风险自评估等一系列要求。

1.2 数据跨境流动需求

无论是境内外资机构基于发挥境外集团在

全球范围内的资产配置作用、复用集团先进系统

及经验等目的，还是境外集团借助境内外资机构

更好的了解中国市场，发掘中国市场蕴含的潜在

机会等需求，双方均有较大的数据流动需求。目

前，金融机构跨境流动的数据主要可以分为以下

几类 ：一是基于业务协同需要，以满足集团化运

营管理为目的的业务数据和管理数据，如跨境并

购时需与境外团队共享的概要性尽职调查信息、

用于风险敞口计量的数据、证券自营业务交易数

据、符合我国有关法律法规要求并取得员工同意

的员工个人信息等。二是基于公司财务并表管理

或流动性风险计量需要，需定期通报股东单位的

结果类、汇总类信息。三是基于复用经验、提升

项目质量的目的，供全球业务领域专家做专业研

判的数据。四是基于满足境外监管要求需报送的

数据，如出于满足反洗钱、反恐怖等司法目的的

数据、为协助境外集团满足巴塞尔协议资本计量

的要求，需报送风险损失等数据。

1.3 数据跨境流动存在的问题

1. 数据跨境传输手段落后。目前，金融机构

主要使用邮箱、文件传输系统，或者直接通过数

据接口等传统方式进行数据跨境传输。随着数据

跨境流动场景的规模化和复杂化，此类方式缺乏

足够的管控手段覆盖敏感、复杂数据的跨境流动

风险，也无法满足防范数据泄露、传输留痕、配

52

交易技术前沿

合审计等合规需求。

2. 缺乏高效的审计方式。根据监管要求，金

融机构应对跨境数据进行分类分级管理，建立完

善的日志、记录等留痕管理及防篡改机制，并对

相关内容定期开展审计。由于数据的类型、敏感

度不同，金融机构往往采用多种数据传输方式，

相关操作的留痕记录相对分散，且留痕标准参差

不齐，导致审计成本较高，审计效率低下。

3. 缺乏有效的监管手段。在互联网以及其他

技术手段的支持下，数据跨境流动更加便捷，但

随着外资金融机构数据跨境流动场景日益增多，

监管方面缺乏有效的技术管控手段及时感知全市

场的数据跨境流动风险，导致监管效率低下，一

旦发生风险，容易出现爆点多、燃点低的特征。

2、数据跨境流动管理探索

2.1 场景分析

在全球普遍加强网络空间主权、数据安全、

个人隐私保护以及数据跨境流动场景日益复杂

化、多样化等背景下，数据跨境流动管理应聚焦

于在安全、合规的前提下保障外资机构的数据跨

境流动需求，同时兼顾效率和成本。以下将从五

个方面简要分析数据跨境流动管理场景需兼顾的

几个问题 ：

1. 提供多种数据跨境流动方式，支持多种数

据出境场景。外资金融机构应根据数据分类分级

管理要求，使用与数据敏感性、重要性相匹配的

传输方式。因此，解决方案应支持直接传输、模

板传输、受限访问等多种跨境流动方式，且相关

数据的操作权限均可灵活配置，实现数据分类分

级管理以及多种数据跨境流动需求。

2. 降低合规成本，提升效率。在技术的赋能

下，数据跨境流动及数据访问往往具有瞬时性，

同时数据的规模化及复杂化已必将带来合规要求

的推陈出新，而传统线下或半线下的合规方式难

以及时、有效的识别风险。因此，解决方案在设

计时应考虑在代码中嵌入合规及监管要求，真正

实现“规则即代码”，对多种跨境流动方式提供

统一的留痕标准，在便利监管和审计的同时有效

降低成本。

3. 开放数据接口，便利监管机构。数据跨境

流动表面属于技术问题，背后则涉及个人隐私保

护、社会公众利益、国家安全等，监管机构需立

足于整个行业进行数据跨境流动的监管。因此，

解决方案需设计成开放接口，利于对接监管端集

中平行监测平台，以便监管机构及时掌握金融机

构的数据跨境流动情况，有效解决监管效率及成

本问题。

4. 降低系统改造运维成本，提供安全、合规、

可靠服务。随着数据跨境流动场景日益复杂化、

多样化，外资金融机构加强对跨境数据流动的合

规管控措施，对其信息系统的改造维护成本也随

之提高。解决方案部署于行业云，符合行业标准

与安全规范要求，用户资源可按需弹性扩展，提

高升级运维效率和灵活性，能有效降低经营机构

改造、使用、运维成本。

2.2 方案探索

由于外资金融机构存在开展业务多种多样，

内部 IT 建设能力参差不齐，数据接口规格难以

统一等特点，为外资机构提供数据跨境流动管理

的解决方案初衷并不是提供一种大而全且满足所

有机构需求的“万能服务”，而是要在满足监管

合规前提下，降低外资机构接入与使用成本，并

且作为服务提供方应具备一定行业中立属性，与

服务使用方无商业利益往来或业务合作，以免影

响该服务的公信力与监管中立性。

此外该方案应根据数据分类分级管理、最小

必要原则、白名单管理制度、与风险特征相匹配

的增强型管控措施等合规要求，结合外资金融机

构展业特点，通过数据加密、权限控制、操作留

痕、关键字检索等技术手段支持多场景下的数据

跨境流动，并通过统一日志、数据接口等技术更

53

探索与应用

好地支持审计和监管。

对此，我们设想的外资金融机构数据跨境流

动解决方案核心是基于上证云部署的“虚拟数据

室”服务。该服务可根据相关法律法规要求，按

照“事前可存、事中可控、事后可查”原则，对

数据的采集、存储、流动等各环节进行加密、权

限控制、操作留痕等管理，为机构提供安全、合

规的一站式数据跨境流动管理服务。具体来说，

境内外资机构将出境信息上传至上证云“虚拟数

据室”服务端，境外用户通过客户端进行受限操

作。同时，监管端可通过相关接口及时掌握数据

跨境流动情况。“虚拟数据室”服务设想系统架

构如图 1。

2.2.1 服务端

“虚拟数据室”主要为跨境数据提供脱敏、

加密、存储、赋权和留痕等功能，覆盖跨境数据

收集、存储、加工、使用等各个环节，主要功能

包括 ：

数据分类分级。根据外资经营机构开展业务

的类型、海外总部对其经营管理数据的需求以及

我国跨境数据领域的法律法规行业标准，制定跨

境数据的数据模板，对跨境数据传输的元数据、

数据字典、数据标签等进行标准化规约，便于监

测及数据分析 ；

跨境传送通道管控。提供云端文件交换模块

和用户端数据交换前置模块，在核心的数据跨境

传送通道上实现了精准管控 ；

跨境数据留痕。对于通过“虚拟数据室”完

成的数据跨境活动，系统会对已经完成跨境动作

的数据进行备份和标记，实现对应的审计留痕 ；

敏感信息扫描与出境监控告警。对数据跨境

传输行为进行内容扫描，根据事先定义的规则确

定是否存在敏感信息，并对风险事件及时发起监

控告警 ；

数据脱敏。服务提供预定义或用户自定义的

数据脱敏规则，在发起数据跨境传输行为前，用

户可以选择执行脱敏动作，避免触发敏感信息扫

描告警 ；

统一日志审计。服务对数据跨境行为进行跟

踪，记录下跨境行为的发生时间、操作人员、数

据类型、数据分级分类、原始数据等信息，并生

成操作日志，以便监控层的日志审计模块进行查

询、汇总和生成报告。

监控预警。监控模块可对用户数据操作的全

流程监控，包括账号、源地址、路径、操作类型、

时间、所属机构等每个环节进行日志留痕，提供

完整的操作溯源能力，便于日志调取和合规审计；

针对非法操作，监控模块通过设置告警规则、告

警阀值，以短信、邮件等多种形式向用户发出告

警，及时监测数据资产，确保安全可控。

使用与数据敏感性、重要性相匹配的传输方式。因此，解决方案应支持直接传输、模板传输、受限访问等

多种跨境流动方式，且相关数据的操作权限均可灵活配置，实现数据分类分级管理以及多种数据跨境流动

需求。

2.降低合规成本，提升效率。在技术的赋能下，数据跨境流动及数据访问往往具有瞬时性，同时数据

的规模化及复杂化已必将带来合规要求的推陈出新，而传统线下或半线下的合规方式难以及时、有效的识

别风险。因此，解决方案在设计时应考虑在代码中嵌入合规及监管要求，真正实现“规则即代码”，对多

种跨境流动方式提供统一的留痕标准，在便利监管和审计的同时有效降低成本。

4.开放数据接口，便利监管机构。数据跨境流动表面属于技术问题，背后则涉及个人隐私保护、社会

公众利益、国家安全等，监管机构需立足于整个行业进行数据跨境流动的监管。因此，解决方案需设计成

开放接口，利于对接监管端集中平行监测平台，以便监管机构及时掌握金融机构的数据跨境流动情况，有

效解决监管效率及成本问题。

5.降低系统改造运维成本，提供安全、合规、可靠服务。随着数据跨境流动场景日益复杂化、多样化，

外资金融机构加强对跨境数据流动的合规管控措施，对其信息系统的改造维护成本也随之提高。解决方案

部署于行业云，符合行业标准与安全规范要求，用户资源可按需弹性扩展，提高升级运维效率和灵活性，

能有效降低经营机构改造、使用、运维成本。

2.2 /0FG

由于外资金融机构存在开展业务多种多样，内部 IT 建设能力参差不齐，数据接口规格难以统一等特点，

为外资机构提供数据跨境流动管理的解决方案初衷并不是提供一种大而全且满足所有机构需求的“万能服

务”，而是要在满足监管合规前提下，降低外资机构接入与使用成本，并且作为服务提供方应具备一定行

业中立属性，与服务使用方无商业利益往来或业务合作，以免影响该服务的公信力与监管中立性。

此外该方案应根据数据分类分级管理、最小必要原则、白名单管理制度、与风险特征相匹配的增强型

管控措施等合规要求，结合外资金融机构展业特点，通过数据加密、权限控制、操作留痕、关键字检索等

技术手段支持多场景下的数据跨境流动，并通过统一日志、数据接口等技术更好地支持审计和监管。

对此，我们设想的外资金融机构数据跨境流动解决方案核心是基于上证云部署的“虚拟数据室”服务。

该服务可根据相关法律法规要求，按照“事前可存、事中可控、事后可查”原则，对数据的采集、存储、

流动等各环节进行加密、权限控制、操作留痕等管理，为机构提供安全、合规的一站式数据跨境流动管理

服务。具体来说，境内外资机构将出境信息上传至上证云“虚拟数据室”服务端，境外用户通过客户端进

行受限操作。同时，监管端可通过相关接口及时掌握数据跨境流动情况。“虚拟数据室”服务设想系统架

构如下：

图 1 ：“虚拟数据室”系统架构图 L 1MNO'(PQRSTUL

54

交易技术前沿

2.2.2 用户端

境内外资机构可根据情况选择文件上传、录

入、系统对接等多种方式数据传入方式，根据不

同的信息类型、敏感程度选择直传、模板传输、

受限访问等多种跨境流动方式，为境外用户分配

受控的访问权限。在接入方式上，境内外资机构

可通过专线（如证联网）、VPN、互联网等线路

接入，境外用户则通过互联网接入，在保障数据

传输安全前提下，满足不同接入需求。服务支持

PC 端、网页端和移动端访问，可提供数据交换

模块前置于机构内部网络，该前置模块主要满足

于机构内网信息系统与其海外总部间数据直传场

景，可根据合规和监管要求进行监测、预警与备

份。

2.2.3 监管端

“虚拟数据室”服务对跨境流动数据的存储、

流动、使用等进行全方位、统一的留痕管理，可

为审计、监管等提供直观查阅界面，并可提供

API 接口，进行满足特定规则的审计、监测、预

警和溯源功能实现。虽然目前针对外资金融机构

数据跨境监管的行业细则未出台，但长远来看，

具备能够对全行业外资机构进行统一监管审查的

平台仍具有参考意义，按照“事前可存、事中可

控、事后可查”的设计原则，一套统一的、基于

全行业的平行监测平台可及时感知机构的数据跨

境流动情况，便于执法机构监管检查、有效降低

执法成本，提高监管效率。

2.2.4 上证云

“虚拟数据室”服务底座基于上证云。上证

云是上交所技术有限责任公司面向证券、基金等

金融机构推出的云服务平台，其依托上交所技

术 T3+ 等级数据中心，使用两地三中心（上海

和北京）高可用架构，拥有成熟稳定的云技术平

台、完善的用户服务体系及丰富的安全运营管理

经验，严格遵循国家相关部门监管政策，符合行

业标准与行业安全规范要求，为金融机构提供技

术领先、稳定可靠、安全合规的云计算服务。基

于上证云可对“虚拟数据室”服务的整体容量、

集群健康状态、网络带宽、iops、延迟、存储池、

硬件服务器以及对象存储等服务状态进行监控和

运维，确保服务健康与安全。

3、总结和展望

目前，外资金融机构数量及业务规模尚处于

2.2.4 上证云

“虚拟数据室”服务底座基于上证云。上证云是上交所技术有限责任公司面向证券、基金等金融机构

推出的云服务平台，其依托上交所技术 T3+等级数据中心，使用两地三中心（上海和北京）高可用架构，

拥有成熟稳定的云技术平台、完善的用户服务体系及丰富的安全运营管理经验，严格遵循国家相关部门监

管政策，符合行业标准与行业安全规范要求，为金融机构提供技术领先、稳定可靠、安全合规的云计算服

务。基于上证云可对“虚拟数据室”服务的整体容量、集群健康状态、网络带宽、iops、延迟、存储池、

硬件服务器以及对象存储等服务状态进行监控和运维，确保服务健康与安全。

L 2 #$%VWXYZ[\\

3 ]^_`a

目前，外资金融机构数量及业务规模尚处于初始阶段，随着对外开放的深入，数据跨境流动场景日益图 2 ：上证云产品及服务能力

55

探索与应用

56

初始阶段，随着对外开放的深入，数据跨境流动

场景日益复杂化、多元化，同时，内资金融机构

在境外展业过程中也同样面临境外监管机构对数

据收集、传输、使用等的各项监管要求。因此，“虚

拟数据室”服务将进一步拓展使用场景，更好地

支持金融机构在“走出去”和“引进来”过程中

涉及的数据流动需求。未来将做好以下研究与准

备工作 ：

积极探索境外信息技术系统或模块的运行模

式，支持其本地化部署。外资金融机构出于自身

需要及展业特点，有使用境外集团的信息系统或

模块的现实需求，过程中往往涉及大量敏感的数

据跨境流动。为此，我们将积极研究此类技术系

统特性，为其境内部署提供安全、稳定的运行环

境，将需要跨境流动的敏感性数据转变为敏感度

较低的结果类、汇总类信息，在避免敏感数据的

跨境流动的同时，极大提升境内系统与境外系统

进行信息共享的便利性，有利于在符合现行法律

法规相关要求的前提下更好的实现外资机构自身

需求。

2、融合深化“虚拟数据室”服务，打通云

上服务全流程管理。伴随行业机构云上服务需求

愈发多样，上证云可根据行业机构需求，提供办

公系统、邮件系统、风控系统、业务系统、资管

数据报送系统、投行底稿管理系统以及其他业务

系统云服务，全方位、多层次、大广度覆盖行业

需求。研究将“虚拟数据室”服务组件化，根据

需要嵌入机构用户的各类应用系统中，直接参与

数据的全生命周期，打通云上产品服务全流程管

理，全面参与外资金融机构信息系统能力建设，

深入满足用户合规需求。

3、引入境外相关规则，适时开放数据接口，

探索跨境监管协作技术实现方式。目前各国对数

据跨境流动尚未形成统一、对等的监管协作机制，

我们将加强对国内外相关政策以及各国对数据跨

境流动监管方式的研究，将境外监管经验及数字

空间治理规则融入“虚拟数据室”服务，适时开

放相应的技术接口，为推动跨境监管协作做好技

术准备。

4、加强前沿技术储备，满足不同应用场景。

探索运用系统跨境部署、支付标记化（Payment

Tokenization）、区块链、隐私保护集合求交（Private

Set Intersection）、联邦学习等前沿技术，实现对

个人、企业和监管三方数据隐私保护和数据应用

之间的平衡，打造全行业通用解决方案，有效释

放行业数据红利。

交易技术前沿

本文介绍了安信证券建设网络自动化运维平台的实践经验，针对网络日常运维工作

中涉及的重复性高、或涉及大批量操作对象的操作，进行了多种方式的自动化尝试和探索。

经过几年长期坚持不懈的努力，一个可弹性扩展、功能完备的网络系统自动化运维平台

初具雏形，不仅可以自动化处理流程类申请引发的各类网络日常操作变更，还可以协助

网络管理员自动化处理各类人工难以完成的运维工作和批量操作。极大提升了工作效率，

有效降低人工操作在网络日常运维中的各种潜在风险。

安信证券网络系统自动化运维

平台建设实践

梁德汉、何洲星、武孟军 / 安信证券股份有限公司

E-mail ：liangdh@essence.com.cn hezx@essence.com.cn wumj@essence.com.cn

1、引言

作为 IT 系统运维的一部分 , 网络运维工作

大致包括三部分内容 : 系统建设、系统监控和系

统变更。其中，网络系统建设属于一次性的工作，

而系统监控和变更则贯穿于网络系统的整个生命

周期，也是网络日常运维工作的主要内容。

网络运维自动化，就是要实现网络系统的监

控和日常变更自动化。相较于其他 IT 系统，得

益于网络简单管理协议 SNMP 标准的制定和普

及，网络监控自动化实现得最早也最成熟，各种

基于 SNMP 协议的网络管理软件得到普遍应用，

实现了整个网络系统的运行性能的自动化监控，

基本上满足了网络系统日常监控需求。

然而，网络日常变更工作的自动化却是困难

重重，虽然近年来出现了许多基于 Python 的自动

57

探索与应用

58

化运维工具，诸如 Ansible 或 SaltStack，但是和

网络工程师们心目中所期望的“自动化运维”情

景还是相差甚远。可以说，网络日常变更 90%

的工作，仍然需要网络工程师通过终端登录设备

的命令行模式，逐行将命令输入的方式实施。

本文所涉及的网络运维自动化，即是指网络

日常变更这部分工作的自动化实现。同时，作为

监控系统的补充，也包括少部分属于监控系统未

能实现的监控功能，例如特定设备性能指标的日

常巡检。网络系统的建设、日常运行性能指标监

控，不属于本文自动化运维讨论的范畴。

2、网络运维工作特点

网络日常运维工作种类繁多，涉及到的网络

设备更是五花八门，有路由器、交换机、防火墙、

负载均衡等等。有的运维操作重复频率高，几乎

每天都有 ；有的操作涉及到的对象数量庞大，工

作量大。从操作结果来看，有的操作变更了设备

配置，有些操作仅仅是察看设备状态，不改变设

备配置。

（一）流程类配置变更

此类网络变更通常由申请人通过各类管理流

程发起，经过层层审批后，最终流转到网络运维

人员，根据具体需求进行变更处理。典型的例子

如防火墙访问权限开通，物理机上架时交换机端

口 VLAN 划分等。

流程类配置变更的特点是，变更由流程触发；

申请人需要提供一定的配置参数，比如源，目的

地址，交换机端口等 ；涉及到的操作对象数量不

多，但是同类的流程数量非常多，每天重复不断，

配置操作琐碎繁杂，手工操作极易疲劳出错。

（二）查询类操作

有时候运维人员需要查询现有设备的配置情

况，再决定后续的配置操作。比如，在一台防火

墙上配置一条访问策略前，需要检查相同的策略

配置是否已经存在 ；设备健康巡检时，需要输入

察看类的指令，根据返回结果检查自己关注的文

本信息。

查询类操作的特点是，不涉及设备配置比变

更，但是需要检查大量的文本信息，并从文本信

息中筛选出感兴趣的信息。在查询两台主机之间

的访问关系时，需要处理的设备可能不止一台，

需要将访问路径中每台设备的检查结果综合考虑

后才能得出结论。对网络运维人员来说，这类操

作是非常劳神费力的。

（三）定期执行的任务

需要定期执行，每天，或每周、每月都有可

能。例如设备配置文件备份，通信线路性能巡检，

设备健康检查，设备信息定期采集等工作。

定期执行类的操作不涉及配置变更，但是涉

及的操作对象数量庞大，通常是几百甚至上千。

人工操作需要耗费大量人力和时间，且容易出错

和漏操作。

（四）批量设备操作

通常为执行某一特定任务而引发。例如密码

到期更新设备密码，修改某一范围内的设备访问

控制列表，增加特定路由条目等操作。

此类操作需要修改设备配置，同样涉及的操

作对象数量庞大。更困难的是，不同的设备下发

的配置脚本可能不同。手工操作，同样需要耗费

大量人力和时间。

（五）其它

另外，有一些运维辅助类的操作，例如各种

防火墙策略的管理操作，网络应急操作等。

总的来说，上面列举的运维操作，要么重复

性强，要么涉及的操作对象数量庞大，如果能从

传统的手工操作转化为自动化，不仅可以提高运

维效率，减少错误，降低运行风险，而且可以节

交易技术前沿

59

省大量的人力和时间成本，获取最大化收益。

3、网络自动化运维平台

2019 年，迫于应用系统访问权限开通流程

手工处理效率低下的压力 , 我司已经组织力量 ,

自行开发了一套防火墙策略自动化开通的系统，

成功将防火墙策略开通由传统手工模式转型为自

动化处理，并在 2020 年第 3 期《技术交易前沿》

作了题为《网络自动化运维系统自主研发的探索

与实践》的分享。

有了以前的自动化系统开发经验，我们决定

在现有的开发基础上，继续完善系统功能，打造

一个网络系统自动化运维平台，除了已有防火墙

策略自动化开通功能，计划实现下列功能 ：

（一）安全策略查询功能

在全网范围内，实现访问权限的任意查询功

能。具体说来，假定 h1 和 h2 是两台主机，则可

以查询 ：

① h1 能否访问 h2 的 指 定 服 务（ 例 如

HTTP）？

② h1 可以访问 h2 的哪些服务？

③ h1/h2 能访问哪些主机的哪些服务？

④ h1/h2 的指定服务能被哪些主机访问？

⑤ h1/h2 能访问哪些主机的指定服务？

⑥ h1/h2 的哪些服务能被哪些主机访问？

策略查询功能可用于申请人在提起流程前确

认访问策略是否已经开通，避免重复提流程 ；应

用系统新增客户端时，往往需要查询已有的客户

端已经开通了哪些访问权限作参考 ；还可用于访

问故障排除，高危端口攻击链分析，查找潜在风

险主机。

（二）防火墙策略管理

防火墙安全策略管理，主要实现下列功能 ：

① 根据指定条件，筛选出一台指定防火墙

中符合条件的所有策略 ；

② 分析一台防火墙中策略之间的包含或相

同关系，查找无用的地址对象和服务对象 ；

③ 批量策略迁移。根据指定条件，从防火

墙 A 中筛选出符合条件的所有策略，进行指定的

转换后，将筛选出的所有策略迁移到防火墙 B 中；

④ 垃圾策略的识别。防火墙中无用策略既

视为垃圾策略。识别垃圾策略，是根据一定时间

段内特定策略的命中匹配数确定。例如，如果 3

个月内，某条策略的命中数为 0，则可以认为该

策略为垃圾策略，后续公示后可作删除处理。

（三）统一地址对象

统一地址对象功能，目的为了简化防火墙策

略申请和部署。主要解决 ：

① 个人办公 / 交易终端的地址改变，导致

原来申请的访问权限需要全部重新申请一遍。这

样不仅增加了工作量，还会增加垃圾策略数量 ；

② 应用系统内，一组相同功能的主机，往

往具有相同的访问策略。当需要增加组中成员时，

往往需要先查询现有主机的访问权限，然后再申

请新增成员的访问权限，费时费力 ；

③ 一组用于特定目的的主机 IP，数量多，

需要在多台防火墙进行部署。如果需要增减组成

员时，需要在多台设备上进行操作，非常麻烦。

统一地址对象功能，将上述主机定义为逻辑

地址对象，申请人可以直接使用地址对象来申请

访问权限。这样，当地址对象的成员变更，成员

增减时，只需要操作地址对象即可，所有用到该

地址对象的安全策略，跟随变更，极大地减少了

工作量。

（四）交换机端口配置

该功能可以根据需要，在物理机上架时，对

选定的交换机接口进行配置。可以将接口划分到

指定 VLAN，或配置成 trunk 模式。

和防火墙策略配置功能类似，交换机接口

探索与应用

60

配置是基于申请人发起的物理主机上架流程进行

的，属于重复性高的日常维护类操作。机房管理

人员负责将需要的参数，如指定交换机管理 IP、

交换机接口、vlan 号、接口要求速率等参数提交，

系统在指定变更时间窗口内，统一读取，根据参

数生成不同的配置脚本，然后下发到交换机设备。

（五）定期执行类任务

定期执行类的任务包括网络设备定期配置文

件备份 , 重要核心设备接口日常运行参数检查 ( 光

衰 , 双工模式等 ), 交换机端口工作状态采集等工

作。

此类操作大多属于在设备上执行查看类命

令，然后分析返回结果，获取关注的信息，再判

断结果。由于需要执行的查看类命令各种各样，

不同的设备命令格式，返回信息都不相同，因此

实现的关键是要能够自行配置和定义执行任务所

需的各种参数，这样才能满足当有新的任务需求

时，能够快速部署实施。

（六）网络设备批量操作

网络设备批量操作，通常是指对大批量设备

进行相同或类似的配置变更，典型的例子如数据

中心所有网络设备的更新登录密码。自动化实现

的思路和基本操作步骤如下 ：

① 在纳管的设备库中筛选出一批目标设备 ；

② 配置需要下发的指令序列。如果选中的

设备使用的命令序列不一样，可以有多个命令序

列 ；

③ 如果有多个命令序列，则需要配置设备

选择命令序列的条件 ；

④ 命令序列中如果有变量，例如不同的网

络中心可能密码不一样 ；增加路由时的命令中下

一跳网关不一样等等，都可以通过定义变量来实

现。每个变量，都需要对应定义一个取值条件，

用来最终确定命令行的最终形式 ；

⑤ 根据上述配置，为每台设备生成特定格

式下发命令脚本。命令脚本就是一个普通的文本

文件，可以进行检查和手工修正 ；

⑥ 检查脚本无误后，下发到设备。

上面的操作场景，下发到设备的命令序列相

对固定的。还有一种复杂场景，假设有一个批量

操作需求 ：将所有交换机中运行状态为 down 的

接口，配置为 shut down 状态。这种操作下发到

设备的命令序列，就和单台设备中接口状态有关

了。就是说，在产生命令序列前，需要从操作对

象取回一些参数，这些参数作为生成命令序列的

输入，再最终生成正确的命令序列。

除了上述主要功能外，系统还需要具备设

备管理功能，即对纳管网络设备添加、删除、登

录方式和密码的管理等 ；支持 IPv6，即能够处理

IPv6 安全策略的处理 ；应急操作的自动化，既执

行事先定义好的应急操作脚本 ；与外部系统的接

口，可接受其它系统发送过来的流程参数，对其

它系统提供策略查询，网络接口状态查询的服务

等等功能。

4、系统架构及主要模块流程

（一）系统架构

整个系统由操作界面、事务处理和数据库三

部分组成。其中，操作界面实现系统管理和用户

输入申请流程功能 ；数据库保存各种系统数据，

包括系统自身使用的初始化配置信息，用户申请

的流程信息等 ；事务处理则完成各种系统功能，

它由一组互相独立运行的服务组成，每个服务完

成不同的系统功能。事务处理的启动可以由定时

器触发，也可以由操作界面的命令按钮触发。

图 1 所示为系统的逻辑架构图。

系统核心功能在业务处理模块中实现。各个

业务模块相互独立，互不影响，单个功能模块可

以随时启动和停止，提供了一种类似“微服务”

的架构，各个模块通过数据库和文件服务器共享

数据。这种架构的特点是灵活且容易扩展，只要

交易技术前沿

61

由新的业务需求，只需开发新的功能模块并添加

进去即可。

（二）访问权限申请处理流程

申请人通过流程审批系统入口，输入要求的

参数并提交。其中，所有的参数被保存到自动化

系统的流程数据库中，流程在流程审批系统中继

续流转直至审批完毕，审批结果会传输到自动化

系统。自动化系统中的每个提交的流程，根据不

同的审批结果，有 同的审批结果，有“待审批”、“审批通过”、“审

批未通过”等几个状态。

凡是审批通过的流程，自动化系统在每天指

定的变更时间窗口内，间隔一定的时间，读取状

态为“审批通过”的流程，按照图 的流程，按照图 2 所示步骤进

行处理 ：

（三）交换机端口配置

交换机端口配置完成物理主机上架时接入

整个系统由操作界面、事务处理和数据库三部分组成。其中，操作界面实现

系统管理和用户输入申请流程功能；数据库保存各种系统数据，包括系统自身使

用的初始化配置信息，用户申请的流程信息等；事务处理则完成各种系统功能，

它由一组互相独立运行的服务组成，每个服务完成不同的系统功能。事务处理的

启动可以由定时器触发，也可以由操作界面的命令按钮触发。

图 1 所示为系统的逻辑架构图。

图 1 网络系统自动化运维系统逻辑架构图

系统核心功能在业务处理模块中实现。各个业务模块相互独立，互不影响，

单个功能模块可以随时启动和停止，提供了一种类似“微服务”的架构，各个模

块通过数据库和文件服务器共享数据。这种架构的特点是灵活且容易扩展，只要

由新的业务需求，只需开发新的功能模块并添加进去即可。

（二）访问权限申请处理流程

申请人通过流程审批系统入口，输入要求的参数并提交。其中，所有的参数

被保存到自动化系统的流程数据库中，流程在流程审批系统中继续流转直至审批

完毕，审批结果会传输到自动化系统。自动化系统中的每个提交的流程，根据不

同的审批结果，有“待审批”、“审批通过”、“审批未通过”等几个状态。

凡是审批通过的流程，自动化系统在每天指定的变更时间窗口内，间隔一定

图 1 ：网络系统自动化运维系统逻辑架构图

的时间，读取状态为“审批通过”的流程，按照图 2 所示步骤进行处理：

图 2 访问权限流程处理

（三）交换机端口配置

交换机端口配置完成物理主机上架时接入交换机的端口配置，包括将交换机

图 2 ：访问权限流程处理

探索与应用

62

交换机的端口配置，包括将交换机指定端口划分

到指定 VLAN，或将指定端口配置为 trunk 模式。

同时，还要考虑是否有指定速率需求等因素。

同样地，自动化系统只保存完成配置需要的

流程编号、选中的交换机端口、VLAN id 等参数。

这些参数申请人员在流程审批系统中输入，并

由流程审批系统通过外部系统接口传给自动化系

统。

自动化系统在每天指定的变更时间窗口内，

间隔一定的时间，读取流程数据，按照图 3 所示

步骤进行处理 ：

（四）策略查询

假定需要查询主机 假定需要查询主机 H1 能否访问 H2 的 TCP

80 端口，处理思路是首先确定 端口，处理思路是首先确定 H1 访问 H2 的完

整路径中经过了几台防火墙，并查询每台防火墙

中是否都开放了 中是否都开放了 H1 能否访问 H2 的 TCP 80 端口

的策略，如是，则满足访问条件。简单起见，这

里只介绍单台防火墙设备中查询是否满足 H1 访

问 H2 的 TCP 80 端口的策略，且不考虑 端口的策略，且不考虑 NAT 的

情况。

首先按顺序比较防火墙中每条策略，只要存

在一条源地址包含 / 等于 H1，同时目的地址包

含 / 等于 H2，同时服务包含 ，同时服务包含 / 等于 TCP 80 端口，

并且安全域、动作都满足条件的策略，即可以认

为该防火墙满足条件。

由于防火墙匹配策略时是按照先后顺序进行

的，因此要考虑动作是“禁止”的策略。如果先

匹配到了 1 条动作为禁止访问的安全策略，既可

以终止查询，认为该防火墙不满足访问条件。

图 4 所示是在单台防火墙设备中查询是否有

满足条件策略的处理流程 ：

5、系统运行效果

在克服了人手不足、疫情影响等不利因素后，

经过近两年的艰苦努力，基本上实现了预期目标，

一个功能完备的网络系统自动化运维平台初具

雏形，日常运维工作中，涉及到重复性强、或操

作对象数量庞大的操作类型，自动化覆盖率达到

90% 以上。以下是自动化运维平台功能以及日常

应用中实际例子展示，因访问权限自动化开通系

统在以前的文章中已经由详细介绍，这里不再讲

述。

（一）策略查询

策略查询可以查询当前防火墙上主机之间的

访问策略开放情况。根据查询模式的不同，分为

六种查询模式 ；根据指定主机所处交易网、非交

易网和互联网不同，提供多种查询范围。图 5 所

示为系统提供的策略查询模式。

图 6 所示是查询办公网的一台指定主机（10.

是否有指定速率需求等因素。

同样地，自动化系统只保存完成配置需要的流程编号、选中的交换机端口、

VLAN id 等参数。这些参数申请人员在流程审批系统中输入，并由流程审批系统

通过外部系统接口传给自动化系统。

自动化系统在每天指定的变更时间窗口内，间隔一定的时间，读取流程数据，

按照图 3 所示步骤进行处理：

图 3 交换机端口配置流程处理

（四）策略查询

假定需要查询主机 H1 能否访问 H2 的 TCP 80 端口，处理思路是首先确定

图 3 ：交换机端口配置流程处理

交易技术前沿

63

时目的地址包含/等于 H2，同时服务包含/等于 TCP 80 端口，并且安全域、动作

都满足条件的策略，即可以认为该防火墙满足条件。

由于防火墙匹配策略时是按照先后顺序进行的，因此要考虑动作是“禁止”

的策略。如果先匹配到了 1 条动作为禁止访问的安全策略，既可以终止查询，认

为该防火墙不满足访问条件。

图 4 所示是在单台防火墙设备中查询是否有满足条件策略的处理流程：

图 4 策略查询处理流程

五、系统运行效果

在克服了人手不足、疫情影响等不利因素后，经过近两年的艰苦努力，基本

上实现了预期目标，一个功能完备的网络系统自动化运维平台初具雏形，日常运

维工作中，涉及到重复性强、或操作对象数量庞大的操作类型，自动化覆盖率达

到 90%以上。以下是自动化运维平台功能以及日常应用中实际例子展示，因访问

权限自动化开通系统在以前的文章中已经由详细介绍，这里不再讲述。

（一）策略查询

策略查询可以查询当前防火墙上主机之间的访问策略开放情况。根据查询模

式的不同，分为六种查询模式；根据指定主机所处交易网、非交易网和互联网不

同，提供多种查询范围。图 5 所示为系统提供的策略查询模式。

图 4 ：策略查询处理流程

图 5 查询模式

图 6 所示是查询办公网的一台指定主机（10.x.x.155），能访问办公网内哪

些主机的 22 端口的操作界面。

图 6 查询操作

图 7 所示是查询结果的一部分，列出的主机都开了 TCP 22 端口服务，且指

定主机具有访问权限。

图 5 查询模式

图 6 所示是查询办公网的一台指定主机（10.x.x.155），能访问办公网内哪

些主机的 22 端口的操作界面。

图 6 查询操作

图 7 所示是查询结果的一部分，列出的主机都开了 TCP 22 端口服务，且指

定主机具有访问权限。

图 5 ：查询模式

图 6 ：查询操作

探索与应用

x.x.155），能访问办公网内哪些主机的 22 端口的

操作界面。

图 7 所示是查询结果的一部分，列出的主机

都开了 TCP 22 端口服务，且指定主机具有访问

权限。

图 6 查询操作

图 7 所示是查询结果的一部分，列出的主机都开了 TCP 22 端口服务，且指

定主机具有访问权限。

图 7 策略查询结果

（二）交换机端口自动化配置

图 7 ：策略查询结果

（二）交换机端口自动化配置

因物理机上架流程在 CMDB 系统中流转，

因此交换机端口配置流程中的参数由申请人在

CMDB 系统中输入并提交，如图 8 所示。

每个工作日的下午 4 点开始，系统自行扫描

数据库，读出需要处理的参数，生成交换机配置

脚本保存，下发后，将下发结果保存到另外一个

下发结果文件中。

该模块自 2022 年 10 月份试运行，至今处

理了近 200 条流程，配置端口约 700 个，可以配

置指定端口到某指定 VLAN，或配置为 trunk 口。

为确保配置的交换机端口准确性，系统提供给一

线人员选择的可用交换机端口，必须满足连续两

天状态为 down。

图 9 所为一份根据配置参数生成的配置脚本

文件样例。

图 8 CMDB 交换机接口参数输入界面

每个工作日的下午 4 点开始，系统自行扫描数据库，读生成交换机配置脚本保存，下发后，将下发结果保存到另外一该模块自 2022 年 10 月份试运行，至今处理了近 200 条流个，可以配置指定端口到某指定 VLAN，或配置为 trunk 口。机端口准确性，系统提供给一线人员选择的可用交换机端口，状态为 down。

图 9 所为一份根据配置参数生成的配置脚本文件样例。

图 9 交换机端口配置脚本文件

因物理机上架流程在 图 10 所示图 9 ： 交换机端口配置脚本文件 是一份下发结果文件样例。 CMDB 系统中流转，因此交换机端口配置流程中的参

数由申请人在 CMDB 系统中输入并提交，如图 8 所示。

图 8 CMDB 交换机接口参数输入界面

每个工作日的下午 4 点开始，系统自行扫描数据库，读出需要处理的参数，

生成交换机配置脚本保存，下发后，将下发结果保存到另外一个下发结果文件中。

该模块自 2022 年 10 月份试运行，至今处理了近 200 条流程，配置端口约 700

个以配置指定端到某指定或配置为为确保配置的交换图 8 ：CMDB 交换机接口参数输入界面

64

交易技术前沿

图 10 所示是一份下发结果文件样例。

图 10 配置脚本下发反馈文件

（三）定期执行类任务

定期执行类任务目前完成/每天：

l 纳管设备配置文件备份

l 路由器/交换机物理接口信息采集

l 指定的设备巡检任务

l 指定的清理指令

目前纳管的设备主要为我司三个数据中心的近 600 台防火墙、交换机和路由

器。物理接口信息的采集主要完成接口的工作状态、所属 VLAN 等基础信息，

为其它应用提供数据支持；指定设备巡检任务，是对重要设备进行的日常巡检，

对监控系统的一种补充。例如，重要通信线路接口的错包率、双工模式；光接口

的光衰指标检查等。指定的清理类指令，是每天对特定设备执行的一种“无害化”

指令。例如，为防止操作人员打开了设备的 debug 功能忘记关闭，可以每天在指

定时间段内执行 1 条设备关闭 debug 功能的指令。

巡检类任务实际上是在设备上执行指定的查看类指令，然后对返回的结果进

行分析，取回感兴趣的信息进行分析，并将巡检结果记录在巡检报告中。配置一

个巡检任务的界面如图 11 所示：

图 10 ：配置脚本下发反馈文件

（三）定期执行类任务

定期执行类任务目前完成 / 每天 ：

·纳管设备配置文件备份

·路由器 / 交换机物理接口信息采集

·指定的设备巡检任务

·指定的清理指令

目前纳管的设备主要为我司三个数据中心的

近 600 台防火墙、交换机和路由器。物理接口信

息的采集主要完成接口的工作状态、所属 VLAN

等基础信息，为其它应用提供数据支持 ；指定设

备巡检任务，是对重要设备进行的日常巡检，对

监控系统的一种补充。例如，重要通信线路接口

的错包率、双工模式；光接口的光衰指标检查等。

指定的清理类指令，是每天对特定设备执行的一

种“无害化”指令。例如，为防止操作人员打开

了设备的 debug 功能忘记关闭，可以每天在指定

时间段内执行 1 条设备关闭 debug 功能的指令。

巡检类任务实际上是在设备上执行指定的查

看类指令，然后对返回的结果进行分析，取回感

兴趣的信息进行分析，并将巡检结果记录在巡检

报告中。配置一个巡检任务的界面如图 11 所示 ：

上述配置的巡检任务，是检查指定交换机的

指定接口 eth1/1，检查项为该接口的 CRC 参数和

双工工作模式。其中，CRC 参数为实数类型，值

不等于 0 即为异常，双工模式是字符串类型，值

不等于 full-duplex 或 Full-duplex 即为异常。

另外，采集到的基础信息，还可以进一步做

图 11 配置一个巡检任务

上述配置的巡检任务，是检查指定交换机的指定接口 eth1/1，检查项为该接

口的 CRC 参数和双工工作模式。其中，CRC 参数为实数类型，值不等于 0 即为

异常，双工模式是字符串类型，值不等于 full-duplex 或 Full-duplex 即为异常。

图 11 ：配置一个巡检任务

65

探索与应用

“增值化”处理。例如，可以将昨天状态为 处理。例如，可以将昨天状态为 up，

今天状态为 down 的接口信息筛选出来，也可以

将状态为 err_disable 的接口筛选出来，提供给技

术人员做进一步分析处理。

（四）策略管理

防火墙策略管理实现了垃圾策略清理，敏感

策略筛选，策略批量迁移和策略优化分析等功能。

绝大部分策略管理的功能是基于防火墙配置文件

进行操作的，因此可以不限制操作时间段。图 12

所示为策略管理操作界面。

1、策略筛选

策略筛选功能 , 可以在指定防火墙中 , 根据

事先定义的筛选条件 , 找出满足条件的策略。最

常见的应用场景是，当网络结构发生变化，一

个网段不再使用，那么这个网段有关的安全策略

理论上都成了垃圾策略，都应该清理掉。另外，

出于安全考虑，我们希望找出一些目的地址是

Any，或服务是 Any，或服务是一些高位端口的

安全策略进行安全评估。

图 13 所示为筛选策略输入筛选条件的系统

界面。

首先需要指定防火墙，然后输入筛选条件。

通常，筛选出的策略需要做进一步的操作，例如

删除，这时，可以将选中的策略提取关键字，比

如策略 ID，和指定的前、后缀字符串组成删除

命令，这样就可以很容易地顺带生成删除策略的

脚本。目的安全域，源、目的地址，服务端口以

及策略动作，都可以做为筛选的条件设定，设置

的多个条件是与的关系，只有满足全部筛选条件

的策略才会被选中。

源、目的地址作为筛选条件时，可以指定一

图 11 配置一个巡检任务

上述配置的巡检任务，是检查指定交换机的指定接口 eth1/1，检查项为该接

口的 CRC 参数和双工工作模式。其中，CRC 参数为实数类型，值不等于 0 即为

异常，双工模式是字符串类型，值不等于 full-duplex 或 Full-duplex 即为异常。

另外，采集到的基础信息，还可以进一步做“增值化”处理。例如，可以将

昨天状态为 up，今天状态为 down 的接口信息筛选出来，也可以将状态为

err_disable 的接口筛选出来，提供给技术人员做进一步分析处理。

（四）策略管理

防火墙策略管理实现了垃圾策略清理，敏感策略筛选，策略批量迁移和策略

优化分析等功能。绝大部分策略管理的功能是基于防火墙配置文件进行操作的，

因此可以不限制操作时间段。图 12 所示为策略管理操作界面。

图 12 策略管理界面

1、策略筛选

策略筛选功能,可以在指定防火墙中,根据事先定义的筛选条件,找出满足条

件的策略。最常见的应用场景是，当网络结构发生变化，一个网段不再使用，那

么这个网段有关的安全策略理论上都成了垃圾策略，都应该清理掉。另外，出于

安全考虑，我们希望找出一些目的地址是 Any，或服务是 Any，或服务是一些高

位端口的安全策略进行安全评估。

图 13 所示为筛选策略输入筛选条件的系统界面。

图 12 ：策略管理界面

图 13 ：策略筛选操作

图 13 策略筛选操作

首先需要指定防火墙，然后输入筛选条件。通常，筛选出的策略需要做进一

步的操作，例如删除，这时，可以将选中的策略提取关键字，比如策略 ID，和

指定的前、后缀字符串组成删除命令，这样就可以很容易地顺带生成删除策略的

66

交易技术前沿

个地址集合，设置策略地址等于或包含指定地址，

或指定地址包含策略地址的条件。还可以限定策

略中对应地址包含的地址个数，以提高匹配精确

度。

假定因网络拓扑变化，地址段 192.168.1.0/24

这 个 网 段 取 消， 需 要 将 源 地 址 全 部 包 含 在

192.168.1.0/24 这个段的策略挑选出来并删除，则

按图 13 设定条件筛选策略即可。

再假定删除策略的命令格式如下 ：

delete rule01

其 中，delete 为 删 除 策 略 命 令 关 键 字，

rule01 是策略 ID，则前缀字符串设置为 ，则前缀字符串设置为 delete，

后缀设置为空，既可以根据所有筛选出的策略，

顺带生成删除策略的脚本文本。

2、 批量迁移

在设备更换、网络拓扑变更等情况下，通常

需要将原有设备中的一部分安全策略提取出来，

并将其迁移到另外一台设备中。手工迁移策略的

做法通常是简单粗暴编辑设备配置文件，提取策

略，再拷贝到目标设备中。因为很多安全策略中

涉及到源、目的设备中的地址对象、服务对象等

配置情况，因此手工方式不仅仅效率低下，且极

易出错。自动化系统根据设定的策略迁移条件，

代替人工自动完成上述工作。图 14 所示为策略

批量迁移操作界面。

首先需要设定源、目的防火墙 IP，再设定

源设备选择策略条件，即选择哪些策略需要迁移，

设置条件同“策略筛选”。然后设置变换条件，

即允许将迁移的策略做一定的变换，可以变更源、

目的安全域，源、目的地址和服务端口。图中所

示为将迁移策略中的源地址做转换 ：设定一个地

址集合，迁移后的策略中源地址可以排除这个地

址集合，也可以只保留这个地址集合，排除其它

地址。

假定想要将一台防火墙中，策略中源安全域

为 trust，目的安全域为 untrust 的策略全部迁移到

另外一台防火墙中，同时，迁移后的策略中源地

址为 192.168.1.0/24 这个网段内的地址去掉，保

留其它地址，则筛选条件中设定源、目的安全域

分别是 trust 和 untrust，变换条件中设置源地址限

定值为 192.168.1.0/24 192.168.1.0/24，操作模式为“排除”即可。

假设源设备中有如下两条选中的策略 ：

rule 1

action permit

src-zone \"trust\"

dst-zone \"untrust\"

src-ip 192.168.1.5/32

dst-ip 202.0.0.2

图 14 策略批量迁移

首先需要设定源、目的防火墙 IP，再设定源设备选择策略条件，即选择哪

些策略需要迁移，设置条件同“策略筛选”。然后设置变换条件，即允许将迁移

的策略做一定的变换，可以变更源、目的安全域，源、目的地址和服务端口。图

中为将移策略中的地做转换定个地集合移的策略中图 14 ：策略批量迁移

67

探索与应用

service \"http\"

exit

rule 2

action permit

src-zone \"trust\"

dst-zone \"untrust\"

src-ip 192.168.1.15/32

src-ip 192.168.2.15/32

dst-ip 202.0.0.2

service \"http\"

exit

那么迁移后，rule 1 排除操作后，源地址为空，

成为一条非法策略，不再迁移 ；rule 2 去掉源地

址 192.168.1.15/32 后再迁移，最终生成的迁移脚

本为 ：

rule

action permit

src-zone \"trust\"

dst-zone \"untrust\"

src-ip 192.168.2.15/32

dst-ip 202.0.0.2

service \"http\"

exit

（五）通用批量操作

批量设备操作根据下发的配置复杂度不同，

分为几种情况 ：

·单一固定命令集合

·多个固定命令集合

·单一带可变参数命令集合

·多个带可变参数命令集合

·复杂命令集合

单一命令集合是所有操作设备对象下发统同

一个命令脚本，多个则是不同设备操作对象下发

的脚本不同 ；固定命令集合是指脚本是固定不变

的，例如所有设备更新为相同的超级用户密码 ；

带参数的命令集合则是脚本中命令格式下发前需

要按要求替换 ；复杂命令集合是指，需要从被操

作对象取回一定的参数，根据这些参数动态生成

命令脚本。

自动化系统实际上是根据要求和设定条件，

为每一台操作设备对象生成配置脚本并保存，然

后通过下发脚本功能批量下发。图 15 所示为设

备批量操作界面。

篇幅所限，这里只介绍复杂脚本批量生成的

界面。如图 16 所示。

首先要指定操作设备对象集合。这里输入的

参数，系统组合后形成一个 SQL 语句的条件部分，

从纳管设备库中筛选出操作对象。任务名指定对

选中的设备执行的操作，并获取指定的参数集合，

这些参数集合作为指定配置模板的输入参数，最

终为每个选中设备动态生成一个配置脚本。这里

的配置脚本是系统自定义格式，操作人员可以审

核并随时修改，然后通过下发配置操作下发到指

定设备中。

一个典型的应用场景是，将某个数据中心

所有的接入层交换机，状态为 down 的网络接

口，设置为 shut down。假定某台接入交换机

（192.168.1.1 192.168.1.1）通过执行“获取所有接口状态 获取所有接口状态”任

务，得到其中以下接口状态为 down:

rule

action permit

src-zone \"trust\"

dst-zone \"untrust\"

src-ip 192.168.2.15/32

dst-ip 202.0.0.2

service \"http\"

exit

（五）通用批量操作

批量设备操作根据下发的配置复杂度不同，分为几种情况：

l 单一固定命令集合

l 多个固定命令集合

l 单一带可变参数命令集合

l 多个带可变参数命令集合

l 复杂命令集合

单一命令集合是所有操作设备对象下发统同一个命令脚本，多个则是不同设

备操作对象下发的脚本不同；固定命令集合是指脚本是固定不变的，例如所有设

备更新为相同的超级用户密码；带参数的命令集合则是脚本中命令格式下发前需

要按要求替换；复杂命令集合是指，需要从被操作对象取回一定的参数，根据这

些参数动态生成命令脚本。

自动化系统实际上是根据要求和设定条件，为每一台操作设备对象生成配置

脚本并保存，然后通过下发脚本功能批量下发。图 15 所示为设备批量操作界面。

图 15 批量操作界面

篇幅所限，这里只介绍复杂脚本批量生成的界面。如图 16 所示。

图 15 ：批量操作界面

68

交易技术前沿

Eth1/22,Etrh1/30,Eth1/35

另外一台接入交换机（192.168.1.2）以下接

口状态为 down:

Eth1/2,Etrh1/3

则最终生成的配置脚本如图 17 所示 ：

图 16 复杂脚本生成界面

首先要指定操作设备对象集合。这里输入的参数，系统组合后形成一个 SQL

语句的条件部分，从纳管设备库中筛选出操作对象。任务名指定对选中的设备执

行的操作，并获取指定的参数集合，这些参数集合作为指定配置模板的输入参数，

最终为每个选中设备动态生成一个配置脚本。这里的配置脚本是系统自定义格

式，操作人员可以审核并随时修改，然后通过下发配置操作下发到指定设备中。

一个典型的应用场景是，将某个数据中心所有的接入层交换机，状态为 down

的网络接口，设置为 shut down。假定某台接入交换机（192.168.1.1）通过执行

“获取所有接口状态”任务，得到其中以下接口状态为 down:

Eth1/22,Etrh1/30,Eth1/35

另外一台接入交换机（192.168.1.2）以下接口状态为 down:

Eth1/2,Etrh1/3

则最终生成的配置脚本如图 17 所示：

图 17 结果配置脚本

其中，@@开头的语句为自定义的脚本操作控制语句。这个脚本文件就是一

个普通的文本文件，经过复核后，就可以通过下发操作，批量下发到指定设备。

（六）统一地址对象

统一地址对象有 3 类，个人终端、地址组和系统类。个人终端类只能有一个

IP 地址，地址组类可以有多个地址，但必须处于同一安全域，系统类地址成员不

限，可以根据需要随意配置。

1、 创建地址对象

图 17 ：结果配置脚本

其中，@@ 开头的语句为自定义的脚本操作

控制语句。这个脚本文件就是一个普通的文本文

件，经过复核后，就可以通过下发操作，批量下

发到指定设备。

（六）统一地址对象

统一地址对象有 3 类，个人终端、地址组和

系统类。个人终端类只能有一个 IP 地址，地址

组类可以有多个地址，但必须处于同一安全域，

系统类地址成员不限，可以根据需要随意配置。

1、 创建地址对象

申请人可以自行创建地址对象，但只可以创

建个人终端或地址组类型的地址对象。创建的地

址对象可以是私有，只有自己可以使用 ；也可以

公有，所有人都可以使用。图 18 所示为创建地

址对象界面。

图 18 地址对象创建

创建好的地址对象，就可以用来申请安全策略了。后续，如果变化，或地址组成员发生增减，只需要提申请流程修改地址对象就更前相同的访问权限了。图 19 所示为地址对象变更操作界面。

图 18 ：地址对象创建

创建好的地址对象，就可以用来申请安全策

略了。后续，如果个人终端地址变化，或地址组

成员发生增减，只需要提申请流程修改地址对象

就可以具备和变更前相同的访问权限了。图 19

所示为地址对象变更操作界面。

图 15 批量操作界面

篇幅所限，这里只介绍复杂脚本批量生成的界面。如图 16 所示。

图 16 ：复杂脚本生成界面

69

探索与应用 图 18 地址对象创建

创建好的地址对象，就可以用来申请安全策略了。后续，如果个人终端地址

变化，或地址组成员发生增减，只需要提申请流程修改地址对象就可以具备和变

更前相同的访问权限了。图 19 所示为地址对象变更操作界面。

图 19 地址对象变更

图 19 所示的流程申请，将地址对象 test 地址变更为 192.168.1.230/32。

2、系统地址对象

系统地址对象一般由网络管理员创建并管理使用，禁止在策略申请中使用。

系统地址对象应用在特殊的安全策略中，且此类策略数量少，只须手工配置即可。

通常频繁变化的是地址对象中的成员。图 20 所示为系统地址对象管理界面。

图 19 ：地址对象变更

图 19 所示的流程申请，将地址对象 test 地

址变更为 192.168.1.230/32。

2、系统地址对象

系统地址对象一般由网络管理员创建并管理

使用，禁止在策略申请中使用。系统地址对象应

用在特殊的安全策略中，且此类策略数量少，只

须手工配置即可。通常频繁变化的是地址对象中

的成员。图 20 所示为系统地址对象管理界面。

图 18 地址对象创建

创建好的地址对象，就可以用来申请安全策略了。后续，如果个人终端地址

变化，或地址组成员发生增减，只需要提申请流程修改地址对象就可以具备和变

更前相同的访问权限了。图 19 所示为地址对象变更操作界面。

图 19 地址对象变更

图 19 所示的流程申请，将地址对象 test 地址变更为 192.168.1.230/32。

2、系统地址对象

系统地址对象一般由网络管理员创建并管理使用，禁止在策略申请中使用。

系统地址对象应用在特殊的安全策略中，且此类策略数量少，只须手工配置即可。

通常频繁变化的是地址对象中的成员。图 20 所示为系统地址对象管理界面。

图 20 ：系统地址对象管理

例如，互联网边界防火墙通常会定义一组高

危地址，此类地址被禁止访问内网。因为这个高

危地址组成员是动态变化的，因此经常需要对它

进行修改。如果有多台边界防火墙，就相当繁琐

了。因此，这样一组高危地址，可以将其定义为

一个系统地址对象使用、管理。

6、结束语

我司自 2020 年网络自动化项目一期上线运

行至今，系统已经由一个单一处理访问权限申请

流程的自动化处理工具，演变为一个可弹性扩展、

功能完备的网络系统自动化运维平台。不仅可以

自动化处理流程类申请引发的各类网络日常操作

变更，还可以协助网络管理员自动化处理各类人

工难以完成的运维工作和批量操作。

系统平台仍以处理访问权限开通申请流程为

主要功能，图 21 所示为系统上线以来每年处理

的访问条目数量增长情况。

图 20 系统地址对象管理

例如，互联网边界防火墙通常会定义一组高危地址，此类地址被禁止访问内

网。因为这个高危地址组成员是动态变化的，因此经常需要对它进行修改。如果

有多台边界防火墙，就相当繁琐了。因此，这样一组高危地址，可以将其定义为

一个系统地址对象使用、管理。

六、结束语

我司自 2020 年网络自动化项目一期上线运行至今，系统已经由一个单一处

理访问权限申请流程的自动化处理工具，演变为一个可弹性扩展、功能完备的网

络系统自动化运维平台。不仅可以自动化处理流程类申请引发的各类网络日常操

作变更，还可以协助网络管理员自动化处理各类人工难以完成的运维工作和批量

操作。

系统平台仍以处理访问权限开通申请流程为主要功能，图 21 所示为系统上

线以来每年处理的访问条目数量增长情况。

图 21 访问权限流程开通数量变化

由于我司近年来办公场地和数据中心屡次搬迁，导致每年涉及的网络访问权

限申请剧增，2022 年自动化系统共处理了 22117 条访问申请，包括节假日在内平均每天自动化处理 60 多条，基本上做到了流程“审批通过当天处理完毕”。

剔除因为网络变更导致的基础数据配置错误以及申请人提交信息错误等原因，生

成配置脚本、下发脚本处理过程正确率达到了 100%。

安全策略管理功能 2022 年上线试运行，至今已经完成 6 次因网络拓扑变更设备更新引发的策略批量迁移，迁移策略总数约 700 条；清除因弃用网段、相互

包含的垃圾策略 1100 多条；通过策略优化分析功能，清除无用地址对象、服务

对象 4 批次，自动化操作处理准确率高于 99%。

应用自动化系统的意义不仅仅在于节省了人力，更重要的是自动化可以完成

许多人工不能完成，或者说很难完成的工作。比如说在配置安全策略时，确定一

条策略是否在目标设备上已经实现或被包含，是一件非常费时费力的事情，特别

是当目标设备中的策略条数很多时，更加难以处理。又比如，只要配置足够强的

算力，自动化系统可以在业务空闲时间段对所有网络设备接口进行自动化巡检

筛选出潜在风险点。这种操作需要登录大量设备，输入命令并处理天量的返回文

本，再生成巡检报告。类似操作如果换成人力，是几乎不可能完成的任务。

图 21 ：访问权限流程开通数量变化

由于我司近年来办公场地和数据中心屡次

搬迁，导致每年涉及的网络访问权限申请剧增，

2022 年自动化系统共处理了 22117 条访问申请，

包括节假日在内，平均每天自动化处理 60 多条，

基本上做到了流程“审批通过当天处理完毕”。

剔除因为网络变更导致的基础数据配置错误以及

申请人提交信息错误等原因，生成配置脚本、下

发脚本处理过程正确率达到了 100%。

安全策略管理功能 2022 年上线试运行，至

今已经完成 6 次因网络拓扑变更、设备更新引发

的策略批量迁移，迁移策略总数约 700 条 ；清除

因弃用网段、相互包含的垃圾策略 1100 多条 ；通

过策略优化分析功能，清除无用地址对象、服务

对象 4 批次，自动化操作处理准确率高于 99%。

应用自动化系统的意义不仅仅在于节省了人

力，更重要的是自动化可以完成许多人工不能完成，

或者说很难完成的工作。比如说在配置安全策略

时，确定一条策略是否在目标设备上已经实现或被

包含，是一件非常费时费力的事情，特别是当目标

设备中的策略条数很多时，更加难以处理。又比如，

只要配置足够强的算力，自动化系统可以在业务空

闲时间段对所有网络设备接口进行自动化巡检，筛

选出潜在风险点。这种操作需要登录大量设备，输

入命令并处理天量的返回文本，再生成巡检报告。

类似操作如果换成人力，是几乎不可能完成的任务。

70

交易技术前沿

兴业证券应用性能监控系统

建设思路、方法和实践

刘洋、石良生、杨洋 / 兴业证券股份有限公司 金融科技部 福建 福州 350001

E-mail ：yangyang2021@xyzq.com.cn

1、建设背景

业务的复杂化和上层技术的升级是推动监

控手段不断发展的原动力。企业级监控体系要面

对众多信息化系统拓扑组成的复杂 IT 经营服务，

其实际运行工作更为复杂，再加上微服务、云原

生、函数计算等新技术的不断涌现，传统的日志

加系统监控的手段已经难以充分地满足企业的监

控需求。

系统监控领域由于其复杂性和普适性，是各

类技术服务商和开源组织竞相角逐的战场，流行

方案层出不求、创新不断。通过开源或商用工具

快速构建监控能力是小型团队的常规路径，但对

于有大量存量系统、或自研与外购混合、或多中

心、或多技术栈的中型以上企业来说，明确监控

体系建设质量目标，通过目标倒推监控工具和管

理流程规划相比较而言更加具有长期成效。无论

技术如何发展更迭、企业业务特性如何包罗万象，

抛开层出不穷的新潮概念和流行方案，从主要监

控步骤（日志采集－〉发送告警－〉故障定位）

来看，衡量企业监控体系健壮性的关键指标依然

是 ：监控覆盖度、告警有效性和可观测性。

随着微服务框架在公司内的逐步推广落地，对分布式架构下的产线可观测性提出了

新的挑战。业务的复杂化，给性能监控的内容和方式也提出了新的要求。同时，为数众多

的外采的烟囱式的信息系统，使得应用的性能监控更加困难。本文针对公司现状，对应用

性能监控系统的解决方案进行探讨，通过自主研发一套全新的应用性能监控系统，在传统

的分布式链路跟踪技术的基础之上，实现丰富的接入方案，灵活的监控配置，动态的指标

拉取，边缘化的数据存储，解决了公司产线观测的问题，在大量自研及外采系统中进行实

践，取得了良好的效果。

71

探索与应用

72

1.1. 监控覆盖度

具体包括监控目标的覆盖度和监控指标的覆

盖度。监控目标包括 ：应用、系统（运行环境）、

数据库、中间件、硬件（机房、服务器、空调）、

网络等。监控指标可以分为系统指标、应用性能

指标、日志、业务指标等。通过设置标准化的监

控管理流程和角色来保障监控覆盖度是非常有必

要的。与之相反的是运动式、缺乏监督和检查点、

缺乏针对性评估。

对于存量系统，打通 CMDB（Configuration

Management Database，配置管理数据库）与监控

系统，将 CMDB 系统清单和监控系统的指标清单

匹配整合，通过日志有无采集来判断覆盖度是一

种比较理想化的存量覆盖度检查手段。

1.2. 告警有效性

当完成监控覆盖度后最重要的工作便是维持

告警的有效性，包括去除无效日志、告警降噪、

触达审计等。告警有效性保障是监控体系最容易

忽略的一环，有效性的缺失会导致整个监控机制

的失灵。因此，通过管理机制和协同工具来保障

每条告警的有效触达和被充分重视是至关重要的

监控工作之一。

1.3. 可观测性

不同于狭义监控侧重于观察特定指标，可观

测性则是强调通过分析系统生成的数据理解推演

出系统内部的状态。可观测性是面向复杂分布式

系统的现代监控理念，以应对云原生、大规模分

布式协同等现代技术场景，同时，可观测性也是

产线排障的重要支点。

可观测性内容非常多，是监控体系中最具技

术挑战性的部分。大致可以分类为日志（Logging）、

指标（Metrics）和追踪（Tracing）。全链路的可

观测建设牵涉到诸多方面，易入门难完善，同时

也间接反映企业整体 IT 研发实力水平。

1.4. 金融类企业其他要求

1.4.1. 多技术栈、多外购系统

不同于一个技术栈撸到底的互联网公司，大

多数券商非常依赖技术供应商，其技术栈容易发

散，同时还存在大量的外购黑盒系统，部分还自

带监控子系统。对自研和外购的分层支持、对于

不同技术栈系统保有一致性的监控水准需要一个

不求、创新不断。通过开源或商用工具快速构建监控能力是小型团队的常规路径，但对于有大量存量系统、

或自研与外购混合、或多中心、或多技术栈的中型以上企业来说，明确监控体系建设质量目标，通过目标

倒推监控工具和管理流程规划相比较而言更加具有长期成效。无论技术如何发展更迭、企业业务特性如何

包罗万象，抛开层出不穷的新潮概念和流行方案，从主要监控步骤（日志采集－〉发送告警－〉故障定位）

来看，衡量企业监控体系健壮性的关键指标依然是：监控覆盖度、告警有效性和可观测性。

图 1：监控系统关键指标

8989 )*<=>7

图 1 ：监控系统关键指标

交易技术前沿

73

系统性解决方案。

1.4.2. 数据脱敏与研发协同

对于瀑布类的项目和外购系统，运维团队掌

控力较强。但敏捷交付项目往往更需要开发人员

参与稳定性的维护。因此，在开发和运维两类角

色中进行数据隔离同时保证高效协同也是完善监

控体系的重要内容。

1.4.3. 系统的健壮性

金融类企业的信息系统，涉及交易、资金等

许多环节。对于监控系统的引入，需要非常谨慎。

必须要保证监控系统不能对原有系统的正常运行

造成影响。

2、建设思路

企业监控体系的搭建可以分为监控接入管

理、监控服务、监控平台三项工作。良好的监

控体系需要依赖可靠的平台系统和有效的工作制

度，系统与制度缺一不可。

检查手段。

?9 @ABC'7

当完成监控覆盖度后最重要的工作便是维持告警的有效性，包括去除无效日志、告警降噪、触达审计

。告警有效性保障是监控体系最容易忽略的一环，有效性的缺失会导致整个监控机制的失灵。因此，通

管理机制和协同工具来保障每条告警的有效触达和被充分重视是至关重要的监控工作之一。

D9 EFG'7

不同于狭义监控侧重于观察特定指标，可观测性则是强调通过分析系统生成的数据理解推演出系统内

的状态。可观测性是面向复杂分布式系统的现代监控理念，以应对云原生、大规模分布式协同等现代技

场景，同时，可观测性也是产线排障的重要支点。

可观测性内容非常多，是监控体系中最具技术挑战性的部分。大致可以分类为日志（Logging）、指标

Metrics）和追踪（Tracing）。全链路的可观测建设牵涉到诸多方面，易入门难完善，同时也间接反映

业整体 IT 研发实力水平。

H9 IJKL\"MNOP7

4.1. 多技术栈、多外购系统

不同于一个技术栈撸到底的互联网公司，大多数券商非常依赖技术供应商，其技术栈容易发散，同时

存在大量的外购黑盒系统，部分还自带监控子系统。对自研和外购的分层支持、对于不同技术栈系统保

一致性的监控水准需要一个系统性解决方案。

4.2. 数据脱敏与研发协同

对于瀑布类的项目和外购系统，运维团队掌控力较强。但敏捷交付项目往往更需要开发人员参与稳定

的维护。因此，在开发和运维两类角色中进行数据隔离同时保证高效协同也是完善监控体系的重要内容。

4.3. 系统的健壮性

金融类企业的信息系统，涉及交易、资金等许多环节。对于监控系统的引入，需要非常谨慎。必须要

证监控系统不能对原有系统的正常运行造成影响。

-./07

企业监控体系的搭建可以分为监控接入管理、监控服务、监控平台三项工作。良好的监控体系需要依

可靠的平台系统和有效的工作制度，系统与制度缺一不可。

图 2 ：项目建设思路

2.1. 监控接入管理

监控接入管理是指通过清晰有效的工作机

制，在研发交付流程环节保障监控覆盖面，避免

死角。具体包括健全开发侧相关规范，在架构评

审环节增加监控评估内容等 ；

2.1.1. 监控接入规范

监控接入规范旨在指导开发人员在应用设计

阶段就考虑监控方面的需求。从日志、异常、探

活和业务事件等方面着手主动适配企业监控体

系。因此，我们需要制定可行的相关规范，包括

日志输出规范、异常处理规范、应用探活规范、

事件上报规范。

2.1.2. 监控覆盖评估

2.1.2.1. 监控基线

针对各类监控对象建立监控配置基线，由监

控探针按照配置进行日志采集。基线的目的是面

向常规系统监控和基础应用监控而设，可以满足

绝大多数监控需求。基线往往由系统运维设立并

打入交付设施中，与交付系统打通往往可以支持

全自动化生效。同时，监控基线应该能自然支持

市面上主流的中间件、基础设施。

2.1.2.2. 监控评估

监控评估主要在架构评审、采购评审等阶

段开展，面向的是非基线约定的监控角度。除了

复核常规监控配置基线外，主要评估内容为高可

用自动切换等变更告警、关键 Transaction 监控、

可观测性评估等，具有较大的自主性和主观性。

因此有必要建立专人专岗，在研发交付的流程中

设定专门评估环节来保障有效落地。

2.2. 监控服务

监控服务描述的是应用接入企业监控体系

后，将监控告警和观测平台打包提供给项目人员

的一系列标准化服务的集合，是由监控团队提供

给开发和应用运维人员。

2.2.1. 告警工单服务

告警与工单的结合不但标准化了异常处理过

程，同时也可以作为项目的应急处置能力的评估

指标。自动化告警工单在监控体系中的价值包括：

·对告警进行归纳和分类

·无干扰地统计处理时长

·度量 IT 团队的异常处置能力

·在制度上有助于收敛无效告警

2.2.2. 观测支撑服务

监控团队集中建设的观测平台是面向项目组

探索与应用

74

提供合规、脱敏的产线运行状况的观测通道。观

测支撑服务支持开发工程师、应用运维两类角色，

分别提供不同程度的数据查看权限。同时，也支

持应用运维即时授权给开发查看更多内容。可观

测的数据包括 ：

·日志数据

·统计数据

·分析数据

·事件数据

·交互数据

2.3. 监控平台

当下市场上流行的监控平台层出不穷，对于

金融企业需要重点兼顾的需求包括有 ：

·多语言支持

·多中心支持

·与 IT 资产管理、交付工具、工单系统、

成效分析系统的打通和集成

抛开各类流行监控产品的上层能力图谱的影

响，从监控工具的运行流程来看，监控平台可以

拆分为如下阶段性子系统或模块。

3、技术方案

3.1. 产品定位

目 前 公 司 拥 有 包 括 Zabbix、Prometheus、

日志易、动环监控、天旦、APM（Application

Performance Management，应用性能管理）、服务

治理以及其他专项监控设施共同组成的多方案

企业监控体系。监控不同于通信框架，可以适

度冗余，通过有限交错的监控工具可以增加容

错率。目前公司在应用层监控采用以 Prometheus

为主，以自研的 APM、服务治理为补充的整体

结构。

图 3 ：监控平台链路

l 与 IT 资产管理、交付工具、工单系统、成效分析系统的打通和集成

抛开各类流行监控产品的上层能力图谱的影响，从监控工具的运行流程来看，监控平台可以拆分为如

下阶段性子系统或模块。

图 3：监控平台链路

图 4：监控平台功能细分

D9 YZ2[7

D989 \\]^_7

l 与 IT 资产管理、交付工具、工单系统、成效分析系统的打通和集成

抛开各类流行监控产品的上层能力图谱的影响，从监控工具的运行流程来看，监控平台可以拆分为如

下阶段性子系统或模块。

图 3：监控平台链路

图 4：监控平台功能细分

D9YZ2[图 4 ：监控平台功能细分

交易技术前沿

75

3.2. 系统设计

3.2.1. 整体设计

兴业证券 APM 是一个主要基于 Java 开发而

成的分布式系统集，其包括多个子系统。系统设

计的整体目标为高吞吐、海量存储，但在数据一

致性、备份冗余方面需求不高。除了支持异地部

署外，还需要强调对业务监控的支撑力度，同时

在企业监控体系的定位上做了下沉，APM 新增

的事件处理编排能力旨在构建灵活的业务监控能

力，与其他监控设施做差异化服务。

3.2.2. 事件分析与存储

APM 以灵活配置事件消息处理流程为目的，

基于 Kafka 流式处理能力自主设计了的可编排日

志分析器。对于上报的事件消息，根据事件的

“type”关键字，区分不同的事件类型。对不同的

事件类型，可以配置一个或多个有序的事件消息

处理器。分析器服务将会根据配置的分析器，按

需对事件消息进行处理。链条处理器目前定义了

6 种基础的处理器。

处理后的事件消息，如需要持久化，则最

终会通过特定类型的分析器落入到 3 类存储设施

中。其中，BitCask 是我们基于 Riak 分布式数据

库论文，结合边缘存储的理念做的自主实现。存

储结构为 Key->Value List，具有较高的吞吐能力。

目前我们测试数据结果为 ：单机 4 核 8G 的机械

硬盘下 QPS 为 10K/S 左右。

D989 \\]^_7

目前公司拥有包括 Zabbix、Prometheus、日志易、动环监控、天旦、APM（Application Performance

Management，应用性能管理）、服务治理以及其他专项监控设施共同组成的多方案企业监控体系。监控不

同于通信框架，可以适度冗余，通过有限交错的监控工具可以增加容错率。目前公司在应用层监控采用以

Prometheus 为主，以自研的 APM、服务治理为补充的整体结构。

图 5 ：产品边界

图 5：产品边界

D9?9 +,.`7

3.2.1. 整体设计

兴业证券 APM 是一个主要基于 Java 开发而成的分布式系统集，其包括多个子系统。系统设计的整体

目标为高吞吐、海量存储，但在数据一致性、备份冗余方面需求不高。除了支持异地部署外，还需要强调

对业务监控的支撑力度，同时在企业监控体系的定位上做了下沉，APM 新增的事件处理编排能力旨在构建

灵活的业务监控能力，与其他监控设施做差异化服务。

图 6：产品整体设计

3.2.2. 事件分析与存储

APM 以灵活配置事件消息处理流程为目的，基于 Kafka 流式处理能力自主设计了的可编排日志分析器。

对于上报的事件消息，根据事件的“type”关键字，区分不同的事件类型。对不同的事件类型，可以配置

一个或多个有序的事件消息处理器。分析器服务将会根据配置的分析器，按需对事件消息进行处理。链条图 6 ：产品整体设计

探索与应用

76

图 6：产品整体设计

3.2.2. 事件分析与存储

APM 以灵活配置事件消息处理流程为目的，基于 Kafka 流式处理能力自主设计了的可编排日志分析器。

对于上报的事件消息，根据事件的“type”关键字，区分不同的事件类型。对不同的事件类型，可以配置

一个或多个有序的事件消息处理器。分析器服务将会根据配置的分析器，按需对事件消息进行处理。链条

处理器目前定义了 6 种基础的处理器。

图 7 ：事件分析处理器

图 7：事件分析处理器

图 8：日志分析流程

表 1：分析器功能说明

图 8 ：日志分析流程

我们针对 APM 事件消息详情数据写入频率

远高于查询，且写入后不会修改的特点，将调用

链详情数据写入本地 BitCask，运用边缘存储的

方式，极大地节约了网络带宽资源，同时提高了

数据的安全性和隐私保护。

3.2.3. 数据查询服务

APM 数据查询服务是实现了类似 MyBatis 的

在线模板录入生成数据查询能力的服务，是 APM

重要的子系统。其查询脚本存储在 Zookeeper 中，

同时脚本采用 Velocity 模板，有很强的灵活性，

可以根据模板及传入参数形成复杂的数据检索逻

辑。同时对外开放了检索的 RPC 服务与 HTTP 接

口，周边系统开发人员可以通过接口提取采集到

的 Metrics 数据。

通过灵活的事件分析存储、数据查询配置，

我们就可以将业务与能力解耦。将业务交给接入

方，使得他们在享受 APM 基础能力的同时，能

够根据自己的需求，定义特殊的事件，做定制化

的事件分析和分析结果查询，形成完整的自闭环。

这种方式能极大提升系统的数据权限隔离和隐私

保护能力，使之在金融行业内，能发挥更大的能

动性。

交易技术前沿

77

Set 集合分析器 通过配置的 keys 进行去重，对新数据进行转发

Tracing 跟踪分析器 将调用链数据持久化写入 BitCask

Alarm 告警分析器 触发告警

处理后的事件消息，如需要持久化，则最终会通过特定类型的分析器落入到 3 类存储设施中。其中，

BitCask 是我们基于 Riak 分布式数据库论文，结合边缘存储的理念做的自主实现。存储结构为 Key->Value

List，具有较高的吞吐能力。目前我们测试数据结果为：单机 4 核 8G 的机械硬盘下 QPS 为 10K/S 左右。

我们针对 APM 事件消息详情数据写入频率远高于查询，且写入后不会修改的特点，将调用链详情数据

写入本地 BitCask，运用边缘存储的方式，极大地节约了网络带宽资源，同时提高了数据的安全性和隐私

保护。

3.2.3. 数据查询服务

APM 数据查询服务是实现了类似 MyBatis 的在线模板录入生成数据查询能力的服务，是 APM 重要的子

系统。其查询脚本存储在 Zookeeper 中，同时脚本采用 Velocity 模板，有很强的灵活性，可以根据模板及

传入参数形成复杂的数据检索逻辑。同时对外开放了检索的 RPC 服务与 HTTP 接口，周边系统开发人员可以

通过接口提取采集到的 Metrics 数据。

图 9：数据查询服务执行流程

通过灵活的事件分析存储、数据查询配置，我们就可以将业务与能力解耦。将业务交给接入方，使得

他们在享受 APM 基础能力的同时，能够根据自己的需求，定义特殊的事件，做定制化的事件分析和分析结

果查询，形成完整的自闭环。这种方式能极大提升系统的数据权限隔离和隐私保护能力，使之在金融行业

分析器 功能 说明

MySQL MySQL 分析器 将数据插入 mysql 数据库

InfluxDB InfluxDB 分析器 将数据插入 influxdb 数据库

Counting 计数分析器 按参数，对指定维度，指定关键字进行计数

Set 集合分析器 通过配置的 keys 进行去重，对新数据进行转发

Tracing 跟踪分析器 将调用链数据持久化写入 BitCask

Alarm 告警分析器 触发告警

处理后的事件消息，如需要持久化，则最终会通过特定类型的分析器落入到 3 类存储设施中。其中，

BitCask 是我们基于 Riak 分布式数据库论文，结合边缘存储的理念做的自主实现。存储结构为 Key->Value

List，具有较高的吞吐能力。目前我们测试数据结果为：单机 4 核 8G 的机械硬盘下 QPS 为 10K/S 左右。

我们针对 APM 事件消息详情数据写入频率远高于查询，且写入后不会修改的特点，将调用链详情数据

写入本地 BitCask，运用边缘存储的方式，极大地节约了网络带宽资源，同时提高了数据的安全性和隐私

保护。

3.2.3. 数据查询服务

APM 数据查询服务是实现了类似 MyBatis 的在线模板录入生成数据查询能力的服务，是 APM 重要的子

系统。其查询脚本存储在 Zookeeper 中，同时脚本采用 Velocity 模板，有很强的灵活性，可以根据模板及

传入参数形成复杂的数据检索逻辑。同时对外开放了检索的 RPC 服务与 HTTP 接口，周边系统开发人员可以

通过接口提取采集到的 Metrics 数据。

图 9：数据查询服务执行流程

通过灵活的事件分析存储、数据查询配置，我们就可以将业务与能力解耦。将业务交给接入方，使得

他们在享受 APM 基础能力的同时，能够根据自己的需求，定义特殊的事件，做定制化的事件分析和分析结

果查询，形成完整的自闭环。这种方式能极大提升系统的数据权限隔离和隐私保护能力，使之在金融行业

表 1 ：分析器功能说明

图 9 ：数据查询服务执行流程

内，能发挥更大的能动性。

图 10：事件消息数据流图

3.2.4. 跨中心同步

公司系统有多个数据中心，有的系统仅部署在一个数据中心，有的系统部署在多个数据中心，就会导

致我们有跨数据中心的请求。而数据中心间的网络资源，往往是比较紧缺的，APM 的数据量又是比较大的，

因此，我们设计了一种跨数据中心的调用链存储和查询方式，能够极大地减少跨中心请求时伴随着的跨中

心调用链数据上报。

图 10 ：事件消息数据流图

3.2.4. 跨中心同步

公司系统有多个数据中心，有的系统仅部署

在一个数据中心，有的系统部署在多个数据中心，

就会导致我们有跨数据中心的请求。而数据中心

间的网络资源，往往是比较紧缺的，APM 的数据

量又是比较大的，因此，我们设计了一种跨数据

中心的调用链存储和查询方式，能够极大地减少

跨中心请求时伴随着的跨中心调用链数据上报。

探索与应用

4、成果及展望

本文主要介绍了兴业证券在应用性能管理系

统上的建设思路和实践。不同于外购和开源方案，

系统在复杂模块使用开源组件的基础上，自主研

发底层存储和事件分析查询能力，使系统对公司

技术栈和潜在技术变更有着更好的兼容性和适应

能力。

该系统在公司内上线运行以来，经过反复地

迭代升级，对特殊业务、协议、中间件的陆续支

持，已取得了良好的效果，成为应用性能管理提

供了有力的抓手。

4.1. 监控体系

兴业证券自研的 APM 系统自 2018 年上线以

来，经过不断地完善和优化，在性能上和兼容性

上持续提升，目前已成为应用性能监控的标准方

案，配合 Prometheus 的中间件监控和 Zabbix 的主

机监控，共同构成了我司完整的监控体系。

4.2. 减少带宽占用

基于新中心网络规划进行技术攻关解决跨中

心海量数据同步和传输网络带宽占用问题。在今

年的新中心搬迁工作中，对于新中心的两地三中

心网络规划，自研 APM 发挥了完全自主可控的

优势，攻关了应用运行数据集中存储与异地网络

带宽限制，满足数据就近存储，减少跨机房数据

同步，禁止应用跨机房数据上报的需求，实现多

中心部署并支持弹性伸缩，避免对机房间网络带

宽的占用。

4.3. 支持自研与外购系统

APM 凭借多语言支持，目前已成为中台、

优理宝、兴证 e 家、财富梦工厂和集团 CRM 等

几大自研产品线运行观测和生产排障的主要工

具，外购系统接入率也在持续提升，极大提高开

发运维人员性能监测、故障感知与定位的效率。

4.4. 未来展望

未来，我们会持续深耕，探索现场还原、风

险预判、自动剖析等更前瞻的观测能力，探索边

缘存储方案和应用场景，持续沉淀和输出相关的

通用方案，提供更加丰富的观测指标和能力，为

产线系统稳定运行保驾护航。

3.2.4. 跨中心同步

公司系统有多个数据中心，有的系统仅部署在一个数据中心，有的系统部署在多个数据中心，就会导

致我们有跨数据中心的请求。而数据中心间的网络资源，往往是比较紧缺的，APM 的数据量又是比较大的，

因此，我们设计了一种跨数据中心的调用链存储和查询方式，能够极大地减少跨中心请求时伴随着的跨中

心调用链数据上报。

图 11：跨中心同步部署架构

H9 abcde7

本文主要介绍了兴业证券在应用性能管理系统上的建设思路和实践。不同于外购和开源方案，系统在

复杂模块使用开源组件的基础上，自主研发底层存储和事件分析查询能力，使系统对公司技术栈和潜在技

术变更有着更好的兼容性和适应能力。

该系统在公司内上线运行以来，经过反复地迭代升级，对特殊业务、协议、中间件的陆续支持，已取

得了良好的效果，成为应用性能管理提供了有力的抓手。

H989 )*f+7

兴业证券自研的 APM 系统自 2018 年上线以来，经过不断地完善和优化，在性能上和兼容性上持续提

升，目前已成为应用性能监控的标准方案，配合 Prometheus 的中间件监控和 Zabbix 的主机监控，共同构

图 11 ：跨中心同步部署架构

78

交易技术前沿

姜洪涛、宫珂、于慧 / 上交所技术有限责任公司 上海 200120

E-mail ：htjiang@sse.com.cn

一种可扩展的多因素访问控制方法

及实践

1、背景

互联网技术的发展促进了用户对于系统使用

便利性的需求，那些部署在受保护网络下的信息

系统逐步显露出不能有效满足用户需求的问题，

在需求驱动之下需要向更加开放的外部网络环境

延伸。而外部网络环境的多样性和复杂性会对信

息系统的受保护内容带来新的挑战，因此有效的

访问控制手段是这些系统首先要具备的能力。

在运维领域，随着 DevOps 等模式的发展，

去后台操作的白屏化运维逐步成为趋势。而且，

在一体化运营、业务与技术联动等企业数字化转

型的战略安排下，传统的在 ECC 内完成的运维

工作，尤其是不涉及敏感数据和不影响生产运行

的相关工作，在逐步向日常办公环境甚至是互联

网环境延伸。为避免产生数据泄露及破坏到生产

安全运行，需要通过访问控制技术来保证只对授

权用户、授权场景开放服务。

2、问题与挑战

对于访问控制模型，较为普遍常见的就是基

于角色的 RBAC(Role Based Access Control)，通过

赋予不同角色不同权限来进行访问控制。对于一

在数字化转型浪潮下，通过科技创新和数字化变革寻找发展动能已成为必然趋势。

在企业内部，各业务条线正在朝着信息化、自动化、智能化的方向转变，对 IT 带来前所

未有的挑战。应用系统需要更加开放，提供更好的使用体验，同时需要必要的访问控制技

术，保证在非保护网络环境下的信息安全，而且对于存量系统来说存在一定的改造成本。

本文就如何构建多因素可扩展的访问控制能力进行阐述，并结合自动化运维平台的需求，

提出比较合适的实践方法。

79

探索与应用

80

个主体（往往是组织内的人员或者某个客户端），

可以拥有多个角色以应对多种不同的操作权限。

RBAC 与组织内的实际业务组织架构相近，往往

是系统首选的原生访问控制技术，但随着环境变

化，尤其是对于安全防御要求提高，需给系统增

加更多因素的访问控制技术，如用户使用环境、

访问途径、时间段等。

在现有系统上增加访问控制因素，一种简单

明了的做法是将相关控制逻辑嵌入到代码中，比

如在认证模块或代码段增加访问控制相关代码。

该方法虽然有效但也存在两个比较明显的局限

性。一方面，增加访问控制逻辑需要重构现有模

块，且与系统现有功能有强耦合性，甚至在一些

特殊情况下，一些系统不一定能支持新版本的上

线。另一方面，其它系统无法复用相关能力，容

易形成竖井式的功能孤岛。访问控制技术在一个

组织当中，属于安全基础设施，是一种基础能力，

应具备在各系统中共享的能力。在实现上，可以

借鉴中台建设的思路，在架构上以松耦合方式独

立于各应用系统，且又能满足不同应用系统的差

异化需求。

本文介绍一种针对基于互联网架构的，可扩

展地增加访问控制的方法，而且通过在构建自动

化运维平台的实践场景验证，其不仅可以按需灵

活地添加控制因素和策略，而且能够加强现有存

量系统的访问控制能力。

3、方法阐述

运维操作白屏化是 DevOps 重要组成部分，

敏态的运维过程带来了收益，但也同样带来了一

系列安全隐患，比如 ：网络攻击、运维操作权限

控制和审计问题等。因而，需要一个可灵活配置、

扩展的访问控制模块，为运维操作、故障问题排

查提供安全防护，为提高安全运行的能力提供支

撑。

3.1 总体架构

本文中设计的多因素访问控制模块，在架构

上与后端各应用节点间独立解耦。原则上用户访

问行为均基于策略进行控制，策略规则支持动态

扩展，灵活设置。总体架构如图 1 所示。

用户的访问请求首先经过负载均衡层，此时

3 ./9:

运维操作白屏化是 DevOps 重要组成部分，敏态的运维过程带来了收益，但也同样带来了一系列安全

隐患，比如：网络攻击、运维操作权限控制和审计问题等。因而，需要一个可灵活配置、扩展的访问控制

模块，为运维操作、故障问题排查提供安全防护，为提高安全运行的能力提供支撑。

3.1 ;<=>

本文中设计的多因素访问控制模块，在架构上与后端各应用节点间独立解耦。原则上用户访问行为均

基于策略进行控制，策略规则支持动态扩展，灵活设置。总体架构如图 1 所示：

图 1 总体架构图

用户的访问请求首先经过负载均衡层，此时请求首先被转发到访问控制层进行验证，只有验证通过的

请求才会被转发到后端服务。负载均衡层的该转发能力将访问控制可动态插入到请求处理链条，与流量镜

像不同的是，这里是一个同步顺序执行关系。

访问控制模块在整体架构中处于用户和目标应用服务器之间，属于保护代理结构，用户请求经过此模

块完成策略规则的校验判定后可根据判定结果获取到对应的目标服务器资源原则上访问控制模块是图 1 ：总体架构图

交易技术前沿

81

请求首先被转发到访问控制层进行验证，只有验

证通过的请求才会被转发到后端服务。负载均衡

层的该转发能力将访问控制可动态插入到请求处

理链条，与流量镜像不同的是，这里是一个同步

顺序执行关系。

访问控制模块在整体架构中处于用户和目标

应用服务器之间，属于保护代理结构，用户请求经

过此模块完成策略规则的校验判定后，可根据判定

结果获取到对应的目标服务器资源。原则上，访问

控制模块是无状态的，不负责代理应用的用户认证

和权限校验，只做多因素访问控制，但在实现过程

中，也可将鉴权作为检查因素之一，如设置一条策

略校验当前用户请求的 Token 是否有效。

3.2 基于 nginx auth_request 实现负载

转发能力

基于总体架构方法，需要一个可以拦截用

户请求并进行鉴权的工具，将用户的请求都先发

送给鉴权服务进行访问控制鉴权后，根据鉴权结

果决定是否可以访问应用服务。拦截用户请求最

直接的方式是从负载均衡层进行拦截，前期调研

发现常用的负载均衡工具 Nginx 提供的 ngx_http_

auth_request_module 模块，可以协助实现访问拦

截和访问鉴权。在 Nginx 访问 ServiceA/B 的配置

里添加 auth_request /auth 参数后，当用户访问

ServiceA/B 时，Nginx 会先将请求拦截，先请求 /

auth 访问鉴权模块 Auth Service，当 Auth Service

返回鉴权通过时允许继续访问，Nginx 会将请求

发给 Service A/B; 当鉴权服务返回无访问权限时，

可以将指定的拦截页面返回给用户。

基于 Nginx 中 auth_request 模块进行访问控

制逻辑改造，可将访问控制模块与现有功能模块

分离，将用户请求内容拦截到访问控制模块进行

统一鉴权，使控制策略逻辑内聚到访问控制模块

中，其他服务只做 Token 有效性验证，轻量级适

配现有权限控制体系，从而，降低存量系统访问

控制改造成本。

3.3 访问控制模块

本文设计的访问控制模块架构主要分为三

层 ：策略层、执行层、校验层。架构设计如图 2

所示。

以协助实现访问拦截和访问鉴权。在 Nginx 访问 ServiceA/B 的配置里添加 auth_request /auth 参数后，当用

户访问 ServiceA/B 时，Nginx 会先将请求拦截，先请求/auth 访问鉴权模块 Auth Service，当 Auth Service 返

回鉴权通过时允许继续访问，Nginx 会将请求发给 Service A/B;当鉴权服务返回无访问权限时，可以将指定

的拦截页面返回给用户。

基于 Nginx 中 auth_request 模块进行访问控制逻辑改造，可将访问控制模块与现有功能模块分离，将

用户请求内容拦截到访问控制模块进行统一鉴权，使控制策略逻辑内聚到访问控制模块中，其他服务只做

Token 有效性验证，轻量级适配现有权限控制体系，从而，降低存量系统访问控制改造成本。

图 2 基于 Nginx 中 auth_request 模块访问控制架构图

3.3 *+,-HI

本文设计的访问控制模块架构主要分为三层：策略层、执行层、校验层。架构设计如图 2 所示，

图 3 策略执行架构图

整体架构主要遵循两点设计原则：1.策略层中支持多种访问控制策略的逻辑组合；2.执行层可针对不同

的访问要素类型设计不同的执行器，执行器在验算策略过程中需保证幂等性，执行器支持组合使用。在实

现过程中可基于实际业务需求设置策略组合，各执行器对策略组合进行幂等运算后，输出校验结果的布尔

值。

图 3 ：策略执行架构图

的拦截页面返回给用户。

基于 Nginx 中 auth_request 模块进行访问控制逻辑改造，可将访问控制模块与现有功能模块分离，将

用户请求内容拦截到访问控制模块进行统一鉴权，使控制策略逻辑内聚到访问控制模块中，其他服务只做

Token 有效性验证，轻量级适配现有权限控制体系，从而，降低存量系统访问控制改造成本。

图 2 基于 Nginx 中 auth_request 模块访问控制架构图

3.3 *+,-HI

本文设计的访问控制模块架构主要分为三层：策略层、执行层、校验层。架构设计如图 2 所示，

图 3 策略执行架构图

整体架构主要遵循两点设计原则：1.策略层中支持多种访问控制策略的逻辑组合；2.执行层可针对不同

的访问要素类型设计不同的执行器，执行器在验算策略过程中需保证幂等性，执行器支持组合使用。在实

现过程中可基于实际业务需求设置策略组合，各执行器对策略组合进行幂等运算后，输出校验结果的布尔

值。

运维平台使用人员、场景复杂，需要一个灵活的、多维度的访问控制策略，基于此，我们设计一种可

灵活拆分、组合的策略执行方法。首先，将系统所需的访问控制规则打散，变成一个个不易分割的原子策

略，比如：基于访问时间限制的控制策略 P1，可以拆分成允许访问的时间区间；基于访问地点限制的控制

策略 P2，可以拆分成允许访问的指定 ip 或者指定 ip 前缀；基于访问请求路径限制的控制策略 P3,可以拆分

成允许访问的指定 url 路径或者 url 路径前缀；基于角色的访问控制策略 P4,可以拆分成角色或者角色集合

图 2 ：基于 Nginx 中 auth_request 模块访问控制架构图

探索与应用

82

整体架构主要遵循两点设计原则 ：1. 策略层

中支持多种访问控制策略的逻辑组合 ；2. 执行层

可针对不同的访问要素类型设计不同的执行器，

执行器在验算策略过程中需保证幂等性，执行器

支持组合使用。在实现过程中可基于实际业务需

求设置策略组合，各执行器对策略组合进行幂等

运算后，输出校验结果的布尔值。

运维平台使用人员、场景复杂，需要一个灵

活的、多维度的访问控制策略，基于此，我们设

计一种可灵活拆分、组合的策略执行方法。首先，

将系统所需的访问控制规则打散，变成一个个不

易分割的原子策略，比如 ：基于访问时间限制的

控制策略 P1，可以拆分成允许访问的时间区间 ；

基于访问地点限制的控制策略 P2，可以拆分成

允许访问的指定 ip 或者指定 ip 前缀 ；基于访问

请求路径限制的控制策略 P3, 可以拆分成允许访

问的指定 url 路径或者 url 路径前缀 ；基于角色的

访问控制策略 P4, 可以拆分成角色或者角色集合

等等，然后借助组合数学中交集、并集的概念，

将不同子策略组合在一起，实现复杂的策略的组

合，例如 ：公式（1）可以表示允许 P4 角色的用

户在 P1 时间区间内使用 时间区间内使用 P2 指定 ip 访问请求路

径 P3，而公式（2）可以表示允许 ）可以表示允许 P4 角色在 P1

时间区间内访问请求链接，或允许 P4 角色在 P2

指定 ip 访问请求链接，或允许 访问请求链接，或允许 P4 角色访问 P3

请求路径。

等等，然后借助组合数学中交集、并集的概念，将不同子策略组合在一起，实现复杂的策略的组合，例如：

公式（1）可以表示允许 P4 角色的用户在 P1 时间区间内使用 P2 指定 ip 访问请求路径 P3，而公式（2）可

以表示允许 P4 角色在 P1 时间区间内访问请求链接，或允许 P4 角色在 P2 指定 ip 访问请求链接，或允许

P4 角色访问 P3 请求路径。

P1 ∩ P2 ∩ P3 ∩ P4 （1）

(P1 ∪ P2 ∪ P3) ∩ P4 （2）

运维平台对操作审计信息十分敏感，基于本文访问控制方式改造后，所有审计信息都可以在访问控制

鉴权模块进行采集，统一记录访问人、访问路径、请求设备（ip 地址或者 MAC 地址）、请求时间等信息，

为审计工作提供便利。

基于策略组合实现的访问控制方式相较于传统单独基于角色的访问控制方式更为灵活，它允许通过流

程审批临时增加或者变动访问控制策略，这种访问控制策略变动的方式，无需更新系统版本，也无需进行

其他适配性改造，就可以达到临时赋权访问的效果，而流程审批记录也可以为审计记录留痕，例如可以让

某一用户通过 IP 为 1.1.1.1 的主机在 1 个小时区间内访问指定资源。

图 4 策略方法层次架构图

4 JK12

4.1 LMNOP&12QR

随着运维工作数字化转型的推进，运维平台能力变得更加开放和服务化，如何做好访问控制，避免敏

感信息泄露和对安全运行造成破坏是不得不解决的一个难题。基于本文所述架构，在存量运维平台上进行

了相关实践验证，根据运维实际场景要求，提取所需访问控制元素，内聚在新建的访问控制模块中，对用

户请求进行统一拦截鉴权。

从生产安全性考虑，运维平台不能在公网直接开放使用，但如遇紧急情况时，运维人员、二线支持人

员短时间内无法赶去现场，极有可能导致定位问题、处置问题时间被拖长，给生产安全运行带来隐患。基

于本文多因素访问控制方法，通过访问控制策略，临时访问策略审批流程，可允许运维人员、二线支持人

员在指定设备终端在持有 CA 证书的情况下在指定时间区间内访问运维平台，及时定位、解决生产问题。

本系统基于 SpringBoot 框架创建了一个访问控制服务 AC Service，用于进行访问控制权限校验。并在

控制层 AuthController 开放了一个权限校验接口/auth，供 Nginx auth_request 模块拦截鉴权，该接口实际调

（1）

等等，然后借助组合数学中交集、并集的概念，将不同子策略组合在一起，实现复杂的策略的组合，例如：

公式（1）可以表示允许 P4 角色的用户在 P1 时间区间内使用 P2 指定 ip 访问请求路径 P3，而公式（2）可

以表示允许 P4 角色在 P1 时间区间内访问请求链接，或允许 P4 角色在 P2 指定 ip 访问请求链接，或允许

P4 角色访问 P3 请求路径。

P1 ∩ P2 ∩ P3 ∩ P4 （1）

(P1 ∪ P2 ∪ P3) ∩ P4 （2）

运维平台对操作审计信息十分敏感，基于本文访问控制方式改造后，所有审计信息都可以在访问控制

鉴权模块进行采集，统一记录访问人、访问路径、请求设备（ip 地址或者 MAC 地址）、请求时间等信息，

为审计工作提供便利。

基于策略组合实现的访问控制方式相较于传统单独基于角色的访问控制方式更为灵活，它允许通过流

程审批临时增加或者变动访问控制策略，这种访问控制策略变动的方式，无需更新系统版本，也无需进行

其他适配性改造，就可以达到临时赋权访问的效果，而流程审批记录也可以为审计记录留痕，例如可以让

某一用户通过 IP 为 1.1.1.1 的主机在 1 个小时区间内访问指定资源。

图 4 策略方法层次架构图

4 JK12

4.1 LMNOP&12QR

随着运维工作数字化转型的推进，运维平台能力变得更加开放和服务化，如何做好访问控制，避免敏

感信息泄露和对安全运行造成破坏是不得不解决的一个难题。基于本文所述架构，在存量运维平台上进行

了相关实践验证，根据运维实际场景要求，提取所需访问控制元素，内聚在新建的访问控制模块中，对用

户请求进行统一拦截鉴权。

从生产安全性考虑，运维平台不能在公网直接开放使用，但如遇紧急情况时，运维人员、二线支持人

员短时间内无法赶去现场，极有可能导致定位问题、处置问题时间被拖长，给生产安全运行带来隐患。基

于本文多因素访问控制方法，通过访问控制策略，临时访问策略审批流程，可允许运维人员、二线支持人

员在指定设备终端在持有 CA 证书的情况下在指定时间区间内访问运维平台，及时定位、解决生产问题。

本系统基于 SpringBoot 框架创建了一个访问控制服务 AC Service，用于进行访问控制权限校验。并在

控制层 AuthController 开放了一个权限校验接口/auth，供 Nginx auth_request 模块拦截鉴权，该接口实际调

（2）

运维平台对操作审计信息十分敏感，基于本

文访问控制方式改造后，所有审计信息都可以在

访问控制鉴权模块进行采集，统一记录访问人、

访问路径、请求设备（ip 地址或者 MAC 地址）、

请求时间等信息，为审计工作提供便利。

基于策略组合实现的访问控制方式相较于

传统单独基于角色的访问控制方式更为灵活，它

允许通过流程审批临时增加或者变动访问控制策

略，这种访问控制策略变动的方式，无需更新系

统版本，也无需进行其他适配性改造，就可以达

到临时赋权访问的效果，而流程审批记录也可以

为审计记录留痕，例如可以让某一用户通过 IP

为1.1.1.1的主机在1个小时区间内访问指定资源。

4、应用实践

4.1 在运维平台的实践情况

随着运维工作数字化转型的推进，运维平

台能力变得更加开放和服务化，如何做好访问控

制，避免敏感信息泄露和对安全运行造成破坏是

不得不解决的一个难题。基于本文所述架构，在

存量运维平台上进行了相关实践验证，根据运维

等等，然后借助组合数学中交集、并集的概念，将不同子策略组合在一起，实现复杂的策略的组合，例如：

公式（1）可以表示允许 P4 角色的用户在 P1 时间区间内使用 P2 指定 ip 访问请求路径 P3，而公式（2）可

以表示允许 P4 角色在 P1 时间区间内访问请求链接，或允许 P4 角色在 P2 指定 ip 访问请求链接，或允许

P4 角色访问 P3 请求路径。

P1 ∩ P2 ∩ P3 ∩ P4 （1）

(P1 ∪ P2 ∪ P3) ∩ P4 （2）

运维平台对操作审计信息十分敏感，基于本文访问控制方式改造后，所有审计信息都可以在访问控制

鉴权模块进行采集，统一记录访问人、访问路径、请求设备（ip 地址或者 MAC 地址）、请求时间等信息，

为审计工作提供便利。

基于策略组合实现的访问控制方式相较于传统单独基于角色的访问控制方式更为灵活，它允许通过流

程审批临时增加或者变动访问控制策略，这种访问控制策略变动的方式，无需更新系统版本，也无需进行

其他适配性改造，就可以达到临时赋权访问的效果，而流程审批记录也可以为审计记录留痕，例如可以让

某一用户通过 IP 为 1.1.1.1 的主机在 1 个小时区间内访问指定资源。

图 4 策略方法层次架构图

4 JK12

LNP&12Q图 4 ：策略方法层次架构图

交易技术前沿

实际场景要求，提取所需访问控制元素，内聚在

新建的访问控制模块中，对用户请求进行统一拦

截鉴权。

从生产安全性考虑，运维平台不能在公网直

接开放使用，但如遇紧急情况时，运维人员、二

线支持人员短时间内无法赶去现场，极有可能导

致定位问题、处置问题时间被拖长，给生产安全

运行带来隐患。基于本文多因素访问控制方法，

通过访问控制策略，临时访问策略审批流程，可

允许运维人员、二线支持人员在指定设备终端在

持有 CA 证书的情况下在指定时间区间内访问运

维平台，及时定位、解决生产问题。

本系统基于 SpringBoot 框架创建了一个访

问控制服务 AC Service，用于进行访问控制权

限校验。并在控制层 AuthController 开放了一个

权限校验接口 /auth，供 Nginx auth_request 模块

拦截鉴权，该接口实际调用策略执行器 StrategyExecutor，而 StrategyExecutor 根据单一策略要

素校验结果按照复合策略进行组合计算，将访

问控制策略结果返回给 Nginx。用户可灵活化

自定义单一策略要素和组合策略，本运维平台

已纳入的单一策略要素有 ：限制访问 IP 前缀

的 IPPolicyExecutor、限制访问时间区间的 TimeRangePolicyExecutor、限制是否交易日访问的

TradeDayExecutor、限制用户是否可以远程访问

的 UserPolicyExecutor、限制使用指定 CA 证书

访问的 CertPolicyExecutor 等，如图 5 访问控制

策略实现图所示。

为满足生产环境实际需要，本平台根据访问

日期、访问时间、访问网段等元素，设计了一系

列不易拆分的单一策略，部分策略如表 1 所示。

以应用发布功能为例，涉及生产操作需双岗复核，

不应允许用户在交易时间内访问操作，仅允许用

户在办公内网非交易时段进行访问，它的复合策

略应为 {{P1，P2，P3}，{P1，P5}}，如公式（3）；

而对于应用日志下载、应用状态检查功能，不涉

及生产环境敏感操作，应既允许用户在办公内网

访问，也允许用户在非交易时间通过外网访问，

它的复合策略应为 它的复合策略应为 {{P1}，{P4，P5}，{P2，P3，

P4}}，如公式（4）。

单一策略要素有：限制访问 IP 前缀的 IPPolicyExecutor、限制访问时间区间的 TimeRangePolicyExecutor、

限制是否交易日访问的 TradeDayExecutor、限制用户是否可以远程访问的 UserPolicyExecutor、限制使用指

定 CA 证书访问的 CertPolicyExecutor 等，如图 6 访问控制策略实现图所示。

图 5 访问控制策略实现图

为满足生产环境实际需要，本平台根据访问日期、访问时间、访问网段等元素，设计了一系列不易拆

分的单一策略，部分策略如表 1 所示。以应用发布功能为例，涉及生产操作需双岗复核，不应允许用户在

交易时间内访问操作，仅允许用户在办公内网非交易时段进行访问，它的复合策略应为{{P1，P2，P3}，{P1，

P5}}，如公式（3）；而对于应用日志下载、应用状态检查功能，不涉及生产环境敏感操作，应既允许用户

在办公内网访问，也允许用户在非交易时间通过外网访问，它的复合策略应为{{P1}，{P4，P5}，{P2，P3，

P4}}，如公式（4）。

P1 ∩ P2 ∩ P3 ∪ (P1 ∩ P5) (3P1 ∪ P4 ∩ P5 ∪ (P2 ∩ P3 ∩ P4) (4表 1 单一策略表

单一策略标号 策略名称 策略方向 策略内容

P1 仅允许办公内网 IP 访问 Positive [“172.*.*.*”]

P2 仅交易日允许 Positive

P3 非交易时间段 Negative [“9:15-15:30”]

P4 证书 ID Positive [“cert1”, “cert2”]

P5 节假日允许 Positive

经过实践验证，通过灵活的策略组合及 Nginx 可插拔的 auth_request 模块应用，本文所述架构能够较

好地对现有运维平台访问控制能力增强，起到相关的预期作用。

4.2 $%S412

本文所述方法及架构不仅可用于访问控制技术，而且可以推广到对系统能力进行的其它场景，结合实

践情况列举以下两个场景进行描述。

4.2.1 用于 IPV6 过渡方案

随着社会数字化、智能化的体系建设不断深入，大部分政企单位均面临着数字化转型及创新体系构建

的挑战，其中加快建设部署 IPv6，快速完成现有 IPv4 业务系统转换，具备一定的战略意义。本文设计实现

的多因素访问控制方法同样可以用于 IPv6 与 IPv4 之间的服务转化，用户可以在策略层中增加 IPv6 与 IPv4

服务间的映射策略，设计具体执行器完成服务请求校验及转发规则判断，此设计模式可以在不改造现有架

构的基础上，快速帮助存量 IPv4 业务系统具备 IPv6 终端和用户访问能力。

(3)

单一策略要素有：限制访问 IP 前缀的 IPPolicyExecutor、限制访问时间区间的 TimeRangePolicyExecutor、

限制是否交易日访问的 TradeDayExecutor、限制用户是否可以远程访问的 UserPolicyExecutor、限制使用指

定 CA 证书访问的 CertPolicyExecutor 等，如图 6 访问控制策略实现图所示。

图 5 访问控制策略实现图

为满足生产环境实际需要，本平台根据访问日期、访问时间、访问网段等元素，设计了一系列不易拆

分的单一策略，部分策略如表 1 所示。以应用发布功能为例，涉及生产操作需双岗复核，不应允许用户在

交易时间内访问操作，仅允许用户在办公内网非交易时段进行访问，它的复合策略应为{{P1，P2，P3}，{P1，

P5}}，如公式（3）；而对于应用日志下载、应用状态检查功能，不涉及生产环境敏感操作，应既允许用户

在办公内网访问，也允许用户在非交易时间通过外网访问，它的复合策略应为{{P1}，{P4，P5}，{P2，P3，

P4}}，如公式（4）。

P1 ∩ P2 ∩ P3 ∪ (P1 ∩ P5) (3P1 ∪ P4 ∩ P5 ∪ (P2 ∩ P3 ∩ P4) (4表 1 单一策略表

单一策略标号 策略名称 策略方向 策略内容

P1 仅允许办公内网 IP 访问 Positive [“172.*.*.*”]

P2 仅交易日允许 Positive

P3 非交易时间段 Negative [“9:15-15:30”]

P4 证书 ID Positive [“cert1”, “cert2”]

P5 节假日允许 Positive

经过实践验证，通过灵活的策略组合及 Nginx 可插拔的 auth_request 模块应用，本文所述架构能够较

好地对现有运维平台访问控制能力增强，起到相关的预期作用。

4.2 $%S412

本文所述方法及架构不仅可用于访问控制技术，而且可以推广到对系统能力进行的其它场景，结合实

践情况列举以下两个场景进行描述。

4.2.1 用于 IPV6 过渡方案

随着社会数字化、智能化的体系建设不断深入，大部分政企单位均面临着数字化转型及创新体系构建

的挑战，其中加快建设部署 IPv6，快速完成现有 IPv4 业务系统转换，具备一定的战略意义。本文设计实现

的多因素访问控制方法同样可以用于 IPv6 与 IPv4 之间的服务转化，用户可以在策略层中增加 IPv6 与 IPv4

服务间的映射策略，设计具体执行器完成服务请求校验及转发规则判断，此设计模式可以在不改造现有架

构的基础上，快速帮助存量 IPv4 业务系统具备 IPv6 终端和用户访问能力。

(4)

经过实践验证，通过灵活的策略组合及

Nginx 可插拔的 auth_request 模块应用，本文所述

架构能够较好地对现有运维平台访问控制能力增

强，起到相关的预期作用。

4.2 扩展场景实践

本文所述方法及架构不仅可用于访问控制

技术，而且可以推广到对系统能力进行的其它

场景，结合实践情况列举以下两个场景进行描

述。

4.2.1 用于 IPV6 过渡方案

随着社会数字化、智能化的体系建设不断深

入，大部分政企单位均面临着数字化转型及创新

体系构建的挑战，其中加快建设部署 IPv6，快速

83

用策略执行器 StrategyExecutor，而 StrategyExecutor 根据单一策略要素校验结果按照复合策略进行组合计算，

将访问控制策略结果返回给 Nginx。用户可灵活化自定义单一策略要素和组合策略，本运维平台已纳入的

单一策略要素有：限制访问 IP 前缀的 IPPolicyExecutor、限制访问时间区间的 TimeRangePolicyExecutor、

限制是否交易日访问的 TradeDayExecutor、限制用户是否可以远程访问的 UserPolicyExecutor、限制使用指

定 CA 证书访问的 CertPolicyExecutor 等，如图 6 访问控制策略实现图所示。

图 5 访问控制策略实现图

为满足生产环境实际需要，本平台根据访问日期、访问时间、访问网段等元素，设计了一系列不易拆

分的单一策略，部分策略如表 1 所示。以应用发布功能为例，涉及生产操作需双岗复核，不应允许用户在

交易时间内访问操作，仅允许用户在办公内网非交易时段进行访问，它的复合策略应为{{P1，P2，P3}，{P1，

P5}}如公式（3）而对于应用日志下载应用状态检查功能不涉及生产环境敏感操作应既允许用户图 5 ：访问控制策略实现图

探索与应用

84

完成现有 IPv4 业务系统转换，具备一定的战略

意义。本文设计实现的多因素访问控制方法同样

可以用于 IPv6 与 IPv4 之间的服务转化，用户可

以在策略层中增加 IPv6 与 IPv4 服务间的映射策

略，设计具体执行器完成服务请求校验及转发规

则判断，此设计模式可以在不改造现有架构的基

础上，快速帮助存量 IPv4 业务系统具备 IPv6 终

端和用户访问能力。

4.2.2 用于系统保护机制

在传统 IT 系统架构中，应用系统一般会通

过专业压测来获取性能指标，如接口并发响应时

延、最大并发用户数量、数据库记录数等等，这

些指标不仅能够帮助运维及开发人员评估应用系

统在高负载情况下出现故障的可能性，也可用于

应用监测告警，有效避免系统安全运行风险。但

在实际的生产环境中，同样可能面临击穿性能容

量的情况，本文设计实现的多因素访问控制方法

同样可以用于系统性能容量保护，在不调整后端

服务架构的基础上，通过在策略层增加多因素拦

截策略，如限制同一设备单位时间内请求次数，

请求响应延时超过阈值后弹回处理等等，不仅提

升了整体架构的灵活性，也是一种有效的安全防

护手段。

4.3 收益分析

通过将本文所述方法在运维系统中进行实践

验证，访问控制模块的引入不仅可以有效加强系

统安全性，而且，在成本、架构管理等产生一定

的收益。

安全方面，架构在负载均衡层接入到现有系

统，可以对所有请求进行分析处理。访问控制模

块可以灵活制定原子策略并加以组合，可以按需

添加访问控制的要素，能够较好满足系统的安全

需求。 在该架构下，安全审计仅需要针对访问

控制模块进行，不需要逐个系统模块进行审计确

认，节省审计日志的存储及审计人员的重复检查

工作。

成本方面，架构以 Sidecar 形式灵活接入到

现有系统，对现有系统几乎无改造需求。架构上

解耦后，通过将访问控制能力沉淀为中台服务，

避免单个系统的改造，规避不同系统或模块的重

复开发和适配，若按照 20 个系统或模块接入该

鉴权方式，可节省 90% 以上的开发成本。而且，

访问控制服务就绪后，各系统可快速对接，大大

缩短推广周期。

架构管理方面，安全控制通过集中化的访问

控制模块完成，减少各系统因系统架构、鉴权逻

辑不统一产生的设计疏漏和运行风险，进一步降

低管理成本和提升系统健壮性。

5、总结与优化

通过对现有运维平台增加基于 IP 地址、时

间段范围、CA 证书等验证要素的实践，证明本

文所述方法不仅可以做到架构上对现有系统无侵

入性，而且通过策略的灵活组合，可以实现对于

不同保护等级的功能模块进行细粒度访问控制。

后续，除进一步支持更多访问控制要素外，可以

结合智能分析技术提前识别潜在风险并阻断相关

访问，而且可以进一步加强审计能力，定期回顾

访问控制的有效性。

交易时间内访问操作，仅允许用户在办公内网非交易时段进行访问，它的复合策略应为{{P1，P2，P3}，{P1，

P5}}，如公式（3）；而对于应用日志下载、应用状态检查功能，不涉及生产环境敏感操作，应既允许用户

在办公内网访问，也允许用户在非交易时间通过外网访问，它的复合策略应为{{P1}，{P4，P5}，{P2，P3，

P4}}，如公式（4）。

P1 ∩ P2 ∩ P3 ∪ (P1 ∩ P5) (3)

P1 ∪ P4 ∩ P5 ∪ (P2 ∩ P3 ∩ P4) (4)

表 1 单一策略表

单一策略标号 策略名称 策略方向 策略内容

P1 仅允许办公内网 IP 访问 Positive [“172.*.*.*”]

P2 仅交易日允许 Positive

P3 非交易时间段 Negative [“9:15-15:30”]

P4 证书 ID Positive [“cert1”, “cert2”]

P5 节假日允许 Positive

经过实践验证，通过灵活的策略组合及 Nginx 可插拔的 auth_request 模块应用，本文所述架构能够较

好地对现有运维平台访问控制能力增强，起到相关的预期作用。

4.2 $%S412

本文所述方法及架构不仅可用于访问控制技术，而且可以推广到对系统能力进行的其它场景，结合实

践情况列举以下两个场景进行描述。

4.2.1 用于 IPV6 过渡方案

随着社会数字化、智能化的体系建设不断深入，大部分政企单位均面临着数字化转型及创新体系构建

的挑战，其中加快建设部署 IPv6，快速完成现有 IPv4 业务系统转换，具备一定的战略意义。本文设计实现

的多因素访问控制方法同样可以用于 IPv6 与 IPv4 之间的服务转化，用户可以在策略层中增加 IPv6 与 IPv4

服务间的映射策略，设计具体执行器完成服务请求校验及转发规则判断，此设计模式可以在不改造现有架

构的基础上，快速帮助存量 IPv4 业务系统具备 IPv6 终端和用户访问能力。

表 1 ：单一策略表

交易技术前沿

85

潘建东、徐政钧、刘逸雄、谷航宇 / 中信建投证券股份有限公司 信息技术部 北京 100010

E-mail ：xuzhengjun@csc.com.cn

证券公司智慧营销与服务平台建设

1、概述

随着数字化转型的不断深入，金融科技领域

迎来了蓬勃发展的黄金时期，金融机构运用人工

智能、大数据、云计算、区块链等技术改变传统

业务的经营模式和业务场景，建设端到端的智能

化生态，实现运营效率提升与经营成本降低已成

为行业共识。对证券公司来说，随着越来越多投

资者涌入金融市场，如何以更完善的方式实现服

务与营销的结合，如何结合科技能力实现高效营

销，成为了一项重点的攻关项目。

线上开户是证券公司的核心开户渠道，开户

引流效果也是衡量业绩的重要指标，开户流程分

为手机号注册、营业部选择、身份证上传、风险

测评等十余个步骤，此外需添加身份证核验，人

工核验，回访确认等诸多需等待步骤，很大程度

上会使客户停留并遗忘。此外，在产品推介、业

务办理等众多过程中，均存在各种原因导致的客

户停留。及时地识别客户停留原因，为客户提供

陪伴式的服务引导，将在增强客户体验的同时提

升经营业绩。因此，为实现智慧营销，增强引流

和转化能力，进一步提升公司的核心业绩，中信

随着居民可投资资产的快速增长以及资本市场改革红利的充分释放，券商财富管理

业务正迎来蓬勃发展的新时代，而互联网运营模式的逐步推广，使得传统大规模线下金融

业务以及传统营销模式受到诸多限制。对证券公司来说，充分发挥大数据、云计算、人工

智能等新兴技术的优势，大力发展线上营销服务，以智能化方式提升顾问营销与服务能力，

提高客户服务体验是大势所趋。本文阐述了中信建投证券通过对传统电话营销服务的智能

化改造，实现了高效、合规的全流程精细化服务，最后本文总结客户服务中智慧营销的经

验与未来展望。

探索与应用

建投证券以全流程数字驱动的理念为引领、以数

字化手段为支撑 , 着力建设全流程、多维度智慧

营销服务平台。该平台提供客户行为跟踪、IP 电

话呼叫、客户画像、智能分析引擎、数据统计与

分析等功能，通过智能监听客户业务办理及产品

购买流程，实现基于模型及流程的客户意图预测，

最终智能生成任务并路由分配。此外平台在对话

过程中引入实时知识与话术推荐等一系列功能，

实现全流程、多维度、精细化的智慧营销。

2、营销服务平台智能化建设

2.1 功能与架构

营销服务平台整体划分为任务管理单元、数

据统计单元、行为监控单元和智能化单元四个部

分，对外提供客户行为跟踪、IP 电话呼叫、客户

画像、智能分析引擎以及数据统计与分析等功能。

行为监控单元是平台中的数据获取中心，它

通过数据埋点，轻量级地收集各界面上客户的状

态信息，并发送至统一后台消息队列，消息队列

提供全流程客户信息，任何监听消息队列的用户

均可获取全量客户状态信息。过滤管理则是面对

海量客户信息，精准地实现信息漏斗，过滤掉无

关的监听信息，平台提供了基于渠道、流程状态

的监听配置，该过滤管理功能也可实现基于业务

的信息过滤，以达到个性化监听的目的。数据扩

容模块则是为了向营销人员提供更多客户信息而

设置的，该模块对接公司其他数据中台，在流程

监控中拉取的部分信息进行数据补全，收集用户

的历史营销信息、个人信息和历史办理业务信息

等，为营销人员决策提供数据支撑。

智能化单元是平台的核心单元，是平台的决

策大脑。智能分析单元提供数据画像的分析能力，

并且通过基于自然语言处理（Natural Language

Processing，NLP）技术实现自动画像生成，可在

对话过程中实时分析客户的意向。行为预测则是

平台的辅助单元，该单元收集用户的特征，并基

于流程信息对客户的后续行为进行预测，该预测

采用深度学习模型，决策出用户后续办理业务成

功的概率，并将概率反馈给营销人员，营销人员

则可根据该单元决策是否电话营销。用户增长是

平台中的员工数据分析单元，该单元可将平台中

的全部信息进行实时分析，实现基于不同维度的

分析数据，实现漏斗分析、行为分析、成功率分

员工数据分析单元，该单元可将平台中的全部信息进行实时分析，实现基于不同维度的分析数据，实现漏斗分析、行为分析、

成功率分析等营销的质量报告。

任务管理单元则是平台运行的控制单元，该单元连接智能化单元和行为监控单元，从行为监控单元中抓取数据，并实时

生成任务，然后将该任务分配给公司内的营销人员。任务生成单元内置任务生成引擎，采用可配置模型实现任务的自动生成

和匹配。任务管理则是为管理员用户提供的核心功能，可实现任务的重定向、删除等操作。任务执行实现了基于公司 IP 电

话的一键拨打功能，该模块同时提供话术推荐服务，可针对客户的停留步骤和其他配置信息提供优秀话术。数据统计单元则

提供了基础的管理员服务，实现员工、渠道、总览的报表数据服务，为运营决策提供数据支持。

图 1 整体架构图

2.2 789:

2.2.1 轻量级用户行为埋点监听

图 1 ：整体架构图

86

交易技术前沿

析等营销的质量报告。

任务管理单元则是平台运行的控制单元，该

单元连接智能化单元和行为监控单元，从行为监

控单元中抓取数据，并实时生成任务，然后将该

任务分配给公司内的营销人员。任务生成单元内

置任务生成引擎，采用可配置模型实现任务的自

动生成和匹配。任务管理则是为管理员用户提供

的核心功能，可实现任务的重定向、删除等操作。

任务执行实现了基于公司 IP 电话的一键拨打功能，

该模块同时提供话术推荐服务，可针对客户的停

留步骤和其他配置信息提供优秀话术。数据统计

单元则提供了基础的管理员服务，实现员工、渠道、

总览的报表数据服务，为运营决策提供数据支持。

2.2 核心技术

2.2.1 轻量级用户行为埋点监听

埋点是数据采集领域的术语，指的是针对特

定用户行为或事件进行捕获、处理和发送的相关

技术及其实施过程。埋点可以为后续的产品优化

和用户运营提供可供参考的业务数据及其附带信

息。根据部署的位置可以分为客户端埋点和服务

端埋点，而客户端埋点可以根据埋点工具的方式

划分，可以分为三种类型 ：代码埋点，可视化埋

点和全埋点。综合考虑数据采集有效性、客户端

可靠性以及移动端的电量、流量和内存消耗，本

平台采用统一代码埋点，即部署完基础的 SDK 后，

在需要采集数据地方添加跟踪代码，APP 启动的

时候会初始化 SDK，数据采集位置被触发的时候

就会调用 SDK 对应的数据接口把数据发送出去。

基础埋点 SDK 将上报用户界面点击进度，并发

至后端消息队列中。

本 平 台 采 用 Kafka 消 息 队 列， 通 过 监 听

Kafka 消息队列即可完整接收全部客户的实时状

态信息，基于客户全流程信息，即可实现流程信

息的分析，通过用户的行为实现预测与诊断。

2.2.2 智能外呼系统

传统电话客服模式中，外呼人员的服务承载

能力有限，无法应对数量庞大的电话交流场景，

并且众多重复性问题会造成人力资源的浪费。为

了保障营销服务的时效性，降低营销服务成本，

智能外呼应运而生。智能外呼主要采用智能机器

人进行电话外呼服务，用以提高公司主动与用户

联系沟通的效率。智能外呼系统能够模拟真人与

客户进行电话沟通，引导用户完成电话主流程任

务，支持实时意图识别、开放域提问，且在回答

开放域问题后能够引导客户关注主流程。智能外

呼的核心是赋予产品语音识别、理解以及合成的

能力。

智能外呼系统由话务模块、语音服务模块、

算法模块、对话管理模块以及运营管理平台组成。

其中话务模块管理话务能力方面的功能，例如语

音通讯、录音等 ；语音服务模块负责语音方面的

工作，包括自动语音识别以及自然语言合成 ；算

法模块是外呼机器人的核心组件，需要完成数据

的处理、模型的构建与训练等，让机器人具备识

别与交互能力 ；对话管理模块的工作是在机器人

识别客户的意图之后，对回复的内容进行生成 ；

运营管理平台负责系统的日常管理，通过制定用

户名单以及外呼策略，实现在限定时间范围内向

目标客户进行自动呼叫。

为了更好地进行营销与服务客户，实现量质

并举，平台会在对客户进行意图预测后依据预测

的意向对客户进行分类。对于意愿较弱的客户，

由智能机器人进行服务，智能机器人会告知客户

开户流程未完成，并提供常见问题的智能问答。

此外，平台会询问客户是否需要人工指引，若客

户回复需要，则通过多轮对话的形式沟通客户需

求，并将需求以工单形式发送给客户经理，客户

经理则会根据工单及时服务客户，及时解答客户

问题。

2.2.3 基于客户行为及画像的意图预测

目前大多数系统均将与客户的实时通话内容

作为意图识别的主要特征来源，这导致在未与客

户接触时缺乏对于客户的了解。传统外呼服务中

87

探索与应用

心缺乏一套智能决策系统来预测业务办理中断客

户需要帮助的紧急程度以及业务办理意图强弱。

为此，本平台根据预测模型，建立分级的外呼服

务策略，将外呼服务分为直接人工外呼的高优先

级，先进行智能外呼的中优先级，以及不进行外

呼的低优先级，解决服务不及时和效率低下的问

题，提升营销效果。

本平台设计了一种基于客户行为及画像的意

图预测方法，该方法针对业务办理中断的客户进

行实时预测，预测客户最终业务办理成功率以及

客户中断的原因，并将办理高成功率客户作为高

优先级，引导营销人员优先处理。该方法收集客

户流程特征与个人信息，其中流程特征包括客户

业务办理进行的步骤总数、客户回退的步骤总数、

客户平均停留时长、客户历史停留超时次数、客

户当前停留步骤、客户是否主动回退和客户历史

意愿 ；客户个人信息包括客户的基本信息，即户

籍地址、住址地址、教育程度、性别、年龄等。

其中“客户历史意愿”即为用户历史对话中办理

意愿的强弱，是根据该业务的客户历史对话语音，

在提取文本矩阵后输入至双向长短时神经网络

BiLSTM 的意图检测模型获得的。

预测的整个流程为，将客户全部信息输入二

分类器，该二分类器根据历史数据训练而来，用

于对客户产品办理是否成功进行预测，并给出具

体成功概率。考虑到模型运行的运行速度，该二

分类器在本文中采用轻量级的 LightGBM 实现，

LightGBM 以直方图算法代替 XGBoost 的与排序

算法构建的数据结构，大幅度提升了训练速度减

少了内存消耗，并且采用按叶生长（Leaf-wise）

的策略代替按层生长（Level-wise）策略，增加

了最大深度的限制，保证高效的同时防止过拟合。

2.2.4 实时合规质检的 IP 电话设计

本平台的营销电话采用基于 VoIP 协议软交

换平台 FreeSWITCH 的电话语音呼叫系统，又称

作两端呼，即一端通过 IP 电话机或 IP 软电话连

接客服人员，另一端通过传统的 PSTN 电话网络

连接客户。实现员工电话录音的集中管理，并对

外开放接口以供第三方系统调用。员工在拨打客

户电话时，员工侧采用 IP 电话（软电话）来拨打，

不占用电话线路，节省线路资源与费用。此外，

两端呼电话与系统自动挂接，实现了对话语音的

自动上传与实时质检分析，设计架构如图 2 所示。

以及不进行外呼的低优先级，解决服务不及时和效率低下的问题，提升营销效果本平台设计了一种基于客户行为及画像的意图预测方法，该方法针对业务办理中断的客户进行实时预测，预测客户业务办理成功率以及客户中断的原因，并将办理高成功率客户作为高优先级，引导营销人员优先处理。该方法收集客户特征与个人信息，其中流程特征包括客户业务办理进行的步骤总数、客户回退的步骤总数、客户平均停留时长、客户历留超时次数、客户当前停留步骤、客户是否主动回退和客户历史意愿；客户个人信息包括客户的基本信息，即户籍地址址地址、教育程度、性别、年龄等。其中“客户历史意愿”即为用户历史对话中办理意愿的强弱，是根据该业务的客户对话语音，在提取文本矩阵后输入至双向长短时神经网络 BiLSTM 的意图检测模型获得的。

预测的整个流程为，将客户全部信息输入二分类器，该二分类器根据历史数据训练而来，用于对客户产品办理是否进行预测，并给出具体成功概率。考虑到模型运行的运行速度，该二分类器在本文中采用轻量级的 LightGBM 实现，Ligh以直方图算法代替 XGBoost 的与排序算法构建的数据结构，大幅度提升了训练速度减少了内存消耗，并且采用按叶生长（Lwise）的策略代替按层生长（Level-wise）策略，增加了最大深度的限制，保证高效的同时防止过拟合。

2.2.4 实时合规质检的 IP 电话设计

本平台的营销电话采用基于 VoIP 协议软交换平台 FreeSWITCH 的电话语音呼叫系统，又称作两端呼，即一端通过 话机或 IP 软电话连接客服人员，另一端通过传统的 PSTN 电话网络连接客户。实现员工电话录音的集中管理，并对外开口以供第三方系统调用。员工在拨打客户电话时，员工侧采用 IP 电话（软电话）来拨打，不占用电话线路，节省线路资费用。此外，两端呼电话与系统自动挂接，实现了对话语音的自动上传与实时质检分析，设计架构如图 2 所示。

图 2 两端呼电话架构

两端呼电话采用云端部署，通过 TLS 对信令加密和 SRTP 对语音数据加密实现数据传输的安全性，同时底层构建管务器、录音服务器、知识库服务器、语音网关等底层服务单元。基于两端呼 IP 电话，可以实现录音的文件的实时获取，图 2 ：两端呼电话架构

两端呼电话采用云端部署，通过 TLS 对信

令加密和 SRTP 对语音数据加密实现数据传输的安

全性，同时底层构建管理服务器、录音服务器、知

识库服务器、语音网关等底层服务单元。基于两端

呼 IP 电话，可以实现录音的文件的实时获取，系

统可在电话过程中实现实时话术提醒与实时语音质

检，营销平台与电话系统通过 restful 接口进行对接，

实现一键拨打，录音收听，智能质检等功能。

2.2.5 基于延迟队列的自定义监听方案

延迟队列就是进入该队列的消息会被延迟消

费的队列。而一般的队列，消息一旦入队了之后

就会被消费者马上消费。生产者把消息发送到消

息队列中以后，并不期望被立即消费，而是等待

指定时间后才可以被消费者消费，这类消息通常

被称为延迟消息。一般通过最大生存时间（TimeTo-Live）和死信交换机（Dead Letter Exchanges）

两个特性模拟出延迟消息的功能。消息超过最大

生存时间没有被消费就成为一条死信，便会被重

新投递到死信交换机，然后死信交换机根据绑定

88

交易技术前沿

规则转发到对应的死信队列上，监听该队列就可

以让消息被重新消费。

本平台实现可自定义的延迟管理单元，采用

基于 RabbitMQ 的 delayed message exchange 插件

实现任意时长的毫秒级监听，该插件支持延迟投

递机制的 Exchange 类型，在接收到该类型的消

息后不会立即将消息投递至目标队列中，而是存

储在 mnesia 表中，检测消息达到可投递时间时

再投递到目标队列，基于该插件的二次开发和封

装，本平台实现了监听管理、延迟启停、延迟配

置管理、延迟队列管理等一系列标准化功能，实

现用户监听的千人千面，即可根据用户进度信息、

客户个人信息等构建任务生成模型，使不同客户

的状态监听时长自定义，例如某些直播渠道因为

营销实时性高，延迟定义为较小。

3、智能化建设成效

3.1 实现精准且专业的营销

平台采用预测技术对客户综合信息进行快速

评估，帮助员工在海量客户中过滤高潜力客户，

提升工作效率，实现点对点的精准营销。本文提

出的平台有效提升了服务流程的标准化与营销团

队的专业化程度。此外，基于智能外呼、人工外

呼及短信的营销方式能够全方位触达客户，营销

与服务结合的模式能够以为客户解决问题为出发

点附带营销，提升客户服务体验的同时兼顾业绩

提升。

3.2 提高营销服务的规范性

平台实现了基于 IP 电话的智能合规质检功

能，员工可以通过平台一键拨打电话，语音数据

及拨打记录会实时存储在后端云盘。平台通过搭

建完整的合规风险分析模型，建立员工合规风险

画像，并通过对营销服务过程的实时合规监控实

现对员工的潜在合规风险预警，有效提高员工的

合规意识，保证营销服务的规范性。

3.3 降本增效与业绩提升

智慧营销服务平台创新性地引用了多种智能

化组件，将传统电话营销系统进行数字化改造，

实现智能客户行为跟踪、客户行为预测、客户画

像分析等一系列创新性应用，平台应用后效果明

显，依据智能预测开展的营销可有效降低对于客

户的打扰，同时减少了外呼人员的人力资源成本。

根据客户意图预测模型进行的精细化营销实现了

客户开户率的稳步提升。上线以来，平台运行良

好，实现了服务体验、合规管控与业务转化的齐

头并进与良性发展，客户满意度稳步提升。

4、总结

中信建投证券以智能化为引领，在推进智慧

营销平台建设上持续深入，努力打造贯穿用户全

周期的数字化智能营销服务，通过数据驱动，智

能地为客户匹配适宜的服务和产品，实现高效、

合规、精细的服务。以数据为核心构建的智能化

体系将成为支撑未来券商发展的关键，智慧化建

设在金融行业具备广阔前景，将对未来证券业态

发展产生深远影响，着力布局智能应用将成为券

商的必由之路。随着区块链技术的快速发展，营

销平台未来可以在营销结算、利益分配等方面发

力，利用区块链技术去中心化、公正性和透明性、

防伪、防篡改、准匿名性、交易可追溯等特点，

可更好地在实现合规的前提下提高营销分配效率

与完善奖惩机制。随着人工智能算法的不断进步，

深度强化学习、自动化机器学习以及大模型为代

表的新兴模型在解决问题的多样性、结构复杂度、

训练数据规模等方面有了显著提高，为此营销平

台要不断紧跟新技术、探索新方法、实现新突破。

百舸争流千帆竞，乘风破浪正远航，未来中信建

投证券将继续以时不我待、只争朝夕的精神，保

持对智能化建设的敏感度 , 发挥自身资源优势 ,

不断增强客户服务水平，以向客户提供优质高效

服务为目标而不断努力！

89

探索与应用

参考文献 :

[1] 于建彬 , 邱轲 . 智能化转型背景下提升现金服务的路径选择 [J]. 金融发展研究 ,2020(8):4.

[2] 李婕 . 商业银行网点智能化建设研究 [J]. 现代经济信息 ,2018(21):267.

[3] 王琛 . 国内证券公司客户服务变化趋势 [J]. 经贸实践 ,2017(03):67-69.

[4] 苗英哲 . 互联网金融背景下券商网络营销对策 [J]. 山西农经 , 2019(23):2.

[5] 刘艳丽 , 刘心义 , 林黎钦 . 基于适当性管理的用户画像助力智慧营销研究 [C]. 创新与发展 : 中

国证券业 2017 年论文集 .2018.

[6] 刘新霞 , 廖信超 . 全渠道智能营销平台建设探索 [J]. 金融科技时代 ,2022,30(3):5.

[7] 张巍 , 唐琴 . 人工智能客服软件企业营销渠道管理探析 [J]. 现代工业经济和信息化 ,2021,

11(9):3.

[8] 苏萌 . 隐私计算在智能营销中的应用 [J]. 金融电子化 ,2022(1):3.

[9] 侯晓 . 银行 \" 零接触 \" 营销服务体系建设 [J]. 中国金融 ,2021.

90

交易技术前沿

季晓娟、王中澎、李炜、赵冬昊、王汉杰、李蓉 / 上证所信息网络有限公司 上海 200120

E-mail ：xjji@sse.com.cn

证券行业网站智能数据搜索服务的

研究与实践

1、概述

近年来，我所加快推进数字化建设，积极推

动业务、技术、数据的深度融合。为切实服务市

场主体，集中精力提升服务体验，我所完成了网

站智能数据搜索服务的研究与系统建设，将人工

智能和搜索引擎技术相结合，为网站用户获取披

露数据提供更加便捷、有效、易读的服务体验。

2、系统建设效果

网站智能数据搜索服务体验版于 2020 年底

上线并对市场提供试点服务，日均调用量超过

一万次，陆续收到市场良好反馈。根据我所“我

为群众办实事”实践活动中“持续听取广大群众

和市场各方的合理诉求，扎扎实实办好大家关注、

关心、关切的实事”的相关指示精神，我所常态

化开展网站用户调研和搜索服务用户意见征集等

活动，并以此为基础，积极改进搜索服务体验。

从反馈情况看，用户对数据获取的效率与阅读体

验提升的需求较为迫切。因此，我所开展了网站

智能数据搜索服务的算法自研、数据扩展、语义

模型训练、功能迭代、数据验证，将数据搜索服

务由官网试点转为网站群全面服务。以下进行具

为加快推进数字化建设，打造数字智能型交易所，上交所积极研究探索技术创新，

强化搜索对网站服务的赋能。本文主要介绍了上海证券交易所网站智能数据搜索服务的建

设历程，重点讲述了建设目标、成果及未来方向等内容。希望可以给致力于科技赋能的读

者以启发，共同探索以科技创新增强用户获得感之路。

!\"#$%&'()*+,-./

01234

季晓娟、王中澎、李炜、赵冬昊、王汉杰、李蓉

上证所信息网络有限公司 上海 200120

E-mail ：xjji@sse.com.cn

摘 要：为加快推进数字化建设，打造数字智能型交易所，上交所积极研究探索技术创新，强化搜索对网

站服务的赋能。本文主要介绍了上海证券交易所网站智能数据搜索服务的建设历程，重点讲述了建设目标、

成果及未来方向等内容。希望可以给致力于科技赋能的读者以启发，共同探索以科技创新增强用户获得感

之路。

关键词：人工智能；搜索；网站数据；5

1 67

近年来，我所加快推进数字化建设，积极推动业务、技术、数据的深度融合。为切实服务市场主体，

集中精力提升服务体验，我所完成了网站智能数据搜索服务的研究与系统建设，将人工智能和搜索引擎技

术相结合，为网站用户获取披露数据提供更加便捷、有效、易读的服务体验。

2 89:;<=

网站智能数据搜索服务体验版于 2020 年底上线并对市场提供试点服务，日均调用量超过一万次，陆续

收到市场良好反馈。根据我所“我为群众办实事”实践活动中“持续听取广大群众和市场各方的合理诉求，

扎扎实实办好大家关注、关心、关切的实事”的相关指示精神，我所常态化开展网站用户调研和搜索服务

用户意见征集等活动，并以此为基础，积极改进搜索服务体验。从反馈情况看，用户对数据获取的效率与

阅读体验提升的需求较为迫切。因此，我所开展了网站智能数据搜索服务的算法自研、数据扩展、语义模

型训练、功能迭代、数据验证，将数据搜索服务由官网试点转为网站群全面服务。以下进行具体建设效果

介绍。

91

探索与应用

体建设效果介绍。

2.1 实现搜索意图的“智能处理”。

实现了将人类口语化语言转换为机器能识别

的“数据语言”，进而从海量数据中搜索答案并

精准高效地反馈结果。支持更口语化的表述作为

系统输入，支持多实体组合及数据指标的处理，

有效桥接用户需求和网站数据间的语义鸿沟，提

升了用户获取披露数据的便捷性。

2.2 实现数据内容的“一键直达”。

扩展数据范围至网站群，扩展后的数据范围

涵盖股票、债券、基金等多产品，贯穿注册审核、

发行承销、上市交易等阶段，解决了站点栏目分

散不易查找的问题，提升了用户获取披露数据的

有效性。

2.3 实现搜索结果的“友好交互”。

统一搜索入口，根据用户搜索意图聚合展示

数据、公告、规则等相关结果，并新增五大类搜

索频道，支持细分用户搜索场景，提升了用户获

取披露数据的易读性。

3、技术突破点

3.1 整体架构

网站智能数据搜索服务的整体架构图如图 1

所示，主要包括数据源层、数据采集层、数据存

储层、逻辑处理层、应用层。

（一）数据源层 ：搜索的数据源来自于上交

所官网、子网站、应用及部分行业知识。

（二）数据采集层：采集的过程通过解析文件、

数据库，并通过 REST API 还有消息队列交互。

（三）数据存储层 ：数据被采集加工后被重

新组织并存储，被存储为文件、ES 中的索引信息、

还有经过逻辑清洗的结构化数据。

（四）逻辑处理层 ：在处理搜索 QUERY

请求时，运用了自然语言处理技术，分词、同

义词、改写实体识别等技术将输入 QUERY 构

建为多层（layer）语义信息。通过关键字段如

证券代码将结构化数据建立关系，通过 NLP

模型判断权重，映射为可能性最高的 SQL 语句

图 1 整体架构图

3.2 QR2Z([\\

本项目基于证券行业先验知识和预训练模型构建了混合架构语义解析引擎技术先进性及阶段性成果图 1 ：整体架构图

92

交易技术前沿

去做查询。

（五）应用层 ：顶层在应用层构建，输出语

义理解能力。

3.2 技术与功能创新

本项目基于证券行业先验知识和预训练模型

构建了混合架构语义解析引擎。技术先进性及阶

段性成果主要如下 ：

一是基于数据关系的自动发现方法，将数据

知识化，构建数据实体间的关联关系，为智能分

析提供决策依据。

二是基于行业先验知识，构建实体及意图识

别模型，避免过度泛化，提升了实体及意图识别

模型的准确率，模型训练过程中使用的训练语料

达 300 万条。

三是优化推理模型网络结构，实现高效在

线实时运算。采用粗排、精排、网络结构剪枝、

GPU 和 CPU 混合计算、半浮点数运算等方法，

突破了在线实时交互查询的运算瓶颈，在准确率

得到保障的情况下，计算效率提升了 6 倍。

4、未来挑战

网站智能数据搜索服务是基于人工智能技

术、搜索引擎技术与我所数据信息的综合应用。

技术方面，涉及搜索引擎技术、人工智能技术等

多种技术的研究发展。信息来源方面，接入数据

的质量、用户行为数据粒度对结果产生直接影响。

应用方面，市场对个性化与多元化搜索体验的要

求不断提高。因此，作为数字化时代的基础设施

应用，需持续进行技术迭代、行业反馈、服务运

营的积累与更新。

5、总结展望

我所已初步完成网站智能数据搜索服务的建

设，该服务提升了用户获取数据服务的效率与体

验，基于搜索服务实践经验，我所将积极推进落

实上交所网站搜索引擎建设，强化多源多态信息

的融合搜索，持续提升数字化基础设施的服务能

力，强化数字科技对资本市场的有效支撑。

93

探索与应用

张涛、卢雅哲、徐广斌、谢毅 / 上海证券交易所 信息科技部 上海 200120

E-mail ：yzlu@sse.com.cn

关于ION GROUP遭遇勒索病毒

攻击事件的分析思考报告

1、事件整体综述

ION Group 是一家软件公司，其产品被金

融机构、银行和公司广泛用于交易、投资管理

和市场分析。1 月 31 日早间，ION Group 的服

务器遭遇严重网络攻击，整个通信网络瘫痪数

小时，导致期货交易匹配和保证金计算业务无

法正常运行。该事件影响了其位于欧洲和美国

的 42 个客户，其中包括荷兰银行清算所（ABN

Amro Clearing）和意大利联合圣保罗银行（Intesa

Sanpaolo）。该事件迫使多家银行和经纪人手动处

理交易，美国商品期货交易委员会（CFTC）宣

布推迟三周发布其交易商承诺报告，泛欧证券交

易所（Euronext N.V.）宣布推迟发布大宗商品衍

生品持仓周报。

黑客组织 Lockbit 于 2 月 2 日将 ION Group

添加到其数据泄露网站的受害者名单中，声称在

入侵期间窃取了数据，并威胁 2 月 4 日前不缴纳

赎金，将公布这些数据，对 ION Gruop 进行文件

加密和数据披露的“双重勒索”。文件加密导致

受害方无法访问和获取系统中文件和数据，系统

崩溃，但此类攻击受害方可通过备份数据进行恢

复 ；数据披露，即攻击方以公开其敏感数据要挟

受害方缴纳赎金。2月4日ION Group支付了赎金，

1 月 31 日，国际金融行业关键软件提供商英国 ION Group 遭遇勒索病毒攻击，攻

击使得衍生品系统无法完成保证金计算、主要市场头寸监管报送等。美国财政部、商品期

货交易委员会、欧洲央行等纷纷就此事件发声。据 2 月 9 日报道，大部分受影响的业务

已恢复运行。事件发生后，上交所密切关注进展，持续跟踪境内外媒体报道，对事件进行

思考分析，并对行业防范供应链网络与信息安全风险提出启示与建议。

94

交易技术前沿

LockBit将其移出受害者名单，并对系统进行恢复，

2 月 7 日 ION Markets 系统基本恢复运行。

2、事件影响

衍生品投资的结算具有时间敏感性，多家

机构在 2 月 1 日表示此次攻击对其业务造成了严

重影响。伦敦洲际交易所（ICE）宣布，已将维

持头寸的截止时间从上午 10 点延长至中午，并

警告，延期将导致未平仓合约延迟公布，受攻击

影响期间可能错误陈述未平仓合约。商品期货交

易委员会（CFTC） 表示，ION 的中断正在影响其

一些成员向其提供及时和准确数据的能力。多家

交易所运营商表示，攻击可能会影响当天按时发

布交易所报告。荷兰银行（ABN Amro Bank NV）

的美国清算部门表示，中断将延迟其隔夜处理，

并将在 2 月 1 日继续手动操作。美国期货业协会

（FIA）正在评估该事件对 ION Group 造成的破坏

后果，并在声明中表示，此次攻击影响了 ION 客

户在全球交易所衍生品的交易和清算。英国金融

行为监管局（FCA）正在与同行合作，帮助受影

响的金融服务公司。

3、攻击过程分析

据分析，在过往攻击中，黑客组织 Lockbit

攻击过程大致可分为初始入侵、深入渗透和目标

达成三个阶段。

初始入侵阶段，Lockbit 主要采用三种策略

获取访问权限。一是单刀直入，非法购买或暴力

破解远程登录账户。二是迂回包抄，采用社会工

程学策略，向目标用户发送带有恶意附件的“钓

鱼”电子邮件。三是大刀阔斧，借助大规模漏洞

扫描定位潜在目标，利用应用程序漏洞获取初始

感染机会。

深入渗透阶段，Lockbit 进一步提升权限，

扩大感染面，探测内部网络敏感数据。一是通

过渗透工具或诱饵文件得以加载执行。二是为

进一步扩大感染面，通过各种权限提升工具来

扩展对系统的访问权限，一旦进入域控制器，

即可通过 SMB（一种通信协议）连接传播到其

他系统，或在网络中横向扩展。三是躲避受害

者系统安全防护产品检测，利用进程管理工具

禁用安全软件，或直接利用域管理员权限关闭

系统防护，再者伪装成常见的 PNG 图像格式来

隐藏可执行文件。

目标达成阶段，Lockbit 在感染多台主机后

实施数据加密和渗出。加密环节 , 收集各类系统

信息，在不影响正常运行下，开始加密其可以访

问的本地和远程设备上的所有数据。渗出环节，

通过云存储工具上传所窃取的文件 ；使用窃密木

马，盗取用户数据文件以对受害者进行数据披露

勒索。

完成攻击后，lockbit 会在其网站公布受害者

信息，并以邮件等方式向受害者进行勒索，赎金

要求以比特币和门逻币等区块链货币支付。

4、思考与启示

网络和信息安全工作事关国家安全、政权安

全和经济发展。此次 ION Group 遭遇勒索病毒攻

击对全球衍生品交易产生了极大的负面影响。据

知名网络安全厂商 Imperva 研究，全球网络攻击

事件中，针对金融机构的攻击占比高达 28%，采

取供应链或“跳岛”的方式进行攻击，越来越普遍。

根据此次事件分析结果，结合我国证券期货行业

的实际情况 , 从防范供应链安全风险角度，提出

几点启示。

一是警惕供应链上下游的网络安全风险。随

着金融交易向更快、更自动化发展，ION 这样的

软件公司逐渐蓬勃壮大，已成为现代金融市场管

道中越来越重要的部分。对 ION 的攻击，体现出

金融系统的相互关联性和对软件的强烈依赖性。

建议证券期货行业重点单位梳理重要系统供应链

95

探索与应用

96

上下游厂商，对其基础设施、工具、开源组件、

源代码和配置开展评估，定位和降低漏洞风险。

二是加强证券期货行业的攻击面风险管理。

攻击面指任何可能受到攻击的载体，包括与互联

网连接的系统、供应商链、移动设备、物联网和

员工。证券期货行业可联合加强攻击面风险管理，

对行业依赖度较高的供应商和服务商进行常态化

监测。

三是针对类似攻击事件开展应急演练和沙盘

推演。金融领域的网络攻击不再仅仅是针对金融

企业本身，而是转向攻击其数字化转型的关键供

应商。证券期货行业可联合开展此类情况的应急

演练，并针对供应链上下游厂商遭受攻击的各类

极端情况，开展沙盘推演。

信息资讯采撷 I nformation

监管科技全球追踪

信息资讯采撷

12 月 22 日，国际清算银行发布报告《可持

续金融中的信息治理》 （以下简称报告）。

12 月 27 日，中国银保监会发布《外国银行

分行综合监管评级办法（试行）》（以下简称《办

法》），目的在于进一步完善外国银行分行监管评

级体系，合理配置监管资源，加强分类监管，促

进外国银行分行稳健运营。

1 月 4 日，英国首相表示，英国已通过 260

亿英镑有效保护了收入较低的人群，并稳定了国

内经济与抵押贷款利率。

1 月 4 日，2023 年人民银行工作会议以视频

形式召开。会议深入学习贯彻党的二十大和中央

经济工作会议精神，总结 2022 年和五年来主要

工作，分析当前形势，部署 2023 年工作。

1 月 4 日，日本金融科技公司 SmartPay 在日

本、沙特阿拉伯及阿联酋推出了新的数字客户金

融服务 SmartPay Bank Direct。

1 月 8-9 日，国际清算银行在瑞士巴塞尔召

开行长例会，中国人民银行行长易纲出席了新兴

经济体行长会、经济顾问委员会会议、全球经济

形势会等会议，与会央行行长们就全球经济金融

形势、新兴经济体如何面对全球冲击以及汇率调

整的挑战等问题进行了交流。

1 月 11 日，英国国家网络安全中心发文建

议机构通过托管服务提供商管理运维云服务。

1 月 11 日，丹麦央行及 7 家商业银行遭

受了分布式拒绝服务攻击（Distributed denial of

service attack，DDoS）。

1 月 12 日，欧洲银行管理局、欧洲保险与职

业养老金管理局和欧洲证券和市场管理局联合发

布了一份关于数字化国家金融教育计划的联合主

题报告，重点关注网络安全、诈骗和欺诈等问题。

1 月 13 日，证监会、人民银行联合发布《公

开募集证券投资基金信息披露电子化规范》金融

行业标准，标准自公布之日起施行。

2 月 2 日， 亚 马 逊 云 科 技（Amazon Web

Services，AWS）宣布，全球领先的保险公司苏

黎世保险集团选择 AWS 作为其云服务提供商，

并迁移其企业 IT 基础设施至 AWS。

2 月 4 日，人民银行易纲行长前往通州参加

北京城市副中心打造国家级绿色交易所启动仪式

并发表讲话。

2 月 8 日，英国央行（The Bank of England）

监管科技全球追踪

98