从1.0到2.0：民生银行数据库智能运维的探索升级与实践

从1.0到2.0：民生银行数据库智能运维的探索升级与实践

本文根据孔再华老师在〖deeplus直播：金融业数据库转型与国产化改造〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）

孔再华

民生银行 数据库专家

• 民生银行资深数据库专家，具有丰富的数据库环境问题诊断和性能调优经验，尤其擅长同城双活、集群、多分区、分布式等项目咨询和实施。

• 现致力于数据库分布式架构建设和智能运维（AIOps），建设了民生银行基础软件智能运维平台，实现基础软硬件的产品深度智能运维，引导传统运维向智能运维发展。

今天我给大家带来的主题是民生银行数据库的智能运维实践。之前我在 dbaplus社群曾经给大家分享过一次，那个当做是1.0的版本《不谈宽泛的智能运维，聊聊我在用的异常检测核心算法》。而这次我又补充了很多新的内容，所以作为智能运维2.0的版本给大家分享。

一、基础软件智能运维平台

首先介绍一下我做的这样一个智能运维平台，在这个智能运维平台里面，大致分为这样4个部分：

1、运维数据中台

首先，大家知道关于智能运维，我们其实最看重的还是数据质量。作为一个运维大数据的分析平台，我们需要对运维大数据做一些分类，把不同类型的数据都汇总到一个运维数据中台里面去。

我们可以采用不同的技术手段来存放这些数据，并通过统一的消费来做智能分析。首先需要一个比较夯实的数据基础，所以运维数据中台里面可能需要分这样几类数据：

一种是监控数据。监控数据包括性能数据、状态数据。监控数据的来源非常多，可能我们都有这种集中监控平台，它会去采集一些各个软硬件产品比较核心的性能指标。有些可能还有其他各种各样的平台，里面都会放着跟业务、交易、产品、软件、硬件相关的信息和日志。这些数据我们要想办法把它们集中到一起，进行统一的消费。

还有一种数据是所谓的元数据。或者也可以看作是像CMDB的一个关系类的数据。这种关系类的数据它也是一样散布在很多不同的地方。CMDB可能是一个比较集中的、管理着所有的这些关系数据的地方，它只是汇总了一部分，还有很多其他的系统也包含相关的数据，并且有很多关系数据是要经过分析才能得出来的。所以关系数据可能不仅仅是我们已知的一些关系，还是我们总结出来的一些关系。

最后一部分数据是知识库相关的数据，比如说我们建的问题库、知识库等等，它可能包含了你运维过程中总结的一些知识，或者是跟产品相关的一些知识。而这些数据基本上就是我们需要去关注和处理的这种运维大数据。

2、实时计算引擎

当我们拥有这些数据之后，会在上层建一个实时的计算引擎。这个实时计算引擎主要是做实时的数据分析以及历史的数据分析。

3、智能算法库

再上一层相当于构建了一套智能算法库。智能算法库里面在不停地补充各种各样的智能场景。这些智能算法库，我们的想法是让它通用一些，能够采用一些通用的方法解决比较个性的一些问题。

4、智能运维服务

最后是在智能算法库、在大数据的基础上封装一些智能运维服务。这些智能运维服务，通常是深度分析软硬件的产品的运行状态、产品的问题发现，根因分析等等。

在这个基础上，我们甚至还可以再有一些自助服务。比如说可能不在我们采集的产品、数据上面，还有一些其他系统自己的数据，它们也希望用我们的智能算法和一些服务。那它们可以通过我们比较通用的接口来推动数据，获取这个服务所取得的信息。

为了做这件事情，我在这几年构建了这样一个基础软件智能运维平台。针对这些智能场景，这个运维平台里面主要分为这样几个部分：

第一个是产品的深度智能运维。这里面内容比较多，比方说我们会围绕某一个数据库的产品，对它各个智能场景、组件形成相关的服务。

除此之外，我们还会跟监控告警那边一块儿去合作，通过和集中监控打通，然后通过智能运维服务，向集中监控提供更多、更准确性的告警服务。

二、数据库产品深度运维1.0

我们先回顾一下去年曾经给大家分享过的，关于智能运维的1.0的版本。在1.0的版本里，我主要给大家介绍过三种比较重要的智能场景：

一种是做异常检测，在做完异常检测的基础上，我们再做一定的根因分析，通过根因分析找到问题的根因所在。

有了异常检测和根因分析之后，就可以去通过创造一些所谓的智能场景，通过场景告警的方式，收敛这些告警和根因分析，给普通用户或者专业的DBA提供决策相关的信息。

1、异常检测

首先说一下异常检测。大家想想：我为什么要做这样一个异常检测？当我们做监控的时候，可能只需要对一些指标设置一定的阈值，我就可以说我关于指标的异常检测已经搞定了。这也是我们把一些核心指标提供给监控系统，然后由监控系统帮我们告警的一个方法。

但事实上，如果大家在平时使用的过程中发现：监控确实告警了。而它告完之后，你拿着它的告警去查看你的数据库。想要去分析更深层次的问题时就会很困难。因为可能告警出来的只是结果，但是真正的原因、真正的告警的细节的点在什么地方呢？其实大家并不知道。我们知道，像数据库里面其实有很多很多的性能数据，它可能在不同的层次、不同的组件上，都有相关的性能数据的采集。如果这部分内容不被利用起来，对于我们来讲这个数据库就是一个黑盒。

但是如果我们能够把这些所有的指标，比方说可能有成千上百的这种指标，全部都监控起来，并且不通过人为的方式去进行判断，而是通过机器的智能算法，去寻找这些指标运行有异常的情况。那这样我在问题点的时候能够看到：到底是什么地方发生异常了？那我是不是就可以找到更细的那个点，并且知道是什么原因。

所以在过去的异常检测里，我们做了针对全时段和分时段的异常检测，就像这张图右边的两张小图：

右上角的这张是全时段的异常检测，也就是说，我会参考整个过去的时间段里面所有的指标运行情况，来判断：有没有可能，现在运行的跟以前所有的时间都大不相同？

还有一种就是：比如说我对交易的类型，我的数据库它的运行状态是有一定的周期性的。无论是工作日也好，还是日间和夜间不同的工作负载也好，我可能需要不同的更细力度的检测才可以。那这样也没问题，我们可以通过分时段，将整个的阈值线做一个分时段的设置。

2、根因分析

在做完异常检测之后，我们还需要找到什么？我们还需要找到问题的根因SQL。我们可以基于日常的异常检测，去找到这个点。这个点它如果有异常了，那到底是哪个SQL导致的呢？我们可以基于这个点和SQL的一些指标进行排序，然后得到对这个点的贡献最大的这些 SQL。

当我找到这个SQL之后，我就可以去看这个SQL的历史执行情况。第一，我可以看这个SQL当前的执行时间分布图。它到底是在什么地方花的时间比较多？然后我还要去看 SQL的历史执行情况。它之前也跑了这么多次，也是在这样的一些时间点运行，那它整个的响应时间、整个的执行时间有没有什么太大的变化？

通过这种和历史的对比、和当前的细致的分析，我们就能够把根因分析做得非常好！

3、智能场景

最后是智能场景。我刚刚说了，当你真的把所有的、1000多个指标都监控起来，这些指标可能会有很多是相关联的，它们可能都喜欢一块儿出现运行不一样的情况。

在对历史的这种运行不一样的情况进行分析之后，我们可以把相关的指标组合在一起。组合在一起之后我可以告诉说：如果这一类的指标发生异常，它其实说明的是一个什么样的场景。

像这个例子里面，我跟日志写盘相关的有哪些指标？当这些指标发生异常的时候，那其实就是一个写盘的异常。那这个写盘的异常一般是什么原因导致的？有什么样的解决办法？那我把这些东西作为智能场景总结完之后，基本上有问题发生的时候，通过一键分析就可以告诉你：在当前，你应该去发现这个数据库是发生什么问题？然后怎么样去解决。

在去年做1.0的介绍的时候，可能还花了很多时间去介绍一些智能运维的算法，怎么样去做这些工作？但我觉得，像这些智能运维的算法，其实跟我们用的这些Java语言、Python语言一样，大家只要说思路上知道怎么去做这个东西，其实用什么样的算法都是好算法。所以今天我介绍的时候可能就不太注重说算法的研究，而是给大家提供一些做智能运维的思路。

三、数据库产品深度运维2.0

现在正式开始介绍所谓的数据库的智能运维2.0。2.0版本我大致会介绍这样几个新的内容：系统画像、容量预测和日志检测。

1、系统画像

对于系统画像这个东西我们先想想。我们要做系统画像，那我们平时认识到的最多的画像是什么？其实是客户的画像、用户的画像。对于这些客户的画像、用户的画像，我们可以随便上网搜一些图。那我自己就去搜了一些图，这些图片都是网络上搜过来的：

大家在做用户的行为分析或者用户的画像分析时。可能会看用户他的年龄、性别、收入、支出、所在的地理位置，还有他平时喜欢看的剧、喜欢听的歌、喜欢做什么样的事情、喜欢购买什么样的东西等等。

这些画像其实是从非常多的维度去描述一个人的特点。后续在有了这个画像的基础上，各种推荐系统就上线了。你如果是个卖东西的，你会说，我看这个画像，这个人我给他推荐什么样的东西他才会去购买？而有些东西可能不应该推给他，因为那只会让他觉得烦。

所以用户的画像现在已经是一个非常流行的东西，对于系统画像我们也是一样。可能大家现在做的不太多。因为大家会觉得：做系统画像干什么？但我如果把这个图画出来的话，大家应该会有一定的印象。因为当我想了解一个数据库的时候，我其实是想了解它平时的TPS的情况、CPU的使用情况、内存的使用情况、硬盘的使用情况等等。但我之前可能没想到过把这些东西汇总到一起，作为一个系统画像来看待。

我事实上是把这个东西作为系统画像给大家展示一遍。比如我将数据库的一些指标汇总列成这样一个主要的6大维度：

在这6大维度里面可能是一些比较细节的指标。在这些指标的基础上，我们可以做一些聚类，做一些整体的、跟其他的数据库的横比。因为毕竟在银行或者是在其他的金融行业，大家其实并不缺数据，对吧？

就像我们卖衣服要把人的衣服分成 XL、XXL、XXXL等情况，对数据库我们也可以一样。比如说按照这些数据库的CPU的使用情况，把它们分为好几个档。当你分完好几个档之后，基本上你只要告诉别人，你的数据库是在某某档上，他立马就会对这个数据库有一定的了解。

比如我说这个人是穿XXXL的，你立刻就能想到他是一个高大的胖子，对吧？

通过这种方式，把这个数据库描述起来之后，我就可以知道它这个数据库在整个企业的数据库里面，是运行在怎样一个level里面，并且我也是基于不同的维度去做的。

通过这种系统画像，你可以很快地了解这个数据库的特征。

在这个系统画像的基础上，我们还会做一定深度的运维。比如我们可以通过判断数据库运行的基线的趋势变化，像前面这张图，我们可以看到那个图里面，本次和上次曾经在某一个维度上发生了一定的变化，这种变化通常是比较大的。

就像你从XL的码数穿到XXL，要不就是你长个了，要不就是你增肥了。这都是一些需要去关注的事情，这是第一点。

第二点，我可以通过对这些画像里面比较重要的指标的基线，做一定的资源分析和调度。比如说这个CPU用的比较多的，或者用的比较少的，它们适合用什么样的硬件环境去运行？

这就涉及到了后面：我们要基于画像的标签维度去进行资源的管理。像现在我们都用虚拟机、容器云等。那在这些云环境里面，动态调度是非常有用的一种方式，能够充分地利用你的资源。

如果有我的画像和我画像基线里面的这些数据的话，我就可以知道，某一些数据库的CPU和另外一些数据库的CPU，它们彼此之间的运行时间是互补的，有的白天忙，有的晚上忙。而在它们互补的情况下将它们凑到一起去，可能会充分地利用宿主机的 CPU。我们可以通过这种方式来做一些瓶颈分析和动态调度。

因为时间的关系，我不会把某一个功能里面的点讲得特别细致，但是我希望，通过跟大家探讨这种做法和它已经能够产生的效益，能够给大家一些做相关工作的思路。

2、容量预测

1）容量预测需求：

解决空间类容量的预测需求，先一步解决容量问题，避免出现容量事故。

实现性能容量类预测目标，适用于资源预测告警，资源调度等运维场景。

2）总体算法思路：

自主研发时序预测算法，分解数据的整体偏移性，周期性，趋势性和误差，从而实现稳定可靠的时序预测功能。（现有的算法验证效果较差，需要综合各类算法的思想自研。）

稀疏点与密集点需要采用不同的预测模型，需要兼顾预测准确性和训练预测性能。

3）容量报告和告警：

提升系统容量报告信息量，提供预测内容供参考分析。

实现容量类预测告警，提前发现容量瓶颈。

我们来看下面这几张图：

在这4个小图里面，你会看到，右边的这两张小图，在某个时间点都出现了一个突然的下降。而在突然下降之后，后续是比较平稳的。这种突然下降可能是因为我解决了一个问题。假如它是CPU，那我可能杀掉了一个比较耗CPU的进程。我觉得它这个进程没用，那我干掉它以后，就再也不会有这部分加成了。

所以去掉它之后，整个曲线后面的预测会平稳一些。否则它会觉得：你的趋势是从一个很高的点往低的点走，那我后面在预测的时候它也会往低的点走。所以这部分加成去掉之后，对它整个的平稳性会有很高的帮助。

然后还有周期性。像左下角的这个图，其实它是很明显有一定的周期性的。周期性里面红色的部分是真实的点，黑色的则是我们的预测的点。可以看到，我们预测的点和红色的点其实差异并不是很大。所以总体来看，如果在周期性很明显的情况下，我们还是能够得到比较准确的预测的。

我们再看右下角的这张图。它其实整个的数据是有一定的趋势性的，它是在往上走。虽然它在前面曾经掉下来过，但我通过第一步的偏移性解决之后，最后在计算整体的趋势性的情况下，它也一样能够拟合它真正的趋势。

做完容量预测之后，我们拿一些数据库的表空间、数据库的大小还有大表来做检测：

在做这个检测的时候，除了上文对未来的预测，同时我们也能对所谓的突变和增长做一些判断，把这些发生突变和发生增长很快的对象都拎出来，作为告警发给负责人。那负责人就知道这个问题，知道他的表一直在不停地变大，或者是近期突然变得很大，那可能就需要去关心一下。

这就是关于容量预测这块的内容。后面再给大家讲一下日志检测。

3、日志检测

日志检测我们首先从出发点上去看：我们为什么要做日志检测？我们怎样才能把它给做好？大家以前在发现产品问题的时候，你们是怎么办的？

你们想到的可能是，当我发现问题了以后，我需要去分析它的原因；然后寻求官方支持；再按照官方要求收集数据，日志；拿到这些之后他会去分析。而很多时候厂家会告诉你：“这个问题以前已经碰到过了，这是我们一个case，并且已经在官方发布了一个文档，你们按照这个文档的步骤去进行配置解决，事情就搞定了。”

整个的过程看起来，是我们日常处理过程中做的最多的地方。但我们深思一下，在整个过程里有没有问题？这个时间是不是太久了？来来回回的沟通成本和解决问题的时间成本是不是太长了？尤其是这些官方已经知道的问题，我们还需要把流程再走一遍，这简直就是浪费嘛！

所以我们想到要做日志检测，这样如果我们在日志里面发现问题，当时立刻发现，立刻解决，那是不是要更快一些，更好一些？我们要把这种被动地分析问题变为主动地发现问题。

那主动发现问题要怎么做呢？

• 建立产品问题库：包括通过爬虫获取官网问题和自建问题。

• 建立产品日志白名单库：对于检测出来的无效问题，加入白名单，减少无效告警。

• 日志实时检测：实时告警，展示命中的已知问题。

• 问题库搜索：根据贴入的关键字或者日志查找最可能遇到的问题。

总体算法思路：

基于机器学习自然语言处理的能力，将文本处理成向量，然后基于文本相似度来计算是否命中已知问题。

当前困难与解决思路：

• 问题1：日志片段计算出来的词向量过少

思路：通过命中词多少或者向量总和大小设限，过滤日志。

• 问题2：日志命中非关联问题。

思路：主要原因是问题库中的问题特征可能包含很多日志片段，当前日志命中的是非关键片段，导致误报。

一种方法是健全白名单库，将非关键片段放入白名单。另外一种方法是健全问题特征，将关键片段标注为问题特征。

• 问题3：日志命中非关键问题。

思路：部分问题是可忽略的，不需要告警。这部分问题可标注为白名单。

• 问题4：新问题不断产生，模型滞后。

思路：定期爬取新问题和定期重新训练更新模型。

我们来看一下效果，我这边是列了一个比较简单的例子：

比如在这段日志内容里面，最上面有这样一串日志，模型会在你的问题库和日志内容里面都去寻找，把其中的一些关键词给列出来，并且把它的权重也列出来。那会发现说：这些关键词很可能是一个消息码，这个码如果对上的话那基本上就是一回事了。如果这些码对得上的时候，你基本上就能发现它们两个确实是很相关的。而最终，根本原因是不是这个还需要人为再判断一下。

但总体来说，它立刻就从你的已知的问题库里面，找到了跟这条日志相关的问题，这样就能达到一个很好的命中，然后自己去判断！

对于日志检测其实还有一定的改进的空间。

• 自建问题库的价值更高，需要促进DBA们努力。

• 连续的日志更容易精确反应问题，可以尝试对连续日志的分析检测。

• 当前流行的转换日志文本为日志模板，再通过计算频率转化为数值分析问题模式，可以参考和研究是否具备可行性和可用性。

总体来说优化是无止境的，我们如果有想法、有思路、有时间的话，可以去把这些东西做得更好！

四、懂AIOps的DBA

最后跟大家探讨一下智能运维和DBA的关系。

我觉得我们DBA的运维工作也是一样，分为这样三个阶段：

第一个阶段是几年前，我们大家都是这种所谓的人力的经验运维。在这个阶段我们DBA都忙着做些手工的操作，装机、变更、监控、应急、巡检、调优等等。

现在大部分的企业其实都实现了所谓的工具运维，也就是自动化运维。自动化运维就是把以前我们重复的东西都扔到了工具里，让它去标准化、工具化。这样我们的工作就会变得更快一些。当然有一些任务可能工具搞不定，比如像应急、调优。对于工具来说，它不是标准化的东西，所以这还是需要更多地考验DBA的能力。我觉得我们现在的DBA还算是比较幸福的一代，只需要去做应急和调优就可以了。

但未来是属于智能化的时代。智能化的时代出现在两方面的提升，一方面，它大幅地提升了运维的质量；另一方面，其实也是提升了DBA的知识宽度和深度。比如说到了智能时代，都已经AI了，那还需要DBA干什么？

那DBA要干什么呢？DBA要做一个懂AI的DBA，知道要怎样去利用这些AI的技术来提升自己的运维能力。这件事情是要DBA去做的，而不是靠AI来做。因为AI如果你什么都不告诉它的话，它就是一个白痴。

所以我们DBA需要去想办法使用这些AI的技术，为AI的技术铺平道路，给AI的技术提供数据，建立相关的需求场景，帮助AI实现运维。

 AI实现完了之后，同时AI也会在整个数据分析里面获取到更多知识、更多经验。再把这些东西反馈给DBA。DBA拿到这些东西之后会觉得：我以前怎么没有发现这个？或者，我以前怎么还不知道这个？

那你现在已经从原来的"救火队员"，变成一个更懂你的数据库的DBA了，所以你的经验和能力会更上一层。

那么我们把DBA的工作和 AI的工作放在一起，从底向上怎样去实现运维的提升？

DBA需要去准备数据，提供给AIOPS来分析；

DBA还需要去创造智能模型，这些智能模型可能是DBA创造的，也可能是一些成型的，或者是行业里面其他的DBA发现的，又或者是其他厂家发现的。总体来说，这些智能模型是通过DBA的创新思路一点点总结起来的，并且一定能够去泛化开来。AI拿到模型之后，它会得出一些相关的结论；

这些结论会反馈给DBA，然后DBA从AI给的模型结果里面判断，AI是对的还是错的？大部分情况下它可能是对的，在对的情况下很简单，照着AI给的办法去做就可以了；如果它是错的，那我就需要思考：是不是还有什么地方做的不到位？为什么让它得出了这样错误的结论？是我以前的哪部分工作没做好？你需要去往前分析，让它做的更好一点，帮助AI做出更精准的决策。

所以AI能够辅助决策，而DBA就基于这些决策的动作去做你的决策。比如AI告诉你说：你这是一个日志写得很慢的问题，需要去调整一些相关的参数。那DBA现在就是很自动地就拿着这些方法去试一遍，看看是不是可以把这个问题解决。

当你发现你的AI做的挺好，每次决策大部分情况下都是对的；或者对于某一种类型基本上是百分百没问题。这种情况下就可以提升到下一个阶段，就是故障的自愈。这就不需要AI来辅助决策了。AI可以把这些列出来的决策作为一个固定的决策，自己发现、判断之后自己去做，当AI做完了之后，就相当于实现了故障自愈，因为这里面已经不需要DBA的参与了。

故障自愈就是AIOPS下一步的工作。DBA就拿着它的故障自愈和之前的一些告警信息等等，做一定的复盘和优化。这些复盘和优化，是有AI的数据基础和自己的经验基础的，做的这些事情，比现在没有AI的情况下其实要准确很多。

那最终：自动驾驶。如果我们通过复盘优化，通过以往攒的经验，将这个方面的东西都做到极致的情况下，我们是不是可以实现自动驾驶？放心地把故障的自愈、调配资源或各方面的任务都扔给 AI来做。让AI自己在整个云化的环境里面去控制这些东西。这是我们的终极目标。

今天的分享就到这里，其实我今天最主要是跟大家分享一定的思路，也希望大家能够将你们的、比较新颖的思路来跟我一起探讨！

获取本期PPT，请添加群秘微信号：dbachen

↓点这里可回看本期直播

阅读原文