CN113590370B - 一种故障处理方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了故障处理方法、装置、设备及存储介质，涉及数据处理技术领域，尤其涉及故障处理技术领域。具体实现方案为：获得业务系统产生的报警信息；根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；根据所述原因信息和所述报警信息，获得包括故障自愈任务的故障自愈方案；通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。应用本公开实施例提供的方案，能够对业务系统产生的故障进行故障自愈。

Description

一种故障处理方法、装置、设备及存储介质

技术领域

本公开涉及数据处理技术领域，尤其涉及故障处理技术领域。进一步涉及一种故障处理方法、装置、设备及存储介质。

背景技术

随着企业大力推进IT数字化转型，企业为用户提供的各种业务越来越多的通过线上业务系统实现。另外，企业为满足用户不断变化的用户需求，上述业务系统为用户提供的各种业务也越来越丰富，因此，业务系统的业务量越来越大，进而业务系统发生故障的概率也越来越高。

发明内容

本公开提供了一种故障处理方法、装置、设备以及存储介质。

根据本公开的一方面，提供了一种故障处理方法，包括：

获得业务系统产生的报警信息；

根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；

根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；

根据所述原因信息和所述报警信息，获得包括故障自愈任务的故障自愈方案；

通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。

根据本公开的另一方面，提供了一种故障处理装置，包括：

信息获得模块，用于获得业务系统产生的报警信息；

数据获得模块，用于根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；

信息确定模块，用于根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；

方案获得模块，用于根据所述原因信息和所述报警信息，获得包括故障自愈任务的故障自愈方案；

故障自愈模块，用于通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行故障处理方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行故障处理方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现故障处理方法。

由以上可见，应用本公开实施例提供的方案进行故障自愈时，由于故障自愈任务既考虑了报警信息自身的信息，又考虑了触发产生报警信息的故障的原因信息，原因信息能够反映触发产生报警信息的故障的原因，因此，故障自愈任务不仅能够从报警信息所呈现出来的故障直观层面进行故障自愈，还能够从故障的原因信息所呈现出来的根源层面进行故障自愈，进而实现了故障问题的精准解决，有效提升了故障止损的效率。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的一种业务系统的故障管理全流程的示意图；

图2为本公开实施例提供的第一种故障处理方法的流程示意图；

图3为本公开实施例提供的第二种故障处理方法的流程示意图；

图4为本公开实施例提供的第三种故障处理方法的流程示意图；

图5a为本公开实施例提供的第四种故障处理方法的流程示意图；

图5b为本公开实施例提供的第五种故障处理方法的流程示意图；

图6为本公开实施例提供的第六种故障处理方法的流程示意图；

图7为本公开实施例提供的一种故障处理方法的流程框图；

图8为本公开实施例提供的第一种故障处理装置的结构示意图；

图9为本公开实施例提供的第二种故障处理装置的结构示意图；

图10为本公开实施例提供的第三种故障处理装置的结构示意图；

图11a为本公开实施例提供的第四种故障处理装置的结构示意图；

图11b为本公开实施例提供的第五种故障处理装置的结构示意图；

图12为本公开实施例提供的第六种故障处理装置的结构示意图；

图13为本公开实施例提供的一种电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

由于业务系统发生故障时，需要对故障进行有效解决，本公开实施例提供了一种故障处理方法、装置、设备及存储介质。

本公开的一个实施例中，提供了一种故障处理方法，包括：

获得业务系统产生的报警信息；

根据业务系统的监控数据，获得与报警信息具有关联性的关联数据；

根据关联数据，确定触发产生报警信息的故障的原因信息；

根据原因信息和报警信息，获得包括故障自愈任务的故障自愈方案；

通过执行故障自愈方案中包括的故障自愈任务，进行故障自愈。

由于故障自愈任务既考虑了报警信息自身的信息，又考虑了触发产生报警信息的故障的原因信息，原因信息能够反映触发产生报警信息的故障的原因，因此，故障自愈任务不仅能够从报警信息所呈现出来的故障直观层面进行故障自愈，还能够从故障的原因信息所呈现出来的根源层面进行故障自愈，进而实现了故障问题的精准解决，有效提升了故障止损的效率。

首先，对本公开实施例的应用场景进行说明。

本公开实施例的应用场景为：对业务系统发生的故障进行故障自愈的运维场景。

业务系统配置有故障管理全流程，故障管理全流程的各阶段从开始到结束可以依次为：故障预防阶段、发现故障阶段、止损、根因定位以及恢复服务阶段、总结改进阶段，故障自愈是上述止损、根因定位以及恢复服务阶段中的一个环节。

以图1为例，图1示出了业务系统的故障管理全流程的示意图。

从图1可以看到，在止损、根因定位以及恢复服务阶段中，故障自愈的过程为：从响应报警信息到故障自愈方案生成、从故障自愈方案生成到开始执行故障自愈方案、从开始执行故障自愈方案到结束执行故障自愈方案这一整个过程。故障自愈所经历的时长称为止损时长，止损时长越短，业务损失越小。

以下对本公开实施例提供的故障处理方法进行具体说明。

参见图2，图2为本公开实施例提供的第一种故障处理方法的流程示意图，上述方法包括以下步骤S201-步骤S205。

步骤S201：获得业务系统产生的报警信息。

业务系统是用于向用户提供业务的系统，例如，上述业务系统可以是搜索业务系统、云存储业务系统、游戏业务系统等。

当业务系统产生报警信息时，表示业务系统中出现了故障，进而发生报警，报警信息中一般记录有报警的描述信息，如，报警时间、发生报警的业务节点的名称等信息。

上述报警信息可以是基于业务系统的监控结果获得的信息。一种实现方式中，可以对业务系统运行过程中产生的不同类型的信息进行监控，当监控到业务系统产生报警类型的信息，也就是，报警信息时，可以从存储报警信息的信息库中获取报警信息。

例如：上述信息库可以位于事件平台，业务系统中配置有事件平台，这样事件平台用于存储业务系统产生的报警信息，在此基础上，可以按照预设时间间隔从事件平台中获取报警信息，上述预设时间间隔可以为1s、5s、10s等。

步骤S202：根据业务系统的监控数据，获得与报警信息具有关联性的关联数据。

业务系统运行过程中可能会产生各种类型的数据，对这些数据进行监控得到监控数据。

上述监控数据可以是来自业务系统配置的不同功能子系统的监控数据，例如，上述监控数据可以为：来自监控功能子系统中记录的业务系统产生的各种报警信息、业务系统的运行状态等，上述监控数据还可以为：来自系统变更子系统中记录的业务系统变更信息、来自容量子系统中记录的业务系统的可用资源量等。

关联数据中可以包括与报警信息具有关联性的监控数据，还可以包括对监控数据进行分析得到的、与报警信息具有关联性的数据。

具体获得关联数据的方式可以参见图3对应的实施例，在此不进行详述。

步骤S203：根据关联数据，确定触发产生报警信息的故障的原因信息。

上述原因信息表征触发产生报警信息的故障的原因。

例如：业务系统发生的故障为：网络链路出现故障，这一故障会触发产生的报警信息为：业务节点的网络流量下跌，上述故障的原因是网络链路出现断路，所以，触发产生上述报警信息的故障的原因信息为：“网络链路出现断路”。

由于关联数据是与报警信息具有关联性的数据，又由于在业务系统出现故障时，这一故障可能会带来一系列连锁效应，同时这一故障也可能是由其他问题导致的，在这一连串的连锁效应中所产生的各种信息是相互关联的，基于具有关联关系的各种信息可以确定导致故障产生的原因信息，因此，根据关联数据能够确定触发产生报警信息的故障的原因信息。

一种实现方式中，可以预先设定报警信息与原因信息之间的对应关系，由于多种故障均可能会引起相同的报警，因此，一个报警信息可能会与多种原因信息存在对应关系，基于此，可以先从上述对应关系中，确定当前的报警信息对应的各备选原因信息，从各备选原因信息中选择与关联数据相关的备选原因信息，作为触发产生报警信息的故障的原因信息。

上述对应关系可以是由专家或者运维工作人员根据经验确定的。

例如：当前的报警信息为：业务系统A流量下跌，从预设的各对应关系中，确定上述报警信息的三种备选原因信息分别为：“网络出现故障”、“系统变更”、“设备A故障”，所获得的关联数据中包括：网络流量波动大、设备B故障，备选原因信息为“网络出现故障”与关联数据中“网络流量波动大”是相关的，可以将“网络出现故障”确定为触发产生报警信息的故障的原因信息。

步骤S204：根据原因信息和报警信息，获得包括故障自愈任务的故障自愈方案。

故障自愈方案中包括的故障自愈任务的数量可以是1个，也可以是多个。当故障自愈任务的数量是多个时，故障自愈方案中还包括各个故障自愈任务的执行顺序，其中，各个故障自愈任务之间的执行顺序可以是并行执行顺序，也可以是串行执行顺序。

获得故障自愈方案的具体实现方式可以参见图4、图5a、图5b、图6对应的实施例，在此不进行详述。

步骤S205：通过执行故障自愈方案中包括的故障自愈任务，进行故障自愈。

一种实现方式中，可以按照故障自愈方案中包括的故障自愈任务的执行顺序，依次执行各故障自愈任务，实现故障自愈。

另一种实现方式中，可以确定与故障自愈任务的任务类型相匹配的任务执行工具；按照故障自愈方案中各故障自愈任务的执行顺序，调用各故障自愈任务对应的任务执行工具，执行各故障自愈任务，进行故障自愈。

各任务执行工具用于执行不同任务类型的任务。例如：上述任务执行工具可以包括：网络链路关闭工具、重启工具、健康度检查工具等。

由于上述任务执行工具是与故障自愈任务的任务类型相匹配的，与任务的任务类型相匹配的任务执行工具能够执行该任务，因此，通过调用上述各任务执行工具，能够执行故障自愈任务，从而实现故障自愈。

由以上可见，应用本实施例提供的方案进行故障自愈时，由于故障自愈任务既考虑了报警信息自身的信息，又考虑了触发产生报警信息的故障的原因信息，原因信息能够反映触发产生报警信息的故障的原因，因此，故障自愈任务不仅能够从报警信息所呈现出来的故障直观层面进行故障自愈，还能够从故障的原因信息所呈现出来的根源层面进行故障自愈，进而实现了故障问题的精准解决，有效提升了故障止损的效率。

另外，由于关联数据是与报警信息具有关联性的数据，又由于在业务系统出现故障时，这一故障可能会带来一系列连锁效应，同时这一故障也可能是由其他问题导致的，在这一连串的连锁效应中所产生的各种信息是相互关联的，基于具有关联关系的各种信息可以确定导致故障产生的原因信息，因此，根据关联数据能够较为准确地确定触发产生报警信息的故障的原因信息，进而根据原因信息和报警信息所获得的故障自愈方案对原因信息对应的故障进行故障自愈的成功率越高。

以下结合图3对上述步骤S202中获得关联数据的具体实现方式进行说明。图3为本公开实施例提供的第二种故障处理方法的流程示意图，上述步骤S202，可以按照以下步骤S2021-S2024中的至少一个步骤获得信息，作为与报警信息具有关联性的关联数据。

步骤S2021：从监控数据中，获得报警信息中记录的报警时间在第一时间段内且针对目标业务节点的其他报警信息。

上述报警时间为：产生报警信息的时间。

上述第一时间段可以为：报警时间向前延长第一预设时长的时间段，上述第一预设时长可以由工作人员根据经验设定。例如：报警时间为00:10:00，第一预设时长为5min，第一时间段为00:05:00-00:10:00；上述第一时间段还可以为：报警时间分别向前向后延长一定时长的时间段。例如：报警时间为00:10:00，向前延长的时长为5min，向后延长的时长为8min，第一时间段为00:05:00-00:18:00；上述第一时间段还可以为：报警事件向后延长第二预设时长的时间段，上述第二预设时长可以由工作人员根据经验设定。例如：报警时间为00:10:00，第二预设时长为8min，第一时间段为00:10:00-00:18:00。上述第一预设时长、第二预设时长可以是相同的，也可以是不同的。

上述目标业务节点为：报警信息针对的业务节点。报警信息针对的业务节点是指：产生上述报警信息的业务节点。上述目标业务节点可以为业务模块、机房或设备等。

可选的，可以从监控数据中获取上述第一时间段内生成的报警信息，从获取到的报警信息中确定针对目标业务节点的其他报警信息。

由于在一个时间段内针对同一节点的各报警信息之间具有关联关系的概率较大，所以第一时间段内针对目标节点的其他报警信息与报警信息之间具有关联关系的概率较大，将上述其他报警信息确定为关联数据的准确度高。

步骤S2022：确定触发目标故障类型的故障的影响因子，根据监控数据中记录的报警时间在第二时间段内的影响因子的取值，获得表征影响因子波动的第一信息。

上述目标故障类型为：报警信息中记录的故障类型。上述目标故障类型可以是触发报警信息产生的故障的故障类型。

上述影响因子表征导致目标故障类型的故障产生的影响因素。

可选的，可以从预先设定的故障类型与影响因子之间的对应关系中，确定目标故障类型对应的影响因子，作为触发目标故障类型的故障的影响因子。

例如：以目标故障类型为网络流量下跌类型为例，从预设的各对应关系中，可以确定上述目标故障类型对应的各影响因子包括：上游业务模块的网络流量、外网链路质量、内网链路质量。

上述第二时间段可以为报警时间向前延长第三预设时长的时间段，还可以为报警时间分别向前向后延长一定时长的时间段，还可以为报警事件向后延长第四预设时长的时间段。上述第三预设时长与第四预设时长可以是相同的，也可以是不同的。

上述第一信息表征影响因子波动的情况。以影响因子为网络流量为例，上述第一信息表征网络流量波动情况。

一种实施方式中，可以计算上述第二时间段内影响因子的最大值与最小值之间的差异值，将上述差异值确定为第一信息。当上述差异值大于预设差异阈值时，表示在第二时间段内影响因子波动较大；当上述差异值不大于预设差异阈值时，表示在第一时间段内影响因子波动较平稳。

另一种实施方式中，还可以计算第二时间段内影响因子的取值的平均值，将上述平均值确定为第一信息。当上述平均值大于预设平均阈值时，表示在第二时间段内影响因子波动较大；当上述平均值不大于预设平均阈值时，表示在第一时间段内影响因子波动较平稳。

由于影响因子是触发报警信息中记录的故障类型的故障的影响因子，在一定时间段内影响因子的取值与该时间段内产生的报警信息具有关联关系，又由于上述第一信息是根据包括报警信息的报警时间的第二时间段内影响因子的取值确定的，上述第一信息是与第二时间段内影响因子的取值相关的，所以，第一信息与上述报警信息具有关联关系，将第一信息确定为关联数据的准确度高。

步骤S2023：根据监控数据中记录的最新系统更新时间和报警时间，获得表征业务系统在报警信息产生前的第三时间段内是否发生系统更新的第二信息。

第三时间段为报警时间向前延长第五预设时长的时间段。

最新系统更新时间是指对系统更新的最近时间。系统更新是指对系统进行升级、修复等操作。

可选的，可以判断上述第三时间段内是否包含最新系统更新时间，若为是，确定第二信息为；第三时间段内发生系统更新；若为否，确定第二信息为；第三时间段内未发生系统更新。

可选的，当确定第三时间段内发生系统更新，还可以获得系统更新的更新内容、更新对象、更新时间等信息，可以将所获得的上述信息确定为与报警信息具有关联性的关联数据。

由于第二信息是表征报警信息产生前的第三时间段内是否发生系统更新的信息，又由于发生系统更新导致业务系统产生故障的概率较大，从而易产生报警信息，所以表征第三时间段内是否发生系统的第二信息与报警信息之间关联性高，将第二信息确定为关联数据的准确度高。

步骤S2024；从监控数据中，选择报警时间在第四时间段内业务系统的可用资源量。

第四时间段可以为报警时间向前延长第六预设时长的时间段，还可以为报警时间分别向前向后延长一定时长的时间段，还可以为报警时间向后延长第七预设时长的时间段。上述第六预设时长与第七预设时长可以是相同的，也可以是不同的。

上述可用资源量是指业务系统响应用户请求的可用资源的资源量，上述可用资源可以包括带宽资源、计算资源等。

具体的，可以从监控数据中获得第四时间段内各时刻的可用资源量，对各可用资源量进行统计分析，将统计分析值确定为上述第四时间段内业务系统的可用资源量。上述统计分析可以是计算平均值、中值等方式。

由于业务系统的可用资源量会对业务系统产生影响，当发生故障时产生报警信息，如可用资源量低会造成业务系统难以响应用户请求的故障，从而产生对应的报警信息。所以包括报警时间的第四时间段内业务系统的可用资源量与报警信息之间具有关联关系，将上述业务系统的可用资源量确定为关联数据的准确度高。

上述各个步骤中，第一时间段、第二时间段、第三时间段、第四时间段可以是相同的，也可以是不同的。

在确定关联数据时，可以选择其中一个步骤获得信息，作为与报警信息具有关联性的关联数据，还可以选择其中多个步骤获得信息，将所获得的多个信息作为与报警信息具有关联性的关联数据。

以下结合图4对上述步骤S204中获得故障自愈方案的具体实现过程进行说明。

图4为本公开实施例提供的第三种故障处理方法的流程示意图，在上述实施例的基础上，上述步骤S204，可以按照以下步骤S2041-步骤S2042实现。

步骤S2041：根据报警信息，在已知故障自愈方案中，查找对原因信息对应的故障进行自愈处理的故障自愈方案。

上述已知故障自愈方案可以为：对已经发生过的故障进行自愈处理的方案，在这种情况下，上述方案可以存储于服务端中的方案库中。

上述已知故障自愈方案还可以为：对可能发生的故障预先生成的方案。可选的，可以是由专家或者运维工作人员根据经验确定对上述可能发生的故障进行自愈处理的方案。在这种情况下，可以由专家或者运维工作人员通过用户端提供的方案录入接口，输入所确定的故障自愈方案，服务端接收到上述故障自愈方案并存储于上述方案库中。

例如：在业务系统的用户端的用户界面中，可以配置自愈控制台，专家或者运维工作人员可以通过自愈控制台输入故障自愈方案，业务系统可以将用户输入的故障自愈方案中存储至自愈方案规则库中，上述自愈方案规则库中存储各已知故障自愈方案。

本公开的一个实施例中，可以提取报警信息中预设字段的目标字段值；基于目标字段值，在已知故障自愈方案中，查找对原因信息对应的故障进行自愈处理、且包括目标自愈任务的故障自愈方案。

上述预设字段可以包括：报警信息的报警时间、报警信息所针对的业务节点的标识、生成报警信息的设备的标识、上述设备所在机房的标识、触发生成报警信息的实例(例如，程序、算法等)的标识以及异常描述信息。

上述报警信息所针对的业务节点的标识是指：触发生成报警信息的故障发生的业务节点的标识，如业务节点的编号、名称等。上述业务节点可以包括业务模块等。

上述机房的标识是指生成报警信息的设备所在机房的标识，上述机房的标识可以为机房所在地、机房编号等。

上述设备的标识是指生成报警信息的的设备的标识。上述设备的标识可以为设备IP地址(Internet Protocol Address，互联网协议地址)、MAC地址(Media Access ControlAddress，媒体存取控制位址)等。

由于上述预设字段包括报警信息的报警时间，报警信息所针对的业务节点的标识、生成报警信息的设备的标识、上述设备所在机房的标识、触发生成报警信息的实例的标识，这些字段的取值从不同方面表示报警信息的具体情况，通过提取报警信息中上述预设字段的取值，可以较为准确地反映报警信息。

上述目标字段值可以是对报警信息进行解析、提取得到的。

上述目标自愈任务为：依据预设字段的目标字段值设置的故障自愈任务。例如：以目标字段值为机器的标识为例，依据上述目标字段值设备的故障自愈任务可以是对标识为目标字段值的机器进行重启操作。

由于已知故障自愈方案中记录有所针对的原因信息，基于此，可以以上述原因信息作为关键字，从各已知故障自愈方案记录的原因信息进行关键字匹配，获得针对上述原因信息的故障进行自愈处理的已知故障自愈方案；

又由于已知故障自愈方案包括故障自愈任务，故障自愈任务中可以记录所针对的预设字段的字段值，基于此，可以以目标字段值为关键字，从所获得的各已知故障自愈方案包括的故障自愈任务记录的各字段值进行关键字匹配，确定依据上述目标字段值设置的故障自愈任务，进而得到包括上述故障自愈任务的故障自愈方案。

由于是从对原因信息对应的故障进行自愈处理的已知故障自愈方案中，进一步查找包括目标自愈任务的故障自愈方案，目标自愈任务为依据预设字段的目标字段值设置的故障自愈任务，所以查找到的故障自愈任务是针对报警信息中预设字段的目标字段值设置的，提高了故障自愈任务进行故障自愈的成功率。

步骤S2042：将查找到的故障自愈方案确定为包括故障自愈任务的故障自愈方案。

由于已知故障自愈方案是指已知的对故障进行故障自愈的方案，从上述已知故障自愈方案中查找故障自愈方案，可以直接基于查找到的故障自愈方案进行故障自愈，提高了故障自愈的效率。

另外，由于是根据报警信息，查找到的对原因信息对应的故障进行自愈处理的故障自愈方案，使得查找到的故障自愈方案能够对上述故障进行自愈处理，从而通过执行上述故障自愈方案实现故障自愈。

在上述步骤S2041中，若未查找到对原因信息对应的故障进行自愈处理的故障自愈方案时，可以参见图5a所示的实施例确定故障自愈方案。

图5a为本公开实施例提供的第四种故障处理方法的流程示意图，在上述步骤S2041中若未查找到对原因信息对应的故障进行自愈处理的故障自愈方案时，还可以包括以下步骤S2043-S2047。

步骤S2043：根据各已知运维信息中描述信息的第一语义与原因信息的第二语义，获得各已知运维信息与原因信息之间的第一相似度。

上述每一条已知运维信息中包括：系统异常的描述信息以及系统异常处理方式的描述信息。描述信息可以是文字形式的信息。

例如：系统异常的描述信息可以为：业务模块无法运行，系统异常处理方式的描述信息可以为：对安装有业务模块的设备进行重启。

上述各已知运维信息可以基于运维手册、运维预案以及历史运维文档等相关运维文档确定的运维信息。上述各已知运维信息可以存储于运维知识库中。

可选的，可以是对上述运维文档进行结构化抽取，得到系统异常的描述信息以及系统异常处理方式的描述信息，进而得到包括系统异常的描述信息以及系统异常处理方式的描述信息的已知运维信息。还可以是在从运维文档中结构化抽取得到的各描述信息后，由工作人员对上述描述信息的内容、所包括的各系统异常处理方式的顺序等信息进行调整，得到包括调整后的系统异常的描述信息以及系统异常处理方式的描述信息的已知运维信息。

上述第一语义表征已知运维信息中描述信息所表达的语义，第二语义表征原因信息所表达的语义。

一种实现方式中，可以采用自然语言理解技术对各已知运维信息中描述信息的语义进行识别、对原因信息的语义进行识别，得到第一语义和第二语义。

另一种实现方式中，可以采用语义提取模型，将已知运维信息输入至语义提取模型，得到语义提取模型输出的已知运维信息的描述信息的语义特征，作为第一语义，并将原因信息输入至语义提取模型，得到语义特征提取模型输出的原因信息的语义特征，作为第二语义。

可选的，可以计算上述第一语义与第二语义之间的距离，如欧式距离、余弦距离等，基于计算得到的距离确定第一语义与第二语义之间的相似度，作为各已知运维信息与原因信息之间的第一相似度。

步骤S2044：根据第一语义和报警信息的第三语义，获得各已知运维信息与报警信息之间的第二相似度。

上述第三语义表征报警信息所表达的语义。

可选的，可以对报警信息的预设字段的目标字段值的语义进行识别，将识别结果确定为第三语义。

一种实现方式中，可以采用自然语言理解技术对报警信息的语义进行识别，得到第三语义。另一种实现方式中，还可以采用语义提取模型，将报警信息输入至语义提取模型，得到语义提取模型输出的报警信息的语义特征，作为第三语义。

可选的，可以计算上述第一语义与第三语义之间的距离，如欧式距离、余弦距离等，基于计算得到的距离确定第一语义与第三语义之间的相似度，作为各已知运维信息与报警信息之间的第二相似度。

步骤S2045：根据第一相似度和第二相似度，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息。

上述候选处理方式的描述信息是指对候选处理方式进行描述的信息，上述描述信息可以是文字形式的信息。

可选的，可以针对每一已知运维信息，对该已知运维信息对应的第一相似度和第二相似度进行数据融合，如对上述第一相似度和第二相似度进行加权求和，得到该已知运维信息对应的目标值，根据计算得到的各已知运维信息对应的目标值，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息。

一种实现方式中，可以选择目标值最高的已知运维信息包括的系统异常异常处理方式的描述信息，作为候选处理方式的描述信息。

另一种实现方式中，还可以选择目标值大于预设目标阈值的已知运维信息包括的系统异常处理方式的描述信息，作为候选处理方式的描述信息。

步骤S2046：针对每一候选处理方式，基于该候选处理方式的描述信息，获得候选处理任务，以得到包含候选处理任务的候选故障自愈方案。

上述候选处理任务中包含可执行命令。例如：候选处理方式的描述信息为：启动A程序，候选处理任务包含的可执行命令为：start A。

可选的，可以获得候选处理方式的描述信息的语义特征，基于所获得的语义特征，将描述信息转换为可执行命令，得到包含上述可执行命令的候选处理任务。

还可以在将描述信息转换为可执行命令后，由运维工作人员对转换后的可执行命令的执行顺序、执行参数等信息进行校准，得到包含校准后的可执行命令的候选处理任务。

步骤S2047：从各候选故障自愈方案中确定故障自愈方案。

一种实施方式中，可以从各候选故障自愈方案中随机选择一种方案，作为故障自愈方案。确定故障自愈方案的其他实施方式还可以参见图5b对应的实施例。

由于第一相似度是各已知运维信息中描述信息的第一语义与原因信息的第二语义之间的相似度，第二相似度是上述第一语义与报警信息的第三语义之间的相似度，在根据第一相似度和第二相似度确定候选处理方式的描述信息时，综合考虑了原因信息、报警信息的语义分别与各已知运维信息中描述信息的语义之间的相似度，使得所确定的描述信息对应的候选处理方式能够较为准确地处理报警信息的故障，进而使得所确定的故障自愈方案较为准确。

参见图5b，图5b为本公开实施例提供的第五种故障处理方法的流程示意图，在上述步骤S2045之后，还可以包括以下步骤S2048。

步骤S2048：获得采用各候选处理方式对原因信息对应的故障进行故障自愈的第一成功概率。

上述第一成功概率表示采用候选处理方式能够成功对原因信息对应的故障进行故障自愈的概率。

可选的，可以根据各候选处理方式对应的第一相似度和第二相似度数据融合后得到的目标值，确定第一成功概率。例如：可以对上述目标值进行归一化处理，基于归一化处理后的值，确定第一成功概率。

当目标值越高，表示该候选处理方式能够成功对原因信息对应的故障进行故障自愈的概率越高，也就是第一成功概率越高，当目标值越低，表示该候选处理方式能够成功对原因信息对应的故障进行故障自愈的概率越低，也就是第一成功概率越低。

在上述实施例的基础上，上述步骤S2047，还可以按照以下步骤S20471-S20472实现。

步骤S20471：针对每一候选故障自愈方案，根据业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务，预估采用候选自愈方案对原因信息对应的故障进行故障自愈的第二成功概率。

当前网络环境信息包括当前网络流量、当前网络的可用资源量等信息。

由于上述第二成功概率是根据业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务预估得到的，上述第二成功概率与业务系统的当前网络环境信息相关，又由于业务系统的当前网络环境会影响故障自愈方案对故障进行故障自愈的成功概率，所以计算得到的第二成功概率适应业务系统的当前网络环境信息，使得计算得到的第二成功概率准确度高。

步骤S20472：根据第一成功概率和第二成功概率，从各候选自愈方案中确定故障自愈方案。

可选的，可以对第一成功概率和第二成功概率进行数据融合，得到融合概率，如按照预设的权重，对第一成功概率和第二成功概率进行加权求和，将计算得到的值确定为融合概率。基于各候选自愈方案的融合概率，确定故障自愈方案。

例如：可以将融合概率最高的候选自愈方案确定为故障自愈方案，还可以将融合概率大于预设概率阈值的候选自愈方案确定为故障自愈方案。

由于是根据第一成功概率和第二成功概率从各候选自愈方案中确定的故障自愈方案，又由于第一成功概率表示各候选处理方式自身进行故障自愈的成功概率，第二成功概率不仅考虑了候选故障自愈方案的候选处理任务的信息，还考虑了业务系统的当前网络环境信息，使得第二成功概率适应业务系统的当前网络环境信息，所以第一成功概率和第二成功概率是从两种不同角度确定各候选自愈方案的成功概率，从而基于上述两种成功概率，提高了通过所确定的故障自愈方案进行故障自愈的成功概率。

本公开的一个实施例中，上述步骤S2043-S2045可以采用推荐模型得到候选处理方式的描述信息，上述步骤S2048也可以采用上述推荐模型得到第一成功率。

可选的，可以将已知运维信息中描述信息、原因信息以及报警信息作为推荐模型的输入；

推荐模型计算得到各已知运维信息与原因信息之间的第一相似度、并计算各已知运维信息与报警信息之间的第二相似度，根据第一相似度和第二相似度，从各已知运维信息包括的系统异常处理方式的描述信息中，确定候选处理方式的描述信息，并确定采用各候选处理方式对所述原因信息对应的故障进行故障自愈的第一成功概率，输出上述候选处理方式的描述信息以及第一成功概率。

为更准确获得第二成功概率，参见图6所示的实施例，图6为本公开实施例提供的第六种故障处理方法的流程示意图。在图5b对应的实施例的基础上，上述步骤S20471，可以按照以下步骤S204711-S204712实现。

步骤S204711：根据候选故障自愈方案包括的各候选处理任务的任务参数以及任务间依赖关系，确定各候选处理任务的执行耗时。

上述任务参数包括执行候选处理任务时需要的执行参数，如内存参数、计算资源参数、带宽资源参数等。

上述任务间依赖关系可以基于各候选处理任务之间的执行顺序确定，如，若候选处理任务之间的执行顺序依次为串行执行顺序：任务A1、任务A2、任务A3，则任务A1、任务A2、任务A3之间均具有依赖关系、且相邻两个任务之间的依赖关系最高；若候选处理任务之间的执行顺序为并行执行的顺序，那么各并行执行的候选处理任务之间的依赖关系最低。

可选的，可以根据预设的故障自愈任务的任务参数、任务间依赖关系与执行耗时之间的对应关系，确定各候选处理任务的执行耗时。上述信息对应关系可以由专家根据经验确定。

步骤S204712：根据各候选处理任务的执行耗时和业务系统的当前网络环境信息，预估采用候选自愈方案对原因信息对应的故障进行故障自愈的第二成功概率。

可选的，可以确定在业务系统的当前网络环境信息下各候选自愈方案对上述故障进行故障自愈的成功概率，在这一过程中，可以采用预设的网络环境信息与故障自愈方案对应的成功概率的对应关系，确定上述各候选自愈方案的成功概率，基于各候选处理任务的执行耗时，对上述成功概率进行调整，将调整后的成功概率确定为第二成功概率。

例如：对于同一成功概率的不同候选自愈方案，若其中一个候选自愈方案P1中包括的各候选处理任务的执行耗时小于另外一个候选自愈方案P2中包括的各候选处理任务的执行耗时，可以提高候选自愈方案P1对应的成功概率，并减少候选自愈方案P2对应的成功概率，从而将调整后的成功概率确定为第二成功概率。

上述步骤S204711-S204712可以采用效果预测模型得到第二成功率，将候选故障自愈方案包括的各候选处理任务作为效果预测模型的输入，效果预测模型根据各候选处理任务的任务参数以及任务间依赖关系，确定各候选处理任务的执行耗时，并根据各候选处理任务的执行耗时、业务系统的当前网络环境，预估得到第二成功概率。

由于是根据各候选处理任务的执行耗时和当前网络环境信息预估第二成功概率，预估得到的第二成功概率与各候选处理任务的执行耗时相关，而各候选处理任务的执行耗时影响故障自愈的效率，所以预估得到的第二成功概率考虑了故障自愈的效率，进而基于第一成功概率和第二成功概率确定故障自愈方案，在执行上述故障自愈方案时提高了故障自愈的效率。

为实现更好对故障进行自愈，本公开的一个实施例中，还可以对各故障自愈任务的执行过程进行监控；在监控到任务执行异常的情况下，对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度。

上述任务执行异常的情况可以包括：执行任务时出现任务冲突、当前执行任务进度缓慢等。

可选的，可以对各故障自愈任务的执行过程的执行状态、执行进行进度百分比以及执行描述信息等信息进行监控，基于上述监控信息，在任务执行异常的情况下，确定故障自愈任务的调度顺序的调整操作和/或故障自愈任务的执行进度的控制操作，并执行上述操作。

由于在任务执行异常的情况下，对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度，使得能够对可能出现的问题及时进行调整，从而顺利实现故障自愈。

本公开的一个实施例中，在故障自愈方案包括的各故障自愈任务执行过程中，可以由运维工作人员同步对故障自愈任务的执行进度进行监控、调整、调度等操作。

可选的，在生成故障自愈方案后，可以由运维工作人员对上述故障自愈方案中包括的各故障自愈任务进行调整，实时控制任务的开始、结束、暂停、继续等进度，并对执行结果进行确认，将上述故障自愈方案通过自愈控制台录入方案库中。

在运维工作人员进行调整的过程中，还可以存储运维工作人员在方案执行过程中的执行操作，剔除上述操作过程中无效信息，并对上述执行操作进行格式转换，使用转换后的数据作为推荐模型的训练样本，对推荐模型进行重新训练，使得推荐模型学习到运维工作人员执行操作的规律和特征。

业务系统的用户端的用户界面中配置有故障自愈控制台，用户可以通过故障自愈控制台的自愈任务管理功能模块，浏览当前生成或者执行的故障自愈方案，对故障自愈方案中包括的故障自愈任务进行编辑，如增删改操作任务、检查任务等。还可以配置各任务对应的执行工具的参数。

用户还可以通过故障自愈控制台的自愈方案编辑功能模块，如调整故障自愈方案中各故障自愈任务的执行顺序，增删改故障自愈方案的内容等。

以下结合图7，对本公开实施例提供的一种故障处理方法的具体过程进行说明。

图7为本公开实施例提供的一种故障处理方法的流程框图。

图7包括5个功能模块，分别为：感知引擎、决策引擎、执行引擎、协同引擎以及故障自愈控制台，其中，感知引擎、决策引擎、执行引擎、协同引擎为服务器安装的功能模块，故障自愈控制台为客户端安装的功能模块。

应用本公开实施例提供的故障自愈方案进行故障自愈时，首先，感知引擎获取报警信息，并且通过感知引擎获取业务系统的监控数据，感知引擎将上述报警信息和监控数据输入至决策引擎；

其次，决策引擎根据上述感知引擎所输入的监控数据，获得与报警信息具有关联性的关联数据，根据上述关联数据，确定触发产生所述报警信息的故障的原因信息；

然后，决策引擎还根据上述原因信息和感知引擎所获取的报警信息，确定包括故障自愈任务的故障自愈方案，并将上述故障自愈方案输入至执行引擎；

最后，执行引擎通过执行故障自愈方案中包括的故障自愈任务，进行故障自愈。

在执行上述故障自愈任务的过程中，运维工作人员可以通过决策引擎以及协同引擎监控上述故障自愈任务的执行情况，并对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度。

以下对各个功能模块的组成以及功能进行具体说明。

感知引擎中包括三个功能单元，分布为：文档数据订阅、报警数据订阅、指标数据抽取。

文档数据订阅用于对文档平台中的文档进行订阅，对获取的文档进行结构化抽取，得到“问题-答案”形式的已知运维信息，又称运维知识，将上述运维知识添加至运维知识库中。

报警数据订阅用于对事件平台中的报警信息进行订阅，抽取获取到的报警信息的预设字段的目标字段值。

指标数据抽取用于从监控系统、变更系统以及容量系统中获取监控指标、变更单以及容量数据，具体的，监控指标包括业务系统针对发生报警信息的目标节点产生的其他报警信息、业务系统的运行状态、异常信息等，变更单包括业务系统在报警信息产生前是否发生系统变更的信息、以及系统变更的内容，容量数据包括业务系统的可用资源量。

在决策引擎中包括四个功能单元，分别为；态势理解、预案推荐、方案生成以及自愈方案控制器。

其中，态势理解获得报警信息，根据报警信息中记录的预设字段的目标字段值，从指标数据抽取功能单元中抽取与报警信息具有关联关系的关联数据，并对关联数据进行多维度分析，得到触发报警信息的故障的原因信息。

预案推荐中包括两个功能子单元，分别为：规则匹配、方案推荐，以及推荐模型，上述推荐模型可以为NLP/KG(Natural Language Processing/Knowledge Graph，自然语言理解/知识图谱)模型。

上述规则匹配用于获得原因信息，以原因信息和报警信息作为关键字，从自愈配置模块对应的方案库存储的各已知故障自愈方案中进行关键字匹配，确定匹配成功的故障自愈方案。

上述方案推荐用于在上述规则匹配未匹配成功之后，根据报警信息以及原因信息，调用了推荐模型，从运维知识库中获取候选处理方式的描述信息，并确定各描述信息的置信度(前述第一成功概率)也就是运维知识库中存储的各“问题-答案”中的若干个“答案”。

方案生成中包括方案生成器，方案生成器获得上述方案推荐功能子单元输出的若干个“答案”，并且按照置信度由高到低的顺序排列，，方案生成器调用效果预测算法对上述各“答案”的效果进行预测，得到第二成功概率，基于第一成功概率和第二成功概率，并结合运维工作人员的调整与控制，生成故障自愈方案。

自愈方案控制器，用于获得方案生成器生成的故障自愈方案，并将上述故障自愈方案输入至执行引擎功能模块中，还用于在故障自愈方案执行过程中，对执行过程的风险以及进度进行控制。

执行引擎，用于确定故障自愈方案中各故障自愈任务的任务类型相匹配的执行工具，并在执行各故障自愈任务的过程中，调用上述执行工具，上述执行工具包括：链路关闭工具、重启工具、健康度检查工具等。

协同引擎，运维工作人员可以通过上述功能模块中的人工接管模块，对运维知识库中录入的知识进行确认、对生成的故障自愈方案进行调整、并对执行故障自愈方案过程进行干预。协同引擎功能模块，还用于采集运维工作人员的行为数据，将上述行为数据作为推荐模型的训练样本对上述模型进行迭代更新。

故障自愈可控制台中包括故障自愈方案推荐功能模块、运维知识库功能模块、效果统计分析功能模块、自愈配置功能模块、登录认证功能模块、自愈任务管理功能模块以及自愈方案编辑功能模块。

其中，故障自愈方案推荐功能模块，用于显示所生成的故障自愈方案。

运维知识库，可以使得运维工作人员基于这一功能模块进行运维知识的录入与运维知识的确认。

效果统计分析，用于显示已运行过的故障自愈方案的效果。

自愈配置模块，用于使得运维工作人员基于这一功能模块录入已运行过得故障自愈方案。

登录认证，用于对登录的用户进行认证。

权限管理，用于对用户的权限进行管理。

自愈任务管理，用于显示当前生成或者执行的故障自愈方案，并提供故障自愈方案中包括的故障自愈任务编辑的功能，如增删改操作任务、检查任务等。还可以配置各任务对应的执行工具的参数。

自愈方案编辑，用于调整故障自愈方案中各故障自愈任务的执行顺序，增删改故障自愈方案的内容等。

参见图8，图8为本公开实施例提供的第一种故障处理装置的结构示意图，上述装置包括以下模块801-805。

信息获得模块801，用于获得业务系统产生的报警信息；

数据获得模块802，用于根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；

信息确定模块803，用于根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；

方案获得模块804，用于根据所述原因信息和所述报警信息，获得包括故障自愈任务的故障自愈方案；

故障自愈模块805，用于通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。

由以上可见，应用本实施例提供的方案进行故障自愈时，由于故障自愈任务既考虑了报警信息自身的信息，又考虑了触发产生报警信息的故障的原因信息，原因信息能够反映触发产生报警信息的故障的原因，因此，故障自愈任务不仅能够从报警信息所呈现出来的故障直观层面进行故障自愈，还能够从故障的原因信息所呈现出来的根源层面进行故障自愈，进而实现了故障问题的精准解决，有效提升了故障止损的效率。

另外，由于关联数据是与报警信息具有关联性的数据，又由于在业务系统出现故障时，这一故障可能会带来一系列连锁效应，同时这一故障也可能是由其他问题导致的，在这一连串的连锁效应中所产生的各种信息是相互关联的，基于具有关联关系的各种信息可以确定导致故障产生的原因信息，因此，根据关联数据能够较为准确地确定触发产生报警信息的故障的原因信息，进而根据原因信息和报警信息所获得的故障自愈方案对原因信息对应的故障进行故障自愈的成功率越高。

参见图9，图9为本公开实施例提供的第二种故障处理装置的结构示意图，在上述实施例的基础上，上述数据获得模块802包括以下子模块中的至少一个子模块：

报警信息获得子模块8021，用于从所述监控数据中，获得所述报警信息中记录的报警时间在第一时间段内且针对目标业务节点的其他报警信息，其中，所述目标业务节点为：所述报警信息针对的业务节点；

第一信息获得子模块8022，用于确定触发目标故障类型的故障的影响因子，根据所述监控数据中记录的报警时间在第二时间段内的所述影响因子的取值，获得表征所述影响因子波动的第一信息，其中，所述目标故障类型为：所述报警信息中记录的故障类型；

第二信息获得子模块8023，用于根据所述监控数据中记录的最新系统更新时间和报警时间，获得表征所述业务系统在所述报警信息产生前的第三时间段内是否发生系统更新的第二信息；

资源量选择子模块8024，用于从所述监控数据中，选择报警时间在第四时间段内所述业务系统的可用资源量。

针对上述子模块8021，由于在一个时间段内针对同一节点的各报警信息之间具有关联关系的概率较大，所以第一时间段内针对目标节点的其他报警信息与报警信息之间具有关联关系的概率较大，将上述其他报警信息确定为关联数据的准确度高。

针对上述子模块8022，由于影响因子是触发报警信息中记录的故障类型的故障的影响因子，在一定时间段内影响因子的取值与该时间段内产生的报警信息具有关联关系，又由于上述第一信息是根据包括报警信息的报警时间的第二时间段内影响因子的取值确定的，上述第一信息是与第二时间段内影响因子的取值相关的，所以，第一信息与上述报警信息具有关联关系，将第一信息确定为关联数据的准确度高。

针对上述子模块8023，由于第二信息是表征报警信息产生前的第三时间段内是否发生系统更新的信息，又由于发生系统更新导致业务系统产生故障的概率较大，从而易产生报警信息，所以表征第三时间段内是否发生系统的第二信息与报警信息之间关联性高，将第二信息确定为关联数据的准确度高。

针对上述子模块8024，由于业务系统的可用资源量会对业务系统产生影响，当发生故障时产生报警信息，如可用资源量低会造成业务系统难以响应用户请求的故障，从而产生对应的报警信息。所以包括报警时间的第四时间段内业务系统的可用资源量与报警信息之间具有关联关系，将上述业务系统的可用资源量确定为关联数据的准确度高。

参见图10，图10为本公开实施例提供的第三种故障处理装置的结构示意图，在上述实施例的基础上，上述方案获得模块804包括以下子模块8041-8042：

方案查找子模块8041，用于根据所述报警信息，在已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的故障自愈方案；

方案确定子模块8042，用于将查找到的故障自愈方案确定为包括故障自愈任务的故障自愈方案。

由于已知故障自愈方案是指已知的对故障进行故障自愈的方案，从上述已知故障自愈方案中查找故障自愈方案，可以直接基于查找到的故障自愈方案进行故障自愈，提高了故障自愈的效率。

另外，由于是根据报警信息，查找到的对原因信息对应的故障进行自愈处理的故障自愈方案，使得查找到的故障自愈方案能够对上述故障进行自愈处理，从而通过执行上述故障自愈方案实现故障自愈。

本公开的一个实施例中，上述方案查找子模块8041，还用于提取所述报警信息中预设字段的目标字段值；基于所述目标字段值，在所述已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的、且包括目标自愈任务的故障自愈方案，其中，所述目标自愈任务为：依据所述预设字段的目标字段值设置的故障自愈任务。

由于是从对原因信息对应的故障进行自愈处理的已知故障自愈方案中，进一步查找包括目标自愈任务的故障自愈方案，目标自愈任务为依据预设字段的目标字段值设置的故障自愈任务，所以查找到的故障自愈任务是针对报警信息中预设字段的目标字段值设置的，提高了故障自愈任务进行故障自愈的成功率。

本公开的一个实施例中，上述预设字段包括以下字段中的至少一个字段：

所述报警信息的报警时间、所述报警信息所针对的业务节点的标识、生成所述报警信息的设备的标识、所述设备所在机房的标识、触发生成所述报警信息的实例的标识以及异常描述信息。

由于上述预设字段包括报警信息的报警时间，报警信息所针对的业务节点的标识、生成报警信息的设备的标识、设备所在机房的标识、触发生成报警信息的实例的标识，这些字段的取值从不同方面表示报警信息的具体情况，通过提取报警信息中上述预设字段的取值，可以较为准确地反映报警信息。

参见图11a，图11a为本公开实施例提供的第四种故障处理装置的结构示意图，在上述实施例的基础上，上述方案获得模块804还包括以下子模块8043-8047。

第一相似度获得子模块8043，用于在上述方案查找子模块8041中未查找到对所述原因信息对应的故障进行自愈处理的故障自愈方案之后，根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，获得各已知运维信息与所述原因信息之间的第一相似度，其中，每一条已知运维信息中包括：系统异常的描述信息以及系统异常处理方式的描述信息；

第二相似度获得子模块8044，用于根据所述第一语义和所述报警信息的第三语义，获得各已知运维信息与所述报警信息之间的第二相似度；

信息选择子模块8045，用于根据所述第一相似度和第二相似度，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息；

候选方案确定子模块8046，用于针对每一候选处理方式，基于该候选处理方式的描述信息，获得候选处理任务，以得到包含所述候选处理任务的候选故障自愈方案；

自愈方案确定子模块8047，用于从各候选故障自愈方案中确定故障自愈方案。

由于第一相似度是各已知运维信息中描述信息的第一语义与原因信息的第二语义之间的相似度，第二相似度是上述第一语义与报警信息的第三语义之间的相似度，在根据第一相似度和第二相似度确定候选处理方式的描述信息时，综合考虑了原因信息、报警信息的语义分别与各已知运维信息中描述信息的语义之间的相似度，使得所确定的描述信息对应的候选处理方式能够较为准确地处理报警信息的故障，进而使得所确定的故障自愈方案较为准确。

参见图11b，图11b为本公开实施例提供的第五种故障处理装置的结构示意图，在上述实施例的基础上，上述方案获得模块804还包括以下子模块8048。

概率获得子模块8048，用于在所述信息选择子模块8045之后，获得采用各候选处理方式对所述原因信息对应的故障进行故障自愈的第一成功概率；

上述自愈方案确定子模块8047，包括：

概率预估单元80471，用于针对每一候选故障自愈方案，根据所述业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率；

自愈方案确定单元80472，用于根据所述第一成功概率和第二成功概率，从各候选自愈方案中确定故障自愈方案。

由于是根据第一成功概率和第二成功概率从各候选自愈方案中确定的故障自愈方案，又由于第一成功概率表示各候选处理方式自身进行故障自愈的成功概率，第二成功概率不仅考虑了候选故障自愈方案的候选处理任务的信息，还考虑了业务系统的当前网络环境信息，使得第二成功概率适应业务系统的当前网络环境信息，所以第一成功概率和第二成功概率是从两种不同角度确定各候选自愈方案的成功概率，从而基于上述两种成功概率，提高了通过所确定的故障自愈方案进行故障自愈的成功概率。

参见图12，图12为本公开实施例提供的第六种故障处理装置的结构示意图，在上述实施例的基础上，上述概率预估单元80471，包括：

耗时确定子单元804711，用于根据候选故障自愈方案包括的各候选处理任务的任务参数以及任务间依赖关系，确定各候选处理任务的执行耗时；

概率预估子单元804712，用于根据各候选处理任务的执行耗时和所述业务系统的当前网络环境信息，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率。

由于是根据各候选处理任务的执行耗时和当前网络环境信息预估第二成功概率，预估得到的第二成功概率与各候选处理任务的执行耗时相关，而各候选处理任务的执行耗时影响故障自愈的效率，所以预估得到的第二成功概率考虑了故障自愈的效率，进而基于第一成功概率和第二成功概率确定故障自愈方案，在执行上述故障自愈方案时提高了故障自愈的效率。

本公开的一个实施例中，上述故障自愈模块805，包括：

工具确定子模块，用于确定与所述故障自愈任务的任务类型相匹配的任务执行工具；

故障自愈子模块，用于按照所述故障自愈方案中各故障自愈任务的执行顺序，调用各故障自愈任务对应的任务执行工具，执行所述各故障自愈任务，进行故障自愈。

由于上述任务执行工具是与故障自愈任务的任务类型相匹配的，与任务的任务类型相匹配的任务执行工具能够执行该任务，因此，通过调用上述各任务执行工具，能够执行故障自愈任务，从而实现故障自愈。

本公开的一个实施例中，上述装置还包括：

过程监控模块，用于对各故障自愈任务的执行过程进行监控；

任务控制模块，用于在监控到任务执行异常的情况下，对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度。

由于在任务执行异常的情况下，对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度，使得能够对可能出现的问题及时进行调整，从而顺利实现故障自愈。

本公开实施例提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够故障处理方法。

本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行故障处理方法。

本公开实施例提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现故障处理方法。

图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图13所示，设备1300包括计算单元1301，其可以根据存储在只读存储器(ROM)1302中的计算机程序或者从存储单元1308加载到随机访问存储器(RAM)1303中的计算机程序，来执行各种适当的动作和处理。在RAM 1303中，还可存储设备1300操作所需的各种程序和数据。计算单元1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

设备1300中的多个部件连接至I/O接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许设备1300通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如故障处理方法。例如，在一些实施例中，故障处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序加载到RAM 1303并由计算单元1301执行时，可以执行上文描述的故障处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1301可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行故障处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (19)

1.一种故障处理方法，包括：

获得业务系统产生的报警信息；

根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；

根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；

根据所述报警信息，在已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的故障自愈方案；

将查找到的故障自愈方案确定为包括故障自愈任务的故障自愈方案；

若未查找到对所述原因信息对应的故障进行自愈处理的故障自愈方案，根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息；

获得采用各候选处理方式对所述原因信息对应的故障进行故障自愈的第一成功概率；

针对每一候选处理方式，基于该候选处理方式的描述信息，获得候选处理任务，以得到包含所述候选处理任务的候选故障自愈方案；

根据所述第一成功概率，从各候选自愈方案中确定故障自愈方案；

通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。

2.根据权利要求1所述的方法，其中，所述根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据，包括：

根据所述业务系统的监控数据，按照以下方式中的至少一种方式获得信息，作为与所述报警信息具有关联性的关联数据：

从所述监控数据中，获得所述报警信息中记录的报警时间在第一时间段内且针对目标业务节点的其他报警信息，其中，所述目标业务节点为：所述报警信息针对的业务节点；

确定触发目标故障类型的故障的影响因子，根据所述监控数据中记录的报警时间在第二时间段内的所述影响因子的取值，获得表征所述影响因子波动的第一信息，其中，所述目标故障类型为：所述报警信息中记录的故障类型；

根据所述监控数据中记录的最新系统更新时间和报警时间，获得表征所述业务系统在所述报警信息产生前的第三时间段内是否发生系统更新的第二信息；

从所述监控数据中，选择报警时间在第四时间段内所述业务系统的可用资源量。

3.根据权利要求1所述的方法，其中，所述根据所述报警信息，在已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的故障自愈方案，包括：

提取所述报警信息中预设字段的目标字段值；

基于所述目标字段值，在所述已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理、且包括目标自愈任务的故障自愈方案，其中，所述目标自愈任务为：依据所述预设字段的目标字段值设置的故障自愈任务。

4.根据权利要求3所述的方法，其中，

所述预设字段包括以下字段中的至少一个字段：

所述报警信息的报警时间、所述报警信息所针对的业务节点的标识、生成所述报警信息的设备的标识、所述设备所在机房的标识，触发生成所述报警信息的实例的标识以及异常描述信息。

5.根据权利要求1-4中任一项所述的方法，其中，所述根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息，包括：

根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，获得各已知运维信息与所述原因信息之间的第一相似度，其中，每一条已知运维信息中包括：系统异常的描述信息以及系统异常处理方式的描述信息；

根据所述第一语义和所述报警信息的第三语义，获得各已知运维信息与所述报警信息之间的第二相似度；

根据所述第一相似度和第二相似度，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息。

6.根据权利要求5所述的方法，其中，

所述根据所述第一成功概率，从各候选自愈方案中确定故障自愈方案，包括：

针对每一候选故障自愈方案，根据所述业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率；

根据所述第一成功概率和所述第二成功概率，从各候选自愈方案中确定故障自愈方案。

7.根据权利要求6所述的方法，其中，所述根据所述业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率，包括：

根据候选故障自愈方案包括的各候选处理任务的任务参数以及任务间依赖关系，确定各候选处理任务的执行耗时；

根据各候选处理任务的执行耗时和所述业务系统的当前网络环境信息，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率。

8.根据权利要求1-4中任一项所述的方法，其中，所述通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈，包括：

确定与所述故障自愈任务的任务类型相匹配的任务执行工具；

按照所述故障自愈方案中各故障自愈任务的执行顺序，调用各故障自愈任务对应的任务执行工具，执行所述各故障自愈任务，进行故障自愈。

9.根据权利要求1-4中任一项所述的方法，所述方法还包括：

对各故障自愈任务的执行过程进行监控；

在监控到任务执行异常的情况下，对故障自愈任务的调度顺序进行调整，和/或，控制故障自愈任务的执行进度。

10.一种故障处理装置，包括：

信息获得模块，用于获得业务系统产生的报警信息；

数据获得模块，用于根据所述业务系统的监控数据，获得与所述报警信息具有关联性的关联数据；

信息确定模块，用于根据所述关联数据，确定触发产生所述报警信息的故障的原因信息；

方案获得模块，用于根据所述报警信息，在已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的故障自愈方案；将查找到的故障自愈方案确定为包括故障自愈任务的故障自愈方案；

故障自愈模块，用于若未查找到对所述原因信息对应的故障进行自愈处理的故障自愈方案，根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息；

获得采用各候选处理方式对所述原因信息对应的故障进行故障自愈的第一成功概率；

针对每一候选处理方式，基于该候选处理方式的描述信息，获得候选处理任务，以得到包含所述候选处理任务的候选故障自愈方案；

根据所述第一成功概率，从各候选自愈方案中确定故障自愈方案；

通过执行所述故障自愈方案中包括的故障自愈任务，进行故障自愈。

11.根据权利要求10所述的装置，其中，所述数据获得模块，包括：

根据所述业务系统的监控数据，按照以下各子模块中的至少一种子模块获得信息，作为与所述报警信息具有关联性的关联数据：

报警信息获得子模块，用于从所述监控数据中，获得所述报警信息中记录的报警时间在第一时间段内且针对目标业务节点的其他报警信息，其中，所述目标业务节点为：所述报警信息针对的业务节点；

第一信息获得子模块，用于确定触发目标故障类型的故障的影响因子，根据所述监控数据中记录的报警时间在第二时间段内的所述影响因子的取值，获得表征所述影响因子波动的第一信息，其中，所述目标故障类型为：所述报警信息中记录的故障类型；

第二信息获得子模块，用于根据所述监控数据中记录的最新系统更新时间和报警时间，获得表征所述业务系统在所述报警信息产生前的第三时间段内是否发生系统更新的第二信息；

资源量选择子模块，用于从所述监控数据中，选择报警时间在第四时间段内所述业务系统的可用资源量。

12.根据权利要求10所述的装置，其中，所述方案获得模块，包括：

方案查找子模块，用于根据所述报警信息，在已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的故障自愈方案；

方案确定子模块，用于将查找到的故障自愈方案确定为包括故障自愈任务的故障自愈方案。

13.根据权利要求12所述的装置，其中，所述方案查找子模块，还用于提取所述报警信息中预设字段的目标字段值；基于所述目标字段值，在所述已知故障自愈方案中，查找对所述原因信息对应的故障进行自愈处理的、且包括目标自愈任务的故障自愈方案，其中，所述目标自愈任务为：依据所述预设字段的目标字段值设置的故障自愈任务。

14.根据权利要求13所述的装置，其中，

所述预设字段包括以下字段中的至少一个字段：

所述报警信息的报警时间、所述报警信息所针对的业务节点的标识、生成所述报警信息的设备的标识、所述设备所在机房的标识、触发生成所述报警信息的实例的标识以及异常描述信息。

15.根据权利要求12-14中任一项所述的装置，所述方案获得模块，还包括：

第一相似度获得子模块，用于根据各已知运维信息中描述信息的第一语义与所述原因信息的第二语义，获得各已知运维信息与所述原因信息之间的第一相似度，其中，每一条已知运维信息中包括：系统异常的描述信息以及系统异常处理方式的描述信息；

第二相似度获得子模块，用于根据所述第一语义和所述报警信息的第三语义，获得各已知运维信息与所述报警信息之间的第二相似度；

信息选择子模块，用于根据所述第一相似度和第二相似度，从各已知运维信息包括的系统异常处理方式的描述信息中，选择候选处理方式的描述信息；

候选方案确定子模块，用于针对每一候选处理方式，基于该候选处理方式的描述信息，获得候选处理任务，以得到包含所述候选处理任务的候选故障自愈方案；

自愈方案确定子模块，用于从各候选故障自愈方案中确定故障自愈方案。

16.根据权利要求15所述的装置，所述方案获得模块，还包括：

概率获得子模块，用于在所述信息选择子模块之后，获得采用各候选处理方式对所述原因信息对应的故障进行故障自愈的第一成功概率；

所述自愈方案确定子模块，包括：

概率预估单元，用于针对每一候选故障自愈方案，根据所述业务系统的当前网络环境信息和候选故障自愈方案包括的候选处理任务，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率；

自愈方案确定单元，用于根据所述第一成功概率和所述第二成功概率，从各候选自愈方案中确定故障自愈方案。

17.根据权利要求16所述的装置，其中，所述概率预估单元，包括：

耗时确定子单元，用于根据候选故障自愈方案包括的各候选处理任务的任务参数以及任务间依赖关系，确定各候选处理任务的执行耗时；

概率预估子单元，用于根据各候选处理任务的执行耗时和所述业务系统的当前网络环境信息，预估采用候选自愈方案对所述原因信息对应的故障进行故障自愈的第二成功概率。

18.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-9中任一项所述的方法。

19.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-9中任一项所述的方法。

Images