清华大学金融科技研究院孵化
金融科技与金融创新全媒体

扫描分享

本文共字,预计阅读时间

文/中信建投证券首席信息官肖钢,中信建投证券信息技术部徐志彬、刘亚静

(本文为“证券机构数字化转型与证券科技创新”征文活动精选文章。)

一、背景

信息系统安全、稳定、高效运行,是证券公司IT部门的重要职能,也是服务客户的重要途径。随着业务的快速发展,信息系统复杂性成倍的增加,尤其是随着中台系统的建设,完成一个业务,需要多个信息系统配合,大大增加了系统的复杂性,运行管理的难度随之增加,加之信息系统的数量也快速扩张,人力资源与系统快速膨胀的矛盾也更加突出,因此,在业务快速发展及信息系统快速变化的过程中,如何有效地保障信息系统安全运行,面临新的挑战。

经过多年的发展,IT运维管理从流程化、可视化、自动化、逐步实现运维管理全生命周期的数字化,并向智能化转型,在这个过程中,如何准确地从全局上揭示系统运行状态、分析并预测IT系统后续的运行状态尤为关键。如果可以做到这点,我们将会提前发现系统潜在的问题,比如系统容量问题、系统性能问题以及系统交互的合理性,更为重要的是,我们可以利用大数据和AI技术,来提升系统运行和管理的可靠性,从而促进系统运行和软件质量的提升。此时,运维团队的价值也随之发生变化,由低价值的重复工作,逐步转向与开发团队共同构建高质量的业务系统,为客户提供更加高效、稳定、安全的信息系统综合服务;同时,IT运维人员也从繁杂日常事务中解放出来,从而有更多的时间和精力进行运维设计及相关工具的开发,开展各类信息系统运行分析,进一步提升了系统运行质量和综合IT服务。

本文将结合实际的应用场景,介绍我司利用大数据和人工智能技术,来提升运维质量的实践以及探索。

二、运维分析系统介绍及落地

运维是技术类运营维护人员依据业务需求来规划信息、网络、服务,通过网络监控、事件预警、业务调度、排障升级等手段,使系统服务处于长期稳定可用的状态。运维分析系统是以大数据和机器学习为基础,从多种数据源中采集海量数据(包括日志、监控数据、探测数据、网络数据等)进行实时或离线分析,通过主动性、人性化和可视化的形式帮助IT运维人员全局把握系统的运行状态、分析预测系统的后续运行状态以及系统排障等。

2.1   运维分析系统架构介绍

参考大数据平台的架构,运维分析系统由数据采集层、数据解析层、数据存储层、数据计算层和展示层组成,逻辑架构如下图所示。

数据采集层是整个运维分析系统的数据来源,其所接入的数据类型包括实时日志、监控数据、探测数据和网络交换机数据等。采集的方式分为主动和被动两种方式。主动的方式为通过agent(例如Filebeat)主动采集数据(例如日志),将增量数据推送到Kafka。被动方式为Kafka被动接收从其它系统(例如天旦)推送过来的数据(例如网络数据)。

数据解析层负责对采集到的实时数据进行格式化处理。数据从解析层开始,分流保存到实时库(ES)和历史库(HDFS)中。数据通过Logstash解析后,进入ES中;通过Flink或Flume进入HDFS中。

数据存储层用于落地格式化后的运维数据。依据不同的使用场景,选择不同的存储方式。实时数据选用支持全文检索、分词搜索的ES;实时性要求不高或历史数据存于HDFS中。

数据计算层提供实时和离线数据计算。通过Python脚本形式,实时对ES上的数据进行二次加工处理,计算的结果保存至ES;通过 Hive或Flink对历史数据进行计算,计算结果同样保存至ES。

展示层为用户提供可视化的方式展示运维数据的聚合结果,展示的形式包括指标、视图、看板和场景,同时支持策略的自定义编写(采用Python语言)和报警功能。

2.2   运维分析系统的主要使用场景及功能

1)  主要使用场景介绍

故障定位(链路耗时分析)场景

交易时延是衡量交易系统的一个重要性能指标。目前由于交易系统具有中心化特点,客户的交易请求需经过多个环节才能报给交易所,同时各系统上线后配备的监控系统只能监控自身,当出现耗时大的请求,无法快速定位到哪个环节是导致耗时增大的根本原因。

链路耗时分析场景通过每个请求在整条链路的各个环节都记录了唯一的msgId,利用Python算法脚本计算出该请求的所经轨迹,在展示层绘制出请求链路并统计出轨迹中每个环节的耗时,同时筛选出途经设备的相关指标,查找出异常指标,帮助IT人员快速定位根因。链路耗时分析场景如下所示。

接口调用分析场景

图2.2.1 XX系统接口分析

客户端的一个业务功能可能由多个请求完成,同时一个请求可能会拆解成多个子请求,如上图2.2.1所示一个登录请求在TradeService环节会拆分成5个子请求。

接口调用分析场景可以统计出每个业务功能在途径各子系统接口拆分的情况。根据接口间的映射关系,IT人员可以评估接口设计是否合理;同时为系统链路分段探测提供数据支撑,分段探测程序可以指向链路中的某个环节(Nginx)通过直接调用接口(/api/login)来模拟APP端的业务功能请求(/api/login)来完成功能探测。

客户行为分析场景

在对系统进行压力测试(以下简称“压测”)时,通常按照实际接口调用比例准备测试用例,往往忽略了接口间调用的上下文的影响。例如客户实际按照下单、查成交、查持仓的顺序操作,由于下单成功后,成交记录和持仓会增加,随着下单笔数的增多,查成交、查持仓压力会逐渐变大,耗时也会逐渐变大。如果压力程序没有按照这种客户实际操作顺序来压测,就会造成最后的压测结果与实际有出入。客户行为分析场景基于历史数据,采用Hive/Flink按照时间序列将客户操作流水提取出来,压测系统基于分析结果自动组装测试用例。另外,基于历史数据利用机器学习去统计客户的交易行为、投资偏好,为客户打标签(画像),实现公司证券产品的智能推荐和精准营销。

在检测客户异常交易行为方面发挥的作用

目前反外挂工作正在全行业推进,对于客户采用外挂程序非法对接交易系统、操控多账户、交易留痕虚假等非法交易行为进行限制。运维分析系统通过分析交易频率、外网IP与资金账号对应关系、留痕信息与资金账号的对应关系等来排查外挂行为。针对反外挂这件工作,策略上应采取疏堵结合的方式,证券公司要去了解客户的诉求,利用公司的技术来帮助用户去合理合法的实现用户的量化交易需求,从而实现双赢的目的。就这点上,对于运维分系统来说后续还有很多的事情要做,利用AI技术去学习客户的操作行为,推导出相应量化策略,给客户提供更有价值的产品。

在系统容量评估方面发挥的作用

证券公司外围系统上线后一般采用多站点分布式部署,鉴于交易系统中心化的特点和长途专线的影响,各个站点的实际接入能力会不一致。

图2.4.1 多站点拓扑

如上图所示,上海站点的交易请求数据最终要汇聚到北京后再上报给交易所。由此可见,受长途专线影响从上海入口进来的请求耗时明显要大于从北京入口进来的请求耗时。此时对两个站点的容量评估就不能再简单的依赖于压测数据。保障系统容量的最终目标是保障客户流畅的操作体验,不出现卡顿现象,不出现因容量不够带来的报错。运维分析系统从以上目标出发,通过分析接口的报错率、请求耗时(RT)与TPS的走势来评估系统各站点运行的真实负载和实际可承载能力。在对响应速度要求较高的业务中,RT与客户体验的关系如下:

随着RT的增加,用户体验逐渐变差(绿色好,红色差)。所以当RT超过200ms时,需要考虑扩容站点的容量或限制该站点的接入人数。

图2.4.2 XX系统容量分析指标面板

2)  其它功能

日志查询

运维数据通过实时采集、格式化处理,保存到ES。IT人员无需再登录到机器上查看日志,只需通过运维分析系统就可以实时查看日志。查询语法保持ES DSL的语法规则,支持全文检索,分词搜索等功能。

实时监控

由于数据采集的实时性特点(秒级),运维分系统通过创建指标、设置报警策略和搭建场景,实时自动筛选出日志中的报错信息,例如状态码5XX、耗时大于2S的请求,实现对系统整体运行的全方位的监控。

数据二次加工计算

运维分析系统支持对采集到的原始数据定期进行二次加工处理。该功能通过Python脚本对数据进行处理,处理的结果保存到ES中或历史大数据平台中。例如日活、日最大TPS、日最大并发在线人数、各站点每日95%分位耗时统计等。

历史指标主要用途:分析指标的历史走势;用作动态阈值(例如当前值与(历史均值×浮动系数)做比较,可以发现某些指标抖动的现象)。

历史数据查询

原始运维数据经过Kafka分流后,分别保存到ES和HDFS中。经验证,保存到ES上的数据大小是原始数据的6-10倍,且ES在搜索过程中,会将数据加载在内存中,所以ES如果定位实时索引,不建议存放太大的数据。HDFS的定位为存放历史数据,数据文件压缩保存,同时配置大空间的存储。当读取历史数据时,通过Hive/Flink读取HDFS上的数据,将计算后的结果保存到ES上。

2.3   落地经验总结

运维分析系统的建设是一个指标化、场景化和智能化的过程,最终通过大数据技术和AI智能算法,与自动化系统对接,形成智能分析、智能排障、智能修复一体化智能分析过程。因此运维分析的实施路径可分为以下三个阶段:

1) 指标化

数据是运维分析系统落地的基础,运维分析系统的落地首先要建立大数据平台,对运维数据进行采集、解析、存储,并定义标准化的指标体系,积累大量的可用的运维指标。

以性能指标体系为例,可对操作系统、数据库、中间件等应用建立可供分析的性能指标体系,并在系统运行中获取性能数据,以此来刻画各应用的正常状态,为后续的检测、预测、分析等提供基础的运维指标数据。

2) 场景化

从实际出发,立足当前运维痛点,从简单监控型运维场景切入,如通过组合系统运行指标,建立全局性系统运行状态监控场景,为后期进行运维分析智能化的实现打下基础。

3) 智能化

运维分析智能化是指对运维场景中硬件、系统、网络、数据库、中间件等分别实现智能监控、异常预警、故障发现、故障分析、根因分析、故障自愈等闭环场景。以链路耗时分析为例,当运维分析系统检测到请求耗时RT超过阈值或产生波动时,将发出告警信息,同时自动排查故障环节,定位故障根因,经IT人员确认后,调用自动化运维工具执行相应的修复操作,实现该场景下故障自愈。智能化实现的关键是AI技术和智能算法。智能算法的引入可分为根据IT运维人员的经验自己编写策略脚本和使用专业的AI算法两个阶段。针对智能运维的一体化,运维分析系统也要与配置管理系统CMDB、事件平台、自动化系统对接,来形成故障自愈的闭环。

2.4    运维分析系统的一些技术特点

由于我司部分系统采用多站点分布式部署的方案,数据存储在多个不同的IDC机房,例如北京、上海、广州、成都等,考虑到专线带宽和实效性,数据无法实时归集到一个中心。经调研,我司利用ES的Cross-Cluster技术,在每个IDC部署一个ES集群,实现了数据采集在本地,解析在本地、保存在本地。当要从多个ES集群上统计数据时,通过中心ES集群向各IDC ES集群发送请求,各IDC ES收到请求后在本地计算出聚合结果,将结果返回给中心ES,中心ES将最终的汇聚结果返回给展示终端OptAnaly。

在数据源方面,运维分析系统既可以使用自己ES的数据,也可以使用第三方ES的数据。考虑到第三方系统使用的ES版本不同,对于老版本的ES(5系及以下),系统采用TransportClient技术;对于新版本的ES(6系及以上),采用了功能强大且ES官方推荐的Java High Level Rest Client技术。

在系统设计方面,本着从一款开放式的工具产品出发对系统进行设计。用户可根据自身需求快速创建指标、视图、看板、场景等对IT系统进行监控分析。运维分析系统不仅可在证券公司使用,还可在任何具有IT系统的场景中使用。

三、运维分析系统给证券公司数字化建设带来的好处及问题

在公司内部运营方面,运维分析系统推进了IT运维工作向标准化、数字化、自动化、智能化方向发展,提升工作效率,降低成本,提高系统的安全性和可靠性;IT人员从基础的日常维护工作向系统专家转型,建立起善于利于运维数据分析系统运行状态的习惯,提升通过分析系统各种性能指标来优化系统的能力。

在客户价值提升方面,基于客户的行为分析为客户制定画像,用机器学习客户的交易策略,了解客户的实际需求,制定出符合客户个性化需求的产品,实现公司产品的精准营销,实现公司业务价值的最大化的最终目标。

数据是数字化转型的基础,安全是数字化转型的前提。运维分析系统中包含了内部系统运行的数据,也可能包含一些敏感数据。一旦发生网络攻击,敏感数据的泄露将给公司和客户带来巨大损失。因此,网络及数据安全必须摆放在数字化转型的首要位置,是数字化转型工作必须优先考虑的环节。

四、总结与展望

运维分析系统采用大数据技术和智能算法对运维数据进行分析,推动了IT系统运行向标准化、数据化、智能化、自动化转变。在标准化方面,促使各系统日志输出格式更加规范,内容更有价值;在系统容量评估上引入全新的评估标准,依据报错率和耗时两个关键指标来分析各站点的运行状态,进而评估各站点的真实负载和实际可承载能力。在智能化方面,利用策略算法自动排查故障、故障定位以及自动修复。整体做到以主动预防为主,全局性掌握系统运行状态,以及对系统后续运行状态进行预测。

另外,运维分析系统的使用促使IT运维人员从被动地面对系统故障转变为主动分析系统性能,向系统架构和业务转变,更多的投入到有价值和创造性的工作中,例如系统架构设计评估、开发以及新技术的引入,从而更好的支持企业的业务创新,更好地体现IT团队及个人在企业中的价值。

虽然现阶段通过一些策略算法实现了故障定位,但距真正的人工智能还有很长的路要走。未来,在大数据和智能的基础上,通过将运维经验公式化、数据化来落地更多复杂的运维场景,同时加强AI人才储备,积极探索更多实用的算法和模型,与行业交流学习,拓展思路,实现互利共赢。

[Source]

本文系未央网专栏作者发表,属作者个人观点,不代表网站观点,未经许可严禁转载,违者必究!首图来自图虫创意。

本文为作者授权未央网发表,属作者个人观点,不代表网站观点,未经许可严禁转载,违者必究!首图来自图虫创意。

本文版权归原作者所有,如有侵权,请联系删除。首图来自图虫创意。

评论


猜你喜欢

扫描二维码或搜索微信号“iweiyangx”
关注未央网官方微信公众号,获取互联网金融领域前沿资讯。