银行数据库智能运维平台建设经验

　【摘要】人工智能技术非常适合运维场景，智能运维就是将机器学习的能力利用起来，实现更好的自动化运维，甚至是最终的无人运维。本文介绍了某银行通过数据库智能运维平台实时自动发现异常，定位根因，分析 SQL的实践经验。

　当前智能运维现状

　智能运维（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.异常场景案例

　场景名称

　日志写盘异常

　场景字段名

　logdisk_abnormal

　相关字段

　LOG_DISK_WAITS_TOTAL

　LOG_DISK_WAIT_TIME

　TOTAL_COMMIT_PROC_TIME

　TOTAL_COMMIT_TIME

　解决方案

　当前异常表示数据库写活动日志到磁盘出现异常。

　异常分析：

　1、一种原因是 IO 延时高，需要警惕。建议结合操作系统，存储信息来一起判断。

　2、另一种原因是出现临时大量 INSERT|UPDATE|DELETE操作，写日志成为瓶颈。可以参考当前时间的 ROWS_MODIFIED，ROWS_DELETED，ROWS_INSERTED，ROWS_UPDATED 判断是否发生突变。

　解决方案：

　1、找到写数据的原因，分析是否是正常业务。

　2、如果伴随着 LOG_BUFFER_WAIT_TIME，NUM_LOG_BUFFER_FULL 异常，可以考虑增加数据库参数 Logbufsz 的设置。

　3、 排除是否是磁盘 IO 缓慢原因，如有问题请联系系统组分析解决。

　基于数据分析和经验总结，我们积累了二十多个场景，在分析异常的时候，根据指标关联场景，直接形成命中异常场景的分析告警，并且提示可能的问题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 分钟定位分析问题，提高的效率还是非常可观的。

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