证券公司信息系统监控管理实战分享

Posted 2021-05-18 证券信息技术研发中心

证券公司信息系统监控管理实战分享

--基于开源软件Zabbix+Grafana

肖钢、张建军、张欣宇/中信建投证券股份有限公司

张杰/东兴证券股份有限公司

安浩铭/华融基金管理有限公司

赵茂军/世纪证券有限责任公司

王海航/深圳市金证科技股份有限公司

1 引言

随着证券金融市场的高速发展，各证券经营机构对信息技术的投入显著增加，业务开展严重依赖各类信息系统。因此，各业务信息系统的安全稳定运行就显得尤为重要，也是证券经营机构运行维护团队的首要职责。如何提前发现问题、快速定位并解决问题，减少运行风险，降低运行维护成本，保证业务的连续性是每个运行团队必须要面对的挑战。

2 监控管理工作的重要性

运维行业有句话：“无监控、不运维”，可见监控系统在“运维人”心中的地位。监控系统是运维的基础，也是持续改善运维工作的重要数据来源。构建一套完整的监控体系，能够最大程度的降低信息系统异常给业务造成的影响，提升运维效率和运维水平。笔者认为监控管理的重要性体现在以下三方面：

其次，一套合适的监控管理工具和监控管理流程，能够有效保障业务的SLA（服务级别协议），让运维团队全面、深入掌握信息系统的运行状态，提早发现系统异常情况，定位故障原因，缩短业务恢复时长。《证券期货业信息安全事件报告与调查处理办法》中对“较大事件”进行了定义“证券公司、期货公司集中交易系统或者网上交易系统全部中断、部分中断，影响交易时间累计在5分钟以上的；第三方存管系统、融资融券系统全部或者部分停止运行，影响业务时间累计30分钟以上”。故障的恢复时间直接决定了信息安全事件的级别，进而影响证券公司的分类评价评分情况。

最后，监控管理与事态管理、事件管理、可用性管理、容量管理、变更管理等多个IT服务管理流程相关，上述IT服务管理过程中很多基础数据都需要通过监控系统提供，是IT服务管理持续改善的基础。

3 证券公司系统监控的痛点

3.1 监控系统繁多

很多公司为了监控信息系统不同的组件，部署了多套零散的监控系统，比如网络用一套监控、操作系统和基础设施用一套监控、数据库用一套监控、应用系统又用一套，各监控系统监控的颗粒度和重点不同，监控管理责任人也不相同，这样做不但导致告警分散，还会因为操作界面多，提高了管理难度，需要花费很多的人力、物力去维护，增加了运维成本，运维效率也比较低下。

3.2.监控项不全

虽然很多证券公司都构建了一套或多套监控系统，但在实际使用过程中仍然存在一些问题。

1、监控存在盲区：部分公司监控系统未实现对监管要求的监控项进行全覆盖，存在监控盲区。比如数据库表空间、连接数、日志、存储设备的电池状态，磁盘交换延迟等；

2、缺少关键业务指标监控：部分公司缺少关键业务指标的监控，很多情况下服务器网络联通性，端口，进程都正常，但业务已经中断，如果不从业务角度进行监控很难及时发现系统发生异常。

3、缺少基于业务流向的监控展示：目前有很多证券公司已经实现上述监控指标的全覆盖，对关键配置文件及关键业务指标也进行了监控，但比较少有基于业务流向的监控展示，虽然能够第一时间发现异常情况，但解决起来仍然很慢。现在很多开源监控工具已经可以实现从用户下单到最后成交的一整条业务数据流向的监控，监控系统可以快速的定位影响业务连续性的设备或组件，极大的缩短系统故障恢复时长。

3.3监控管理流程不完整

缺少对系统监控的全生命周期管理，从系统的上线到下线缺少必要的环节对监控设置进行管理。同时，对各个系统的监控项的增、删、改没有流程控制，运维人员可以随意增加、减少监控项，或变更监控阈值，导致监控系统中存在很多废弃监控项或为同一类型的监控指标设置不同的监控阈值。

3.4监控评估不到位

《证券期货业信息系统运维管理规范》监管中要求“应至少每季度全面评估监控日志和操作记录，分析异常情况，形成评估报告”。部分公司对于监控的评估形式大于实质，起不到真正的作用。笔者认为针对监控系统的评估可以通过三个方面进行，一是对系统的容量评估；二是对系统的可用性评估；三是对已有的监控项和监控阈值进行评估。具体的评估内容笔者在第5章进行详细论述。

4 监控管理的指导思想

4.1 构建集中监控系统

通过实践摸索，笔者认为做好证券信息系统的运维管理，首先要构建一套集中监控体系，实现对信息系统的所有部件重要运行指标的集中统一监控、预警、处置和跟踪。

所有部件，指能够覆盖到系统运行管理的所有组成，包括机房物理设备（空调、UPS）、网络设备、安全设备、服务器设备、存储设备等,同时除生产机房，同城机房、灾备机房都应涵盖在内。

重要运行指标，指能够监控系统运行过程中可能会导致服务可用性下降或业务中断以及监管发布的规章制度中必须监控的相关指标；

统一，指能够对上述监控对象和监控指标进行集中告警分发与展示。

4.2 梳理对象层次架构

笔者认为监控对象从上至下可分为四个层级，即：业务数据层、应用服务层、系统平台层和基础设施通讯层：

1、业务数据层

主要针对各业务系统的业务数据进行收集。因为业务间存较大差异，个性化的需求和业务逻辑也不尽相同，其监控方式一般是由Agent通过数据库语句或Python脚本在业务系统的数据库中进行数据读取，并将读取结果发送至监控平台，实现业务指标的监控。

2、应用服务层

主要针对操作系统上的应用系统进行监控。由于是对应用系统进行监控，需要对应用系统的配置文件信息进行抓取，所以此部分的监控思路是以在终端部署Agent为主，由Agent通过执行特定命令，搜集目标软件的信息和状态，并搭配监控平台或其他监控站点对目标业务所在服务器指定服务端口、进程状态判定服务的可用性。

3、系统平台层

主要针对操作系统层面的指标进行监控，比如系统版本、CPU内存利用率、磁盘使用空间等。在监控方式上，Windows、Linux系统平台上支持通过SNMP协议传输一些基础指标信息；此外，也可通过监控平台下发查询指令获取监控指标信息或者在终端设备上部署Agent（监控客户端）获取监控指标信息并上传至监控平台。

4、基础设施通讯层

主要针对信息系统基础设施的监控，包括物理服务器、网络设备、空调、UPS等基础设施，对其状态进行监控，判断其可用性。此层设备特点是支持SNMP协议，所以监控平台可直接通过SNMP协议主动抓取或被动接收数据来实现监控。

如下是监控对象的层次架构图如图1所示：

图1

4.3 制定标准化监控模板

随着国内证券金融行业的不断发展，新业务、新技术推陈出新，为每一个层次的监控指标选取并设计一套基于最佳实践的监控模板会极大的提高运维效率。可以针对Windows、Linux、mysql、SQLServer、Oracle结合企业实际情况创建标准化模板，当遇到新业务上线时，可以批量添加监控对象和监控指标，提升工作效率。

4.4 建立监控管理闭环

笔者认为好的监控管理体系不光要有功能强大的监控平台工具，还应该对监控指标的设定、告警策略、告警事件处置、以及评估和改进等过程建立一整套的管理机制，形成可执行的落地文件，能够指导运行团队有效做好监控管理的方方面面。

4.5 建立评估与持续改进机制

监控系统是系统运维管理持续改进过程中的重要一环，通过对系统容量、可用性等关键指标的评估，能够使运维团队发现当前运维管理工作中的不足，通过量化的数据更有针对性的改进，形成PDCA（Plan、Do、Check、Ack）的闭环管理，持续提升运维管理水平。

5 基于开源技术的监控系统构建

5.1 监控工具及逻辑架构

为达到上述集中监控与展示的目标，笔者经过对比多款开源监控工具，推荐采用Zabbix+Grafana作为集中监控及展示平台并集成其它专用监控软件的方式实现。其优势是开源、高效、易上手、功能组件丰富、可扩展性强。

Zabbix是分布式监控系统，采用多层设计将系统分为数据采集层、数据处理层、数据展示层。支持多种采集方式和采集客户端，有专用的Agent代理且消耗低，对监控主机基本不构成安全风险，支持SNMP、IPMI、JMX、Telnet、SSH等多种协议。Zabbix将采集到的数据存放到数据库，然后对其进行分析整理，实现数据的采集、存储、分析、展示、预警，当达到条件时触发告警。

对于Zabbix目前无法完成监控的部分，如业务监控，可通过行业专业监控软件的采集业务运行状态，将监控结果集成进Zabbix，实现业务监控的集中处置。

Grafana是一个跨平台的开源分析和可视化工具，支持的数据源类型广泛，可视化插件也非常丰富，配合Zabbix可以将采集的数据进行集中可视化展示。

Zabbix+Grafana监控体系如图2所示：

图2

5.2 监控指标的选择

如何选择监控指标做到有的放矢是评价监控系统是否有效最重要的标准。在监控指标的选择上笔者认为可以借鉴《Google SRE》一书的方法，将监控指标分为四大类，分别是：错误类指标、延迟类指标、流量类指标及饱和度类指标。

每种类型中又可以针对业务数据层、应用服务层、系统平台层、基础设施层进行细化。需要注意的是很多情况下，基础设施层、系统平台层和应用服务层的监控指标并不能完全代表系统真实的运行状态(如CPU、内存、磁盘、端口、进程等)，必须辅以业务数据层的指标（也叫业务指标，如业务量：从特定时间开始计算的累计业务笔数、吞吐量：单位时间内发生的业务笔数、响应时间：一笔业务的处理时间，异常业务的笔数：业务处理异常或业务处理失败的事件等）才能最大程度的实现对系统运行状态的监测。

1、错误类指标

错误类指标就是指在信息系统运行过程中的异常错误，包括错误请求、错误率等。该类监控指标的选择一般从硬件报错、状态异常、日志报错、业务请求报错、业务处理报错等影响业务正常处理等方面考虑。

业务数据层错误指标："集中交易三方存管签到状态值异常"，"集中交易系统投保报送数据异常,异常客户代码为XXXX"等；

应用服务层错误指标：“数据库1521端口访问异常”，“kcbp.exe（业务中间件）进程不存在”，“kcxp（通讯中间件）集群不可用节点大于1”、“生产、灾备应用软件版本不一致”等；

操作系统层错误指标：系统日志错误、映射磁盘不存在等；

基础设施层错误指标：包括设备宕机、电池状态异常、空调或UPS日志报错等。

2、延迟类指标

延迟类指标是指，信息系统处理某种请求的响应时间。这类指标的选择一般围绕是否影响终端用户的体验为准则。需要注意的是，在选择此类指标的时候应该区分正常请求的延迟时间和可能影响用户体验请求的延迟时间。

比如业务数据层中应包括：“集中交易单笔成交时间大于1s”,“ElasticSearch的索引、搜索延迟大于5s和慢查询大于5次”，“某网站页面响应延迟时间大于3s”等；

应用服务层中包括：“Oracle主备数据同步超时5s”，“Oracle数据库的慢查询时长大于5s”等；

操作系统层中包括：“监控系统Agent与Zabbix服务器时间差大于10s”等；

基础设施层中包括：“局域网网络ping延时超过150ms”等。

这些指标会不同程度的影响终端用户的流畅体验，因此，从用户延时体验的角度逐层分析定位指标，可以更合理有效的形成技术对业务的驱动作用。

3、流量类指标

流量类指标是指，对一个系统所承载的服务在单位时间内所形成负载的度量。对于一个WEB系统来说，它所承载的是服务请求，那么它的流量指标就是对每秒处理请求数量的度量；一个网络系统，它所承载的是电信号，那么它的流量指标就是对每秒处理电信号数量的度量；对交易系统而言，就是委托或回报的请求数量等。流量指标的大幅波动常常代表系统的内部或外部环境发生变化，需要运维团队排查诱因。

比如业务数据层的“业务笔数”应包括：集中交易系统单位时间的成交回报数和累计成交回报笔数（就算所有监控指标都正常，在交易时段内如果一定时间没有成交回报，有极大概率集中交易系统出现了异常）。“客户量”包括当日手机APP活跃客户数、开户数等、三方存管的证转银、银转证笔数等；

应用服务层中包括：集中交易Run库当前建立连接数、表打开数等；

操作系统层中包括：当前系统进程数、用户登录数等；

基础设施层中包括：服务器磁盘I/O、网络设备接口流量等。

在实践的过程中我们可以通过读取数据库，获取当日委托笔数、当日登录客户数、当日交易客户数、当日开户数、密码输错锁定客户数等数据，这些指标能够协助运行团队更准确的掌握系统运行的状态。

需要注意的是流量指标有时候并不会像错误类、延迟类指标直观的反映出故障（毕竟对券商来说，业务笔数激增并不是一件坏事），但事实上大流量的背后可能隐藏着恶意的攻击或其他异常行为。因此，流量指标一般情况下作为协同判断指标，这样可以提前发出预警，最大程度的规避信息安全事件的发生。

4、饱和度类指标

饱和度类指标是信息系统对于流量、数据、业务等的承载能力。该指标主要反映影响服务状态或受限制资源的使用情况，可能是应用本身性能、处理能力存在上限，也可能是磁盘I/O速度存在瓶颈，总之当系统资源超过其处理能力最大上限而影响业务正常受理时，都应进行监控。

比如业务数据层中系统并发达到上限的80%等；

应用服务层中Oracle数据库连接数达到最大连接数的80%等；

操作系统层中磁盘利用率、内存利用率等；

基础设施层中网络带宽利用率、UPS电池剩余使用量等。

通过对饱和度指标的监控，可以帮助运行团队预测未来的资源使用情况，提早做出扩容决策，避免因容量不足导致的系统性能下降，发生信息安全事件。

为了确保监控指标完整、有效，阈值定义准确、合理，笔者建议运行团队在系统上线前先召集系统的研发人员、业务人员、安全管理员进行头脑风暴，去繁化简，确定对监控指标的预警阈值、监控时间段、监控的预警级别，形成监控列表；已上线的系统可以根据每次系统故障进行分析，避免漏项或通过新增监控指标提前发现系统异常。也可以结合历史经验，将监控指标汇总成Check-list,定期或在系统上线前进行评估。

5.3 监控告警的设定

监控是对目标数据的获取和展示，而告警是对监控采集的数据进行分析与处理，对影响系统安全稳定运行的情况，发出告警信号。大量的无用告警会极大的增加运维团队的工作量，造成运维人员怀疑告警的有效性甚至忽略重要告警信息，最终产生“狼来了”效应，影响运维效率，甚至导致运维事故。因此，确保告警的有效性，减少无用告警的产生，对运维团队来说至关重要。笔者认为在设定监控告警时，应从以下三个方面进行考虑：

1、谨慎设定告警级别

笔者建议将告警根据影响范围和重要程度分成3个级别，即重要紧急（High）、重要不紧急（Warning）、信息提示（Info）。

重要紧急类的告警表示已经对系统正常运行造成影响，收到此类告警后运维人员必须有介入动作，立即进行应急处置。

重要不紧急的告警一般是针对原因的告警，告警发生后可能并不会立即影响系统运行，但可以协助检测即将发生的故障或未被发现的问题，此时不需要运维人员及时干预，但需要重视并持续观察，对可能导致系统正常运行的提前采取预防措施。

信息提示一般针对系统运行和维护任务的结果进行告知，比如清算系统对完成清算的结果反馈、某个自动化脚本执行成功结果的反馈等。

2、合理设定度量精度

运维人员经常会遇到一种情况，即监控平台产生一个CPU使用率超过阈值的告警，运维人员还未登录设备查看原因告警就已消失，通过查看日志也未发现异常。其实这些都是属于监控频率或阈值设定精度出现了问题。

将监控对象的数据采集设置为实时监控能够提高监控的精度，但其对监控平台、被监控对象的性能以及运维人员后续的管理会造成较大考验。笔者认为可以根据系统的SLA和指标对系统影响的敏感程度综合考虑。如系统的可用率为99.9%（年停机时间小于9小时，约525分钟），每1分钟检查一次硬盘剩余空间或实时监控系统的CPU利用率是没有必要的。但如果系统的可用率为99.99%（年停机时间要小于1小时），则监控频率一定要控制在1分钟以内。

阈值的设定也是保障告警有效性的重要因素。在上面中笔者将监控项划分为四类（错误、延迟、流量、饱和度），其中错误类指标的阈值很好设定，就是一个状态，出现即告警；但流量类、延迟类和饱和度类的阈值通常没有固定的模板，笔者建议可以根据监控对象数据的平均值、最大值（最大流量、最大饱和度）、业务增量等多种因素设置合理阈值。比如一个1T硬盘容量超过80%的告警，产生告警时，硬盘的剩余量实际还有200G，但此硬盘的每日数据增量只有1G，还够使用半年，这种情况下根据硬盘的每日增量与剩余容量的比值设定告警阈值，其可参考性更高。

3、动态设定告警时限

5.4 监控的实现方法

上述指标的监控实现方法主要分为三类，分别是Agent监控方式、Trapper监控方式、SNMP监控方式。Agent方式是最长用的监控方法；Trapper一般用于自定义指标监控；SNMP方式主要用于网络设备的监控。这三类方法结合Zabbix的宏又可以实现灾备场景切换的监控。

1、Agent监控方式

需要在客户端安装Zabbix-agent。Zabbix-agent会主动收集本机的监控信息并通过TCP协议与Zabbix-server传递信息。Zabbix提供了大量的内置监控项，可以直接配置使用，比如端口、进程、日志等。对于一些自定义指标可以通过编写脚本把返回值传给Server端再进行处理，比如当日的撤单委托数，可以利用Python脚本通过连接数据库执行SQL查询返回撤单委托数量，然后传给Server端根据设定的阈值进行预警。

通过Agent+shell脚本的方式还能够实现对特殊设备和自定义监控项的监控。例如笔者在某证券公司任职时需要对EMC存储设备进行监控，但在监控过程中出现MIB库导入Zabbix不兼容的问题。最后通过安装 CLI 工具调用 Naviseccli 命令获取EMC硬件模块状态指标。

2、Trapper监控方式

Trapper监控方式使用Zabbix-sender程序主动向Zabbix-server发送数据，不需要安装Agent，发送的信息采用JSON格式，遵循Zabbix-sender协议。该方式无内置监控项目，需要自定义发送的信息。

例如上级有指示想要在监控大屏幕上显示我们的集中交易系统安全运行天数，这时就可以使用Zabbix-sender方式，利用本地执行脚本获取“安全运行天数”，然后利用Zabbix_sender命令传值给Server端，实现“安全运行天数”的展示。与Agent方式相比，这样就省去了配置Agent、重启Agent的过程，更加快捷高效。

3、SNMP监控方式

SNMP作为通用的网络管理协议被广泛的应用于各种交换机、路由器、服务器等硬件设备。Zabbix可以根据MIB库直接获取目标监控项的数值并展示出来，包括CPU利用率、内存使用率、端口状态、接口流量、电源状态、设备温度、磁盘状态等。

4、利用“自定义宏”实现灾备环境的监控

针对灾备环境的监控可以利用Zabbix 自定义宏功能（也可以理解为自定义变量）结合正则表达式实现。灾备环境的监控应从两个维度考虑，一是当生产环境正常运行时，对灾备环境相关系统基础运行指标的监控；二是当灾备环境转生产环境后，其各项基础指标和应用服务状态的监控。

要想实现应用监控指标在生产和灾备之间进行有效切换，需要通过一个“变量开关”控制监控指标是否生效，当“变量开关”为“开启”时应用服务启动为正常，反之当“变量开关”为“关闭”时应用服务不启动为正常。

以集中交易系统生产和灾备切换为例，当生产环境正常运行，从手机APP端发起的交易的业务流为：手机APP发起买入指令→KCXP队列→KCBP处理请求→写入Oracle数据库→报交易所→成交回报。正常情况下，生产环境的“变量开关”设置“开启”状态，此时，灾备环境的变量设置开关为“关闭”状态，那么生产环境应用服务器的进程均为启动状态是正常现象，灾备环境的应用服务器进程未启动状态是正常现象。当生产环境切换到灾备环境后，与前者相反，其生产环境的“变量开关”需要设置为“关闭”状态，灾备环境的“变量开关”要设置为“开启”状态，这样灾备环境整个应用服务进程启动且有成交回报才会被监控系统视为为正常情况。

通过自动化脚本设置“变量开关”方法能够让运行团队更准确、快速的掌握灾备环境的切换的进展，为灾备切换争取更多时间，减少故障损失。

5.5 可视化监控案例展示

基于上述工具与方法，开源的监控系统一样可以实现很多商业监控工具才具备的可视化“全链路”监控功能。通过对多个系统或组件的关键指标进行监控，并预先设定系统（组件）之间的关联关系绘制系统拓扑图，使运行团队能够在故障发生时快速定位故障发生点，缩短故障处置时长。

首先，需要利用Zabbix Maps 工具绘制系统拓扑图（Maps的工作原理是对Zabbix已有的触发器、图标、连接线进行绑定，使系统拓扑图告警后通过颜色的变化反映系统的运行状态），再使用Grafana Status Panel插件制作系统模块展示图，把每个系统作为一个模块进行前端展示。图3是某证券公司融资融券系统的监控拓扑展示，当展示面板变成橙色以后，只需点击就可以看到融资融券的系统拓扑，快速定位发生异常的组件，并根据应急预案进行技术处置。

      另外，也可以将金证（KCMM）、恒生、鼎点等交易系统厂商自带的监控数据通过Grafana Status Panel进行前端展示，以弥补开源监控系统对某些业务指标的监控，形成一套完整的监控体系。

图3

6 监控管理流程

前文已经对Zabbix监控系统的构建做了介绍，本章主要是对系统监控管理的重要环节进行讲述，使监控系统搭建完毕后，能够在日常工作中能够真正为运维团队所用，提高系统运行维护管理水平。

6.1 监控设置及告警处置流程

笔者发现在进行监控管理的过程中，很多公司容易忽视监控设置和告警处置流程。当人员发生离职或调转的时候，很多监控项、监控阈值任谁都说不清为什么这样设置；当告警触发后，也不清楚是否有人处置，容易造成疏漏导致信息安全事件的发生。因此，笔者认为非常有必要对监控设置及告警处置过程进行管理。

1、监控项设置流程

笔者建议在OA或者运维服务管理平台中，针对监控项的增、删、改创建专门的流程，当需要进行操作的时候通过流程去管理，这样做的好处是任何时候都可以回溯相关的事项，也可以避免因个人操作导致监控项、监控阈值设置不合理的情况。某证券公司监控项变更流程及审批节点如图4所示：

图4

2、告警处置流程

所谓的告警处置流程，就是通过系统地观察服务和服务组件，管理整个生命周期中的事件，最小化或消除其对业务的负面影响。笔者认为告警处置流程的几个关键过程应包括告警发现与记录、诊断、处理和关闭四个阶段。

在告警发现与记录阶段，一线的监工工程师应该及时将告警信息进行记录，并指派至对应的系统运行负责人处；

诊断阶段主要是确定告警信息是否为误报，系统运行状态是否正常，对应系统的影响及范围等内容；

处置阶段主要是依据诊断结果对告警信息进行处理，如已经导致服务可用性下降或业务中断，应根据应急处置预案进行应急处置，快速回复业务；

关闭阶段主要就是对告警内容做出应答，一线监控工程师应该跟踪告警的处置进展，确保每一条有效告警信息都能被处理和关闭，不留隐患。部分监控系统支持对告警事件的推送，自动将告警信息同步至运维管理平台，如果没有运维管理平台也可以让一线监控工程师通过Excel来进行记录和管理。

6.2监控评估管理

1、系统的容量评估

容量管理的目标主要是为了通过合理配置资源，确保信息系统有足够的容量满足当前和未来的业务需求，使IT投入能按计划进行，减少资源的浪费。因此，通过监控系统的数据进行趋势分析是容量管理中行之有效的方法之一，评估内容主要包括如下四方面：

（1）网络层面

证券公司网络架构相对比较复杂，除了要监控公司办公网出口外，还需要对业务网络、主备中心间网络、主备中心到交易所、结算公司等各类网络带宽进行监控。同时，证券公司带宽受市场行情影响，而网络运营商对带宽进行扩容一般都有一定的实施周期，因此，需提前进行规划，以免影响业务。

（2）系统层面

系统层面主要针对操作系统的磁盘空间、CPU、内存使用率进行评估。部分证券公司通过私有云构建了生产系统交易环境，需要对整体的云资源使用情况有充分的了解。笔者之前所在证券公司每月会对私有云的上述指标进行评估，当达到70%使用率时就会提前启动扩容项目。这样即使有新项目上线或业务激增的情况，也能够从容应对。图5是某证券公司私有云的部分评估内容：

图5

（3）业务层面

业务层面的容量评估主要针对核心交易系统的关键业务指标，包括行情、日均委托、日均开户、存管转账等，确定目前系统是否能够支撑未来一段期限内的业务发展，根据量化的数据模型提前做好扩容准备工作。某证券公司业务指标评估样例如图6所示：

图6

2、系统可用性评估

笔者认为系统的可用性评估可以从可用性、可靠性和可维护性三方面入手：

（1）可用性：指一个组件或服务在设定的某个时刻或某段时间内发挥应有功能的能力，比如某个业务当月的中断时长。

（2）可靠性：指 IT基础架构无间断运行的能力，取决于某个IT组件的可靠性和IT基础架构的整体恢复能力，比如某个业务的中断次数，某条线路的中断次数。通过分析故障设备的故障次数，能够使运行团队了解设备或者线路的稳可靠性，更有针对的制定应急预案或改进运行方法；

（3）可维护性：指IT基础架构在出现故障后迅速恢复的能力，比如故障响应时长、故障恢复时长等。通过分析这些指标，能够使运行团队了解某个业务或系统的处置能力及存在的不足，进行持续改进。

3、监控项和监控阈值评估

针对监控项和监控阈值的评估笔者认为可以从完整性和准确性两方面进行评估。完整性就是通过对异常事件的分析以及日常运行监控过程中发现的问题，判断每个系统的监控阈值是否完整，是否有因监控项缺失导致未能及时发现的故障；准确性就是通过分析回顾当月/季度的报警数量，筛选出误报的报警，对监控策略模板或者单个系统的报警阈值进行调整，已符合运行管理要求，减少因误报导致的工作量。

建议评估方式采用组内专题会议的方式进行，结合系统的变更清单、事件清单、告警列表及系统部署逻辑架构图进行评估，集思广益，对发现的问题进行记录，制定解决方案，落实整改责任人和整改期限，形成评估报告。

6.3 监控系统管理

最后，监控系统自身也要进行必要的日常管理和运行维护，结合监管要求和实际工作经验，总结如下：

1、每日对监控系统自身运行状态进行巡检，保证监控系统正常可用。如有一线值班人员，可由一线值班人员纳入值班管理，统一监控；

2、制定计划任务每日对监控系统自身的配置和数据进行完全备份，并将备份结果纳入监控管理；

3、定期对监控系统中用户账号进行检查，删除无用账号；

4、确保监控系统日志保存时间不少于一年。

7 行业建议

随着中国证券金融行业的高速发展，金融业务种类推陈出新，在行业内也掀起了技术驱动业务的浪潮，国内各大券商信息投入占比逐年增加。金融科技的创新正在改变证券行业商业模式，即从传统的收费模式向通过互联网技术提供专业服务的模式转变，以便在竞争激烈的市场中通过金融科技快速推进金融产品与服务创新，抢占市场先机。与互联网行业不同的是，由于证券公司对系统的安全稳定性要求较高，系统从架构设计到选型中大多采用成熟的商业产品，以获得更好的服务与技术支持。但近几年，A（AI人工智能）、B（Blockchain区块链）、C（Cloud云计算）和D（BigData大数据）飞速渗入证券公司的各个领域，随着开源社区的不断发展，越来越多的公司和运维人员开始“拥抱开源”，并且在实际应用中让这些开源技术与商业软件协同工作，使信息技术更好的支撑业务发展。此外，开源工具还具备以下优势：

1、降低信息技术运维成本

商业软件大多需要付出额外的采购费用以及持续的维保费用，对中小券商来说无形增加了公司整体运营成本。而开源工具大部分都可以免费使用，如果想获得更好的质量也只需要支付商业软件的一小部分成本，且开源技术解决方案通常会有蓬勃发展的社区，全世界爱好开源技术的人们共同维护和改进开源工具，完全可以作为企业的技术资源支撑。

2、加快创新和产品迭代

近年来开源社区发展飞速，能够实现快速创新和迭代。由于开源解决方案的代码都是公开可见的，任何人都可以在此基础上进行免费开发，因此，众多开发者在持续改进功能、提升用户体验。

3、减少对外部的技术依赖

采购商业软件必然在功能、价格、开发周期、维护等方面受到供应商的制约。如采用开源技术，所有需求都可以结合企业实际情况量身定制，甚至进行二次开发。由于证券行业本身技术趋同，采用相同技术架构的公司可以方便的将成果分享给其他公司，既实现了知识资源共享，又能促进行业的交流与共同进步。

4、安全可控

随着《中华人民共和国网络安全法》的颁布，国家越来越重视网络安全和个人信息保护。开源工具的每一行代码对用户都是可见的，无需担心商业软件后台留有后门程序非法获取企业信息等安全问题。

综上所述，开源技术这一概念已从幕后走向台前,建议行业在非核心交易系统--尤其是运维管理工具中可以加大开源技术的使用，如监控系统（Zabbix、Zenoss、Nagios）、自动化运维(Ansible)、运维流程管理（Itop）、堡垒机（Jumpserver）等，更为高效的提升运维管理能力，降低运维成本。当然，这也需要证券公司有足够的技术能力作为支撑，这也对行业信息技术人才提出了更高的要求。

8 总结

感谢大家抽出宝贵时间阅读，希望本文能对证券公司的监控管理工作有所启发。由于水平有限，文中不够完善之处敬请谅解。随着信息技术的发展，目前也出现了很多监控系统与运维管理平台、自动化运维管理工具结合的案例，能够实现智能定位、故障自愈等功能，实现运维一体化的管理，极大的提高了运维效率，如果大家有好的经验欢迎随时与笔者交流、分享。

参考文献

《证券期货业信息系统运维管理规范》

《Google SRE》

Zabbix官网：https://www.zabbix.com

Grafana官网：https://grafana.com

 

附录：某证券公司监控系统主要监控指标

1、业务数据层监控指标及阈值

序号	监控指标	阈值设定（故障）	级别
1	异常业务的笔数	>1 >10 >50	warning average high
2	成功委托数	无	info
3	已申报委托数	无	info
4	已处理成交数	无	info
5	撤单委托数	无	info
6	当日开户数	无	info
7	密码输错锁定客户数	>5	warning
8	生产、灾备环境应用软件版本	不一致	high

2、应用服务层监控指标及阈值

（1）数据库

序号	监控指标	阈值设定（故障）	级别
1	监听端口 进程存在	端口不存在 进程不存在	high
2	表空间使用率	>80%	warning
3	建立连接数占比：Max_used_connections/max_connections	> 85%	warning
4	临时表占用空间百分比：Created_tmp_disk_tables/Created_tmp_tables	>25%	warning
5	有创建、删除操作：Com_delete、Com_drop%	交易期间有操作	warning
6	表打开文件占比：open files/open_files_limit	> 75%	warning
7	表扫描率：Handler_read_rnd_next/com_select	> 4000	warning
8	慢查询次数：Slow_queries	>= 5	info

（2）应用集群

序号	监控指标	阈值设定（故障）	级别
1	集群健康状态	yellow red	warning high
2	集群节点数	无	info
3	数据节点数	无	info
4	主分片数	无	info
5	可用的分片数	无	info
6	正在迁移的分片数	无	info
7	正在初始化的分片数	无	info
8	可用分片数占总分片的比例	无	info

3、操作系统层监控指标及阈值

序号	监控指标	阈值设定（故障）	级别
1	ping	3分钟内连续3次不通	warning
2	CPU使用率	平均五分钟使用率大于80%	warning
3	可用内存	平均五分钟使用率大约80%	warning
4	可用存储	最近一次（每分钟检测一次）的可用存储小于20%	warning
5	Agent连通性	5分钟内的检测均没有得到从Agent返回的数据	warning
6	系统运行时间	系统进行重启	high
7	与server端时间差对比	与server端时间差超过10s	warning
9	端口流量	无	info

4、基础设施层监控指标及阈值

序号	监控指标	阈值	级别
1	网络设备、主机、存储等CPU状态	正常范围大于40%	average
2	网络设备、主机、存储等内存状态	3分钟内平均值大于100M
3	端口状态	1分钟内端口频繁UP/Down变化	high
4	网络延时	5分钟内平均值大于0.25s	warning
5	数据流量	根据实际带宽需求确定，一般大于80%报警	warning
6	存储电池状态	正常电池个数小于46(根据实际情况设定)	warning
7	存储硬盘状态	正常硬盘个数小于238	warning
8	存储运行日志	运行日志中出现error	warning
	空调、UPS
	UPS电源
	广域网、局域网带宽

EMC存储监控中使用的监控脚本参考如下：

电池状态：naviseccli -h [IP address] getcrus | grep Present |wc -l