一种业务异常监测方法、装置、设备及存储介质

技术领域

本申请涉及通信技术领域，具体而言，涉及一种业务异常监测方法、装置、设备及存储介质。

背景技术

目前，现有的业务异常监测方法主要应用于单一的应用系统节点中，并且采用的具体监测方式也主要是对于已有业务数据进行事后排查，例如，以银行系统为例，一般是以季度为周期，根据银行系统内上一个季度的已有业务数据，从中识别检测出业务处理存在异常的风险类事件，从而实现对于银行系统的风险排查功能。

但是，在一些业务处理流程中，往往会涉及多个不同的应用系统节点(如，汇款转账类业务的处理过程中至少会涉及汇款发起节点、收款方节点以及用于记账的银行核心系统等多个不同的应用系统节点)，因此，上述现有的业务异常监测方法并不适用于跨应用系统的业务处理流程，从而无法有效的对跨应用系统的业务处理流程中实时可能出现的业务异常进行监测。

发明内容

有鉴于此，本申请的目的在于提供一种业务异常监测方法、装置、设备及存储介质，能够有效的对跨应用系统的业务处理流程中可能出现的业务异常进行实时监测，有利于提高对于业务处理流程中出现的业务异常的监测效率。

第一方面，本申请实施例提供了一种业务异常监测方法，所述业务异常监测方法包括：

响应针对目标业务链路的异常监测，采集所述目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据；

针对每一所述业务处理节点，根据该业务处理节点在所述目标业务中对应处理的目标子业务，从该业务处理节点对应的所述业务处理数据中，提取与所述目标子业务匹配的关键业务要素，并将提取的所述关键业务要素与该业务处理节点进行关联；

响应于监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息；其中，所述异常提示信息用于提示该业务处理节点在处理所述目标子业务的过程中出现异常。

第二方面，本申请实施例提供了一种业务异常监测装置，所述业务异常监测装置包括：

采集模块，用于响应针对目标业务链路的异常监测，采集所述目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据；

关联匹配模块，用于针对每一所述业务处理节点，根据该业务处理节点在所述目标业务中对应处理的目标子业务，从该业务处理节点对应的所述业务处理数据中，提取与所述目标子业务匹配的关键业务要素，并将提取的所述关键业务要素与该业务处理节点进行关联；

响应模块，用于响应于监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息；其中，所述异常提示信息用于提示该业务处理节点在处理所述目标子业务的过程中出现异常。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述业务异常监测方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述业务异常监测方法的步骤。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请实施例提供了一种业务异常监测方法、装置、设备及存储介质，响应针对目标业务链路的异常监测，采集目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据；针对每一业务处理节点，根据该业务处理节点在目标业务中对应处理的目标子业务，从该业务处理节点对应的业务处理数据中，提取与目标子业务匹配的关键业务要素，并将提取的关键业务要素与该业务处理节点进行关联；响应于监测到任一个业务处理节点关联的关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息。这样，本申请能够有效的对跨应用系统的业务处理流程中可能出现的业务异常进行实时监测，有利于提高对于业务处理流程中出现的业务异常的监测效率。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的一种业务异常监测方法的流程示意图；

图2a示出了本申请实施例所提供的第一种目标业务链路的结构示意图；

图2b示出了本申请实施例所提供的第二种目标业务链路的结构示意图；

图3示出了本申请实施例所提供的第一种监测业务处理节点是否出现业务异常的方法的流程示意图；

图4示出了本申请实施例所提供的第二种监测业务处理节点是否出现业务异常的方法的流程示意图；

图5示出了本申请实施例所提供的一种业务异常监测装置的结构示意图；

图6为本申请实施例提供的一种计算机设备600的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

目前，现有的业务异常监测方法主要应用于单一的应用系统节点中，但是，在一些业务处理流程中，往往会涉及多个不同的应用系统节点(如，汇款转账类业务的处理过程中至少会涉及汇款发起节点、收款方节点以及用于记账的银行核心系统等多个不同的应用系统节点)，因此，现有的业务异常监测方法并不适用于跨应用系统的业务处理流程，从而无法有效的对跨应用系统的业务处理流程中实时可能出现的业务异常进行监测。

基于此，本申请实施例提供了一种业务异常监测方法、装置、电子设备及存储介质，能够有效的对跨应用系统的业务处理流程中实时可能出现的业务异常进行监测，有利于提高对于业务处理流程中出现的业务异常的监测效率。

为便于对本实施例进行理解，下面对本申请实施例提供的一种业务异常监测方法进行详细介绍。

参照图1所示，图1示出了本申请实施例所提供的一种业务异常监测方法的流程示意图，所述业务异常监测方法包括步骤S101-S103；具体的：

S101，响应针对目标业务链路的异常监测，采集所述目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据。

这里，目标业务链路表征目标业务对应的处理链路，也即，目标业务链路中包括用于处理目标业务的多个业务处理节点，每一业务处理节点用于处理目标业务中的一个目标子业务。

需要说明的是，目标业务链路中包括的业务处理节点的具体节点数量可以根据目标业务的实际业务流程确定，并且不同的业务处理节点可以分布于不同的应用系统中，对于上述目标业务的具体业务处理流程、上述业务处理节点的具体节点数量以及上述不同的业务处理节点是否分布于不同的应用系统中，本申请实施例不作任何限定。

具体的，考虑到本申请主要用于对跨应用系统的业务处理流程中实时可能出现的业务异常进行监测，因此，在一种优选的实施方式中，上述目标业务链路中可以包括多个分布于不同应用系统的业务处理节点。

示例性的说明，以目标业务是用户通过手机银行APP(Application，应用程序)发起的理财产品申购业务为例，图2a示出了本申请实施例所提供的第一种目标业务链路的结构示意图，此时，根据上述目标业务(即用户通过手机银行APP发起的理财产品申购业务)的实际业务处理流程，可以确定该目标业务对应的目标业务链路如图2a所示，在该目标业务链路中共包括A-F这6个业务处理节点；其中，A业务处理节点表示用户的手机银行APP，B业务处理节点表示银行的对私BP(Basis Point，基点)，C业务处理节点与E业务处理节点均用于表示交换平台，D业务处理节点表示理财平台，F业务处理节点表示银行的核心系统，A-F这6个业务处理节点分别用于处理目标业务中涉及的多个不同目标子业务，图2a中箭头的指向则用于表示不同业务处理节点在处理目标业务过程中的先后顺序，也即，在目标业务链路中，箭头用于指向目标业务处理过程中的下一业务处理节点。

示例性的说明，以目标业务是二代支付转账业务为例，图2b示出了本申请实施例所提供的第二种目标业务链路的结构示意图，此时，根据上述目标业务(即二代支付转账业务)的实际业务处理流程，可以确定该目标业务对应的目标业务链路如图2b所示，在该目标业务链路中共包括a-d这4个业务处理节点；其中，a业务处理节点表示银行的前置系统，b业务处理节点表示二代支付系统，c业务处理节点表示交换平台，d业务处理节点表示银行的核心系统，图2b中箭头的指向仍然用于表示不同业务处理节点在处理目标业务过程中的先后顺序。

具体的，基于目标业务的实际业务处理流程是较为短暂的(不考虑网络拥挤等特定外界因素的影响)，因此，在执行步骤S101的过程中，针对目标业务链路上包括的每一个业务处理节点，可以同时采集每一个业务处理节点在处理目标业务过程中的业务处理数据，其中，不同业务处理节点可以使用相同的数据采集方式(如，都通过网络流量旁路采集的方式进行采集，或是都通过应用系统日志数据采集的方式进行采集，其中，应用系统日志数据表示不同业务处理节点处的日志数据)进行业务处理数据的采集，也可以使用不同的数据采集方式(如，一个业务处理节点通过网络流量旁路采集的方式进行采集，另一个业务处理节点通过应用系统日志数据采集的方式进行采集)进行业务处理数据的采集；对于不同业务处理节点对应的数据采集方式是否相同，以及每一个业务处理节点对应的具体数据采集方式，本申请实施例都不进行任何限定。

S102，针对每一所述业务处理节点，根据该业务处理节点在所述目标业务中对应处理的目标子业务，从该业务处理节点对应的所述业务处理数据中，提取与所述目标子业务匹配的关键业务要素，并将提取的所述关键业务要素与该业务处理节点进行关联。

这里，结合上述步骤S101的分析内容可知，在目标业务链路上，每一个业务处理节点用于处理目标业务中的一个目标子业务，基于此，在本申请实施例中，每一个业务处理节点对应的业务处理数据的具体数据内容可以根据每一个业务处理节点对应处理的具体目标子业务确定；也即，每个业务处理节点对应的业务处理数据能够包含该业务处理节点在处理目标子业务时涉及的上述关键业务要素即可，对于每一个业务处理节点对应的业务处理数据的具体数据内容，本申请实施例不作任何限定。

具体的，对于目标业务链路上的每一个业务处理节点，该业务处理节点处需要关联的关键业务要素取决于该业务处理节点对应处理的具体目标子业务；对于上述关键业务要素的具体要素类型，本申请实施例同样不作任何限定。

示例性的说明，以业务处理节点x1对应处理的目标子业务是交易业务(包括转账业务、提现业务等)为例，则与交易业务匹配的关键业务要素可以包括以下至少之一：目标子业务所属的业务类型、交易发起方的用户身份信息、交易的流水号、具体交易金额、下一业务处理节点针对本次发送的业务处理数据所反馈的返回码以及该返回码所属的返回码类型等；

需要说明的是，由于在执行步骤S101的过程中，针对目标业务链路上包括的每一个业务处理节点，可以同时采集每一个业务处理节点在处理目标业务过程中的业务处理数据，因此，在上述步骤S101中相当于是针对目标业务链路上包括的不同业务处理节点进行无序式的数据采集，从而，在执行步骤S102的过程中，需要根据每一个目标子业务提取出与之匹配的关键业务要素之后，将提取出的关键业务要素与用于处理该目标子业务的业务处理节点进行关联，以便在监测出异常(即业务处理逻辑与关键业务要素不匹配)的关键业务要素之后，能够及时锁定出现异常的具体业务处理节点，有利于提高对于业务处理流程中出现的业务异常的监测效率。

S103，响应于监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息。

这里，上述异常提示信息用于提示该业务处理节点在处理目标子业务的过程中出现异常，其中，对于异常提示信息的具体信息内容以及具体信息格式，本申请实施例不作任何限定。

具体的，以目标业务是汇款转账业务为例，在处理目标业务的目标业务链路中至少包括：x1业务处理节点(手机银行APP)和x2业务处理节点(银行核心系统)；基于x1业务处理节点用于处理的目标子业务是“发起汇款转账”，x2业务处理节点用于处理的目标子业务是“对汇款转账业务进行最终记账”，可以确定x1业务处理节点与x2业务处理节点关联的关键业务要素都包括收款人身份信息，此时由于两个目标子业务的业务处理逻辑都要求收款人身份信息在目标业务处理过程中全程保持一致，因此，当x1业务处理节点与x2业务处理节点出现收款人身份信息不一致的问题时，可以输出针对x1业务处理节点与x2业务处理节点的异常提示信息(如，x1业务处理节点与x2业务处理节点的收款人身份信息不一致)，以提示业务运维人员及时锁定业务异常在目标业务链路上出现的具体位置是x1业务处理节点与x2业务处理节点，从而有效的提高了对于业务处理流程中出现的业务异常的监测效率。

需要说明的是，考虑到在实际应用场景中可能需要同时对多个不同的目标业务进行业务异常监测，因此，在本申请实施例中，当同时对多个不同的目标业务进行业务异常监测时，还可以将上述步骤S103的具体执行方式适应性地调整为如下步骤a1的方式，具体的：

步骤a1、响应于监测到多个目标业务中出现业务异常的业务数量大于或者等于预设数量阈值，则输出针对每一出现业务异常的目标业务的异常提示信息。

具体的，在上述步骤a1中，可以按照上述步骤S101-S103所述的方法来监测每一个目标业务是否出现业务异常，重复之处在此不再赘述。

下面针对上述步骤S101-S103中，如何确定是否监测到任意一个业务处理节点出现业务异常(即监测到任一个业务处理节点关联的关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配)，分别进行详细说明如下：

在本申请实施例中，针对目标业务链路上的每一个业务处理节点，在判断该业务处理节点关联的关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑是否匹配时，可以拆分为以下两种不同情况：

情况1、将该业务处理节点关联的关键业务要素与一个预先设置的标准值/标准范围(具体取值由该业务处理节点对应的目标子业务的业务处理逻辑确定)进行比较，当监测到上述关键业务要素与上述标准值/标准范围之间的数值关系不符合该业务处理节点对应的目标子业务的业务处理逻辑时，则确定该业务处理节点出现业务异常，需要输出针对该业务处理节点的异常提示信息。

这里，在上述情况1下，在一种可选的实施方案中，如图3所示，图3示出了本申请实施例所提供的第一种监测业务处理节点是否出现业务异常的方法的流程示意图，该方法包括步骤S301-S302；具体的：

S301，获取所述目标业务链路上的每一所述业务处理节点关联的所述关键业务要素。

这里，在执行步骤S301的过程中，可以按照如上步骤S101所述的方式，先通过无序采集的方式，同时采集目标业务链路上每一个业务处理节点在处理各自对应的目标子业务时产生的业务处理数据；再按照如上步骤S102所述的方式，根据每一个业务处理节点对应处理的具体目标子任务，提取出每一个业务处理节点关联的关键业务要素。

具体的，以目标业务是银行业务场景中常出现的交易业务(包括任何类型的转账业务、提现业务等)为例，可以获取到每一个业务处理节点关联的关键业务要素可以包括以下至少之一：目标子业务所属的业务类型、交易发起方的用户身份信息、交易的流水号、具体交易金额、下一业务处理节点针对本次发送的业务处理数据所反馈的返回码以及该返回码所属的返回码类型等。

S302，当监测到所述目标业务链路上的第一业务处理节点关联的第一关键业务要素与所述第一业务处理节点对应的第一预设范围不匹配时，确定所述第一关键业务要素与所述第一业务处理节点对应的目标子业务的业务处理逻辑不匹配。

这里，仍以目标业务是银行业务场景中常出现的交易业务为例，在处理交易业务的过程中，目标业务链路上的每一个业务处理节点在处理完各自对应的目标子业务之后，需要进入下一业务处理节点(执行顺序如图2b所示的箭头指向)，此时，下一业务处理节点需要向上一业务处理节点返回一个返回码，以便根据返回码所属的返回码类型(如，成功还是失败)来确定每一个业务处理节点的节点状态。

具体的，当上述第一业务处理节点关联的第一关键业务要素包含上述返回码时，上述第一预设范围可以是包括多个成功类型的返回码组成的数组为例，此时，可以按照如下步骤b1所示的方式执行上述步骤S302：

步骤b1、响应于监测到任一个所述业务处理节点关联的返回码位于目标数组之外，输出针对该业务处理节点的异常提示信息。

这里，上述步骤b1中的目标数组中包括多个用于标识目标业务处理过程中属于正常情况的成功返回码，也即，上述步骤b1中的目标数组此时相当于上述步骤S302中的第一预设范围(第一预设范围中包括多个成功类型的返回码组成的数组)。

具体的，对于目标业务链路上的每一个业务处理节点来说，该业务处理节点关联的返回码也相当于该业务处理节点向上一业务处理节点(以图2b所示的目标业务链路为例，则返回码的反馈方向与箭头指向相反)反馈的返回码。

示例性的说明，以目标数组中包括的成功返回码为：AAAA、TTTT、KKKK、NNNN为例，当监测到目标业务链路中的任意一个业务处理节点x2向上一业务处理节点x1反馈的返回码(即业务处理节点x2关联的返回码)为CCCC(即位于上述示例的目标数组之外)时，则输出针对业务处理节点x2的异常提示信息，确定业务处理节点x2在目标业务处理过程中出现业务异常；当监测到业务处理节点x2向上一业务处理节点x1反馈的返回码是AAAA(即位于上述示例的目标数组之内)时，确定业务处理节点x2没有出现业务异常，可以继续判断目标业务链路上的下一业务处理节点x3的返回码是否出现异常(即是否位于上述示例中的目标数组之外)。

需要说明的是，除上述返回码之外，上述步骤S301-S302所述的监测方式，还可以用于监测不同业务处理节点(即上述第一业务处理节点可以表征目标业务链路上的任意一个业务处理节点)中关联的其他类型的关键业务要素(即上述第一关键业务要素也可以是除返回码之外的其他类型的关键业务要素，如，交易发起方的用户身份信息、交易的流水号)是否出现异常，此时，以监测“交易发起方的用户身份信息”为例，则上述步骤S302中的“第一预设范围”即为交易发起方的真实用户信息；基于此，对于上述步骤S302中第一业务处理节点表征的具体业务处理节点、第一关键业务要素包括的具体要素内容以及“第一预设范围”表征的具体含义以及具体取值信息，本申请实施例不作任何限定。

情况2、将该业务处理节点关联的关键业务要素与其他业务处理节点(位于同一目标业务链路上)关联的同类型的关键业务要素进行比较，当该业务处理节点与其他业务处理节点关联的同类型关键业务要素之间的关系不符合各自对应的目标子业务的业务处理逻辑时，则确定该业务处理节点与上述其他业务处理节点都出现业务异常，需要输出针对该业务处理节点与上述其他业务处理节点的异常提示信息。

这里，在上述情况2下，在一种可选的实施方案中，如图4所示，图4示出了本申请实施例所提供的第二种监测业务处理节点是否出现业务异常的方法的流程示意图，该方法包括步骤S401-S402；具体的：

S401，获取所述目标业务链路上的每一所述业务处理节点关联的所述关键业务要素。

这里，上述步骤S401的具体实施方式与上述步骤S301的具体实施方式相同，重复之处在此不再赘述。

S402，当监测到所述目标业务链路上不同业务处理节点关联的同一类型的所述关键业务要素出现不匹配的情况时，确定监测到所述不同业务处理节点关联的同一类型的所述关键业务要素与所述不同业务处理节点各自对应的目标子业务的业务处理逻辑不匹配。

这里，仍以目标业务是银行业务场景中常出现的交易业务为例，当上述步骤S402中所述的同一类型的关键业务要素出现不匹配是指：不同业务处理节点关联的同种关键业务要素不一致时，可以按照如下步骤c1所示的方式执行上述步骤S402，具体的：

步骤c1、响应于监测到第二业务处理节点关联的第二关键业务要素与第三业务处理节点关联的第三关键业务要素不一致，输出针对所述第二业务处理节点和所述第三业务处理节点的异常提示信息。

需要说明的是，结合上述步骤S402的内容可知，上述第二业务处理节点与上述第三业务处理节点属于目标业务链路上不同的两个业务处理节点；在目标业务链路上，第二业务处理节点可以是与第三业务处理节点相邻的业务处理节点，也可以是与第三业务处理节点不相邻的业务处理节点；基于此，对于上述第二业务处理节点与上述第三业务处理节点在目标业务链路上的节点位置关系以及上述第二业务处理节点与上述第三业务处理节点各自表征的具体业务处理节点，本申请实施例不作任何限定。

具体的，在上述步骤c1中，第二关键业务要素与第三关键业务要素属于同一类型的关键业务要素，该类型的关键业务要素包括以下至少之一：流水号、交易金额以及所述交易业务的收款方信息；对于上述步骤c1中同一类型的关键业务要素包括的具体要素类型(也即上述步骤c1中第二业务要素与第三业务要素各自对应的具体要素内容)，本申请实施例不作任何限定。

示例性的说明，以上述步骤c1中的第二关键业务要素与第三关键业务要素都属于上述流水号为例，当监测到第二业务处理节点关联的流水号与第三业务处理节点关联的流水号不一致时，可以确定第二业务处理节点关联的流水号与第三业务处理节点关联的流水号都出现了业务异常，此时可以输出针对第二业务处理节点和第三业务处理节点的异常提示信息，以提示业务运维人员及时对第二业务处理节点关联的流水号与第三业务处理节点关联的流水号进行纠错与检验。

这里，仍以目标业务是银行业务场景中常出现的交易业务为例，当上述步骤S402中所述的同一类型的关键业务要素出现不匹配是指：目标业务链路中上一业务处理节点关联的交易类型与下一业务处理节点关联的返回码类型不匹配时，可以按照如下步骤d1所示的方式执行上述步骤S402，具体的：

步骤d1、响应于监测到所述目标业务链路中上一业务处理节点关联的交易类型与下一业务处理节点关联的返回码类型不匹配时，输出针对所述目标业务链路的异常提示信息。

具体的，在交易业务(即目标业务)的处理过程中，下一业务处理节点反馈的返回码类型需要与上一业务处理节点处的交易类型相匹配，因此，当监测到上一业务处理节点关联的交易类型与下一业务处理节点关联的返回码类型不匹配时，则可以确定目标业务链路此时存在业务异常，需要输出针对本次业务异常的异常提示信息。

示例性的说明，以图2b所示的目标业务链路为例，当银行前置系统(即业务处理节点a)向二代支付系统(即业务处理节点b)发送交易类型为aaa的交易请求时，此时根据二代支付系统接收到的交易请求数据，可以提取出二代支付系统关联的交易类型为aaa，当监测到二代支付系统的下一业务处理节点c(即交换平台)发送的返回码是BBBB时，由于交易类型aaa匹配的返回码是AAAA，而不是BBBB，因此，可以确定监测到二代支付系统关联的交易类型与交换平台关联的返回码类型不匹配，从而输出针对目标业务链路的异常提示信息。

这里，仍以目标业务是银行业务场景中常出现的交易业务为例，当上述步骤S402中所述的同一类型的关键业务要素出现不匹配是指：目标业务链路中上一业务处理节点关联的返回码类型与下一业务处理节点关联的返回码类型不一致时，可以按照如下步骤e1所示的方式执行上述步骤S402，具体的：

步骤e1、响应于监测到所述目标业务链路中上一业务处理节点关联的返回码类型与下一业务处理节点关联的返回码类型不一致时，输出针对所述目标业务链路的异常提示信息。

示例性的说明，以图2a所示的目标业务链路为例，其中，返回码的反馈方向与图2a中箭头的指向是相反的，当业务处理节点F(即银行核心系统)向业务处理节点E(即交换平台)反馈的返回码(即业务处理节点F关联的返回码)属于成功返回码，业务处理节点E(即交换平台)向业务处理节点D(即理财平台)反馈的返回码(即业务处理节点E关联的返回码)属于成功返回码，业务处理节点D(即理财平台)向业务处理节点C(即交换平台)反馈的返回码(即业务处理节点D关联的返回码)属于失败返回码时，则确定监测到业务处理节点D关联的返回码与上一业务处理节点E关联的返回码类型不一致，输出针对目标业务链路的异常提示信息。

本申请实施例提供的上述业务异常监测方法，响应针对目标业务链路的异常监测，采集目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据；针对每一业务处理节点，根据该业务处理节点在目标业务中对应处理的目标子业务，从该业务处理节点对应的业务处理数据中，提取与目标子业务匹配的关键业务要素，并将提取的关键业务要素与该业务处理节点进行关联；响应于监测到任一个业务处理节点关联的关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息。这样，本申请能够有效的对跨应用系统的业务处理流程中可能出现的业务异常进行实时监测，有利于提高对于业务处理流程中出现的业务异常的监测效率

基于同一发明构思，本申请还提供了与上述业务异常监测方法对应的业务异常监测装置，由于本申请实施例中的业务异常监测装置解决问题的原理与本申请实施例中上述业务异常监测方法相似，因此，业务异常监测装置的实施可以参见前述业务异常监测方法的实施，重复之处不再赘述。

参照图5所示，图5示出了本申请实施例所提供的一种业务异常监测装置的结构示意图，所述业务异常监测装置包括：

采集模块501，用于响应针对目标业务链路的异常监测，采集所述目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据。

关联匹配模块502，用于针对每一所述业务处理节点，根据该业务处理节点在所述目标业务中对应处理的目标子业务，从该业务处理节点对应的所述业务处理数据中，提取与所述目标子业务匹配的关键业务要素，并将提取的所述关键业务要素与该业务处理节点进行关联。

响应模块503，用于响应于监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息；其中，所述异常提示信息用于提示该业务处理节点在处理所述目标子业务的过程中出现异常。

在一种可选的实施方式中，响应模块503，用于通过以下方法确定监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配：

获取所述目标业务链路上的每一所述业务处理节点关联的所述关键业务要素；

当监测到所述目标业务链路上的第一业务处理节点关联的第一关键业务要素与所述第一业务处理节点对应的第一预设范围不匹配时，确定所述第一关键业务要素与所述第一业务处理节点对应的目标子业务的业务处理逻辑不匹配。

在一种可选的实施方式中，响应模块503，用于通过以下方法确定监测到任一个所述业务处理节点关联的所述关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配：

获取所述目标业务链路上的每一所述业务处理节点关联的所述关键业务要素；

当监测到所述目标业务链路上不同业务处理节点关联的同一类型的所述关键业务要素出现不匹配的情况时，确定监测到所述不同业务处理节点关联的同一类型的所述关键业务要素与所述不同业务处理节点各自对应的目标子业务的业务处理逻辑不匹配。

在一种可选的实施方式中，当所述目标业务包括交易业务时，响应模块503，具体用于：

响应于监测到第二业务处理节点关联的第二关键业务要素与第三业务处理节点关联的第三关键业务要素不一致，输出针对所述第二业务处理节点和所述第三业务处理节点的异常提示信息；其中，所述第二关键业务要素与所述第三关键业务要素属于同一类型的关键业务要素，该类型的关键业务要素包括以下至少之一：流水号、交易金额以及所述交易业务的收款方信息。

在一种可选的实施方式中，当所述目标业务包括交易业务时，响应模块503，具体用于：

响应于监测到所述目标业务链路中上一业务处理节点关联的交易类型与下一业务处理节点关联的返回码类型不匹配时，输出针对所述目标业务链路的异常提示信息。

在一种可选的实施方式中，当所述目标业务包括交易业务时，响应模块503，具体用于：

响应于监测到所述目标业务链路中上一业务处理节点关联的返回码类型与下一业务处理节点关联的返回码类型不一致时，输出针对所述目标业务链路的异常提示信息。

在一种可选的实施方式中，当所述目标业务包括交易业务时，响应模块503，具体用于：

响应于监测到任一个所述业务处理节点关联的返回码位于目标数组之外，输出针对该业务处理节点的异常提示信息；其中，所述目标数组中包括多个用于标识所述目标业务处理过程中属于正常情况的成功返回码。

通过本申请实施例提供的上述业务异常监测装置，响应针对目标业务链路的异常监测，采集目标业务链路上的每一业务处理节点在处理目标业务过程中的业务处理数据；针对每一业务处理节点，根据该业务处理节点在目标业务中对应处理的目标子业务，从该业务处理节点对应的业务处理数据中，提取与目标子业务匹配的关键业务要素，并将提取的关键业务要素与该业务处理节点进行关联；响应于监测到任一个业务处理节点关联的关键业务要素与该业务处理节点对应的目标子业务的业务处理逻辑不匹配，输出针对该业务处理节点的异常提示信息。这样，本申请能够有效的对跨应用系统的业务处理流程中可能出现的业务异常进行实时监测，有利于提高对于业务处理流程中出现的业务异常的监测效率。

如图6所示，本申请实施例提供了一种计算机设备600，用于执行本申请中上述业务异常监测方法，该设备包括存储器601、处理器602及存储在该存储器601上并可在该处理器602上运行的计算机程序，其中，上述处理器602执行上述计算机程序时实现上述业务异常监测方法的步骤。

具体地，上述存储器601和处理器602可以为通用的存储器和处理器，这里不做具体限定，当处理器602运行存储器601存储的计算机程序时，能够执行上述业务异常监测方法。

对应于本申请中上述业务异常监测方法，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述业务异常监测方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述业务异常监测方法。

在本申请所提供的实施例中，应该理解到，所揭露系统和方法，可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，系统或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。