用于确定业务系统异常原因的方法和装置与流程

本说明书的实施例通常涉及计算机领域，更具体地，涉及用于确定业务系统异常原因的方法及装置。

背景技术：

在业务系统运营时，如果发生例如业务接口变更、业务应用版本升级、外部恶意攻击等情形，业务系统可能会出现系统异常，比如业务处理不成功或者发生业务风险，从而给业务提供方或用户带来损失。在这种情况下，需要及时发现业务系统异常，并且高效地确定业务系统异常原因以便快速地进行应对。

技术实现要素：

鉴于上述问题，本说明书的实施例提供了一种用于确定业务系统异常原因的方法及装置。利用该方法及装置，能够迅速并准确地确定业务系统异常原因。

根据本说明书的实施例的一个方面，提供了一种用于确定业务系统异常原因的方法，包括：执行下述循环过程来确定业务系统异常原因，直到不存在未处理的归因维度组合为止：根据业务系统的第一业务指标数据和第二业务指标数据，确定当前归因维度组合集中的各个当前归因维度组合的当前维度值组合集，所述第一业务指标数据是在系统异常时间点发生的业务指标数据，所述第二业务指标数据是在系统参考时间点发生的业务指标数据；从所述第一和第二业务指标数据中提取出各个当前维度值组合所对应的业务指标数值；基于所提取出的业务指标数值，计算各个当前维度值组合的贡献度和异变度；从所述当前维度值组合集中获取至少一个第一当前维度值组合，所述第一当前维度值组合的贡献度大于预定阈值；针对各个第一当前维度值组合，基于所计算出的异变度，判断是否需要进行深层归因；在判断不需要进行深层归因时，根据所述第一当前维度值组合，生成业务系统异常原因，以及在判断需要进行深层归因时，通过分别向所述第一当前维度值组合对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集，以作为下一循环过程中的当前归因维度组合集。

可选地，在上述方面的一个示例中，所述当前维度值组合集是从所述第一业务指标数据和第二业务指标数据中提取出所增加归因维度的各个维度值，并将所提取的各个维度值分别增加到所述第一当前维度值组合中得到。

可选地，在上述方面的一个示例中，基于所计算出的异变度，判断是否需要进行深层归因可以包括：基于所计算出的异变度和业务归因深度要求，判断是否需要进行深层归因。

可选地，在上述方面的一个示例中，所述方法还可以包括：对所生成的业务系统异常原因进行整合。

可选地，在上述方面的一个示例中，所述整合可以包括合并、去重和/或基于异变度的排序。

可选地，在上述方面的一个示例中，所述方法还可以包括：输出所生成的业务系统异常原因。

可选地，在上述方面的一个示例中，所述方法还可以包括：获取所述业务系统的业务指标时序数据；以及基于所述业务指标时序数据，检测目标系统运营时间点是否是系统异常时间点。

可选地，在上述方面的一个示例中，所述方法还可以包括：在所述目标系统运营时间点被确定为是系统异常时间点时，确定所述目标系统运营时间点的异常程度。

可选地，在上述方面的一个示例中，所述业务指标可以是基于系统异常检测方案的应用场景定义的。

根据本说明书的实施例的另一方面，提供一种用于确定业务系统异常原因的装置，包括：维度值组合集确定单元，根据业务系统的第一业务指标数据和第二业务指标数据，确定当前归因维度组合集中的各个当前归因维度组合的当前维度值组合集，所述第一业务指标数据是在系统异常时间点发生的业务指标数据，所述第二业务指标数据是在系统参考时间点发生的业务指标数据；业务指标数值提取单元，从所述第一业务指标数据和所述第二业务指标数据中提取出各个当前维度值组合所对应的业务指标数值；计算单元，基于所提取出的业务指标数值，计算各个当前维度值组合的贡献度和异变度；维度值组合获取单元，从所述当前维度值组合集中获取至少一个第一当前维度值组合，所述第一当前维度值组合的贡献度大于预定阈值；深层归因判断单元，针对各个第一当前维度值组合，基于所计算出的异变度，判断是否需要进行深层归因；异常原因生成单元，针对各个第一当前维度值组合，在确定不需要进行深层归因时，根据所述第一当前维度值组合，生成业务系统异常原因；以及归因维度组合更新单元，针对各个第一当前维度值组合，在确定需要进行深层归因时，通过分别向所述第一当前维度值组合对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集，其中，所述维度值组合集确定单元、所述业务指标数值提取单元、所述计算单元、所述维度值组合获取单元、所述深层归因判断单元以及所述归因维度组合更新单元循环执行操作，直到不存在未处理的归因维度组合为止，其中，在确定需要进行深层归因时，所述更新后的归因维度组合集被作为下一循环过程中的当前归因维度组合集。

可选地，在上述方面的一个示例中，所述维度值组合集确定单元可以从所述第一业务指标数据和第二业务指标数据中提取出所增加归因维度的各个维度值，并将所提取的各个维度值分别增加到所述第一当前维度值组合中得到所述当前维度值组合集。

可选地，在上述方面的一个示例中，所述深层归因判断单元可以基于所计算出的异变度和业务归因深度要求，判断是否需要进行深层归因。

可选地，在上述方面的一个示例中，所述装置还可以包括：异常原因整合单元，对所生成的业务系统异常原因进行整合。

可选地，在上述方面的一个示例中，所述装置还可以包括输出单元，输出所生成的业务系统异常原因。

可选地，在上述方面的一个示例中，所述装置还可以包括：时序数据获取单元，获取所述业务系统的业务指标时序数据；以及异常检测单元，基于所述业务指标时序数据，检测目标系统运营时间点是否是系统异常时间点。

可选地，在上述方面的一个示例中，所述业务指标时序数据是规定时间段内的业务指标时序数据，以及所述装置还可以包括：参考时间点确定单元，将所具有的业务指标在系统正常时间点集合中呈现中位数的系统正常时间点确定为系统参考时间点。

可选地，在上述方面的一个示例中，所述装置还可以包括：异常程度确定单元，在所述目标系统运营时间点被确定为是系统异常时间点时，确定所述目标系统运营时间点的异常程度。

根据本说明书的实施例的另一方面，提供一种电子设备，包括：一个或多个处理器，以及与所述一个或多个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行如上所述的用于确定业务系统异常原因的方法。

根据本说明书的实施例的另一方面，提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的用于确定业务系统异常原因的方法。

附图说明

通过参照下面的附图，可以实现对于本说明书的实施例内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。

图1示出了根据本说明书的实施例的用于确定业务系统异常原因的系统架构图；

图2示出了根据本说明书的实施例的用于业务系统异常检测的方法；

图3示出了根据本说明书的实施例的业务指标数据的示例示意图；

图4示出了根据本说明书的实施例的用于确定业务系统异常原因的方法的流程图；

图5示出了根据本说明书的实施例的系统异常检测装置的方框图；

图6示出了根据本说明书的实施例的异常原因确定装置的方框图；

图7示出了根据本说明书的实施例的用于实现业务系统异常原因确定过程的电子设备的方框图。

具体实施方式

现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书的实施例内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

在传统的业务系统异常发现及归因方案中，对业务系统的关键指标进行阈值监控，如果超出正常阈值范围就告警。然后，通过人工排查方式来确定业务系统异常原因。在这种方案中，异常阈值的设置通常依赖于专家经验，在各种应用场景中普遍告警精度差，覆盖率和召回率低。此外，人工排查异常原因的工作量大。排查一个异常问题通常需要半天到几天不等。

在根据本说明书的实施例中，提供了一种业务系统异常原因确定方案。在该方案中，针对一种异常类型(异常风险)定义一种业务指标，从业务系统的业务运营数据中提取出对应的业务指标时序数据，并基于业务指标数值来进行业务系统异常检测。在检测到发生业务系统异常检测后，使用结合贡献度和异变度的启发式归因算法来进行多维度组合归因，由此确定业务系统异常原因。利用该方案，能够快速且准确地进行多维度组合归因。

在本说明书中，术语“业务系统”可以是任何与业务应用运营相关的系统。术语“业务指标”可以是针对特定业务异常类型定义的业务指标。术语“维度”可以是用于构建和定义业务指标的基础属性，例如，“城市”、“渠道”、“性别”等。术语“维度值”可以是维度的赋值，例如，针对维度“城市”，维度值可以为“杭州”、“上海”、“北京”等。业务指标具有业务指标数值，并且可以基于不同的维度值来进行统计得出。

下面将结合附图来描述根据本说明书的实施例的用于确定业务系统异常的方法及装置。

图1示出了根据本说明书的实施例的用于确定业务系统异常的系统(下文中也称为业务异常确定系统)1的架构示意图。

如图1所示，业务异常确定系统1包括服务端和多个终端设备，比如台式机(或服务器)10，笔记本电脑20和移动终端30。终端设备上可以安装有业务应用来进行业务运营。终端设备与服务端之间可以是通过网络40进行通信互联。网络40可以是任何类型的无线网络或者有线网络，比如lan网络、wan网络、wlan网络、wifi网络等。

在本说明书的实施例中，服务端可以是异常确定设备50。异常确定设备50可以包括系统异常检测装置510和异常原因确定装置530。在工作时，服务端可以从各个终端设备获得业务指标数据，并通过系统异常检测装置510来基于所获得的业务指标数据检测系统异常，并且在检测到系统异常时，通过异常原因确定装置530来确定系统异常原因。

图2示出了根据本说明书的实施例的用于业务系统异常检测的方法200的流程图。

如图2所示，在块210，获取业务应用的业务指标时序数据。例如，可以通过网络40来从各个业务系统运营设备(例如，图1中的各个正在进行业务应用运营的终端设备)获取业务运营数据，或者可以通过网络40来从业务运营数据库中获取业务运营数据。然后，从业务运营数据中提取出业务指标时序数据。这里，业务指标时序数据可以是按照时序排列的业务指标数据。例如，假设以天为单位进行业务运营监控，则业务指标时序数据是每天的业务指标数据按照时间顺序组成的时序数据。在本说明书中，业务指标时序数据的时间粒度可以是根据需要定义的，比如，“小时”，“天”，“月”等。在本说明书中，业务指标时序数据可以是规定时间段内的业务指标时序数据。所述规定时间段可以是自目标系统时间点起向前计算的规定时间段。例如，假设目标系统时间点为7月30日，规定时间段的时长是7天，则规定时间段是7月24日到7月30日。

在进行系统异常检测之前，需要预先定义好异常检测过程所使用的业务指标，该业务指标能够从指标数值上体现出异常状态和正常状态之间的差异。通常，每个业务指标对应一种业务异常类型。

业务指标是基于系统异常检测方案的应用场景定义的，并且需要符合一致性要求和有效性要求。一致性要求是指业务指标需要与所监控的异常紧密相关。对大多数应用场景来说，可以从需要关注的业务运营数据(业务结果)中直接提取出业务指标。但在一些特定应用场景下，需要结合其他条件来确定。比如针对双十一期间的囤积号异常，业务指标可以被定义为：在风险设备上所发生的风险交易量。

有效性要求可以是指异常发生时，业务指标的指标数值需要能够体现出异常。比如，在监控支付宝支付成功率的场景下，如果只检测每个国家的总支付成功率，则可能无法检测出异常。在这种情况下，需要针对业务指标进行细粒度拆分，比如，将业务指标拆分为不同城市，不同支付渠道，不同性别，不同发卡行、不同操作介质上的支付成功率。并且，通过分析过去异常历史数据，确定哪些细分粒度的业务指标能够体现异常波动，由此确定最终的业务指标的维度，例如，确定业务指标的维度为“城市”、“渠道”和“性别”。

在本说明书中，在一些示例中，业务指标可以由单个基础指标组成，例如，可以由基础指标“用户数”组成。在一些示例中，业务指标可以由多个基础指标组成，例如，业务指标“支付成功率”可以由基础指标“支付成功用户数”除以基础指标“支付总用户数”组成。

图3示出了根据本说明书的实施例的业务指标数据的示例示意图。

图3中示出的业务指标数据是针对支付成功率异常监控的业务指标数据。如图3所示，业务指标的维度可以包括“城市”、“渠道”和“性别”。每个维度具有多个维度值，例如，针对维度“城市”，具有三个维度值“杭州”、“上海”和“北京”。业务指标被定义为支付成功率m＝m1/m2，其中，m1表示支付成功用户数，以及m2表示总支付用户数。这里，m1和m2可以称为基础指标。针对支付成功率的业务指标m属于衍生指标，由多于一个基础指标组合形成。

从图3中可以看出，针对每个维度值，可以具有对应的业务指标数值，例如，针对维度值“杭州”，系统正常点时的业务指标数值可以为“(杭州正常支付成功率)95％”，以及系统异常点时的业务指标数值可以为“(杭州异常支付成功率)60％”。此外，针对该维度“城市”，需要统计所有维度值的业务指标数值，例如图3中的“总正常支付成功率90％”以及“总异常支付成功率50％”。

在获取业务指标时序数据后，基于业务指标时序数据，检测目标系统运营时间点是否是系统异常时间点。这里，目标系统运营时间点通常是完成业务运营的最近系统运营时间点，例如，昨天。

具体地，在获取到业务指标时序数据后，在块220，对业务指标时序数据进行时序分解，例如，使用stl(seasonal-trenddecompositionprocedurebasedonloess)时序分解算法来进行时序分解以得到业务指标分量数据，trend分量、seasonal分量和residual分量。然后，在块230，使用gesd算法来业务指标分量数据进行异常检测。在一些应用场景下，可以使用gesd算法来对trend分量和residual分量进行异常检测。在一些应用场景下，可以使用gesd算法来对residual分量进行异常检测。两者区别在于：前者倾向于持续性告警，后者倾向于更短暂的告警。

此外，在本说明书的实施例中，可以使用median(中位数)和mad(medianabsolutedeviation，绝对中位差)来替换原有gesd算法中的mean(均值)和std(标准差)。

此外，方法200还可以包括：在目标系统运营时间点被确定为是系统异常时间点时，在块240，确定目标系统运营时间点的异常程度。在本说明书中，异常程度可以使用异常分来表征。例如，异常分可以通过下述公式来确定出，abnorm_score＝(value-median)/mad，其中，value为系统异常时间点的业务指标数值，median为业务指标时序数据的中位数，mad为绝对中位差。在异常分输出为负分时，表示异常下跌，以及异常分输出为正分时，表示异常上升。异常分的绝对值越大，则说明异常下跌或异常上升越大。按照这种方式，在需要进行多种异常类型监测时，可以通过所确定出的异常程度来确定哪种异常类型的异常程度更高，更需要及时进行应对处理，由此可以基于异常程度来确定出异常处理优先级，并基于所确定出的异常处理优先级来进行后续异常原因确定和异常应对。

此外，可选地，在方法200中，在确定出异常程度后，还可以输出所确定的异常程度，例如，输出异常分。

图4示出了根据本说明书的实施例的用于确定业务系统异常原因的方法的流程图。

如图4所示，在目标系统运营时间点被确定为系统异常点后，在块410，确定系统参考时间点。在本说明书中，在规定时间段中可以包括多个系统运营时间点，所述系统运营时间点可以包括系统正常时间点和系统异常时间点。所述系统参考时间点是所述多个系统正常点中的一个，并且被使用来确定业务系统异常原因。例如，系统参考时间点可以是基于历史数据确定的，比如，可以将所具有的业务指标在系统正常时间点集合中呈现中位数的系统正常时间点确定为系统参考时间点。

具体地，可以通过从规定时间段的系统运营时间点集合中排除系统异常点来找出所有系统正常时间点，以得到系统正常时间点集合。然后，获取系统正常时间点集合中的业务指标数值为中位数的系统正常时间点作为系统参考点。

以某场景交易量日指标为例来说明系统参考时间点确定过程。例如，假设目标系统运营时间点为12月11日，其被确定是系统异常时间点，并且业务指标异常降到100次。在进行系统异常检测时所使用的规定时间段为10天，则系统运营时间点集合为{12月2日，12月3日，12月4日，12月5日，12月6日，12月7日，12月8日，12月9日，12月10日，12月11日}。在上述系统运营时间点集合中，12月2日，12月3日，12月8日，12月9日和12月11日为系统异常时间点，则所得到的系统正常时间点集合是{12月4日，12月5日，12月6日，12月7日，12月10日}，其中，12月4日的业务指标是1000次，12月5日的业务指标是980次，12月6日的业务指标是1010次，12月7日的业务指标是1011次，12月10日的业务指标是990次，则12月4日的业务指标处于中位数，从而将12月4日作为系统参考时间点。

此外，要说明的是，在本说明书的另一示例中，也可以不包括块410的操作。例如，系统参考时间点可以是预先指定的系统正常时间点。

在如上确定出系统参考时间点后，在块415，获取业务系统的第一业务指标数据和第二业务指标数据，这里，第一业务指标数据是在系统异常时间点(即，所检测出的系统异常时间点)发生的业务指标数据，以及第二业务指标数据是在系统参考时间点发生的业务指标数据。

接着，循环执行块420到块460的操作，直到不存在未处理的归因维度组合为止。

具体地，在块420，基于归因维度集中的剩余归因维度，确定当前归因维度组合集。这里，归因维度集可以是预先定义的或者经由用户输入的。例如，可以分别向上一循环过程中确定出需要进行深层归因的当前维度值组合(下文中称为第一当前维度值组合)对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集。在初次循环过程中，没有上一循环过程，即，上一循环过程中的归因维度组合为零，由此，当前归因维度组合集包括各个单独维度。例如，假设归因维度集为{城市，渠道，性别}，则当前归因维度组合集所包括的各个当前归因维度组合是{城市}，{渠道}和{性别}。如果上一归因维度组合为{城市}，则当前归因维度组合集所包括的各个当前归因维度组合是{城市，渠道}和{城市，性别}。这里，假设维度{城市}的维度值为“杭州”，“上海”和“北京”，维度{渠道}的维度值为“电信”，“移动”和联通，以及维度{性别}的维度值为“男”和“女”。

接着，在块425，根据第一业务指标数据和第二业务指标数据，确定当前归因维度组合集中的各个当前归因维度组合的当前维度值组合集。在一个示例中，可以从第一业务指标数据和第二业务指标数据中提取出所增加归因维度的各个维度值，并将所提取的各个维度值分别增加到第一当前维度值组合中得到当前维度值组合集。例如，假设第一当前维度值组合为{杭州}，则所得到的当前维度值组合集包括{杭州，电信}，{杭州，移动}，{杭州，联通}，{杭州，男}和{杭州，女}。

在块430，从第一业务指标数据和第二业务指标数据中分别提取出各个当前维度值组合所对应的业务指标数值。例如，从第一业务指标数据中提取出分别与维度值组合{杭州，电信}，{杭州，移动}，{杭州，联通}，{杭州，男}和{杭州，女}对应的业务指标数值(异常业务指标数值)，以及从第二业务指标数据中提取出分别与维度值组合{杭州，电信}，{杭州，移动}，{杭州，联通}，{杭州，男}和{杭州，女}对应的业务指标数值(正常数值)。

然后，在块435，基于所提取出的各个维度值组合的业务指标数值，分别计算出各个当前维度值组合的贡献度和异变度。这里，术语“贡献度”是指维度值组合cij的变化量对整体变化量的解释度，其满足

具体地，针对由单个基础指标构成的业务指标，可以采用下述公式(1)来计算贡献度：

cij＝(aij-nij)/(am-nm)(1)

其中，cij是维度值eij的贡献度，aij是与维度值eij对应的异常业务指标数值(对应于系统异常时间点)，nij是与当前维度值组合eij对应的正常业务指标数值(对应于系统参考时间点)，am是与当前维度对应的总异常业务指标数值(对应于系统异常时间点)，nm是与当前维度对应的总正常业务指标数值(对应于系统参考时间点)。例如，假设维度为性别，维度值为“男”和“女”，业务指标是“用户数”，则在计算维度值“男”的贡献度时，cij是维度值“男”的贡献度，aij是与维度值“男”对应的异常业务指标数值(男异常用户数，即，系统异常时间点的男用户数)，nij是与aij是与维度值“男”对应的正常业务指标数值(男正常用户数，即，系统参考时间点的男用户数)，am是与当前维度对应的总异常业务指标数值(总异常用户数，即，系统异常时间点的男用户数和女用户数之和，换言之，该维度下的所有维度值的业务指标数值之和)，nm是与当前维度对应的总正常业务指标数值(总正常用户数，即，系统参考时间点的男用户数和女用户数之和，换言之，该维度下的所有维度值的业务指标数值之和)。

针对由2个基础指标m1和m2构成的业务指标，例如，m＝m1/m2，可以采用下述公式(2)来计算贡献度：

其中，cij是维度值eij的贡献度，a(m1)是与维度值eij和基础指标m1对应的异常业务指标数值，n(m1)是与维度值eij和基础指标m1对应的正常业务指标数值，a(m2)是与维度值eij和基础指标m2对应的异常业务指标数值，n(m2)是与维度值eij和基础指标m2对应的正常业务指标数值。

例如，假设维度为“城市”，维度值为“杭州”，业务指标是“支付成功率”，其由基础指标m1“支付成功人数”除以基础指标m2“支付总人数”得到，则在计算维度值“杭州”的贡献度时，cij是维度值“杭州”的贡献度，a(m1)是与维度值“杭州”和基础指标m1“支付成功人数”对应的异常业务指标数值，n(m1)是与维度值“杭州”和基础指标m1“支付成功人数”对应的正常业务指标数值，a(m2)是与维度值“杭州”和基础指标m2“支付总人数”对应的异常业务指标数值，n(m2)是与维度值“杭州”和基础指标m2“支付总人数”对应的正常业务指标数值。

在业务指标由多于2个基础指标组成时，可以采用其它合适的公式来计算出各个维度值组合的贡献度。

针对由单个基础指标构成的业务指标，可以采用下述公式(3)-(5)来计算维度值eij的异变度：

sij＝plog(2p/(p+q))+qlog(2q/(p+q))(3)

p＝nij(m)/n(m)(4)

q＝aij(m)/a(m)(5)

其中，sij是维度值eij的异变度，aij是与维度值eij对应的异常业务指标数值，nij是与当前维度值组合eij对应的正常业务指标数值，am是与当前维度对应的总异常业务指标数值，以及nm是与当前维度对应的总正常业务指标数值。

针对由多个基础指标构成的业务指标，可以采用上述公式(3)-(5)计算出各个基础指标的异变度，然后将所计算出的异变度加和来得到业务指标的异变度。

在如上计算出贡献度后，在块440，从当前维度值组合集中获取至少一个第一当前维度值组合，所述第一当前维度值组合的贡献度大于第一预定阈值。即，从当前维度值组合集中选择出所有贡献度大于第一预定阈值的维度值组合，构成第一当前维度值组合集。

然后，在块445，针对各个第一当前维度值组合，基于所计算出的异变度，判断是否需要进行深层归因。例如，可以将所计算出的异变度与第二预定阈值进行比较。在所计算出的异变度大于第二预定阈值时，则认为需要进行深层归因。在所计算出的异变度不大于第二预定阈值时，则认为不需要进行深层归因。

在另一示例中，还可以基于所计算出的异变度和业务归因深度要求，判断是否需要深层归因。这里，业务归因深度要求可以包括递进层数。在这种情况下，只要递进层数达到预定层数，就可以判断为不需要进行深层归因。此外，只有在所计算出的异变度大于预定阈值且递进层数未达到预定层数，才判断为需要进行深层归因。在本说明书中，递进层数是指从首次拆分后进行的递进拆分的次数。例如，针对归因维度集{d1，d2，d3，d4}，则首次拆分后的归因维度组合为d1，d2，d3，d4。如果针对d1的维度值e11，所计算出的贡献度大于第一预定阈值且异变度大于第二预定阈值，则认为需要深层归因，由此需要进行维度递进拆分，进行维度拆分后的新归因维度组合是{d1，d2}，{d1，d3}，{d1，d4}，对应的递进层数为1。换言之，每进行一次维度拆分，递进层数就加1。

如果判断为不需要进行深层归因，则在块450，针对被确定不需要进行深层归因的各个第一当前维度值组合，根据第一当前维度值组合，生成业务系统异常原因。例如，可以将该维度值组合中包含的维度值组合在一起生成业务系统异常原因。比如，假设维度值组合为{杭州，电信}，则所生成的业务系统异常原因是“杭州的电信出现问题”。

在生成业务系统异常原因后，在块455，判断是否存在未处理的维度组合。如果存在，则返回块425，再次执行循环过程。如果不存在，则在块460，输出所生成的业务系统异常原因。

如果判断为确定需要进行深层归因，则返回到块420，重新进行维度拆分。即，通过分别向第一当前维度值组合对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集。然后，再次执行循环过程。

此外，可选地，在输出所生成的业务系统异常原因之前，方法400还可以包括：对所生成的业务系统异常原因进行整合。可选地，所述整合可以包括合并、去重和/或基于异变度的排序。相应地，输出经过整合处理后的业务系统异常原因。在所述整合包括基于异变度的排序的情况下，可以输出topn个业务系统异常原因。n通常设置为3或5，也可以设置为其它合适的数值。

在根据本说明书的实施例的用于确定业务系统异常原因的方法中，计算维度值组合的贡献度和异变度并基于所计算出的异变度来进行维度递进拆分决策，并且输出各个不需要维度递进拆分的维度值组合所对应的系统异常原因，由此可以提高系统异常原因确定过程的准确率。此外，上述过程可以由系统自动执行，从而极大地缩短了异常原因确定过程所需的时间。

图5示出了根据本说明书的实施例的系统异常检测装置510的方框图。如图5所示，系统异常检测装置510包括时序数据获取单元511、异常检测装置513和异常程度确定单元515。

时序数据获取单元511被配置为获取业务系统的业务指标时序数据。时序数据获取单元511的操作可以参考上面参照图2和图3描述的块210的操作。

异常检测单元513被配置为基于业务指标时序数据，检测目标系统运营时间点是否是系统异常时间点。异常检测单元513的操作可以参考上面参照图2描述的块220和230的操作。

异常程度确定单元515被配置为在目标系统运营时间点被确定为是系统异常时间点时，确定目标系统运营时间点的异常程度。异常程度确定单元515的操作可以参考上面参照图2描述的块240的操作。

图6示出了根据本说明书的实施例的异常原因确定装置530的方框图。如图5所示，异常原因确定装置530包括维度值组合集确定单元531、业务指标数值提取单元532、计算单元533、维度值组合获取单元534、深层归因判断单元535、异常原因生成单元536和归因维度组合更新单元537。

维度值组合集确定单元531被配置为根据业务系统的第一业务指标数据和第二业务指标数据，确定当前归因维度组合集中的各个当前归因维度组合的当前维度值组合集。这里，第一业务指标数据是在系统异常时间点发生的业务指标数据，以及第二业务指标数据是在系统参考时间点发生的业务指标数据。此外，针对下一循环过程中的当前维度值组合集，维度值组合集确定单元531可以是从第一业务指标数据和第二业务指标数据中提取出所增加归因维度的各个维度值，并将所提取的各个维度值分别增加到第一当前维度值组合中得到。维度值组合集确定单元531的操作可以参考上面参照图4描述的块425的操作。

在一个示例中，系统参考时间点可以是预先指定的系统正常时间点。在另一示例中，系统参考时间点也可以是基于历史数据确定的。相应地，异常原因确定装置530还可以包括参考时间点确定单元538。参考时间点确定单元538将所具有的业务指标在系统正常时间点集合中呈现中位数的系统正常时间点确定为系统参考时间点。参考时间点确定单元538的操作可以参考上面参照图4描述的块410的操作。

业务指标数值提取单元532被配置为从第一业务指标数据和第二业务指标数据中提取出各个当前维度值组合所对应的业务指标数值。业务指标数值提取单元532的操作可以参考上面参照图4描述的块430的操作。

计算单元533被配置为基于所提取出的业务指标数值，计算各个当前维度值组合的贡献度和异变度。计算单元533的操作可以参考上面参照图4描述的块435的操作。

维度值组合获取单元534被配置为从当前维度值组合集中获取至少一个第一当前维度值组合，所述第一当前维度值组合的贡献度大于预定阈值。维度值组合获取单元534的操作可以参考上面参照图4描述的块440的操作。

深层归因判断单元535被配置为针对各个第一当前维度值组合，基于所计算出的异变度，判断是否需要进行深层归因。在另一示例中，深层归因判断单元535可以基于所计算出的异变度和业务归因深度要求，判断是否需要进行深层归因。深层归因判断单元535的操作可以参考上面参照图4描述的块445的操作。

异常原因生成单元536被配置为针对各个第一当前维度值组合，在确定不需要进行深层归因时，根据第一当前维度值组合，生成业务系统异常原因。异常原因生成单元536的操作可以参考上面参照图4描述的块450的操作。

归因维度组合更新单元537被配置为针对各个第一当前维度值组合，在确定需要进行深层归因时，通过分别向所述第一当前维度值组合对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集。归因维度组合更新单元537的操作可以参考上面参照图4描述的块420的操作。

在本说明书中，维度值组合集确定单元531、业务指标数值提取单元532、计算单元533、维度值组合获取单元534、深层归因判断单元535以及归因维度组合更新单元536循环执行操作，并且在确定需要进行深层归因时，所述更新后的归因维度组合集被作为下一循环过程中的当前归因维度组合集。

此外，异常原因确定装置530还可以包括输出单元(未示出)。输出单元被配置为输出所生成的业务系统异常原因。

此外，异常原因确定装置530还可以包括异常原因整合单元(未示出)。异常原因整合单元被配置为对所生成的业务系统异常原因进行整合。所述整合例如可以包括合并，去重和/或基于异变度进行排序等。在存在异常原因整合单元的情况下，输出单元被配置为输出经过整合后的业务系统异常原因。此外，可选地，输出单元还可以输出异常得分。

这里要说明的是，在图1中示出的实施例中，系统异常检测装置510和异常原因确定装置530被示出为两个独立的装置。在本说明书的其它实施例中，系统异常检测装置510也可以作为组件包括在异常原因确定装置530中。

如上参照图1到图6，对根据本说明书的实施例的用于确定业务系统异常原因的方法及异常原因确定装置的实施例进行了描述。上面的异常原因确定装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图7示出了根据本说明书的实施例的用于确定业务系统异常原因的电子设备700的结构框图。

如图7所示，电子设备700可以包括至少一个处理器710、存储器(例如，非易失性存储器)720、内存730、通信接口740以及内部总线760，并且至少一个处理器710、存储器720、内存730和通信接口740经由总线760连接在一起。该至少一个处理器710执行在计算机可读存储介质中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在本说明书的实施例中，电子设备700可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(pda)、手持装置、可佩戴计算设备、消费电子设备等等。

在一个实施例中，在存储器中存储有计算机可执行指令，其当执行时使得至少一个处理器710：执行下述循环过程来确定业务系统异常原因：根据业务系统的第一业务指标数据和第二业务指标数据，确定当前归因维度组合集中的各个当前归因维度组合的当前维度值组合集，第一业务指标数据是在系统异常时间点发生的业务指标数据，第二业务指标数据是在系统参考时间点发生的业务指标数据；从第一和第二业务指标数据中提取出各个当前维度值组合所对应的业务指标数值；基于所提取出的业务指标数值，计算各个当前维度值组合的贡献度和异变度；从当前维度值组合集中获取至少一个第一当前维度值组合，第一当前维度值组合的贡献度大于预定阈值；针对各个第一当前维度值组合，基于所计算出的异变度，判断是否需要进行深层归因；在判断不需要进行深层归因时，根据第一当前维度值组合，生成业务系统异常原因，以及在判断需要进行深层归因时，通过分别向第一当前维度值组合对应的归因维度组合中增加剩余归因维度中的一个归因维度来生成更新后的归因维度组合集，以作为下一循环过程中的当前归因维度组合集。

应该理解的是，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器710执行在本说明书的各个实施例中如上结合图1-6描述的各种操作和功能。

根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中如上结合图1-6描述的各种操作和功能。

具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如cd-rom、cd-r、cd-rw、dvd-rom、dvd-ram、dvd-rw、dvd-rw)、磁带、非易失性存储卡和rom。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，fpga或asic)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。