故障自愈方法和装置、设备及存储介质与流程

本公开涉及网络运维领域，尤其涉及一种故障自愈方法和装置、设备及存储介质。

背景技术：

对于量产服务器与网络产品的故障排除，在大多数情况下的操作是类似的，传统的运维人员会浪费大量的时间在重复的排障流程上排除几乎相似的故障。随着机器学习的流行，一些企业开始试图通过收集分析以往的排障修复操作记录以发现共通处，自动生成排障指南以实现智能运维。不管是利用通用或专业领域的知识图谱数据，通过纯机器学习建立ai的模型，数据量大，人力和时间的投入大，效率低下。

技术实现要素：

有鉴于此，本公开提出了一种故障自愈方法，包括：

提取修复操作记录和对应的告警信息；

将所述修复操作记录和所述告警信息进行参数化得到多个参数；

将多个所述参数进行实例化得到多个变量；

依据多个所述变量建立知识模型和自愈脚本，并得到包含有所述知识模型与所述自愈脚本的映射关系的知识问答库；

依据故障的描述从所述知识模型中选择对应的所述自愈脚本进行故障处理。

在一种可能的实现方式中，所述参数包括宿主参数、采集项参数、描述信息参数和修复脚本参数；

所述变量包括：宿主变量、采集项变量和描述信息变量。

在一种可能的实现方式中，将所述修复操作记录和所述告警信息进行参数化得到多个参数包括：

在所述修复操作记录中获取修复脚本；

将所述告警信息和所述修复脚本依据pythonansible进行参数化提取得到宿主参数、采集项参数、描述信息参数和修复脚本参数。

在一种可能的实现方式中，将多个所述参数进行实例化得到多个变量包括：

使用图数据库将所述宿主参数、所述采集项参数和所述描述信息参数进行实例化得到宿主变量、采集项变量和描述信息变量。

在一种可能的实现方式中，依据多个所述变量建立知识模型和自愈脚本，并得到包含有所述知识模型与所述自愈脚本的映射关系的知识问答库：

将所述宿主变量、采集项变量和描述信息变量建立数据库表格得到所述知识模型；

依据所述修复脚本参数建立所述自愈脚本；

将所述描述信息变量与所述自愈脚本建立映射关系得到知识问答库。

在一种可能的实现方式中，依据故障的描述从所述知识模型中选择对应的所述自愈脚本进行故障处理包括：

依据所述故障的描述在所述知识模型中进行匹配；

若所述知识模型存在所述故障的描述，则选择对应的所述自愈脚本进行故障处理。

在一种可能的实现方式中，还包括使用ai模型泛化所述知识模型；

在使用ai模型泛化所述知识模型时包括：

使用nlpbert模型对自定义告警信息的描述信息和所述数据库表格中的描述信息参数进行自动化匹配得到评分；

将评分最高的所述数据库表格中的描述信息对应的所述自愈脚本作为所述自定义告警信息的描述信息的自愈脚本。

根据本公开的另一方面，提供了一种故障自愈装置，其特征在于，包括修复操作记录提取模块、参数化模块、实例化模块、知识模型建立模块和故障处理模块；

所述修复操作记录提取模块，被配置为提取修复操作记录和对应的告警信息；

所述参数化模块，被配置为将将所述修复操作记录和所述告警信息进行参数化得到多个参数；

所述实例化模块，被配置为将多个所述参数进行实例化得到多个变量；

所述知识模型建立模块，被配置为依据多个所述变量建立知识模型和自愈脚本，并得到包含有所述知识模型与所述自愈脚本的映射关系的知识问答库；

故障处理模块，被配置依据故障的描述从所述知识模型中选择对应的所述自愈脚本进行故障处理。

根据本公开的另一方面，提供了一种故障自愈设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现前面任一所述的方法。

根据本公开的另一方面，提供了一种非易失性计算机可读存储介质，其上存储有计算机程序指令，其特征在于，所述计算机程序指令被处理器执行时实现前面任一所述的方法。

通过提取修复操作记录和对应的告警信息，将修复操作记录和告警信息进行参数化得到多个参数，将多个参数进行实例化得到多个变量，依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库，依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理。在本公开方法中基于运维人员对某种告警的第一次修复的操作为机器，对修复操作日志模板化，然后在自动自愈过程中，将模板参数的实例化，建立了自己的自愈脚本模板和告警的知识问答库，把第一次修复的方法进行推广和泛化，达到告警自动自愈的实现，这是一种简单，高效和准确的方法。

根据下面参考附图对示例性实施例的详细说明，本公开的其它特征及方面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。

图1示出本公开实施例的故障自愈方法的流程图；

图2示出本公开实施例的故障自愈方法的参数化示意图；

图3示出本公开实施例的故障自愈方法的实例化示意图；

图4示出本公开实施例的故障自愈方法的数据库表格示意图；

图5示出本公开实施例的故障自愈方法的泛化匹配示意图；

图6示出本公开实施例的故障自愈装置的框图；

图7示出本公开实施例的故障自愈设备的框图。

具体实施方式

以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。

图1示出根据本公开一实施例的故障自愈方法的流程图。如图1所示，该故障自愈方法包括：

步骤s100，提取修复操作记录和对应的告警信息，步骤s200，将修复操作记录和告警信息进行参数化得到多个参数，步骤s300，将多个参数进行实例化得到多个变量，步骤s400，依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库，步骤s500，依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理。

通过提取修复操作记录和对应的告警信息，将修复操作记录和告警信息进行参数化得到多个参数，将多个参数进行实例化得到多个变量，依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库，依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理。在本公开方法中基于运维人员对某种告警的第一次修复的操作为机器，对修复操作日志模板化，然后在自动自愈过程中，将模板参数的实例化，建立了自己的自愈脚本模板和告警的知识问答库，把第一次修复的方法进行推广和泛化，达到告警自动自愈的实现，这是一种简单，高效和准确的方法。

具体的，参见图1，首先执行步骤s100，提取修复操作记录和对应的告警信息。

在一种可能的实现方式中，在出现告警信息时，首先由运维人员在终端进行操作，进行第一次人为修复，在操作过程中会生成修复操作记录，其中，包括通过webshell堡垒机或linuxscript中的一种工具自动收集和保存操作日志，然后进行提取修复操作记录和对应的告警信息，在提取修复操作记录时，包括使用终端软件提取修复操作记录或使用接口中的任意一种。举例来说，运维人员在终端进行操作，进行第一次人为修复，操作环境为shell环境下，使用webshell堡垒机进行修复操作记录的保存，使用终端的软件mobaxterm进行修复操作记录的提取，接着提取告警信息，将告警信息通过特定标识与修复操作记录进行关联，示例性的，若告警信息为“httpserviceisdown”，修复操作记录中包含“http”或“httpservice”等字符，则将这条修复操作记录与告警信息进行关联。

进一步的，参见图1，执行步骤s200，将修复操作记录和告警信息进行参数化得到多个参数。

在一种可能的实现方式中，在提取到修复操作信息和告警信息后，将修复操作记录和告警信息进行参数化得到多个参数，其中包括：在修复操作记录中获取修复脚本，将告警信息和修复脚本使用pythonansible进行参数化提取得到宿主参数、采集项参数、描述信息参数和修复脚本参数。举例来说，运维人员在pythonansible的模板中设定好需要提取的参数，具体的，将所需要提取的参数使用双“{”进行标注，示例性的，在语句“systemctlrestarthttpd”中需要对“httpd”进行参数化，则在pythonansible的模板中加入“{”后变成“systemctlrestart{{service_name}}”，即提取“httpd”作为“service_name”(服务名称)，接着在使用中按照设定好的需要提取的部分进行参数化，提取到各项参数，参见图2，其中提取到的宿主参数为宿主节点的id信息，采集项参数可以为“process/name＝httpd”，即告警信息的名称中包括“httpd”字符或者进程中包括“httpd”字符，描述信息即为对于本次故障的描述性语句，示例性的，描述信息为“httpserviceisdown”，修复操作记录中的修复脚本为“servicerestart”。

需要说明的是，在告警信息进行参数化的时，可以包括更多参数，示例性的，其中还可以包括时间项，告警类型项等信息，本公开不进行限定。

进一步的，参见图1，执行步骤s300，将多个参数进行实例化得到多个变量。

在一种可能的实现方式中，在将修复操作记录和告警信息进行参数化得到多个参数之后，将多个参数进行实例化得到多个变量，该步骤还包括：使用图数据库将宿主参数、采集项参数和描述信息参数进行实例化得到宿主变量、采集项变量和描述信息变量。参见图3，该图为使用neo4j图数据库的查询语言cypherquerylanguage在shell日志(修复操作日志)的参数化时，进行推理和归纳，还可以找到可实例化的其他参数包括端口号(port)、进程名称(processname)和服务名(servicename)，然后扩充建立的pythonansible的模板中的参数，然后进行pythonansible的模板中的参数的实例化。其中，实例化后的变量即包括“port”、“processname”和“servicename”，示例性的，其中所对应的参数为端口号：“8080”，进程名称：“htlpd”和服务名称：“httpdservice”。

需要说明的是，本公开不对图数据库的类型进行限定，可以达到所需功能即可。

进一步的，参见图1，执行步骤s400，依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库。

在一种可能的实现方式中，在得到各变量之后，依据多个变量使用知识问答库问答方式建立知识模型和自愈脚本，知识问答库问答即为kb-qa，其中，知识问答库(kb)即为自愈脚本，问答(qa)为告警信息的描述信息，该步骤包括：将宿主变量、采集项变量和描述信息变量建立数据库表格得到知识模型，依据修复脚本参数建立自愈脚本，将描述信息变量与自愈脚本建立映射关系得到知识问答库。举例来说，参见图4，现有变量包括宿主变量(script_id)，对应的为宿主参数，即为宿主节点的id信息；采集项变量(alarmmetric)；描述信息变量(alarm_descirptions)；分别将各变量对应的参数存入数据库表格中，示例性的，采集项变量(alarmmetric)一列中包括：“process/name＝httpd”和“net.port.listen/port＝8080”，其中对于同一个采集项参数可以对应多条描述信息参数，示例性的，采集项参数为“process/name＝httpd”对应的描述信息变量(alarm_descirptions)包括四条描述信息参数，分别为：“httpserviceisdown”“apacheserviceisdown”“apacheservicehasgone”“httpservicehasgone”，当出现以上四条描述信息中任意一条的描述信息时，均代表同一意义的告警信息，将收集到的描述信息添加到表格中，与其他变量中的参数对应起来，即建立了知识模型，需要指出的是，描述信息变量对应的表格中可以手动实时在线的修改，增加灵活性和准确性，接着，将同一告警信息对应的修复脚本参数进行编译成可以在shell环境中运行的脚本，即建立了自愈脚本，将这一自愈脚本与对应的告警信息中所有描述信息参数建立映射关系，即完成了知识问答库的创建。

进一步的，参见图1，执行步骤s500，依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理。

在一种可能的实现方式中，在创建完成知识问答库后，即可依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理，该步骤包括：依据故障的描述在知识模型中进行匹配，若知识模型存在故障的描述，则选择对应的自愈脚本进行故障处理。具体的，举例来说，描述信息变量(alarm_descirptions)包括四条描述信息参数，分别为：“httpserviceisdown”“apacheserviceisdown”“apacheservicehasgone”“httpservicehasgone”，若故障的描述为：“httpserviceisdown”，即在知识模型中存在这条描述信息，接着可以在知识问答库中寻找对应的自愈脚本，然后自动执行自愈脚本，即完成了故障处理，示例性的，自愈脚本为：“servicerestart”，在shell环境中执行这条语句，将该服务重启，同样的，若故障的描述为：“apacheservicehasgone”，也会在知识问答库中寻找到同一条自愈脚本，同样用自愈脚本为：“servicerestart”解决问题。

另外的，本公开的故障自愈方法还包括使用ai模型拓展知识模型，即，使用nlpbert模型算法进行泛化，在一种可能的实现方式中，在使用ai模型拓展知识模型时包括：使用nlpbert模型对自定义告警信息的描述信息和数据库表格中的描述信息参数进行自动化匹配得到评分，将评分最高的数据库表格中的描述信息对应的自愈脚本作为自定义告警信息的描述信息的自愈脚本。该步骤的前提是基于已建立的知识问答库，将其中的告警信息中的描述信息做进一步的自然语言相似度匹配，可以把同一个自愈脚本推广到其他同类告警信息中，参见图5，用户对apacheservice进程的监控建了一个新的告警信息，该告警信息的描述信息为“apacheserverhasproblem”。该描述信息并不在标准的alarm_description里面，但根据使用的nlp的bert模型，可以将数据库表格中的已有告警信息进行匹配评分，匹配分数最高的告警信息的描述信息为：“apacheservicehasdown”，其匹配到的自愈脚本依然是准确的。

需要说明的是，尽管以上述各个步骤作为示例介绍了本公开的故障自愈方法如上，但本领域技术人员能够理解，本公开应不限于此。事实上，用户完全可根据个人喜好和/或实际应用场景灵活设定故障自愈方法，只要达到所需功能即可。

这样，通过提取修复操作记录和对应的告警信息，将修复操作记录和告警信息进行参数化得到多个参数，将多个参数进行实例化得到多个变量，依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库，依据故障的描述从知识模型中选择对应的自愈脚本进行故障处理。在本公开方法中基于运维人员对某种告警的第一次修复的操作为机器，对修复操作日志模板化，然后在自动自愈过程中，将模板参数的实例化，建立了自己的自愈脚本模板和告警的知识问答库，把第一次修复的方法进行推广和泛化，达到告警自动自愈的实现，这是一种简单，高效和准确的方法。

进一步的，根据本公开的另一方面，还提供了一种故障自愈装置100。由于本公开实施例的故障自愈装置100的工作原理与本公开实施例的故障自愈方法的原理相同或相似，因此重复之处不再赘述。参见图6，本公开实施例的故障自愈装置100包括修复操作记录提取模块110、参数化模块120、实例化模块130、知识模型建立模块140和故障处理模块150；

所述修复操作记录提取模块110，被配置为提取修复操作记录和对应的告警信息；

所述参数化模块120，被配置为将将所述修复操作记录和所述告警信息进行参数化得到多个参数；

所述实例化模块130，被配置为将多个所述参数进行实例化得到多个变量；

所述知识模型建立模块140，被配置为依据多个变量建立知识模型和自愈脚本，并得到包含有知识模型与自愈脚本的映射关系的知识问答库；

故障处理模块150，被配置依据故障的描述从所述知识模型中选择对应的所述自愈脚本进行故障处理。

更进一步地，根据本公开的另一方面，还提供了一种故障自愈设备200。参阅图7，本公开实施例故障自愈设备200包括处理器210以及用于存储处理器210可执行指令的存储器220。其中，处理器210被配置为执行可执行指令时实现前面任一所述的故障自愈方法。

此处，应当指出的是，处理器210的个数可以为一个或多个。同时，在本公开实施例的故障自愈设备200中，还可以包括输入装置230和输出装置240。其中，处理器210、存储器220、输入装置230和输出装置240之间可以通过总线连接，也可以通过其他方式连接，此处不进行具体限定。

存储器220作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序和各种模块，如：本公开实施例的故障自愈方法所对应的程序或模块。处理器210通过运行存储在存储器220中的软件程序或模块，从而执行故障自愈设备200的各种功能应用及数据处理。

输入装置230可用于接收输入的数字或信号。其中，信号可以为产生与设备/终端/服务器的用户设置以及功能控制有关的键信号。输出装置240可以包括显示屏等显示设备。

根据本公开的另一方面，还提供了一种非易失性计算机可读存储介质，其上存储有计算机程序指令，计算机程序指令被处理器210执行时实现前面任一所述的故障自愈方法。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。