故障定位平台、故障定位方法及装置与流程

本发明涉及通信
技术领域：
，特别涉及一种故障定位平台、故障定位方法及装置。
背景技术：
：在云服务环境中，一个平台为了提供多种业务，通常在平台中设置有多个系统，通过多个系统之间的交互调用完成多种业务。其中，多种业务可以包括：文件业务、对象业务和主机备份业务等。现有技术中，平台在执行某一业务时，平台中的多个系统之间存在交互调用的情况，当该业务执行失败时，需要按照从上至下的顺序，从平台中最上层的系统开始，依次排查执行该业务时存在交互调用的各个系统，最终定位出现故障的系统。请参考图1所示，以云平台100中包括：云管理系统210、数据保护服务系统220、虚拟化系统230、生产存储系统240、云备份管理系统250和备份存储系统260为例。该云平台100执行主机备份业务流程如下：云管理系统210向数据保护服务系统220发送备份请求；数据保护服务系统220在接收到备份请求后，向虚拟化系统230发送调度备份请求；虚拟化系统230根据接收到的调度备份请求，向云备份管理系统250发送执行备份请求，并每隔预设时间查询备份状态；云备份管理系统250根据执行备份请求依次执行卷快照251、卷快照对比252、提取数据253、存放数据254和备份完成255。其中，卷快照对比是指将当前时刻的数据与上一时刻的数据进行对比；云备份管理系统250将卷快照对比的结果和经过提取后得到的差异数据存储至生产存储系统240中；将当前时刻的数据存放至备份存储系统260中。在实现本发明实施例的过程中，发明人发现现有技术至少存在以下问题：当主机备份执行失败时，需要从最上层的云管理系统210开始，依次排查数据保护服务系统220、虚拟化系统230、生产存储系统240、云备份管理系统250和备份存储系统260是否出现故障，最终定位出现故障的系统，导致对出现故障的系统的定位效率较低。技术实现要素：为了解决现有技术中的问题，本发明实施例提供了一种故障定位平台、故障定位方法及装置。所述技术方案如下：第一方面，提供了一种故障定位平台，所述平台包括：标识分配系统、日志系统、第一业务系统和第二业务系统；所述标识分配系统，用于向业务请求分配业务请求标识(identification，ID)，所述业务请求是所述第一业务系统执行业务时发送的；所述业务是由存在调用关系的所述第一业务系统和所述第二业务系统协作执行的业务；所述第一业务系统，用于生成与所述业务请求ID对应的各个业务步骤的处理日志，所述处理日志用于记录所述业务步骤的执行结果；所述各个业务步骤包括：所述第一业务系统执行的业务步骤，和，所述第一业务系统调用所述第二业务系统执行的业务步骤；所述日志系统，用于接收与所述业务请求ID对应的所述处理日志；根据所述处理日志中的所述执行结果确定异常业务步骤，将用于执行所述异常业务步骤的业务系统定位为故障业务系统。本发明实施例所示的方案，由于第一业务系统和第一业务系统调用第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。在第一方面的第一种可能的实现方式中，所述第一业务系统，用于在执行与所述业务请求ID对应的内部业务步骤时，生成与所述内部业务步骤对应的第一处理日志，向所述日志系统发送所述第一处理日志，所述第一处理日志用于记录所述第一业务系统执行所述内部业务步骤的执行结果；所述第一业务系统，还用于在调用所述第二业务系统执行与所述业务请求ID对应的外部业务步骤时，生成与所述外部业务步骤对应的第二处理日志，向所述日志系统发送所述第二处理日志，所述第二处理日志用于记录被调用的所述第二业务系统执行所述外部业务步骤的执行结果；所述日志系统，用于根据所述第一处理日志中的所述执行结果确定所述内部业务步骤是否为所述异常业务步骤，在所述内部业务步骤是所述异常业务步骤时，将所述第一业务系统定位为所述故障业务系统；根据所述第二处理日志中的所述执行结果确定所述外部业务步骤是否为所述异常业务步骤，在所述外部业务步骤是所述异常业务步骤时，将被调用的所述第二业务系统定位为所述故障业务系统。本发明实施例所示的方案，第一业务系统将执行内部业务步骤的执行结果记录为第一处理日志；将执行外部业务步骤的执行结果记录为第二处理日志；日志系统根据第一处理日志的执行结果可以确定出第一业务系统是否为故障业务系统；根据第二处理日志的执行结果可以确定出第二业务系统是否为故障业务系统；将内部业务步骤和外部业务步骤进行区别记录，有利于提高对故障业务系统的定位效率。结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一业务系统包括：具有第一应用编程接口(ApplicationProgrammingInterface，API)的第一处理模块，所述第一API具有对应的第一API标识；所述第二业务系统包括：具有第二API的第二处理模块，所述第二API具有对应的第二API标识；所述第一业务系统，用于向所述日志系统发送所述第一处理日志；所述第一处理日志包括：所述业务请求ID、第一业务系统ID、所述第一API标识和结果码，所述结果码是指所述第一处理模块执行所述内部业务步骤的执行结果；所述第一业务系统，还用于向所述日志系统发送所述第二处理日志；所述第二处理日志包括：所述业务请求ID、所述第一业务系统ID、所述第一API标识、第二业务系统ID、所述第二API标识和返回码，所述返回码是指在调用所述第二处理模块执行所述外部业务步骤的执行结果；所述日志系统，用于在所述故障业务系统为所述第一业务系统时，将所述第一API标识对应的API定位为故障API；在所述故障业务系统为被调用的所述第二业务系统时，将所述第二API标识对应的API定位为所述故障API。本发明实施例所示的方案，在故障业务系统为第一业务系统时，日志系统根据第一处理日志中携带的第一API标识，确定第一API标识对应的API为故障API；在故障业务系统为第二业务系统时，日志系统根据第二处理日志中携带的第二API标识，确定第二API表示对应的API为故障API；通过在第一处理日志中携带有第一API标识和第二处理日志中携带有第二API标识，以便日志系统可以根据API标识定位出故障API，提高了对故障业务系统的定位的准确性的效果。结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，所述日志系统，用于获取与所述业务请求ID对应的业务流程模型，所述业务流程模型包括：与所述业务请求ID对应的各个业务步骤的执行顺序；根据所述执行顺序依次获取与各个业务步骤对应的n个第一处理日志和m个第二处理日志，所述n和所述m分别为正整数。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序获取与各个业务步骤对应的第一处理日志和第二处理日志，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述日志系统，还用于：根据第i个第一处理日志中的执行结果确定所述内部业务步骤是否为所述异常业务步骤，所述i为小于等于n的正整数；若是所述异常业务步骤，则将所述第i个第一处理日志中包括的第一API标识对应的API定位为所述故障API；若不是所述异常业务步骤，则令i＝i+1，再次根据所述第i个第一处理日志中的执行结果确定所述内部业务步骤是否为所述异常业务步骤。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序依次根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。结合第一方面的第三种可能的实现方式，在第五种可能的实现方式中，所述日志系统，还用于：根据第j个第二处理日志中的执行结果确定所述外部业务步骤是否为所述异常业务步骤，所述j为小于等于m的正整数；若是所述异常业务步骤，则将所述第j个第二处理日志中包括的第二API标识对应的API定位为所述故障API；若不是所述异常业务步骤，则令j＝j+1，再次根据所述第j个第二处理日志中的执行结果确定所述外部业务步骤是否为所述异常业务步骤。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序依次根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。第二方面，提供了一种故障定位方法，所述方法包括：接收与业务请求标识ID对应的处理日志；业务请求是第一业务系统执行业务时发送的，所述业务是由存在调用关系的所述第一业务系统和第二业务系统协作执行的业务，所述处理日志用于记录与所述业务请求ID对应的各个业务步骤的执行结果，所述各个业务步骤包括：所述第一业务系统执行的业务步骤，和，所述第一业务系统调用所述第二业务系统执行的业务步骤；根据所述处理日志中的所述执行结果确定异常业务步骤；将用于执行所述异常业务步骤的业务系统定位为故障业务系统。本发明实施例所示的方案，由于日志系统根据接收到的与业务请求ID对应的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。在第二方面的第一种可能的实现方式中，所述处理日志包括：第一处理日志和第二处理日志；所述根据所述处理日志中的所述执行结果确定异常业务步骤，包括：根据第一处理日志中的所述执行结果确定内部业务步骤是否为所述异常业务步骤；所述第一处理日志用于记录所述第一业务系统执行与所述业务请求ID对应的所述内部业务步骤的执行结果；根据第二处理日志中的所述执行结果确定外部业务步骤是否为所述异常业务步骤；所述第二处理日志用于记录在调用所述第二业务系统执行与所述业务请求ID对应的所述外部业务步骤的执行结果。结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，所述将用于执行所述异常业务步骤的业务系统定位为故障业务系统，包括：在所述内部业务步骤是所述异常业务步骤时，将所述第一业务系统定位为所述故障业务系统；在所述外部业务步骤是所述异常业务步骤时，将被调用的所述第二业务系统定位为所述故障业务系统。本发明实施例所示的方案，业务系统将执行内部业务步骤的执行结果记录为第一处理日志；将执行外部业务步骤的执行结果记录为第二处理日志；日志系统根据第一处理日志的执行结果可以确定出第一业务系统是否为故障业务系统；根据第二处理日志的执行结果可以确定出第二业务系统是否为故障业务系统；将内部业务步骤和外部业务步骤进行区别记录，有利于提高对故障业务系统的定位效率。结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，所述第一业务系统包括：具有第一应用编程接口API的第一处理模块，所述第一API具有对应的第一API标识；所述第二业务系统包括：具有第二API的第二处理模块，所述第二API具有对应的第二API标识；所述方法，还包括：在所述故障业务系统为所述第一业务系统时，根据所述第一处理日志中包含的所述第一API标识，将所述第一API标识对应的API定位为故障API；所述第一处理日志包括：所述业务请求ID、第一业务系统ID、所述第一API标识和结果码，所述结果码是指所述第一处理模块执行所述内部业务步骤的执行结果；在所述故障业务系统为被调用的所述第二业务系统时，根据所述第二处理日志中包含的所述第二API标识，将所述第二API标识对应的API定位为所述故障API；所述第二处理日志包括：所述业务请求ID、所述第一业务系统ID、所述第一API标识、第二业务系统ID、所述第二API标识和返回码，所述返回码是指在调用所述第二处理模块执行所述外部业务步骤的执行结果。本发明实施例所示的方案，在故障业务系统为第一业务系统时，日志系统根据第一处理日志中携带的第一API标识，确定第一API标识对应的API为故障API；在故障业务系统为第二业务系统时，日志系统根据第二处理日志中携带的第二API标识，确定第二API表示对应的API为故障API；通过在第一处理日志中携带有第一API标识和第二处理日志中携带有第二API标识，以便日志系统可以根据API标识定位出故障API，提高了对故障业务系统的定位的准确性的效果。结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述方法，还包括：获取与所述业务请求ID对应的业务流程模型，所述业务流程模型包括：与所述业务请求ID对应的各个业务步骤的执行顺序；根据所述执行顺序依次获取与各个业务步骤对应的n个第一处理日志和m个第二处理日志，所述n和所述m分别为正整数。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序获取与各个业务步骤对应的第一处理日志和第二处理日志，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，所述根据第一处理日志中的所述执行结果确定内部业务步骤是否为所述异常业务步骤，包括：根据第i个第一处理日志中的执行结果确定所述内部业务步骤是否为所述异常业务步骤，所述i为小于等于n的正整数；所述将所述第一API标识对应的API定位为故障API，包括：若是所述异常业务步骤，则将所述第i个第一处理日志中包括的第一API标识对应的API定位为所述故障API；若不是所述异常业务步骤，则令i＝i+1，再次执行所述根据所述第i个第一处理日志中的执行结果确定是否为所述异常业务步骤的步骤。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序依次根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。结合第二方面的第四种可能的实现方式，在第六种可能的实现方式中，所述根据第二处理日志中的所述执行结果确定外部业务步骤是否为所述异常业务步骤，包括：根据第j个第二处理日志中的执行结果确定所述外部业务步骤是否为所述异常业务步骤，所述j为小于等于m的正整数；所述将所述第二API标识对应的API定位为所述故障API，包括：若是所述异常业务步骤，则将所述第j个第二处理日志中包括的第二API标识对应的API定位为所述故障API；若不是所述异常业务步骤，则令j＝j+1，再次执行所述根据所述第j个第二处理日志中的执行结果确定所述外部业务步骤是否为所述异常业务步骤的步骤。本发明实施例所示的方案，日志系统根据业务流程模型中的执行顺序依次根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。第三方面，提供了故障定位装置，所述故障定位装置包括至少一个单元，该至少一个单元用于实现上述第二方面或第二方面中任意一种可能所提供的故障定位方法。上述本发明实施例第三方面所获得的技术效果与第二方面中对应的技术手段获得的技术效果近似，在这里不再赘述。第四方面，提供一种计算机可读存储介质，该计算机可读存储介质中存储有用于实现上述第二方面或第二方面中任意一种可能的设计所提供的故障定位方法的可执行程序。第五方面，提供一种日志系统，该日志系统包括处理器和存储器；所述处理器用于存储一个或一个以上的指令，所述指令被指示为由所述处理器执行，所述处理器用于实现上述第二方面或第二方面中任意一种可能的设计中所提供的故障定位方法。综上所述，本发明实施例提供的技术方案带来的有益效果包括：通过业务系统在执行与业务请求ID对应的业务步骤时，向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了提高对故障业务系统的定位效率的效果。附图说明为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。图1是现有技术中提供的主机备份业务的方法流程图；图2是本发明一个实施例提供的故障定位平台的结构示意图；图3是本发明另一个实施例提供的故障定位平台的结构示意图；图4是本发明一个实施例提供的主机备份业务故障定位的结构示意图；图5是本发明一个实施例提供的日志系统的结构示意图；图6是本发明一个实施例提供的一种故障定位方法的方法流程图；图7是本发明另一个实施例提供的一种故障定位方法的方法流程图；图8是本发明又一个实施例提供的一种故障定位方法的方法流程图；图9是本发明一个实施例提供的一种故障定位系统的结构示意图；图10是本发明一个实施例提供的一种故障定位方法的方法流程图；图11是本发明一个实施例提供的故障定位装置的结构框图。具体实施方式为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。请参考图2，其示出了本发明一个实施例提供的故障定位平台的结构示意图。如图2所示，该平台可以包括：标识分配系统120、日志系统140、第一业务系统161和第二业务系统162。标识分配系统120具有为业务请求分配业务请求ID的能力。其中，业务请求是第一业务系统161执行业务时发送的，业务是由存在调用关系的第一业务系统161和第二业务系统162协作执行的业务。可选的，本发明实施例中仅以执行业务的业务系统包括第一业务系统161和第二业务系统162为例进行举例说明，但不对执行业务的业务系统做具体限定，比如：执行业务的业务系统还包括：第三业务系统(图中未示出)；其中，业务是由存在调用关系的第一业务系统161和第二业务系统162，以及存在调用关系的第一业务系统161和第三业务系统协作执行的业务。可选的，标识分配系统120还具有为业务分配业务ID的能力。一个业务ID对应一个业务请求ID，或者，一个业务ID对应若干个业务请求ID。可选的，在执行同一个业务时，在不同时间点触发业务请求时，标识分配系统120会为不同时间点触发的业务请求生成不同的业务请求ID。也就是说，每执行业务中的一个业务步骤，都会生成一个业务请求，标识分配系统120也会分配一个业务请求ID。可选的，标识分配系统120中记录有业务ID、业务请求ID，以及业务ID和业务请求ID之间的对应关系。可选的，标识分配系统120将记录的业务ID、业务请求ID，以及业务ID和业务请求ID之间的对应关系同步给日志系统140。第一业务系统161和第二业务系统162具有执行业务的能力，同时第一业务系统161还具有调用第二业务系统执行业务步骤的能力。业务请求ID对应的各个业务步骤包括：第一业务系统161执行的业务步骤和第一业务系统161调用第二业务系统162执行的业务步骤；在执行与业务请求ID对应的各个业务步骤时，第一业务系统161生成与业务请求ID对应的各个业务步骤的处理日志；可选的，业务请求ID对应有一个业务步骤，或者，业务请求ID对应有若干个业务步骤；业务请求ID对应的业务步骤中存在至少一个业务步骤是第一业务系统161调用第二业务系统162完成的步骤；每个业务步骤对应有一个处理日志。可选的，处理日志用于记录业务步骤的执行结果；可选的，执行结果包括：执行成功或执行失败。可选的，第一业务系统161将生成的与业务请求ID对应的处理日志发送给日志系统140。第一业务系统161通过异步发送的方式将与业务请求ID对应的处理日志发送给日志系统140，或者，第一业务系统161将生成的与业务请求ID对应的处理日志集中一起上报给日志系统140。日志系统140具有分析处理日志的能力。日志系统140接收第一业务系统161发送的与业务请求ID对应的处理日志，根据处理日志中的执行结果确定异常业务步骤，并将执行该异常业务步骤的业务系统140定位为故障业务系统。可选的，异常业务步骤包括执行失败；日志系统140在检测到处理日志中的执行结果为执行失败时，确定执行该业务步骤的业务系统140为故障业务系统。综上所述，本实施例提供的故障定位平台，通过第一业务系统和第一业务系统调用第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。基于图2所示的故障定位平台中，可选的，第一业务系统161上报的处理日志包括：第一处理日志和第二处理日志，如图3所示。第一业务系统161可以通过自身独立执行与业务请求ID对应的内部业务步骤，在执行内部业务步骤时，生成与内部业务步骤对应的第一处理日志。第一处理日志记录第一业务系统161执行内部业务步骤的执行结果。可选的，第一业务系统161包括具有第一API的第一处理模块，第一API具有对应的第一API标识；第一业务系统161通过第一处理模块执行与业务请求ID对应的内部业务步骤；第一处理日志包括：业务请求ID、第一业务系统ID、第一API标识和结果码，其中结果码是第一处理模块执行内部业务步骤的执行结果。可选的，当业务步骤执行失败时，第一处理日志中携带有错误的结果码，或者，第一处理日志中不携带结果码，或者，第一处理日志中不携带有结果码，且携带有网络连接异常或无响应等。可选的，第一业务系统161将生成的第一处理日志发送给日志系统140。第二业务系统162是第一业务系统161在执行与业务请求ID对应的外部业务步骤时调用的业务系统。可选的，第一业务系统161在调用第二业务系统162执行与业务请求ID对应的外部业务步骤时，生成与外部业务步骤对应的第二处理日志。第二处理日志记录调用第二业务系统162执行外部业务步骤的执行结果。可选的，第二业务系统162包括具有第二API的第二处理模块，第二API具有对应的第二API标识；第一业务系统161通过第一处理模块调用第二处理模块执行与业务请求ID对应的外部业务步骤；第二处理日志包括：业务请求ID、第一业务系统ID、第一API标识、第二业务系统ID和第二API标识和返回码，其中返回码是第二处理模块执行外部业务步骤的执行结果。可选的，第一业务系统161将生成的第二处理日志发送给日志系统140。需要补充说明的是，本实施例中仅以第一业务系统161执行业务时发送的业务请求为例进行举例说明，但不对此做具体限定，比如：由第二业务系统162在执行业务时发送的业务请求为例，则在执行业务的过程中第二业务系统162也可以独立执行业务请求ID对应的内部业务步骤，并生成对应的第一处理日志，发送给日志系统140，或者第二业务系统调用其他的业务系统执行业务请求ID对应的外部业务步骤，并生成对应的第二处理日志，发送给日志系统140。日志系统140根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，在内部业务步骤是异常业务步骤时，将第一业务系统161定位为故障业务系统；日志系统140还根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，在外部业务步骤是异常业务步骤时，将被调用的第二业务系统162定位为故障业务系统。可选的，日志系统140在将第一业务系统161定位为故障业务系统后，根据第一处理日志中携带的第一API标识，确定第一API标识对应的API为故障API；日志系统还在将第二业务系统162定位为故障业务系统后，根据第二处理日志中携带的第二API标识，确定第二API标识对应的API为故障API。可选的，日志系统140还获取与业务请求ID对应的业务流程模型。业务流程模型中包括：与业务请求ID对应的各个业务步骤的执行顺序。日志系统140根据业务流程模型中的执行顺序依次获取与各个业务步骤对应的n个第一处理日志和m个第二处理日志，n和m分别为正整数。可选的，日志系统140根据第i个第一处理日志中的执行结果确定内部业务步骤是否异常业务步骤，i为小于等于n的正整数；在内部业务步骤是异常业务步骤时，日志系统140将第i个第一处理日志中携带的第一API标识对应的API确定为故障API；若内部业务步骤不是异常业务步骤，则日志系统140令i＝i+1，继续根据第i个第一处理日志中的执行结果确定内部业务步骤是否异常业务步骤，直至确定出异常业务步骤为止。可选的，日志系统140根据第j个第二处理日志中的执行结果确定外部业务步骤是否异常业务步骤，j为小于等于m的正整数；在外部业务步骤是异常业务步骤时，日志系统140将第j个第二处理日志中携带的第二API标识对应的API确定为故障API；若外部业务步骤不是异常业务步骤，则日志系统140令j＝j+1，继续根据第j个第二处理日志中的执行结果确定外部业务步骤是否异常业务步骤，直至确定出异常业务步骤为止。可选的，日志系统140包括：分析组件141、建模组件142、ID处理组件143和日志组件144；ID处理组件143，用于存储业务请求ID；日志组件144，用于存储与业务请求ID对应的处理日志；建模组件142，用于存储与业务请求ID对应的业务流程模型；分析组件141，用于根据业务流程模型和处理日志中的执行结果确定异常业务步骤，将用于执行异常业务步骤的业务系统定位为故障业务系统。在一个示例性的例子中，如图4所示，以图1所示的主机备份业务为例，执行业务的业务系统包括：云管理系统11、数据保护服务系统12、虚拟化系统13、云备份管理系统14、生产存储系统15和备份存储系统16；在完成主机备份业务时，云管理系统11调用数据保护服务系统12执行备份请求，标识分配系统为备份请求分配业务请求ID，将业务请求ID反馈给云管理系统11，同时也同步给日志系统140中的ID处理组件143；在调用数据保护服务系统12执行备份请求时，云管理系统11生成对应的第二处理日志，并将生成的第二处理日志发送给日志系统140中的日志组件144；数据保护服务系统12调用虚拟化系统13执行调度备份请求时；数据保护服务系统12生成对应的第二处理日志，并将生成的第二处理日志发送给日志系统140中的日志组件144；虚拟化系统13调用云备份管理系统14依次执行卷快照、卷快照对比、提取数据、存放数据和备份完成5个步骤时；虚拟化系统13生成对应的第二处理日志，并将生成的第二处理日志发送给日志系统140中的日志组件144；云备份管理系统14在独立执行卷快照、卷快照对比、提取数据、存放数据和备份完成5个步骤时，根据每个步骤生成对应的第一处理日志，将生成的5个第一处理日志发送给日志系统140中的日志组件144；云备份管理系统14调用生产存储系统15存储卷快照对比的结果和经过提取后得到的差异数据时，云备份管理系统14生成对应的第二处理日志，并将生成的第二处理日志发送给日志系统140中的日志组件144；云备份管理系统14在调用备份存储系统16存储当前时刻的数据时，云备份管理系统14生成对应的第二处理日志，并将生成的第二处理日志发送给日志系统140中的日志组件144；日志系统140中的建模组件142中预先存储有与主机备份请求ID对应的业务流程模型；在主机备份业务失败时，日志系统140中的分析组件141，根据业务流程模型和日志组件144中存储的处理日志的执行结果确定异常业务步骤，将用于执行异常业务步骤的业务系统定位为故障业务系统。比如：根据虚拟化系统13上报的第二处理日志中的执行结果确定该业务步骤为异常业务步骤，则分析组件141确定云备份管理系统14为故障业务系统。请参考图5，其示出了本发明一个实施例提供的日志系统140的结构示意图，该日志系统140可以包括：处理器511、通信总线512、存储器513以及通信接口514。处理器511可以包括一个或者一个以上中央处理单元(英文：CentralProcessingUnit，缩写：CPU)。处理器511通过运行软件程序以及模块，从而执行各种功能应用以及业务数据处理。通信接口514可以包含无线网络接口，比如以太网接口，也可以包含有线网络接口。该通信接口514用于接收业务系统发送的处理日志和标识分配系统发送的业务请求ID。存储器513和通信接口514分别通过通信总线512与处理器511相连。存储器513可用于存储软件程序以及模块，该软件程序以及模块由处理器511执行。此外，该存储器513中还可以存储各类业务数据和用户数据。在本发明实施例中，存储器513可存储操作系统51以及至少一个功能所需的程序指令52。程序指令52可以包括接收模块521、确定模块522和定位模块523和获取模块524等。接收模块521，用于接收与业务请求标识ID对应的处理日志。确定模块522，用于根据处理日志中的执行结果确定异常业务步骤。定位模块523，用于将用于执行异常业务步骤的业务系统定位为故障业务系统。获取模块524，用于获取与业务请求ID对应的业务流程模型。存储器513可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(staticrandomaccessmemory，SRAM)，动态随机存取存储器(dynamicrandomaccessmemory，DRAM)，电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，EEPROM)，可擦除可编程只读存储器(erasableprogrammableread-onlymemory，EPROM)，可编程只读存储器(programmableread-onlymemory，PROM)，只读存储器(read-onlymemory，ROM)，磁存储器，快闪存储器，磁盘或光盘。本领域技术人员可以理解，图5中所示出的该日志系统140结构并不构成对该日志系统140的限定，本发明中的日志系统140可以包括比图示更多或更少的部件或组合某些部件，或者不同的部件布置。请参考图6，其示出了本发明一个实施例提供的故障定位方法的方法流程图。本实施例以该故障定位方法应用于图2所示的日志系统140中来举例说明。该故障定位方法包括以下步骤：步骤601，日志系统接收与业务请求ID对应的处理日志。业务请求是第一业务系统执行业务时发送的，业务是由存在调用关系的第一业务系统和第二业务系统协作执行的业务，处理日志用于记录与业务请求ID对应的各个业务步骤的执行结果，各个业务步骤包括：第一业务系统执行的业务步骤，和，第一业务系统调用第二业务系统执行的业务步骤。可选的，本发明实施例中仅以执行业务的业务系统包括第一业务系统和第二业务系统为例进行举例说明，但不对执行业务的业务系统做具体限定，比如：执行业务的业务系统还包括：第三业务系统；其中，业务是由存在调用关系的第一业务系统和第二业务系统，以及存在调用关系的第一业务系统161和第三业务系统协作执行的业务。对应地，业务请求ID对应的各个业务步骤也仅以第一业务系统执行的业务步骤和第一业务系统调用第二业务系统执行的业务步骤为例进行举例说明，本发明实施例对此并不做具体限定，比如：各个业务步骤还可以包括：第一业务系统调用第三业务系统执行的业务步骤。第一业务系统生成与业务请求ID对应的各个业务步骤的处理日志。第一业务系统在执行与业务请求ID对应的业务步骤，以及第一业务系统调用第二业务系统执行与业务请求ID对应的业务步骤时，第一业务系统生成与各个业务步骤对应的处理日志，可选的，每一个业务步骤对应一个处理日志。比如：业务系统A在执行与业务请求B对应的业务步骤时需要完成业务步骤1、业务步骤2和业务步骤3，业务步骤1需要调用业务系统C执行；则在执行业务步骤1时，业务系统A生成与业务步骤1对应的处理日志1；在执行业务步骤2时，业务系统A生成与业务步骤2对应的处理日志2；在执行业务步骤3时，业务系统A生成与业务步骤3对应的处理日志3。第一业务系统将生成的处理日志发送给日志系统；可选的，第一业务系统通过异步发送的方式分别将处理日志发送给日志系统；或者，第一业务系统将生成的处理日志一起发送给日志系统；比如：第一业务系统在生成处理日志1时将处理日志1发送给日志系统；在生成处理日志2时将处理日志2发送给日志系统；在生成处理日志3时将处理日志3发送给日志系统；或者，第一业务系统在生成处理日志1、处理日志2和处理日志3后，将处理日志1、处理日志2和处理日志3一起发送给日志系统。对应的，日志系统接收第一业务系统发送的与业务请求ID对应的处理日志。该步骤可以由图5所示的日志系统140中的处理器511执行接收模块521来实现。步骤602，日志系统根据处理日志中的执行结果确定异常业务步骤。日志系统在接收到处理日志后，根据处理日志中的执行结果确定异常业务步骤。可选的，处理日志中的执行结果包括：执行成功或执行失败；异常业务步骤为执行结果为执行失败对应的业务步骤。当处理日志中的执行结果为执行失败时，日志系统确定该处理日志对应的业务步骤为异常业务步骤。比如：处理日志1、处理日志2和处理日志3中处理日志2中的执行结果为执行失败，则日志系统根据处理日志2中的执行结果确定业务步骤2为异常业务步骤。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤603，将用于执行异常业务步骤的业务系统定位为故障业务系统。日志系统再确定出异常业务步骤后，将用于执行该异常业务步骤的业务系统定位为故障业务系统。比如：日志系统确定业务步骤2为异常业务步骤，则日志系统将执行业务步骤2的业务系统A确定为故障业务系统。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块523来实现。综上所述，本实施例提供的故障定位方法，通过第一业务系统和第一业务系统调用第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。基于图6所示的实施例中，可选的，第一业务系统可以独立执行与业务请求ID对应的内部业务步骤；处理日志为第一处理日志，第一处理日志用于记录第一业务系统执行与业务请求ID对应的内部业务步骤的执行结果。则作为一种可能的实现方式，步骤602至步骤603可以替换实现为如下步骤701至步骤705，如图7所示：步骤701，日志系统获取与业务请求ID对应的业务流程模型，业务流程模型包括：与业务请求ID对应的各个业务步骤的执行顺序。在业务请求执行失败时，日志系统获取与业务请求ID对应的业务流程模型。第一业务系统在独立执行与业务请求ID对应的内部业务步骤时，需要按照预定的执行顺序执行整个业务请求ID对应的内部业务步骤，比如：业务系统A执行业务请求71时，总共需要执行4个业务步骤，分别为业务步骤1、业务步骤2、业务步骤3和业务步骤4；先通过B模块执行业务步骤1和业务步骤2；再通过C模块执行业务步骤3和业务步骤4。则示例性的，业务系统A执行业务请求71对应的业务流程模型如下表一所示：业务请求ID业务系统业务系统的模块执行顺序业务请求71业务系统AB模块1业务请求71业务系统AC模块2表一该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤702，日志系统根据执行顺序依次获取与各个业务步骤对应的n个第一处理日志，n为正整数。日志系统在获取到业务流程模型后，根据业务流程模型中的执行顺序从接收到的处理日志中，获取与各个业务步骤对应的n个第一处理日志。可选的，第一处理日志是第一业务系统在独立执行与业务请求ID对应的内部业务步骤时对应的执行结果。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤703，日志系统根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤。可选的，第一处理日志中的执行结果包括：执行成功或执行失败；异常业务步骤为执行结果为执行失败对应的业务步骤。当第一处理日志中的执行结果为执行失败时，日志系统确定该第一处理日志对应的内部业务步骤为异常业务步骤。比如：第一处理日志1、第一处理日志2和第一处理日志3中第一处理日志2中的执行结果为执行失败，则日志系统根据第一处理日志2中的执行结果确定内部业务步骤2为异常业务步骤。可选的，本步骤可以通过如下可能的实现方式实现：第一步，根据第i个第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，i为小于等于n的正整数。可选的，i的初始值为1。日志系统从第1个第一处理日志开始，根据第1个第一处理日志的执行结果确定对应的内部业务步骤是否为异常业务步骤。第二步，若不是异常业务步骤，则令i＝i+1，继续根据第i个第一处理日志中的执行结果确定对应的内部业务步骤是否为异常业务步骤。通过上述两个步骤的循环，直至确定到异常业务步骤为止，否则对n个第一处理日志中的执行结果依次进行确定。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤704，在内部业务步骤是异常业务步骤时，日志系统将第一业务系统定位为故障业务系统。当日志系统确定第i个第一处理日志中对应的内部业务步骤是异常业务步骤时，则日志系统将执行该内部业务步骤的第一业务系统定位为故障业务系统。比如：日志系统确定第2个第一处理日志中对应的内部业务步骤2为异常业务步骤，则日志系统将执行内部业务步骤2的第一业务系统A确定为故障业务系统。可选的，第一业务系统包括：具有第一API的第一处理模块，第一API具有对应的第一API标识；第一处理日志包括：业务请求ID、第一业务系统ID、第一API标识和结果码，结果码是指第一处理模块执行内部业务步骤的执行结果。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块523来实现。步骤705，在故障业务系统为第一业务系统时，日志系统根据第一处理日志中包含的第一API标识，将第一API标识对应的API定位为故障API。日志系统在根据第一处理日志中携带的结果码确定出第一业务系统为故障业务系统后，将第一处理日志中包含的第一API标识对应的API确定为故障API。比如：第一业务系统B包括第一处理模块a和第一处理模块b；第一处理模块a的第一API标识为API11，第一处理模块b的第一API标识为API12；第一业务系统B执行业务请求72时，总共需要执行2个内部业务步骤，分别为内部业务步骤1和内部业务步骤2；先通过第一处理模块a执行内部业务步骤1；再通过第一处理模块b执行内部业务步骤2；当日志系统根据第一处理日志中的结果码确定第一业务系统B为故障业务系统时，根据第一处理日志中携带的API12确定API12对应的API为故障API。可选的，故障API对应的第一处理模块b为故障处理模块。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块523来实现。综上所述，本实施例提供的故障定位方法，通过第一业务系统和第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。另外，日志系统根据业务流程模型中的执行顺序依次根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。同时，在故障业务系统为第一业务系统时，日志系统根据第一处理日志中携带的第一API标识，确定第一API标识对应的API为故障API，通过在第一处理日志中携带有第一API标识，以便日志系统可以根据API标识定位出故障API，提高了对故障业务系统的定位的准确性的效果。基于图6所示的实施例中，可选的，第一业务系统调用第二业务系统执行与业务请求ID对应的外部业务步骤；处理日志为第二处理日志，第二处理日志用于记录第一业务系统在调用第二业务系统执行与业务请求ID对应的外部业务步骤的执行结果。则作为另一种可能的实现方式，步骤602至步骤603可以替换实现为如下步骤801至步骤805，如图8所示：步骤801，日志系统获取与业务请求ID对应的业务流程模型，业务流程模型包括：与业务请求ID对应的各个业务步骤的执行顺序。在业务请求执行失败时，日志系统获取与业务请求ID对应的业务流程模型。第一业务系统调用第二业务系统在执行与业务请求ID对应的外部业务步骤时，需要按照预定的执行顺序执行整个业务请求ID对应的外部业务步骤，比如：如图9所示，执行业务请求81时，总共需要6个业务系统共同完成分别为业务系统91、业务系统92、业务系统93、业务系统94、业务系统95和业务系统96；共需要执行7个业务步骤，分别为业务步骤1、业务步骤2、业务步骤3、业务步骤4、业务步骤5、业务步骤6和业务步骤7；业务系统91先通过x模块执行业务步骤1、业务步骤2和业务步骤3；再通过y模块执行业务步骤4、业务步骤5和业务步骤6；最后通过z模块执行业务步骤7。其中，业务系统91通过x模块执行业务步骤1时需要通过2-1API调用业务系统92来完成；业务步骤92通过w模块执行业务步骤1时需要通过2-2API调用业务系统93来完成；业务系统91在执行业务步骤2时需要通过3-1API调用业务系统93来完成；业务系统91通过y模块执行业务步骤4时系统通过4-1API调用业务系统94来完成；业务系统91通过y模块执行业务步骤5时系统通过5-1API调用业务系统95来完成；业务系统91通过y模块执行业务步骤6时系统通过6-1API调用业务系统96来完成。则示例性的，执行业务请求81对应的业务流程模型如下表一所示：表二该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤802，日志系统根据执行顺序依次获取与各个业务步骤对应的m个第二处理日志，m为正整数。日志系统在获取到业务流程模型后，根据业务流程模型中的执行顺序从接收到的处理日志中，获取与各个业务步骤对应的m个第二处理日志。可选的，第二处理日志是在被调用的第二业务系统执行与业务请求ID对应的外部业务步骤时对应的执行结果。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤803，日志系统根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤。可选的，第二处理日志中的执行结果包括：执行成功或执行失败；异常业务步骤为执行结果为执行失败对应的业务步骤。当第二处理日志中的执行结果为执行失败时，日志系统确定该第二处理日志对应的外部业务步骤为异常业务步骤。比如：第二处理日志1、第二处理日志2和第二处理日志3中第二处理日志2中的执行结果为执行失败，则日志系统根据第二处理日志2中的执行结果确定外部业务步骤2为异常业务步骤。可选的，本步骤可以通过如下可能的实现方式实现：第一步，根据第j个第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，j为小于等于m的正整数。可选的，j的初始值为1。日志系统从第1个第二处理日志开始，根据第1个第二处理日志的执行结果确定对应的外部业务步骤是否为异常业务步骤。第二步，若不是异常业务步骤，则令j＝j+1，继续根据第j个第二处理日志中的执行结果确定对应的外部业务步骤是否为异常业务步骤。通过上述两个步骤的循环，直至确定到异常业务步骤为止，否则对m个第二处理日志中的执行结果依次进行确定。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤804，在外部业务步骤是异常业务步骤时，日志系统将被调用的第二业务系统定位为故障业务系统。当日志系统确定第j个第二处理日志中对应的外部业务步骤是异常业务步骤时，则日志系统将执行该外部业务步骤的第二业务系统定位为故障业务系统。比如：日志系统确定第2个第二处理日志中对应的外部业务步骤2为异常业务步骤，则日志系统将被调用执行外部业务步骤2的第二业务系统A1确定为故障业务系统。可选的，第一业务系统包括：具有第一API的第一处理模块，第一API具有对应的第一API标识；第二业务系统包括：具有第二API的第二处理模块，第二API具有对应的第二API标识；第二处理日志包括：业务请求ID、第一业务系统ID、第一API标识、第二业务系统ID、第二API标识和返回码，结果码是指在调用第二处理模块执行外部业务步骤的执行结果。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块523来实现。步骤805，在故障业务系统为第二业务系统时，日志系统根据第二处理日志中包含的第二API标识，将第二API标识对应的API定位为故障API。日志系统在根据第二处理日志中携带的返回码确定出被调用的第二业务系统为故障业务系统后，将第二处理日志中包含的第二API标识对应的API确定为故障API。比如：第二业务系统B1包括第二处理模块a1和第二处理模块b1；第二处理模块a1的第二API标识为API21，第二处理模块b的第二API标识为API22；调用第二业务系统B1执行业务请求82时，总共需要执行2个外部业务步骤，分别为外部业务步骤1和外部业务步骤2；先通过第二处理模块a1执行外部业务步骤1；再通过第二处理模块b1执行外部业务步骤2；当日志系统根据第二处理日志中的返回码确定第二业务系统B1为故障业务系统时，根据第二处理日志中携带的API22确定API22对应的API为故障API。可选的，故障API对应的第二处理模块b1为故障处理模块。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块523来实现。综上所述，本实施例提供的故障定位方法，通过第一业务系统和第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。另外，日志系统根据业务流程模型中的执行顺序依次根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，有利于按照执行业务步骤的先后顺序依次确定异常业务步骤，有利于避免资源浪费，提高对故障业务系统的定位效率的效果。同时，在故障业务系统为第二业务系统时，日志系统根据第二处理日志中携带的第二API标识，确定第二API标识对应的API为故障API，通过在第二处理日志中携带有第二API标识，以便日志系统可以根据API标识定位出故障API，提高了对故障业务系统的定位的准确性的效果。请参考图10，其示出了本发明另一个实施例提供的故障定位方法的方法流程图。本实施例以该故障定位方法应用于图3所示的故障定位系统中来举例说明。可选的，日志系统包括：分析组件、建模组件、ID处理组件和日志组件；该故障定位方法包括以下步骤：步骤1001，分析组件接收待分析的业务请求ID。在业务请求执行失败时，分析组件接收输入的待分析的业务请求ID。该步骤可以由图5所示的日志系统140中的处理器511执行接收模块521来实现。步骤1002，分析组件通过ID处理组件获取与业务请求ID对应的业务流程模型ID。分析组件向ID处理组件发送携带有业务请求ID的流程ID请求。该流程ID请求用于向ID处理组件请求与业务请求ID对应的业务流程模型ID。ID处理组件接收到流程ID请求后，根据流程ID请求中携带的业务请求ID，查询与业务请求ID对应的业务流程模型ID；将查询的到业务流程模型ID反馈给分析组件。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤1003，分析组件通过建模组件获取与业务请求ID对应的业务流程模型。分析组件向建模组件发送携带有业务流程模型ID的模型请求。模型请求用于向建模组件请求反馈与业务流程模型ID对应的业务流程模型。建模组件接收到模型请求后，根据模型请求中携带的业务流程模型ID查询与业务流程模型ID对应的业务流程模型，并将查询到的业务流程模型反馈给分析组件。业务流程模型的详细描述请参考图7所示的步骤701和图所示的步骤801，此处不再赘述。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤1004，分析组件通过日志组件获取与业务请求ID对应的处理日志。分析组件在获取到业务流程模型后，向日志组件发送日志获取请求，该日志获取请求用于请求日志组件反馈与业务请求ID对应的处理日志；可选的，处理日志包括：第一处理日志和第二处理日志。关于第一处理日志的详细描述请参考图7所示的步骤702，关于第二处理日志的详细描述请参考图8所示的步骤802，此处不再赘述。日志组件接收到日志获取请求后，获取日志获取请求中携带的业务请求ID，根据业务请求ID查询与业务请求ID对应的第一处理日志和第二处理日志；并将查询到的与业务请求ID对应的n个第一处理日志和m个第二处理日志反馈给分析组件。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤1005，分析组件根据第i个第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤。可选的，分析组件按照业务流程模型中的执行顺序依次根据第i个第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤，其中，i为小于等于n的正整数。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤1006，若不是异常业务步骤，则分析组件令i＝i+1，继续根据第i个第一处理日志中的执行结果确定对应的内部业务步骤是否为异常业务步骤。通过步骤1005和步骤1006的循环，直至确定到异常业务步骤为止，否则对n个第一处理日志中的执行结果依次进行确定。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤1007，若是异常业务步骤，则分析组件从m个第二处理日志中，获取与执行异常业务步骤的第一处理模块对应的t个第二处理日志。若内部业务步骤是异常业务步骤，则分析组件将执行该内部业务步骤的第一处理模块确定为故障模块，由于第一处理模块存在调用其他业务系统完成业务步骤的可能，因此，分析组件获取与第一处理模块对应的t个第二处理日志。该步骤可以由图5所示的日志系统140中的处理器511执行获取模块524来实现。步骤1008，分析组件根据第j个第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤。可选的，分析组件按照业务流程模型中的执行顺序依次根据第j个第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤，其中，j为小于等于t的正整数。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤1009，若不是异常业务步骤，则分析组件令j＝j+1，继续根据第j个第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤。通过步骤1008和步骤1009的循环，直至确定到异常业务步骤为止，否则对t个第二处理日志中的执行结果依次进行确定。该步骤可以由图5所示的日志系统140中的处理器511执行确定模块522来实现。步骤1010，若是异常业务步骤，则分析组件将被调用的第二业务系统中第二API标识对应的API定位为故障API。若外部业务步骤是异常业务步骤，则分析组件将执行该外部业务步骤的第二处理模块对应的第二API标识对应的API定位为故障API。本步骤的详细描述请参考图8所示的步骤805，此处不再赘述。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块524来实现。步骤1011，若不存在与第一处理模块对应的第二处理日志，则分析组件将第一处理模块的第一API标识对应的API定位为故障API。分析组件在第i个第一处理日志中的执行结果确定内部业务步骤是异常业务步骤时，分析组件确定执行该内部业务步骤的第一处理模块为故障模块，若m个第二处理日志中不存在与第一处理模块对应的第二处理日志时，则分析组件将第一处理模块中第一API标识对应的API定位为故障API；或者，在分析组件确定出与第一处理模块对应的t个第二处理日志中的执行结果中外部业务步骤都不是异常业务步骤时，分析组件将第一处理模块中第一API标识对应的API定位为故障API。该步骤可以由图5所示的日志系统140中的处理器511执行定位模块524来实现。综上所述，本实施例提供的故障定位方法，通过第一业务系统和第二业务系统在执行与业务请求ID对应的业务步骤时，第一业务系统向日志系统发送对应的处理日志，日志系统根据接收到的处理日志中的执行结果确定异常业务步骤，最终定位出故障业务系统；由于第一业务系统为每个业务步骤都生成一个处理日志，使得日志系统根据处理日志中的执行结果可以确定出具体的故障业务系统，解决了现有技术中需要通过从上之下依次排查各个业务系统，最终确定出故障业务系统，当业务系统的个数较多时，导致对故障业务系统的定位效率较低的问题，达到了通过与业务请求ID对应的处理日志定位故障业务系统，提高了对故障业务系统的定位效率的效果。需要补充说明的是，本实施例中仅以先根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤后，再根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤为例进行说明，对第一处理日志和第二处理日志的先后顺序并不做具体限定。可选的，可以先根据第二处理日志中的执行结果确定外部业务步骤是否为异常业务步骤后，再根据第一处理日志中的执行结果确定内部业务步骤是否为异常业务步骤。下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。请参考图11，其示出了本发明一个实施例提供的故障定位装置的结构框图，该故障定位装置可以通过软件、硬件或者两者的结合实现为图2或图3所示的日志系统140中的全部或者部分。该故障定位装置可以包括：接收单元1120，具有与接收模块521相同或相似的功能，以及由接收模块521包含的其它隐含功能。确定单元1140，具有与确定模块522相同或相似的功能，以及由确定模块522包含的其它隐含功能。定位单元1160，具有与定位模块523相同或相似的功能，以及由定位模块523包含的其它隐含功能。获取单元1180，具有与获取模块524相同或相似的功能，以及由获取模块524包含的其它隐含功能。应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”(“a”、“an”、“the”)旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。当前第1页1 2 3