智能运维中诊断路径的积累方法

白鳝的洞穴 2021-02-24

1141

智能运维中诊断路径是用于故障分析、预警、溯源的运维知识，对于智能运维系统能够真正落地具有十分重要的作用。目前的绝大多数智能运维系统中这方面的积累都是较为有限的，甚至一定数量的智能运维系统中运维经验基本为0，仅仅存在一些通过数据分析形成的模型，而这些模型往往过于简单而无法在实际运维工作之中发挥作用。

诊断路径的积累有三种最为常见的方法，第一种是专家梳理，通过专家的梳理，可以把以前只由专家掌握的运维经验数字化，形成可以自动化分析的能力；第二种是通过智能分析算法，发现一些可能专家也不一定能够发现的隐含路径，实际上这项工作如果依靠第一种方法形成的知识库，再去做相关的分析，会取得事半功倍的效果，如果仅仅依靠纯粹的机器学习或者深度学习，往往效果不佳；第三种方法是大家最应该进行的，但是往往又是被大家忽视的方法，那就是通过历史的案例或者运维工作中的案例来发现运维经验。

第一种方法比较直观，专家根据其多年运维工作的经验进行总结，然后将总结后的知识点导入图数据库。比如下面就是一个专家梳理的Oracle latch hit过低的诊断路径。

第二种方法听起来似乎比较简单，可以不依托专家，仅仅通过异常检测等手段发现新的诊断路径。不过事实上不是这样的，采用第二种方法更要依赖于专家的参与。数据的标注需要专家，分析结果的确认与提升需要专家。比如说我们通过深度学习发现了一个模型，这个模型实际上只能告诉我们某个事件可能与某个现象有关，但是里面的深层次关系与分析路径往往是不明晰的，因为深度学习无法明确的告知我们明确的故障传播路径。而专家由于经历的案例有限，往往也存在一定的局限性，可能以前并无这方面的思考与经验。通过深度学习获得的经验交给专家后，专家可以根据他所掌握的运维知识与经验对此进行分析，从而从理论上找到人工智能发现的知识的内在原理，从而可以发现新的故障传播路径，并根据这些发现形成新的诊断路径，完善补充知识图谱。

第三种方法实际上是十分有价值的，可以依靠我们以往发生的故障与运维经验梳理出新的诊断路径。但是不幸的是，第三种访问依然需要专家的介入。作为今天重点介绍的方法，我们用一个十多年前的案例来做一个演示。

这是一个几乎没有负载的小系统，从load profile上看，负载几乎微乎其微。不过从等待事件上看，这个系统存在比较多的问题：

前台等待事件：

后台等待事件：

可以看出，写IO相关的等待事件都异乎寻常的高。而系统负载很低，后端的存储系统也没有问题。

而在同一个时段，正常的时候，负载情况是这样的：

当这个数据库启动了一个月后，就开始处于不正常状态，此时如果重启数据库或者重启服务器，这个系统就又恢复正常了。说到这里，有些老DBA可能就已经猜到了这个问题的原因了。在当时10.2.0.4的数据库里，跑在LINUX 5.X版本上，如果没有启用HUGEPAGE，就会出现类似的情况。这种情况出现的时候，SYS CPU的使用率会达到USER CPU的80%以上，甚至高于USER CPU。

针对这个案例，经过专家梳理，就可以形成一个新的运维经验，同时也可以形成新的运维经验的诊断路径。新的运维经验的触发条件可以被描述为：“UPTIME > $1 AND ((LOG FILE PARALLEL WRITE >$2) OR (DB FILE PARALLEL WRITE >$3)) AND (SYS CPU > (USER CPU*$4)) AND (HUGEPAGE_USED=FALSE）AND (LOAD_SCORE<$5)”。

可能有朋友看到这里就有些疑惑了，“AIOPS”，从老白你今天所说的AIOPS里看不出任何AI的成分来。这句话说的有点对，任何强大的AIOPS背后都离不开运维专家艰辛的劳动。AIOPS能力的起点起于人类专家的经验，不过随着知识图谱的积累，人类专家的经验会以人类无法企及的规模进行积累，并且在实际运维工作中不断通过自动化的推理计算发挥作用。无论是人类专家梳理出来的知识，还是通过专家梳理案例获得的知识，还是通过机器学习发现的新知识构建的越来越丰富的知识体系，在AI算法的加持下，就会输出比人类专家更为强大的分析能力，我想AIOPS超越人类专家的能力，也指日可待了。

数据库

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

智能运维中诊断路径的积累方法

评论