原创智能优化,原创度检查,一键采集,文章组合(民生*敏*感*词*库转型与国产化改造〗线上分享演讲内容整理)

　　原创智能优化,原创度检查,一键采集,文章组合(民生*敏*感*词*库转型与国产化改造〗线上分享演讲内容整理)

　　本文基于孔再华老师在【深加直播：金融行业数据库转型与本地化转型】上分享的在线演讲内容。（文末有回放方式，不要错过）

　　

　　

　　孔再华

　　民生*敏*感*词*库专家

　　今天给大家带来的话题是民生*敏*感*词*库智能化运维实践。之前在dbaplus社区和大家分享过一次。它被认为是1.0的版本。而这次我又增加了很多新的内容，所以作为智能运维的版本分享给大家2.0。

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

　　首先介绍一下我做的智能运维平台。在这个智能运维平台中，大致分为四个部分：

　　

　　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.Version 0 我大概介绍几个新的内容：系统画像、容量预测和日志检测。

　　

　　1、系统画像

　　我们先来想想系统画像。我们想做一个系统的人像，那么我们通常最认可什么样的人像呢？其实就是客户的画像，用户的画像。对于这些客户和用户的画像，我们可以在网上搜索图片。然后我自己搜索了一些图片，这些图片都是从网上搜索的：

　　

　　大家都在做用户行为分析或者用户画像分析。这可能取决于用户的年龄、性别、收入、支出、地理位置，以及他喜欢看的剧、他喜欢听的歌曲、他喜欢做什么样的事情、他喜欢什么样的事情买，等等。

　　这些肖像实际上是从多个维度描述了一个人的特征。后来在这个画像的基础上，推出了各种推荐系统。如果你是卖家，你会说，我看这幅画像，我推荐给这个人什么样的东西，他会买吗？而有些事情，不一定要推给他，因为那只会惹恼他。

　　所以用户画像现在是很流行的东西，我们对系统画像也是一样。也许你现在没有做太多。因为大家会想：系统画像你是做什么的？但是如果我把这张图画出来，大家应该会有一定的印象吧。因为当我想了解一个数据库的时候，其实是想知道它平时的TPS情况，CPU使用率，内存使用率，硬盘使用率等等。但我可能没有想过把这些东西放在一起，把它们当作一个系统的画像。

　　我其实是把这东西当成系统画像给大家看的。比如我把数据库的一些指标总结成这样一个主要的六个维度：

　　

　　这六个维度可能还有一些更详细的指标。在这些指标的基础上，我们可以进行一些聚类，并与其他数据库进行一些整体比较。因为毕竟在银行或其他金融行业，不缺数据，对吧？

　　就像我们卖衣服的时候，需要把人的衣服分成XL、XXL、XXXL等，数据库也可以这样。例如，根据这些数据库的 CPU 使用率，将它们分成几个文件。你分了几个文件之后，基本上你只需要告诉别人你的数据库在一个文件上，他马上就对数据库有了一定的了解。

　　举个例子，如果我说这个人穿XXXL，你会立刻认为他是个高大胖子吧？

　　这样，在对数据库进行描述之后，我就可以知道它在整个企业的数据库中运行在什么级别，并且我是根据不同的维度来做的。

　　通过这种系统画像，可以快速了解这个数据库的特点。

　　

　　在这个系统简介的基础上，我们还会做一些深入的运维。比如我们可以判断数据库操作的基线的变化趋势。和上一张图一样，我们可以看到这次和上次在某个维度上发生了一定的变化。这种变化通常是比较大的。

　　就像你从 XL 到 XXL，或者你变长了，或者你体重增加了。这些都是需要注意的。这是第一点。

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

　　这涉及到：我们需要根据人像的标签维度来管理资源。像现在我们都使用虚拟机、容器云等。在这些云环境中，动态调度是一种非常有用的方式，可以充分利用您的资源。

　　如果有我的肖像和我的肖像基线中的数据，我可以知道某些数据库的CPU和其他数据库的CPU具有互补的运行时间。有的白天很忙，有的白天很忙。晚上忙。当它们互补时，将它们放在一起可以充分利用主机的CPU。我们可以通过这种方式进行一些瓶颈分析和动态调度。

　　由于时间关系，我不会在某个功能中详细说明要点，但希望通过与您讨论这种方法以及它已经产生的好处，我可以给您一些做相关工作的想法。

　　2、产能预测

　　1）产能预测需求：

　　解决天基容量预测需求，先解决容量问题，避免容量事故。

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

　　2）整体算法思路：

　　自主研发的时间序列预测算法，对数据的整体偏差、周期性、趋势和误差进行分解，实现稳定可靠的时间序列预测功能。（现有算法验证效果较差，需要自学整合各种算法。）

　　稀疏点和密集点需要使用不同的预测模型，同时需要兼顾预测精度和训练预测性能。

　　3）容量报告和警告：

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

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

　　让我们看看以下图片：

　　

　　在这4张小图中，你会看到右边的两张小图在某个时间点突然下降。突降后，后续相对平稳。这种突然下降可能是因为我解决了一个问题。如果是CPU，那么我可能杀了一个消耗CPU的进程。我觉得这个过程没用，所以我杀了之后，这部分就没有了。

　　所以去掉之后，整个曲线后面的预测会更平滑。否则它会感觉：你的趋势正在从高点走向低点，然后当我稍后预测时它会进入低点。所以去掉这部分加成后，对它的整体稳定性会有很大的帮助。

　　然后是周期性。就像左下角的图片，其实是很有周期性的。周期性的红色部分是真实点，黑色部分是我们预测的点。可以看到，我们的预测点和红点之间的差异并不是很大。所以总的来说，如果周期性很明显，我们仍然可以得到更准确的预测。

　　我们再看一下右下角的图片。事实上，整个数据有一定的趋势，而且是向上的。虽然之前跌过，但经过我第一步的offset解决了，最后算出整体趋势，也能贴合它的真实趋势。

　　做完容量预测后，我们用一些数据库的表空间，数据库的大小，大表来测试：

　　

　　在做这个测试的时候，除了上面对未来的预测之外，我们还可以对所谓的突变和生长做一些判断，挑出这些突变和快速生长的物体，作为警告发送给负责人. . 负责人知道这个问题，知道他的表一直在不断变大，或者最近突然变得很大，那么你可能需要关心一下。

　　这是关于容量预测的内容。稍后我将讨论日志检测。

　　3、日志检测

　　日志检测我们先来看一个出发点：我们为什么要做日志检测？我们怎样才能做好呢？之前发现产品问题时你是怎么做的？

　　

　　你的想法是当我发现问题时，我需要分析它的原因；然后寻求官方支持；然后根据官方要求采集数据和日志；得到这些后他会分析。并且很多时候厂家会告诉你：“这个问题以前也遇到过，这是我们的情况，官方已经出文档了，你按照这个文档的步骤配置解决，事情就解决了。” ”

　　整个过程似乎是我们日常处理中做的最多的。但是大家想想，整个过程有没有问题？这个时间是不是太长了？来回沟通的成本和解决问题的时间成本是不是太长了？尤其是这些官方的问题，还需要重新走一遍流程，简直是浪费！

　　所以我们想到了做日志检测，这样如果我们在日志中发现问题，我们立即发现并立即解决，是不是更快更好？我们必须把这种被动的问题分析转变为主动发现问题。

　　如果我们主动发现问题怎么办？

　　

　　

　　整体算法思路：

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

　　目前的困难和解决办法：

　　思路：通过对命中的词数或向量的总大小设置限制来过滤日志。

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

　　一种方法是改进白名单库，将非关键片段放入白名单。另一种方法是改进问题特征，将关键段标记为问题特征。

　　思路：有些问题可以忽略，不需要警告。这部分问题可以标记为白名单。

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

　　我们来看看效果。下面是一个比较简单的例子：

　　

　　比如这个日志内容，最上面有这么一系列的日志。模型会在你的问题库和日志内容中查找，列出其中一些关键词，并给出其权重将其列出。然后你会发现：这些关键词很可能是一个消息码，如果匹配到这个码，基本上就是一回事了。如果这些代码匹配，你基本上可以发现他们两个确实非常相关。归根结底，到底是不是这个，还是需要判断的。

　　但一般情况下，它会立即从你的已知问题库中找到与此日志相关的问题，这样它才能达到很好的命中率，然后自己判断！

　　事实上，日志检测还有改进的空间。

　　一般来说，优化是无止境的。如果我们有想法、想法和时间，我们可以把这些事情做得更好！

　　四、懂AIOps的DBA

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

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

　　第一阶段是几年前，我们都有过这种所谓的人性化运维。在这个阶段，我们的DBA忙着做一些手动操作，比如安装、更改、监控、应急响应、检查、调优等等。

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

　　但未来属于智能时代。智能时代在两个方面得到了提升。一方面大大提高了运维质量；另一方面，它实际上提高了DBA知识的广度和深度。比如智能时代，AI已经有了，那还需要DBA做什么？

　　那么DBA是做什么的呢？DBA需要是一个懂AI，知道如何利用这些AI技术提升运维能力的DBA。这件事是DBA来做的，而不是靠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现在就很自动地采取这些方法再试一次，看问题能否解决。

　　当你发现你的人工智能做得很好时，在大多数情况下，每一个决定都是正确的；或者对于某种类型，它基本上是 100% OK 的。在这种情况下，可以推进到下一阶段，即故障的自愈。这不需要人工智能来辅助决策。AI 可以将这些列出的决策视为固定决策，在发现和判断之后自行做出。当AI完成后，就相当于实现了故障的自愈，因为不需要DBA的参与。

　　故障自愈是AIOPS的下一步。DBA会根据其故障自愈和之前的一些警告信息等，做一定的回顾和优化。这些重放和优化是基于 AI 的数据库和我自己的经验。我所做的事情实际上比没有人工智能要准确得多。

　　最终：自动驾驶。如果在这方面优化利用过去的经验，做到极致，能不能实现自动驾驶？放心，故障自愈、资源调配或各种任务都交给AI。让AI在整个云环境中控制这些东西。这是我们的最终目标。

　　今天的分享就到此为止。其实我今天主要想和大家分享一些想法，也希望大家能和我一起讨论一下你们的新想法！