CN105721187B - 一种业务故障诊断方法及装置 - Google Patents

Abstract

本发明公开了一种业务故障诊断方法及装置，主要技术方案包括：根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。采用该技术方案，能够解决现有技术中存在处理故障的周期太长的问题。

Description

一种业务故障诊断方法及装置

技术领域

本发明涉及互联网信息处理技术领域，更具体的涉及一种业务故障诊断方法及装置。

背景技术

为了解真实用户感知，定位业务故障，业内普遍使用主动探测结合被动探测的方法来捕捉终端用户的交易信息，进而分析导致用户体验障碍的根源，以实现精确管理。

目前业务监控的分析一般只是判断单笔交易的结果是成功还是失败，或者是交易是否超时，缺乏对业务环节的监控，缺乏从大数据量的业务指标中挖掘问题的办法，通常故障问题都是在用户投诉后才发现的。

综上所述，现有技术中存在处理故障的周期太长的问题。

发明内容

本发明实施例提供一种业务故障诊断方法及装置，用以解决现有技术中存在处理故障的周期太长的问题。

本发明实施例提供一种业务故障诊断方法，包括：

根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间 段的修正阈值得到的。

较佳地，所述根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析，包括：

所述各业务环节的时间段日志数据包括以下至少之一：该业务环节对应的请求时间、响应时间、交易地点、交易结果、交易步骤、办理业务的用户信息；

所述业务分析模型为故障率统计模型，通过所述交易结果获知所述时间段的故障交易业务发生的次数或频率；和/或

所述业务分析模型为调用链分析模型，通过所述交易步骤获知所述时间段的交易业务的操作路径；和/或

所述业务分析模型为用户在线分析模型，通过所述交易请求时间、交易响应时间获取所述时间段各个环节的响应时长和页面停留时间占比；和/或

所述业务分析模型为漏斗分析模型，通过所述交易记录的访问量、中断办理量获取所述时间段业务的使用状况及每个环节的访问量。

较佳地，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的，具体为：

根据所述时间段的前一时间段的修正阈值，及所述时间段的前一时间段的业务指标与上月或上周相应时间段的业务指标的比值，确定所述时间段的修正阈值。

较佳地，根据所述业务分析模型时间段输出的业务指标与修正阈值的关系，确定所述日志消息是否存在异常，包括：

将所述业务分析模型时间段输出的业务指标与所述输出的业务指标相对应的修正阈值进行比较；

若所述输出的业务指标值大于所述输出的业务指标相对应的修正阈值，则确定所述输出的业务指标对应的日志消息存在异常。

较佳地，呼叫记录监视系统CRM和/或电信业务运营支持系统BOSS记录前台日志消息及后台日志消息，根据所述前台日志消息和所述后台日志消息记 录的业务内容，建立业务流程模型；

所述业务流程模型中节点与所述业务内容中的环节相对应，其中，所述业务内容中的环节包括前台操作环节和后台服务环节。

较佳地，根据所述业务分析模型时间段输出的业务指标与修正阈值的关系，确定所述日志消息是否存在异常之后，还包括：

根据所述输出的业务指标对应的日志消息，确定所述日志消息产生告警的业务环节。

本发明实施例提供一种业务故障诊断装置，包括：

建立模型单元，用于根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

模型分析单元，用于根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

判断单元，用于将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。

较佳地，所述模型分析单元具体用于：

所述各业务环节的时间段日志数据包括以下至少之一：该业务环节对应的请求时间、响应时间、交易地点、交易结果、交易步骤、办理业务的用户信息；

所述业务分析模型为故障率统计模型，通过所述交易结果获知所述时间段的故障交易业务发生的次数或频率；和/或

所述业务分析模型为调用链分析模型，通过所述交易步骤获知所述时间段的交易业务的操作路径；和/或

所述业务分析模型为用户在线分析模型，通过所述交易请求时间、交易响应时间获取所述时间段各个环节的响应时长和页面停留时间占比；和/或

所述业务分析模型为漏斗分析模型，通过所述交易记录的访问量、中断办理量获取所述时间段业务的使用状况及每个环节的访问量。

较佳地，所述判断单元具体用于：

将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。

较佳地，所述建立模型单元具体用于：

呼叫记录监视系统CRM和/或电信业务运营支持系统BOSS记录前台日志消息及后台日志消息，根据所述前台日志消息和所述后台日志消息记录的业务内容，建立业务流程模型；

所述业务流程模型中节点与所述业务内容中的环节相对应，其中，所述业务内容中的环节包括前台操作环节和后台服务环节。

较佳地，所述判断单元具体用于：

将所述业务分析模型时间段输出的业务指标与所述输出的业务指标相对应的修正阈值进行比较；

若所述输出的业务指标值大于所述输出的业务指标相对应的修正阈值，则确定所述输出的业务指标对应的日志消息存在异常。

较佳地，所述判断单元具体还用于：

根据所述输出的业务指标对应的日志消息，确定所述日志消息产生告警的业务环节。

本发明实施例根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。采用该方法通过业务分析模型来统计周期内的业务指标，根据修正阈值值与所述周期内的业务指标的关系，能够有效的自动预警，并且产生告警，解决现有技术中存在处理故障的周期太长的问题。

附图说明

图1为本发明实施例一提供的一种业务故障诊断方法流程图；

图2为本发明实施例提供的建立业务环节示意图；

图3为本发明实施例提供的调用链分析模型处理流程图；

图4为本发明实施例提供的用户在线分析模型处理流程图；

图5为本发明实施例提供的业务管理分析模型处理流程图；

图6为本发明实施例二提供的一种业务故障诊断装置示意图。

具体实施方式

本发明实施例根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。采用该方法通过业务分析模型来统计周期内的业务指标，根据修正阈值值与所述周期内的业务指标的关系，能够有效的自动预警，并且产生告警，解决现有技术中存在处理故障的周期太长的问题。

为了使本发明所解决的技术问题、技术方案及有益效果更加清楚明白，以下结合附图及实施例对本发明的优选实施例进行说明。应该理解，此处所描述的优选实施例仅仅用以说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

本发明实施例中，主要是对BOSS(Business&Operation Support System,电信业务运营支持系统)、CRM(Call Recording Monitor,呼叫记录监视器)系统核心业务的日志采集及监控分析。其中，日志中主要包括交易发起的渠道、地市、 请求时间、响应时间、交易结果等等信息，并支持日志按以下维度输出：

支持交易日志输出；

支持服务请求日志输出；

支持服务响应日志输出；

支持业务步骤日志输出；

支持按业务、地市、操作员ID(identity，身份标识号码)来控制日志输出；

实施例一

如图1所示，本发明实施例提供一种业务故障诊断方法，包括如下步骤：

步骤101，根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

步骤102，根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

步骤103，将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。

在步骤101中，采集的日志主要包括BOSS、CRM系统核心业务，其中，CRM、BOSS侧记录前台操作关键步骤的日志，其中，关键步骤日志包括操作时间长度、业务操作路径、页面响应时间长度等信息；后台服务环节主要包括后台服务调用日志、跨平台交互的日志等信息。CRM、BOSS记录了每笔交易的业务、步骤、渠道、地市、请求时间、响应时间、交易结果等等信息；CRM侧通过UDP(User Datagram Protocol,用户数据报协议)方式发送日志消息给日志采集服务端。

日志采集服务端通过监听指定UPD端口接收业务日志消息，并将日志消息保存为日志文件；

日志预处理程序实时扫描新的日志文件，读取日志文件对日志消息进行过滤和预处理，将日志消息按业务、步骤、地市等维度进行分类汇总并入库。

日志采集服务端通过梳理CRM/BOSS系统的核心业务，在系统中建立业务流程模型，流程中的每个节点表示业务的一个环节，包括业务前台操作环节和后台服务调用环节等等；如图2所示，定义产品变更包括六个环节。

在步骤102中，根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

本发明实施例中，根据所述各业务环节的时间段日志数据及业务分析模型进行时间段业务指标分析，其中，业务分析模型主要包括下列几种模型：

模型一、故障率统计模型：

故障率统计模型主要是根据日志消息中记录的交易业务，在设定的时间段统计所述日志消息中交易业务的故障发生次数与频率；

根据交易业务的故障发生次数与频率作为故障判定依据，统计影响业务可用性的相关指标，实现对所有业务故障类型覆盖监控。

其中，故障率统计模型中主要的关键算法如下：

故障量：主要是统计周期内的失败交易量，其中故障量按照公式(1)确定：

公式(1)

故障率：主要是统计周期内的失败交易量占业务交易总量的占比，其中故障率按照公式(2)确定：

公式(2)

故障率同比：主要是统计当前周期的故障率的周同比、月同比，分析变换趋势，其中故障率同比按照公式(3)确定：

公式(3)

故障率环比：主要是统计当前周期的故障率与上个周期的故障率的变化；其中故障率环比按照公式(4)确定：

公式(4)

模型二、调用链分析模型：

调用链分析模型主要是根据所述日志消息中记录的交易步骤，按照时间段统计所述日志消息中交易步骤中调用链数据。

根据时间段所述日志消息中的交易步骤，确定操作的最佳路径，优化业务体验。

其中，调用链分析模型的关键算法如图3所示：

比如，以客户产品变更为例，由于营业员办理业务时操作路径不同，通过业务环节日志统计所有调用链组合及其占比，进而分析出最佳路径。(例如：主推产品用的频率较少是否是因为主推产品更新频率低，与地市近期业务发展不匹配，根据分析结果考虑取消该功能或者提高更新频率)。

模型三、用户在线分析模型：

用户在线分析模型主要是通过所述日志消息中记录的交易请求时间、交易响应时间、交易结束时间，按照时间段统计所述日志消息中每个环节的系统响应时间和页面停留时间比例。

其中，用户在线分析模型关键算法如图4所示：根据业务环节日志，统计操作过程中环节间的页面停留时长，页面停留时长反映了业务办理过程中人为占用时间，这样通过分析每一个环节的页面响应时长和页面停留时长占比，分析出影响业务办理的瓶颈所在。

模型四、漏斗模型：

漏斗模型主要是根据所述日志消息中记录的访问量、中断办理量，按照时间段统计业务的使用状况及每个环节的访问量。

通过定制的交易漏斗，观察业务的使用状况和每个环节的访问量，分析出在哪个环节跳出率最高，从而改善业务操作。

其中，漏斗模型的关键算法：假设以产品变更为例，统计每个环节的访问量、跳出量，并计算环节跳出率，通过漏斗模型分析在哪一个环节跳出率较高， 进而找出业务瓶颈进行改进优化。

模型五、业务关联分析模型：

业务关联分析模型主要是根据所述日志消息中记录的交易渠道，按照时间段统计所述日志消息中常用业务组合。

业务关联分析模型通过对用户行为轨迹进行分析，基本上可以确定用户的核心需求，进而可以了解哪几个业务经常关联办理，从而整合业务优化业务体验。

其中，业务关联分析模型关键算法如图5所示：统计出各手机号码在各渠道一段时间内办理的业务功能，形成所有用户的业务关联关系实例。比如，使用业务关联关系实例抽象出特征码(业务组合)，作为分析的要素。在系统范围内采集形成业务关联关系特征码库，作为分析依据。系统可以为业务分析人员提供特征码分析结果，为业务流程改进决策提供依据。

本发明实施例根据采集到BOSS、CRM系统核心业务中的日志信息，可以根据需要确定的指标，从业务分析模型中选择一个业务分析模型确定需要的输出指标，可以选择多个业务分析模型确定需要的不同的输出指标，也可以选择五个业务分析模型同时对采集的日志信息进行分析，本发明实施例对具体选择哪个业务分析模型，或者选择多个业务分析模型不做限定。

比如，需要选择上述5个业务分析模型对采集的日志消息进行分析，其中，具体的分析过程及分析结果如表一所示：

表一 模型分析过程及输出结果

其中，从采集的日志消息中输入的指标包括：失败量、交易量、环节调用链组合、调用链调用次数、业务组合特征码(与产品变更相关的不同业务组合)、环节请求时间、环节响应时间、环节访问量和环节跳出量；相应的经过各个业务分析模型之后输出的指标包括：故障量、故障率、调用链组合占比、业务组合出镜数、业务组合出镜率、页面停留时长和环节跳出率。

本发明实施例中，根据对日志信息的业务分析之后输出的指标，可以对其中影响业务的指标进行异常分析，其中，异常分析主要是判断输出指标中业务异常因子分析，异常因子分析结果包括正常和异常。

其中，异常因子可以对业务或业务的环节配置使用哪些异常因子来分析，实现对不同应用场景的异常分析。如使用故障率异常因子来分析可用性异常，使用超时率异常因子来分析快捷性异常，从而根据异常分析结果来判断当前周期的是否存在异常。

本发明实施例主要的异常因子包括表二中所示的异常因子，但是不限于表二中示出的异常因子：

表二 异常因子

步骤103，根据所述业务分析模型输出的业务指标与修正阈值的关系，确定所述日志消息是否存在异常。

本发明实施例中，以故障率异常因子，采用故障率分析模型，统计出业务或业务环节的失败量和失败率等指标，并通过异常因子的规则，如判断失败量是否超过阀值且失败率是否超过阀值，如果都超过阀值则判定当前业务存在异常。

进一步地，本发明实施例综合运用三种业务分析模型统计出业务环节的输出指标，然后根据异常因子规则判断不同环节的指标的差异率是否超过阈值，从而可以判断采集到的日志消息是否出现了异常。

本发明实施例中，修正阈值值的确定包括下列方法：

第一种方法，根据所述输出的业务指标的上月同时间段的修正阈值，通过各种计算方法，得出一个指标基准值作为基础阀值；在将所述时间段的前一时间段的业务指标与上月上一时间段的业务指标的平均值的比值作为趋势系数，最后通过趋势系数对基础阈值进行修正，即得到所述时间段的业务指标的修正阈值。

第二种方法，根据所述输出的业务指标的上月同时间段的修正阈值，通过各种计算方法，得出一个指标基准值作为基础阀值；在将所述时间段的前一时间段的业务指标与上周上一时间段的业务指标的平均值的比值作为趋势系数，最后通过趋势系数对基础阈值进行修正，即得到所述时间段的业务指标的修正阈值。

第三种方法，根据所述输出的业务指标的上周同时间段的修正阈值，通过各种计算方法，得出一个指标基准值作为基础阀值；在将所述时间段的前一时间段的业务指标与上周上一时间段的业务指标的平均值的比值作为趋势系数，最后通过趋势系数对基础阈值进行修正，即得到所述时间段的业务指标的修正阈值。

第四种方法，根据所述输出的业务指标的上周同时间段的修正阈值，通过各种计算方法，得出一个指标基准值作为基础阀值；在将所述时间段的前一时间段的业务指标与上月上一时间段的业务指标的平均值的比值作为趋势系数，最后通过趋势系数对基础阈值进行修正，即得到所述时间段的业务指标的修正阈值。

本发明实施例中，修正阈值可以采用上述任一一种方法确定，本发明实施对对修正阈值的确定方法不做具体限定。

在本发明实施例中，确定修正阈值中采用的各种算法包括：同期90P、平均值、峰值、谷值等。其中，表三中根据不同类别的指标阈值，分别给出了具体的计算方法：

表三 不同类别的指标阈值表

其中，表三中涉及的算法主要包括：

同期90P：取上月同一天同一时间段所有采样参数中90％的数值范围上限；或者，

取上周同一天同一时间段所有采样参数中90％的数值范围上限。

同期平均值乘系数：取上月同一天同一时间段内所有采样参数的平均值乘以系数作为阀值，系数根据实际效果进行调整；或者，

取上周同一天同一时间段内所有采样参数的平均值乘以系数作为阀值，系数根据实际效果进行调整。

同期上限：取上月同一天同一时间段所有采样参数的上限值；或者，

取上周同一天同一时间段所有采样参数的上限值。

同期下限：取上月同一天同一时间段所有采样参数的下限值；或者，

取上周同一天同一时间段所有采样参数的下限值。

趋势修正：取当天前一时间段的平均值与上月同一天前一时间段的平均值的比值作为系数，对阀值进行修正，以适应各种情况对指标值造成的趋势变化；或者，

取当天前一时间段的平均值与上周同一天前一时间段的平均值的比值作为系数，对阀值进行修正，以适应各种情况对指标值造成的趋势变化。

本发明实施例中，确定所述业务模型输出指标中影响业务的输出指标；将所述影响业务的输出指标与确定的修正阈值进行比较，若所述影响业务的输出指标大于所述修正阈值，则确定所述日志消息是否存在异常。

其中，主要的判断方法根据表四所示：

表四 故障率统计模型统计过程

根据表四所示，分别能够确定采集到的日志消息中输出指标与修正阈值值之前的关系，若输出指标大于修正阈值值，则可以确定所述输出指标对应的日志消息存在异常，对所述产生异常的输出消息对应的日志消息进行告警。

若输出指标不大于修正阈值值，则可以确定所述输出指标对应的日志消息没有产生异常，则对所述日志消息继续监控。

本发明实施例对采集到的日志消息进行解析，根据解析结果将所述日志消息进行分类；根据所述日志消息的分类结果，将所述分类后的日志消息分别按照业务分析模型在设定周期内进行分析；根据所述业务分析模型在周期内统计出的业务指标，与修正阈值值的关系，确定所述日志消息是否存在异常；若所述日志消息存在异常，则产生告警。采用该方法通过业务分析模型来统计周期内的业务指标，根据修正阈值值与所述周期内的业务指标的关系，能够有效的自动预警，并且产生告警，解决现有技术中存在处理故障的周期太长的问题。

实施例二

为了更好地理解本发明实施例一提供的技术方案，下面以产品变更的统计分析过程为例，具体的说明本发明一种业务故障诊断方法。

步骤201，设置产品变更业务的分析周期15分钟，即每隔15分钟对产品变更进行一次异常分析，默认对15分钟内的日志数据进行分析。

如下是对6月11日19:30的产品变更日志数据进行的汇总统计，得出如表五所示的基础指标：

业务	地市	时间	成功量	失败量	交易总量
						产品变更	南京	19:30	455	68	523

表五 基础指标

步骤202，查询产品变更业务关联的分析模型，通过本发明实施例一中设置了故障率统计模型和漏斗模型，则产品变更会依次使用关联的分析模型进行分析，得出相应的指标，具体如表六所示的故障率统计模型的输出指标：

表六 故障率统计模型输出指标

步骤203，根据表七，根据确定的故障量和故障率指标，确定修正阈值。

表七 确定修正阈值

根据表五所示，可以确定6月11日19:30产品变更的故障量是68，而根据表七可以确定故障量的修正阈值是7，同时，表五中故障率为12.750％，而表七中故障率的修正阈值是2％；从而可以确定产品变更当前时段存在异常情况，所以系统产生告警。

在本发明实施例中，步骤201～至步骤203完成了根据故障率通模型对产品变更业务的统计分析，然后依次使用产品变更关联的其他分析模型对产品变更及其环节进行分析，直到完成所有关联模型的统计分析。

在本发明实施例中，由于产生了告警，所以需要对产生异常的系统进行定位。具体如下：

其中，表八显示了周期内所有的产品变更业务：

表八 周期内所有产品变更业务表

表八中有一个明细栏，可以点击每个产品变更的明细，查看每一笔异常交易的详细信息，其中包括错误原因。

表九中显示了明细的详细信息：

表九 交易详单

进一步地，可以根据表九中的交易流水号，继续查看该交易的详细步骤，从而可以根据详细步骤定位问题在哪个环节出现异常。

表十中详细的显示了交易环节中具体出现异常的环节：

表十 显示交易故障环节

本发明实施例，通过上述过程，不仅实现了对业务的实时监控，并通过业务分析模型对业务发展情况进行了有效分析，智能阀值功能更是帮助摆脱目前告警阀值全部依赖人工配置的模式，从而更有效的对业务进行监控分析。

基于同一发明构思，本发明实施例提供了一种业务故障诊断装置，由于该装置解决技术问题的原理与一种业务故障诊断方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

实施例三

本发明实施例三提供了一种业务故障诊断装置，如图6所示，该设备包括建立模型单元21、模型分析单元22和判断单元23。

建立模型单元21，用于根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

模型分析单元22，用于根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；判断单元23，

用于将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。

较佳地，所述建立模型单元21具体用于：

所述各业务环节的时间段日志数据包括以下至少之一：该业务环节对应的请求时间、响应时间、交易地点、交易结果、交易步骤、办理业务的用户信息；

所述业务分析模型为故障率统计模型，通过所述交易结果获知所述时间段的故障交易业务发生的次数或频率；和/或

所述业务分析模型为调用链分析模型，通过所述交易步骤获知所述时间段的交易业务的操作路径；和/或

所述业务分析模型为用户在线分析模型，通过所述交易请求时间、交易响应时间获取所述时间段各个环节的响应时长和页面停留时间占比；和/或

所述业务分析模型为漏斗分析模型，通过所述交易记录的较佳地，所述判断单元23具体用于：

将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是基于所述时间段的前一时间段的修正阈值得到的。

较佳地，所述建立模型单元21具体用于：

呼叫记录监视系统CRM和/或电信业务运营支持系统BOSS记录前台日志消息及后台日志消息，根据所述前台日志消息和所述后台日志消息记录的业务内容，建立业务流程模型；

所述业务流程模型中节点与所述业务内容中的环节相对应，其中，所述业务内容中的环节包括前台操作环节和后台服务环节。

较佳地，所述判断单元23具体用于：

将所述业务分析模型时间段输出的业务指标与所述输出的业务指标相对应的修正阈值进行比较；

若所述输出的业务指标值大于所述输出的业务指标相对应的修正阈值，则确定所述输出的业务指标对应的日志消息存在异常。

较佳地，所述判断单元23具体还用于：

根据所述输出的业务指标对应的日志消息，确定所述日志消息产生告警的 业务环节。

应当理解，以上一种业务故障诊断装置包括的单元仅为根据该系统实现的功能进行的逻辑划分，实际应用中，可以进行上述单元的叠加或拆分。并且该实施例提供的业务故障诊断装置所实现的功能与上述实施例提供的业务故障诊断方法一一对应，对于该设备所实现的更为详细的处理流程，在上述方法实施例一中已做详细描述，此处不再详细描述。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种业务故障诊断方法，其特征在于，包括：

根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，其中，所述时间段的修正阈值是根据所述时间段的前一时间段的修正阈值，及所述时间段的前一时间段的业务指标与上月或上周相应时间段的业务指标的比值确定的。

2.如权利要求1所述方法，其特征在于，所述根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析，包括：

所述各业务环节的时间段日志数据包括以下至少之一：该业务环节对应的交易请求时间、交易响应时间、交易地点、交易结果、交易步骤、办理业务的用户信息；

所述业务分析模型为故障率统计模型，通过所述交易结果获知所述时间段的故障交易业务发生的次数或频率；和/或

所述业务分析模型为调用链分析模型，通过所述交易步骤获知所述时间段的交易业务的操作路径；和/或

所述业务分析模型为用户在线分析模型，通过所述交易请求时间、交易响应时间获取所述时间段各个环节的响应时长和页面停留时间占比；和/或

所述业务分析模型为漏斗分析模型，通过所述交易记录的访问量、中断办理量获取所述时间段业务的使用状况及每个环节的访问量。

3.如权利要求1所述方法，其特征在于，所述根据采集的日志消息建立业务流程模型，包括：

呼叫记录监视系统CRM和/或电信业务运营支持系统BOSS记录前台日志消息及后台日志消息，根据所述前台日志消息和所述后台日志消息记录的业务内容，建立业务流程模型；

所述业务流程模型中节点与所述业务内容中的环节相对应，其中，所述业务内容中的环节包括前台操作环节和后台服务环节。

4.如权利要求1所述方法，其特征在于，根据所述业务分析模型时间段输出的业务指标与修正阈值的关系，确定所述日志消息是否存在异常，包括：

将所述业务分析模型时间段输出的业务指标与所述输出的业务指标相对应的修正阈值进行比较；

若所述输出的业务指标值大于所述输出的业务指标相对应的修正阈值，则确定所述输出的业务指标对应的日志消息存在异常。

5.如权利要求4所述方法，其特征在于，根据所述业务分析模型时间段输出的业务指标与修正阈值的关系，确定所述日志消息是否存在异常之后，还包括：

根据所述输出的业务指标对应的日志消息，确定所述日志消息产生告警的业务环节。

6.一种业务故障诊断装置，其特征在于，包括：

建立模型单元，用于根据采集的日志消息建立业务流程模型，获取所述业务流程模型中各业务环节的时间段日志数据；

模型分析单元，用于根据业务分析模型及所述各业务环节的时间段日志数据进行时间段业务指标分析；

判断单元，用于将得到的时间段业务指标与所述时间段的修正阈值进行比较，确定所述业务是否存在故障，所述时间段的修正阈值是根据所述时间段的前一时间段的修正阈值，及所述时间段的前一时间段的业务指标与上月或上周相应时间段的业务指标的比值确定的。

7.如权利要求6所述装置，其特征在于，所述模型分析单元具体用于：

所述各业务环节的时间段日志数据包括以下至少之一：该业务环节对应的交易请求时间、交易响应时间、交易地点、交易结果、交易步骤、办理业务的用户信息；

所述业务分析模型为故障率统计模型，通过所述交易结果获知所述时间段的故障交易业务发生的次数或频率；和/或

所述业务分析模型为调用链分析模型，通过所述交易步骤获知所述时间段的交易业务的操作路径；和/或

所述业务分析模型为用户在线分析模型，通过所述交易请求时间、交易响应时间获取所述时间段各个环节的响应时长和页面停留时间占比；和/或

所述业务分析模型为漏斗分析模型，通过所述交易记录的访问量、中断办理量获取所述时间段业务的使用状况及每个环节的访问量。

8.如权利要求6所述装置，其特征在于，所述建立模型单元具体用于：

呼叫记录监视系统CRM和/或电信业务运营支持系统BOSS记录前台日志消息及后台日志消息，根据所述前台日志消息和所述后台日志消息记录的业务内容，建立业务流程模型；

所述业务流程模型中节点与所述业务内容中的环节相对应，其中，所述业务内容中的环节包括前台操作环节和后台服务环节。

9.如权利要求6所述装置，其特征在于，所述判断单元具体用于：

将所述业务分析模型时间段输出的业务指标与所述输出的业务指标相对应的修正阈值进行比较；

若所述输出的业务指标值大于所述输出的业务指标相对应的修正阈值，则确定所述输出的业务指标对应的日志消息存在异常。

10.如权利要求9所述装置，其特征在于，所述判断单元具体还用于：

根据所述输出的业务指标对应的日志消息，确定所述日志消息产生告警的业务环节。