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

孔再华

民生银行 数据库专家

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）容量预测需求：

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

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

2）总体算法思路：

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

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

3）容量报告和告警：

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

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

我们来看下面这几张图：

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

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

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

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

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

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

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

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

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

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

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

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