CN105827431B - 基于故障因果图的集群故障收敛方法和装置 - Google Patents

Abstract

本发明提供了一种基于故障因果图的集群故障收敛方法和装置，该方法包括：获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图；当集群发生故障时，判断本次集群故障的故障症状在所述故障因果图中是否存在；如果存在，根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障；如果所述故障症状在所述故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将所述本次集群故障案例的信息添加到故障因果图。该方法和装置能够让处理集群故障的经验得到积累和迁移，降低对运维人员能力的要求，同时在集群故障排除的时候更有针对性。

Description

基于故障因果图的集群故障收敛方法和装置

技术领域

本发明涉及计算机集群故障处理技术，尤其涉及一种基于故障因果图的集群故障收敛方法和装置。

背景技术

集群，是集群通信系统的简称，其是一种计算机系统，通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。现代IT系统集群的发展趋势为多组件(一个组件为集群中的单个软件系统或硬件设备)、大规模的分布式系统，并且其规模和复杂度日益提升。这给运维工作带来了极大的挑战，主要的难点在于以下两点：

(1)一个集群由多个组件整合而成，每个组件承担特定且细分的功能，在集群中发挥不同的作用；一个组件故障将导致集群的部分或全部功能不可用。(2)组件之间有很强的依赖关系，一个底层组件的故障可能会扩散到其他组件，可能表现为上层组件的故障。因此，处理集群故障需要从故障的综合表现出发进行排查与分析，从而找到并解决故障集里的原生故障，才能让集群恢复正常运行。(故障是指集群的软件系统或硬件设备在工作过程中，因某种原因而丧失规定功能或造成安全危害的状态。一个原先正常工作的集群中有一个组件出现了故障并扩散到多个组件，导致其他组件也出现故障。源头的故障叫做原生故障，后续受原生故障影响而随之出现的其他故障叫做派生故障。集群中的一个原生故障与由它派生出的所有故障的集合称为故障集。)

要让这样的系统保持正常运行并在故障发生时及时加以修复，需要强有力的运维能力保障，要求运维人员有很强的技术能力与丰富的经验，并且每次处理故障都需要运维人员的深度介入。而这就使得运维能力成为约束IT能力和集群规模发展的一个瓶颈。

解决上述集群运维问题的一种思路是：用软件定期记录集群的配置及各组件的工作状态的快照，当集群出现故障时，由运维人员调取集群正常时与故障时的两组快照信息，并加以比较，找到差异，以帮助定位出可能导致故障的一组因素，再对这组因素进行排查。

然而，上述快照差异的方法也存在不足：(1)集群快照的差异与故障原因的相关性不高。在两个快照期间，集群可能发生许多变更，快照比较差异的方法能够找出这些变更，但这些变更不能准确地反映出故障的根源，同时快照差异的信息只能作为运维人员处理故障时的参考，而并不能确定地指出故障所在，更不能给出检测与修复方法的建议。(2)群故障处理的历史经验得不到有效的积累。用快照差异的方法分析和处理故障，对于新故障类型的处理经验无法在系统中沉淀，对于曾出现过的故障类型也无法自动化地应用之前的经验。无法解决集群运维对运维人员经验的高要求的问题。

发明内容

为了解决上述问题，本发明提出了一种基于故障因果图的集群故障收敛方法和装置。

一种基于故障因果图的集群故障收敛方法，所述方法包括如下步骤，

获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图，其中，所述集群故障案例的信息包括各组件的故障症状、所述各故障症状所对应的检测方法和修复方法、以及所述各故障症状之间的依赖关系；

当集群发生故障时，判断本次集群故障的故障症状在所述故障因果图中是否存在；

如果所述故障症状在所述故障因果图中存在，根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障；

如果所述故障症状在所述故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将所述本次集群故障案例的信息添加到故障因果图，其中，所述本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系。

一种基于故障因果图的集群故障收敛装置，所述装置包括故障因果图建立模块、判断模块、应用模块、更新模块；

所述建立模块，用于获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图，其中，所述集群故障案例的信息包括各组件的故障症状、所述各故障症状所对应的检测方法和修复方法、以及所述各故障症状之间的依赖关系；

所述判断模块，用于当集群发生故障时，判断本次集群故障的故障症状在所述故障因果图中是否存在；

所述应用模块，用于如果所述故障症状在所述故障因果图中存在，根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障；

所述更新模块，用于如果所述故障症状在所述故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将所述本次集群故障案例的信息添加到故障因果图，其中，所述本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系。

以上方法和装置所带来的有益效果如下：

1、降低对运维人员能力的要求。在集群故障处理时，故障因果图就像一个经验非常丰富的运维顾问，通过获取故障的局部、零散、浅层的症状，提示出可能导致该症状发生的深层原因，指引没有经验的运维人员在复杂的集群组件中针对高可疑的点进行排查，并给出检测及修复方法作为参考。这样就不需要运维人员具备很高的经验和技能才能处理复杂集群的故障，降低集群维护对运维人员的要求。

2、处理集群故障的经验可以得到积累。故障因果图中记录了一个集群曾经发生过的所有故障在其各个组件中相互影响的依赖关系。每当运维人员处理一个新的故障，就可以将新故障的相关信息添加到故障因果图，让故障因果图的信息更完善，以后再发生同类故障时，之前的经验就可以发挥指导作用。

3、处理集群故障的经验可以迁移。故障因果图描述了一个集群中各组件可能发生故障之间的依赖关系，针对一个集群建立起的故障因果图可以无缝地迁移到由相同组件组成的其他集群。这样，可以为典型、常见的集群类型建立起故障因果图，在运维排障方面发挥作用。

4、方法和装置中给出的故障的提示是相关的、有针对性的。方法和装置中给出的故障的提示是从当前显现出的故障症状出发，根据以往故障的因果关系而提示的，也就是说每一个提示都是适用于当前的故障场景的，不会给出在当前故障场景中绝对不可能出现的提示。如果获取有多个显现故障症状，能对提示进行裁剪，求出其交集，给出更有针对性、更聚焦于故障根源的提示。这样可以更直接、更迅速地收敛到故障的根源。在处理一个故障时，会按当前可用的多个提示被证实有效的概率的顺序给出，也就是优先给出更有可能发生的提示。这样可以减少排查的次数。

附图说明

为了更清楚地说明本发明实施例中的具体方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为基于故障因果图的集群故障收敛方法的流程图。

图2为两个组件故障症状之间依赖关系的示意图。

图3为故障因果图建立的具体方法流程图。

图4为故障因果图应用的具体方法流程图。

图5为故障因果图应用的示意图。

图6为故障因果图更新的具体方法流程图。

图7为基于故障因果图的集群故障收敛装置的功能模块图。

图8为故障因果图建立模块的子功能框图。

图9为故障因果图应用模块的子功能框图。

图10为故障因果图更新模块的子功能框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的具体实施方式作进一步的详细描述。

图1为基于故障因果图的集群故障收敛方法的流程图。故障收敛是指在分析集群故障时，由观察到的故障集出发，经分析得到引发该故障集的原生故障的过程。请参看图1，该方法包括如下步骤。

步骤S11，获取集群故障案例的信息，并根据集群故障案例的信息建立故障因果图，其中，集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法、以及各故障症状之间的依赖关系。

集群中的故障在各个组件中的具体表现称为故障症状，简称症状。集群中的每个组件都可能发生故障，并在其他组件派生出新的故障，而这些新的故障又可能派生出更多的故障。将集群在一定时期中产生的故障按照它们之间的派生关系组织起来，形成一张图(Graph)，图的顶点是各个故障症状及相应的检测与修复方法，图的边是故障之间的因果关系，也称为依赖关系，这样的图就叫做集群的故障因果图。集群故障中的原生故障与派生故障之间是原因与结果的依赖关系。故障因果图是对集群中各组件之间功能性的依赖关系的反映，其背后的原理是：集群的故障是其每个组件故障的集合；各个组件的故障不是偶然的、孤立的，而是有着内在的因果关系；一个组件的原生故障会扩散成为其他组件的派生故障；原生故障往往是底层的、内隐的，表现在外的故障往往是派生故障；从集群中故障集的任一故障症状出发，沿着故障之间的因果关系向源头排查，最终能够发现到导致故障集的原生故障。

图2为两个组件故障症状之间依赖关系的示意图。图中有两个顶点A.X和B.Y，A.X存储的是A组件的X故障、A组件的X故障的故障症状、A组件的X故障的检测方法、A组件的X故障的修复方法，B.Y存储的是B组件的Y故障、B组件的Y故障的故障症状、B组件的Y故障的检测方法、B组件的Y故障的修复方法。有一条A.X指向B.Y的边，表示A.X与B.Y之间的依赖关系。具体表示为A组件的X故障是由B组件的Y故障引起的，A组件的X故障的解决依赖于B组件的Y故障的解决。经过一段时间的积累，就能得到一张较为完备的、针对该集群的各个组件可能发生的故障的依赖关系图，即故障因果图。

步骤S12，当集群发生故障时，判断该故障症状在故障因果图中是否存在。如果存在，执行步骤S13；如果不存在，执行步骤S14。

步骤S13，根据该故障症状以及在故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用该原生故障的修复方法修复本次故障。当集群有新的故障发生时，运维人员首先找到集群中组件出现的表层故障症状，获取该故障症状，在故障因果图中查找该故障症状，如果在故障因果图中存在该故障症状，根据该故障症状以及该故障症状与其他故障之间的依赖关系找到本次故障的原生故障，并利用该原生故障的修复方法修复本次故障。具体可理解为获取本次故障的故障症状，在故障因果图中找到该故障症状对应的顶点，然后根据图中离开该对应顶点的边，查到能够导致该顶点故障症状发生的后续顶点并提示，并对这些后续顶点所代表的故障症状在集群故障中进行核查，当确认其中某个故障也发生之后，从这个后续顶点出发重复上述过程，也就是在故障因果图的启发式指引下，从浅层的派生故障逐步向原生故障靠拢，最终找到本次集群故障的根源，并修复本次集群故障。

步骤S14，修复本次集群故障后，获取本次集群故障案例的信息，并将本次集群故障案例的信息添加到故障因果图，其中，本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系。

当集群中有故障发生时，如果是之前未发生过的故障，故障因果图无法指示其原生故障所在。在该故障修复后，把故障分析过程中得到的各个组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系等信息添加到故障因果图，从而让故障因果图更加完善，在今后的故障处理中能发挥更全面的作用。

图3为步骤S11的具体方法流程图，即故障因果图建立的具体方法流程图，具体包括如下步骤。

步骤S111，获取集群故障案例引起故障的组件和故障症状。

步骤S112，判断该故障症状是否已经保存。如果已经保存，执行步骤S116；如果没有保存，执行步骤S113。

步骤S113，获取组件的故障症状的检测方法。

步骤S114，获取组件的故障症状的修复方法。

步骤S115，保存组件的故障，该故障的故障症状、该故障症状的检测方法和修复方法。

步骤S116，判断是否有引起该故障症状的另一个故障症状。如果有另一个故障症状，执行步骤S117；如果没有另一个故障症状，流程结束。

步骤S117，获取另一个故障症状和另一个故障症状所对应的组件。

步骤S118，保存该故障症状与另一个故障症状之间的依赖关系，保存后把另一个故障症状作为该故障症状。接着执行步骤S112，直到集群故障全部获取完毕。

获取多次集群故障案例，以使故障因果图记录更多的信息。

图4为步骤S13的具体方法流程图，即故障因果图应用的具体方法流程图。具体包括如下步骤。

步骤S1301，获取故障发生时组件的故障症状。获取本次集群故障发生时的故障症状。该故障症状可能是局部的、零散的、浅层的症状。

步骤S1302，在故障因果图中查找该故障症状。

步骤S1303，判断是否存在该故障症状。如果故障因果图中存在该故障症状，执行步骤S1304，如果不存在该故障症状，则说明是新的故障，执行步骤S1404。

步骤S1304，根据该故障症状在故障因果图中的依赖关系查找引起该故障症状发生的后续故障症状。

步骤S1305，判断该故障症状的后续故障症状是否有多个。如果有一个后续故障症状，执行步骤S1308；如果有多个后续故障症状，执行步骤S1306；如果没有后续故障症状，执行步骤S1311。

步骤S1306，将该故障故障的多个后续故障症状进行提示并进行标记，称为标记的故障症状。当在故障因果图中查到有多个后续故障症状时，将多个后续故障症状进行提示并标记。对同一个故障症状有依赖关系的多个后续故障症状进行标记的过程称为一次标记。每次标记的时候记录下开始标记的时间。

步骤S1307，从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状并进行提示，取消该故障症状的标记。最后一次标记是指离当前时间最短的一次标记。确认出现次数最多的一个故障症状是指，到目前为止，修复集群故障时故障症状被确认出现次数最多的一个故障症状。

步骤S1308，核查该故障症状在本次集群故障中是否存在。如果存在，执行步骤S1309；如果不存在，执行步骤S1312。

步骤S1309，将该故障症状所对应的检测方法和修复方法进行提示，并利用该修复方法修复本次集群故障。

步骤S1310，判断是否修复本次集群故障。如果已经修复本次集群故障，执行步骤S1313；如果没有修复本次集群故障，执行步骤S1311。

步骤S1311，判断该故障症状是否已没有依赖关系。如果已经没有依赖关系，说明已经到了故障因果图的一个分支的末尾，执行步骤S1312；如果还有依赖关系，执行步骤S1304。

步骤S1312，判断是否还有标记的故障症状。如果有，执行步骤S1307；如果故障症状已没有依赖关系，并且也没有标记的故障症状，说明是新的故障，执行步骤S1404。

步骤S1313，记录本次集群故障的修复记录，该故障症状所对应的故障即为本次集群故障的原生故障，该故障症状所对应的检测方法及修复方法即为本次集群故障的检测方法及修复方法，并提示本次集群故障已修复。流程结束。其中，修复记录是指从获取本次集群故障症状到修复本次集群故障的一条因果关系链。当有某个故障症状有多个依赖关系，多个依赖关系对应有多个后续故障症状存在时，修复记录可帮助选取在以前的修复过程中确认出现次数最多的一个故障症状，以给出更有可能发生的故障症状的提示，减少排查的次数，更快地向原生故障收敛。

在其他的实施例中，如果获取了多个故障症状；在故障因果图中查找该多个故障症状，判断是否存在该多个故障症状，如果存在该多个故障症状，根据该多个故障症状的依赖关系依次查找该多个故障症状的后续故障症状，获取该多个故障症状所对应的后续故障症状的交集，将该交集作为后续故障症状。接着执行步骤S1305。对多个故障症状所对应的后续故障症状进行裁剪，给出更有针对性、更聚焦于故障根源的故障症状提示。这样可以更直接、更迅速地收敛到故障的根源。

图5为故障因果图应用的示意图。请参看图5，其是一张已经建立好的故障因果图。现在发现本次集群中有故障症状A.X，A.X存储的是A组件的X故障、A组件的X故障的故障症状、A组件的X故障的检测方法、A组件的X故障的修复方法。获取A.X故障症状，在故障因果图上查找到A.X故障症状的依赖关系有两个，分别是故障症状B.Y和C.Z，表示A.X故障症状的原因可能是B.Y或是C.Z。将B.Y和C.Z进行标记，则B.Y和C.Z分别表示标记了的故障症状。从B.Y和C.Z中选取一个确认出现次数最多的一个故障症状，假设为C.Z，经核查发现，C.Z故障症状存在本次集群故障中，用C.Z的修复方法修复本次故障，若没有修复本次集群故障，同时C.Z还存在有依赖关系，根据C.Z的故障症状查找引起C.Z故障症状发生的后续故障症状E.U，核查发现故障症状E.U存在于本次集群故障中，用E.U的修复方法修复了本次故障，则表示E.U是本次集群故障的原生故障，E.U对应的修复方法即为本次集群故障的修复方法。在其他的一些实施例中，将B.Y和C.Z进行标记后，也可以按顺序依次核查这两个故障症状是否存在于系统中。具体地，经核查，系统中没有B.Y故障症状，但有C.Z故障症状。根据故障因果图进一步提示C.Z故障是由E.U故障引起。经运维人员核查，E.U故障存在。于是运维人员根据故障因果图中E.U故障的修复方法修复本次集群中的故障，集群系统恢复正常，E.U故障即为本次集群故障的根源。

若是运维人员在一开始就观察到系统中存在A.X和F.V故障症状，那么输入这两个故障症状后，需对这两个故障症状的后续故障症状的提示进行裁剪，求出其交集，缩小怀疑范围，直接排除掉可能导致A.X的B.Y和可能导致F.V的G.S，而直接以C.Z作为最可能发生的结果。

图6为步骤S14的具体方法流程图，即故障因果图更新的具体方法流程图。具体包括如下步骤。

步骤S1401，获取集群发生的故障症状或者获取核查的故障症状。

步骤S1402，在故障因果图中查找该故障症状。

步骤S1403，是否存在该故障症状。如果不存在，执行步骤S1404；如果存在，执行步骤S1304。

步骤S1404，是否修复该故障症状所对应的本次集群故障。如果已经修复该故障症状所对应的本次集群故障，执行步骤S1405。

步骤S1405，判断该故障症状是否已经保存。如果已经保存，执行步骤S1409；如果没有保存，执行步骤S1406。

步骤S1406，获取组件的故障症状的检测方法。

步骤S1407，获取组件的故障症状的修复方法。

步骤S1408，保存组件的故障，该故障的故障症状、该故障症状的检测方法和修复方法。

步骤S1409，判断是否有引起该故障症状的另一个故障症状。如果有另一个故障症状，执行步骤S1410；如果没有另一个故障症状，流程结束。

步骤S1410，获取另一个故障症状和另一个故障症状所对应的组件。

步骤S1411，保存该故障症状与另一个故障症状之间的依赖关系，保存后把另一个故障症状作为该故障症状。接着执行步骤S1405，直到本次集群故障添加完毕。

图7为基于故障因果图的集群故障收敛装置的功能模块图。该装置包括故障因果图建立模块21、判断模块22、应用模块23、更新模块24。

建立模块21，用于获取集群故障案例的信息，并根据信息建立故障因果图，其中，集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法、以及各故障症状之间的依赖关系。

集群中的故障在各个组件中的具体表现称为故障症状，简称症状。集群中的每个组件都可能发生故障，并在其他组件派生出新的故障，而这些新的故障又可能派生出更多的故障。将集群在一定时期中产生的故障按照它们之间的派生关系组织起来，形成一张图(Graph)，图的顶点是各个故障症状及相应的检测与修复方法，图的边是故障之间的因果关系，也称为依赖关系，这样的图就叫做集群的故障因果图。集群故障中的原生故障与派生故障之间是原因与结果的依赖关系。故障因果图是对集群中各组件之间功能性的依赖关系的反映，其背后的原理是：集群的故障是其每个组件故障的集合；各个组件的故障不是偶然的、孤立的，而是有着内在的因果关系；一个组件的原生故障会扩散成为其他组件的派生故障；原生故障往往是底层的、内隐的，表现在外的故障往往是派生故障；从集群中故障集的任一故障症状出发，沿着故障之间的因果关系向源头排查，最终能够发现到导致故障集的原生故障。

判断模块22，用于当集群发生故障时，判断该故障症状在故障因果图中是否存在。

应用模块23，用于如果该故障症状在故障因果图中存在，根据该故障症状以及在故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用该原生故障的修复方法修复本次故障。运维人员首先找到集群中组件出现的表层故障症状，获取该故障症状，在故障因果图中查找该故障症状，如果在故障因果图中存在该故障症状，根据该故障症状以及该故障症状与其他故障之间的依赖关系找到本次故障的原生故障，并利用该原生故障的修复方法修复本次故障。具体可理解为获取本次故障的故障症状，在故障因果图中找到该故障症状对应的顶点，然后根据图中离开该对应顶点的边，查到能够导致该顶点故障症状发生的后续顶点并提示，并对这些后续顶点所代表的故障症状在集群故障中进行核查，当确认其中某个故障也发生之后，从这个后续顶点出发重复上述过程，也就是在故障因果图的启发式指引下，从浅层的派生故障逐步向原生故障靠拢，最终找到本次集群故障的根源，并修复本次集群故障。

更新模块24，用于如果该故障症状在故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将本次集群故障案例的信息添加到故障因果图，其中，本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系。

当集群中有故障发生时，如果是之前未发生过的故障，故障因果图无法指示其原生故障所在。在故障修复后，把故障分析过程中得到的各个组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系等信息添加到故障因果图，从而让故障因果图更加完善，在今后的故障处理中能发挥更全面的作用。

图8为故障因果图建立模块21的子功能框图。故障因果图建立模块21包括第一获取单元211、第一判断单元212、第一保存单元213。

第一获取单元211，用于获取集群故障案例引起故障的组件和故障症状。

第一判断单元212，判断该故障症状是否已经保存。

第一获取单元211，还用于如果该故障症状没有保存，获取组件的故障症状的检测方法，获取组件的故障症状的修复方法。

第一保存单元213，用于保存组件的故障，该故障的故障症状、该故障症状的检测方法和修复方法。

第一判断单元212，还用于判断是否有引起该故障症状的另一个故障症状。

第一保存单元213，还用于保存该故障症状与另一个故障症状之间的依赖关系，把另一个故障症状作为该故障症状。

图9为故障因果图应用模块23的子功能框图。故障因果图应用模块23包括第二获取单元231、查找单元232、第二判断单元233、标记单元234、选取单元235、核查单元236、修复单元237、第二保存单元238。

第二获取单元231，用于获取故障发生时组件的故障症状。获取本次集群故障发生时的故障症状。该故障症状可能是局部的、零散的、浅层的症状。

查找单元232，用于在故障因果图中查找该故障症状。

第二判断单元233，用于判断是否存在该故障症状。

查找单元232，还用于如果存在该故障症状，根据该故障症状在故障因果图中的依赖关系查找引起该故障症状发生的后续故障症状。

第二判断单元233，还用于判断该故障症状的后续故障症状是否有多个。

标记单元234，用于如果该故障症状的后续故障症状有多个，将该故障故障的多个后续故障症状进行提示并进行标记，称为标记的故障症状。当在故障因果图中查到有多个后续故障症状时，将多个后续故障症状标记。对同一个故障症状有依赖关系的多个后续故障症状进行标记的过程称为一次标记。每次标记的时候记录下开始标记的时间。

选取单元235，用于从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状并进行提示，取消该故障症状的标记。最后一次标记是指离当前时间最短的一次标记。确认出现次数最多的一个故障症状是指，到目前为止，修复集群故障时故障症状使用次数最多的故障症状。

核查单元236，用于核查该故障症状在本次集群故障中是否存在，该故障症状是指确认出现次数最多的一个故障症状。核查单元236，还用于如果该故障症状的后续故障症状只有一个，核查该故障症状在本次集群故障中是否存在。

修复单元237，用于将该故障症状所对应的检测方法和修复方法进行提示，并利用该修复方法修复本次集群故障。

第二判断单元233，还用于判断是否修复本次集群故障。

第二判断单元233，还用于如果没有修复本次集群故障，判断该故障症状是否已没有依赖关系。已没有依赖关系表示已经到了故障因果图的一个分支的末尾。

第二判断单元233，还用于如果已没有依赖关系，判断是否还有标记的故障症状。

选取单元235，还用于如果还有标记的故障症状，从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状并进行提示，取消该故障症状的标记。

第二保存单元238，记录本次集群故障的修复记录，该故障症状所对应的故障即为本次集群故障的原生故障，该故障症状所对应的检测及修复方法即为本次集群故障的检测及修复方法，并提示本次集群故障已修复。其中，修复记录是指从获取本次集群故障症状到修复本次集群故障的一条因果关系链。当有多个依赖关系的后续故障症状存在时，修复记录可帮助选取在以前的修复过程中确认出现次数最多的一个故障症状，以给出更有可能发生的故障症状的提示，减少排查的次数，更快地向原生故障收敛。

在其他的一些实施例中，故障因果图应用模块23还包括交集获取单元。在该实施例中，第二获取单元用于获取故障发生时的多个故障症状；查找单元用于在故障因果图中查找该多个故障症状；第二判断单元用于判断是否存在该多个故障症状；查找单元还用于如果故障因果图中存在多个故障症状，根据该多个故障症状在故障因果图中的依赖关系依次查找引起多个故障症状发生的后续故障症状；交集获取单元用于获取多个故障症状所对应的后续故障症状的交集，将交集作为后续故障症状。在该实施例中，在查找多个故障症状所对应后续故障症状时，需要获取后续故障症状的交集，对不相关的后续故障症状进行裁剪，给出更有针对性、更聚焦于故障根源的提示。这样可以更直接、更迅速地收敛到故障的根源。

故障因果图应用的示意图请参看图5。这里不再赘述。

图10为故障因果图更新模块24的子功能框图。故障因果图更新模块24包括第三获取单元241、查找单元242、第三判断单元243、第三保存单元244。

第三获取单元241，用于获取集群发生的故障症状或者获取核查的故障症状。

查找单元242，用于在故障因果图中查找该故障症状。

第三判断单元243，用于判断是否存在该故障症状。

第三判断单元243，还用于如果在故障因果图中不存在该故障症状，判断是否修复该故障症状所对应的本次集群故障。

第三判断单元243，还用于如果已经修复该故障症状所对应的本次集群故障，判断该故障症状是否已经保存在故障因果图中。

第三获取单元241，还用于如果该故障症状没有保存，获取组件的故障症状的检测方法。获取单元241还用于获取组件的故障症状的修复方法。

第三保存单元244，用于保存组件的故障，该故障的故障症状、该故障症状的检测方法和修复方法。

第三判断单元243，还用于判断是否有引起该故障症状的另一个故障症状。

第三获取单元241，还用于如果有引起该故障症状的另一个故障症状，获取另一个故障症状和另一个故障症状所对应的组件。

第三保存单元244，还用于保存该故障症状与另一个故障症状之间的依赖关系，把另一个故障症状作为该故障症状。

以上方法和装置通过故障因果图记录了一个集群曾经发生过的所有故障及其检测方法与修复方法，以及所有故障在其各个组件中相互影响的依赖关系，当运维人员处理一个新的故障时，获取新故障的相关信息，将新故障的相关信息添加到故障因果图，让故障因果图的信息更完善，处理集群故障的经验可以得到积累。同时故障因果图可以无缝地迁移到有相同组件组成的其他集群。当集群发生之前处理过的故障时，获取集群故障的局部、零散、浅层的症状，根据故障因果图提示出可能导致该症状发生的深层原因，指引没有经验的运维人员在复杂的集群组件中针对高可疑的点进行排查，并给出检测及修复方法作为参考。这样就不需要运维人员具备很高的经验和技能，当集群发生同类故障时，故障因果图可以发挥指导作用，降低集群维护对运维人员的要求。在处理一个故障时，如果故障因果图中故障症状对应的依赖关系有多个，多个依赖关系对应多个后续故障症状，则优选给出有效概率最大的后续故障症状来进行提示并排查，以此来减少排查的次数。如果同时获取多个故障症状，对多个故障症状的后续故障症状的提示进行裁剪，求出其交集，给出更有针对性的提示。这样可更直接、更迅速地收敛到原生故障。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于故障因果图的集群故障收敛方法，其特征在于：该方法包括如下步骤，

获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图，其中，所述集群故障案例的信息包括各组件的故障症状、所述各故障症状所对应的检测方法和修复方法、以及所述各故障症状之间的依赖关系；

当集群发生故障时，判断本次集群故障的故障症状在所述故障因果图中是否存在；

如果所述故障症状在所述故障因果图中存在，根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障；

如果所述故障症状在所述故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将所述本次集群故障案例的信息添加到故障因果图，其中，所述本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系；

其中，所述根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障，包括：

获取故障发生时组件的故障症状；

在所述故障因果图中查找所述故障症状；

判断是否存在所述故障症状；

如果存在所述故障症状，根据所述故障症状在所述故障因果图中的依赖关系查找引起所述故障症状发生的后续故障症状；

判断所述后续故障症状是否有多个；

如果所述后续故障症状有多个，将所述故障症状的多个后续故障症状进行标记，称为标记的故障症状；

从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状并进行提示，取消所述故障症状的标记；

核查所述故障症状在本次集群故障中是否存在；

如果所述故障症状在本次集群故障中存在，利用所述故障症状所对应的修 复方法修复本次集群故障；

判断是否修复本次集群故障；

如果没有修复本次集群故障，判断所述故障症状是否已没有依赖关系；

如果所述故障症状已没有依赖关系，判断是否还有标记的故障症状；

如果还有标记的故障症状，从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状，取消所述故障症状的标记；

如果已修复本次集群故障，记录本次集群故障的修复记录，所述故障症状所对应的故障即为本次集群故障的原生故障，所述故障症状所对应的修复方法即为本次集群故障的修复方法。

2.如权利要求1所述的方法，其特征在于：获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图，其中，所述集群故障案例的信息包括各组件的故障症状、所述各故障症状所对应的检测方法和修复方法、以及所述各故障症状之间的依赖关系的步骤具体包括：

获取集群故障案例引起故障的组件和故障症状；

判断所述故障症状是否已经保存到故障因果图中；

如果所述故障症状没有保存，获取组件的故障症状的检测方法，获取组件的故障症状的修复方法；

保存组件的故障，所述故障的故障症状、所述故障症状的检测方法和修复方法；

判断是否有引起所述故障症状的另一个故障症状；

获取所述另一个故障症状和所述另一个故障症状所对应的组件；

保存所述故障症状与另一个故障症状之间的依赖关系。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

如果所述后续故障症状只有一个，核查所述后续故障症状在本次集群故障中是否存在；

利用所述后续故障症状所对应的修复方法修复本次集群故障；

判断是否修复本次集群故障；

如果没有修复本次集群故障，判断所述后续故障症状是否已没有依赖关系；如果所述后续故障症状还存在依赖关系，根据所述后续故障症状在所述故障因果图中的依赖关系查找引起所述后续故障症状发生的后续故障症状；

如果已修复本次集群故障，记录本次集群故障的修复记录，所述后续故障 症状所对应的故障即为本次集群故障的原生故障，所述后续故障症状所对应的修复方法即为本次集群故障的修复方法。

4.如权利要求1所述的方法，其特征在于：

获取故障发生时的多个故障症状；

在所述故障因果图中查找所述多个故障症状；

判断是否存在所述多个故障症状；

如果存在所述多个故障症状，根据所述多个故障症状的依赖关系依次查找所述多个故障症状的后续故障症状；

获取所述多个故障症状所对应的所述后续故障症状的交集，将所述交集作为后续故障症状。

5.一种基于故障因果图的集群故障收敛装置，其特征在于：所述装置包括故障因果图建立模块、判断模块、应用模块、更新模块；

所述建立模块，用于获取集群故障案例的信息，并根据所述集群故障案例的信息建立故障因果图，其中，所述集群故障案例的信息包括各组件的故障症状、所述各故障症状所对应的检测方法和修复方法、以及所述各故障症状之间的依赖关系；

所述判断模块，用于当集群发生故障时，判断本次集群故障的故障症状在所述故障因果图中是否存在；

所述应用模块，用于如果所述故障症状在所述故障因果图中存在，根据所述故障症状以及所述故障因果图中各故障症状的依赖关系找到本次故障的原生故障，并利用所述原生故障的修复方法修复本次集群故障；

所述更新模块，用于如果所述故障症状在所述故障因果图中不存在，修复本次集群故障后，获取本次集群故障案例的信息，并将所述本次集群故障案例的信息添加到故障因果图，其中，所述本次集群故障案例的信息包括各组件的故障症状、各故障症状所对应的检测方法和修复方法以及各故障症状之间的依赖关系；

其中，所述应用模块包括第二获取单元、查找单元、第二判断单元、标记单元、选取单元、核查单元、修复单元、第二保存单元；

所述第二获取单元，用于获取故障发生时组件的故障症状；

所述查找单元，用于在所述故障因果图中查找所述故障症状；

所述第二判断单元，用于判断是否存在所述故障症状；

所述查找单元，还用于如果存在所述故障症状，根据所述故障症状在所述故障因果图中的依赖关系查找引起所述故障症状发生的后续故障症状；

第二判断单元，还用于判断所述后续故障症状是否有多个；

所述标记单元，用于如果所述后续故障症状有多个，将所述故障症状的多个后续故障症状进行标记，称为标记的故障症状；

所述选取单元，用于从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状，取消所述故障症状的标记；

所述核查单元，还用于核查所述故障症状在本次集群故障中是否存在；

所述修复单元，还用于利用所述故障症状所对应的修复方法修复本次集群故障；

所述第二判断单元，还用于判断是否修复本次集群故障；

所述第二判断单元，还用于如果没有修复本次集群故障，判断所述故障症状是否已没有依赖关系；

所述第二判断单元，还用于如果所述故障症状已没有依赖关系，判断是否还有标记的故障症状；

所述选取单元，还用于如果还有标记的故障症状，从最近一次标记的故障症状中选取故障症状确认出现次数最多的一个故障症状，取消所述故障症状的标记；

所述第二保存单元，还用于如果已修复本次集群故障，保存本次集群故障的修复记录，所述故障症状所对应的故障即为本次集群故障的原生故障，所述故障症状所对应的修复方法即为本次集群故障的修复方法。

6.如权利要求5所述的装置，其特征在于：所述故障因果图建立模块包括第一获取单元、第一判断单元、第一保存单元；

所述第一获取单元，用于获取集群故障案例引起故障的组件和故障症状；

所述第一判断单元，用于判断所述故障症状是否已经保存；

所述第一获取单元，还用于如果所述故障症状没有保存，获取组件的故障症状的检测方法，获取组件的故障症状的修复方法；

所述第一保存单元，用于保存组件的故障，所述故障的故障症状、所述故障症状的检测方法和修复方法；

所述第一判断单元，还用于判断是否有引起所述故障症状的另一个故障症状；

所述第一获取单元，还用于获取所述另一个故障症状和所述另一个故障症状所对应的组件；

所述第一保存单元，还用于保存所述故障症状与另一个故障症状之间的依赖关系。

7.如权利要求5所述的装置，其特征在于：

所述核查单元，还用于如果所述后续故障症状只有一个，核查所述后续故障症状在本次集群故障中是否存在；

所述修复单元，还用于利用所述后续故障症状所对应的修复方法修复本次集群故障；

所述第二判断单元，还用于判断是否修复本次集群故障；

所述第二判断单元，还用于如果没有修复本次集群故障，判断所述后续故障症状是否已没有依赖关系；

所述查找单元，还用于如果所述后续故障症状还存在依赖关系，根据所述后续故障症状在所述故障因果图中的依赖关系查找引起所述后续故障症状发生的后续故障症状；

所述第二保存单元，还用于如果已修复本次集群故障，保存本次集群故障的修复记录，所述后续故障症状所对应的故障即为本次集群故障的原生故障，所述后续故障症状所对应的修复方法即为本次集群故障的修复方法。

8.如权利要求5所述的装置，其特征在于：所述装置还包括交集获取单元；

所述第二获取单元，还用于获取故障发生时的多个故障症状；

所述查找单元，还用于在所述故障因果图中查找所述多个故障症状；

所述第二判断单元，还用于判断是否存在所述多个故障症状；

所述查找单元，还用于如果存在所述多个故障症状，根据所述多个故障症状在所述故障因果图中的依赖关系依次查找引起多个故障症状发生的后续故障症状；

所述交集获取单元，用于获取所述多个故障症状所对应的所述后续故障症状的交集，将所述交集作为后续故障症状。