CN107203464A - 业务问题的定位方法以及装置 - Google Patents

Abstract

本申请公开了一种业务问题的定位方法以及装置。其中该方法包括：获取业务的业务编号，并根据业务编号分别获取各个服务系统针对业务所生成的业务日志；对各个服务系统的业务日志进行汇总并分析以生成针对业务的调度关系链路信息；将调度关系链路信息与预先建立的业务数据模型进行匹配，其中，业务数据模型包含业务状态信息；当调度关系链路信息与业务数据模型匹配时，根据业务数据模型中的业务状态信息对业务进行问题定位。该方法通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

Description

业务问题的定位方法以及装置

技术领域

本申请涉及通信网络领域，尤其涉及一种业务问题的定位方法以及装置。

背景技术

目前，随着有线互联网与无线互联网技术的成熟及相关设备日益完善和普及，为了满足用户各种各样的需求以及提升用户体验，当前业务系统会为用户提供越来越多的业务功能。然而，在业务系统为用户提高越来越多的业务功能的同时，也为系统检测人员在业务系统出现问题时定位哪个或哪些业务出现问题带来了困难，例如，系统检测人员需求找业务涉及的各个系统定位问题。

相关技术中，一般业务问题的定位方法主要是通过收集该业务涉及的各个系统的业务日志，分别对这些日志进行分析以形成业务调用关系链路图，检测人员通过直观地形式再结合人工思维定位业务问题。

但是，目前存在的问题是，当业务系统比较庞大，例如该业务系统具有很多个(如100多个)服务系统时，从对业务日志分析以生成业务调用关系链路图，到根据该链路图定位业务问题，该整个过程都是通过人工进行操作处理，定位方式缺乏智能化，导致人工的工作量增多、人工成本提高、定位效率低等问题。

发明内容

本申请的目的旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种业务问题的定位方法。该方法通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

本申请的第二个目的在于提出一种业务问题的定位装置。

为达上述目的，本申请第一方面实施例的业务问题的定位方法，包括：获取业务的业务编号，并根据所述业务编号分别获取各个服务系统针对所述业务所生成的业务日志；对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息；将所述调度关系链路信息与预先建立的业务数据模型进行匹配，其中，所述业务数据模型包含业务状态信息；当所述调度关系链路信息与所述业务数据模型匹配时，根据所述业务数据模型中的业务状态信息对所述业务进行问题定位。

本申请实施例的业务问题的定位方法，在根据业务编号分别获取各个服务系统针对业务所生成的业务日志之后，可对业务日志进行汇总并分析以形成针对该业务的调度关系链路信息，并将该调度关系链路信息与预先建立的业务数据模型进行匹配，以从该业务数据模型中匹配出该调度关系链路信息所对应的业务状态信息，从而根据该业务状态信息定位该业务的问题所在。该方法通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，在整个过程中，通过软件的方式实现自动化、智能化，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

为达上述目的，本申请第二方面实施例的业务问题的定位装置，包括：第一获取模块，用于获取业务的业务编号；第二获取模块，用于根据所述业务编号分别获取各个服务系统针对所述业务所生成的业务日志；生成模块，用于对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息；匹配模块，用于将所述调度关系链路信息与预先建立的业务数据模型进行匹配，其中，所述业务数据模型包含业务状态信息；问题定位模块，用于在所述调度关系链路信息与所述业务数据模型匹配时，根据所述业务数据模型中的业务状态信息对所述业务进行问题定位。

本申请实施例的业务问题的定位装置，通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，在整个过程中，通过软件的方式实现自动化、智能化，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中，

图1是根据本申请一个实施例的业务问题的定位方法的流程图；

图2是根据本申请一个实施例的建立业务数据模型的流程图；

图3(a)、(b)、(c)和(d)分别为本申请实施例的4种业务场景下各服务系统之间的调用示意图；

图4是根据本申请一个实施例的业务问题的定位装置的结构框图；

图5是根据本申请一个实施例的生成模块的结构框图；

图6是根据本申请另一个实施例的生成模块的结构框图；

图7是根据本申请另一个实施例的业务问题的定位装置的结构框图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的业务问题的定位方法以及装置。

需要说明的是，本申请实施例中所提到的业务所对应的业务系统可以是基于SOA(Service-Oriented Architecture，面向服务的体系结构)思想构建的服务系统，可以理解，该SOA是一个组件模型，其将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来，从而，该业务系统(如交易系统)中可具有多个服务系统，该服务系统可以为不同的业务提供相应的服务以实现该业务的功能。可以理解，为了更好地对业务系统进行维护，该业务系统中的每个服务系统在实现业务功能的同时，会生成该业务所对应的业务日志并进行记录。本申请实施例的业务问题的定位方法可以收集并分析这些业务日志，并将这些日志中所包含的业务调度关系链路形成数据化，以形成业务调用关系链路数据化模型，以便通过软件方式根据业务数据实现自动定位业务问题的目的。

图1是根据本申请一个实施例的业务问题的定位方法的流程图。如图1所示，该业务问题的定位方法可以包括：

S110，获取业务的业务编号，并根据业务编号分别获取各个服务系统针对业务所生成的业务日志。

可以理解，本申请实施例中的业务编号可以由接收业务请求经过的第一个服务系统生成的，该业务编号的生成规则可以是：服务系统所对应的IP+生成业务编号时的时间+自增序列，其中，该业务编号具有唯一性。

还可以理解，为了区分每个业务，该业务系统中的各个服务系统会根据每个业务的业务编号生成并记录每个业务所对应的业务日志。因此，在实现业务问题的定位的过程中，在获取到业务的业务编号之后，可根据该业务编号分别访问各个服务系统以获取各个服务系统针对该业务所生成的业务日志。

作为一种示例，可根据业务编号通过串行化方式分别获取各个服务系统针对业务所生成的业务日志。也就是说，可根据业务编号通过串行化的方式依次访问各个服务系统，以收集各个服务系统针对该业务所生成的业务日志。由此，通过串行化的方式获取各个服务系统的业务日志，可以减少系统资源的使用。

作为另一种示例，可根据业务编号通过并行化方式分别获取各个服务系统针对业务所生成的业务日志。也就是说，可根据业务编号通过并行化的方式同时访问各个服务系统，以收集各个服务系统针对该业务所生成的业务日志。由此，通过并行化的方式获取各个服务系统的业务日志，提升了效率。

S120，对各个服务系统的业务日志进行汇总并分析以生成针对业务的调度关系链路信息。

具体地，可先汇总各个服务系统针对该业务所生成的业务日志，之后，可对该汇总后的业务日志进行分析，确定各个服务系统中针对该业务的多个调用关系，其中，每个调用关系可以包括调用系统、被调用系统、以及调用系统调用被调用系统时所使用的调用方法，该调用关系的形式可为“调用系统.被调用系统.调用方法”，或者，每个调用关系可以包括调用系统、被调用系统、调用系统调用被调用系统时所使用的被调方法、以及该被调方法的被调次数，该调用关系的形式可为“调用系统.被调用系统.调用方法.被调次数”。可以理解，调用关系所包括的信息内容可以根据预先建立的业务数据模型的样式来决定，具体如下：

作为一种示例，当业务数据模型还包含调用系统信息、被调系统信息以及被调方法信息时，对各个服务系统的业务日志进行汇总并分析以生成针对业务的调度关系链路信息(即上述步骤S120)，可以包括：对各个服务系统针对业务所生成的业务日志进行汇总；基于汇总后的业务日志，确定各个服务系统中针对业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、以及调用系统调用被调系统时所使用的被调方法；根据多个调用关系生成针对业务的调度关系链路信息。

作为另一种示例，当业务数据模型还包含调用系统信息、被调系统信息、被调方法信息以及被调次数信息时，对各个服务系统的业务日志进行汇总并分析以生成针对业务的调度关系链路信息(即上述步骤S120)，可以包括：对各个服务系统针对业务所生成的业务日志进行汇总；基于汇总后的业务日志，确定各个服务系统中针对业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、调用系统调用被调系统时所使用的被调方法、以及被调方法的被调次数；根据多个调用关系生成针对业务的调度关系链路信息。

在确定该业务的多个调用关系之后，可按照预设的规则根据该多个调用关系以生成针对该业务的调用关系链路信息，从而实现了根据业务编号即可找到该业务所对应的全链路的调用情况。其中，在本申请的实施例中，上述预设的规则可以是根据业务系统实现业务的实际情况来设置的，例如，可以按照各个服务系统的序号大小、按照各个服务系统的调用顺序、或按照各个服务系统生成业务日志时的时间顺序等。

S130，将调度关系链路信息与预先建立的业务数据模型进行匹配，其中，该业务数据模型包含业务状态信息。此外，该业务状态信息可以理解用于描述该业务的状态情况，该状态情况可以包括正常情况和失败情况，该失败情况可以包括具体失败原因等。

需要说明的是，本申请实施例的业务数据可以理解为根据业务编号找到本业务全链路的调用情况，形成一系列的“调用系统+被调系统+被调方法”、“调用系统+被调系统+被调方法+被调次数”的业务数据，即本业务的调度关系链路信息。

本申请实施例的业务数据模型可理解为业务数据对应的业务状态，例如，“系统D失败，调用系统A+被调系统B+被调方法b，调用系统B+被调系统C+被调方法c，……”其中，“系统D失败”为业务状态信息，“调用系统A+被调系统B+被调方法b，调用系统B+被调系统C+被调方法c，……”为调度关系链路信息。

还需要说明的是，本申请实施例的业务问题的定位方法的主要思想是通过预先建立业务数据模型，并将该当前业务的调度关系链路信息与该业务数据模型进行匹配，以实现根据匹配情况来从该业务数据模型中获取该当前业务的调度关系链路信息所对应的业务状态信息。

可以理解，不同的业务会形成不同的调用关系链路信息(TraceKey信息)，同一个业务在不同场景下也会形成不同的调用关系链路信息(TraceKey信息)，特别是异常场景下会有特征的调用关系链路信息(TraceKey信息)，基于这个事实，可预先收集业务系统中的每个业务所对应的调用关系链路信息，以形成业务数据模型，该业务数据模型中包含调用关系链路信息、以及该调用关系链路信息对应的业务详细状态信息。下面参见图2将对业务数据模型的建立方式进行详细描述。

在本申请的一个实施例中，如图2所示，该业务数据模型可通过以下步骤预先建立：

S210，获取训练业务的业务编号，并根据训练业务的业务编号分别获取各个服务系统针对训练业务所生成的业务日志。

可以理解，该训练业务与上述业务均是业务系统所提供的业务功能，本实施例中的训练业务可以是多个，目的是通过该训练业务来建立业务数据模型。

S220，对各个服务系统的业务日志进行汇总并分析以生成针对训练业务的调度关系链路信息。

在本实施例中，在对各个服务系统的业务日志进行汇总之后，可按照一定的规则对汇总后的业务日志进行分析以生成针对该训练业务的调用关系链路信息。其中，该一定的规则可以例如是按照各个服务系统的序号、按照各个服务系统的调用顺序、或按照各个服务系统生成业务日志时的时间顺序等。下面以示例的形式分别描述按照上述给出的示例规则对汇总后的业务日志进行分析以生成针对该训练业务的调用关系链路信息的实现过程：

作为一种示例，可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统的序号，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。也就是说，在确定针对训练业务的多个调用关系之后，可按照各个服务系统的序号大小或顺序，对多个调用关系进行排序，排序得到的结果即为该训练业务的调度关系链路信息。例如，假设确定训练业务的调用关系分别有调用系统A.被调系统B.被调方法b、调用系统C.被调系统F.被调方法f、调用系统B.被调系统C.被调方法c为例，其中，服务系统A、服务系统B、服务系统C和服务系统F的序号分别为A、B、C和F，则按照服务系统的序号，对该调用关系进行排序，得到的排序结果“调用系统A.被调系统B.被调方法b，调用系统B.被调系统C.被调方法c，调用系统C.被调系统F.被调方法f”即为该训练业务的调用关系链路信息。

作为另一种示例，可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统的调用顺序，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。也就是说，在确定针对训练业务的多个调用关系之后，可按照各个服务系统的调用顺序，对多个调用关系进行排序，排序得到的结果即为该训练业务的调度关系链路信息。例如，以确定训练业务的调用关系分别有调用系统A.被调系统B.被调方法b、调用系统C.被调系统F.被调方法f、调用系统B.被调系统C.被调方法c为例，假设已知针对某个训练业务1，业务系统中的服务系统F是最先进行调用操作，其次为服务系统B，最后为服务系统A，则按照服务系统的调用顺序，对该调用关系进行排序，得到的排序结果“调用系统C.被调系统F.被调方法f，调用系统B.被调系统C.被调方法c，调用系统A.被调系统B.被调方法b”即为该训练业务的调用关系链路信息。

作为又一种示例，可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统生成业务日志时的时间顺序，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。例如，以确定训练业务的调用关系分别有调用系统A.被调系统B.被调方法b、调用系统C.被调系统F.被调方法f、调用系统B.被调系统C.被调方法c为例，假设服务系统A生成业务日志时的时间为17点20分35秒、系统B生成业务日志时的时间为17点20分33秒、系统F生成业务日志时的时间为17点20分36秒，则按照服务系统生成业务日志时的时间顺序，对该调用关系进行排序，得到的排序结果“调用系统B.被调系统C.被调方法c，调用系统A.被调系统B.被调方法b，调用系统C.被调系统F.被调方法f”即为该训练业务的调用关系链路信息。

S230，确定训练业务的调度关系链路信息所对应的业务状态信息。

在本步骤中，可对训练业务的调度关系链路信息进行业务状态分析，其中，作为一种示例，该分析操作可以是通过人工分析该调度关系链路所对应的训练业务的完成情况，并根据该完成情况来确定该调度关系链路信息对应的业务状态信息；作为另一种示例，该分析操作可以是自动获取该调度关系链路所对应的训练业务的完成结果网页内容，并对该网页内容进行抓取以获取与完成结果相关的关键字信息，并对该关键字信息进行语义分析以确定该训练业务的状态信息。

S240，根据训练业务的调度关系链路信息所对应的业务状态信息，以及训练业务的调度关系链路信息建立业务数据模型。

针对每个训练业务，建立训练业务的调度关系链路信息与业务状态信息的对应关系，并对每个训练业务的对应关系进行整合以形成该业务数据模型。

可以理解，由于调度关系链路信息的生成方式不同，所以建立的业务数据模型也会不同，针对上述给出的生成调度关系链路信息的三种示例，则可对应有三种不同的业务数据模型，业务数据模型的个数可根据实际应用来设定。此外，该业务数据模型的表现形式与调度关系链路信息的表现形式有关，作为一种示例，该业务数据模型的形式可以为“业务状态信息，调用系统.被调用系统.调用方法”；作为另一种示例，该业务数据模型的形式可以为“业务状态信息，调用系统.被调用系统.调用方法.被调次数”。

为了使得本领域的技术人员能够更加清楚地了解本申请的业务数据模型，下面将结合图3进行进一步描述。

举例而言，图3(a)、(b)、(c)和(d)分别为本申请实施例的4种业务场景下各服务系统之间的调用示意图。如图3(a)所示，为场景1：业务1的正常情况下各服务系统之间的调用示意图，可对业务日志进行汇总分析以生成针对业务1的调度关系链路信息，其中，不带调用同一个方法次数的调度关系链路信息：A.B.b,B.C.c,C.D.d,D.H.h，带调用同一个方法次数的调度关系链路信息：A.B.b,1,B.C.c,1,C.D.d,1,D.H.h,1，则这两个调度关系链路信息对应的TraceKey1模型(即业务数据模型)：业务1正常,A.B.b,B.C.c,C.D.d,D.H.h，TraceKey2模型(即业务数据模型)：A.B.b,1,B.C.c,1,C.D.d,1,D.H.h,1。

如图3(b)所示，为场景2：业务1的失败情况下各服务系统之间调用示意图，可对业务日志进行汇总分析以生成针对业务1的调度关系链路信息，其中，不带调用同一个方法次数的调度关系链路信息：A.B.b,B.C.c，带调用同一个方法次数的调度关系链路信息：A.B.b,1,B.C.c,1，则这两个调度关系链路信息对应的TraceKey1模型(即业务数据模型)：业务1失败，D系统服务不可用，需找小D支持,A.B.b,B.C.c，TraceKey2模型(即业务数据模型)：业务1失败，D系统服务不可用，需找小D支持,A.B.b,1,B.C.c,1。

如图3(c)所示，为场景3：业务2的正常情况下各服务系统之间调用示意图，可对业务日志进行汇总分析以生成针对业务2的调度关系链路信息，其中，不带调用同一个方法次数的调度关系链路信息：A.C.c,C.E.e,C.F.f，带调用同一个方法次数的调度关系链路信息：A.C.c,2,C.E.e,1,C.F.f,1，则这两个调度关系链路信息对应的TraceKey1模型(即业务数据模型)：业务2正常,A.C.c,C.E.e,C.F.f，TraceKey2模型(即业务数据模型)：业务2正常,A.C.c,2,C.E.e,1,C.F.f,1。

如图3(d)所示，为场景4：业务2的失败情况下各服务系统之间调用示意图，可对业务日志进行汇总分析以生成针对业务2的调度关系链路信息，其中，不带调用同一个方法次数的调度关系链路信息：A.C.c,C.E.e，带调用同一个方法次数的调度关系链路信息：A.C.c,2,C.E.e,1，则这两个调度关系链路信息对应的TraceKey1模型(即业务数据模型)：业务2失败，金额不足，请充值后再发起交易,A.C.c,C.E.e，TraceKey2模型(即业务数据模型)：业务2失败，金额不足，请充值后再发起交易,A.C.c,2,C.E.e,1。

可以看出，综合上述典型的四个场景，在构建好业务数据模型之后，下次遇到同样的问题时，可以根据本次业务的调用关系链路信息与构建好的业务数据模型进行匹配，从而可以很快速地匹配出该业务的问题所在。

由此，通过根据训练任务的业务编号收集各服务系统针对训练任务的业务日志，并对该业务日志进行汇总并分析以形成对应的调用关系链路信息，并将这些训练任务的调用关系链路信息收集起来以形成业务数据模型，该业务数据模型包含了调用关系形成的调用链路数据、以及该链路数据对应的业务详细状态，以便基于新做的业务形成的调用关系链路，可以与该业务数据模型进行匹配以定位该新做的业务的状态信息，即通过反向查询，可以查询到：做的是什么业务？该笔业务是成功还是失败？失败的原因是什么？即定位到业务问题，以便后续根据该业务问题进行分析以找到对应的解决办法。

S140，当调度关系链路信息与业务数据模型匹配时，根据业务数据模型中的业务状态信息对业务进行问题定位。

具体地，当调度关系链路信息与业务数据模型中所包含的调度关系链路匹配时，可从该业务数据模型中找到该调度关系链路信息所对应的业务状态信息，该业务状态信息是对该业务状态的详细描述，由此根据该业务状态详细描述可以定位到该业务的问题所在。

本申请实施例的业务问题的定位方法，在根据业务编号分别获取各个服务系统针对业务所生成的业务日志之后，可对业务日志进行汇总并分析以形成针对该业务的调度关系链路信息，并将该调度关系链路信息与预先建立的业务数据模型进行匹配，以从该业务数据模型中匹配出该调度关系链路信息所对应的业务状态信息，从而根据该业务状态信息定位该业务的问题所在。该方法通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，在整个过程中，通过软件的方式实现自动化、智能化，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

可以理解，本申请实施例提供的业务问题的定位方法还可运用到业务测试自动化执行完成之后的自动定位问题，这样可以充分做到了质量保证过程的自动化，极大的解放了低级的脑力和体力劳动，使得质量保证进入新的阶段。

与上述几种实施例提供的业务问题的定位方法相对应，本申请的一种实施例还提供一种业务问题的定位装置，由于本申请实施例提供的业务问题的定位装置与上述几种实施例提供的业务问题的定位方法相对应，因此在前述业务问题的定位方法的实施方式也适用于本实施例提供的业务问题的定位装置，在本实施例中不再详细描述。图4是根据本申请一个实施例的业务问题的定位装置的结构框图。如图4所示，该业务问题的定位装置可包括：第一获取模块100、第二获取模块200、生成模块300、匹配模块400和问题定位模块500。

其中，第一获取模块100可用于获取业务的业务编号。

第二获取模块200可用于根据业务编号分别获取各个服务系统针对业务所生成的业务日志。

作为一种示例，第二获取模块200可根据业务编号通过串行化方式分别获取各个服务系统针对业务所生成的业务日志。

作为另一种示例，第一获取模块200可根据业务编号通过并行化方式分别获取各个服务系统针对业务所生成的业务日志。

生成模块300可用于对各个服务系统的业务日志进行汇总并分析以生成针对业务的调度关系链路信息。

在本申请的一个实施例中，当业务数据模型还包含用系统信息、被调系统信息以及被调方法信息时，如图5所示，生成模块300包括：第一汇总单元310、第一确定单元320和第一生成单元330。

其中，第一汇总单元310可用于对各个服务系统针对业务所生成的业务日志进行汇总。

第一确定单元320可用于基于汇总后的业务日志，确定各个服务系统中针对业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、以及调用系统调用被调系统时所使用的被调方法。

第一生成单元330可用于根据多个调用关系生成针对业务的调度关系链路信息。

在本申请的另一个实施例中，当业务数据模型还包含调用系统信息、被调系统信息、被调方法信息以及被调次数信息时，如图6所示，生成模块300包括：第二汇总单元340、第二确定单元350和第二生成单元360。

其中，第二汇总单元340可用于对各个服务系统针对业务所生成的业务日志进行汇总。

第二确定单元350可用于基于汇总后的业务日志，确定各个服务系统中针对业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、调用系统调用被调系统时所使用的被调方法、以及被调方法的被调次数。

第二生成单元360可用于根据多个调用关系生成针对业务的调度关系链路信息。

匹配模块400可用于将调度关系链路信息与预先建立的业务数据模型进行匹配，其中，业务数据模型包含业务状态信息。

问题定位模块500可用于在调度关系链路信息与业务数据模型匹配时，根据业务数据模型中的业务状态信息对业务进行问题定位。

进一步地，在本申请的一个实施例中，如图7所示，该定位装置还可包括：模型建立模块600，模型建立模块600可用于预先建立业务数据模型。其中，在本申请的实施例中，如图7所示，该模型建立模块600可包括：获取单元610、生成单元620、确定单元630和建立单元640。

其中，获取单元610可用于获取训练业务的业务编号，并根据训练业务的业务编号分别获取各个服务系统针对训练业务所生成的业务日志。

生成单元620可用于对对各个服务系统的业务日志进行汇总并分析以生成针对训练业务的调度关系链路信息。

作为一种示例，该生成单元620可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统的序号，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。

作为另一种示例，生成单元620可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统的调用顺序，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。

作为又一种示例，生成单元620可先对各个服务系统针对训练业务所生成的业务日志进行汇总，之后，基于汇总后的业务日志，确定各个服务系统中针对训练业务的多个调用关系，最后，按照各个服务系统生成业务日志时的时间顺序，根据训练业务的多个调用关系生成针对训练业务的调度关系链路信息。

确定单元630可用于确定训练业务的调度关系链路信息所对应的业务状态信息。

建立单元640可用于根据训练业务的调度关系链路信息所对应的业务状态信息，以及训练业务的调度关系链路信息建立业务数据模型。

本申请实施例的业务问题的定位装置，通过将业务过程中的信息进行数据化、模型化，以便通过软件的方式将“具体业务”和“数据模型”产生对应关系，从而在问题发生时能够快速定位问题，在整个过程中，通过软件的方式实现自动化、智能化，极大地解放了低级的脑力和体力劳动，降低了人工成本，提高了效率。

在本申请的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (18)

1.一种业务问题的定位方法，其特征在于，包括以下步骤：

获取业务的业务编号，并根据所述业务编号分别获取各个服务系统针对所述业务所生成的业务日志；

对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息；

将所述调度关系链路信息与预先建立的业务数据模型进行匹配，其中，所述业务数据模型包含业务状态信息；

当所述调度关系链路信息与所述业务数据模型匹配时，根据所述业务数据模型中的业务状态信息对所述业务进行问题定位。

2.如权利要求1所述的业务问题的定位方法，其特征在于，所述业务数据模型通过以下步骤建立：

获取训练业务的业务编号，并根据所述训练业务的业务编号分别获取各个服务系统针对所述训练业务所生成的业务日志；

对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述训练业务的调度关系链路信息；

确定所述训练业务的调度关系链路信息所对应的业务状态信息；

根据所述训练业务的调度关系链路信息所对应的业务状态信息，以及所述训练业务的调度关系链路信息建立所述业务数据模型。

3.如权利要求1所述的业务问题的定位方法，其特征在于，当所述业务数据模型还包含调用系统信息、被调系统信息以及被调方法信息时，所述对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息，包括：

对所述各个服务系统针对所述业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、以及所述调用系统调用所述被调系统时所使用的被调方法；

根据所述多个调用关系生成针对所述业务的调度关系链路信息。

4.如权利要求1所述的业务问题的定位方法，其特征在于，当所述业务数据模型还包含调用系统信息、被调系统信息、被调方法信息以及被调次数信息时，所述对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息，包括：

对所述各个服务系统针对所述业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、所述调用系统调用所述被调系统时所使用的被调方法、以及所述被调方法的被调次数；

根据所述多个调用关系生成针对所述业务的调度关系链路信息。

5.如权利要求2所述的业务问题的定位方法，其特征在于，所述对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述训练业务的调度关系链路信息，包括：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统的序号，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

6.如权利要求2所述的业务问题的定位方法，其特征在于，所述对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述训练业务的调度关系链路信息，包括：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统的调用顺序，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

7.如权利要求2所述的业务问题的定位方法，其特征在于，所述对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述训练业务的调度关系链路信息，包括：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统生成业务日志时的时间顺序，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

8.如权利要求1所述的业务问题的定位方法，其特征在于，根据所述业务编号通过串行化方式分别获取所述各个服务系统针对所述业务所生成的业务日志。

9.如权利要求1所述的业务问题的定位方法，其特征在于，根据所述业务编号通过并行化方式分别获取所述各个服务系统针对所述业务所生成的业务日志。

10.一种业务问题的定位装置，其特征在于，包括：

第一获取模块，用于获取业务的业务编号；

第二获取模块，用于根据所述业务编号分别获取各个服务系统针对所述业务所生成的业务日志；

生成模块，用于对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述业务的调度关系链路信息；

匹配模块，用于将所述调度关系链路信息与预先建立的业务数据模型进行匹配，其中，所述业务数据模型包含业务状态信息；

问题定位模块，用于在所述调度关系链路信息与所述业务数据模型匹配时，根据所述业务数据模型中的业务状态信息对所述业务进行问题定位。

11.如权利要求10所述的业务问题的定位装置，其特征在于，还包括：

模型建立模块，用于预先建立所述业务数据模型；其中，所述模型建立模块包括：

获取单元，用于获取训练业务的业务编号，并根据所述训练业务的业务编号分别获取各个服务系统针对所述训练业务所生成的业务日志；

生成单元，用于对对所述各个服务系统的所述业务日志进行汇总并分析以生成针对所述训练业务的调度关系链路信息；

确定单元，用于确定所述训练业务的调度关系链路信息所对应的业务状态信息；

建立单元，用于根据所述训练业务的调度关系链路信息所对应的业务状态信息，以及所述训练业务的调度关系链路信息建立所述业务数据模型。

12.如权利要求10所述的业务问题的定位装置，其特征在于，当所述业务数据模型还包含用系统信息、被调系统信息以及被调方法信息时，所述生成模块包括：

第一汇总单元，用于对所述各个服务系统针对所述业务所生成的业务日志进行汇总；

第一确定单元，用于基于汇总后的所述业务日志，确定所述各个服务系统中针对所述业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、以及所述调用系统调用所述被调系统时所使用的被调方法；

第一生成单元，用于根据所述多个调用关系生成针对所述业务的调度关系链路信息。

13.如权利要求10所述的业务问题的定位装置，其特征在于，当所述业务数据模型还包含调用系统信息、被调系统信息、被调方法信息以及被调次数信息时，所述生成模块包括：

第二汇总单元，用于对所述各个服务系统针对所述业务所生成的业务日志进行汇总；

第二确定单元，用于基于汇总后的所述业务日志，确定所述各个服务系统中针对所述业务的多个调用关系，其中，每个调用关系包括调用系统、被调用系统、所述调用系统调用所述被调系统时所使用的被调方法、以及所述被调方法的被调次数；

第二生成单元，用于根据所述多个调用关系生成针对所述业务的调度关系链路信息。

14.如权利要求11所述的业务问题的定位装置，其特征在于，所述生成单元具体用于：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统的序号，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

15.如权利要求11所述的业务问题的定位装置，其特征在于，所述生成单元具体用于：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统的调用顺序，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

16.如权利要求11所述的业务问题的定位装置，其特征在于，所述生成单元具体用于：

对所述各个服务系统针对所述训练业务所生成的业务日志进行汇总；

基于汇总后的所述业务日志，确定所述各个服务系统中针对所述训练业务的多个调用关系；

按照所述各个服务系统生成业务日志时的时间顺序，根据所述训练业务的多个调用关系生成针对所述训练业务的调度关系链路信息。

17.如权利要求10所述的业务问题的定位装置，其特征在于，所述第二获取模块根据所述业务编号通过串行化方式分别获取所述各个服务系统针对所述业务所生成的业务日志。

18.如权利要求10所述的业务问题的定位装置，其特征在于，所述第一获取模块根据所述业务编号通过并行化方式分别获取所述各个服务系统针对所述业务所生成的业务日志。