故障的分类方法和设备与流程

本公开的实施例总体上涉及故障处理领域，更具体地涉及针对故障的自动分类方法和设备。

背景技术：

在软件运行的过程中，很容易发生故障。在具有多个功能部件的大型复杂软件系统中，在开发、测试和运行期间可能产生许多故障。在发生故障之后，通常需要基于一些故障现象，利用经验来判断哪个功能部件负责修复该故障。

软件系统在发生故障时，通常会保留各种原始运行信息例如，日志。通常地，通过人工分析故障现象日志来对故障进行分类，这不仅耗费大量时间精力，而且受分析人员知识的限制，导致故障分类的准确性较低。此外，由于相同的故障现象可能来自不同功能部件，因此，仅仅依靠故障现象，通常很难确定具体哪个功能部件应当负责该故障的分析和修复。

因此，在不断地产生故障时，如何快速、准确地对故障进行自动分类，成为一个亟待解决的问题。

技术实现要素：

有鉴于此，本公开的各实施例提出了一种针对故障的自动分类方法和设备。本公开的实施例通过计算未分类的故障与已分类的历史故障之间的关键事件相似度，能够在没有了解具体故障内容的情况下，快速、准确地对故障进行自动分类。

根据本公开的一个方面，提供了一种针对故障的分类方法，该方法包括：获取与故障相关联的日志；确定日志中的关键事件；根据关 键事件，确定该故障与历史故障中的每个历史故障之间的关键事件相似度，其中历史故障已经被分类；以及至少部分地基于关键事件相似度，对所述故障进行分类。

根据本公开的另一方面，提供了一种针对故障的分类设备，该设备包括：日志获取装置，用于获取与故障相关联的日志；事件确定装置，用于确定日志中的关键事件；相似度确定装置，用于根据关键事件，确定该故障与历史故障中的每个历史故障之间的关键事件相似度，其中历史故障已经被分类；以及故障分类装置，用于至少部分地基于关键事件相似度，对所述故障进行分类。

根据本公开的又一方面，提供了一种针对故障的分类设备，该设备包括：存储器，以及处理器，其中该处理器被配置为：获取与故障相关联的日志；确定日志中的关键事件；根据关键事件，确定该故障与历史故障中的每个历史故障之间的关键事件相似度，其中历史故障已经被分类；以及至少部分地基于关键事件相似度，对所述故障进行分类。

附图说明

结合附图并参考以下详细说明，本公开的各实施例的特征、优点及其他方面将变得更加明显，在此以示例性而非限制性的方式示出了本公开的若干实施例，在附图中：

图1图示了根据本公开的实施例的针对故障的分类方法100的流程图；

图2图示了根据本公开的另一个实施例的针对故障的分类方法200的流程图；

图3图示了根据本公开的实施例的针对故障的分类设备300的框图；

图4图示了可以用来实施本公开的实施例的设备400的示意性框图。

具体实施方式

以下参考附图详细描述本公开的各个示例性实施例。附图中的流程图和框图示出了根据本公开的各种实施例的方法和系统的可能实现的体系架构、功能和操作。应当注意，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分可以包括一个或多个用于实现各个实施例中所规定的逻辑功能的可执行指令。也应当注意，在有些作为备选的实现中，方框中所标注的功能也可以按照不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，或者它们有时也可以按照相反的顺序执行，这取决于所涉及的功能。同样应当注意的是，流程图和/或框图中的每个方框、以及流程图和/或框图中的方框的组合，可以使用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以使用专用硬件与计算机指令的组合来实现。

本文所使用的术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出

应当理解，给出这些示例性实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开的实施例，而并非以任何方式限制发明的范围。

图1图示了根据本公开的实施例的针对故障的分类方法100的流程图。方法100从步骤102开始，获取与故障相关联的日志。在本公开的实施例中，故障包括运行时发生的问题、错误等，其可能导致软件系统无法正常运行，也可能仅仅只是一些异常，而不会影响系统的正常工作。日志是软件运行时所保留的运行信息，其包含了来自不同源或不同功能部件(例如，软件系统的各个子系统)的事件记录。在复杂的软件系统中，日志文件通常非常庞大，不方便被直接处理以获得故障所属的功能部件。在一个实施例中，日志中所包括的多个事件 的重要程度不一样，因此可以提取日志的内容，并且针对不同的事件设置不同的重要性权重。

方法100继续进行到步骤104，确定日志中的关键事件。当系统发生故障时，每个功能部件都可能在专用的或者通用的日志文件中记录一些重要的信息，也被称为关键事件。在一些实施例，关键事件可以包括功能部件及其状态，例如，当a部件还没有准备好时，a部件会在日志中记录“a…not.ready”事件的日志。

在一个实施例中，可以将预定的关键事件与日志进行匹配；以及响应于预定的关键事件中的一个或多个关键事件在日志中被命中，将一个或多个关键事件确定为日志中的关键事件。预定的关键事件是预先人为定义的各个功能部件的关键事件。可选地，预定的关键事件可以包括每个能模块部件的事件。备选地，出于速度最快、能耗最少的目的，可以只选择一些相对重要的一些功能部件的一些事件作为预定的关键事件。一般来说，设置的预定的关键事件的数量越多，故障分类的效果越好。

在一些实施例中，可以针对故障设置事件状态列表，其中事件状态列表指示预定的关键事件中的每个关键事件是否被命中。在一个实施例中，可以根据预定的关键事件，确定故障的事件状态列表，并且根据预定的关键事件，确定历史故障中的每个历史故障的事件状态列表。例如，可以针对每个故障，过滤相关的日志文件，以获得故障的设置事件状态列表。例如，如果某个预定的关键事件在故障的日志中被命中，则在该故障的事件状态列表中，将该预定的关键事件的值设置为1，即表示日志中存在该预定的关键事件。在一些实施例，可以通过正则表达式的匹配来确定预定的关键事件在故障的日志中是否被命中。

方法100继续进行到步骤106，根据关键事件，确定故障与历史故障中的每个历史故障之间的关键事件相似度，其中历史故障已经被分类，即历史故障事件已经被分配了所属的功能部件。

在一个实施例中，可以通过判断故障与历史故障之间的共同的关 键事件的数目，确定故障与历史故障之间的关键事件相似度。在另一个实施例中，可以通过比较故障的事件状态列表与历史故障中的每个历史故障的事件状态列表，确定故障与历史故障中的每个历史故障之间的关键事件相似度。

在一个实施例中，可以对所有的关键事件设置相同的权重，表示所有的关键事件具有相同的重要性。在另一个实施例中，可以对不同的关键事件设置不同的相应的权重，并且根据相应的权重来确定故障与历史故障中的每个历史故障之间的关键事件相似度。例如，某些重要的关键事件可以设置更高的权重。

方法100继续进行到步骤108，至少部分地基于关键事件相似度，对故障进行分类。例如，根据已确定的关键事件相似度，对故障进行分类，例如将故障分类到关键事件相似度最高的历史故障所对应的分类位置，或者将关键事件相似度得分最高的多个(例如，10个)历史故障中出现次数最多的分类位置作为该故障的分类位置。可选地，除了关键事件相似度，还可以基于其他一些因素，来对故障进行分类。

在一个实施例中，示出了针对故障的分类方法100的一个示例。例如，软件系统可以包括三个功能部件，分别为功能部件a、b和c。其中功能部件a、b和c存在一些已登记的预定的关键事件，例如功能部件a包括没有准备好(not.ready)的事件，功能部件b包括没有准备好(not.ready)的关键事件，功能部件c包括没有准备好(not.ready)和电源故障(power.fail)两个关键事件。针对这些事件，利用正则表达式进行表示，例如，用于匹配这些事件的正则表达式如下：

以下是软件系统在运行过程中生成的故障的日志的一个示例，其 包括软件系统在发生故障过程中所产生多条日志记录。

通过匹配，可以发现该日志中命中的事件包括功能部件a没有准备好(not.ready)的事件、部件b没有准备好(not.ready)的事件和部件c电源故障(power.fail)的事件，但是不包括部件c没有准备好(not.ready)的事件。在事件状态列表将命中的事件表示为1，即该故障中的事件状态列表可表示为如下：

关键事件的选择是可扩展的，例如，可以对某些功能部件设置更多的关键事件，例如功能部件a发生驱动器故障的事件、功能部件b高速缓存无法使用的故障。另外，当存在另外的功能部件时，也可以新增新的关键事件，例如功能部件e发生媒体错误的事件。例如，可以新增以下三个预定的关键事件。

a.drive.fail＝>0

b.cache.disable＝>1

e.media.error＝>1

在确定事件状态列表之后，可以基于事件状态列表来计算故障与历史故障中的每个历史故障之间的关键事件相似度。例如，可以通过矢量e-状态来表示事件状态列表的内容。例如，针对未分类的故障，e-状态＝[e0,e1,e2,…,en]，其中如果第i个事件在未分类的故障的日志中被命中，则ei＝1，如果第i个事件在未分类的故障的日志中没有被命中，则ei＝1。针对历史故障中的每个历史故障，e-状态’＝[e0’,e1’,e2’,…,en’]，其中如果第i个事件在特定历史故障的日志中被命中，则ei’＝1，如果第i个事件在特定历史故障的日志中没有被命中，则ei’＝1。

接下来，可以对事件状态列表中的每个事件进行加权，则未分类的故障与特定历史故障之间的相似度得分可以通过以下公式(1)进行计算。

其中s’表示未分类的故障与特定历史故障之间相似度得分，wi表示 第i个关键事件的权重，权重可以根据事件重要性进行设置，ei表示针对未分类的故障的第i个事件的命中状态，ei’表示针对特定历史故障的第i个事件的命中状态。此外，为了使得相似度得分在0到1之间，可以通过以下公式(2)对相似度得分进行归一化处理。

s＝s’/smax；(2)

其中s表示归一化后的相似度得分，smax等于s’的最大值。然后，根据已确定的关键事件相似度得分s，对故障进行分类，例如将故障分类到关键事件相似度最高的历史故障所对应的分类位置，或者将关键事件相似度得分最高的多个(例如，10个)历史故障中出现次数最多的分类位置作为该故障的分类位置。可选地，除了关键事件相似度，还可以基于其他一些因素，来对故障进行分类。

在一些实施例中，方法100的步骤108还可以包括：将关键事件相似度大于预定阈值的所有历史故障确定为相关的历史故障；计算故障与相关的历史故障中的每个历史故障之间的特定特征的相似度，特定特征包括与故障相关联的以下各项中的至少一项：新近度(即，故障发生的时间、状态(即，故障目前的处理状态)、发行号(release)、版本号(version)以及重复值(即，该故障被重复出现的次数)；以及基于关键事件相似度和特定特征相似度二者，对故障进行分类。也就是说，除了计算关键事件相似度，还可以计算其他特定特征的相似度，并根据关键事件和其他特定特征的相似度二者来对故障进行分类。

在一个实施例中，可以分别计算特定特征中的每个特征的特征相似度，例如通过比较故障之间的时间戳信息，计算新近度相似度；通过确定历史故障的当前状态，计算状态相似度；通过比较发生故障的软件之间发行号信息，计算发行号相似度；通过比较发生故障的软件之间版本号信息，计算版本号相似度；以及通过确定故障在历史故障中的重复出现的数量，计算重复值相似度。此外，可以根据关键事件的相似度及权重和特定特征中的每个特征的相似度及权重，确定故障与历史故障中的每个历史故障之间的总相似度；以及基于总相似度，对故障进行分类。

在一些实施例中，可以从从系统日志或系统数据库获得与其它特征有关的信息。例如，从日志文件收集其他特征的信息，对于无法从日志文件本身获得的其它特征信息，可以从实况系统或者其它资源等进行收集。可以实时地获得信息，也可以构建数据库，提前存储与故障有关的信息。这些信息很大程度上能够表示故障之间的关联或者相关程度。例如，可以计算与故障相关联的新近度得分、状态得分、发行号得分、版本号得分以及重复值得分。

新近度得分

新近度(recency)被定义为故障之间的时间紧密程度。在获得故障的时间戳信息之后，根据故障的时间戳信息对所有故障进行排序，每个故障可以被分类作为时间戳顺序#的唯一的t#。因此，t#是从0到n的唯一编号，以标记故障发生的时间线，其中n表示所有可用的故障的总数。通过以下公式(3)来计算未分类的故障与特定历史故障之间的新近度得分。

其中，r表示未分类的故障与特定历史故障之间的新近度得分，公式(3)已经进行了r值的归一化处理，因此r的值在0-1之间，tu表示未分类的故障的时间戳顺序t#，ta表示特定历史故障的时间戳顺序t#，l表示在最近的故障上的加权的带宽参数，其指示前l名或者第l名前后的故障需要被重点考虑，根据一个实施例，将l的默认值设置为10000。在另一个实施例中，还可以通过计算故障之间的时间间隔等方式确定新近度得分。

状态得分

故障从产生到最终被解决一共会经历多个状态，故障的状态表示着故障由指定分类位置处理的处理进展情况。例如，故障就可以具有以下五个处理状态，当故障首先被产生时，其状态是waiting_assign，然后它被分类到相应的工作人员进行处理，其状态是“in_progess”，如果工作人员得到故障发生的根本原因，则他将会将故障的状态其设置为“root_cause_known”；然后进 行相应的修正处理，即进入状态“fix_in_progress”，最终在完成故障的修正处理之后，状态变为已修正状态“fixed”。因此，针对故障的示例分析状态的顺序如下：

waiting_assign(0)->in_progress(1)->root_cause_known(2)->fix_in_progress(3)->fixed(4)

如以上顺序所指示的，如果故障的状态指示故障是较新的，则对该故障打更高的分。一般来说，新产生的历史故障更可能与未分类的故障相关，而那些已经修正的故障，则可能较少与未分类的故障相关。因此，对于具有m个状态的故障而言，可以通过以下公式(4)来计算特定历史故障的状态得分。

其中，sv表示故障的状态得分，它的值在0-1之间，os表示故障的当前状态在所有状态中所处的顺序，例如，“in_progress”状态的顺序是1，n表示被选择为归一化状态得分的值，其中n≥m。例如，将n选择为10，从而计算出当前状态为“in_progress”的故障的状态得分是0.9，而当前状态为“fixed”的故障的状态得分是0.6，这也说明了正在被处理的那些故障的热度得分反而更高。然而，上述状态顺序和公式(4)只是一种示例，可以包括其他状态顺序，并且根据故障的当前状态计算出故障的状态得分。

发行号得分

在工程组织中，针对相同的产品可以开发许多不同的发行号(release)。一般来说，与具有不同发行号的两个软件相比，具有相同发行号的两个软件之间的关联性更大。发行号信息一般可以从产生故障的系统中被获得。在一个实施例中，如果发生未分类的故障的软件与发生特定历史故障的软件的发行号相同，则发行号得分被确定为1，如果不相同，则发行号得分被确定为0。在另一个实施例中，如果发行号可以按照发行的先后时间或者顺序进行排序，则通过以下公式(5)根据软件之间的发行号排序间隔来计算故障的发行号得分。

其中，rv表示故障的发行号得分，smax表示可用的发行号的最大顺序编号，s表示发生特定历史故障的软件的发行号顺序编号，s表示发生未分类的故障的软件的发行号顺序编号。由公式(5)可见，软件之间的发行号越接近，发行号得分越高。根据本公开的另一个实施例，如果在特定的发行号上故障发生更为频繁，则也可以对该发行号设置更高的发行号得分。

版本号得分

在工程组织中，针对相同的产品可以开发许多不同的版本号(version)。一般来说，与具有不同版本号的两个软件相比，具有相同版本号的两个故障之间的关联性更大。版本号信息一般可以从产生故障的系统中被获得。在一个实施例中，如果发生未分类的故障的软件与发生特定历史故障的软件的版本号相同，则版本号得分被确定为1，如果不相同，则版本号得分被确定为0。在另一个实施例中，如果版本号可以按照版本的先后时间或者顺序进行排序，则通过以下公式(6)根据软件之间的版本号排序间隔来计算故障的版本号得分。

其中，v表示故障的版本号得分，smax表示可用的版本号的最大顺序编号，s表示发生特定历史故障的软件的版本号顺序编号，s表示发生未分类的故障的软件的版本号顺序编号。由公式(5)可见，软件之间的版本号越接近，版本号得分越高。根据本公开的另一个实施例，如果在特定的版本号上故障发生更为频繁，则也可以对该版本号设置更高的版本号得分。

重复值得分

一般来说，在历史故障的分析或者调试期间，会标识相同的故障，这些故障重复信息会被存储在数据库中，可选地，也可以在故障的状态分析过程中记录故障的重复次数。通常，故障重复的次数越多，说明该故障出现的可能性越大，故障的关注度和流行性也越大，因此未分类的故障与其相关的可能性也越大。根据特定历史故障在所有特定 历史故障中的累计副本数量，来计算故障的重复值得分。例如，可以通过以下公式(7)来计算故障的重复值得分。

其中，dv表示故障的重复得分，其值在0-1之间，cd表示故障被重复的次数，d表示所有历史故障中的最高故障重复次数，如果d的值是0，则默认将其设置为1。

在分别计算其它特征中的每个特征的得分(例如，r、sv、rv、v、dv)之后，根据其它特征中的每个特征的权重来计算其它特征的得分。根据本公开的一个实施例，其它特征之间可以设置为相同的权重，则其它特征的得分等于每个特征得分(例如，r、sv、rv、v、dv)之和。根据本公开的另一个实施例，其它特征之间的权重可以设置为不相同，则根据各自的权重来计算综合的其它特征的相似度得分。例如，其它特征的相似度得分＝a1×r+a2×sv+a3×rv+a4×v+a5×dv，其中a1-a5分别表示各个特定特征的权重。

在一些实施例中，方法100中的步骤108还可以包括：选择相关的历史故障中总相似度排名前k名的相关的历史故障，其中k≥3；对前k名的相关的历史故障的分类位置进行统计；以及选择统计次数最多的分类位置作为故障要被分类的最终分类位置。在一些实施例中，如果一个分类位置和另一个分类位置的统计出的次数相同，则选择这两个分类位置的故障中得分排名最高的故障对应的分类位置作为最终分类位置。在一些实施例中，可以使用k-近邻算法来实现本公开的实施例统计过程。

在一个实施例中，针对名称为coherence_error_2015-11-23_780321的给定故障，对其执行方法100的步骤。在该示例中，选择总相似度得分前9的特定历史故障的进行分类位置统计。根据统计结果，前9名中，出现次数最多的分类位置是“mcx:mcc”，共3次，因此，事件#68062的故障自动分类的分类位置是“mcx:mcc”。

表1：总相似度得分排名前9的故障的得分

由此可见，本公开的实施例的方案能够快速地、自动地对故障进行自动分类，并且其故障自动分类方法的准确率超过60％，而现有的人工故障分类方式的准确率一般都只有50％左右，因此，本公开的实施例的方案能够更准确地对故障进行自动分类。

图2图示了根据本公开的另一个实施例的针对故障的自动分类方法200的流程图。在步骤202处，获得与故障相关联的信息，例如获得关键事件信息，以及可选地还可以获得新近度信息、状态信息、发行号信息、版本号信息或者重复值信息中的一项或多项。在步骤204处，对获得的信息进行数据抽取和准备，使得信息被转换成可以被计算的标准化格式。在步骤206处，进行特征转换和归一化处理，计算出相应特征的相似度得分(例如，以上所描述的s、r、sv、rv、v或dv)，并对每个特征得分进行归一化处理，使得每个特征得分的值在0-1之间。在步骤208处，根据每个特征得分计算总得分(例如， 根据每个特征的权重进行加权计算)，并且按得分对相关的历史故障进行排名，并且选择前k名(例如，k＝10)的故障对应的分类位置进行统计(例如，前10名中，aaa分类位置出现5次，bbb分类位置出现3次)，根据统计结果选择最相关的分类位置(例如，aaa分类位置)进行分类。

图3图示了根据本公开的实施例的故障的自动分类设备300的框图。该设备300包括：日志获取装置302，用于获取与故障相关联的日志；事件确定装置304，用于确定日志中的关键事件；相似度确定装置306，用于根据关键事件，确定该故障与历史故障中的每个历史故障之间的关键事件相似度，其中历史故障已经被分类；以及故障分类确定装置308，用于至少部分地基于关键事件相似度，对所述故障进行分类。

应当理解，设备300可以利用各种方式来实现。例如，在某些实施例中，设备300可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本公开的实施例的设备和装置不仅可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合来实现。

图4图示了可以用来实施本公开的实施例的设备400的示意性框图。如图所示，设备400包括中央处理单元(cpu)401，其可以根据存储在只读存储器(rom)402中的计算机程序指令或者从存储单元408加载到随机访问存储器(ram)403中的计算机程序指令，来 执行各种适当的动作和处理。在ram403中，还可存储设备400操作所需的各种程序和数据。cpu401、rom402以及ram403通过总线404彼此相连。输入/输出(i/o)接口405也连接至总线404。

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

上文所描述的各个过程和处理，例如方法100，可由处理单元401执行。例如，在一些实施例中，方法100可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由rom402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序被加载到ram403并由cpu401执行时，可以执行上文描述的方法100的一个或多个步骤。

应当注意，尽管在上文的详细描述中提及了设备的若干装置或子装置，但是这种划分仅仅是示例性而非强制性的。实际上，根据本公开的实施例，上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

以上所述仅为本公开的实施例可选实施例，并不用于限制本公开的实施例，对于本领域的技术人员来说，本公开的实施例可以有各种更改和变化。凡在本公开的实施例的精神和原则之内，所作的任何修改、等效替换、改进等，均应包含在本公开的实施例的保护范围之内。

虽然已经参考若干具体实施例描述了本公开的实施例，但是应该理解，本公开的实施例并不限于所公开的具体实施例。本公开的实施例旨在涵盖在所附权利要求的精神和范围内所包括的各种修改和等同布置。所附权利要求的范围符合最宽泛的解释，从而包含所有这样 的修改及等同结构和功能。