CN111817901A - 一种故障工单处理方法、设备和计算机可读存储介质 - Google Patents

Abstract

本申请涉及云计算领域，提供了一种故障工单处理方法、设备和计算机可读存储介质，以解决现有技术针对故障的效率低的问题。所述方法包括：业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送初始故障工单；工单子系统根据初始故障工单的关键字段生成标准化故障工单；工单子系统将故障定位相关信息和标准化故障工单向运营商子系统发送；运营商子系统受理所述标准化故障工单，向工单子系统返回受理结果；根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统返回故障定位结果；将受理结果和故障定位结果展示于运营商自动保障历史页面。本申请的技术方案将故障工单的处理时间缩短，提高了故障工单的处理效率。

Description

一种故障工单处理方法、设备和计算机可读存储介质

技术领域

本申请涉及云计算领域，特别涉及一种故障工单处理方法、设备和计算机可读存储介质。

背景技术

作为承载互联网的运营商基础网络，任何一条线路故障都有可能对用户产生严重影响。因此，如何尽快排除故障是网络各方关注的问题。目前，互联网故障的传统处理方式是逐段排查定位，这种故障处理方式过程中，需要对故障工单进行一些列处理，包括生成、上报和派发等。

然而，上述故障工单处理方式中，是通过人工收集信息，再通过邮件或电话逐级沟通后，最终生成故障工单并上报，因此影响了故障上报时间，导致故障的解决速度或效率降低。

发明内容

本申请实施例提供了一种故障工单处理的方法、设备和计算机可读存储介质，以解决现有技术针对故障的解决速度或效率降低的问题。该技术方案如下：

一方面，提供了一种故障工单处理方法，该方法包括：

业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送所述初始故障工单；

所述工单子系统根据所述初始故障工单的关键字段生成标准化故障工单，所述关键字段包括故障描述字段；

所述工单子系统将故障定位相关信息和所述标准化故障工单向运营商子系统发送；

所述运营商子系统受理所述标准化故障工单，向所述工单子系统返回受理结果；

所述运营商子系统根据所述故障定位相关信息定位所述标准化故障工单中反映的故障，向所述工单子系统返回故障定位结果；

所述工单子系统将所述受理结果和故障定位结果展示于运营商自动保障历史页面。

一方面，提供了一种故障工单处理系统，该装置包括：

业务报障子系统，用于根据故障类型生成初始故障工单，向工单子系统传送所述初始故障工单；

所述工单子系统，用于根据所述初始故障工单的关键字段生成标准化故障工单，所述关键字段包括故障描述字段；

所述工单子系统，用于将故障定位相关信息和所述标准化故障工单向运营商子系统发送；

所述运营商子系统，用于受理所述标准化故障工单，向所述工单子系统返回受理结果；

所述运营商子系统还用于根据所述故障定位相关信息定位所述标准化故障工单中反映的故障，向所述工单子系统返回故障定位结果；

所述工单子系统还用于将所述受理结果和故障定位结果展示于运营商自动保障历史页面。

一方面，提供了一种计算机设备，该计算设备包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，该计算机程序代码由该一个或多个处理器加载并执行以实现该故障工单处理方法所执行的操作。

一方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序由处理器加载并执行以实现该故障工单处理方法所执行的操作。

从上述本申请提供的技术方案可知，相比于现有技术在处理故障工单时依靠人工层层上报并逐层等待，本申请的技术方案中的业务报障子系统、工单子系统和运营商子系统从生成故障工单、转发故障工单到处理故障工单，其处理过程类似于流水作业，其间并没有停留、等待环节，也无需是人工参与，因此，本申请的技术方案将故障工单的处理时间大大缩短，提高了故障工单的处理效率。

附图说明

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

图1是本申请实施例提供的故障工单处理方法的流程图；

图2是本申请实施例提供的运营商子系统对故障工单的受理结果的示意图；

图3是本申请实施例提供的运营商子系统对故障工单所反映的故障的定位结果示意图；

图4是本申请实施例提供的故障的处理进度信息在运营商自动保障历史页面的展示示意图；

图5是本申请实施例提供的故障工单处理的结构示意图；

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

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请实施例基于计算机设备作为执行主体来进行介绍。此处的计算机设备可以是服务器，也可以是终端，其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，而终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。上述终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

现有技术中，互联网故障的传统处理方式是逐段排查定位，这种故障处理方式过程中，需要对故障工单进行一些列处理，包括生成、上报和派发等。然而，这种故障工单处理方式是通过人工收集信息，再通过邮件或电话逐级沟通后，最终生成故障工单并上报，因此影响了故障上报时间，导致故障的解决速度或效率降低。为了解决上述问题，本申请提供一种故障工单处理方法，该方法应用于业务报障子系统、工单子系统和运营商子系统构成的系统，各个子系统的主要硬件是服务器，这些服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务以及大数据和人工智能平台等基础云计算服务的云服务器。

参见图1，本申请提供的故障工单处理方法主要包括以下步骤S101至S106，详细说明如下：

步骤S101：业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送初始故障工单。

在本申请实施例中，网络故障既有可能是来自网络应用的直接感知，也有可能是来自专门的监控系统的监控，前者对故障的描述可能是初级的或者模糊的，后者对故障的描述相对要精准，例如，前者对故障类型的描述可以是业务异常、访问受限、域名故障等定性的描述，后者对故障类型的描述可以是对质量故障、专线故障和出口故障等的专业化或定量的描述。无论是什么方式，业务报障子系统都可以调用工单子系统提供的接口，根据故障类型(业务异常、访问受限、域名故障、质量故障、专线故障和出口故障等)填写相应标题、故障描述、工单分类和紧急级别后，生成初始故障工单，向工单子系统传送所生成的初始故障工单。

步骤S102：工单子系统根据初始故障工单的关键字段生成标准化故障工单，其中，关键字段包括故障描述字段。

工单子系统在收到来自业务报障子系统传送的初始故障工单后，提取其中的结构化关键字段，包括故障工单号、故障级别、故障类型、故障开始时间、线路编号和故障描述等，生成标准化故障工单，其中，对于故障描述字段，需要根据不同故障类型进行设计，例如，对于专线中断故障，其故障描述[2020-04-01 21:21:43，成都-深圳xxNP，中断]。标准化故障工单相对于前述的初始故障工单而言，区别在于前者在内容描述方面更加标准化，在格式方面也更加统一，利于后续运营商子系统的处理。

步骤S103：工单子系统将故障定位相关信息和标准化故障工单向运营商子系统发送。

在本申请实施例中，故障定位相关信息包括数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息等。工单子系统通过调用运营商子系统提供的接口，将故障定位相关信息和标准化故障工单向运营商子系统发送。

需要说明的是，为了安全起见，在本申请实施例中，上述步骤S101至步骤S103中，数据的传输都是通过https+json或ajax+json方式进行，这些方式是以安全为目标的HTTP通道来进行传输，即在HTTP下加入安全套接字层(Secure Socket Layer，SSL)，HTTPS的安全基础是SSL。

步骤S104：运营商子系统受理标准化故障工单，向工单子系统返回受理结果。

若运营商子系统能够向工单子系统返回受理结果，则表明运营商子系统已经收到标准化故障工单并受理。

步骤S105：运营商子系统根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统返回故障定位结果。

运营商子系统根据故障定位相关信息定位标准化故障工单中反映的故障，主要是通过统计每个节点的数据包历史路径信息、网络节点最多的省份、数据包质量指标、端口利用率以及结合网元信息表等，得到若干故障疑似节点，然后，从这些故障疑似节点中再确定真正的故障节点。作为本申请一个实施例，运营商子系统根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统返回故障定位结果可通过如下步骤S1051至步骤S1055实现，说明如下：

步骤S1051：运营商子系统根据每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点。

节点的数据包历史路径信息即本节点所收到的数据包曾经历过哪些节点等信息。具体而言，运营商子系统根据每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点可以是：运营商子系统根据每个节点的数据包历史路径信息中每个IP归属省份，统计IP次数出现最多的省份，在IP次数出现最多的省份内，根据每个节点的数据包历史路径信息计算历史公共路径节点信息，将具有最大历史公共路径的节点作为第一故障疑似节点。

步骤S1052：运营商子系统针对网络节点最多的省份，并根据数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，将影响路径最多的节点作为第二故障疑似节点。

具体而言，步骤S1052通过如下步骤S1至S3实现：

S1：针对网络节点最多的省份，根据所每个节点的数据包实时路径信息，拆分出若干节点对。

如前所述，数据包的路径信息即数据包经过哪些节点。因此，针对经步骤S1051统计出来的网络节点最多的省份，可以根据所每个节点的数据包实时路径信息，拆分出若干节点对。所谓节点对，是指数据包所经历的两个节点，该两个节点之间不存在其他节点。

S2：根据数据包质量指标和每个节点的数据包历史路径信息，确定若干节点对中质差节点对。

可以根据数据包质量指标，例如，延时、丢包和不可达等信息，将这些数据包的实时质量指标与历史路径上的质量指标相比，得到若干节点对中质差节点对即质量最差的节点对。

S3：结合网元信息表，统计质差节点对中各节点影响路径数量，将影响路径最多的节点作为第二故障疑似节点。

在本申请实施例中，网元信息表中记录了各节点所在的路径信息。因此，可以结合网元信息表，统计出质差节点对中各节点影响路径数量，然后，将影响路径最多的节点作为第二故障疑似节点。

步骤S1053：确定第二故障疑似节点是否为故障节点，若无法确定第二故障疑似节点为故障节点，则根据预定时间段内流量数据中端口利用率确定第三故障疑似节点。

具体而言，步骤S1053的实现过程如下：统计网络节点最多的省份中数据包经过的最多的前3个节点；将前3个节点和第二故障疑似节点与网管重要告警匹配，若前3个节点中具有一个节点或第二故障疑似节点与网管重要告警最匹配，则将最匹配的节点确定为故障节点；若无法确定故障节点，则统计预定时间段内流量数据中端口利用率，将利用率高于预设阈值的端口所在的节点作为第三故障疑似节点。

步骤S1054：比较第一故障疑似节点、第二故障疑似节点和第三故障疑似节点，若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中两个或三个疑似节点重合，则将重合的节点确定为故障节点。

例如，在第一故障疑似节点、第二故障疑似节点和第三故障疑似节点后，若第一故障疑似节点和第二故障疑似节点实际上是同一节点，则将第一故障疑似节点或第二故障疑似节点确定为故障节点；又如，在第一故障疑似节点、第二故障疑似节点和第三故障疑似节点后，若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点实际上是同一节点，则将第一故障疑似节点、第二故障疑似节点或第三疑似故障节点确定为故障节点。

步骤S1055：若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中无重合，则根据第一故障疑似节点、第二故障疑似节点和第三故障疑似节点的数据包实时路径信息分析出故障节点。

若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中无重合的节点，则说明无法通过历史路径信息分析出到底哪个故障疑似节点是真正的故障节点，因此，可以针对第一故障疑似节点、第二故障疑似节点和第三故障疑似节点，根据第一故障疑似节点、第二故障疑似节点和第三故障疑似节点的数据包实时路径信息，分析出到底哪个故障疑似节点属于故障节点。

步骤S1056：向工单子系统返回经步骤S1051至步骤S1055分析出来的故障节点。

步骤S106：工单子系统将受理结果和故障定位结果展示于运营商自动保障历史页面。

在本申请实施例中，运营商自动保障历史页面主要用于展示运营商子系统对故障工单的受理结果、故障定位结果以及工单子系统与运营商子系统的之间的交互等信息，以便于提单人及时获知故障工单的受理和处理情况。如附图2所示，是运营商子系统对故障工单的受理结果的示意图，附图3是运营商子系统对故障工单所反映的故障的定位结果示意图。

在上述处理故障过程中，工单子系统周期性地与运营商子系统交互，以获取故障的处理进度信息；若需要向运营商子系统反馈故障的答复信息，则工单子系统向运营商子系统反馈答复信息；工单子系统将处理进度信息和答复信息展示于运营商自动保障历史页面。如附图4所示，是故障的处理进度信息在运营商自动保障历史页面的展示示意图。

需要说明的是，上述交互具体实施方式是运营商在页面填写反馈内容，使用ajax请求的方式传递给工单子系统的服务器。工单子系统的服务器按照接口协议拼装数据后，以https+json的方式调用运营商子系统提供的接口，并在故障工单的处理过程中增加一条记录，保存反馈人、反馈内容和反馈时间等信息，再与运营商自动报障历史合并后展示到运营商自动保障历史页面。

在上述实施例中，工单子系统将运营商自动保障历史页面中的历史标准化故障工单与数据库保存的故障历史记录比较；若比较的结果显示具有新增故障，则工单子系统将新增故障推送至业务报障子系统。新增故障推送到业务报障子系统后，由业务报障子系统调用即时通信接口，例如，微信接口，将新增故障发送至与业务报障子系统对应企业的微信群，告知微信群里故障处理相关人员有新增故障，以便该相关人员进行相应处理，例如，向业务报障子系统提交该新增故障的故障类型等相关信息。

从上述附图1示例的技术方案可知，相比于现有技术在处理故障工单时依靠人工层层上报并逐层等待，本申请的技术方案中的业务报障子系统、工单子系统和运营商子系统从生成故障工单、转发故障工单到处理故障工单，其处理过程类似于流水作业，其间并没有停留、等待环节，也无需是人工参与，因此，本申请的技术方案将故障工单的处理时间大大缩短，提高了故障工单的处理效率。

请参阅附图5，是本申请实施例提供的一种故障工单处理系统的结构示意图，该系统可以集成在终端等计算机设备中，该系统包括业务报障子系统501、工单子系统502和运营商子系统503，其中：

业务报障子系统501，用于根据故障类型生成初始故障工单，向工单子系统502传送初始故障工单；

工单子系统502，用于根据初始故障工单的关键字段生成标准化故障工单，其中，关键字段包括故障描述字段；

工单子系统502还用于将故障定位相关信息和标准化故障工单向运营商子系统503发送；

运营商子系统503，用于受理标准化故障工单，向工单子系统502返回受理结果；

运营商子系统503还用于根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统502返回故障定位结果；

工单子系统502还用于将受理结果和故障定位结果展示于运营商自动保障历史页面。

在一种可能实现方式中，故障定位相关信息包括数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，附图5示例的运营商子系统503具体用于根据每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点；运营商子系统503针对网络节点最多的省份，并根据数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，将影响路径最多的节点作为第二故障疑似节点；确定第二故障疑似节点是否为故障节点，若无法确定第二故障疑似节点为故障节点，则根据预定时间段内流量数据中端口利用率确定第三故障疑似节点；比较第一故障疑似节点、第二故障疑似节点和第三故障疑似节点，若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中两个或三个疑似节点重合，则将重合的节点确定为故障节点；若第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中无重合，则根据第一故障疑似节点、第二故障疑似节点和第三故障疑似节点的数据包实时路径信息分析出故障节点；向工单子系统返回分析出来的故障节点。

在一种可能实现方式中，上述运营商子系统503根据每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点可以是：运营商子系统503根据每个节点的数据包历史路径信息中每个IP归属省份，统计IP次数出现最多的省份；在IP次数出现最多的省份内，根据每个节点的数据包历史路径信息计算历史公共路径节点信息，将具有最大历史公共路径的节点作为所述第一故障疑似节点。

在一种可能实现方式中，上述运营商子系统503针对网络节点最多的省份，并根据数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，将影响路径最多的节点作为第二故障疑似节点可以是针对网络节点最多的省份，根据每个节点的数据包实时路径信息，拆分出若干节点对；根据数据包质量指标和每个节点的数据包历史路径信息，确定若干节点对中质差节点对；结合网元信息表，统计质差节点对中各节点影响路径数量，将影响路径最多的节点作为第二故障疑似节点。

在一种可能实现方式中，上述确定第二故障疑似节点是否为故障节点，若无法确定第二故障疑似节点为故障节点，则根据预定时间段内流量数据中端口利用率确定第三故障疑似节点可以是：统计网络节点最多的省份中数据包经过的最多的前3个节点；将前3个节点和第二故障疑似节点与网管重要告警匹配，若前3个节点中具有一个节点或第二故障疑似节点与网管重要告警最匹配，则将最匹配的节点确定为故障节点；若无法确定故障节点，则统计预定时间段内流量数据中端口利用率，将利用率高于预设阈值的端口所在的节点作为第三故障疑似节点。

在一种可能实现方式中，上述工单子系统502周期性地与运营商子系统503交互，以获取故障的处理进度信息；若需要向运营商子系统503反馈故障的答复信息，则工单子系统502向运营商子系统503反馈答复信息；工单子系统502将处理进度信息和答复信息展示于运营商自动保障历史页面。

在一种可能实现方式中，上述工单子系统502将运营商自动保障历史页面中的历史标准化故障工单与数据库保存的故障历史记录比较；若比较的结果显示具有新增故障，则工单子系统502将新增故障推送至业务报障子系统。

需要说明的是，上述实施例提供的故障工单处理系统在故障工单处理时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的故障工单处理系统与故障工单处理方法实施例属于同一构思，其具体实现过程以及技术效果详见方法实施例，此处不再赘述。

本申请实施例还提供一种计算机设备，该计算机设备可以为终端或者服务器等设备，如图6所示，其示出了本申请实施例所涉及的计算机设备的结构示意图，具体来讲：

该计算机设备可以包括一个或者一个以上处理核心的处理器601、一个或一个以上计算机可读存储介质的存储器602、电源603和输入单元604等部件。本领域技术人员可以理解，图6中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器601是该计算机设备的控制中心，利用各种接口和线路连接整个计算机设备的各个部分，通过运行或执行存储在存储器602内的软件程序和/或模块，以及调用存储在存储器602内的数据，执行计算机设备的各种功能和处理数据，从而对计算机设备进行整体监控。可选的，处理器601可包括一个或多个处理核心；优选的，处理器601可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器601中。

存储器602可用于存储软件程序以及模块，处理器601通过运行存储在存储器602的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器602可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器602还可以包括存储器控制器，以提供处理器601对存储器602的访问。

计算机设备还包括给各个部件供电的电源603，可选地，电源603可以通过电源管理系统与处理器601逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源603还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该计算机设备还可包括输入单元604，该输入单元604可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

尽管未示出，计算机设备还可以包括显示单元等，在此不再赘述。具体在本实施例中，计算机设备中的处理器601会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器602中，并由处理器601来运行存储在存储器602中的应用程序，从而实现各种功能，如下：业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送初始故障工单；工单子系统根据初始故障工单的关键字段生成标准化故障工单，其中，关键字段包括故障描述字段；工单子系统将故障定位相关信息和标准化故障工单向运营商子系统发送；运营商子系统受理所述标准化故障工单，向工单子系统返回受理结果；运营商子系统根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统返回故障定位结果；工单子系统将受理结果和故障定位结果展示于运营商自动保障历史页面。

以上个操作的具体实施例可参见前面的实施例，在此不再赘述。

由以上可知，相比于现有技术在处理故障工单时依靠人工层层上报并逐层等待，本申请的技术方案中的业务报障子系统、工单子系统和运营商子系统从生成故障工单、转发故障工单到处理故障工单，其处理过程类似于流水作业，其间并没有停留、等待环节，也无需是人工参与，因此，本申请的技术方案将故障工单的处理时间大大缩短，提高了故障工单的处理效率。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种故障工单处理方法中的步骤。例如，该指令可以执行如下步骤：业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送初始故障工单；工单子系统根据初始故障工单的关键字段生成标准化故障工单，其中，关键字段包括故障描述字段；工单子系统将故障定位相关信息和标准化故障工单向运营商子系统发送；运营商子系统受理所述标准化故障工单，向工单子系统返回受理结果；运营商子系统根据故障定位相关信息定位标准化故障工单中反映的故障，向工单子系统返回故障定位结果；工单子系统将受理结果和故障定位结果展示于运营商自动保障历史页面。

以上各个操作的具体实施方式可参见前面的实施例，在此不再赘述。

其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read OnlyMemory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该计算机可读存储介质中所存储的指令，可以执行本申请实施例所提供的任一种故障工单处理方法中的步骤，因此，可以实现本申请实施例所提供的任一种故障工单处理方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种故障工单处理方法、设备和计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (10)

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

业务报障子系统根据故障类型生成初始故障工单，向工单子系统传送所述初始故障工单；

所述工单子系统根据所述初始故障工单的关键字段生成标准化故障工单，所述关键字段包括故障描述字段；

所述工单子系统将故障定位相关信息和所述标准化故障工单向运营商子系统发送；

所述运营商子系统受理所述标准化故障工单，向所述工单子系统返回受理结果；

所述运营商子系统根据所述故障定位相关信息定位所述标准化故障工单中反映的故障，向所述工单子系统返回故障定位结果；

所述工单子系统将所述受理结果和故障定位结果展示于运营商自动保障历史页面。

2.如权利要求1所述故障工单处理方法，其特征在于，所述故障定位相关信息包括数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，所述运营商子系统根据所述故障定位相关信息定位所述标准化故障工单中反映的故障，向所述工单子系统返回故障定位结果，包括：

所述运营商子系统根据所述每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点；

所述运营商子系统针对网络节点最多的省份，并根据所述数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，将影响路径最多的节点作为第二故障疑似节点；

确定所述第二故障疑似节点是否为故障节点，若无法确定所述第二故障疑似节点为故障节点，则根据预定时间段内流量数据中端口利用率确定第三故障疑似节点；

比较所述第一故障疑似节点、第二故障疑似节点和第三故障疑似节点，若所述第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中两个或三个疑似节点重合，则将所述重合的节点确定为故障节点；

若所述第一故障疑似节点、第二故障疑似节点和第三故障疑似节点中无重合，则根据所述第一故障疑似节点、第二故障疑似节点和第三故障疑似节点的数据包实时路径信息分析出故障节点；

向所述工单子系统返回所述分析出来的故障节点。

3.如权利要求2所述故障工单处理方法，其特征在于，所述运营商子系统根据所述每个节点的数据包历史路径信息中每个IP归属省份，计算得到第一故障疑似节点，包括：

所述运营商子系统根据所述每个节点的数据包历史路径信息中每个IP归属省份，统计所述IP次数出现最多的省份；

在所述IP次数出现最多的省份内，根据每个节点的数据包历史路径信息计算历史公共路径节点信息，将具有最大历史公共路径的节点作为所述第一故障疑似节点。

4.如权利要求2所述故障工单处理方法，其特征在于，所述运营商子系统针对网络节点最多的省份，并根据所述数据包质量指标、每个节点的数据包历史路径信息和每个节点的数据包实时路径信息，将影响路径最多的节点作为第二故障疑似节点，包括：

针对网络节点最多的省份，根据所述每个节点的数据包实时路径信息，拆分出若干节点对；

根据所述数据包质量指标和每个节点的数据包历史路径信息，确定所述若干节点对中质差节点对；

结合网元信息表，统计所述质差节点对中各节点影响路径数量，将影响路径最多的节点作为所述第二故障疑似节点。

5.如权利要求2所述故障工单处理方法，其特征在于，所述确定所述第二故障疑似节点是否为故障节点，若无法确定所述第二故障疑似节点为故障节点，则根据预定时间段内流量数据中端口利用率确定第三故障疑似节点，包括：

统计所述网络节点最多的省份中数据包经过的最多的前3个节点；

将所述前3个节点和所述第二故障疑似节点与网管重要告警匹配，若所述前3个节点中具有一个节点或所述第二故障疑似节点与所述网管重要告警最匹配，则将所述最匹配的节点确定为所述故障节点；

若无法确定所述故障节点，则统计预定时间段内流量数据中端口利用率，将所述利用率高于预设阈值的端口所在的节点作为所述第三故障疑似节点。

6.如权利要求1至5任意一项所述故障工单处理方法，其特征在于，所述方法还包括：

所述工单子系统周期性地与所述运营商子系统交互，以获取所述故障的处理进度信息；

若需要向所述运营商子系统反馈所述故障的答复信息，则所述工单子系统向所述运营商子系统反馈所述答复信息；

所述工单子系统将所述处理进度信息和答复信息展示于所述运营商自动保障历史页面。

7.如权利要求1至5任意一项所述故障工单处理方法，其特征在于，所述方法还包括：

所述工单子系统将所述运营商自动保障历史页面中的历史标准化故障工单与数据库保存的故障历史记录比较；

若所述比较的结果显示具有新增故障，则所述工单子系统将所述新增故障推送至所述业务报障子系统。

8.一种故障工单处理系统，其特征在于，所述系统包括：

业务报障子系统，用于根据故障类型生成初始故障工单，向工单子系统传送所述初始故障工单；

所述工单子系统，用于根据所述初始故障工单的关键字段生成标准化故障工单，所述关键字段包括故障描述字段；

所述工单子系统，用于将故障定位相关信息和所述标准化故障工单向运营商子系统发送；

所述运营商子系统，用于受理所述标准化故障工单，向所述工单子系统返回受理结果；

所述运营商子系统还用于根据所述故障定位相关信息定位所述标准化故障工单中反映的故障，向所述工单子系统返回故障定位结果；

所述工单子系统还用于将所述受理结果和故障定位结果展示于运营商自动保障历史页面。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任意一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任意一项所述方法的步骤。

Images