48

入功能号进行压测。执行压力测试过程中要开启测试环

境监控，通过CPU使用率、网络使用率、输入输出延迟

等指标实时判断压力测试异常情况，并及时记录压力测

试过程中各项数据。

2.4.4 测试总结

每次压力测试结果会以报告的形式作为测试资产留

存，为后续性能评估、系统扩容等工作提供参考。生产

环境实际运行中的异常性能表现也会对压力测试起到正

向的反馈作用，为分析现有压力测试管理工作中的缺陷

提供了现实依据，同时在改进压力测试工作后也能避免

更严重的系统故障的发生。

2.5 测试内容

测试内容包括配置业务场景、选取压测样本、置备

测试数据、记录测试数据。

为了保证压力测试的有效性，选取的压力测试场景

必须真实反映实际生产业务调用情况。中信建投证券压

力测试的业务场景参考真实的生产业务数据，采样近一

个月交易系统的调用情况，根据业务调用的实际占比调

整压力测试模型。

压测样本由若干条测试用例组成，每个测试用例包

含必要的入参，如订单功能需要客户号、股东代码、股

票代码、买卖类型、委托金额、委托手数等。压力测试

平台会顺序选择测试用例并根据业务比例循环发起系统

调用。

不同业务场景对应不同的数据置备方法，如模拟系统

初始化后测试需要将订单表和成交表清空，而模拟业务

高峰期时的测试则要根据实际生产情况对订单表和成交

表进行装载后再开始压测。

测试数据包括吞吐量、延迟、资源消耗、稳定性等

方面，根据“指南”的标准分类，中信建投将压力测试

指标进行了规范，具体内容见下表。

应用系统变更升级前会对所有功能号进行四种不同

的压力测试，分别为全功能测试、主要功能测试、单功

能号基准测试、业务突发模拟测试。全功能测试即是将

实际生产中发生的所有业务进行全覆盖测试，通常会涉

及到上百个功能号，该测试优点是尽量模拟生产系统的

所有业务情况。主要功能测试则是将生产环境占比前

99%的功能号纳入到测试范围，将调用功能号个数减少

到40以内，该测试基本可以反应出实际生产情况。单功

能号基准功能测试为每个功能号分配固定的压测时长，

根据配置的用例，逐个压测功能号，用于测试每个功能

号的基准性能情况。业务突发模拟测试是在主要功能测

试的基础上，逐个将某一业务量配比提高3倍，观察其对

系统性能的影响。

除了常规压力测试之外，日常压力测试工作还包括若

图3：压力测试流程（KCXP为消息中间件） 表1：测试指标

ITRDC证券信息技术研究发展中心（上海）

49 干专项测试内容，如业务系统配置变更、新版本报盘软

件变更、操作系统版本或杀毒软件版本变更等。无特殊

要求的情况下，此类测试内容与常规压力测试基本相同。

2.6 测试报告

每次压力测试之后都会生成压力测试报告，记录压

力测试的全过程，主要包括压力测试环境、用例、过

程、结果、异常等信息，并且给出本次压力测试的结

论。压力测试报告会备份并保存，以备比对分析、检查

审计、跟踪回顾及经验总结。

证券基金行业信息系统对性能要求越来越高，关键信

息系统的压力测试已经开展了许多年。然而行业级别的

相关标准和制度相对缺乏，相关机构各自为战，隐藏着

诸多风险。“久旱逢甘霖”，2023年中国证券监督管理

委员会科技监管局联合多家机构发布了《证券期货业信

息系统压力测试指南》（意见征求稿），对于行业的指

导意义巨大。中信建投证券开展压力测试工作以来，有

效提升了交易系统测试质量，控制了业务量增大等情况

带来的性能风险，防患于未然，保障了交易系统运行的

稳定性和可靠性，但是在规范化、科学性方面存在一定

的缺陷。本着“真学真用，先行先试”的思想，压力测

试项目组深入学习和参考“指南”，对信息系统压力测

试工作进一步完善，尤其在测试流程、测试指标度量等

方面更加规范、科学、有效，切实保障信息系统平稳高

效运行。

参考文献：

[1]中国证券监督管理委员会，《证券期货业网络和信息

安全管理办法》，2023年2月

[2]中国证监会科技局，上海证券交易所等，《证券期货

业信息系统压力测试指南》（意见征求稿），2023年10月

三、总结

《交易技术前沿》总第56期

50

应国力、李健舒、王海兵、张贺龙、刘军｜上海金融期货信息技术有限公司

E-mail：yinggl@cffex.com.cn

交易全链路追踪监控实践

目前全链路追踪在互联网行业微服务体系架构下应用非常广泛，但在金融行业特别是证券期货交易系统上

使用案例甚少，主要原因为金融行业对系统安全稳定运行要求较高，系统的升级频率低，交易系统引入这

种注入式链路追踪的风险较大。针对该现状，中国金融期货交易所（以下简称为“中金所”）自主设计研

发了基于网络镜像技术的交易全链路追踪方法，该方法在不影响主交易系统实时交易的情况下，通过解析

核心网和接入网的镜像流量，实现对交易系统逐笔委托及行情纳秒级精度的延时测量和监控，具有对系统

无侵入、实时性强、精度高、易扩展、可视化等诸多优点。

全链路追踪；交易系统；逐笔监控；无侵入

交易全链路追踪监控主要由4大模块组成，分别为

SPAN镜像模块，数据采集分析模块，大数据可视化模

块，主要架构如图1所示：

SPAN镜像模块 负责将接入网与核心网交换机的全

量网络数据包实时镜像到数据采集模块，其通过端口镜

像方式采集数据包，不会占用交易主机资源与交易核心

网带宽，且对应用无侵入、无感知，符合交易链路场景

中的安全要求。

数据采集分析模块 通过应用性能管理工具（以下简

称“APM”）的网络抓包单元捕获接入网与核心网的全

量网络数据包，并对全量交易网络数据进行逐笔分析。

其具体功能包括数据过滤、数据预处理、协议解析、字

段解析、数据管理、数据分析、格式化落地、并行加速

等，上述功能完全自主开发，单实例性能可达10万笔报

单/秒实时解析。其支持横向扩展，理论上限为机器资源

上限。

大数据可视化模块 负责展示分析结果与检索历史分

析结果。其基于SPLUNK与云原生技术，可以在Web端

便捷访问，在以亿为单位的数据记录数的数据库中，检

索性能可低至10毫秒级。其支持海量图表 ，通过可视化

与拖拽式操作可快速制作数据展示视图与告警监控视图。

部署方案如图2所示，当有交易数据产生并以网络包

形式进入交换机时，SPAN镜像模块将数据从交换机镜像

到目标网卡。数据采集模块将原始网络包同步至数据分

析模块，数据分析模块对网络进行解析与过滤，并根据

需求进行各种数据分析，并将结果进行格式化落地。大

数据可视化模块对落地数据建立索引，并对可索引的海

量数据提供可视化服务，最终用于分析与展示。

2.1 SPAN镜像

SPAN（全称Switched Port Analyzer）技术是一种

网络设备的镜像技术，主要用来监控网络交换机上的数

据流，使用SPAN镜像可以在不干扰现有业务的情况下，

一、整体架构及部署方案

二、关键技术

摘 要：

关键词：

图1：交易全链路追踪监控架构

图2：交易全链路追踪监控部署方案

ITRDC证券信息技术研究发展中心（上海）

51 将需要监控的网络流量通过旁路的方式，发送到本地或

者远端设备上，在网络监控排障、网络抖动延时分析、

网络流量异常等方面使用非常广泛。金融期货交易系统

特点是高可靠、高并发、低延时、网络流量集中（行情

瞬间），采用常规的基于日志采样的监控采用频率低，

导致监控精度低；而基于注入式的链路追踪监控，则需

要侵入改动系统，带来非常大的升级成本，对系统的稳

定性也有较大影响。而基于SPAN技术的数据分析，可以

很好的满足金融期货交易系统的监控需求。本实践使用

SPAN技术，可以在不影响报文正常处理流程的情况下，

将镜像端口的报文复制一份到观察端口，再通过APM分

析模块来分析复制到观察端口的报文，进行网络及应用的

监控和故障排除，具有对系统无侵入、实时性强的优点。

为了提升监控精度，本实践支持两种精度模式。如

果网络设备是低延时网络设备，支持ERSPAN

（Encapsulted Remote Switch Port Analyzer），网络

报文的时间戳可以直接使用ERSPAN包头时间戳，精度可

以达到百纳秒级，如果网络设备是普通的网络设备，只

支持常规的SPAN，网络报文的时间戳可以采用APM主机

的时间戳，精度为微秒级。目前金融期货交易系统领域

的延时通常在百微秒量级，在资源有限的情况下，采用

APM主机的时间戳基本满足业务需求。

交易系统的前置、撮合、行情等所有模块进出网络

设备的数据流都会通过SPAN汇集到APM主机接收端网

卡，特别需要注意的是，SPAN流量镜像时要考虑交换机

入口的带宽，如果入口带宽是千兆，可以多个口汇聚到

一个口上；如果入口带宽是万兆，只能一对一SPAN，否

则可能会出现较高的丢包率，影响监控精度。

2.2 抓包

通过配置网络设备，可以把SPAN镜像流量推送到指

定的主机网卡，数据到达网卡后，还是原始的网络报

文，原始报文的目的IP和端口并不是APM主机所在的网

卡IP和端口，无法使用操作系统提供的SOCKET函数库获

取原始报文。本实践基于libpcap函数库在APM中设计了

一个网络抓包单元，用于捕获原始网络数据包。网络抓

包单元的核心功能是捕获网络数据包，支持各种参数配

置。APM所在主机需要接收各个模块的流量，通常会采

用多块网卡作为不同业务镜像流量的目标端。所以抓包

单元需要支持配置指定要捕获数据的网卡接口。另外，

对于不同的镜像流量，采用的传输层的协议可能不同，

同一个流量内部可能有需要关注的数据，也有需要过滤

掉的数据，所以抓包单元需要支持指定要捕获的协议类

型，从而减少不必要的数据量。此外，抓包单元也需要

支持指定端口号，以便于只捕获特定端口上的数据流。

金融期货交易系统在行情推送瞬间通常有非常大的网

络流量（微爆现象），即使是万兆网卡也存在瞬间流量

满载的情况，所以抓包单元的瞬间吞吐能力是整个链路

追踪系统的关键性能指标，APM单个进程可以配置多个

抓包单元，每个抓包单元由单独的线程驱动，通过配置

线程池的方式管理抓包单元可以实现抓包单元的灵活伸

缩，满足不同硬件条件和业务监控场景下的抓包需求，

同时不影响系统的稳定性和响应时间。根据测算，单个

抓包单元可以达到8万笔报单/秒，全链路最高30万笔报

单/秒的抓包性能。

捕获的数据通常会被存放在缓存队列中，等待进一

步的处理。这个队列可以是内存中的数据结构，也可以

是磁盘上的文件。存放数据的方式可以根据具体需求进

行配置，以确保数据不会丢失，并且能够高效地被后续

的数据分析程序处理。

2.3 消息解析

解析线程从缓存队列中读取数据后，对原始的链路

层消息进行解析，包括TCP/IP协议层转换、缓存定序、

应用层解析、消息过滤。消息解析完毕后，会实时落地

成解析后的文件。

TCP/IP协议解析 APM的输入是交易系统数据链路

层消息，需要完整解析整个TCP/IP协议栈。libpcap库提

供了基础的抓包接口，APM通过调用libpcap的抓包接

口，从网卡抓取原始的链路层报文，然后从下往上依次

解析MAC层、链路层、IP层、TCP/UDP层的协议。

缓存定序 镜像流量无法保证数据可靠传输，所以原

始报文中可能存在丢包、重传、乱序、数据不完整等现

象，APM为了保证数据的正确解析，底层创建了一个定

序缓存，用于保存接收的数据，所有收到的TCP消息，都

需要通过定序缓存，如果收到的的包是一个完整的业务

包，才进行解析，如果出现包有缺失，则丢弃。

应用层协议解析 SPAN的流量有接入网流量和核心

网流量，其中接入网流量网络层使用的是TCP协议，应用

层使用的是FTD协议；核心网网络层使用的是UDP协议，

应用层使用的是XTP协议（XTP为中金所自定义消息协

议）。APM可以根据输入协议类型动态选择解析应用层

协议。

消息过滤 随着期权的推出，每天交易和行情的数据

量可以达到百GB级别。如果对所有的消息都进行索引和

归档，资源的需求是巨大的。所以为了节省硬件资源，

APM支持对消息进行过滤，过滤规则包括：

（1）消息种类过滤：APM支持业务消息种类级别的

过滤，用户可以通过IGNORE_TID选项忽略掉不想落地的

消息种类，比如资金持仓切片、合约状态切换等消息；

（2）字段过滤：APM也支持字段级别的过滤，考虑到某些

字段可能是敏感字段，或者不需要的字段，可以在配置文件中把

《交易技术前沿》总第56期

52

该字段设置成FALSE，从而避免该字段的输出；

（3）IP过滤：SPAN操作会把交换机指定端口上的所有流

量都进行转发，有些IP的数据可能不是用户关心的，可以通过过

滤操作，去掉不关心的数据；

（4）行情采样过滤：目前TCP行情是轮询发送，如果行情

席位有1000个，那么同样的一笔行情通过SPAN以后就会有相同

的1000份数据。APM支持配置采样间隔，从而大大减少行情消

息数量。

pcap包分析和落地 APM支持直接分析通过其他抓包工具（如

tcpdump）抓取的pcap包，也可以通过添加参数落地pcap包。

系统无侵入 传统的链路追踪的方式通常是通过日志采样或

者字节码注入等方式追踪订单。采用日志的方式，系统性能开销

大，采样频率低，很难观测到系统的微观层面的运行状态，特别

是对于期货交易这种周期性微爆流量的场景，采样很难真实的反

映订单在系统中的实际延时分布情况。基于字节码注入的链路追

踪方案需要预定义注入逻辑，修改代码进行适配，如果分析逻辑

或者统计方式发生变化，就需要改动被监测系统的代码。而交换

机SPAN镜像的方案，直接通过交换机的SPAN功能，从网络层

面镜像一份数据，被监测系统无侵入、无感知。

追踪精度高 基于日志或者字节码注入的追踪方式，通常使

用的是主机时钟，精度单位为微秒，不同主机之间，使用NTP时

钟校准，如果出现时钟校准失败，对产生的数据精度会有很大的

影响。 基于网络镜像的方式，有两种精度模式，如果采用交换

机的时钟戳，精度可以达到百纳秒级，如果采用主机的时间戳，

精度可以达到微秒，两种方式可以同时工作，相互佐证，有很高

的容错性。

监控精细化 数据实时同步、实时分析、实时展示，相比与

基于采样日志的追踪方式，全链路追踪方案能从更细粒度的对金

融交易系统的服务质量进行度量，基于全链路追踪技术，引入了

业务指令网络分段耗时、服务质量抖动概率密度、行情驱动抢单

分析、前置分发时延差异等数十个细粒度监控指标，图3为

SPLUNK中的行情推送延时分布图。

方案易扩展 本实践支持会员、席位、客户等多级别的订单

和行情追踪，从一笔订单进入交易系统到排队、撮合、以及产生

行情等进行全链路追踪。系统支持单实例多端口和多实例多端

口两种部署模式，单实例网络抓包峰值速率可以达到10万笔报

单/秒，支持水平扩展，在资源充足的情况下采用多实例多端口

模式，处理速度快，实时性高。如果计算资源有限可以采用单实

例多端口模式，节省资源。

本文对交易全链路追踪监控的架构和关键技术分别进行了

介绍和阐述。为了解决金融期货交易系统性能和业务实时监控侵

入性强、精度低、延时高、可扩展性差的问题，本实践采用全链

路跟踪的思想，在不影响主交易系统实时交易的情况下，提出了

一种更加轻量化、精细化的监控方式。目前，该方案已在生产和

内部开发测试环境投入使用，至今已在多个应用场景中落地，并

发现多个常规监控手段无法监测的现象，见表1。

随着中国金融市场的发展，交易所业务量和业务复杂程度

必然会不断上升，如何更好地进行全链路追踪监控、提早发现隐

患显得愈发重要。中金所后续将继续精进，持续探索优化，为金

融市场稳定运行做出贡献。

参考文献：

[1]Dapper, a Large-Scale Distrubuted Systems Tracing

Infrastructure [ER/OL].http://research.google.com/pubs/-

pub36356. 2010.

[2]Cisco Systems Inc, Catalyst 3550 Multilayer Switch

Software Configuration Guide [M]. 2006.

[3]戴昆，约翰逊，默克,等.Splunk智能运维实战[M].机械工业出

版社，2015.

三、系统建设成效

四、总结与展望

图3：行情推送延时分布图

表1：APM应用场景

ITRDC证券信息技术研究发展中心（上海）

53 计平台，将体系思想融入到平台中，通过工具来辅助推

动保障体系的形成和发展。

2.1 面临问题

通常，代码审核会作为软件开发流程的一个必选

项。常规的代码审核工作会在软件开发过程中进行，通

过检查代码来确保其质量和可靠性。同时在审核过程中

辅以模糊测试等安全检测手段，可达到及时发现软件缺

陷及漏洞的效果。[1]但是券商作为软件使用方，通常不

直接参与软件研发，因此券商对代码审计过程与供应商

软件研发过程是相互独立的，这就无法有效使用传统的

代码审核方式，需要另辟蹊径，找到符合实际情况的代

码审核措施。经过长期观察及经验总结，在审核实施过

程中遇到了以下问题：

1) 不规范的编码风格成为阻碍代码理解的障碍

软件编码需要遵循安全编码规范是业界共识。由

于软件研发人员的能力水平和编码习惯，会形成不同的

编码风格，而这些风格化的代码就制造了旁人阅读理解

的屏障。

2) 审核人员与软件开发人员之间缺少有效沟通机

制

沟通是帮助代码审核人员理解代码，了解软件设计

思路，从而能够进一步结合已有经验去发现软件缺陷的

基础。但事实上，券商作为软件使用方，很难与供应商

开发人员保持稳定的沟通，无法及时准确地获取软件程

序的相关信息，从传统代码审核方法角度来讲，已经失

去了这项工作的开展基础。因此，从券商代码审核角度

出发，审核人员与软件开发人员之间的有效沟通机制是

缺失的。

3) 券商审核工作量较大且集中是代码审核质量的

一大困境

华仁杰，唐淑艳，华焰，施爱博｜东吴证券股份有限公司｜E-mail：shiaib@dwzq.com.cn

证券核心交易系统代码审计平台建设实践

核心交易系统是券商业务开展的重要核心系统，其软件质量关系到所有投资者的交易安全。本文详细分析

了券商开展此项工作所面临的问题和应对思路，在此基础上研发了代码审计平台，实现落地应用，把代码

审查能力赋能到测试运维之中。平台实际投入使用后，取得了良好的使用效果，有效提升了代码审核质量

与效率，全面加强了代码审核体系建设，形成了一道行之有效的代码保护屏障。

代码质量保障；代码审核；证券核心交易系统

核心交易系统是券商业务开展的重要核心系统，

其软件质量关系到所有投资者的交易安全。随着证券业

务和技术发展需要，核心交易系统进入信创改造与日常

运维系统升级的叠加，因此软件产品质量保障是一项十

分重要工作。

软件代码是构建系统软件的逻辑基础，从代码层

面进行审查、杜绝系统安全隐患是软件工程常规方法。

代码审核是通过编码以外的人员检查代码是否存在安全

隐患，以此来保持代码和产品质量的一个过程。通过代

码审查能够尽早地发现软件的缺陷，找出动态测试难以

发现或隔离的软件缺陷软件。

通常代码审核都是基于软件开发团队内部的一项

工作，适用于熟悉项目的人进行审核。券商作为软件采

购商，并没有参与到具体的软件研发过程中，而且券商

系统代码变更频繁，审核工作量较大，这种作为第三方

的代码审核模式往往事倍功半，因此经了解，鲜有券商

会采用人工审核的方式来进行软件质量把关，并且业内

也没有成熟有效的方案来适用于第三方审核。那么，随

之带来的困境就是在系统出现问题的时候，券商严重受

限于对供应商的依赖，往往无法第一时间找到问题根

源，延误了处理问题的时机。

如何进一步有效提高生产安全是券商重点关注的问

题。在建立健全系统软件质量保障体系，规范系统建设

升级流程的基础上，东吴证券多年以来坚持将代码审核

作为保障系统软件质量的一道门槛，尤其在核心交易系

统信创改造阶段，进一步加强探索适合券商端代码审核

的工作思路，形成了规范化、自动化、工具化、数据

化、智能化的代码审核方法，并以此打造了东吴证券代

码审计平台。

本文将从工作思路入手，分析券商在核心系统代码

的质量保障方面所面临的问题，并提出应对方法，在此

基础上着手构建代码质量保障体系，并研究开发代码审

摘 要：

关键词：

一、概述

二、工作思路

《交易技术前沿》总第56期

54

由于无法详尽知道开发计划，券商审核人员一般

等待供应商发布升级包，确认升级项后，再查找对应代

码，对变动代码进行审核。因此，会在升级前夕聚集大

量的审核任务。在有限时间的情况下进行代码审核，必

然会影响代码审核质量。普遍认同的观点是，要控制单

次代码审核的时间，否则审核效率及质量会急剧下降。

同时，人员配备不足也会造成工作量的囤积。

4) 缺乏专业领域软件的针对性审核

采用传统方法对特定专业领域软件进行代码审

核，只能关注代码本身的逻辑问题，与专业领域知识相

隔离，不易发现与功能逻辑相关的有价值的问题。此

外，在实际工程中，由于未对特定专业领域软件的代码

审查方法进行归纳总结，从而造成了同一专业领域的软

件的不同的测试项目的代码审查工作之间的可借鉴性不

强，效率不高。[3]券商端代码审核必然是要充分结合业

务，有针对性地进行业务逻辑方面的审核。

5) 无法在代码层面快速定位问题

在实际运维过程中，当出现问题的时候，只能定

位到故障模块，很难进一步查找到错误原因。如果此时

依赖供应商远程解决，增加了沟通成本和处理问题的时

效性。如果能够快速找到问题所关联的代码，将代码与

问题查找相结合，必然能够提高实时解决问题的能力。

目前，还未有相关产品能够把代码引入到运维阶段，是

一个值得尝试的方向。

2.2 应对思路

目前核心系统处于持续优化阶段，同时，证券业

务发展迅速、需求变化较大，系统代码修改是一个常态

化的过程。券商作为使用方，代码安全审计可用于软件

升级上线前的审核检查，降低错误发生风险。可以看

到，券商有必要把好升级软件的最后一道关卡，从使

用、运维的角度去审计升级软件。

结合当前软件升级质量管控现状，制定了如下的

一些代码审核措施方向，希望能够提高审核效率，提高

代码质量保障能力。主要从以下几个方面入手：

1) 采用多人审核制度

每个人保持对单独一块业务的持久专注，能够解

决业务纷繁复杂并不断增长变化的现实情况，保证审核

人员对业务和代码有对应的深刻了解，同时借助平台实

现信息共享，加强审核人对软件的整体把控。

2) 记录评审结果，积累评审经验

通过参照前期评审结果，能够加深理解代码逻

辑，掌握代码编写特征，锁定易错点。将经验固化，转

化为辅助评审的重要参考。

3) 集成辅助工具提高效率

在审核过程中快速查询相关信息，包括数据库结构、

开发接口、数据字典、业务需求等定义，节省各种外部

工具的查询环节，专注并辅助理解代码逻辑，确认逻辑

的一致性。

3.1 架构设计

代码审计平台聚焦于升级模块代码的查阅、审

核，围绕核心目标建立了一套完整的工作流程：从升级

包分析、对应代码数据采集、多维度多方法审核、分析

数据归档、审核报告生成等过程。实现了审核周边流程

的全自动化，以及代码审核的辅助决策支持。

在技术架构方面，平台采用前后台分离模式，

web端设计相较于客户端更加具备灵活性和可扩展性。

通过与制品库、SVN服务器、Git服务器对接，完成了

升级模块及源码的整理归档。采集后的源码进入核心分

析阶段，平台提供多种辅助决策、智能化功能配合代码

审核人员进行代码审阅、记录、风险判断等工作。

3.2 平台功能

代码审计平台设计的功能围绕实际代码审核需要

设计而成，用于辅助人工代码审核，提高审核效率和质

量，快速了解版本更迭变化，定位问题，查找潜在风险

点等。

三、平台建设

图1：代码审计平台功能架构图

图2：代码审计平台功

ITRDC证券信息技术研究发展中心（上海）

55 图3：代码审计平台审核界面

图4：智能工具栏

1) 代码比较查阅

代码比较查询用于查找同一模块不同版本之间的代

码差异。通过了解代码变更情况，掌握软件升级源码级

变动点，以此对照判断代码是否符合变更逻辑，是否满

足修改需求。为了提升审核效率，适配审核方法，在源

码上进行了智能化处理，增加了特色功能。主要包括基

于软件版本的代码合并、便于版本追溯的版本比较、推

动代码理解的持续注解等。

2)代码静态扫描

静态检测技术涉及的主要方法包括静态分析和程序

验证。其利用二进制比对技术、词法分析、形式化验证

技术或者手工测试技术，对被测软件的源程序或二进制

代码进行扫描，然后从语法、语义上理解程序的行为，

分析程序的特征，找出可能导致程序异常的漏洞。[1]该

技术具有简单高效自动化的优势，缺点是仅对代码本身

的特征进行检查，对漏洞间复杂的逻辑关联检测力弱，

存在大量的误报和漏报。[2]

平台集成静态扫描工具，后台查找相应代码，自动

进行扫描，把扫描结果集成显示到了代码显示界面，能

够更加直观地定位可疑点。可结合代码特点筛选规则，

减少误报条目。

3) 智能工具栏

智能工具栏的设计用于在审核过程中，进行相关信

息的查询和一些特定功能的快捷应用。主要包括代码注

解、数据字典、数据库结构、功能码定义的查询。

其中，代码注解用于查询持续注解的列表内容，能

够快速加载当前代码所对应的注释，查看历史备注要

点，理解代码内容。数据字典是用于解释代码中字典项

的内容。数据库结构是很多上层应用程序设计的基础，

平台集成了数据库结构信息。功能码是交易系统中间件

基本功能服务单元的接口描述，是构成系统功能的重要

组成部分。

智能工具栏后台能够持续更新相关信息，使得在代

码审核过程中获取最新的内容。

《交易技术前沿》总第56期

56

图5：系统模块化设计

4) 辅助信息查询

辅助信息查询是辅助代码审核过程中进行各种信息

查询，包括资料文件的汇总、数据库、功能码等各种信

息。相比智能工具栏，这是一个全局的查询入口，可以

进行成体系的信息查询。辅助信息查询背后所形成的知

识库是长期积累而成。例如资料文件可包括交易所接口

文件、成体系的代码说明、功能设计文档等。并可以将

文件生成超级链接，插入到代码注解或审核意见中，方

便参考。

5) 审核报告生成

审核报告集合了审核人员代码审核意见、版本说

明、代码变动说明，对每一个升级模块的审核情况进行

了描述。审核报告可以生成导出成word文档，用于归档

管理。

4.1 多维度代码审核体系

核心交易系统的代码质量保障工作有多种方法途径

可展开，平台充分融合各种技术，从多个维度对代码进

行审核，采取多重措施来保障代码质量。平台设计了静

态扫描、人工审查、关联分析、接口审查等。

接口审查可以确保代码接口符合预定义的标准和规

范，确保代码质量和稳定性。并且可以检查代码间的兼

容性和整合性，防止引入新的错误，是保证代码软件质

量的关键步骤。

4.2 插件式自动化审查

除了代码语义层面的静态扫描之外，平台通过插件

加强自动化审查。插件可以获取代码内容，结合后台知

识库，对代码进行分析。可以从业务层面出发，有针对

性地检查代码风险点。例如，对代码中的功能码调用入

参、出参进行扫描，比较接口定义，判断参数类型、必

传项等是否一致，减少代码错误的发生。

插件式设计可以灵活地扩展平台自动化审查能力，

从各个角度多重叠加，降低代码漏洞风险。

4.3 代码结构关联性分析

核心交易系统作为一个大型复杂系统，采用了模块化

架构设计，主要将系统划分为菜单模块、中间件模块、

数据库表及存储过程。从图5的模型可以了解到整个系统

模块间的分层调用关系：菜单调用中间件功能，中间件

既可以调用中间件其他功能，也可以访问数据库，同时

一个菜单功能封装在一个菜单动态库中，而一个中间件

动态库则封装了多个中间件功能。

截至最新的统计结果，整个集中交易系统包含了菜

单1628个，中间件功能4456个（封装在144个动态库

中），涉及到的数据库表或存储过程636个，存在各模块

直接的调用关系18170条。面对拥有如此庞大复杂功能的

系统，理清其内部的逻辑关系是十分重要且关键的工

作。为此，可以将菜单、中间件、数据库、动态库这些

元素视作不同类型的功能节点，根据它们之间的调用、

包含关系，形成了类似图状的“功能网络”拓扑结构。

平台利用代码中功能调用和数据库访问的基本特

征，解析抽取了用于构建“功能网络”的各种要素及要

素之间的关系，并最终存储到了图数据库中，进而可以

快速地挖掘某一特定功能的网络关系。

除了一些基础的关系查询，可以从整体网络的角度

做一些数据统计。例如进行模块扇入扇出、计算网络直

径、紧密中心性、介数中心性等网络分析，后续的工作

中将对“功能网络”进行更多方面的网络分析，以及通

过社区发现等算法查找关联度紧密的菜单、中间件功能

或数据库表等，从而理清系统功能的逻辑脉络，为系统

测试、代码审核提供参考。

4.4 智能化代码辅助理解

根据数据分析发现，从代码行数来看，超过400行的

代码审核，缺陷发现率会急剧下降；从审核速度来看，

超过500行/小时后，审核质量也会大大降低，一个高质

量的代码审核最好控制在一个小时以内。[5]具体数据可能

因人而异，但总体情况确实如此，评审人对持续代码审

核工作会产生效率下降的状况。[6]但券商端代码审核工作

又比较集中，为了解决矛盾，需要辅助提升审核人员对

代码的理解能力。

平台集合了持续注解、智能工具栏等信息参考工

具，为审核人员在审核过程中提供了强大的信息参考支撑。

在代码审核过程中，尝试引入该工具辅助代码理解。经

过试验，AIGC（生成式人工智能）可以有效地添加用于

四、关键技术及创新点

ITRDC证券信息技术研究发展中心（上海）

57 辅助理解的注释，显示出了AI对于编程以及代码审核这一

领域的能力，可以视为代码审核未来发展的一个方向。

从平台角度考虑，多了一道智能审核渠道。但是依据目

前的AI发展现状，尚不能完全依赖AI进行注释，会有一定

的错误率。同时，AIGC技术可能涉及侵犯知识产权，存

在代码隐私泄露等问题，在使用过程中还需加以甄别，

目前的AI发展对代码理解仅可作为参考。代码审计平台将

保持一个开放的态度，积极拥抱探索新技术所带来的能

力，促进代码质量保障发展。

4.5 审核人员智能推荐

核心交易系统软件规模庞大，涉及大量的代码，需

要多人审核。不同审核人员的经验以及对功能点的了解

程度不尽相同，需要合理地指派审核人员审核代码。代

码审核人员指派的方法主要有：

1) 基于规则的方法

通过设置规则，系统能够自动根据代码的特征和审

核人员的专业知识，为代码选择合适的审核人员。代码

审计平台能够根据软件模块功能，预先设置指定相应的

审核人员，当某一软件模块需要审核，则自动指派给对

应的人员。

2) 基于审核历史的方法。

通过分析代码的审核历史情况，系统能够自动学习

审核人员的指定变化，根据审核变化情况选择合适的审

核人员。系统会根据历史审核时间远近、审核次数等参

数，加权重计算审核匹配度。

3) 基于关联模型的方法

代码审计平台参考代码结构构建了“功能网络”，

查找升级包中各升级模块之间关联关系，通过节点间路

径长度确定模块关联升级紧密度，以此将关联度紧密的模

块指定给同一审核人，提高代码审核的整体质量和效率。

自代码审计平台上线投入使用以来，已累计审核升

级包161个，涉及软件模块865个，功能模块4869个，承

接了大量的代码审核工作。2023年单月最高审核软件升

级包18个，有效应对高频升级下的质量把控问题。在审

核过程中，发现接口应用错误、代码笔误、代码逻辑错

误、升级包功能模块版本不一致、内存泄漏、编码不规

范等情况30多次，有效减少软件升级的潜在风险，提高

了质量把控能力和效率。

重新构建了与版本匹配的代码库，形成了审核意见以

及注解，保持最新的数据库表结构定义以及功能接口定义。

增加了强化审核的插件，查找接口应用及文档错误50多项。

东吴证券在坚持自身系统软件质量保障方针的情况

下，总结代码审核经验，提出适应券商的代码审核思

路，在体系架构上建设而成的代码审计平台能够有效地

进行审核工作的实施，并在测试、运维环境提供代码审

查能力。

代码审核平台针对券商进行供应商代码审核的实际

情况，解决过程中各种问题，符合特定的应用场景，是

代码质量保障体系重要的工具平台。平台按照实际审核

过程进行逻辑设计，引入了自动化、智能化技术，形成

了提升券商代码审核质效的有效方法途径，并基于归集

数据进行分析、反馈完善，对系统代码质量保障起到了

一个重要作用。

未来，将进一步完善核心交易系统代码质量保障体

系，优化代码审计平台建设，引入智能化、数智化能

力，挖掘新的行之有效的代码审核模式。同时丰富扫描

插件，多角度保障代码质量。

参考文献：

[1]罗琴灵. 基于静态检测的代码审计技术研究[D]. 贵州大

学, 2015.

[2]周景科. 专业领域软件的代码审查方法研究[J]. 软件可

靠性与评测技术, 2019, 29 (3): 1-7.

[3]李晓峰, 刘宏伟, 王建民. 基于静态分析的软件安全漏洞

检测技术综述[J]. 计算机科学与探索, 2019, 13(2):

191-210.

[4]张志强, 张亚军. 基于范根检查法的软件代码审查方法

[J]. 计算机工程与设计, 2017, 38(6): 1534-1538.

[5]蒋春华. 软件代码审查在敏捷开发中的应用研究[D]. 南

京理工大学, 2016.

[6]王慧娜. 基于结对编程的软件质量保证方法研究[D]. 南

五、实际应用 京理工大学, 2015.

六、总结

《交易技术前沿》总第56期

58

曾东明、沙烈宝、段苏隆、李银鹰｜国投证券股份有限公司｜Email：zengdm@essence.com.cn

基于eBPF技术的无侵入云原生

可观测性系统研究

随着证券行业数字化转型的加速，云原生技术如容器、微服务架构等已经广泛落地应用。然而，这些新技

术带来的技术复杂性，也给业务监控和问题诊断带来了新的挑战。本文总结了基于eBPF技术进行可观测性

系统构建的研究和探索，主要包括以下几个部分：首先，介绍了云原生技术下可观测性技术的挑战和研究

目的；接着，简要介绍了eBPF技术，包括原理和开发流程；然后，详细阐述了采用eBPF技术进行相关指

标的采集和数据分析的方法和实践；最后，对整个研究进行总结和展望。通过本文的探索，希望能为证券

行业提供新的监控和诊断思路。

eBPF；可观测性；无侵入式； Kubernetes

目前云原生技术已经在金融行业内广泛落地，以容

器和Kubernetes编排为底座的容器云平台已经成了数字

化转型的行业标配，并且还在逐步扩大云原生技术应用

范围，微服务架构、中间件容器化也都在逐步落地过程

中。这些新的技术趋势带来了资源利用率的提升，更高

的开发发布效率，更好的运维弹性，但是这些优点都是

以服务整体技术栈变得更加复杂为代价的。因此，在新

的云原生技术栈下，传统的监控、排障方法已经无法满

足需求，更复杂的技术栈对于业务提出了更高的可观测

需求。

eBPF技术近年来成为业界一个备受关注的用于可观

测性的一个解决方案。它能在内核中动态执行代码，深

度监测内核和业务逻辑，无需侵入业务代码。相较传统

的监控手段，eBPF以其无侵入性大大降低了业务接入难

度。同时，对于一些无法修改源码的系统，通过eBPF在

内核增加的探针能力，同样可以获取到服务之间互相访

问的可观测数据。

基于上述分析，希望通过本次基于eBPF技术的可观

测性系统的研究成果，实现更好的系统和应用程序的可

观测性，降低运维成本和风险；同时，也可以为证券行

业提供一种高效、可靠的可观测性解决方案，促进eBPF

技术在证券行业的推广和应用。

2.1 概述

eBPF技术是一种源于传统BPF（Berkeley Packet

Filter）技术的新型可编程内核技术，是Linux内核的一

项革命性技术。它提供了能够在运行时动态安全地修改

Linux内核行为的机制，而无需改变内核代码或者额外加

载内核模块。并且整个eBPF程序会运行在沙箱中，不会

对内核的稳定性造成影响。

目前eBPF技术目前主要用于三个方面：可观测性数

据采集、网络技术增强以及安全审计和安全阻断。在本

次研究课题中，使用eBPF技术做可观测性数据的采集，

并基于采集的数据，构建可观测系统。

2.2 技术原理

1） eBPF虚拟机及指令集

在Linux内核中，eBPF虚拟机用于执行eBPF指令/

字节码。虚拟机内建有一个校验器，用以确保eBPF字节

码的安全性，防止可能导致内核崩溃的操作，例如死循

环、无效跳转和内存越界访问等。eBPF虚拟机基于寄存

器架构，其指令集包含常见的算术逻辑运算、位操作和

跳转等指令。

2） eBPF程序类型

eBPF程序都是内核事件触发的，不同的hook点能

够执行不同类型的eBPF程序，且从hook点获取的入参/

出参也各不相同。在可观测性领域，本文关注的主要是

kprobe类型，即BPF_PROG_TYPE_KPROBE。

3） eBPF程序互操作与数据交互

eBPF提供了一组预定义的helper函数和一组特定的

内核函数，实现与内核的安全交互。在可观测性领域，

通常需要将eBPF程序采集到的数据进行统计和记录，然

后导出以供外部程序进一步处理和分析。为处理结构化

数据，eBPF提供了统一的Map能力的抽象，实现用户态

控制进程与eBPF执行代码之间的双向通信。

摘 要：

关键词：

一、研究背景和目的

二、eBPF技术简介

ITRDC证券信息技术研究发展中心（上海）

59 4） eBPF程序开发脚手架

eBPF程序的开发和加载，需要一系列的脚手架工

具，包括编译、加载、内核交互获取数据等。目前业内

有传统的bcc以及比较新的libbpf。本文选择了bcc作为

开发脚手架框架。

2.3 可观测性eBPF程序的开发和运行流程

如上图所示，开发者在完成eBPF程序代码编写后，

通过Clang编译器将其编译成字节码。这些字节码随后会

被加载到内核中。在加载过程中，内核中的eBPF校验器

会对执行指令的安全性进行检查。校验通过后，字节码

将被即时编译（JIT），并在事件触发时被调用。当相关

的eBPF代码因事件触发而被执行时，其逻辑可以执行数

据采集、统计、采样和记录等操作。在用户态，通过查

询Map来获取eBPF采集到的数据，从而进一步处理和分

析这些信息。

3.1 需求分析

基础设施的三大基石是计算、存储和网络，其中网

络问题最为常见，也是分布式系统故障排查的难点。除

了网络问题之外，其余的问题通常被归类为系统问题。

本文的需求是识别那些需要增强采集的网络和操作系统

指标。下面是一张关于可观测数据项的整体概览图。

1） 网络观测需求

在典型的容器网络方案中，当访问Kubernetes集群

外部网络时，通常在节点出口进行SNAT（源地址网络地

址转换）。这种方法会导致在集群外部网络出现异常

时，难以精确定位到具体的业务Pod。此外，在进行性能

分析时，业务通常需要细粒度的点对点网络监控。常用

的解决方案是在应用层使用APM（应用性能管理）工

具，通过在业务代码中埋点实现对业务访问情况的监

控。然而，这种方法对业务具有侵入性，并增加了业务

的复杂性。

综上所述，一个高效的网络可观测性系统应满足以

下需求：首先，数据采集需要细粒度，收集的数据应能

追溯到最原始的业务容器，并实现不同层级的数据聚

合。其次，网络指标应得到增强，相比传统的网络监

控，系统应额外采集常见错误和异常场景的指标。此

外，网络协议解析应做到无侵入性，应利用eBPF技术对

HTTP、Redis、Kafka等网络协议进行解析，而无需修改

业务代码。

2） 系统观测需求

系统问题主要可以分为以下几类：CPU调度、内存

分配管理、文件操作及IO访问。对于CPU调度，随着现

代机器中的CPU核数逐渐增加，CPU架构日趋复杂，需

要对CPU的调度情况进行监控。在内存分配管理方面，

需要对内存缓存的使用情况、内存申请延迟以及内存回

收过程进行细粒度的监测。对于文件操作，需要采集相

关文件操作的延迟数据。在容器场景下，还需特别监控

两个特定的文件访问延迟：overlayfs的copy up延迟和

PVC远程文件系统访问延迟。综上所述，可观测性系统在

系统层面的监控应涵盖CPU调度、内存分配管理、文件

操作及IO引起的问题，以帮助业务迅速定位问题。

3.2 整体系统设计

上图是容器云场景下的整体数据采集设计框图：

·Agent、Cluster、Storage是数据流的核心组成部

分；

·Agent以Daemonset的方式部署到每台机器上，负

三、研发实践

图1：开发和运行eBPF程序大致流程

图2：可观测数据项的概览

图3：采集设计框图

《交易技术前沿》总第56期

60

责采集指标以及监听的 IP 和端口的元信息；

·Cluster Agent以集群的方式部署，负责整合指标

和监听的IP和端口元信息，形成容器到容器的访问

Metric；

·Storage负责存储Metric；

·Topology Compute是一个存储的消费端，负责消

费Metric产生拓扑图数据；

3.3 技术实现

网络指标包含四层网络指标和七层应用层协议指

标。四层网络指标涵盖了TCP的收发带宽、TCP RTT平均

和最大延迟以及TCP异常关闭连接等。而七层应用层指标

涉及HTTP、Redis、Kafka、MySQL等协议的请求、错

误和延迟指标。四层指标主要用于基础设施的网络监

控。通过细粒度的网络指标可以感知容器之间互访的网

络质量，进行网络带宽审计，识别并绘制出容器之间的

业务依赖关系，形成业务依赖拓扑。此外，这些指标还

可以记录业务容器的网络访问痕迹，帮助发现潜在的安

全风险并进行影响评估。七层应用层指标则用于业务监

控，通常用于观测业务的稳定性以及无侵入的业务调用

拓扑分析。

1）四层指标采集实现

Agent负责从内核的eBPF程序的Metric Map中提取

具体的TCP指标，以及监听的IP和端口等原始信息。这些

原始数据需要进一步与业务数据进行关联处理。在原始

数据采集过程中，涉及的技术要点如下：

·TCP连接会话跟踪。主要维护一个以socket为键的

Map，用于记录与socket对应的监控元数据。

·内核conntrack跟踪。主要用于将经过NAT转换后

的IP地址和端口还原为真实的地址和端口，确保数据正确

关联到相应的业务。

·指标跟踪。Metric Map主要用于记录点对点粒度的

网络监控数据，包括各种TCP指标。

·TCP端口监听跟踪。主要用来记录机器监听的IP和

端口以及容器的对应关系，这有助于更好地进行元数据

分析，包括分辨是否为客户端或服务端。

指标采集需要在不同的hook点上实现，具体的指标

项和对应的hook点如下表所示。采集到的原始数据将由

Agent根据业务元信息进行进一步增强，添加更多的业务

信息到指标的标签中，以方便业务的检索和分析。

2）七层指标采集实现

针对不同场景下的需求不同，七层应用协议指标采

集提供了精简模式和精细模式。精简模式聚焦于应用粒

度的请求QPS、错误率和请求延时等指标，不对协议进

行更细粒度的分析。精细模式则将这些指标精确到应用

的请求路径粒度。例如，HTTP协议精细到URL级别，

MySQL协议精确到SQL语句模板级别。如下图所示，七

层应用协议指标采集和四层TCP指标采集的实现方式大致

相同，差异点在于七层协议指标计算的hook点在

tcp_sendmsg和tcp_recvmsg这两个地方。此外，精细

模式的额外协议解析将消耗更多的资源。

图4：四层指标采集逻辑示意图

表： tcp采集的指标以及对应的hook点

图5：七层指标采集逻辑示意图

ITRDC证券信息技术研究发展中心（上海）

61 3）业务访问拓扑实现

如果业务规模较大，将会产生大量指标数据。在构建

拓扑时通常需要进行各种指标聚合。因此，如果每次都

实时从时序数据库中获取数据，将会给时序数据库造成

较大压力。为解决上述问题，本文提出了一个解决方

法，即通过预先计算并缓存结果，来有效缓解压力。如

图6所示，图计算服务会周期性地从指标存储中获取所有

指标进行计算，然后将计算好的图形结构存储到缓存

中。图计算服务可对外提供API，用于实现拓扑图的过

滤、筛选和查询限制等功能。经过实践证明，拓扑图在

包含10,000个图节点和100,000个图线的情况下，可以实

现秒级响应，大幅提升用户体验。

4） 系统指标采集

在容器原生采集指标的基础上，本文额外采集大量的

系统深度指标，这些指标在业务层面具有较高的价值，

表2是主要采集的系统深度指标的说明：

3.4 性能影响分析

eBPF程序在内核中基于事件触发运行，不可避免地

带来一些开销，从而影响业务性能。为了深入了解eBPF

程序对业务性能的影响，本文针对多种场景进行了详细

测试。根据测试结果，通常情况下，业务延迟增加在

1%-10%之间，CPU的额外消耗在5%-15%之间。当然，

如果开启更精细的采集，开销也会相应增加。

以下是一个具体测试场景的数据，供参考。该场景

选择了最常见的Nginx服务，使用wrk工具模拟不同的请

求压力情景，对比了开启和关闭eBPF探针情况下，

Nginx服务的请求延迟和整机CPU平均使用率的变化情况。

图6：图计算服务说明

图9：网络层监控指标界面

表2：主要的系统深度指标

《交易技术前沿》总第56期

62

图8：开关eBPF的CPU使用率性能对比测试

图 7：开关eBPF的TPS性能对比测试

从测试数据可以看出，P99时延从1.85毫秒增加到

1.92毫秒，时延增加约3.7%。整机CPU平均使用率从

4.4%上升到5.1%，大约增加了15%的CPU消耗。由于

Nginx本身对时延敏感性较高，这些数据可以作为其他业

务评估时的参考基础。实际上，对于普通业务，影响通

常不会达到如此显著的程度。

3.5 应用落地效果展示

上图展示了一个网络层监控指标，可以帮助业务进

行实时监控、可视化和优化网络性能，其带来的价值包括：

·提高业务性能：通过对监控数据的分析利用，业务

可以用来优化网络连接，提高业务性能。

·减少故障时间：可以帮助业务快速发现和解决网络

问题，减少故障时间，提高业务连续性。

·优化资源利用：通过分析网络流量数据，可以帮助

业务优化资源分配，提高网络设备的利用率。

图10：网络拓扑界面

图11：应用层指标界面

ITRDC证券信息技术研究发展中心（上海）

63 ·提高安全性： 可以监控网络流量中的异常行为，帮

助业务及时发现和应对安全威胁，提高网络安全性。

上图展示了一个网络拓扑，旨在基于收集到的网络

流量数据显示服务和应用之间的依赖关系和通信状况。

对业务而言，其带来的价值有：

·提高服务可视化：以图形化的方式展示服务和应用之

间的依赖关系，帮助业务直观地了解服务间的通信状

况。

·故障排查：可以实时显示服务之间的通信性能指

标，帮助业务快速定位故障服务和连接。

·性能优化：通过分析网络拓扑中的流量和性能数

据，业务可以发现服务间的瓶颈和优化点，从而优化服

务性能。

·规划与扩展：可以帮助业务了解现有服务的规模和

复杂性，为服务规划和扩展提供有价值的参考信息。

·提高协作效率：网络拓扑可以作为团队间沟通的基

础，帮助开发人员、运维人员和管理者更好地协作，共

同解决服务问题。

·安全管理：网络拓扑可以帮助业务发现未授权的服

务和连接，提高服务安全性。

上图展示了对应用层指标进行无侵入式采集，成功

实现了指标采集与图表绘制。对于一些老旧系统，无侵

入式采集方式通常是唯一可行的应用访问数据观测手段。

4.1 总结

本文顺应业界趋势，探讨了使用eBPF技术来增强业

务可观测性的方法。通过对网络和系统的无侵入式监

测，获得了细粒度和深度的指标，并构建了业务访问拓

扑。此外，本文对eBPF技术在指标采集过程中对性能的

影响进行了定量分析，为大规模部署基于eBPF的可观测

系统提供了可行性研究和宝贵经验。本文的实践表明，

基于eBPF的可观测技术是对传统监控手段的有力补充，

有助于更精准地定位和解决问题。然而，由于eBPF技术

涉及对内核的增强，对于一些对延迟敏感且请求量大的

业务，仍可能产生一定的性能影响。

4.2 展望

首先，当前可观测性系统在特定内核版本和操作系统

上使用bcc作为开发框架。鉴于移植性和内核版本/架构的

适配问题，未来计划将开发框架从bcc转换到libbpf，以

实现“一次编译，到处运行”的目标。

其次，目前的观测数据采集中大量使用了kprobe和

kretprobe，但在测试中发现对业务性能造成了一定影响。

因此，需要持续优化，包括重新寻找更合适的观测点和优

化代码逻辑，以提升系统性能。

最后，eBPF采集到的观测数据只是可观测性系统的

一部分，而且eBPF技术本身具有广泛的应用潜力。因

此，可以结合其他可观测数据，打造一个统一的观测系

统；同时，eBPF技术的使用也可以扩展到增强网络功

能、安全阻断等多个领域，从而发挥更大的价值。

参考文献：

[1]刘畅.(2020).基于 eBPF 的容器网络可观测性方法与实

践.(硕士论文).浙江大学

[2]高巍. (2022). 基于操作系统 eBPF 在云原生环境下的

技术研究. 电子技术与软件工程.

[3]Cassagnes, C., Trestioreanu, L., Joly, C., & State,

R. (2020, April). The rise of eBPF for non-intrusive

performance monitoring. In NOMS 2020-2020

IEEE/IFIP Network Operations and Management

Symposium (pp. 1-7). IEEE.

[4]Miano, S., Chen, X., Basat, R. B., & Antichi, G.

(2023). Fast In-kernel Traffic Sketching in eBPF. ACM

SIGCOMM Computer Communication Review, 53(1),

3-13.

[5]https://blogs.oracle.com/linux/post/from-kernelto-user-space-tracing

[6]https://ebpf.io/what-is-ebpf/

四、总结与展望

《交易技术前沿》总第56期

64

陈洪炎、吴鑫、屠栽镝、胡跟旺、徐子祺｜上交所技术有限责任公司

E-mail: hongyanchen@sse.com.cn

持续测试助力业务价值高质量交付

随着国家“十四五”规划的发布和2035年远景目标的明确，金融科技行业迎来了前所未有的机遇和挑战。

中国信通院牵头制定的《研发运营一体化（DevOps）能力成熟度模型》覆盖了需求、开发、测试、运营等

软件全生命周期，为证券期货业机构提供了研运能力提质增效的指导方向，持续测试是DevOps体系的重要

一环，秉承了DevOps的思想和理念，以实现价值流顺畅、快速流转为目的，形成了适用于测试领域的方法

论和最佳实践。本文从持续测试的产生、价值、体系和实践等维度展开探索和研究，以期为保障业务价值

高质量交付提供参考。

持续测试；价值流动；度量反馈；持续改进；DevOps

近些年，证券期货行业运用金融科技赋能业务发

展，实现业务创收和发展降本增效已经成为行业关注的

焦点。如何在满足研发运营过程安全、合规的前提下，

通过提升研发交付效率，快速交付有价值的产品和服务

变得越来越重要。目前证券期货业在数智化转型中面临

以下痛点：1）技术债较重，个性化需求难以高效满足；

2）迫于业务压力上线，系统建设缺乏整体规划；3）系

统架构复杂，维护成本高；4）系统建设周期长，失败成

本高。本文旨在帮助行业机构在研发IT软件及相关服务过

程中，将需求、设计、开发、测试和运营等关键环节统

筹考虑，落地覆盖端到端软件研发生命周期全流程持续

测试，助力实现业务价值高质量交付。

2.1 持续测试的产生

软件研发相关的测试活动主要经历了瀑布型测试、

敏捷型测试和持续测试。随着DevOps思想不断发展和传

播，持续交付提倡价值流动，测试与持续交付流水线相

互融合，测试不断向需求侧、开发侧和运维侧移动，形

成覆盖软件研发全生命周期的持续测试闭环。

2.2 持续测试的价值

1.持续反馈

持续反馈是构成持续测试闭环的重要阶段，是对于现

有阶段的测试结果、测试流程、测试质量和效率的反

馈，有助于更早地找到问题而减少修复问题的成本。

2.持续改进

持续改进是通过对产品、系统、流程等进行持续不

断地测试以发现潜在的问题和改进点。持续测试避免了

问题在后期积累，促进软件研发过程的持续改进。

3.提升研发效能

持续测试帮助组织通过提高测试效率，增强交付能

力，保障交付质量，支撑组织实现业务价值的持续交

付，提升整体研发效能。

4.助力数智化转型

持续测试能帮助研发团队的测试转型，软件全生命

周期活动均需要开展测试活动。持续测试强调自动化测

试的能力，能帮助组织将传统手工测试转型为自动化测

试，持续测试支持了预交付流水线的协同，使得全流水

线中不同测试活动之间的衔接变得更加紧密。

5.全面质量管理

基于全面质量管理的思想，建立稳定、高可用性的

系统架构，通过持续测试加强质量管理和业务连续性管

理，保障业务持续稳定运行。

持续测试是在整个软件研发生命周期中持续执行测

试以提供有关被测系统质量高效反馈的过程，是软件交

付流水线中的一种可以随时开展且具有连续性的测试活

动。持续测试体系包含持续测试组织与文化、持续测试

能力和持续测试成熟度模型。

3.1 持续测试组织与文化

持续测试鼓励测试活动尽早介入到软件研发过程中，

及早发现质量与业务风险，测试尽早介入可以提前发现

并纠正在需求设计、产品规划和架构设计中的问题，持

续测试能有效降低项目在快速增长期产生的风险，减少

技术债务的堆积，持续测试倡导流动文化、反馈文化和

合作型组织。

摘 要：

关键词：

一、引言

二、持续测试的产生与价值

三、持续测试体系

ITRDC证券信息技术研究发展中心（上海）

65 传统研发团队按照职能和专业划分团队职责。业务

人员、产品经理、设计人员、开发，测试，运维，运营

等均隶属于不同部门。部门之间“沟通壁垒”问题普遍

存在，项目研发过程中存在较多无效等待时间。

持续测试提倡合作型组织，将组织划分为管理部

落，产品部落和研发部落（图1）。管理部落聚焦战略目

标，业务定位，推进并统筹整体事项。产品部落服务于

业务客户，作为业务和研发人员的枢纽促进高效协作，

实现业务价值高质量交付。研发部落负责实现产品研发

并完成产品的交付。

3.2 持续测试工作流程

持续测试倡导测试人员在软件研发过程中持续参与

需求分析、需求评审、设计开发评审、代码评审、测试

设计、测试用例/脚本开发、冒烟测试、集成测试、验收

测试、线上测试等活动，持续测试使得产品经理、开

发、测试和运维之间有效协作，极大减少沟通成本和无效

等待时间。持续测试在实际过程中的工作流程如图2所示。

3.3 持续测试成熟度模型

持续测试能力成熟度模型（图3）分为过程域、改进

域、平台能力域和度量域四个维度。

续测试能力成熟度分为1-5级（表1），主要分级指标

包括规范制度、测试左移、测试右移、自动化测试、效

能度量、先进技术、智能化测试、过程反馈与改进、精准测

试、缺陷预防、辅助决策、科研能力等。持续测试能力成熟

度模型设计了递进式的要求，结合最佳实践与先进技术发展

趋势，能够用于评估组织各阶段的持续测试能力。

图1：持续测试合作型组织的工作模式

图2：持续测试工作流程

图3：持续测试能力成熟度模型

《交易技术前沿》总第56期

66

表1 ：持续测试能力成熟度分级表

持续测试实践依据持续测试能力成熟度模型分为过程域

实践、改进域实践、平台能力域实践和度量域实践。过程实

践体现持续测试在软件生命周期全流程参与的体现。改进域

实践是持续测试实践的优秀结果。平台能力域实践是持续测

试的基础能力建设。度量域实践用于检验持续测试实践的结果。

4.1 过程实践域

4.1.1 需求阶段测试

精益需求分析通过分析需求与功能点估算对用户故事进

行细粒度的拆分，实现业务语言与技术语言之间的转化，用

领域模型等方法进行业务建模，帮助完成良好的技术实现。

实例化需求是需求分析拆解的一种方法，用具体的例子或可

视化的效果将用户故事描述得更明确。测试通过实例化后的

故事点进行测试场景设计和测试用例开发，并估算测试工作

量，形成测试迭代计划。

持续测试倡导以用户故事方式管理需求（图4），便于

后续每个需求的实现和验收。一般将精益需求分析和实例化

需求后形成的用户故事按照目标进行分层管理，形成树形结

构的故事树，故事树将离散的需求组合起来，使需求汇聚成

一个完整的架构，团队能获得项目的全局观和产品研究的方

向感，并能清晰地看到产品发展路线图。

4.1.2设计阶段测试

设计阶段的持续测试一般与实际工作场景相互结合，主

要用于对齐合作型组织中各角色认知的一切活动，包括对齐开

发方案、测试用例、测试计划等相关活动。通过各角色对齐认

知后的产出判定该环节的成熟度，一般衡量设计阶段持续测试

能力的成熟度的指标有：测试用例对需求、代码的覆盖情况、

开发方案与需求的吻合度、单测断言密度、用例有效性等。

4.1.3开发阶段测试

开发阶段的持续测试通过频繁且精准的单元测试和冒烟

测试，有效提高软件编码的质量，逐渐实现持续测试驱动开

发。开发阶段的持续测试活动包括代码扫描、代码质量管

理、代码分支管理、版本管理、架构设计评审、代码评审，

配置管理等，这些持续测试活动能帮助尽早发现研发早期阶

段中引入的故障。

4.1.4 集成阶段测试

集成阶段测试是在软件作为制品交付并部署到测试环境

后，进行针对性测试、集成测试、系统测试、非功能测试、

回归测试等一系列测试活动（图5）。

图4：需求阶段持续测试活动

图5 ：集成阶段测试阶段的测试活动

四、持续测试实践

ITRDC证券信息技术研究发展中心（上海）

67 1.自动化测试

持续测试提倡应自动化均自动化，包括自动生成用例以

及自动提交缺陷，下钻分析等，自动化测试能节省测试执行

的时间成本和人力成本，快速有效地反馈产品质量问题，自

动化测试能记录故障发生的日志和截图，减少“人为”因素

带来的测试漏测和结果误判，节省开发和测试人员沟通成

本，提高测试精准度。自动化框架的选择在一定程度上决定

了自动化测试后续的维护成本和在项目中产生的价值。自动

化框架的选择需基于团队的特点和能力，提倡根据自身业务

特点定制开发自动化测试平台，解决通用自动化框架无法满

足的痛点和不足。

2.精准测试

精准测试建立在业务功能点（测试用例）和业务代码相

互关联的基础之上，获取功能点的覆盖率，进行测试精准覆

盖和缺陷精准定位。精准测试通过实时感知代码变动，实现

代码变动分析，准确定位代码变动范围和变动影响范围，提

供深入准确的测试决策分析依据，从而准确确定测试范围。

精准测试通过对代码的量化分析，得到测试用例执行后的代

码变更的覆盖率，并以此为依据促进补充和完善测试用例。

精准测试依据代码的变更范围，并追踪服务和方法调用链路

关系，获得明确的测试范围。

3.性能测试

证券期货业的信息系统因业务的特殊属性，具有数据规模

大、耦合性强、复杂性高、安全要求高等特点，对于实时性

和安全性的要求较高，性能测试在证券期货业中有着举足轻

重的作用。一般常见性能测试类型如：压力测试、负载测

试、容量测试、基准测试等。全链路压测是链路化压测的一

种最佳工程实践，一般分为调用链路压测和业务链路压测两

种形式。调用链路压测是从请求出发到结果返回途经的各层

应用、服务、代理所产生的路径，调用链路压测主要验证单

一业务场景的应用、服务、缓存、数据库等各层的性能表

现。业务链路压测是多个有业务关联场景组合所产生的调用

链路的组合，用于评估组合业务场景下系统的性能表现。流

量回放技术丰富了全链路压测的手段，在此基础上可根据

业务场景对录制的数据进行修正和验证。流量回放技术适合

于无状态的系统。

4.其他非功能测试

在实践中，除性能测试外，应定期开展其他非功能测

试，如：安全测试、架构测试、兼容性测试、可维护性测

试、高可用测试等。其他非功能测试应具备测试规范，约定

非功能实施的时机、整体流程和各环节细节。通过手工、自

动化工具结合的方式完成测试。推荐的非功能测试实践还包

括：精准测试、混沌测试、模糊测试等。

4.1.5 验收阶段测试

验收测试一般由用户或者独立测试人员根据测试计划

和最终产品进行接收，确认产品是否满足合同或用户需求的

测试。验收测试是正式投入实际生产使用前的最后一次全面质

量检验活动，验收测试通过与否将最终决定软件是否合格。业

务全链条测试是验收测试中的一种具体实践，当多个系统将共

同发生同一新业务上线或重大业务变更时需要在类生产环境中

进行联测，一般需要多个机构或组织之间协调配合，共同约定

业务场景，数据流转和测试响应服务等。验收测试一般分为设

定验收标准、设计验收场景/用例、执行验收测试用例和验收

结果这几部分、验收测试工作流程如图6所示。

4.1.6运营阶段测试

运营阶段测试是在正式发布上线后对产品进行测试相关

的活动，是测试运营一体化的演进。持续测试打破测试和运

营的边界，促进测试右移到生产运营过程中，运营阶段持续

测试主要是在产品上线后持续对产品线上运行状态、稳定

性、高可用、安全性和系统快速恢复进行持续验证，主要包

含的活动是线上测试，持续监控和低风险发布。

4.2 改进域实践

改进域实践是构成持续测试闭环的重要阶段，对软件全

生命周期的各个阶段进行测试的结果、流程、效率和质量进

行反馈，帮助快速定位问题，预防缺陷故障，提升软件研发

效能。改进域实践包含准入准出、测试报告、缺陷管理、质

量分析和生产事件复盘。

4.3 平台能力域实践

平台能力域是持续测试全流程的支持能力，包括流程制

度规范、测试人员管理、测试环境管理、持续测试平台

建设、测试资产和数据管理等方面。持续测试平台建设能

有效提高持续测试效率，支持在各阶段中持续开展自动化测

试、生成测试报告、实现质量门禁和持续交付流水线，产生

图6：验收测试工作流程

《交易技术前沿》总第56期

68

的测试过程数据可作为效能度量的基础分析数据。持续测试

平台按版本迭代维护测试计划、测试用例、缺陷、测试结

果、测试报告等实体，并建立各实体间的关联关系，形成可

视化视图和各维度统计报表，持续测试平台产生和维护的数

据可作为度量的基础数据，持续测试平台有助于提高测试效

率和产品质量。

4.4 度量域实践

度量域实践包含持续测试效能度量指标，度量可视化和

度量反馈，对持续测试所产生的效果和影响进行度量评估有

利于持续改进。

4.4.1 持续测试效能度量指标

有效的度量指标应基于业务的价值收益来制定，度量指

标指令包括指标定义，指标的权重分配，度量数据采集分析

与维护，制定度量指标时需考虑度量结果的指导意义。度量

有时候是把“双刃剑”，用得好可以促进组织持续改进，用

得不好会产生内耗内卷，反而阻碍发展和创新，减弱组织的

生命力和活力。度量结果的计算需要考虑度量指标数据的时

效性以及数据覆盖的范围。

4.4.2 度量可视化

度量可视化是借助度量平台展示度量指标，度量平台是

将持续测试过程中的离散数据进行有机地组合计算，形成各

种客观指标数据，再配合多重展现方式，形成直观数据看板

和自驱性的数据分析的能力。设计度量平台可分为数据采

集、计算、分析、展现四个部分。

4.4.3 度量反馈

基于度量结果提供快速准确直观的趋势和质量数据，指

导研发团队优化改进，推动组织数字化智能化转型与决策的

进程，实现数据驱动持续改进。通过度量来反馈问题，从中

产生洞察，落实改进行动，通过度量指标体系建立度量分析

模型，系统性地分析问题，有效地帮助持续改进闭环。

五、持续测试结果检验

实践结果是持续测试理论的试金石，经过反复实践探

索，有效证明持续测试实践有效助力证券期货业信息系统的

大力发展，及早发现缺陷，极大减少了缺陷修复的成本，可

观测性实践也增强了缺陷预防的能力。持续测试有效降低研

发投入成本，图7对比了引入持续测试的前后缺陷修复成本

和故障暴露时机，持续测试在软件研发中的实践提前了缺陷

暴露的时间，加快了业务价值的流转速率，大幅降低了缺陷

修复的成本，有效提升信息系统健康度。

持续测试是持续交付质量和效率的核心保障，持续测试

倡导不断提升自动化测试比例，并强调覆盖软件全生命周期

测试，实现随时执行测试并支持随时反馈，各类开箱即用测

试工具组件也让持续测试成为可能。本文重点研究如何在满

足安全和合规前提下，通过持续测试实践来提升研发交付效

率，旨在解决证券、基金、期货行业相关金融机构进行数智

化转型过程中的金融科技痛点问题，以满足现有基础和未来

目标的发展需求，实现持续测试的最佳实践共享，助力提升

运营效能。

参考文献：

[1]茹炳晟，张乐 《软件研发效能权威指南》 ［M］. 北京:

电子工业出版社，2022.

[2](JRT0175-2019)证券期货业软件测试规范[S].

[3](YDT 3763-2021)研发运营一体化（DevOps）能力成熟

度模型 系列标准[S].

六、总结与展望

图7：验收测试工作流程

ITRDC证券信息技术研究发展中心（上海）

69 监管科技全球追踪

1月9日，美国金融业监管局（FINRA）发布2024年

度监管报告。报告较以往新增两个主题：一是加密资产

开发，报告对开展加密资产相关业务的公司提供了指

导。二是信息公开，报告调研结果包括网络安全、反洗

钱、反欺诈和制裁、最佳利益规则（Reg BI）和共同申报

准则（CRS）表格以及合并审计跟踪等。

1月16日，欧洲银行管理局（EBA）宣布将其《反洗

钱和反恐怖融资风险因素指南》（ML/TF Risk Factors

Guidelines）扩展至加密资产服务提供商（CASPs）。

新指南强调CASPs需要考虑的ML/TF风险因素和缓解措

施。

1月24日，清华大学等联合发布《2024年金融业生

成式人工智能应用报告》，提出生成式AI将赋能银行数字

化转型，重塑金融业格局，预计有望带来3万亿增量商业

价值，并可能改变交易、投资管理和风险评估方式。

1月30日，俄罗斯央行行长纳比乌琳娜表示，2024

年俄方将推动金砖国家互相承认评级和建立反洗钱通用

平台。她强调评级互认对贸易投资的重要性，并指出超

国家评级机构面临复杂问题。同时，俄方愿分享反洗钱

经验，简化金砖国家企业间合作。

2月5日，北京首都国际机场和大兴国际机场境外来

宾支付服务示范区正式启用。中国人民银行副行长张青

松表示，按照“大额刷卡、小额扫码、现金兜底”的总

体思路，将在3到6个月内实质性进一步改善境外来华支

付服务。

2月20日，上海市委网络安全和信息化委员会举行会

议指出，要持续强化信息化的支撑和引领，加快培育发

展新质生产力，让信息化数字化更好赋能现代化。抢抓

人工智能发展机遇，推进关键核心技术突破，加快创新

企业孵化培育。

2月27日，上海市委书记陈吉宁、市长龚正与中国人

民银行行长潘功胜座谈。潘功胜表示，将支持上海高质

量发展和国际金融中心建设，深化跨境贸易和投融资便

利化，加强金融市场基础设施，优化人民币跨境支付系

统，深化数字人民币试点，共同做好“五篇大文章”。

3月1日，中国银行业协会发布《银行业数据资产估

值指南》。该指南构建了全面而实用的数据资产估值框

架，涵盖数据资产的识别、评估、管理到价值提升等关

键环节，为全面构建我国金融领域数据资产估值体系提

供了有益借鉴，有助于完善数据要素资源体系，推动数

据要素市场科学有序发展和数据资产估值走向规范化、

市场化，助力行业数字化转型。

3月7日，香港金管局宣布展开全新的批发层面央行数

字货币（wCBDC）项目“Ensemble”，以支持香港代

币化市场发展。香港金管局将成立由本地及跨国银行、

数字资产行业主要参与者、科技公司及CBDC专家小组组

成的wCBDC架构工作小组，以推动制定业内标准及与时

俱进的策略。

3月8日，迪拜国际金融中心（DIFC）宣布出台全球

首部数字资产法，并对原有证券法和相关修正案进行更

新。这些立法旨在确保DIFC法律跟上技术发展带来的国

际贸易和金融市场的快速发展，并为数字资产的投资者

和用户提供法律确定性。

3月13日，欧洲议会正式批准《人工智能法案》，对

AI技术实施全面监管。其将AI分为不同风险等级并规定相

应监管措施，违规者将面临至高7%营收的处罚。该法案

旨在跟上科技发展，塑造跨国公司数据管理和AI使用方

式，适用于27个欧盟国家的企业及在欧盟使用的他国AI

系统。

3月27日，韩亚金融集团宣布了一套道德准则，旨在

利用快速发展的AI技术，提供更安全、以客户为导向的金

融服务。这套AI道德准则优先考虑五组价值观，包括包容

性和公平性、安全性和责任性、透明度、数据管理和隐

私保护。

4月17日，人力资源社会保障部等九部门发布《加快

数字人才培育支撑数字经济发展行动方案（2024－2026

年）》，紧贴数字产业化和产业数字化发展需要，用3年

左右时间，扎实开展数字人才育、引、留、用等专项行

动，增加数字人才有效供给，形成数字人才集聚效应。

4月26日，香港金融管理局推出FiNETech平台，汇

集约100家银行、证券公司、保险公司以及科技企业，共

同发掘在财富科技、保险科技、绿色科技、人工智能和

分布式分类帐技术的进阶合作安排。

4月29日，国家发展改革委、国家数据局印发《数字

经济2024年工作要点》。该工作要点提出适度超前布局

数字基础设施，加快构建数据基础制度，深入推进产业

数字化转型等9方面落实举措。

5月15日，中国证监会发布2023年执法情况综述。

其中在2024年执法工作重点提出：强化线索发现。加大

科技监管应用，不断提升线索发现的敏感度和精准度，

强化跨部门跨领域跨市场监管协作，加强现场监管与非

现场监管联动、信息披露与交易监管联动、现场检查与

稽查调查联动，坚决消除监管空白和盲区。

5月20日，澳大利亚政府宣布审议通过《数字身份法

案（2024）》和《数字身份（过渡和相应条款）法案

（2024）》。该立法将建立一个更广范围的数字身份系

统，并允许金融组织和相关服务提供商申请和加入政府

数字身份平台，为用户提供一个更强大、更安全的在线

生态系统。

《交易技术前沿》总第56期

70

《交易技术前沿》征稿启事

《交易技术前沿》由上海证券交易所主管、主办，主要面向全国证券、期货等相关金融行业的信

息技术管理、开发、运维以及科研人员。近期重点征稿主题如下:

一、云计算

（一）云计算架构

主要包含但不限于：云架构剖析探索，云平台建设经验分享，云计算性能优化研究。

（二）云计算应用

主要包含但不限于：云行业格局与市场发展趋势分析，国内外云应用热点探析，金融行业云应用

场景与实践案例。

（三）云计算安全

主要包含但不限于：云系统下的用户隐私、数据安全探索，云安全防护规划、云安全实践，云标

准的建设、思考与研究。

二、人工智能及大模型技术

（一）应用技术研究

主要包含但不限于：大语言模型/AIGC的数据处理和治理、可解释的人工智能及大语言模型、用

于大语言模型/AIGC的神经网络架构、训练和推理算法、多模态AI等。

（二）应用场景研究

主要包含但不限于：基于人工智能或大语言模型的智能客服、语音图像文本等数据挖掘、柜员业

务辅助等。

主要包含但不限于：金融预测、反欺诈、授信、辅助决策、金融产品定价、智能投资顾问等。

主要包含但不限于：金融知识库、风险控制等。

主要包含但不限于：机房巡检机器人、金融网点服务机器人等。

三、数据中心

（一）数据中心的迁移

主要包含但不限于：展示数据中心的接入模式和网络规划方案；评估数据中心技术合规性认证的

必要性；分析数据中心迁移过程中的影响和业务连续性；探讨数据中心迁移的实施策略和步骤。

（二）数据中心的运营

主要包含但不限于：注重服务，实行垂直拓展模式；注重客户流量，实行水平整合模式；探寻数

据中心运营过程中降低成本和提高服务质量的途径。

四、分布式账本技术（DLT）

（一）主流分布式账本技术的对比

主要包含但不限于：技术架构、数据架构、应用架构和业务架构等。

（二）技术实现方式

主要包含但不限于：云计算+分布式账本技术、大数据+分布式账本技术、人工智能+分布式账本

ITRDC证券信息技术研究发展中心（上海）

71 技术、物联网+分布式账本技术等。

（三）应用场景和案例

主要包含但不限于：结算区块链、信用证区块链、票据区块链等。

（四）安全要求和性能提升

主要探索国密码算法在分布式账本中的应用，以及定制化的硬件对分布式账本技术性能提升的作

用等。

五、信息安全与IT治理

（一）网络安全

主要包括但不限于：网络边界安全的防护、APT攻击的检测防护、云安全生态的构建、云平台的

架构及网络安全管理等。

（二）移动安全

主要包括但不限于：移动安全管理、移动互联网接入的安全风险、防护措施等。

（三）数据安全

主要包括但不限于：数据的分类分级建议、敏感数据的管控、数据共享的风险把控、数据访问授

权的思考等。

（四）IT治理与风险管理

主要包括但不限于：安全技术联动机制、自主的风险管理体系、贯穿开发全生命周期的安全管

控、安全审计的流程优化等。

六、交易与结算相关

（一）交易和结算机制

主要包含但不限于：交易公平机制、交易撮合机制、量化交易、高频交易、高效结算、国外典型

交易机制等。

（二）交易和结算系统

主要包含但不限于：撮合交易算法、内存撮合、双活系统、内存状态机、系统架构、基于新技术

的结算系统等。

投稿说明：

1、本刊采用电子投稿方式，投稿采用Word文件格式（格式详见附件），请通过投稿信箱

ftt.editor@sse.com.cn进行投稿，收到稿件后我们将邮箱回复确认函。

2、稿件字数以4000-6000字左右为宜，务求论点明确、数据可靠、图表标注清晰。

3、不设固定截稿日期，常年对外收稿。收齐一定数量的稿件后将尽快组织专家评审。

4、投稿联系方式021-68602496, 021-68607129欢迎金融行业的监管人员、科研人员及技术工作

者投稿。稿件一经录用发表，将酌致稿酬。

《交易技术前沿》总第56期

72

附件：投稿格式（可通过电子邮件索要电子模版）

标题（黑体 二号 加粗）

作者信息（姓名、工作单位、邮箱）（仿宋GB2312 小四）

摘要：（仿宋GB2312 小三 加粗）

关键字：（仿宋GB2312 小三 加粗）

一、概述（仿宋GB2312 小三 加粗）

二、一级标题（仿宋GB2312 小三 加粗）

（一）二级标题（仿宋GB2312 四号 加粗）

1、三级标题（仿宋GB2312 小四 加粗）

（1）四级标题 （仿宋GB2312 小四）

正文内容（仿宋GB2312 小四）

图：（标注图X. 仿宋GB2312 小四）

正文内容（仿宋GB2312 小四）

表：（标注表X. 仿宋GB2312 小四）

正文内容（仿宋GB2312 小四）

三、结论/总结（仿宋GB2312 小三 加粗）

四、参考文献（仿宋GB2312 小四）

电子平台

欢迎访问我们的电子平台 http://www.sse.com.cn/services/tradingtech/transaction/。

我们的电子平台不仅同步更新当期的文章，同时还提供往期所有历史发表文章的浏览与查阅，欢

迎关注！

ITRDC证券信息技术研究发展中心（上海）

联系电话： 021-68602496

021-68607129

投稿邮箱： ftt.editor@sse.com.cn

内部资料 免费交流

本资料仅为内部交流使用，本期印200册，编印单位为上海证券交易所，面向证券期货行业发送，印刷时间为2024年6月，印刷单位为上海华顿书刊印刷有限公司。

部分图片或文字来源于互联网等公开渠道，其版权归属原作者所有。如有版权相关事宜，请发送邮件至 ftt.editor@sse.com.cn

ITRDC证券信息技术研究发展中心 （上海 ）

中国上海市杨高南路388号

邮编: 200127

公众咨询服务热线： 4008888400

网址： http://www.sse.com.cn