本文根据孔再华老师在〖deeplus直播：金融业数据库转型与国产化改造〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）
1、运维数据中台
首先，大家知道关于智能运维，我们其实最看重的还是数据质量。作为一个运维大数据的分析平台，我们需要对运维大数据做一些分类，把不同类型的数据都汇总到一个运维数据中台里面去。
我们可以采用不同的技术手段来存放这些数据，并通过统一的消费来做智能分析。首先需要一个比较夯实的数据基础，所以运维数据中台里面可能需要分这样几类数据：
一种是监控数据。监控数据包括性能数据、状态数据。监控数据的来源非常多，可能我们都有这种集中监控平台，它会去采集一些各个软硬件产品比较核心的性能指标。有些可能还有其他各种各样的平台，里面都会放着跟业务、交易、产品、软件、硬件相关的信息和日志。这些数据我们要想办法把它们集中到一起，进行统一的消费。
还有一种数据是所谓的元数据。或者也可以看作是像CMDB的一个关系类的数据。这种关系类的数据它也是一样散布在很多不同的地方。CMDB可能是一个比较集中的、管理着所有的这些关系数据的地方，它只是汇总了一部分，还有很多其他的系统也包含相关的数据，并且有很多关系数据是要经过分析才能得出来的。所以关系数据可能不仅仅是我们已知的一些关系，还是我们总结出来的一些关系。
最后一部分数据是知识库相关的数据，比如说我们建的问题库、知识库等等，它可能包含了你运维过程中总结的一些知识，或者是跟产品相关的一些知识。而这些数据基本上就是我们需要去关注和处理的这种运维大数据。
2、实时计算引擎
当我们拥有这些数据之后，会在上层建一个实时的计算引擎。这个实时计算引擎主要是做实时的数据分析以及历史的数据分析。
3、智能算法库
再上一层相当于构建了一套智能算法库。智能算法库里面在不停地补充各种各样的智能场景。这些智能算法库，我们的想法是让它通用一些，能够采用一些通用的方法解决比较个性的一些问题。
4、智能运维服务
最后是在智能算法库、在大数据的基础上封装一些智能运维服务。这些智能运维服务，通常是深度分析软硬件的产品的运行状态、产品的问题发现，根因分析等等。
在这个基础上，我们甚至还可以再有一些自助服务。比如说可能不在我们采集的产品、数据上面，还有一些其他系统自己的数据，它们也希望用我们的智能算法和一些服务。那它们可以通过我们比较通用的接口来推动数据，获取这个服务所取得的信息。
为了做这件事情，我在这几年构建了这样一个基础软件智能运维平台。针对这些智能场景，这个运维平台里面主要分为这样几个部分：
一种是做异常检测，在做完异常检测的基础上，我们再做一定的根因分析，通过根因分析找到问题的根因所在。
有了异常检测和根因分析之后，就可以去通过创造一些所谓的智能场景，通过场景告警的方式，收敛这些告警和根因分析，给普通用户或者专业的DBA提供决策相关的信息。
1、异常检测
首先说一下异常检测。大家想想：我为什么要做这样一个异常检测我们做监控的时候，可能只需要对一些指标设置一定的阈值，我就可以说我关于指标的异常检测已经搞定了。这也是我们把一些核心指标提供给监控系统，然后由监控系统帮我们告警的一个方法。
但事实上，如果大家在平时使用的过程中发现：监控确实告警了。而它告完之后，你拿着它的告警去查看你的数据库。想要去分析更深层次的问题时就会很困难。因为可能告警出来的只是结果，但是真正的原因、真正的告警的细节的点在什么地方呢实大家并不知道。我们知道，像数据库里面其实有很多很多的性能数据，它可能在不同的层次、不同的组件上，都有相关的性能数据的采集。如果这部分内容不被利用起来，对于我们来讲这个数据库就是一个黑盒。
但是如果我们能够把这些所有的指标，比方说可能有成千上百的这种指标，全部都监控起来，并且不通过人为的方式去进行判断，而是通过机器的智能算法，去寻找这些指标运行有异常的情况。那这样我在问题点的时候能够看到：到底是什么地方发生异常了我是不是就可以找到更细的那个点，并且知道是什么原因。
所以在过去的异常检测里，我们做了针对全时段和分时段的异常检测，就像这张图右边的两张小图：
在做完异常检测之后，我们还需要找到什么们还需要找到问题的根因SQL。我们可以基于日常的异常检测，去找到这个点。这个点它如果有异常了，那到底是哪个SQL导致的呢们可以基于这个点和SQL的一些指标进行排序，然后得到对这个点的贡献最大的这些 SQL。
当我找到这个SQL之后，我就可以去看这个SQL的历史执行情况。第一，我可以看这个SQL当前的执行时间分布图。它到底是在什么地方花的时间比较多后我还要去看 SQL的历史执行情况。它之前也跑了这么多次，也是在这样的一些时间点运行，那它整个的响应时间、整个的执行时间有没有什么太大的变化/p>
通过这种和历史的对比、和当前的细致的分析，我们就能够把根因分析做得非常好！
3、智能场景
最后是智能场景。我刚刚说了，当你真的把所有的、1000多个指标都监控起来，这些指标可能会有很多是相关联的，它们可能都喜欢一块儿出现运行不一样的情况。
在对历史的这种运行不一样的情况进行分析之后，我们可以把相关的指标组合在一起。组合在一起之后我可以告诉说：如果这一类的指标发生异常，它其实说明的是一个什么样的场景。
1、系统画像
对于系统画像这个东西我们先想想。我们要做系统画像，那我们平时认识到的最多的画像是什么实是客户的画像、用户的画像。对于这些客户的画像、用户的画像，我们可以随便上网搜一些图。那我自己就去搜了一些图，这些图片都是网络上搜过来的：
在这6大维度里面可能是一些比较细节的指标。在这些指标的基础上，我们可以做一些聚类，做一些整体的、跟其他的数据库的横比。因为毕竟在银行或者是在其他的金融行业，大家其实并不缺数据，对吧br>
就像我们卖衣服要把人的衣服分成 XL、XXL、XXXL等情况，对数据库我们也可以一样。比如说按照这些数据库的CPU的使用情况，把它们分为好几个档。当你分完好几个档之后，基本上你只要告诉别人，你的数据库是在某某档上，他立马就会对这个数据库有一定的了解。
比如我说这个人是穿XXXL的，你立刻就能想到他是一个高大的胖子，对吧/p>
通过这种方式，把这个数据库描述起来之后，我就可以知道它这个数据库在整个企业的数据库里面，是运行在怎样一个level里面，并且我也是基于不同的维度去做的。
通过这种系统画像，你可以很快地了解这个数据库的特征。
在这4个小图里面，你会看到，右边的这两张小图，在某个时间点都出现了一个突然的下降。而在突然下降之后，后续是比较平稳的。这种突然下降可能是因为我解决了一个问题。假如它是CPU，那我可能杀掉了一个比较耗CPU的进程。我觉得它这个进程没用，那我干掉它以后，就再也不会有这部分加成了。
所以去掉它之后，整个曲线后面的预测会平稳一些。否则它会觉得：你的趋势是从一个很高的点往低的点走，那我后面在预测的时候它也会往低的点走。所以这部分加成去掉之后，对它整个的平稳性会有很高的帮助。
然后还有周期性。像左下角的这个图，其实它是很明显有一定的周期性的。周期性里面红色的部分是真实的点，黑色的则是我们的预测的点。可以看到，我们预测的点和红色的点其实差异并不是很大。所以总体来看，如果在周期性很明显的情况下，我们还是能够得到比较准确的预测的。
我们再看右下角的这张图。它其实整个的数据是有一定的趋势性的，它是在往上走。虽然它在前面曾经掉下来过，但我通过第一步的偏移性解决之后，最后在计算整体的趋势性的情况下，它也一样能够拟合它真正的趋势。
做完容量预测之后，我们拿一些数据库的表空间、数据库的大小还有大表来做检测：
你们想到的可能是，当我发现问题了以后，我需要去分析它的原因；然后寻求官方支持；再按照官方要求收集数据，日志；拿到这些之后他会去分析。而很多时候厂家会告诉你：“这个问题以前已经碰到过了，这是我们一个case，并且已经在官方发布了一个文档，你们按照这个文档的步骤去进行配置解决，事情就搞定了。”
整个的过程看起来，是我们日常处理过程中做的最多的地方。但我们深思一下，在整个过程里有没有问题个时间是不是太久了来回回的沟通成本和解决问题的时间成本是不是太长了其是这些官方已经知道的问题，我们还需要把流程再走一遍，这简直就是浪费嘛！
所以我们想到要做日志检测，这样如果我们在日志里面发现问题，当时立刻发现，立刻解决，那是不是要更快一些，更好一些们要把这种被动地分析问题变为主动地发现问题。
那主动发现问题要怎么做呢/strong>
总体算法思路：
基于机器学习自然语言处理的能力，将文本处理成向量，然后基于文本相似度来计算是否命中已知问题。
当前困难与解决思路：
-
问题1：日志片段计算出来的词向量过少
思路：通过命中词多少或者向量总和大小设限，过滤日志。
-
问题2：日志命中非关联问题。
思路：主要原因是问题库中的问题特征可能包含很多日志片段，当前日志命中的是非关键片段，导致误报。
一种方法是健全白名单库，将非关键片段放入白名单。另外一种方法是健全问题特征，将关键片段标注为问题特征。
-
问题3：日志命中非关键问题。
思路：部分问题是可忽略的，不需要告警。这部分问题可标注为白名单。
-
问题4：新问题不断产生，模型滞后。
思路：定期爬取新问题和定期重新训练更新模型。
我们来看一下效果，我这边是列了一个比较简单的例子：
那么我们把DBA的工作和 AI的工作放在一起，从底向上怎样去实现运维的提升br>
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
↓点这里可回看本期直播
文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34371 人正在系统学习中
来源：jeanron100
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！