CN108880838A - 业务故障的监控方法及装置、计算机设备及可读介质 - Google Patents

Abstract

本申请提出了业务故障的监控方法及装置、计算机设备及可读介质，其中，监控方法包括：采集故障业务的关联业务的实际故障数据；将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务出现故障的关联业务作为故障源。采用本申请实施例，在定位故障业务的故障源时，提高了定位故障源的效率以及准确率。

Description

业务故障的监控方法及装置、计算机设备及可读介质

技术领域

本申请涉及互联网数据处理技术领域，特别涉及一种业务故障的监控方法及装置，一种计算机设备，一种计算机可读介质，一种用户界面交互设备，一种故障源的定位方法，以及，一种数据异常检测方法。

背景技术

目前，随着互联网技术的发展，基于互联网技术的软件系统或者互联网产品越来越多，例如，网上商城。在软件系统或者互联网产品中，可以实现多种业务，例如，网上商城每分钟创建的交易就是一种业务。在一般情况下，每种业务都有与其相关的子业务，例如，与网上商城上每分钟创建交易的业务、相关的子业务有：发送咨询信息、访问网上商城首页、搜索产品，以及保存产品信息等等。

软件系统或者互联网产品在使用的过程中会出现业务故障，即软件系统或者互联网产品所定义的功能出现异常，这种功能上的异常可以称为业务故障。例如：业务的功能错误、功能失效、业务涉及的数据出现错误、业务响应延时等不符合软件系统或者互联网产品定义功能的异常情况。一般引起业务故障的故障源为与此业务相关联的子业务。因此，需要及时定位故障源，进而对故障源进行修复，尽快使业务恢复正常。

在现有技术中，定位业务故障源的方法，是通过业务人员人工对与业务相关的子业务等进行排查故障，并汇总排查故障的结果，通过对汇总结果进行人工分析来确定业务的故障源。

发明内容

但是发明人在研究过程中发现，在现有技术对业务定位故障源时，由于与业务相关的子业务的数量较多，因此通过业务人员对子业务进行排查、分析排查结果的方式，会使得确定故障源即导致故障业务出现故障的其他业务或子业务的效率较低，并且，业务人员根据大量的排查结果人工确定故障源，会因为人为疏忽使得确定故障源的准确率低。

基于此，本申请提供了一种业务故障的监控方法，用以采用依次触发各业务产生故障，将受该故障影响的其他业务确定为故障业务的关联业务，并采集所述关联业务对应的故障数据作为参考故障数据；然后，在业务出现故障时，将故障业务的各关联业务的实际故障数据分别与参考故障数据进行比较，依据比较结果确定出导致故障业务出现故障的关联业务。

本申请还提供了一种业务故障的监控装置、一种计算机设备、一种计算机可读介质和一种用户界面交互设备，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，一方面，本申请公开了一种业务故障的监控方法，该方法包括：

采集故障业务的关联业务的实际故障数据；将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务发生故障的关联业务；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

其中，该方法还包括：建立故障数据库，所述故障数据库用于保存所述参考故障数据、关联业务以及两者的对应关系。

其中，所述建立故障数据库，包括：选取任意一个业务、一级子业务或二级子业务作为待触发业务；依次触发所述待触发业务产生故障，以及，将受所述故障影响的其他业务确定为所述待触发业务的关联业务；采集所述关联业务对应的故障数据作为参考故障数据；将所述故障业务、关联业务及对应的参考故障数据存储至故障数据库中；依次选取其他业务、一级子业务或二级子业务作为故障业务，执行所述确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过。

其中，所述将所述实际故障数据分别与预先生成的参考故障数据进行比较，包括：将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量；分别计算各个关联业务的第一向量和第二向量之间的距离。

其中，所述依据比较结果确定所述故障业务发生故障的关联业务，包括：比较各关联业务的第一向量和第二向量之间的距离，并将距离最小值对应的关联业务作为导致所述故障业务出现故障的关联业务。

其中，所述将所述实际故障数据分别与预先生成的参考故障数据进行比较，包括：将各关联业务的实际故障数据分别与各参考故障数据进行相减操作，得到各关联业务对应的数据相减结果。

其中，所述依据比较结果确定导致所述故障业务发生故障的关联业务，包括：将最小的数据相减结果对应的关联业务，确定为导致所述故障业务发生故障的关联业务。

其中，所述方法还包括：实时采集各业务的实际业务数据，判断所述实际业务数据与预先生成的业务标准数据是否一致，如果否，则将不一致的业务确定为故障业务。

其中，所述方法还包括：依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

另一方面，本申请实施例还提供了一种业务故障的监控装置，该监控装置包括：

采集单元，用于采集故障业务的关联业务的实际故障数据；比较单元，用于将所述实际故障数据与参考故障数据进行比较；确定单元，用于确定导致所述故障业务发生故障的关联业务；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

其中，所述装置还可以包括：建立单元，用于建立故障数据库，所述故障数据库用于保存所述参考故障数据、关联业务以及两者的对应关系。

其中，所述建立单元可以包括：选取子单元，用于选取任意一个业务、一级子业务或二级子业务作为待触发业务；确定子单元，用于依次触发所述待触发业务产生故障，以及，将受所述故障影响的其他业务确定为所述待触发业务的关联业务；采集子单元，用于采集所述关联业务对应的故障数据作为参考故障数据；存储子单元，用于将所述关联业务及对应的参考故障数据存储至故障数据库中；执行子单元，用于依次选取其他业务、一级子业务或二级子业务作为故障业务，执行所述确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过。

其中，比较单元可以包括：向量转化子单元，用于将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量；距离计算子单元，用于分别计算各个关联业务的第一向量和第二向量之间的距离。

其中，确定单元可以包括：距离比较子单元，用于比较各关联业务的第一向量和第二向量之间的距离得到距离最小值；第一故障源确定子单元，用于将所述距离最小值对应的关联业务作为导致所述故障业务出现故障的关联业务。

其中，比较单元可以包括：相减子单元，用于将各关联业务的实际故障数据分别与各参考故障数据进行相减操作，得到各关联业务对应的数据相减结果。

其中，确定单元可以包括：第二故障源确定子单元，用于将最小的数据相减结果对应的关联业务，确定为导致所述故障业务发生故障的关联业务。

其中，本实施例还可以包括：采集单元，用于实时采集各业务的实际业务数据，判断所述实际业务数据与预先生成的业务标准数据是否一致，如果否，则将不一致的业务确定为故障业务。

其中，本实施例还可以包括：修复单元，用于依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

再一方面，本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有使计算机执行用于业务故障的监控程序，该处理包括以下步骤：

采集步骤，其采集故障业务的关联业务的实际故障数据；比较步骤，其将所述实际故障数据与参考故障数据进行比较；确定步骤，其确定导致所述故障业务发生故障的关联业务；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

又一方面，本申请实施例还提供了一种计算机设备，该计算机设备包括：处理器、存储器、网络接口和总线系统；所述总线系统，用于将所述计算机设备的各个硬件组件耦合在一起；所述网络接口，用于实现所述计算机设备与至少一个其它计算机设备之间的通信连接；所述存储器，用于存储程序指令和/或数据；所述处理器，用于读取所述存储器中存储的指令和/或数据，执行以下操作：

采集故障业务的关联业务的实际故障数据；将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务发生故障的关联业务；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

又一方面，本申请实施例还提供了一种用户界面交互设备，包括：第一交互模块，用于在接收第一触发指令后，向处理器转发所述第一触发指令，以便处理器采集故障业务的关联业务的实际故障数据；第二交互模块，用于接收第二触发指令，并向处理器转发所述第一触发指令，以便处理器将所述实际故障数据与参考故障数据进行比较；第三交互模块，用于接收第三触发指令，并向处理器转发所述第三触发指令，以便处理器确定导致所述故障业务发生故障的关联业务并进行显示；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

又一方面，本申请实施例还提供了一种故障源的定位方法，该方法包括：采集故障业务的关联业务的实际故障数据；其中，所述实际故障数据用于表示所述故障业务在出现故障时的业务使用情况；将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务发生故障的关联业务；所述关联业务包括：故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

又一方面，本申请实施例还提供了一种故障源的定位方法，该方法包括：如果互联网中能够满足用户需求的功能出现异常，确定该功能对应的故障业务；采集所述故障业务的关联业务的实际故障数据，所述实际故障数据用于表示所述故障业务在出现故障时的业务使用情况；将所述实际故障数据与参考故障数据进行比较；依据比较结果确定导致所述故障业务发生故障的关联业务；所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

本申请实施例还提供了一种数据异常检测方法，其中，异常包括：预设时间范围内，操作行为的统计数据不符合阈值；参考数据包括：多个已知异常之间的关系数据；该数据异常检测方法包括：获取至少一个待检测异常的异常数据；将所述待检测异常的异常数据与参考数据比较；确定导致所述待检测异常的其他已知异常。

与现有技术相比，本申请实施例包括以下优点：

由于本申请实施例，在业务发生故障时，可以将故障业务的各关联业务对应的实际故障数据，分别与，预先生成的故障数据库中的各参考故障数据进行比较，可以自动确定出导致故障业务出现故障的关联业务。因此，本申请实施例无需人工排查故障，不仅可以提高确定故障源的效率，还通过模拟各业务在出现故障来获得各关联业务真实的故障数据，并将真实故障数据作为参考故障数据来定位导致业务出现故障的关联业务，也提高了定位故障业务的故障源的准确率。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请的表示业务与同级业务、各级子业务间的关系示意图；

图2是本申请的业务故障的监控方法实施例的应用场景的示意图；

图3是本申请的故障数据库的建立方法实施例的流程图；

图4是本申请的一种业务故障的监控方法实施例的流程图；

图5是本申请的一种业务故障的监控装置实施例的结构框图；

图6是本申请的一种计算机设备实施例的硬件结构框图；

图7a为本申请的用户界面交互设备的控件显示示意图；

图7b为本申请的用户界面交互设备显示故障源的界面示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

术语定义

业务，在软件系统或互联网产品中，能够满足用户的某种需求的功能可以称为一个业务。业务域中的各业务的子业务则组成了业务子域。

业务域，对于功能相同或相近的业务，可以将这些业务划分在同一个业务域中。例如，在网上商城中，将满足用户的收藏功能的“产品收藏业务”和“店铺收藏业务”划分在“收藏”业务域中，等等。因此，同一个业务域包括功能相同或相近的所有业务。

同级业务，对于某业务，与该业务处于同一个业务域内的其他业务即是该业务的同级业务。

子业务，对于某业务，例如“店铺收藏业务”，该业务包括：“店铺直接收藏”和“店铺分类收藏”等业务，则将“店铺直接收藏”和“店铺分类收藏”称为“店铺收藏业务”的子业务。可见，子业务是否正常直接影响了业务是否正常，并且，一个业务可以包括一个或多个子业务。

业务故障，软件系统或者互联网产品所定义的功能出现异常，无法满足用户的正常需要或者用户无法正常使用该功能，则这种功能上的异常可以称为业务故障。

在实际的应用场景中，每个业务都有与之相关的子业务和同级业务。例如，“网上商城每分钟创建的交易量”这一业务，其同级业务可以为“网上商城每分钟创建的交易额”；在实际的应用中，存在直接影响业务的子业务，例如，一般情况下用户在网上商城下单前，会先向客服咨询详细的产品信息，在得到客服满意的答复后再下单，因此，如果咨询产品信息的功能出现了异常很可能就导致用户无法正常向客服询问产品的详情，进而导致用户不再针对该产品下单。因此，能够直接影响“网上商城每分钟创建的交易量”这一业务的子业务有“咨询产品信息”，或者“访问网上商城首页”(如果无法正常访问网上商城首页，也会导致用户无法对该网上商城的产品进行下单)等。

在本申请实施例中，将直接影响业务的子业务称为一级子业务；同理，存在直接影响一级子业务的子业务。例如，如果用户在向客服发送问题希望了解产品信息时，如果无法正常向客服发送问题或者其他咨询信息，则势必会影响用户正常咨询产品信息；可以理解的是，如果客服无法向用户正常发送产品的详情信息来回复咨询信息，也会影响用户正常咨询产品信息。可见，能够直接影响“咨询产品信息”的子业务有“发送咨询信息”“回复咨询信息”等子业务，则将直接影响一级子业务的子业务称为业务的二级子业务。当然，也可以将直接影响二级子业务的子业务称为业务的三级子业务，以此类推，本申请实施例中的业务可以有N级子业务，N是大于1的整数。

因此，各业务与其同级业务、各级子业务就形成一个业务关系网，可以参考图1所示，图1示例性地表示出了在业务关系网中各业务与同级业务、与一级子业务、以及与二级子业务之间的关系。

为了示例性说明业务与子业务、同级业务间的关系，图1中只列出了三类业务，一类是业务域内的业务；一类是一级业务子域内的一级子业务；一类是二级业务子域内的二级子业务。其中，业务域中的业务级别最高，一级业务子域中的一级子业务的级别次之，二级业务子域中的二级子业务的级别最低。当然，在本申请实施例中以业务存在一级子业务和二级子业务为例进行说明，在实际应用中，还有可能存在三级子业务等，本领域技术人员按照本申请实施例的方法都可以检测出故障源(即导致故障业务出现故障的关联业务)。

图1中用直线表示各业务与同级业务、各级子业务间存在关系，例如，业务A与业务B是同级业务，那么，业务A与业务B相连，表示业务A与同级业务B之间相互影响；同时，业务A分别与一级子业务kpi1、kpi2以及kpi3相连，表示业务A与一级子业务kpi1、kpi2以及kpi3之间相互影响。因此，图1中的各业务与同级业务、各级子业务通过直线的连接，就形成了一个业务关系网。在实际场景中，各业务与同级业务、各级子业务都可以通过图1所示的关系网，来表示各业务与同级业务、各级子业务之间的关系。

在关系网中的各业务与同级业务、各级子业务都存在一定的关系，当某一个业务或者各级子业务出现故障时，与其相关的业务、各级子业务都会受到影响。因此，当业务域中的业务出现故障时，故障源可能是同级业务，也可能是与业务相关的各级子业务。为了快速准确的定位到业务的故障源，可以建立一个故障数据库，该故障数据库保存了各业务作为故障源时，与故障源有关的各业务、各级子业务的真实故障数据。根据该故障数据库，可以对故障业务的故障源进行定位。

具体的，在实际的应用场景中，本申请实施例实现对业务进行监控的原理如图2所示。从图2可以得知，在实际场景中，监控系统201通过对业务域中的各业务及各级子业务进行实时监控，实时比较各业务及各级子业务的实际业务数据，与预先生成的业务标准数据是否一致，若一致，则表示该业务或子业务正常，若不一致，则表示该业务或子业务出现了故障。其中预先生成的业务标准数据可以是，根据以往该业务处于正常状态时的数据预测得到的数据。在图2中，业务域的个数为N个，N可以为大于1的整数。

当监控系统监控到业务域中的某一业务出现故障的时候，将业务的各关联业务的实际故障数据，与建立的故障数据库202中的参考故障数据进行比较，进而确定出故障源是哪个关联业务，以实现对故障源进行及时修复，使得故障业务尽快恢复到正常状态。

在本申请实施例中，首先由本领域技术人员建立一个故障数据库，该故障数据库中保存了受故障业务影响的各关联业务和与关联业务相对应的参考故障数据，该参考故障数据表示受故障影响的其他业务、一级子业务或二级子业务的真实故障数据。其中，参考图3所示，为本申请实施例中建立故障数据库的方法流程图，故障数据库的建立过程可以包括以下步骤：

步骤S301：选取任意一个业务、一级子业务或二级子业务作为待触发业务，依次触发所述待触发业务产生故障。

在本实施例中，建立故障数据库时，首先选取业务域中的任意一个业务、一级业务子域中的任意一个一级子业务，或者，二级业务子域中的任意一个二级子业务作为待触发业务，接着，并依次触发其产生故障。

具体的，在选取待触发业务时，为了避免漏掉某一个业务、某一个一级子业务，或者，某一个二级子业务作为故障源，可以按照业务以及各级子业务的级别从高到低，或者，从低到高，来一一选取业务触发其产生故障。

步骤S302：将受所述故障影响的其他业务确定为所述待触发业务的关联业务。

在触发业务产生故障之后，具体确定该各关联业务时，可以监控哪个业务被该故障影响了，可以将受故障影响的其他同级业务，一级子业务或者二级子业务作为关联业务。在实际应用中，可以通过统计各业务的受影响情况建立关系网，例如图1所示，则也可以按照图1所示的业务关系来确定各关联业务。

例如，“网上商城上每分钟创建的交易”是业务域中的一种业务，与该业务相关的各级子业务有：“咨询产品信息”、“访问网上商城首页”、“搜索产品”，以及“保存产品信息”等等。假设，以“咨询产品信息”作为故障源，此时，该故障源的关联业务就是：“网上商城上每分钟创建的交易”、“访问网上商城首页”、“搜索产品”，以及“保存产品信息”，等等。

步骤S303：采集所述关联业务对应的故障数据作为参考故障数据。

因为故障业务的故障发生时，其关联业务也会受到影响，因此关联业务也处于故障状态，则实时采集关联业务处于故障状态时，所对应的故障数据作为参考故障数据。参考故障数据可以包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

在实际的应用场景中，参考故障数据以数据形式反映各关联业务处于故障状态时的真实故障表现情况。具体的，各关联业务的真实故障表现情况，可以用各关联业务处于故障状态时的实际故障数据，即相对于预测基线上涨或者下跌的百分数来表示。其中，预测基线是根据个关联业务以往处于正常状态时的数据预测得到的预测数据。

例如，还以“咨询产品信息”为故障业务为例，触发“咨询产品信息”出现故障，例如，咨询产品消息无法正常发送。此时，“发送咨询产品消息”这一子业务受到了影响处于故障状态，接着，“网上商城上每分钟创建的交易”、“访问网上商城首页”、“搜索产品”，以及产品“保存产品信息”等业务，同样处于故障状态。

那么，对这些受影响的关联业务采集其实际故障数据可知，网上商城上每分钟创建的交易量的实际数据相对于预测基线上涨了10％、访问网上商城首页所用的时间的实际数据相对于预测基线上涨了25％、搜索产品所用的时间的实际数据相对于预测基线下跌了70％、将产品保存产品信息所用的时间的实际数据相对于预测基线上涨了30％等。上述的网上商城上每分钟创建的交易量、访问网上商城首页所用的时间、搜索产品所用的时间，以及保存产品信息所用的时间所对应的变化数据，就是“咨询产品信息”出现故障时各关联业务所对应的参考故障数据。

为了清楚表示出该故障业务的关联业务，以及关联业务的故障数据之间的关系，可以采用以下表1所示的表格来记录。

表1

步骤S304：将所述故障业务、关联业务及对应的参考故障数据存储至故障数据库中。

当选取的待触发业务，都确定出了关联业务以及对应的参考故障数据时，可以将故障业务、关联业务以及对应的参考故障数据存储至故障数据库中。例如，保存在如下的表2中，将表2存储至故障数据库中。其中，表2中“C”表示业务域中的一种业务，“C-T1”、“C-T2”以及“C-T3”表示业务“C”的一级子业务，“C-T3-I1”表示业务“C”的二级子业务，同时也表示一级子业务“C-T3”的一级子业务。

表2

在表2中，“+”表示相对于预测基线上涨，“-”表示相对于预测基线下跌。

接着，依次选取其他业务、一级子业务或二级子业务作为故障源，执行所述步骤S302确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过，并将受影响的各关联业务以及对应的参考故障数据存储至故障数据库中。

上述通过模拟的方法，触发每个业务出现故障，来确定受影响的关联业务以及对应的参考故障数据。在实际的应用场景中，除了通过模拟的方法外，还可以根据各业务以往真实发生故障时，将故障业务的关联业务出现的真实故障数据作为对应的参考故障数据，并将故障源以及对应的参考故障数据保存至故障数据库中。

通过上述对业务及各级子业务触发故障的流程，可以通过模拟业务产生故障的方式，生成关联业务的参考故障数据，建立故障数据库，。

在介绍完故障数据库的建立过程之后，参考图4，示出了本申请一种业务故障的监控方法实施例的流程图，本实施例可以包括以下步骤：

步骤S401：采集故障业务的关联业务的实际故障数据。

在本实施例中，当监控系统监控到业务域中的某一业务的实际业务数据与预先生成的参考故障数据不一致时，可以确定该业务出现了故障，将该业务作为故障业务，并采集该故障业务的各关联业务的实际故障数据。其中，与故障业务相关联的关联业务可以包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务，等等。

在实际应用中，可以判断互联网中能够满足用户需求的功能是否出现异常，如果出现异常，则可以确定该功能对应的业务出现了故障，将该业务作为故障业务。

例如表3所示的故障业务“C”，所采集的业务“C”的各关联业务的实际故障数据，其中，“C-T1”、“C-T2”、“C-T3”表示故障业务“C”的一级子业务，“C-T3-I1”表示一级子业务“C-T3”的二级子业务。

表3

步骤S402：将所述实际故障数据与参考故障数据进行比较。

在本实施例中，为了定位到导致故障业务出现故障的关联业务，即故障业务的故障源，可以将采集到的关联业务的实际故障数据，分别与预先生成的故障数据库中、各关联业务对应的参考故障数据进行比较，从而确定与所述实际故障数据最接近的那条参考故障数据，以及，将该条最接近的参考故障数据对应的关联业务，确定为导致故障业务出现故障的故障源。

具体的，在本实施例中，将关联业务的实际故障数据与参考故障数据进行比较有多种实施方式，包括通过向量的方式，或者，通过相减的方式，等等。

在第一种实施方式中，将实际故障数据与参考故障数据进行比较的过程可以包括：步骤A1～步骤A2：

步骤A1：将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量。

在本实施例中，将关联业务的实际故障数据，分别转化为第一向量；同时，将故障数据库中的各条参考故障数据，转化为第二向量。具体的，可以采用向量空间模型等方法来将文本形式的实际故障数据或参考故障数据转化为向量。

需要说明的是，在本实施例中，生成第一向量与第二向量没有先后顺序，以及，在对故障数据库中的每条参考故障数据生成第二向量的过程中，各条参考故障数据生成第二向量也不限定先后顺序。

步骤A2：分别计算各个关联业务的第一向量和第二向量之间的距离。

本步骤中，分别计算对应的各个关联业务的第一向量和第二向量之间的距离。此时，得到与参考故障数据条数相同的若干个距离值。例如，参考故障数据有200条，则本步骤中计算出的距离值也对应有200个。

在第二种实施方式中，具体的，将各关联业务所对应的实际故障数据，分别与故障数据库中各参考故障数据对应相减，得到各关联业务对应的数据相减结果。

例如，当前出现故障的业务“C”，业务“C”的实际故障数据，以及关联业务的实际故障数据如表4所示。

表4

预先生成的故障数据库中，各关联业务对应的参考故障数据如表5所示。

表5

为了说明将各关联业务的实际故障数据分别与各参考故障数据进行相减操作的过程，表5中只列举了两条参考故障数据。相减操作可以为：表4中的数据与表5中显示的第一条参考故障数据对应相减，得到表6第一行所示的相减结果；同理，将表4的数据与表5中的第二条参考故障数据对应相减，得到表6第二行所示的相减结果。

表6

当然，上述表格中的数据仅仅为具体示例，不应将其理解为本申请的限定。

步骤S403：确定导致所述故障业务出现故障的关联业务。

在本实施例中，依据得到的比较结果确定导致故障业务出现故障的关联业务，作为故障业务的故障源。具体的，通过步骤S402中第一种实施方式得到的比较结果，确定导致故障业务出现故障的关联业务的步骤可以包括：步骤B1～步骤B2：

步骤B1：比较各关联业务的第一向量和第二向量之间的距离。

本步骤比较各关联业务的第一向量和第二向量之间的距离，从而找出关联业务对应的距离是所有距离值中最小的。

步骤B2：将所述距离最小值对应的故障源确定为目标故障源。

在本步骤中，将最小距离值，即第一向量与第二向量之间的距离最小的关联业务，确定为导致故障业务出现故障的关联业务。

通过第二种实施方式，得到各关联业务对应的数据相减结果，可以将每一条数据相减结果的各项进行相加，得到各条数据相减结果所对应的数值，再将数据相减结果对应的数值最小的关联业务，确定为导致所述故障业务出现故障的关联业务，即故障业务的故障源。例如，表6所示的各关联业务对应的故障数据相减结果，可以分别将表6中两行的数据进行相加，此时得到-7％和+74％两个数据，由于，-7％的绝对值远远小于+74％的绝对值，绝对值越小表示表5中的故障数据，与表6中第一行所示的参考故障数据越接近。因此，将表6所示的第一行参考故障数据对应的关联业务确定为导致故障业务出现故障的故障源。

在本实施例中，在步骤S403确定出故障业务的故障源后，还可以包括：

步骤S404：依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

在本实施例中，预先生成有故障处理规则，该故障处理规则中存有各个业务在出现故障时对应的修复方法，当确定出故障业务的故障源后，根据预先生成的故障处理规则中故障源对应的修复方法，对故障源进行修复，使得故障源恢复正常，以便故障业务也能尽快恢复到正常状态。例如有一条故障处理规则为：“若咨询产品信息出现故障时，需要软件部的技术人员进行维修”，则检测出“咨询产品信息”出现故障时，按照对应的该条故障处理规则，需要通知软件部的相关人员进行修复。

通过本实施例，在业务发生故障时，可以将故障业务的各关联业务对应的实际故障数据，分别与，预先生成的故障数据库中的各参考故障数据进行比较，可以自动确定出导致故障业务出现故障的关联业务。因此，本申请实施例无需人工排查故障，不仅可以提高确定故障源的效率，还通过模拟各业务在出现故障来获得各关联业务真实的故障数据，并将真实故障数据作为参考故障数据来定位导致业务出现故障的关联业务，也提高了定位故障业务的故障源的准确率。

本申请实施例还公开了一种数据异常检测方法，其中，异常可以包括：预设时间范围内，操作行为的统计数据不符合阈值；参考数据可以包括：多个已知异常之间的关系数据；本实施例可以包括步骤C1～步骤C3：

步骤C1：获取至少一个待检测异常的异常数据。

在本实施例中，操作行为可以包括用户在互联网上与服务器进行交互的行为，例如网上商城下订单的行为，或者邮箱登录行为，等等，都属于本实施例中提到的操作行为。

在实际应用中，可以通过统计操作行为在预设时间范围内的数据量，并判断统计数据是否不符合预设的阈值，来判断操作行为是否出现异常。例如，对于网上商城下订单的操作行为，预设时间范围为一分钟的话，预设的阈值可以是100000，则可以实时统计在一分钟内网上商城下订单的操作行为的数据是否为100000，如果是70000，则与预设的阈值100000不同，说明该操作行为的统计数据不符合阈值。当然，本领域技术人员也可以将阈值设置为一个范围，例如90000～100000，则统计数据在该区间内，则认为符合阈值，如果不在该区间内，就可以认为不符合阈值。

对于不符合阈值的统计数据，将对应的操作行为作为待检测异常，并获取待检测异常的关联异常的异常数据。在实际应用中，待检测异常的关联异常之间的关系通过参考数据来表示。例如，能够影响操作行为T的统计数据的操作行为有S和W，则在操作行为T出现异常成为待检测异常时，操作行为S和W则成为待检测异常T的关联异常。在本步骤中，采集到待检测异常T的关联异常的S和W的异常数据。当然，以上具体数据仅仅为示例，本领域技术人员可以根据实际需求自主设置各数据的具体数值。

步骤C2：将所述待检测异常的异常数据与参考数据比较。

在本步骤中，基于步骤C1中采集到的、待检测异常的关联异常的异常数据，将其与关联异常的参考数据进行比较。

该参考数据，可以预先存储在一个数据库中，并且，各参考数据可以通过触发各个操作行为出现异常来生成。例如，对于操作行为A，触发该操作行为A出现异常，然后检测其他操作行为是否也相应的出现异常，例如，操作行为D和F也出现了异常，而操作行为B和E并未出现异常。基于此，可以获取出现异常的操作行为D和F的统计数据作为操作行为B和F的参考数据。然后依次触发各个操作行为出现异常，可以得到每个操作行为出现异常时，其他关联异常的参考数据。

步骤C3：确定导致所述待检测异常的其他已知异常。

在实际应用中，通过将异常数据与参考数据进行比较，可以确定出异常数据中与参考数据最接近或者相同的那一条异常数据，该条最接近或者相同的异常数据对应的操作行为也出现了异常，并且正是该异常导致了待检测异常。例如，通过比较发现，操作行为D出现异常时对应的参考数据，与步骤C1中采集的操作行为D的异常数据最接近，则在本步骤中，将操作行为D认为是导致待检测异常A出现异常的其他已知异常。

在本实施例中，通过采集待检测异常的异常数据，将其与参考数据相比较，从而可以在操作行为的统计数据不符合阈值的情况下，快速找到导致该操作行为的统计数据不符合阈值的原因在于哪一个操作行为，从而准确确定导致待检测异常的其他已知异常。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请一种业务故障的监控方法实施例所提供的方法相对应，参见图5，本申请还提供了一种业务故障的监控装置实施例，在本实施例中，该装置可以包括：

采集单元501，用于采集故障业务的关联业务的实际故障数据。

比较单元502，用于将所述实际故障数据与参考故障数据进行比较，所述参考故障数据为：各故障源发生故障时受所述故障源影响的其他业务的故障数据。

确定单元503，用于确定导致所述故障业务出现故障的关联业务。

所述关联业务可以包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据可以包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

其中，本实施例还可以包括：建立单元，用于建立故障数据库，所述故障数据库用于保存所述参考故障数据、关联业务以及两者的对应关系。

其中，所述建立单元可以包括：选取子单元，用于选取任意一个业务、一级子业务或二级子业务作为待触发业务；确定子单元，用于依次触发所述待触发业务产生故障，以及，将受所述故障影响的其他业务确定为所述待触发业务的关联业务；采集子单元，用于采集所述关联业务对应的故障数据作为参考故障数据；存储子单元，用于将所述关联业务及对应的参考故障数据存储至故障数据库中；执行子单元，用于依次选取其他业务、一级子业务或二级子业务作为故障业务，执行所述确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过。

其中，比较单元502可以包括：向量转化子单元，用于将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量；距离计算子单元，用于分别计算各个关联业务的第一向量和第二向量之间的距离。

其中，确定单元503可以包括：距离比较子单元，用于比较各关联业务的第一向量和第二向量之间的距离得到距离最小值；第一故障源确定子单元，用于将所述距离最小值对应的关联业务作为导致所述故障业务出现故障的关联业务。

其中，比较单元502可以包括：相减子单元，用于将各关联业务的实际故障数据分别与各参考故障数据进行相减操作，得到各关联业务对应的数据相减结果。

其中，确定单元503可以包括：第二故障源确定子单元，用于将最小的数据相减结果对应的关联业务，确定为导致所述故障业务发生故障的关联业务。

其中，本实施例还可以包括：采集单元，用于实时采集各业务的实际业务数据，判断所述实际业务数据与预先生成的业务标准数据是否一致，如果否，则将不一致的业务确定为故障业务。

其中，本实施例还可以包括：修复单元，用于依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

通过本实施例，在业务发生故障时，可以将故障业务的各关联业务对应的实际故障数据，分别与，预先生成的故障数据库中的各参考故障数据进行比较，可以自动确定出导致故障业务出现故障的关联业务，即故障业务的故障源。因此，本申请实施例无需人工排查故障，不仅可以提高确定故障源的效率，还通过模拟各业务在出现故障来获得各关联业务真实的故障数据，并将真实故障数据作为参考故障数据来定位导致业务出现故障的关联业务，也提高了定位故障业务的故障源的准确率。

本申请实施例还公开了一种计算机可读介质，该计算机可读介质存储有使计算机执行用于业务故障的监控程序，该处理包括以下步骤：

采集步骤，其采集故障业务的关联业务的实际故障数据；

比较步骤，其将所述实际故障数据与参考故障数据进行比较；

确定步骤，其依据确定导致所述故障业务出现故障的关联业务；

所述关联业务可以包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据可以包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

图6为本申请实施例中一种计算机设备600的硬件结构示意图。计算机设备600可用于实现业务故障的监控，例如可以是客户端。即计算机设备600可用于执行上述实施例中提供的方法。在本实施例中，计算机设备600包括：处理器601、存储器602、网络接口603和总线系统604。

所述总线系统604，用于将计算设备600的各个硬件组件耦合在一起。

所述网络接口603，用于实现计算设备600与至少一个其它计算设备之间的通信连接，可以使用互联网，广域网，本地网，城域网等方式。

所述存储器602，用于存储程序指令和/或数据。

所述处理器601，用于读取存储器602中存储的指令和/或数据，执行以下操作：

采集故障业务的关联业务的实际故障数据；将所述实际故障数据与参考故障数据进行比较；确定导致所述故障业务出现故障的关联业务；所述关联业务可以包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；所述参考故障数据可以包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

其中，所述处理器601还可以执行以下指令：建立故障数据库，所述故障数据库用于保存所述参考故障数据、关联业务以及两者的对应关系。

其中，所述建立故障数据库，可以包括：选取任意一个业务、一级子业务或二级子业务作为待触发业务；依次触发所述待触发业务产生故障，以及，将受所述故障影响的其他业务确定为所述待触发业务的关联业务；采集所述关联业务对应的故障数据作为参考故障数据；将所述故障业务、关联业务及对应的参考故障数据存储至故障数据库中；依次选取其他业务、一级子业务或二级子业务作为故障业务，执行所述确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过。

其中，所述将所述实际故障数据与参考故障数据进行比较，可以包括：将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量；分别计算各个关联业务的第一向量和第二向量之间的距离。

其中，所述确定所述故障业务出现故障的目标故障源，可以包括：比较各关联业务的第一向量和第二向量之间的距离得到距离最小值；将所述距离最小值对应的关联业务作为导致所述故障业务出现故障的关联业务。

其中，所述将所述实际故障数据分别与预先生成的参考故障数据进行比较，可以包括：将各关联业务的实际故障数据分别与各参考故障数据进行相减操作，得到各关联业务对应的数据相减结果。

其中，所述依据比较结果确定所述当前业务发生故障的目标故障源，可以包括：将最小的数据相减结果对应的关联业务，确定为导致所述故障业务发生故障的关联业务。

其中，所述处理器601还可以执行以下指令：实时采集各业务的实际业务数据，判断所述实际业务数据与预先生成的业务标准数据是否一致，如果否，则将不一致的业务确定为故障业务。

其中，所述处理器601还可以执行以下指令：依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

其中，参见图7a～图7b，本申请还提供了一种用户界面交互设备，该交互设备可以包括：

第一交互模块，用于在接收第一触发指令后，向处理器转发所述第一触发指令，以便处理器采集故障业务的关联业务的实际故障数据。

在用户通过交互界面点击“采集实际故障数据”的控件(参考图7a)后，交互设备的第一交互模块接收第一触发指令，然后，第一交互模块向处理器转发第一触发指令，以便处理器可以在故障业务发生故障的情况下，采集故障业务的各关联业务的实际故障数据。

所述关联业务可以包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务。

第二交互模块，用于接收第二触发指令，并向处理器转发所述第一触发指令，以便接收处理器将所述实际故障数据分别与预先生成的参考故障数据进行比较。

所述参考故障数据可以包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。在用户通过交互界面点击“比较故障数据”的控件(参考图7a)后，交互设备的第二交互模块接收第二触发指令，然后，第二交互模块向处理器转发第二触发指令，以便接收处理器将所述实际故障数据分别与预先生成的参考故障数据进行比较，所述参考故障数据可以为：各故障源发生故障时受所述故障源影响的其他业务的故障数据。

第三交互模块，用于接收第三触发指令，并向处理器转发所述第三触发指令，以便处理器依据比较结果确定导致所述故障业务发生故障的关联业务并进行显示(参考图7b)。

在用户通过交互界面点击“显示故障源”的控件(参考图7a)后，交互设备的第三交互模块接收第三触发指令，然后，第三交互模块向处理器转发第三触发指令，以便接收处理器发送的、依据比较结果确定的、当前业务发生故障的目标故障源并进行显示。

本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，

Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的业务故障的监控方法及装置、计算机设备、计算机可读介质和用户界面交互设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种业务故障的监控方法，其特征在于，该方法包括：

采集故障业务的关联业务的实际故障数据；

将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务出现故障的关联业务；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

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

建立故障数据库，所述故障数据库用于保存所述参考故障数据、关联业务以及两者的对应关系。

3.根据权利要求2所述的方法，其特征在于，所述建立故障数据库，包括：

选取任意一个业务、一级子业务或二级子业务作为待触发业务；

依次触发所述待触发业务产生故障，以及，将受所述故障影响的其他业务确定为所述待触发业务的关联业务；

采集所述关联业务对应的故障数据作为参考故障数据；

将所述故障业务、关联业务及对应的参考故障数据存储至故障数据库中；

依次选取其他业务、一级子业务或二级子业务作为故障业务，执行所述确定所述故障业务的关联业务的步骤，直至所有业务、一级子业务和二级子业务的故障都被触发过。

4.根据权利要求3所述的方法，其特征在于，所述将所述实际故障数据分别与预先生成的参考故障数据进行比较，包括：

将所述各关联业务的实际故障数据转化为第一向量，以及，将所述故障数据库中保存的、各关联业务的各条参考故障数据转化为第二向量；

分别计算各个关联业务的第一向量和第二向量之间的距离。

5.根据权利要求4所述的方法，其特征在于，所述依据比较结果确定所述故障业务发生故障的关联业务，包括：

比较各关联业务的第一向量和第二向量之间的距离，并将距离最小值对应的关联业务作为导致所述故障业务出现故障的关联业务。

6.根据权利要求3所述的方法，其特征在于，所述将所述实际故障数据分别与预先生成的参考故障数据进行比较，包括：

将各关联业务的实际故障数据分别与各参考故障数据进行相减操作，得到各关联业务对应的数据相减结果。

7.根据权利要求6所述的方法，其特征在于，所述依据比较结果确定导致所述故障业务发生故障的关联业务，包括：

将最小的数据相减结果对应的关联业务，确定为导致所述故障业务发生故障的关联业务。

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

实时采集各业务的实际业务数据，判断所述实际业务数据与预先生成的业务标准数据是否一致，如果否，则将不一致的业务确定为故障业务。

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

依据预先生成的故障处理规则，对所述故障业务进行修复，所述故障处理规则包括各故障业务对应的修复办法。

10.一种业务故障的监控装置，其特征在于，该装置包括：

采集单元，用于采集故障业务的关联业务的实际故障数据；

比较单元，用于将所述实际故障数据与参考故障数据进行比较；

确定单元，用于确定导致所述故障业务出现故障的关联业务；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

11.一种计算机可读介质，该计算机可读介质存储有使计算机执行用于业务故障的监控程序，该处理包括以下步骤：

采集步骤，其采集故障业务的关联业务的实际故障数据；

比较步骤，其将所述实际故障数据与参考故障数据进行比较；

确定步骤，其依据确定导致所述故障业务出现故障的关联业务；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

12.一种计算机设备，其特征在于，该计算机设备包括：处理器、存储器、网络接口和总线系统；

所述总线系统，用于将所述计算机设备的各个硬件组件耦合在一起；

所述网络接口，用于实现所述计算机设备与至少一个其它计算机设备之间的通信连接；

所述存储器，用于存储程序指令和/或数据；

所述处理器，用于读取所述存储器中存储的指令和/或数据，执行以下操作：

采集故障业务的关联业务的实际故障数据；

将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务出现故障的关联业务；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

13.一种用户界面交互设备，其特征在于，包括：

第一交互模块，用于在接收第一触发指令后，向处理器转发所述第一触发指令，以便处理器采集故障业务的关联业务的实际故障数据；

第二交互模块，用于接收第二触发指令，并向处理器转发所述第一触发指令，以便处理器将所述实际故障数据与参考故障数据进行比较；

第三交互模块，用于接收第三触发指令，并向处理器转发所述第三触发指令，以便处理器确定导致所述故障业务出现故障的关联业务并进行显示；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

14.一种故障源的定位方法，其特征在于，该方法包括：

采集故障业务的关联业务的实际故障数据；其中，所述实际故障数据包括所述故障业务在出现故障时关联业务的业务数据；

将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务出现故障的关联业务作为故障源；

所述关联业务包括：故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

15.一种故障源的定位方法，其特征在于，该方法包括：

如果互联网中能够满足用户需求的功能出现异常，确定该功能对应的故障业务；

采集所述故障业务的关联业务的实际故障数据，所述实际故障数据包括：所述故障业务在出现故障时关联业务的业务数据；

将所述实际故障数据与参考故障数据进行比较，确定导致所述故障业务出现故障的关联业务作为故障源；

所述关联业务包括：所述故障业务所处的业务域内能够影响所述故障业务的同级业务，能够影响所述故障业务的一级子业务，和/或，能够影响所述一级子业务的二级子业务；

所述参考故障数据包括：各业务、一级子业务和/或二级子业务分别作为故障源出现故障时，受所述故障影响的同级业务、一级子业务和/或二级子业务的已知故障数据。

16.一种数据异常检测方法，其中：

异常包括：预设时间范围内，操作行为的统计数据不符合阈值；

参考数据包括：多个已知异常之间的关系数据；

其特征在于，该数据异常检测方法包括：

获取至少一个待检测异常的异常数据；

将所述待检测异常的异常数据与参考数据比较；

确定导致所述待检测异常的其他已知异常。