智能运维的知识库是怎么生长起来的呢？是不是像传闻的那样，把运维监控采集的数据、日志扔进去，人工智能就自动学习，形成新的知识了呢？上述的场景似乎有些太科幻，起码目前的智能运维人工智能还不具备如此强大的能力，能够从数据中仅仅凭借着算法来学习新的知识。我曾经和很多做智能运维的专家讨论过这个问题，大家不外乎使用的是数据、专家标注、深度学习这样的方法。这种方法我们也试过，可能是因为我们的算法能力比较弱，这种方法我们一直找不到能够成功的可能。
经常有网友问我这个问题，你们的知识库是怎么做的呢？前几天就有个网友给我私信，问我如果你方便的话，能不能介绍一下你们的知识库是如何生长的。随后他又补充了依据，可能我不该问这个问题，因为这可能涉及你们公司的机密。
实际上也谈不上机密，知识积累的方法本身就不是机密，只是以前我们把他记录在本子上，或者记在专家的心里，而现在我们只是把它数字化了而已，整个方法并不神秘。今天早上，我就用我们昨天遇到的一个客户案例，介绍一下D-SMART的知识库是如何生长的。实际上今天早上我的这篇文章不仅仅是一个闲谈，而是一篇生产力文章。昨天我们遇到了一个客户现场的问题，我们的D-SMART能够定位问题，但是在问题溯源上出现了问题，因为我们在网络分析方面的知识不够全面，从而导致部分分析只能人工介入。最终虽然发现了问题，但是也暴露出了D-SMART的知识库上的一个缺陷。因此今天我们需要对这方面的知识库进行增强。具体的方法也比较简单，今天早上我写这篇文章时会对这个问题做一次复盘，然后画一个思维导图，把昨天问题所涉及的知识梳理出来。今天早上上班后，我们团队的小伙伴拿到这张导图后，会对导图进行分解，找出目前我们的知识库所没有覆盖的指标采集、知识点工具等。然后PYTHON工程师会立即把缺少的知识点工具化。然后把这个知识放入我们的知识库中，因为这个问题比较简单，而且D-SMART已经具有了十分稳定的框架，因此这个知识库的更新可以在今天下班前完成。
可能有朋友会有疑问，这样用户现场发生一个问题，知识库增加一些诊断工具，这种模式不是和传统的运维工具一样吗？谈什么智能呢？确实，这种方法和以前的运维工具开发很类似，发现了某个需求，就开发一个工具。这些工具都是针对性的，并不具有普遍适用的价值。而D-SMART中的知识并不是这样的，因为D-SMART的知识库是一个图数据库，任何一个知识点放进去，都不是孤立的，它立即会和已有的图建立联系，从而改变整个图数据库中的原有格局。很多新的知识衍生路径会自动产生，其他的诊断工具也会因为这个知识点的加入而变得不同。当一次性放入的不是一个知识点，而是一个本身带有关联和路径的多个知识点的时候，这个效应会被大大的放大。就像我们做拼图游戏的时候，刚开始拼起来的那几块会十分困难，随着你手中拥有的拼图越来越大的时候，后面的拼图速度会越来越快。知识积累也是如此，刚刚开始放入知识库的知识之间的关系相对孤立，相互之间的协作作用也十分有限，而当你的库中的知识点的数量超过个的时候，知识点之间的网状结构就形成了，此时的知识库里，你只要再放入几个和以前的知识库有一定关联关系的知识的时候，整个知识库都会被新加入的元素所影响。一个知识不仅仅可以为你新分析的场景所用，而且能够自动的参与到有关联的场景的分析中去。
因此获得大量的生产环境的监控数据，对这些数据进行处理，从而发现一些新的知识，是我们常态化在做的事情。目前我们的这项工作只能通过和我们的客户的协作过程中来完成。我们十分珍惜每一个用户的样本，我本人也经常在客户的历史监控数据里翻找。通过扫描发现一个异常，然后利用我们的知识库诊断下去，找出问题，再和用户去确认这个问题，是我每天上班时都会去做的事情。这种工作有时候用户不太理解，都是几个月前的事情了，当时系统并没有明显报错，你折腾这些干啥。不过经过几次发现了深藏在客户系统中的隐患之后，客户也喜欢上了我这个“龙宫探宝”的游戏。可能现在搞计算机的人听到这个词不会产生什么共鸣，而80年代开始搞小型机大型机的人都玩过这个字符游戏，每台计算机被造出来的时候，工程师执行的第一个程序往往就是这个游戏，能玩起这个游戏来，那么说明这台计算机是合格的。
前面啰嗦了半天，最后还是谈一些干货。昨天我们遇到的客户一个系统这几天突然在业务高峰时候很慢，业务部门目前还能忍受这个性能，不过比起前几天来，慢了不少。从资源使用情况，负载等来看，也都正常，CPU使用率也只有10%+，内存资源也有10G+的空闲。系统负载也不高。通过D-SMART来分析，也很快就定位了一些问题：
这个诊断结论似乎就已经定位了问题，出现了大量的gccrblocklost，gccurrentblocklost。这种情况不外乎三种可能性：1）网络存在故障；2）GC的负载太高，导致LMS处理不过来；3）OracleBUG。
因此客户的网络工程师立即检查了网络，发现网络并没有任何问题。两个节点之间的心跳线之间的Ping延时也都是小于0.1毫秒的。同时这套RAC中，只有一个节点处理业务，另外一个节点平时是打酱油的，只有晚上跑跑批处理，确实通过D-SMART我们也能看到高峰期网络流量也不过几兆每秒。对于网络丢包的检查，D-SMART中的指标也是正常的。而如此小的INTERCONNECT流量，GC负载过高也不成立。通过对LMS进程的CPU使用情况检查，也发现LMS进程不忙。因为BUG导致LMS太忙，影响性能也不成立。那么剩下的问题就肯定在网络上了。
实际上，目前的D-SMART知识库里对网络的监控和诊断能力都还存在不足，实际上对于一个网络包从网线进入LINUX内核这段路上，有好几个监控点，我们的工具目前在网卡上做了监控，一旦网卡上有丢包，会立即体现到数据库的健康状态中，而实际上包丢失不只是在这里会发生。从网卡的缓冲到RINGBUFFER也会发生，这种情况是RINGBUFFER满了就会发生的。另外从RINGBUFFER到LINUX内核也会发生这种丢弃，那就是TCP/UDP的接收缓冲满了的时候，就会产生。于是我们让客户现场检查了一下UDP层面的丢包情况。
问题很明确了，在UDP层面确实存在丢包，而且原因就是RCVBUFERRORS，是不是UPD的RCVBUF太小呢？通过D-SMART上的工具去查看客户的网络参数设置情况。
从操作系统参数检查的结果来看，相关的网络参数都做了调整，只是不清楚这些参数调整后有没有重启过数据库实例，参数是否起效。因为客户的LINUX比较老，是核心为3.0.11的SUSE，ss-amp命令无法看到当前连接的RCVBUF的大小。而客户的生产系统也不能轻易重启，因此只能等下一个停机窗口重启一下了。
白鳝