CN115834332A - 一种故障处理方法、服务器及*** - Google Patents

Abstract

本申请提供一种故障处理方法、服务器及***。该方法包括：根据获取到的故障查询请求，向快照数据服务器发送数据查询请求，以使快照数据服务器根据数据查询请求，查询到存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志时返回该数据；从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据；对获取到的网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。通过本申请提供的方法，可以迅速获得故障信息进而进行故障处理，能够缩短对待查询用户的故障业务进行故障分析的时间，提高故障处理的整体效率。

Description

一种故障处理方法、服务器及***

技术领域

本申请涉及通信技术，尤其涉及一种故障处理方法、服务器及***。

背景技术

随着5G独立组网(5G Standalone，简称：5G SA)的大规模商用，移动通信网络结构也进一步复杂化。在现有的这种复杂网络结构下，运营商若收到用户无法使用业务的投诉，往往需要派出专业的工作人员去查询、分析用户业务所涉及的各个网元签约数据，根据自身经验找出用户的具体业务故障点后再给出相应的解决方案。

然而，当前的网络结构下，用户业务涉及的网元可能分属不同的供应商，需要逐个登录不同***进行操作，人工查找、排除故障的效率低。

发明内容

本申请提供一种故障处理方法、服务器及***，用以解决现有技术中需要有经验的专业人员登录不同操作***查看并根据自身经验排查用户业务出现故障的原因而导致的故障处理效率低下的技术问题。

第一方面，本申请提供一种故障处理方法，包括：

获取故障查询请求，所述故障查询请求包括待查询用户的标识和待查询业务的标识；

根据所述故障查询请求，向快照数据服务器发送数据查询请求，以使所述快照数据服务器根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

从与所述待查询业务的标识对应的网元中，获取与所述待查询用户的标识对应的网元当前实时数据；

对所述网元当前实时数据、所述网元快照数据及变更日志进行分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

第二方面，本申请提供一种故障处理方法，包括：

接收应用服务器发送的数据查询请求，所述数据查询请求中包括：待查询用户的标识和待查询业务的标识；

根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

若存在，则将所述与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给所述应用服务器，以供所述应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

该方法还包括：

在获取到业务指令时，识别所述业务指令；其中，所述业务指令包括用户标识、对应的业务标识和业务信息；

当识别出所述业务指令为业务变更指令时，采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件；

若所述业务信息满足所述抓取快照数据的条件，且未查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取所述业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志；

或者，

若所述业务信息满足所述抓取快照数据的条件，且查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取并更新所述业务标识对应的业务在变更前的所述业务标识对应的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志。

该方法还包括：

若所述业务信息不满足所述抓取快照数据的条件，则记录根据所述业务变更指令进行业务处理所对应的变更日志。

在一种可能的实现方式中，所述采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件，包括：

采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果；

若所述业务结果大于或等于预设阈值，则所述业务信息满足抓取快照数据的条件；

若所述业务结果小于预设阈值，则所述业务信息不满足抓取快照数据的条件。

在一种可能的实现方式中，所述采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果，包括：

根据所述业务信息中的所述用户标识对应的用户等级W、所述用户标识对应的归属网络的复杂度X、所述业务变更指令与具体业务的相关度Y、所述业务标识所涉及的网元性能资源使用率Z及上次抓取所述用户标识对应的快照数据距离当前的时间t，采用所述预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E；

其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

第三方面，本申请提供一种应用服务器，包括：

第一收发模块，用于获取故障查询请求，所述故障查询请求包括待查询用户的标识和待查询业务的标识；

所述第一收发模块，还用于根据所述故障查询请求，向快照数据服务器发送数据查询请求，以使所述快照数据服务器根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

所述第一收发模块，还用于从与所述待查询业务的标识对应的网元中，获取与所述待查询用户的标识对应的网元当前实时数据；

故障处理模块，用于对所述网元当前实时数据、所述网元快照数据及变更日志进行分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

第四方面，一种快照数据服务器，包括：

第二收发模块，用于接收应用服务器发送的数据查询请求，所述数据查询请求中包括：待查询用户的标识和待查询业务的标识；

查询模块，根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

第二收发模块，用于若存在，则将所述与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给所述应用服务器，以供所述应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

该快照数据服务器还包括：

识别模块，用于在获取到业务指令时，识别所述业务指令；其中，所述业务指令包括用户标识、对应的业务标识和业务信息；

判断模块，用于当识别出所述业务指令为业务变更指令时，采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件；

快照数据抓取模块，用于若所述业务信息满足所述抓取快照数据的条件，且未查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取所述业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志；

所述快照数据抓取模块，还用于若所述业务信息满足所述抓取快照数据的条件，且查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取并更新所述业务标识对应的业务在变更前的所述业务标识对应的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志。

另外，可选的，所述快照数据抓取模块，还用于若所述业务信息不满足所述抓取快照数据的条件，则记录根据所述业务变更指令进行业务处理所对应的变更日志。

可选的，所述判断模块，具体用于：采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果；

若所述业务结果大于或等于预设阈值，则所述业务信息满足抓取快照数据的条件；

若所述业务结果小于预设阈值，则所述业务信息不满足抓取快照数据的条件。

可选的，所述判断模块，具体用于：根据所述业务信息中的所述用户标识对应的用户等级W、所述用户标识对应的归属网络的复杂度X、所述业务变更指令与具体业务的相关度Y、所述业务标识所涉及的网元性能资源使用率Z及上次抓取所述用户标识对应的快照数据距离当前的时间t，采用所述预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E；

其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

第五方面，本申请提供一种故障处理***，包括：客户端、网元、如第三方面所述的应用服务器以及如第四方面所述的快照数据服务器；其中，所述快照数据服务器与所述应用服务器独立配置或者集成配置。

本申请提供的一种故障处理方法、服务器及***，通过获取包括待查询用户的标识和待查询业务的标识的故障查询请求；并根据该故障查询请求，向快照数据服务器发送数据查询请求，以使快照数据服务器根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据；对获取到的网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。通过本申请提供的方法，可以在接到发生故障的待查询用户投诉的第一时间，根据获取到的来自投诉处理中心的客户端的故障查询请求，获取到与待查询用户的标识对应的网元当前实时数据、与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，并根据对获取到的数据的迅速分析得到故障信息进一步进行故障处理，从而能够有效地缩短对待查询用户的故障业务进行故障原因分析的时间，进而提高故障处理的整体效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的一种故障处理方法实施例一的流程示意图；

图2为本申请提供的一种故障处理方法实施例二的流程示意图；

图3为本申请提供的一种故障处理方法实施例三的流程示意图；

图4为本申请提供的一种故障处理方法实施例四的信令流程示意图；

图5为本申请提供的一种应用服务器实施例的结构示意图；

图6为本申请提供的一种快照数据服务器实施例的结构示意图；

图7为本申请提供的一种故障处理***实施例的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在根据本实施例的启示下作出的所有其他实施例，都属于本申请保护的范围。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

现有技术中，运营商在接到用户无法正常使用业务的投诉时，需要派出专业的网管人员查询该用户对应的网元签约数据，并依据经验判别故障原因后去尝试解决。但是由于网络结构逐渐复杂，一个移动网用户所涉及的网元设备可能由不同的厂家供应，各个网元有各自的数据查询客户端，网管人员在故障原因排查时需要分别登录不同的客户端逐一去查询、对比故障用户的数据，以求找到故障原因。而在负责排查的网管人员具有极强专业背景且经过相当长时间的实践培训的前提下，查询、分析一个用户的数据仍需要10-15分钟的时间。可见，现有技术中对于用户业务故障时的排查对工作人员要求高，且时效和准确度均无法保证，自动化程度低，效率低下。

本申请的技术构思在于：如何使得运营商在接到用户关于相关业务无法使用的投诉时，能够快速响应，迅速准确的定位故障原因，以提高故障处理效率。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图1为本申请提供的一种故障处理方法实施例一的流程示意图。参照图1，该方法包括：

步骤S101、获取故障查询请求，故障查询请求包括待查询用户的标识和待查询业务的标识。

在本实施例中，故障查询请求一般是运营商投诉处理中心的客户端在接收到用户关于某项业务无法使用的投诉时发送给应用服务器，该故障查询请求包括待查询用户的标识以及待查询业务的标识，待查询用户的标识可以是该用户的手机号码，待查询业务的标识可以是该用户无法使用的业务在运营商数据库中对应的业务编码。

步骤S102、根据故障查询请求，向快照数据服务器发送数据查询请求，以使快照数据服务器根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志。

在本实施例中，应用服务器首先应对获取到的故障查询请求进行鉴权，其目的在于对发起故障查询请求的客户端进行鉴权，防止没有权限的客户端访问用户网元数据。

在本实施例中，应用服务器根据获取到的故障查询请求中携带的待查询用户的标识和待查询业务的标识向快照数据服务器发送数据查询请求，以使得快照数据服务器根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若有，则将相应的网元快照数据及变更日志返回给应用服务器。值得注意的是，快照数据服务器中存储的该待查询用户的标识对应的网元快照数据包含所有网元的快照数据，但是若获取到的故障查询请求仅包括该待查询用户的某项待查询业务标识，则仅获取与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志。

步骤S103、从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据。

在本实施例中，该待查询业务可能由运营商侧的一个或多个网元提供业务支撑，从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据。网元当前实时数据指的是该待查询用户的标识对应的该待查询业务已经被该用户发起故障投诉后的网元数据。若待查询业务的标识对应多个网元，则以多线程同步获取的方式获取与待查询用户的标识对应的网元当前实时数据，数据获取时间可缩短到秒级。

步骤S104、对网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。

在本实施例中，对获取到的网元当前实时数据和相应的网元快照数据进行对比分析，将数据不一致的点定位为故障点，并根据对应的变更日志中所记录的业务变更时间、对应的业务变更指令终端标识及业务变更指令执行结果，获取故障信息，并将该并将故障信息携带在故障查询请求响应消息中进行反馈处理。

在本实施例中，根据待查询用户的标识对应的终端基于故障查询请求响应消息而返回的同意修复的故障处理指令，可以触发故障修复处理流程，使得应用服务器根据预设的故障处理模型进行故障修复处理。该故障处理模型是以运营商管理平台中存储的历史故障信息数据和故障处理程序作为训练集的输入集和输出集，训练网络模型得到的。随着应用服务器的故障处理次数的累加可以将每次的故障信息数据和故障处理程序均加入训练集以迭代训练该故障处理模型，提高故障处理模型的效率和准确度。

本实施例中，通过获取故障查询请求，该故障查询请求包括待查询用户的标识和待查询业务的标识；根据故障查询请求，向快照数据服务器发送数据查询请求，以使快照数据服务器根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据；对获取到的网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。通过本实施例提供的方法，可以在接到待查询用户投诉的第一时间，获取到投诉处理中心客户端发送的故障查询请求，并在鉴权通过后获取到与待查询用户的标识对应的网元当前实时数据、与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，并对获取到的数据迅速分析后得到故障信息进而进行故障处理。能够有效缩短对待查询用户的故障业务进行故障点分析的时间，提高故障处理的整体效率。

图2为本申请提供的一种故障处理方法实施例二的流程示意图。参照图2，该方法包括：

步骤S201、接收应用服务器发送的数据查询请求，数据查询请求中包括：待查询用户的标识和待查询业务的标识；

步骤S202、根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

步骤S203、若存在，则将与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给应用服务器，以供应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。

在本实施例中，快照数据服务器接收到应用服务器发送的数据查询请求后，若存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，则将这些数据发送给应用服务器，以使得应用服务器可以根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。

在本实施例中，快照数据服务器保存有待查询用户的标识对应的所有网元快照数据，且快照数据服务器中所存储的网元快照数据是在该用户日常的业务变更指令被执行前抓取的，是该待查询用户的标识对应的业务功能处于正常状态下的网元快照数据。

本实施例中，快照数据服务器存储的与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给应用服务器，以使得应用服务器根据从快照数据服务器获取的与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，和从与待查询业务的标识对应的网元获取的与待查询用户的标识对应的网元当前实时数据对该待查询的故障业务进行分析处理。本实施例提供的方法，可以在用户业务发生故障时迅速作出响应，无需人工逐一查询，有效提高了业务故障的处理效率。

图3为本申请提供的一种故障处理方法实施例三的流程示意图。在上述图2所示实施例的基础上，参照图3，该方法还包括：

步骤S301、在获取到业务指令时，识别业务指令；其中，业务指令包括用户标识、对应的业务标识和业务信息。

在本实施例中，快照数据服务器可以自动获取到用户日常使用业务过程中基于移动终端或者营业厅终端所发出的业务指令。并对获取到的业务指令类型进行识别。该业务指令的类型可以是业务变更指令和非业务变更指令。举例来说，业务变更指令可以是为该用户标识对应的语音业务增加/删除/修改亲情号码，或对该用户标识对应的账户办理停机保号业务等等，此类会对该用户标识对应的网元签约数据进行更改的指令；而非业务变更指令可以是为该用户标识对应的账户进行缴费，或查询该用户标识对应的业务等，不会影响该用户标识对应的网元签约数据的业务指令。

步骤S302、当识别出业务指令为业务变更指令时，采用预设的捕捉模型，判断业务变更指令中的业务信息是否满足抓取快照数据的条件。

在本实施例中，由于非业务变更指令不会影响该用户标识对应的网元签约数据，故而若识别出业务指令为非业务指令时，不需进行快照数据抓取操作。当识别出业务指令为业务变更指令时，为使得快照数据服务器能够高效的抓取必要的网元数据快照，同时也为了避免抓取的快照数据过多而造成服务器负荷过重，本申请采用预设的捕捉模型，来判断业务指令为业务变更指令时该业务变更指令中的业务信息是否满足抓取快照数据的条件。

在一种具体的实现方式中，采用预设的捕捉模型，判断业务变更指令中的业务信息是否满足抓取快照数据的条件的具体方法，包括：

采用预设的捕捉模型，根据业务信息中的用户标识对应的用户等级、用户标识对应的归属网络的复杂度、业务变更指令与具体业务的相关度、业务标识所涉及的网元性能资源使用率及上次抓取用户标识对应的快照数据距离当前的时间，获取业务结果；若业务结果大于或等于预设阈值，则业务信息满足抓取快照数据的条件；若业务结果小于预设阈值，则业务信息不满足抓取快照数据的条件。

在一种具体的实现方式中，根据业务信息中的用户标识对应的用户等级W、用户标识对应的归属网络的复杂度X、业务变更指令与具体业务的相关度Y、业务标识所涉及的网元性能资源使用率Z及上次抓取用户标识对应的快照数据距离当前的时间t，采用预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E。

其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

在本实施例中，该业务信息包括用户标识对应的用户等级W、用户标识对应的归属网络的复杂度X、业务变更指令与具体业务的相关度Y、业务标识所涉及的网元性能资源使用率Z及上次抓取用户标识对应的快照数据距离当前的时间t。

在本实施例中，用户标识对应的用户等级W可以根据注册用户的重要程度进行标记。可选的，用户的重要程度可以是运营商服务管理***基于用户标识所属电话号码的使用年限、当前月套餐价格、历史月均消费额、政企用户/个人用户等条件进行的打分。示例性的，针对获取到的业务变更指令中的用户标识，以该用户标识为用户手机号码进行说明，该用户若属于政企用户则得2分，反之不得分，另外该用户手机号码对应得使用年限、当前月套餐价格以及历史月均消费额各项得分可以对应如下表1、表2及表3进行查询获得。若该用户属于政企用户、用户手机号码使用年限大于5年、当前月套餐价格在50元～200元之间，且历史月均消费额在100元～300元之间，则该用户标识对应的用户等级W可以被标记为2+4+1+1＝8分。

表1、用户手机号码使用年限对应分值查询表

用户手机号码使用年限	分值
		小于半年	0
半年到1年	1
		1年～3年	2
3年～5年	3
		大于5年	4

表2、用户手机号码月套餐价格对应分值查询表

用户手机号码当前月套餐价格	分值
		小于50元	0
50元～200元	1
		大于200元	2

表3、用户手机号码历史月均消费额对应分值查询表

用户手机号码历史月均消费额	分值
		小于100元	0
100元～300元	1
		大于300元	2

在本实施例中，用户业务变更指令中的业务信息包含的用户标识对应的归属网络的复杂度X也可以以分值标记。示例性的，若用户标识对应的归属网络为5G网络则标记为5分，若为4G网络则也标记为5分，若为2G/3G则标记为0分。

在本实施例中，业务变更指令与具体业务的相关度Y指的是，该业务变更指令对被变更业务的影响程度。示例性的，如该业务变更指令为关掉语音功能，则这个变更指令执行后，该用户语音功能将无法使用，该业务变更指令对语音业务的影响是决定性的，该业务变更指令与具体业务的相关度Y可以标记为10分；若该业务变更指令为取消该用户标识对应的亲情号码，则业务变更指令执行后，该业务变更指令对语音业务有影响但该用户标识对应的语音业务仍能正常使用，此时该业务变更指令与具体业务的相关度Y可以标记为5分。

在本实施例中，为保证对故障的处理不影响运营商侧各个网元的正常运行，判断所获取的业务变更指令中的业务信息是否满足抓取快照数据条件时，也考虑了业务标识所涉及的网元性能资源使用率Z。指的是，快照数据服务器所获取到的业务变更指令所涉及的网元在当下的资源使用率，表现的是该网元当下的处理能力，该数据可以从业务变更指令所涉及的网元中直接获取，数值在0％～100％之间。

在本实施例中，A(t)和B(t)均为时间调节系数，示例性的，针对同一业务变更指令：0≤t≤6h时，A(t)和B(t)可以为0，意义在于短时间内不会频繁抓取同一业务变更指令对应的网元快照数据；6h＜t≤24h时，A(t)可以为0.1，B(t)可以为0，意义在于6h～24h之间的网元快照数据是否需要抓取取决于预设的捕捉模型的具体计算值，B(t)不对计算结果进行干扰；t>24h时，B(t)可以为1，意义在于若抓取间隔已超过24小时，则不论前述各项指标分值如何，均应对该业务变更指令对应的网元抓取数据快照。

在本实施例中，依据预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

α+β+γ+δ＝1

获取业务结果E，若E大于或等于预设阈值，则认为获取到的业务变更指令中的业务信息满足抓取快照数据的条件；若E小于预设阈值，则认为该业务变更指令中的业务信息不满足抓取快照数据的条件。可选的，预设阈值可以是0.8。α、β、γ、δ分别为用户标识对应的用户等级W、用户标识对应的归属网络的复杂度X、业务变更指令与具体业务的相关度Y、业务标识所涉及的网元性能资源使用率Z的关联度系数，可根据待查询用户所属的不同运营区域的历史数据以及各项指标在总体指标中的重要程度进行调节，使得α+β+γ+δ＝1。

步骤S303、若业务信息满足抓取快照数据的条件，且未查询到本地存在用户标识对应的网元的历史快照数据记录，则获取业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志。

在本实施例中，若E大于或等于预设阈值，且未查询到本地存在用户标识对应的网元的历史快照数据记录，即代表快照数据服务器还从未对该用户标识对应的网元数据进行过抓取操作，此时应获取业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志。

在本实施例中，变更日志包括：用户标识对应的网元的快照数据变更记录及变更时间、业务变更指令携带的业务标识、业务变更指令对应的变更时间及结果。

本实施例中，通过对业务指令进行获取、识别出业务变更指令，并通过业务变更指令中所包含的业务信息中的用户标识对应的用户等级、用户标识对应的归属网络的复杂度、业务变更指令与具体业务的相关度、业务标识所涉及的网元性能资源使用率及上次抓取用户标识对应的快照数据距离当前的时间，根据采用预设的捕捉模型，来判断其是否满足抓取快照数据的条件，并对满足条件的业务变更指令对应的网元快照数据进行抓取并记录该业务变更指令进行业务处理所对应的变更日志。通过本实施例提供的方法，在日常对网元快照数据进行抓取时综合考虑了用户标识对应的用户等级、用户标识对应的归属网络的复杂度、业务变更指令与具体业务的相关度、业务标识所涉及的网元性能资源使用率及上次抓取用户标识对应的快照数据距离当前的时间，可以使得对网元快照数据的抓取更具科学性、实用性的同时，有效保障运营商侧网元的正常运行，提高故障处理效率。

另外，步骤S303的另一种具体实现方式为：

若业务信息满足抓取快照数据的条件，且查询到本地存在用户标识对应的网元的历史快照数据记录，则获取并更新业务标识对应的业务在变更前的业务标识对应的网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志。

在本实施例中，若E大于或等于预设阈值，即业务信息满足抓取快照数据的条件，且查询到本地存在用户标识对应的网元的历史快照数据记录，由于对同一用户标识首次进行网元数据快照的抓取时均会抓取该用户标识对应的所有网元数据快照，故而若本地若存在该用户标识对应的网元的历史快照数据记录，则在此次网元数据快照抓取时仅抓取业务变更指令所包含的业务标识对应的业务在变更前的业务标识对应的网元快照数据以更新对应的历史网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志。

再有，步骤S303的再一种具体的实现方式为：

若业务信息不满足抓取快照数据的条件，则记录根据业务变更指令进行业务处理所对应的变更日志。

在本实施例中，若业务变更指令所包含的业务信息根据预设的抓取模型计算出其业务结果E小于预设阈值，即不满足抓取快照数据的条件，则仅存储根据业务变更指令进行业务处理所对应的变更日志，以作记录。

图4为本申请提供的一种故障处理方法实施例四的信令流程示意图。在上述图1至图3所示实施例的基础上，图4具体示出了该方法在各组件之间的交互：

步骤S401、客户端发送故障查询请求；该故障查询请求包括待查询用户的标识和待查询业务的标识。

步骤S402、应用服务器接收故障查询请求，对该请求进行鉴权处理，并在鉴权通过后，分别向快照数据服务器及待查询用户的标识和待查询业务的标识对应的网元发送数据查询请求；数据查询请求包括待查询用户的标识和待查询业务的标识。

步骤S403、快照数据服务器返回待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志。

步骤S404、待查询用户的标识和待查询业务的标识对应的网元返回网元当前实时数据。

步骤S405、根据获取到的网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中反馈给客户端。

步骤S406、客户端根据故障查询请求响应消息，触发故障处理流程。

本实施例中，应用服务器在获取到来自客户端的故障查询请求，在鉴权通过后可以同时从快照数据服务器和与待查询用户的标识和待查询业务的标识对应的一个或多个网元获取网元当前实时数据、网元快照数据及变更日志并进行分析处理，获取故障信息，并反馈给客户端以触发故障处理流程。通过本实施例提供的方法，可以在收到用户相关业务无法使用的故障投诉时，以秒级的反应时间获取故障信息，提高了故障处理的自动化程度及效率。

图5为本申请提供的一种应用服务器实施例的结构示意图。参照图5，该应用服务器500包括：第一收发模块501和故障处理模块502。第一收发模块501，用于获取故障查询请求，故障查询请求包括待查询用户的标识和待查询业务的标识；第一收发模块501，还用于根据故障查询请求，向快照数据服务器发送数据查询请求，以使快照数据服务器根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；第一收发模块501，还用于从与待查询业务的标识对应的网元中，获取与待查询用户的标识对应的网元当前实时数据；故障处理模块502，用于对网元当前实时数据、网元快照数据及变更日志进行分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。

本申请提供的应用服务器用于执行前述图1方法实施例中的技术方案，其实现原理和技术效果类似，在此不再赘述。

图6为本申请提供的一种快照数据服务器实施例的结构示意图。参照图6，该快照数据服务器600包括：第二收发模块601、查询模块602、识别模块603、判断模块604及快照数据抓取模块605。第二收发模块601，用于接收应用服务器发送的数据查询请求，数据查询请求中包括：待查询用户的标识和待查询业务的标识；查询模块602，根据数据查询请求，查询是否存在与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；第二收发模块601，用于若存在，则将与待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给应用服务器，以供应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将故障信息携带在故障查询请求响应消息中进行反馈处理。

识别模块603，用于在获取到业务指令时，识别业务指令；其中，业务指令包括用户标识、对应的业务标识和业务信息。

判断模块604，用于当识别出业务指令为业务变更指令时，采用预设的捕捉模型，判断业务变更指令中的业务信息是否满足抓取快照数据的条件。

快照数据抓取模块605，用于若业务信息满足抓取快照数据的条件，且未查询到本地存在用户标识对应的网元的历史快照数据记录，则获取业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志；快照数据抓取模块605，还用于若业务信息满足抓取快照数据的条件，且查询到本地存在用户标识对应的网元的历史快照数据记录，则获取并更新业务标识对应的业务在变更前的业务标识对应的网元快照数据，并记录根据业务变更指令进行业务处理所对应的变更日志。

另外，可选的，快照数据抓取模块605，还用于若业务信息不满足抓取快照数据的条件，则记录根据业务变更指令进行业务处理所对应的变更日志。

可选的，判断模块604，具体用于：采用预设的捕捉模型，根据业务信息中的用户标识对应的用户等级、用户标识对应的归属网络的复杂度、业务变更指令与具体业务的相关度、业务标识所涉及的网元性能资源使用率及上次抓取用户标识对应的快照数据距离当前的时间，获取业务结果；若业务结果大于或等于预设阈值，则业务信息满足抓取快照数据的条件；若业务结果小于预设阈值，则业务信息不满足抓取快照数据的条件。

可选的，判断模块604，具体用于：根据业务信息中的用户标识对应的用户等级W、用户标识对应的归属网络的复杂度X、业务变更指令与具体业务的相关度Y、业务标识所涉及的网元性能资源使用率Z及上次抓取用户标识对应的快照数据距离当前的时间t，采用预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E；其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

本申请提供的快照数据服务器用于执行前述图2和图3方法实施例中的技术方案，其实现原理和技术效果类似，在此不再赘述。

图7为本申请提供的一种故障处理***实施例的结构示意图。参照图7，该故障处理***700包括：客户端701、网元702、如图5所示的应用服务器500以及如图6所示的快照数据服务器600；其中，快照数据服务器与应用服务器独立配置或者集成配置。

在本实施例中，网元702为待查询业务的标识对应的一个网元或多个网元的集群。

本申请提供的故障处理***用于执行前述任一方法实施例中的技术方案，其实现原理和技术效果类似，在此不再赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (13)

1.一种故障处理方法，其特征在于，包括：

获取故障查询请求，所述故障查询请求包括待查询用户的标识和待查询业务的标识；

根据所述故障查询请求，向快照数据服务器发送数据查询请求，以使所述快照数据服务器根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

从与所述待查询业务的标识对应的网元中，获取与所述待查询用户的标识对应的网元当前实时数据；

对所述网元当前实时数据、所述网元快照数据及变更日志进行分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

2.一种故障处理方法，其特征在于，包括：

接收应用服务器发送的数据查询请求，所述数据查询请求中包括：待查询用户的标识和待查询业务的标识；

根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

若存在，则将所述与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给所述应用服务器，以供所述应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

3.根据权利要求2所述的方法，其特征在于，还包括：

在获取到业务指令时，识别所述业务指令；其中，所述业务指令包括用户标识、对应的业务标识和业务信息；

当识别出所述业务指令为业务变更指令时，采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件；

若所述业务信息满足所述抓取快照数据的条件，且未查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取所述业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志；

或者，

若所述业务信息满足所述抓取快照数据的条件，且查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取并更新所述业务标识对应的业务在变更前的所述业务标识对应的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志。

4.根据权利要求3所述的方法，其特征在于，还包括：

若所述业务信息不满足所述抓取快照数据的条件，则记录根据所述业务变更指令进行业务处理所对应的变更日志。

5.根据权利要求3或4所述的方法，其特征在于，所述采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件，包括：

采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果；

若所述业务结果大于或等于预设阈值，则所述业务信息满足抓取快照数据的条件；

若所述业务结果小于预设阈值，则所述业务信息不满足抓取快照数据的条件。

6.根据权利要求5所述的方法，其特征在于，所述采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果，包括：

根据所述业务信息中的所述用户标识对应的用户等级W、所述用户标识对应的归属网络的复杂度X、所述业务变更指令与具体业务的相关度Y、所述业务标识所涉及的网元性能资源使用率Z及上次抓取所述用户标识对应的快照数据距离当前的时间t，采用所述预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E；

其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

7.一种应用服务器，其特征在于，包括：

第一收发模块，用于获取故障查询请求，所述故障查询请求包括待查询用户的标识和待查询业务的标识；

所述第一收发模块，还用于根据所述故障查询请求，向快照数据服务器发送数据查询请求，以使所述快照数据服务器根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志，若存在，则返回与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

所述第一收发模块，还用于从与所述待查询业务的标识对应的网元中，获取与所述待查询用户的标识对应的网元当前实时数据；

故障处理模块，用于对所述网元当前实时数据、所述网元快照数据及变更日志进行分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

8.一种快照数据服务器，其特征在于，包括：

第二收发模块，用于接收应用服务器发送的数据查询请求，所述数据查询请求中包括：待查询用户的标识和待查询业务的标识；

查询模块，根据所述数据查询请求，查询是否存在与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志；

第二收发模块，用于若存在，则将所述与所述待查询用户的标识和待查询业务的标识对应的网元快照数据及变更日志发送给所述应用服务器，以供所述应用服务器根据获取的待查询业务的标识对应的网元当前实时数据、待查询业务的标识对应的网元快照数据及变更日志进行故障分析处理，获取故障信息，并将所述故障信息携带在故障查询请求响应消息中进行反馈处理。

9.根据权利要求8所述的快照数据服务器，其特征在于，还包括：

识别模块，用于在获取到业务指令时，识别所述业务指令；其中，所述业务指令包括用户标识、对应的业务标识和业务信息；

判断模块，用于当识别出所述业务指令为业务变更指令时，采用预设的捕捉模型，判断所述业务变更指令中的业务信息是否满足抓取快照数据的条件；

快照数据抓取模块，用于若所述业务信息满足所述抓取快照数据的条件，且未查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取所述业务标识对应的业务在变更前的用户标识对应的所有的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志；

所述快照数据抓取模块，还用于若所述业务信息满足所述抓取快照数据的条件，且查询到本地存在所述用户标识对应的网元的历史快照数据记录，则获取并更新所述业务标识对应的业务在变更前的所述业务标识对应的网元快照数据，并记录根据所述业务变更指令进行业务处理所对应的变更日志。

10.根据权利要求9所述的快照数据服务器，其特征在于，所述快照数据抓取模块，还用于若所述业务信息不满足所述抓取快照数据的条件，则记录根据所述业务变更指令进行业务处理所对应的变更日志。

11.根据权利要求9或10所述的快照数据服务器，其特征在于，所述判断模块，具体用于：

采用预设的捕捉模型，根据所述业务信息中的所述用户标识对应的用户等级、所述用户标识对应的归属网络的复杂度、所述业务变更指令与具体业务的相关度、所述业务标识所涉及的网元性能资源使用率及上次抓取所述用户标识对应的快照数据距离当前的时间，获取业务结果；

若所述业务结果大于或等于预设阈值，则所述业务信息满足抓取快照数据的条件；

若所述业务结果小于预设阈值，则所述业务信息不满足抓取快照数据的条件。

12.根据权利要求11所述的快照数据服务器，其特征在于，所述判断模块，具体用于：

根据所述业务信息中的所述用户标识对应的用户等级W、所述用户标识对应的归属网络的复杂度X、所述业务变更指令与具体业务的相关度Y、所述业务标识所涉及的网元性能资源使用率Z及上次抓取所述用户标识对应的快照数据距离当前的时间t，采用所述预设的捕捉模型中的公式：

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

获取业务结果E；

其中，A(t)和B(t)均为时间调节系数；α、β、γ、δ为关联度系数，α+β+γ+δ＝1。

13.一种故障处理***，其特征在于，包括：客户端、网元、如权利要求7所述的应用服务器以及如权利要求8至12任一项所述的快照数据服务器；其中，所述快照数据服务器与所述应用服务器独立配置或者集成配置。

Images