某金融保险数据中心基于机器学习的智能运维实践分享

综述

某金融保险数据中心的智能运维项目秉承自主创新的业务理念，掌握自有的技术自主知识产权，建设完全自主的平台，践行机构内部的数据存储管理，具有一定的行业通用性和示范作用。数据中心立足于传统运维职责，通过机器学习技术将运维水准整体大幅提升，实现数据中心智能化，实现运维工作更敏捷、更精准、更智能，其业务创新点主要包括：智能的最优参数定义，智能故障预测和定位，智能的资源管理。其技术创新点包括：一是，根据运维数据特色结合具体的运维场景，利用大数据与人工智能技术，自主开发多种基于机器学习的集监控管理和异常告警于一体的智能模型和策略，提升运维效率，解决传统运维方法不能解决的挑战。二是，为提高算法在复杂场景的工程化实现过程中的效率问题，通过智能管理资源池的方法，使得程序并发执行效率更高，资源调配更合理。三是，模型与专家经验相结合，模型参数经过定期训练和优化，已经可以取代部分专家的工作。该金融保险数据中心的智能运维项目已在初期实践中取得了良好的效果。从模型评估来看，对于单指标的时间序列模型，预测值与真实值的RMSE小于0.5%，对于多指标的无监督学习模型，异常检测的准确率约为99%。从应用反馈来看，基于机器学习的智能告警和预警、异常检测分类等获得了用户的一致认可，为系统监控提供了有力支持，多次提前预测故障，有效减少运维开销，提升问题处理的及时性。从推广价值来看，智能运维模型的通用性较为广泛，整体实施框架适用于基础环境、操作系统、数据库、中间件和前端应用等场合，完全覆盖数据中心工作的方方面面。

一、项目建设背景及目标

（一）项目背景
金融企业的IT中心通常是一个是巨大的成本中心，大量设备被采购用以支持业务系统。现阶段大部分传统金融企业的IT工作依赖于人工操作，实效性低且往往伴随操作风险，随着业务的扩张，也带来了越来越繁重的运维压力。
该金融保险数据中心作为一家保险巨头，每年有着千亿级的业务量，数据中心管理了全国的业务系统并负责所有设备的运维工作，这对人员的调配和技能有着极高的要求。随着业务的增长，IT人员的配备已经无法满足当前运维的需要，急需向智能化和自动化转型。

（二）项目目标
为减少居高不下的运维成本，减少IT人员日常繁琐的工作量，提高自动化及智能化运维能力，越来越多的传统企业开始借鉴互联网公司运维经验，例如腾讯织云的一键式运维操作与智能监控，尝试使用大数据和人工智能技术等创新技术，建立智能运维项目研究和实践，用以提高企业IT运维成熟度。一个IT架构越敏捷、 业务响应时间越短的成熟企业，也将获得更强的业务竞争力。
数据是某数据中心最重要的资产之一，除了业务数据，公司也积攒着多年的运维数据，包括基于数据库的结构化数据和系统日志的半结构化数据，这为智能化应用奠定了良好的基础。项目组成员使用机器学习方法对IT运维数据进行了分析及价值挖掘，通过建立时间序列模型、聚类等方法，实现智能监控与告警，推动IT运维平台在智能化发展的道路上更进一步。

（三）项目内容
监控和告警通常是AIOps中首先需要解决的问题，当前的告警机制大多基于单一指标的分布和阈值来判定，误报率非常高，而且在时效上具有一定的延迟性。在传统告警基础上，我们通过引入改良的时间序列模型对单一指标进行预测;引入机器学习的聚类算法解决与多个指标相关联的异常问题，并根据专家经验制定相应的规则抓取异常数据，以此提高异常识别的准确性。同时，将告警规则与预测结果相结合也可以达到预警的效果，提前获知未来可能发生的运维问题不仅为问题排查和应急处理争取到了宝贵的时间，也能避免因IT故障所导致的业务损失。

二、项目主要创新点

（一）基于数据特色定制模型
1. Oracle日志数据
数据库监控平台的日志数据通过间隔固定时间的快照方式被采集，诸如SQL执行时间、CPU时间增量、集群等待时间等反映数据库性能的多项指标按时刻被记录下来。例如那些基于SQL执行语句的结构化数据，具有离散、非时间序列的特性，并且由于执行SQL过程中发生的故障类型不同，为了定位故障原因，需要综合考虑多个具有一定关联性的指标，因此采用较为复杂的含有多个特征的机器学习算法进行异常识别和分类。

2. Zabbix时序数据
Zabbix基于WEB界面提供分布式系统监视，从WEB接口获得的监控数据具有连续、随时间变化和周期的特性，并且对单一的系统性能指标，例如CPU和内存等进行监控和分析，基本可以达到故障识别和类型定位的效果，在此基础上，我们把时间序列模型引入系统性能指标预测中，并对模型适应性加以改良。随着数据的不断更新，优化的时间序列模型可以学习到数据新的时序规律和变化特征，体现出合理的预测对象的变化趋势，相比逻辑回归等模型有着更为突出的表现。

（二）采用多进程轮询机制
告警的时效性在智能运维研究工作中深受关注，单个轻量的算法或模型在复杂场景的工程化实现过程中极可能在时效性上发生改变，达不到预期的告警效果。在数据中心由Zabbix监控的服务器多达上万台，其中约有上千台是需要重点关注的。在使用时间序列模型对系统性能指标进行预测的过程中，随着IP数量的增加，测试服务器所承受的压力也越来越大，导致程序耗时长，并且伴随着阻塞现象的发生，如何在满足分钟级告警需求的同时尽可能提高运算效率成为考验。
项目中，我们通过开辟进程池的方法，设定多个子进程，使得程序能够多进程并发的执行，通过合理分散资源调配资源，保证程序的运算效率。此外，通过建立URL和IP的关联表，便于运维人员对重点关注的系统进行维护，可以减少人工投入和不必要的系统开销。

（三）模型与经验相结合
在对数据库性能异常数据进行识别和检测的时候，我们使用了K-Means方法，该聚类方法最常见的问题是无法确定k值的大小以及如何看待聚类结果。我们采用了对k值进行范围预设的方式，结合两种异常判定假设，将多种聚类结果与Oracle数据库专家进行周期性交流，根据反馈结果对模型参数进行选择和调优，同时形成一部分基于经验的规则。最终将模型与规则相整合，逐步提高异常识别的准确性。

三、项目主要功能介绍

（一）对于单指标的时间序列模型
1. 异常值判断
由于Zabbix数据具有很强的周期性，且在各时刻点CPU和内存的使用率近似服从正态分布，借鉴统计学中的N-sigma原则能够建立数据在各个时刻点的基线以及上下区间，根据系统重要性和管理员对异常的容忍程度，制定诸如数据落在(μ-3σ,μ+3σ)区间外认为是异常点的规则。该规则不仅可以作为实时告警的标准，如果与预测数据相结合还可以给出预警，具有良好的通用性。

2.系统性能指标预测
针对历史数据，通过时间序列模型对其历史轨迹进行学习，预测下一时刻点的系统性能指标，如CPU空闲率和内存空闲率，为运维人员提供有力指导。

3. WEB接口及页面展示
开发RESTful接口供给外部访问，不仅实现了前后端的分离，保证了数据安全，而且由于前端的表现方式具有多样化，无论是移动端的Android或IOS系统，还是PC端的HTML5等均可无差别的请求资源。此外，项目组开发了基于历史数据、预测数据以及告警信息的展示页面功能，实现了分网页的多IP智能展现，具有很好的扩展性和实用性。系统运维人员只需打开监控页面就可以了解系统性能指标的健康状态。

（二）多指标无监督学习
1. 异常检测与识别
基于SQL语句的数据库异常检测的应用场景与对系统特征检测的方法不同，通过挖掘和分析Oracle数据库日志中的多个性能指标，项目组建立了日志数据性能分析模型，对可能发生异常的情况进行智能化检测和识别，并将告警信息发送至各个系统应用管理员用以规范数据库的使用，保障数据库的稳定和高可用。

2. 异常分类与评估
针对已经识别出异常的情况，为了更加明确定位故障类别，项目组通过对各个指标进行综合比较，确定了异常分类的方案。以异常情况对数据库和系统影响程度为依据对告警进行分级，充分利用专家建议调优告警机制。以Oracle专家建议为核心，调整对异常数据的容忍程度，并对预测出的故障给出建议。

四、项目技术方案

（一）建模流程
智能运维项目的建模过程基本遵循了数据处理、特征工程、模型选择、参数调优、模型效果评估五个步骤。数据处理包含数据集成、数据清洗以及数据转换，由于异常数据在样本数据中占比非常低，我们首先制定了一些规则用于过滤绝大部分正常数据，在过滤过程中也会有少量异常数据丢失，经过专家评估丢失的异常数据几乎可以忽略不计。特征工程包括了特征选择和特征构建等，我们通过主成分分析等降为方法对原始35个特征进行了筛选和转化，最终将19个新特征用于模型输入。模型选择和参数调优是同步迭代进行的，我们根据运维数据特性尝试了目前通用性较强的各种异常检测方法，通过统计手段和专家评价进行优化。从项目建立以来，根据建模的需求积累了一定的异常标签数据，这些半监督的数据帮助我们对模型效果做出了初步的评估。

（二）系统运行监控架构
基于系统运行监控架构可以分为3大模块。
一是，模型构建。其中，包括从REST接口获取数据并进行预处理，利用时间序列算法预测CPU和内存空闲率，基于异常判断规则抛出告警信息和预警信息。
二是，WEB接口和网页开发。用户通过访问WEB接口获取数据；网页显示历史数据和预测数据曲线以及告警信息。
三是，多进程。开辟进程池，并发执行程序。

（三）技术框架
该智能运维监控平台的建设与开展在诸多应用场景中进行了结合与思考，智能化实践涉及操作系统、数据库、网络、安全、中间件、ESB、安全网关等各个基础组件。针对数据分析需求，我们利用组件进行多类数据收集，如时序数据、日志数据、类别数据、模型数据等。主要涵盖内容上，时序指标包括交易数据，有交易量、交易失败率、交易准确率等和各类生产运行监控指标（CPU使用率、内存和存储等）。日志数据分别由不同的应用监控系统进行收集，有系统日志、应用日志、数据库日志和网络安全日志等。数据的处理与存储按照其在智能运维监控平台中的用途可划分为短期、中期、长期数据。短期的数据通过流计算、高频批作业等技术，用于监控和告警；中期的数据存储在基于Hadoop的数据湖体系，主要用于智能运维的分析和优化；长期的数据将形成知识库，以此为基础产生诸如一览搜索引擎、智能机器人等智能应用。算法应用方面主要基于单指标、多指标的异常检测和根因定位，根据不同应用场景将多种有监督、无监督算法进行集成来提高智能监控告警的准确性。有监督学习主要涉及时间序列模型、GBDT、Xgboost、LSTM等，无监督学习使用了聚类算法、孤立森林、OneclassSVM、SOM等。智能运维监控平台展现的内容包含服务调用关系、时序指标趋势、系统性能评分、监控异常告警等多维度可定位及展现故障的模块。实现运维智能化是运维工作未来的方向，也是业界目前研究的课题，要实现运维智能化，前提是先要实现运维工作的流程化、标准化、自动化，由于历史的原因，我公司在这方面还不能一步到位的改造完成，但我们可以合理性的规划，前瞻性的布局，通过一段时间的积累和优化，逐步把我公司的信息系统改造成标准化、自动化的模式，为最终的智能化打好基础。

（四）算法要点
1. 时间序列
ARIMA(p,k,q)时间序列模型，是经过k阶差分后的自回归移动平均模型，AR代表p阶自回归过程，MA代表q阶移动平均过程。
时间序列模型假定过去的变化趋势会延续到未来，是连续渐进的变化。

2. 无监督学习
由于数据库性能异常数据缺少专家给定的标签，标记所需要的人工成本较高，因此采用无监督学习对指标进行聚类，共涉及以下两种主要的无监督学习算法：K-Means和OneClassSVM。
(1) K-Means
使用K-Means进行异常检测存在的问题是聚类后异常存在于哪一类中，我们进行了两种判定异常的基本假设：一是，假设正常数据都在某个簇里，但是异常数据不属于任何一个簇；二是，假设正常数据接近其最接近的聚类质心，而异常数据远离聚类质心。
其次是k值的选定，误差平方和（Sum of Squared Error）虽然可以用于度量聚类的效果，SSE的值越小表示数据点更接近于它们的质心，但该指标本身会随着k的增加而减小，实际案例中并不是分的类越多越好。我们采用了对k值进行范围的预设，结合两种异常判定的假设，将聚类结果周期性的征求数据库专家意见，根据这些反馈，对模型结果进行选择和调优。
(2) OneClassSVM
一类支持向量机在无标签的情况下非常适用于进行异常检测，在我们的应用场景中数据库性能异常数据占比也非常小，一类支持向量机在这种正负样本不均衡的情况下，可以避免分类器过于偏向数据量多的样本类别。

五、项目效果

（一）系统运行指标预测效果
基于时间序列模型对系统运行指标的预测结果与实际值趋势相一致，误差分析显示相对误差近似服从N（0,0.052）的正态分布，即相对误差主要集中在0.5%左右，总体预测结果较好。
同时，预测的结果也获得了用户的肯定，该智能化告警功能有效减少了人工监控的工作量。

（二）数据库异常检测效果
针对基于SQL执行语句的数据库性能数据异常检测，项目组实现了使用无监督学习OneClassSVM算法和K-Means模型对性能数据的分类。使用标签均衡数据的分类准确率约为60%。
调整使用K-Means算法的异常假设，假设异常在每类中离质心较远的位置相比假设异常集中在某一类作为异常的判定条件，可提升异常识别的准确率约3.9%。

（三）项目经验与推广价值
一是，需要加强建模人员对数据含义的理解，注重标签数据的积累。由于项目前期缺少数据标签，建模人员与数据库专家或系统信息安全专家理解的数据库性能异常或系统指标异常存在差异。大部分情况下，建模人员只能基于统计学经验对模型效果进行初步评价，无法对建模结果进行真实的准确性评定。为了解决这个问题，一方面，阶段性的模型结果获得了专家逐条评定，另一方面，项目组开始注重异常数据的积累，便于后续模型改善。
二是，时间序列模型的适用性较为广泛。除了在文档中重点介绍的两个应用之外，我们在数据库表空间使用情况的预测、保费预测和交易量预测等推广应用方面也表现出了良好的效果。

（四）遇到的问题与困难
在中心多个智能运维场景的实践中，我们主要遇到过以下两个问题：
一是，大数据量、非标准化的数据分析与处理。在服务器过万级的企业，每天的业务和运维数据都是海量的，每小时就会有TB级别的数据产生，指标选择、采集技术和计算效率决定了监控告警的时效性。要做到对系统或应用分钟级甚至秒级的告警，监控和异常检测需要做到轻量。
二是，多指标、多数据源、复杂场景下的故障根因定位。对于多数据源的数据，首先在采集方面因为各监控应用系统的分割和独立性，采集数据的时间做不到完全统一。其次，在复杂运维场景下，适用于多指标的算法定位问题的准确性普遍不是特别高，单一的算法无法同时满足高准确性和少误报的告警需求，需要将多种算法进行集成，同时通过规则对告警进行收敛，以减少不必要的告警。