用知识图谱构建运维知识库

白鳝的洞穴 2020-11-05

5797

运维知识的积累是构建运维自动化体系的最核心的工作之一，以往我们构建的运维自动化系统都是给专家看的，因此是以指标为核心的，如何把指标用最为直观的图形化界面展示给相关人员去看是最为关键的。系统的开发人员可能都从来没有从事过运维工作，也不了解运维工作。不过这不重要，运维人员自己会去设定某个指标的告警阈值，并通过这些指标的告警阈值来运维系统。因此传统的运维自动化系统都提供了一个核心框架，提供了对指标、日志等的监控。具体如何告警，如何使用都依赖于专业人士的能力。

解决这个困境一直是运维人员的诉求，运维人员不仅需要知道某个指标告警了，更需要知道某个指标告警意味着什么，如何从中找到出现问题的原因，找到系统中深层次的亚健康风险，从而变被动运维为主动运维，从事后处置变为提前预警。这一切都依赖于一种老白称为运维知识自动化的运维自动化体系。虽然这中间只有“知识”两个字不同，不过其理念差异巨大。运维自动化的主要目的是利用自动化手段，让专业运维人员的工作量得到减轻，而运维知识自动化的目标是将各种专家和运维人员积累下来的运维知识变成可自动化诊断与处置的工具，服务于运维。运维知识自动化的最终目的是减少人在运维工作中的介入，推动流程自动化工作与诊断分析自动化工作，最终实现自动化处置。

构建知识自动化系统中最为核心的能力建设就是运维知识库的构建。老白的团队首先利用专家的经验构建了一系列的知识自动化模型，这个模型是基于运维经验、知识点、工具构建的：

通过对一个或者一组指标的模型分析，可以触发一个基于故障与隐患发现的运维经验，这个运维经验都有针对性的诊断知识点，每个知识点最终都会对应一组分析工具，用于对这个知识点的诊断分析。通过知识点可以构建一个诊断链条，通过这个诊断链条，可以一点点的进行分析与溯源。

这种运维知识自动化系统是完全基于团队的运维经验积累的，并且在自己的信息系统中可以不断的积累团队的经验，每次故障、每次优化工作都会积累大量的运维经验，发现一批知识点，并被团队积累下来，这样团队的能力会不断的提升。

我们先来看一个运维知识自动化系统如何协助我们发现问题并进行问题溯源与故障消缺的。

某系统的整体健康指标突然降为70分，自动触发了状态巡检，状态巡检报告中，我们可以看出IO的总量与IO延时都出现了异常。

同时从报告中的TOP SESSION中也发现了一些高开销的SESSION

进一步下钻分析开销较大的会话，我们找到了几条开销很大的SQL，经过确认发现，TOP SESSION中排名靠前的几个会话都在执行这条SQL。

点击STS诊断按钮继续分析SQL，发现这些SQL都是在对两张大表做全表扫描，同时STS也发现这两张表的统计数据是不准确的。于是和开发商进行了沟通，发现昨晚这两张表都导入了大量的数据，而导入数据后并未对表进行统计分析，同时这两张表的统计信息也是被锁定的，于是解开这两张表的统计数据锁定，重新对表和索引做了分析，问题就消失了。

这种基于运维经验的诊断分析是基于一个强大的知识库的。老白的团队从2017年开始构建这个知识库。不过在构建过程中也遇到了一些问题。最初的知识库是基于规则的，知识点工具也不过百十来个，随着这些年的积累，知识点的数量已经达到了一千多个，知识点管理也越来越困难。

上面是老白的运维知识库1.0，如果我们增加了一个知识点工具，这个工具可能可以优化多个运维经验的诊断流程，那么如何能够让运维经验自动找到这个工具就十分关键了。图数据库和知识图谱在这个领域就十分有价值了。

图数据库用于维护复杂的关系，并可以通过图推理发现一些隐式关联关系，因此称为老白的运维知识库2.0的首选。将1.0的运维知识库导入neo4j后，我们获得了2万多个元组的图数据库，并自动发现了大量的以前没有发现的新的诊断路径，大大丰富了原有的知识库体系。

不过另外一个问题又出现了，仅仅依靠老白团队积累的运维知识库的生长速度还是太慢，快3年的时间才积累了2万多个元组，而且运维对象的覆盖面也受到团队业务的影响，限于数据库、应用中间件、传输中间件、集中式存储等部分领域。因此下一步如何快速丰富这个运维图数据库是我们最重要的任务之一。构建一个开源生态，让更广泛的企业、团队、人员参与到这项工作中可能是解决这个问题的唯一方法。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

用知识图谱构建运维知识库

评论