不谈宽泛的智能运维，聊聊我在用的异常检测核心算法
孔再华中国民生银行信息科技部数据库专家
IBM认证高级DBA、SAP认证BASIS ， 具有丰富的数据库环境问题诊断和性能调优的经验；曾任职于IBM研发中心 ， 为客户提供数据库支持 。 尤其是在数据库同城双活、集群、多分区、分布式等项目咨询和实施上具有丰富经验；目前致力于数据库同城双活架构建设 ， 数据库分布式架构建设和数据库智能运维（AIOps）方向 。 对于如何将AI技术运用在运维领域有浓厚的兴趣和创新热情 。今天我要分享的内容 ， 有这样几个方面 ， 首先讨论在数据库运维中存在什么痛点 ， 其次是我们为什么要做智能运维 ， 智能运维是什么 ， 我们在民生做得怎么样 。 然后会大概说说智能运维中的智能算法 ， 最后是案例分享 ， 也就是我们上了这套智能运维系统后到底有什么效果 ， 在使用过程中帮助我们达成了什么样的目标 。
文章图片
一、运维痛点
首先聊聊运维的痛点 。 我是银行的从业者 ， 我们行内对数据库运维的要求 ， 我总结为两点 。 一点是银行里对数据库运维的要求是非常高的 ， 我们自己银行内部有个“双十”红线的要求 ， 就是说数据库如果出现问题 ， 那么需要DBA在十分种内分析问题 ， 十分钟解决问题 。 如果在十分种内没有分析完成 ， 那么先暂停分析 ， 救急的工作一定要开始做 ， 争取在十分钟内把救急的工作做好 。 所以我们平时在运维过程中时间要求还是很紧张的 。 尤其是没搞清楚原因的情况下 ， 救急的操作可能最终没有解决问题 。
文章图片
另外一点是我们在运维过程中 ， 会产生很多有价值的数据 ， 我们对于机房所有的产品 ， 无论是系统、中间件、数据库都会监控很多东西 。 即便是这样 ， 我们现在监控的数据还是比较片面的 ， 不是说没有更详尽的运维数据 ， 而是我们没有办法把这些把数据用起来 ， 现在我们只是人工挑选了一些比较核心的指标 ， 做了一些监控告警 。
文章图片
首先谈谈“双十”红线 。 如果数据库遇到bug ， 性能不好的SQL ， 我们大概会从运维系统的交易响应率 ， 数据库的一些告警中知道现在数据库运行缓慢或者出现故障 。 这时候我们要赶紧去收集数据 ， 查看日志 ， 分析当前遇到问题是什么 。
如果我们是很有经验的DBA ， 那我们可能会基于现有的数据和现象 ， 能够知道说可能命中了个什么样的问题 ， 如果以前有相关经验的话可能就能很快解决 。 但如果说我遇到这个问题是个新问题 ， 那之前那种解决方式我可能就做不到 。
做不到的情况下 ， 就只能做应急处理 ， 把数据库的应用杀一杀 ， 重启一下数据集 ， 能怎么做就怎么做 ， 通过所谓万能的重启大法 ， 先把问题试着解决 ， 后面再复盘 ， 再把数据上收 ， 发送给对应的数据库厂商来帮我们分析问题 。
这可能就是DBA平时的工作 ， 收集数据 ， 分析问题 ， 应急处理 ， 问题复盘 。 但是在这个过程中会有很多欠缺的地方 ， 比如一开始收集的东西不够多 ， 就会导致问题复盘的时候很难重现 ， 这块其实有很多痛点 。
文章图片
引申来说 ， 除了我们现有对故障的处理的痛点 ， 还有问题就是我们现在拿到这些数据是不是没有什么用？比说我们从数据库这一层面可以收集成百上千个指标 ， 那这些指标都是很奇怪的指标 ， 你要是不查资料你根本不知道这个指标是干嘛的 。 对我来讲也一样 ， 我其实做数据库运维有很长时间了 ， 指标也不是全部都清楚 ， 我遇到后还是要去查一查看一看 。
那这么多指标 ， 它们都是有自己真实的含义的 ， 大家不用起来的话是真浪费 。 如果我们可以做到把所有的指标管理起来 ， 而不仅仅只是管理我们关心的那十几个重要的指标 ， 那我们对数据库的洞察力会更强 。
更进一步 ， 如果我已经拿到这些数据了 ， 那数据和数据之间是不是存在很多的关系呢？比如说我们经常有这样一个需求 ， 我们遇到一个问题 ， 说哪个东西不正常 ， 你知不知道是什么东西引起的不正常呢？会不会是其他的什么事情？
我们平时在运维中分析告警时 ， 总是想办法去找跟它相关的那些指标 ， 或者是因素 。 这个相关性是可以从历史数据中找到的 ， 如果我们已经把这个东西挖掘挖掘 ， 并且形成一定的知识库 ， 那真的遇到问题的时候 ， 我们基于这个知识库立刻就能发现是什么情况 。 所以我们要挖掘运维数据的关系 ， 并且利用起来 。
再继续下去 ， 我们不仅仅是管理了所有的指标 ， 还理清楚了这些指标之间的关系 ， 下一步就要汇聚体现 。 比方说我这么多指标 ， 密密麻麻上千个 ， 到处发生异常对我来说没什么意义 ， 我想知道整个行里面几百到上千个数据库 ， 运行得怎么样 ， 那我怎么样去观察它们？
那这个时候就需要这样一个全局的视图 ， 相当于说我需要数据库的运行状态通过一些有价值的数据指标综合起来 ， 描绘出一个数据库的画像 ， 这样能够从很多数据库运维中立刻挑出来说哪些数据库运行的状态是属于哪一种类型中 ， 也就是把握住这个数据库的运行特点 。
然后我们总结了几种类型 ， 描述这个数据库很忙 ， 它是一个事务性集中的数据库 ， 它平时的业务量大但是数据量不多 ， 它的io的承载能力或者各方面的属于中等 。 这就是一个数据库的画像 ， 这个东西是我下一步会做的事情 。
二、智能运维
其实说了这么多 ， 从我自己的理解来讲 ， 智能运维不是靠人为定义哪些规则去发掘指标的关系 ， 去看指标的含义 ， 而是说我通过智能算法把指标采集起来 ， 再把它们给训练和管理 ， 然后智能算法自己从指标里挖关系 ， 把关系提炼起来 ， 最后通过智能算法把核心的指标挑出来 ， 它们能展示我们自己想要的东西 。
【不谈宽泛的智能运维，聊聊我在用的异常检测核心算法】那做这件事情就是为了节省DBA的人力 ， 因为我是个DBA ， 如果要自己手工做这些事 ， 我相信是不可能发生的 。 但是自从机器学习比较流行之后 ， 我也是看到了机器学习在数据分析上的各种能力 ， 所以我觉得数据库这个层面 ， 再加上机器学习 ， 互相结合能迸发出来火花 ， 完成一些我们之前做不到的事情 。
为了做这个智能运维 ， 我们首先要对智能运维平台进行构思 ， 比如说我这个平台到底要做什么事情 ， 它要监管一些什么样的指标 ， 我这里面有哪些计算的内容 ， 这些内容我们应该怎么去依托现有的架构去实现 ， 还有大数据量的挖掘和处理 。
文章图片
这里我大概提了几个比较重要的点 ， 比如容器化 。 因为我觉得现在云化容器化比较流行 ， 我的计算节点是无状态的 ， 通过容器化的伸缩 ， 很快完成我的目标 。 事实上也确实是这样 ， 智能运维到现在 ， 监管的对象越来越多 ， 内容越来越扩展 ， 数据量越来越大 ， 训练和实时处理的要求越来越高 。 自从用了容器化 ， 把我的平台扔进去 ， 我要扩展这方面的性能就变得比较简单 。
然后关于机器学习的语言选择 。 其实也没有其他什么好选的 ， python是现在最流行的机器学习语言 ， 比较通用 ， 算法包比较多 ， 接口多 。 我自己作为初学者 ， 来看应该用什么平台时 ， python能解决很多开发上的工作 ， 我能很快找到我想要的算法包 ， 很快去把我想要的模型弄出来 ， 研究它的效果 。 所以我最终还是选择python ， 没有选其他高性能的语言 ， 毕竟我这边开发能力资源有限 ， 没有办法去砸很多人把python里的一些算法转化为java、c++高性能语言 。
推荐阅读
- 通达信精选指标：价位时空主图，画线战法是技术派的核心内功
- 疫情冲击经济，第一个“破产”的国家出现！今年5次调查自华产品
- 美国用“核试验”来恫吓中国“核裁军”，那是赤裸裸的核讹诈
- 寂然单排134连胜，队友却全程挂机，赛后寂然发现挂机队友的一个秘密
- RNG新上单暴露了？绿毛小明聊天记录曝光：记得照顾好我们的兄弟
- 下周开始，缘分跟桃花邂逅相遇，迎来幸福爱情的四生肖，恭喜脱单
- 情商高、会说话，相处起来很舒服的星座，走到哪里都受欢迎
- 笑起来超迷人，却不喜欢笑的星座，摩羯上榜
- 十二星座里，翻脸比翻书快，特别爱作的4个星座
- 天海解散后欠薪袭来 流氓协议要把忠心的球员捆绑