2019-11-01 09:55
在2019年11月1日举办的2019金融科技产业峰会之“人工智能在金融领域应用”分论坛上，中国信息通信研究院联合行业协会、金融机构、科技厂商、高校等多家单位，邀请知名学术界专家、行业内顶尖企业工程师，就人工智能在金融领域应用的相关议题开展交流，希望为金融及技术领域从业者提供交流的平台，共同推动行业健康发展。光大证券信息技术总部高级经理孙伟在论坛上做了题为《智能检测与定位在光大证券运维中的实践》的精彩演讲。
光大证券信息技术总部高级经理孙伟
孙伟：各位领导、各位专家，我是来自光大证券的孙伟，我跟大家分享的主题是智能检测与定位在光大运维中的实践。
首先介绍一下自己，我是85后，在乙方做了四年运维开发以及实施经验，怀着对甲方羡慕嫉妒恨进入了光大。不论角色如何，其实我一直是地地道道的一线运维人员，如果有人问我，你作为运维人员你觉得最大的挑战是什么？一入运维深似海。
运维高度依赖于运维经验，对于运维工作来说，就是咖啡式运维，这种往往觉得比较理想、比较漫长的，作为理想中的运维，系统可以极早地发现风险，给我们足够多的时间修复这个风险，从而避免故障的产生，在故障真实产生之后，帮我们找到故障的原因，帮我们修复故障，及时止损。2016年通过机器学习对运维大数据进行分析，找到运维规律，从而提升运维水平。这个方案提出来以后，我们和各家高校实际场景测试之后选择这个场景作为实际落地和研究方向，大家可以看一下，这是我们整个异常检测的一个图。
首先，整个异常检测是以业务为导向的，大家可以看到，我们首先会对应用的KPI指标进行实时的监控，在发现异常之后我们会对组成这个应用的关键组件所有的组件包括KPI进行一个全局的异常检测。最后，我们会这些模块所运行的日志进行日常检测，因为大家知道，其实故障的原因往往隐藏在日志之中。相信在故障发生的时候，我们将所有这些信息摆在我们运维人员的时候，是可以帮助运维人员进行快速的故障定位和故障排查的，这事实上也是我们人为排查故障的正常步骤，因为当故障发生的时候，特别是一些比较复杂的故障，其实是需要各种系统管理员从各个方面进行全局的检测。
在整个场景的构建之后，接下来就构建AI平台，大家知道构建AI平台有两个方面，一个是数据一个是算法，接下来我做一个介绍。首先是数据部分，我们将数据分为三类数据，一是指标数据，二是日志数据，第三是RTM（音）数据，指标数据业务指标和性能指标，业务指标可以反映业务的好坏，不同的业务系统业务指标是不同的，具体的方式也是不同的，网上交易日志，抽取出来的调用数据、平均延时等几个关键指标，到集中交易系统还有OCR系统是通过与APM这种工具进行对接获取这种指标。第二种指标就是性能指标，这些指标就比较固定，操作系统有CPU利用率等等，这些KPI我们通常从监控系统获取，可以实时进行抽取，这些指标是我们作为日常定位的重要的来源跟数据对象。
第二个数据是日志数据，我们将日志数据分为两种，业务日志和运行日志，这些日志我们用做什么呢？第一个抽取业务的关键指标对日志的解析和计算，经过日志计算分析之后，这些指标也是我们作为一个业务报表实时报表输出的重要数据来源。第二个日志是系统运行日志，这种日志其实是可以描绘某一个模块的运行状况。通常来说，大家知道操作系统还有数据库日志，Grade运行日志等等，这些运行日志中我们用来干什么呢？主要做日志日常检测，故障发生的时候我们会对这些日志进行检测。
第三种数据是ITSM数据，一个是CMDB数据一个是变更数据，CMDB给我们提供了算法编排也是我们数据采集的基础，因为它提供了各个模块之间的访问关系和组成关系，另外它也包含了各种日志所在的日志路径。另外大家知道在故障发生的时候，还有一种数据就是变更数据，为什么把变更数据拿出来，大家都知道在故障发生的时候，故障发生原因往往有可能是变更引起的，所以真实的情况下我们在进行故障排查的时候我们会把相应的应用最近一段时间所做的变更也展现在运维人员面前，帮助他进行进一步的故障定位。
以上是所有的数据部分。接下来跟大家介绍一下算法部分，数据部分虽然处理起来是非常复杂的，非常烦琐的，但是最有开源方案或者商业方案来进行，只要投入足够的人力可以做好。但是算法这块专业性非常强，它其实需要支撑的。算法往往缺少一定比如说金融的运维数据还有包括运维经验等等，但是运维人员大家可以看到你在运维中找到非常了解算法或者精通算法的人非常少，这块我们与清华大学一起共同学习进行研发进行算法落地。
然后在我们生产上，包含了三种核心算法，首先是单指标异常检测算法，单指标异常检测算法主要处理哪些问题呢？传统的监控工具主要是依赖于绝对阈值进行监控，绝对阈值存在着诸多问题。首先是大家知道这套系统非常多，你对每一个指标的设置很难保证它的阈值，对于不同的机器阈值设置要不同，设置不同的时间段要设置不同的阈值，交易时间、非交易时间等等，所以处理起来非常复杂。绝对阈值还有一个致命的弱点，就是不能描绘整个数据变化的趋势，单指标异常检测主要解决就是这个问题。我们考量了有两点，第一点我们需要这种检测算法不需要过多的人为标注，因为这个标注非常复杂，运维人员其实没有这么多时间的。另外一个我们需要一套算法对多个指标或者曲线都可以进行检测，而不是说不同的曲线不同的指标要选择不同的算法。
我们整个算法分为特征描述器和检测器，特征描述器主要是通过对历史数据的学习提取出曲线的特征，包括抖动性偏离性等等，这些特征会指导后面检测器的设置，里面会有不同的算法，选择不同的算法或者算法组合对这个曲线进行检测。这整个一套检测方法有几个好处，第一运营效率高，在生产中已经对数万个业务指标进行实时监控。检测器是算法的组合，可以随时扩容，对于不同的曲线可以随时扩容不同的检测器。第三是无监督的，不需要大家进行数据标注或者进行极少标注就可以了。
第二个算法就是多指标异常定位算法， 在我们对关键指标进行定位检测发现故障以后，我们会对这个业务依赖的所有组件和指标进行检测，我们会将检测的结果进行相似度聚类，最后通过排名算法给出最有可能出现故障的模块或者最有可能是故障原因的模块或者是KPI，这个算法效率非常高，在真实生产中故障发生之后我们点一下异常定位的话，可以在一分钟之内，当时是4000多个指标进行检测，效率还是很高的。大家知道CMD里面包含各种业务之间的关系，这些指标的来源其实就是CMD面临的一些数据。
第三个算法是日志异常检测算法，说到日志异常检测大家会说日志异常还不简单吗？设一些关键字就行了。事实并不是如此，对于某一个特殊的日志设一个关键字就可以了，但是其实运行的日志非常多，关键字很难设，不同关键字是不一样的，设置关键字的时候出现了关键字不代表这个业务就是异常的，即便没有出现关键字也不代表业务或者运行模块就是异常的。举个例子，数据库在集群启动的时候会有一些日志，它是一个正常行为，因为启动顺序的原因是一个正常行为并不代表这个启动有问题，我们再拿数据库的日志为例，在业务繁忙的时候大家会关注到里面会有频繁的日志切换，这里面没有关键字等等报错可能说明有问题，说明数据库设置太少了，导致日志切换频繁，至少有一个优化的空间。所以日志异常检测有一套解决问题的方法，首先我们通过对日志的训练学习对所有的日志进行分次序列化，核心就是模块提取算法，通过这个算法我们会对日志进行模板提取，这些模板会对日志进行实时解析，解析后的日志就是结构化日志，有各种变量，通过变量各级整个模板数据量的变化判断日志的异常。
模板提取不写一些正常表达就可以。处理过日志的同学都知道确实可以这样做，但是同样的问题日志量非常多，各种日志，写正常表达的工作是非常复杂的，有些日志有非常多的格式，举个例子，我们有一个业务日志，我上次看了一下有50多个日志，写50多个阵格，非常复杂。而且还需要不断的人工回复和编写，况且这个效率也不是很高，这是日志异常检测算法。
说完了整个算法以及数据这块，接下来我想给大家演示两个场景。第一个场景是通过我们智能运维平台在及时发现了异常并且通过智能运维平台找到了故障的原因，这里面我有一个录屏，没有刚才播放视频的高大上，我之前看了一下不是很清晰，可能是分辨率的问题，大家可以看一下。这里的话就是我们一个智能运维平台，大家可以看到这里面是有很多业务指标实时运行的状态，实时检测，110号业务指标发生了异常，平均响应时间出现了托帧，这个指标是平均响应时间是1202号的平均响应时间，异常定位定位是一个资讯组的模块，同时还有IP地址和指标，这个指标是网络传输指标，大家可以看看当时明显发生了托帧，达到了1000兆每秒。这个故障也明显了出现了托帧，这个日志显示客户端断开了，我们到这个机器看了一下，就是有一个任务被触发了，导致响应时间变长的情况，整个的过程非常清晰。
除了实时异常检测还有其他功能，在这个模块可以看到所有的性能指标包括一些基础性能指标，还有一些模块的聚类情况，在一个平台都可以看到，同时还可以提供日志实时搜索的功能，在这里可以对日志进行实时搜索，这是最近十分钟的日志等等。
另外智能运维平台还包含了算法中心可以随时对这里面进行算法的扩充以及扩容，然后进行一些算法设置等等。
以上就是第一个场景的介绍，因为时间原因我可能讲的比较快一点。
第二我想跟大家介绍的是去年11月份的时候，这个是真实的案例，这个案例我们及时发现了风险，并且最终修复了风险避免了故障的产生。一共三个图，第一个图是异常指标检测的图，一个指标出现了异常，左边多指标异常定位的结果，排名前两位的分别是数据库，数据库的等待指标以及数据库的CPU指标，右边是日志异常检测结果，大家可以看到当时日志摘要里面有异常的情况出现。其实并没有出现问题，整个业务是正常的，事后跟厂商人员一起故障排查，这是一个BUG，会导致业务高峰期响应时间会变慢，甚至会造成服务中断的风险，我们及时发现了这个风险及时修复了。这个案例对我来说印象非常深刻，因为其实当时在异常检测到的时候除了我们的智能运维平台其他平台并没有发生这个异常，包括我们的监控平台，就是对数据库的监控、操作系统的监控并没有发现，因为它没有达到阈值，当时CPU在7-8%左右，这种指标会迅速消失，大家也知道，不会对CPU7%就告警，关键是业务人员也没有发生整个系统变慢，所以这是一个潜在的风险被我们修复了，保证了我们整个系统安全稳定运行。
以上就是我对算法包括平台、数据整个做一个介绍。最后想跟大家说一下整个的收益情况，整个平台是异常检测以及实时定位这样的目的，其实可以减少MTTR的时间，同时提升RTO水平，进一步保障系统的安全、稳定运行。另外一点我们大规模开源技术的应用都是帮我们节省了不少的经济成本，因为我们开始替换一些纯商业的技术监控软件，同时提升运维自主开发能力。
在经验这块想跟大家分享三点，第一点是算法这块，算法是决定智能运维是否能成功或者是能否是鸡肋的关键点，我们自己在跟清华大学合作之前也做过一些算法在预测方面做了一些研究，但是效果并不是非常理想。现阶段与一些科研单位或者一些高校进行合作合研的方式是相对来说比较保险的道路。
第二点数据是非常重要的，包括数据的实时性、颗粒度，还有采集频率都是非常重要的，这也是决定AI是否能够成功的关键环节。
最后是平台搭建这块，要搭建足够的灵活的平台，因为你的算法会随时扩容，我们在平台里面依据服务宗宪，分别解决服务调动和数据处理的问题，这里面时间关系就不会做进一步的介绍了。以上就是我所有的介绍，谢谢大家。