以前看到很多使用知识图谱的产品，里带有的知识图谱都是十分花哨的，看上去似乎很高端很好看，不过我没想明白，运维人员使用这样的图谱如何辅助运维。真正的基于知识图谱的运维自动化工具应该是看不到图谱的，图谱只是用来帮助用户自动化分析问题的工具，而不应该成为一个展示品。
经常有用户问我，你不是说你的产品里有知识图谱吗，怎么我看不到呢？事实上，知识图谱只是在后台默默的存储着我们积累下来的运维知识，它是无法为我们提供任何能力的。真正让知识图谱发挥作用的是D-SMART宏的一些智能分析工具。这些工具看上去和普通的工具并没有什么不同，我们点击上去的时候，显示出来的内容可能也差不太多。不过实际上这些工具在后台分析的时候，里面的逻辑并不是专家预设好的，而是根据图数据库中的运维知识，自动的发现路径，推荐路径给我们。
我们今天用一个达梦数据库问题的分析过程来展现一下知识图谱是如何为运维自动化提供能力的。
首先我们发现一个问题，在12月21号的时候，达梦数据库DM8_120曾经出现了CPU使用率过高的问题。这是两天前的一个系统严重告警。点击“运维经验”来进行分析。
自动诊断报告上确认了，在这个时间段内，确实CPU出现过较高的情况。因为智能诊断比较消耗CPU资源，因此自动诊断报告还是使用的传统的分析工具，其能力还不够高，只是帮你确认了CPU资源使用率较高的问题确实是存在的，在分析区间内，95分位的值高达94.35%。我们希望去了解一下这个时间里，这套达梦数据库到底发生了什么。这时候我们只需要点击一下“手动诊断”。
点击“智能指标分析”的诊断按钮，就可以完成这个自动分析工作了。我们来看看后面的结果，是不是真正的帮我们定位了问题。
可以看到，诊断结论中认为，这段时间里系统的SQL并发执行数量过大，数据库的逻辑读和物理读都比较大,redo的并发量比较大。另外从配置上，DB CACHE的设置也存在一定的不合理的地方。下面我们再来看看智能运维工具给我们推荐了哪些诊断工具呢？
排在靠前的推荐是“逻辑读较多的SQL”,”执行次数较多的SQL”和”达梦数据库参数检查”这三个工具。我们先来看看TOP SQL诊断工具，看看CPU比较高的时候，系统有哪些逻辑读比较高的SQL。
还真的在十多分钟时间里有几条SQL开销挺大。点击“执行计划”按钮来分析一下。
有一条SQL语句针对DMSQL_OORDER做了一个全表扫描，每次扫描471M的数据，1200多万行数据。难怪消耗了那么多CPU资源了。
我们再来看看DBCACHE配置问题，在这里，智能运维工具推荐了达梦数据库命中率维度的诊断。实际上应该还有一个，因为推荐工具排重的问题，在这里被排除掉了，这个工具包含在诊断项4里面-“达梦数据库参数检查”，因为在在前面的推荐中已经出现了，所以在这里就被裁剪掉了。裁剪掉已经出现过的工具是为了让显示界面更为简洁。不过也会让某个章节的内容现得不够准确。这是两难中的选择的结果。
从这里可以看出RECYCLE POOL的命中率是存在问题的。不过这个诊断工具比较老，分析的内容也不是很准确。于是我考虑立即用新提供的“智能知识点”的能力，创建一个分析工具来完善这个分析过程。
老白已经多年不写程序了，手忙脚乱的花了块10分钟才搞定了这个知识点，并把它配置好了。整个框架代码，连注释不到30行，实际上只是修改了其中几处配置，这个知识点就写好了，写代码时间不超过2分钟。下面我们来看看效果。
这个新的知识点的加入，不仅仅会应多出一条诊断路径，因为整个图谱中的各个节点之间的关系也直接发生了变化，诊断结果也发生了变化。从实际效果上来看，虽然发现的问题也还差不多，不过其权重发生了较大的变化，结果变得更准确了，导向性更强了。
可以看到，这个知识点已经能够自动在诊断分析中发现了。我们也可以使用这个知识点来进行诊断。
可以看出，这个“智能知识点”不仅仅是一个智能路由器，自己也具有很强的诊断分析能力，正是这个知识点的诊断分析能力中发现了更多的应用方面的问题，所以从总的诊断结论上，应用问题的排序更靠前了。
这个知识点并没有怎么配置，也没有手工创建与其他知识之间的关系，只要把这个知识点创建起来，扔到图谱里去，就会自动的发挥作用了。运维诊断工具的低代码可以为一线运维和三线专家提供更好的工具，让他们能够更快的实现自己的运维经验的自动化，也可以大大加快智能运维系统的开发。这是我们的智能化知识点中的一种，叫做“泛路由知识点”，这种知识点具有两大特征，
第一个特点是泛路由发现，可以自动建立与其他知识之间的关系，并自动筛选适合的路由，将知识推荐给前端。第二个特点是低代码，实际上，通过简单的配置，这个知识点就可以调用一些平台提供的标准化的智能化分析手段，简单的两三行代码就可以构建一个十分强大的分析功能，用低代码的方法开发一些常用知识点工具，可以大大加速研发进度。
最后再讨论一个问题，昨天还有朋友问我文中前面提到的两条技术路线：大数据+高级算法和运维知识图谱+简单算法，到底哪条路才是企业做智能化运维的最佳选择。实际上，这两种技术路线对于企业的作用是不同的。
对于一些大企业，这两种技术能力都是需要建立的。如果企业目前更需要宏观的异常检测，问题发现，而具体的技术分析工作主要还是依靠人力，那么第一种能力是这个企业当前最迫切需要建立的。而如果企业目前需要一种能力去减轻人力分析的工作量，减少运维中的人力资源，那么第二种能力是企业首先要考虑建立的。如果企业在资金等方面充裕的话，两种能力同时构建肯定是最能看到效果的。而对于一些运维资金十分有限的中小企业，建立第二种能力可能是性价比比较好的，因为它马上能够在你的企业里发挥效用。而第一种能力，一定要等你的运维数据归集和积累达到一定程度后再去做，可能更有效一些。
