智能运维现状

智能运维（AIOps）是将人工智能应用于运维领域，基于机器学习的强大能力，学习海量运维数据的规则，挖掘数据的内在价值，为运维提供更可靠的决策依据。

智能运维的场景包括但不限于：故障发现，故障定位，故障分析，故障恢复，事件关联分析，日志检测，故障预测，容量预测，智能交互，专家系统等等。

智能运维是当前比较炙手可热的话题。清华裴丹教授将2018年称作AIOps在中国落地的元年。当年确实有不少互联网企业和金融企业落地一些AIOps项目。而2019年，随着技术的成熟，落地案例也越来越多。尤其是在2019年初，人行以及各大银行都发文阐述支持AIOps方向。民生银行的AIOps发展落地也是从2018年开始，在运维各个环节全面开花。数据库智能运维平台是其中的一个细分项目。

智能运维能在当前迅速发展和落地，与当前技术发展背景息息相关。一方面是大数据技术的成熟应用，一方面是人工智能算法的蓬勃发展。最后切合运维中需要解决和提高的各类场景，智能运维是传统运维强有力的补充和升华。

为什么要做智能运维

人工智能技术发展到今天，在计算机视觉，自然语言处理，智能机器人，专家系统，智能推荐等领域得到了普遍应用。然而在运维领域，人工智能还属于开发实践阶段。人工智能核心是通过运用机器学习的技术来实现分析和决策。

机器学习技术，包含深度学习，强化学习等方向，最核心能力是回归和分类。回归能力其实也就是预测能力，例如判断房价。分类能力也就是决策能力，例如识别图像种类。几乎所有的人工智能应用场景都是基于这两种能力。就像在计算机世界只有0和1一样。在人工智能领域，就是回归和分类。

系统运维其实也就是在运维中判断和决策。因此人工智能技术非常适合运维场景。智能运维，就是将机器学习的能力利用起来，实现更好的自动化运维，甚至是最终的无人运维。

数据库运维

当前主流数据库运维模式还是基于“专家规则”的经验运维加上自动化运维的方法。

图1.海量数据VS专家运维模式

然而面对越来越多的系统产生的海量运维数据，传统数据库运维遇到一些痛点：

(1) 基于“专家规则”的经验运维场景覆盖面小。一方面人的经验有限，只能定义有限场景。另一方面每套数据库都有其独特性，统一规则运维不能体现差异性，单独运维成本又太高。

(2) 数据库运维产生的海量数据只要很少部分被管理起来，大量数据价值有待挖掘。这些运维数据潜在的规律和关系特征，是高效运维的基础。

民生银行 数据库 智能运维 系统 属于智能运维的细分场景之一。 通过建设机器学习问题分析平台，实现基于机器学习模型的异常检测 ， 根因定位 和问题 管理 。这是对“ 专家 规则”模式的补充，解决 海量数据运维痛点， 提升现有运维能力。

当前基于Db2数据库的智能运维场景已经上线，后续将接入更多的数据库产品和其他产品，并且开发更多的智能运维场景。

数据库智能运维实践

数据库智能运维系统当前实现了一个小目标：Db2数据库的问题实时检测和智能分析。为了实现这个小目标和以后更多的目标，我们首先搭建了一个机器学习平台。当前最流行的机器学习编程语言是python语言，丰富的机器学习插件库让python成为当前最火的数据分析工具。Sklearn，tenserflow，pytorch，pandas等等各类机器库和深度学习框架，都提供了python接口。

图2.机器学习平台

在这个机器学习平台里，运行于python环境的机器学习算法是核心。为了保障大量数据的实时处理，我们采用了kafka并行消息中间件，基于K8S容器平台，动态部署各类计算处理模块。Python处理模块采用了celery并行框架，解决Python多任务处理的性能瓶颈。实时计算模块也充分利用redis缓存，提高运行速度。

前面说到我们实现了一个小目标，那么Db2数据库的问题实时检测和智能分析到底解决了什么问题呢？大家在数据库运维过程中经常遇到的问题就是数据库出现异常导致应用系统受到影响。第一步，系统管理员需要确定是数据库发生了异常。这个通常可以通过一些基于规则的监控来发现，但是这些监控不一定能覆盖所有异常场景。所以更多时候是经验推测数据库发生了异常，需要检查确定。第二步，检查数据库。检查数据库有很多工具，每个工具的信息量也都很大。有经验的数据库管理员会关注一些核心指标，一步一步排查。如果问题还存在，通过抓取一些有用的实时信息，还是可能分析出问题来的，这个需要经验和时间。最后，在确认数据库出现问题的情况下需要定位是什么SQL导致的，然后采用杀SQL或者是优化SQL等具体解决方案。这个过程非常耗时，并且存在信息采集不足，分析不到位等不确定因素。

我们实现的小目标是全管全控数据库几百项性能指标，实时监测这些指标是否发生异常，展现异常指标点关系图，判断是否命中已知异常场景，定位与监控指标相关的SQL，分析SQL的性能问题。简单来说就是实时自动发现异常，定位根因，分析SQL。

洞察整体运行情况

数据库智能运维系统监控几百套数据库，每个数据库几百个性能指标。因此在实时监控页面我们按照异常指标数量，总CPU消耗，总执行时间三个核心维度做了汇总和排行。下图左边是实时汇总数据和历史变化情况。右边是选定时间点的TOP数据库。

图3.监控实时排行

指定时间范围说明

(1) 查询的时间范围在1天以内，数据以十分钟节点返回；

(2) 查询时间范围在1至7天内，数据以小时为时间节点返回；

(3) 查询时间范围在大于7天，数据以天为时间节点返回数据。

折线部分部分说明

(1) TOTAL_PREDICTS折线图表示总的异常数量在指定时间范围内变化，右边横向柱状图表示选中时刻，基于预测值TOP 10系统排行；

(2) TOTAL_CPU_TIME折线图表示总的CPU时间在指定范围内变化，右边横向柱状图表示选中时刻，基于CPU总时间TOP 10系统排行；

(3) TOTAL_RQST_TIME折线图表示总的请求时间在指定范围内的变化，右边横向柱状图表示选中时刻，基于总请求时间TOP 10系统排行。

上图折线图中灰色直线标记选中的时刻，横向柱状图中可以点击对应系统进入该系统的详情页面。

异常定位和分析

在系统详情页面，我们能查看单个系统在一段时间内的异常指标数量曲线图。

图4.系统详情

在这个页面里先从左上曲线图找到异常发生的时间点，右上图查看这个时间点的异常指标信息。点击异常指标，左下曲线图会展示所选指标的历史变化，右下图展示对当前指标贡献最高的SQL排行。简单总结就是查看异常信息，定位TOP SQL。

异常检测算法

因为数据库多，指标多，要做到这么多的指标监控，还得适应每个数据库的独特性，所以我们需要为每个系统的每个指标单独训练异常检测模型。大量的运维数据是没有办法进行人工标注异常的。因此当前异常检测算法只能选择机器学习里的无监督学习算法。

图5.无监督集成学习

因为数据库的大部分指标没有明显的时序特征。因此系统设计之初就排除了基于时间序列的各类算法模型。最终选择了三种不同无监督学习算法并构成集成学习算法。这三种算法分别是孤立森林、DBSCAN和3SIGMA。最终基于这三种算法的综合投票确定计算结果。为了提高训练性能，我们重写了这部分算法，采用算法的思想，摒弃直接使用已有的算法模型。为了提高实时监测性能，我们也是将训练的算法模型最终转换为正常阈值范围上下限，实时数据基于范围直接检测结果，非常高效，节省计算时间和资源。

指标关系模型

除了将指标数据计算出检测结果，我们还需要比较好的方式来展现异常指标的位置。这里不仅需要产品的知识，还需要结合数据的想关性分析结果。图6里的指标层次结构图就是基于数据和专业知识的结合总结出来的。

图6.指标层次结构图

指标关系不仅仅能够用来定位和展示异常指标的位置，还可以在此基础上实现关系异常检测，也就是多指标异常检测。首先找出来指标之间的关系并且量化，然后检测数据是否偏离这种关系，做到关系的异常检测。这个功能已经开发实现，暂时还没有上线。

一键智能分析

其实到这一步已经完成异常分析和问题SQL定位了。但是Db2的监控指标有400多个，这些指标对于非专业人士来说太难理解了。而且同一时间可能会出现多个指标发生异常，理解这些指标的含义和一个个查找根源SQL是比较困难的，尤其是对于非专家使用者来说。

我们解决这个问题的方法基于上面的指标关系分析结果，将相关的指标聚合成一个个异常场景。这里举个简单的例子。

表格1.异常场景案例

基于数据分析和经验总结，我们积累了而是多个场景，在分析异常的时候，根据指标关联场景，直接形成命中异常场景的分析告警，并且提示可能的问题SQL。场景并不全面，还有很多指标没有场景覆盖，因此我们还加入了智能分析功能，基于所有异常指标取top SQL,然后对SQL聚合分析命中的指标数量进行排序，最终分析出来是哪个SQL命中的异常指标最多。

图6中加入了一键智能分析按钮，点击获取当前命中场景和top SQL， 生成所选时刻基于异常指标字段生成智能分析报告，报告内容包含系统信息和下面几张图包含的信息。

图7.命中的异常指标

展示当前异常指标命中的场景，用户可根据当前场景信息进行问题分析。

图8.命中的异常场景

智能分析信息展示当前异常“贡献值”最高的SQL。

图9.TOP SQL

现在找到了问题SQL，但是这还不能结束，我们还需要分析SQL是否真的有问题，它的性能消耗在什么地方。

SQL性能分析

因此我们在找到SQL的基础上，还做出了SQL性能分析页面。 SQL详情页面如下图所示：

(1) “SQL信息”: 展示本条SQL文本的详细信息。

(2) “条件查询栏”: 选定时间范围和DB2_SQLSNAP指标，点击确定后其数据变化会展示在“SQL指标”折线图中；

(3) “SQL指标”: 展示选择的指标在指定查询时间段内的变化折线，点击某时刻，“SQL指标排行 ” 和“SQL时间分布图”都会刷新展示选中时刻数据。如果该指标变化较大，说明该时刻有SQL引起指标字段异常。

(4) “SQL指标排行”: 展示选定时刻TOPSQL排行，点击对应SQL会刷新至此条SQL的详情页面。

(5) “SQL执行时间”: 展示本条SQL执行时间的变化折线。

(6) “SQL时间分布图”:展示本条SQL执行时间的具体组成，点击非others指标，其值会在“SQL执行时间”柱状图上直观的展示时间消耗指标与总执行时间的占比。

在这个页面里我们可以查看SQL指标的历史变化，能够知道是否在这个时间点发生了指标突变。SQL的执行时间分布饼图能直观分析SQL运行时间消耗在什么地方。这些地方就是我们需要优化的方向。

总结

当前系统已经接入了 400 多套数据库系统，每个数据库有 400 多指标被监控。这些海量的系统和指标数据是无法人力运维的。异常检测阈值时通过无监督学习方法，从历史数据找到规律，无需人为标注，做到单系统单指标的阈值定制化。这两点极大减少了人力运维成本。数据库发生故障的时候，相关指标实时检测出异常，自动分析根因并关联问题 SQL ，迅速定位问题并解决问题。降低故障修复时间，减少损失。这个过程中不仅仅是故障得到了控制，而机器学习出来的规则也让运维人员受益良多，更理解数据库内部知识，更了解系统运行状态，从而提高系统运维质量。

从当前上线的效果来看，实际生产中发生几次数据库出问题，通过数据库智能运维系统来分析问题，从几个小时的专家分析定位时间，到系统里1分钟定位分析问题，提高的效率还是非常可观的。

数据库智能运维的实践还在继续，后续异常预测，容量预测，日志智能分析，智能告警等应用场景已经在开发中。