网络故障定位方法及系统与流程

1.本发明涉及计算机技术领域，尤其涉及一种网络故障定位方法及系统。


背景技术：

2.近年来，随着信息科技及因特网的快速发展，网络用户的数量呈爆炸式的增长，网络用户对网络质量的要求也日渐提高。
3.随着网络用户数量的急剧攀升，网络中网元设备的数量日趋庞大，网络拓扑结构更为复杂，网络运行负荷越来越高，使得基于现有的网络故障定位方法已难以准确、高效的定位网络中发生故障的网元设备，严重影响了网络的正常运行。因此，如何更准确、更高效的进行网络故障定位是本领域亟待解决的技术问题。


技术实现要素：

4.本发明提供一种网络故障定位方法及系统，用以解决现有技术中难以准确、高效的定位网络中发生故障的网元设备的缺陷，实现更准确、更高效的进行网络故障定位。
5.本发明提供一种网络故障定位方法，包括：基于深度数据包检测采集目标维度的xdr数据；基于所述xdr数据，获取目标范围内每一网元设备的评价指标值；基于每一所述网元设备的评价指标值，在各所述网元设备中确定质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
6.根据本发明提供的一种网络故障定位方法，所述基于深度数据包检测采集目标维度的xdr数据之后，还包括：在获取到用户的故障投诉信息的情况下，响应于所述故障投诉信息，基于所述xdr数据，在所述用户对应的各网元设备中确定故障网元设备，和/或，确定所述故障投诉信息对应的故障原因。
7.根据本发明提供的一种网络故障定位方法，所述基于每一所述网元设备的评价指标值，在各所述网元设备中确定质差网元设备，包括：基于每一网元设备的设备类型，获取所述每一网元设备对应的质差判定条件；判断所述每一网元设备的评价指标值是否满足所述每一网元设备对应的质差判定条件；在所述每一网元设备的评价指标值满足所述每一网元设备对应的质差判定条件的情况下，将所述每一网元设备确定为所述质差网元设备。
8.根据本发明提供的一种网络故障定位方法，所述响应于所述故障投诉信息，基于所述xdr数据，在所述用户对应的各网元设备中确定故障网元设备，和/或，确定所述故障投诉信息对应的故障原因，包括：对所述故障投诉信息进行特征提取；在从所述故障投诉信息中提取到特征信息的情况下，基于所述特征信息，获取所
述故障投诉信息对应的故障排查顺序；基于所述xdr数据，按照所述故障排查顺序对所述用户对应的各网元设备进行故障排查，进而在所述用户对应的各网元设备中确定所述故障网元设备，和/或，确定所述故障投诉信息对应的故障原因。
9.根据本发明提供的一种网络故障定位方法，所述对所述故障投诉信息进行特征提取之后，还包括：在未从所述故障投诉信息提取到特征信息的情况下，按照预设故障排查顺序对所述用户对应的各网元设备进行故障排查，进而在所述用户对应的各网元设备中确定所述故障网元设备，和/或，确定所述故障投诉信息对应的故障原因。
10.根据本发明提供的一种网络故障定位方法，所述基于深度数据包检测采集目标维度的xdr数据之后，还包括：基于所述xdr数据，获取目标范围内每一用户的用户维度指标值；基于所述每一用户的用户维度指标值，在各所述用户中确定质差用户。
11.本发明还提供一种网络故障定位系统，包括：数据采集模块，用于基于深度数据包检测采集目标维度的xdr数据；数据评价模块，用于基于所述xdr数据，获取目标范围内每一网元设备的评价指标值；故障定位模块，用于基于每一所述网元设备的评价指标值，在各所述网元设备中确定质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
12.根据本发明提供的一种网络故障定位系统，还包括：用户交互界面；所述用户交互界面用于显示所述xdr数据、所述每一网元设备的评价指标值以及所述质差网元设备的设备信息中的至少一种。
13.本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述网络故障定位方法。
14.本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述网络故障定位方法。
15.本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述网络故障定位方法。
16.本发明提供的网络故障定位方法及系统，以dpi作为关键突破点，基于dpi进行多维度的xdr数据的采集，并通过对上述xdr数据的分解和分析，获取目标范围内每一网元设备的评价指标值，从而能更准确、更高效的获知上述每一网元设备的运行负荷和设备性能，能为网络故障定位提供数据支撑，能提高网络故障定位的准确率和效率，能有效支撑网元设备的及时维护、维修和调优工作，还能基于上述xdr数据实现各区域短板分析，进行地市间、区县间横向对比，能从宏观上掌握全区域网络故障情况、质差情况、业务发展情况及业务感知情况，能更及时的发现问题点，能在影响用户正常使用前进行问题修复，能保持用户网络的正常使用。
附图说明
17.为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1是本发明提供的网络故障定位方法的流程示意图；图2为本发明提供的网络故障定位方法中实例一的流程示意图之一；图3为本发明提供的网络故障定位方法中实例一的流程示意图之二；图4本发明提供的网络故障定位方法中实例二的流程示意图之一；图5本发明提供的网络故障定位方法中实例二的流程示意图之二；图6本发明提供的网络故障定位方法中实例三的流程示意图之一；图7本发明提供的网络故障定位方法中实例三的流程示意图之二；图8本发明提供的网络故障定位方法中实例四的流程示意图之一；图9本发明提供的网络故障定位方法中实例四的流程示意图之二；图10是本发明提供的网络故障定位系统的结构示意图；图11是本发明提供的电子设备的结构示意图。
具体实施方式
19.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
20.在发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
21.图1是本发明提供的网络故障定位方法的流程示意图。下面结合图1描述本发明的网络故障定位方法。如图1所示，该方法包括：步骤101、基于深度数据包检测采集目标维度的xdr数据。
22.需要说明的是，本发明实施例的执行主体为网络故障定位系统。
23.具体地，深度数据包检测（deep packet inspection，dpi）是一种基于数据包的深度检测技术，可以通过对网络的关键点处的流量和报文内容进行检测分析，还可以根据事先定义的策略对检测流量进行过滤控制，能完成所在链路的业务精细化识别、业务流量流向分析、业务流量占比统计、业务占比整形、以及应用层拒绝服务攻击、对病毒、木马进行过滤和滥用p2p的控制等功能。
24.xdr（extended detection and response，扩展检测和响应），是传统的edr（endpoint detection and response，端点检测与响应）的拓展和增强。xdr是一种跨多个安全层收集并自动关联信息以实现快速威胁检测的方法，结合了安全信息和事件管理
（siem）、安全编排自动化和响应（soar）、端点检测与响应（edr）以及网络流量分析（nta），集中安全数据和事件响应。
25.基于dpi，可以采集预设范围内目标维度的xdr数据。
26.其中，预设范围与dpi的设置节点相关，例如：预设范围可以为某一省范围内、某一市范围内或每一区范围内。
27.目标维度可以是根据实际情况和/或先验知识预习确定的。本发明实施例中对目标维度不作具体限定。
28.可选地，目标维度可以包括预设时间粒度、预设时间周期、预设区域、预设带宽以及预设业务类型中的至少一种。其中，业务类型可以包括但不限于页面浏览、视频、游戏和http等。
29.步骤102、基于xdr数据，获取目标范围内每一网元设备的评价指标值。
30.其中，评价指标包括业务指标，或者业务指标以及性能指标。
31.具体地，基于dpi采集目标维度的xdr数据之后，可以基于上述xdr数据，通过数值计算、数理统计等多种方式，可以对xdr数据进行分解和分析，进而可以获取目标范围内每一网元设备的业务指标值，或者业务指标指和性能指标值，作为每一网元设备的评价指标值。
32.其中，目标范围是根据实际情况和/或先验知识在上述预设范围内确定的一个范围。本发明实施例中对目标范围不作具体限定。
33.对于任一网元设备，基于该网元设备的评价指标值，可以判断该网元设备的运行负荷和设备性能。其中，该网元设备的业务指标值，可以包括该网元设备的用户体验质量（quality of experience，qoe），用于描述用户对该网元设备的质量和性能的主观感受。
34.需要说明的是，本发明实施例中的各网元设备呈拓扑结构连接，任一网元设备的设备类型可以为光网络单元（optical network unit，onu）、无源光纤分路器（passive optical splitter，pos）、无源光网络（passive optical network，pon）接口、光线路终端（optical line terminal，olt）、交换机（switch，sw）、宽带远程接入服务器（broadband remote access server，bras）和内容源中的任意一种。其中，上述内容源可以包括网页、游戏和视频等。
35.需要说明的是，对于任一网元设备，该网元设备的评价指标中是否包括性能指标以及具体的性能指标，与网元设备的设备类型相关。
36.可选地，在任一网元设备的设备类型为onu的情况下，该网元设备的性能指标包括流量、接收到的光功率和/或下带宽。
37.在任一网元设备的设备类型为pon接口的情况下，该网元设备的性能指标包括接口发送带宽利用率、接口接收带宽利用率、接口接收光功的超出量以及接口发送光功率达到超出量中的至少一个。
38.在任一网元设备的设备类型为olt的情况下，该网元设备的性能指标包括cpu利用率和/或内存利用率。
39.在任一网元设备的设备类型为bras的情况下，该网元设备的性能指标包括cpu利用率、内存利用率、端口发送宽带利用率、端口接收宽带利用率、端口发送光功率超出量以及端口接收光功率超出量。
40.在任一网元设备的设备类型为内容源的情况下，该网元设备的性能指标包括对应业务小类的访问次数。
41.步骤103、基于每一网元设备的评价指标值，在各网元设备中确定质差网元设备。
42.具体地，获取目标范围内每一网元设备的评价指标值之后，可以通过条件判断、数值计算或数理统计等方式，基于每一网元设备的评价指标值，确定每一网元设备是否为存在故障风险的质差网元设备，进而可以在上述各网元设备中确定存在故障风险的质差网元设备。
43.基于上述各实施例的内容，基于每一网元设备的评价指标值，在各网元设备中确定质差网元设备，包括：基于每一网元设备的设备类型，获取每一网元设备对应的质差判定条件。
44.可选地，获取目标范围内每一网元设备的评价指标值之后，可以基于每一网元设备的设备类型，确定每一网元设备对应的质差判定条件。
45.需要说明的是，不同设备类型对应的质差判定条件可以是根据实际情况和/或先验知识预先确定的。本发明实施例中对上述质差判定条件不作具体限定。
46.可选地，在任一网元设备的设备类型为onu的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的流量大于第一预设值、该网元设备的业务指标值小于第一目标值以及该网元设备的业务指标值小于第二目标值，以及该网元设备接收到的光功率大于第二预设值或该网元设备的下带宽不小于第三预设值的用户数量大于第四预设值。
47.其中，上述第一预设值的取值范围在150m到250m之间；第一目标值可以基于目标范围内设备类型为onu的各网元设备的业务指标值的平均值确定；第二目标值可以基于与该网元设备对应的关联网元设备的业务指标值确定，该网元设备对应的关联网元设备，为与该网元设备连接、拓扑结构位于该网元设备的上级且设备类型为pon接口的网元设备。第二预设值的取值范围可以在-25dbm至-29dbm之间；第三预设值的取值范围可以在80m至120m之间；第四预设值的取值范围可以在1至3人之间。
48.优选地，在任一网元设备的设备类型为onu的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的流量大于100m、该网元设备的业务指标值小于目标范围内设备类型为onu的各网元设备的业务指标值的平均值的70%，该网元设备的业务指标值还小于该网元设备对应的关联网元设备的业务指标值的70%，以及该网元设备接收到的光功率大于-27dbm或该网元设备的下带宽不小于100m的用户数量大于1人。
49.可选地，在任一网元设备的设备类型为pos的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第三目标值且该网元设备的业务指标值小于第四目标值。
50.其中，第三目标值可以基于目标范围内设备类型为pos的各网元设备的业务指标值的平均值确定；第二目标值可以基于该网元设备对应的关联网元设备的业务指标值确定，该网元设备对应的关联网元设备，为与该网元设备连接、拓扑结构位于该网元设备的上级且设备类型为pon接口的网元设备。
51.优选地，在任一网元设备的设备类型为pos的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为pos的各网元设备的业务指标值的平均值的70%，且该网元设备的业务指标值小于该网元设备对应的关联网元
设备的业务指标值的80%。
52.可选地，在任一网元设备的设备类型为pon接口的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第五目标值且该网元设备的业务指标值小于第六目标值，以及该网元设备的带宽利用率不小于第五预设值、该网元设备的接口接收带宽利用率不小于第六预设值、该网元设备接口接收光功的超出量在第一预设区间内和该网元设备接口发送光功率达到超出量在第二预设区间内中的至少一个。
53.其中，第五目标值可以基于目标范围内设备类型为pon接口的各网元设备的业务指标值的平均值确定；第六目标值可以基于该网元设备对应的关联网元设备的业务指标值确定，该网元设备对应的关联网元设备，为设备类型为olt，且为该网元设备归属的网元设备。第五预设值的取值范围可以在75%至85%之间；第六预设值的取值范围可以在75%至85%之间；第一预设区间可以为(-8dbm,-27dbm)；第二预设区间可以为(-8dbm,-27dbm)。
54.优选地，在任一网元设备的设备类型为pon接口的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为pon接口的各网元设备的业务指标值的平均值的80%，且该网元设备的业务指标值小于该网元设备对应的关联网元设备的业务指标值的80%，以及该网元设备的带宽利用率不小于80%、该网元设备的接口接收带宽利用率不小于80%、该网元设备接口接收光功的超出量在(-8dbm,-27dbm)内和该网元设备接口发送光功率达到超出量在(-8dbm,-27dbm)内中的至少一个。
55.可选地，在任一网元设备的设备类型为olt的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第七目标值且该网元设备的业务指标值小于第八目标值，以及该网元设备的cpu利用率不小于第七预设值或者该网元设备的内存利用率不小于第八预设值。
56.其中，第七目标值可以基于目标范围内设备类型为olt的各网元设备的业务指标值的平均值确定；第八目标值可以基于该网元设备对应的关联网元设备的业务指标值确定，该网元设备对应的关联网元设备，为与该网元设备连接、拓扑结构位于该网元设备的上级且设备类型为bras的网元设备。第七预设值的取值范围在60%至80%之间；第八预设值的取值范围在60%至80%之间。
57.优选地，在任一网元设备的设备类型为olt的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为olt的各网元设备的业务指标值的平均值的80%且该网元设备的业务指标值小于该网元设备对应的关联网元设备的业务指标值的80%，以及该网元设备的cpu利用率不小于70%或者该网元设备的内存利用率不小于70%。
58.可选地，在任一网元设备的设备类型为sw的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第九目标值且该网元设备的业务指标值小于第十目标值。
59.其中，第九目标值可以基于目标范围内设备类型为sw的各网元设备的业务指标值的平均值确定；第十目标值可以基于该网元设备对应的关联网元设备的业务指标值确定，该网元设备对应的关联网元设备，为与该网元设备连接、拓扑结构位于该网元设备的上级且设备类型为bras的网元设备。
60.优选地，在任一网元设备的设备类型为sw的情况下，该网元设备对应的质差判定
条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为olt的各网元设备的业务指标值的平均值的80%且该网元设备的业务指标值小于该网元设备对应的关联网元设备的业务指标值的80%。
61.可选地，在任一网元设备的设备类型为bras的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第十一目标值且该网元设备的业务指标值小于第十二目标值，以及该网元设备的cpu利用率不小于第九预设值、该网元设备的内存利用率不小于第十预设值、该网元设备的端口发送带宽利用率不小于第十一预设值、该网元设备的端口接收带宽利用率不小于第十二预设值、该网元设备的端口发送光功率超出量在第三预设区间和该网元设备的端口接收光功率超出量在第四预设区间中的至少一个。
62.其中，第十一目标值可以基于目标范围内设备类型为bras的各网元设备的业务指标值的平均值确定；第十二目标值可以基于该网元设备归属地市内设备类型为bras的各网元设备的业务指标值的平均值确定；第九预设值的取值范围在60%至80%之间；第十预设值的取值范围在60%至80%之间；第十一预设值的取值范围在70%至90%之间；第十二预设值的取值范围在70%至90%之间；第三预设区间可以为(-8dbm,-27dbm)；第四预设区间可以为(-8dbm,-27dbm)。
63.优选地，在任一网元设备的设备类型为bras的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为bras的各网元设备的业务指标值的平均值的90%且该网元设备的业务指标值小于该网元设备归属地市内设备类型为bras的各网元设备的业务指标值的平均值90%，以及该网元设备的cpu利用率不小于70%、该网元设备的内存利用率不小于70%、该网元设备的端口发送带宽利用率不小于80%、该网元设备的端口接收带宽利用率不小于80%、该网元设备的端口发送光功率超出量在(-8dbm,-27dbm)内和该网元设备的端口接收光功率超出量在(-8dbm,-27dbm)内中的至少一个。
64.可选地，在任一网元设备的设备类型为内容源的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于第十三目标值，以及该网元设备对应业务小类的访问次数不小于第十三预设值。
65.其中，第十三目标值可以基于目标范围内设备类型为该网元设备对应的业务大类的各网元设备的业务指标值的平均值确定；第十三预设值的取值范围在8000至12000之间。
66.优选地，在任一网元设备的设备类型为内容源的情况下，该网元设备对应的质差判定条件可以包括：该网元设备的业务指标值小于目标范围内设备类型为该网元设备对应的业务大类的各网元设备的业务指标值的平均值的70%且该网元设备对应业务小类的访问次数不小于10000次。
67.判断每一网元设备的评价指标值是否满足每一网元设备对应的质差判定条件。
68.具体地，获取每一网元设备对应的质差判定条件之后，可以基于每一网元设备对应的质差判定条件，对每一网元设备的评价指标值进行条件判断，以确定每一网元设备的评价指标值是否满足上述每一网元设备对应的质差判定条件。
69.在每一网元设备的评价指标值满足每一网元设备对应的质差判定条件的情况下，将每一网元设备确定为质差网元设备。
70.本发明实施例以dpi作为关键突破点，基于dpi进行多维度的xdr数据的采集，并通
过对上述xdr数据的分解和分析，获取目标范围内每一网元设备的评价指标值，从而能更准确、更高效的获知上述每一网元设备的运行负荷和设备性能，能为网络故障定位提供数据支撑，能提高网络故障定位的准确率和效率，能有效支撑网元设备的及时维护、维修和调优工作，还能基于上述xdr数据实现各区域短板分析，进行地市间、区县间横向对比，能从宏观上掌握全区域网络故障情况、质差情况、业务发展情况及业务感知情况，能更及时的发现问题点，能在影响用户正常使用前进行问题修复，能保持用户网络的正常使用。
71.基于上述各实施例的内容，基于深度数据包检测采集目标维度的xdr数据之后，还包括：在获取到用户的故障投诉信息的情况下，响应于故障投诉信息，基于xdr数据，在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
72.具体地，基于dpi获取目标维度的xdr数据之后，若获取到用户的故障信息，则可以响应于上述故障投诉信息，基于上述故障投诉信息，获取上述用户的身份标识等用户基础信息。
73.基于上述用户的身份标识，可以确定上述用户对应的各网元设备。
74.基于上述xdr数据，可以通过条件判断、数值计算或数理统计等方式，判断上述用户对应的每一网元设备是否为存在故障的故障网元设备，进而可以在上述各网元设备中确定存在故障的故障网元设备。
75.可选地，本发明实施例中可以通过多种方式获取用户的故障投诉信息，例如：可以通过接收到的用户输入，获取用户的故障投诉信息；或者，还可以接收其他电子设备发送的用户的故障投诉信息。
76.本发明实施例通过基于dpi采集到的多维度的xdr数据，为网络中用户侧网元设备的故障定位提供数据支撑，能提高网络中用户侧网元设备故障定位的准确率和效率，能减少故障定位周期，能提高用户投诉解决成功率和响应及时率，能有效提高用户满意度和用户粘性。
77.基于上述各实施例的内容，响应于故障投诉信息，基于xdr数据，在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因，包括：对故障投诉信息进行特征提取。
78.具体地，在获取到用户的故障投诉信息的情况下，可以通过语义分析、关键字提取或机器学习模型等多种方式，对上述故障投诉信息进行特征提取。
79.在从故障投诉信息中提取到特征信息的情况下，基于特征信息，获取故障投诉信息对应的故障排查顺序。
80.具体地，若从用户的故障投诉信息中提取到特征信息，则可以基于上述特征信息，获取上述故障投诉信息对应的故障排查顺序。
81.需要说明的是，上述故障排查顺序可以是根据先验知识和/或实际情况预先确定的。
82.为了便于对本发明实施例中故障排查顺序的理解，以下通过四个实例说明上述故障排查顺序。
83.实例一，在用户的故障投诉信息包括“最近几天，晚上便会出现断线，在20:00-21:00更加明显，基本排障拔插重启无法解决”的信息的情况下，对上述故障投诉信息进行特征提取，从上述故障投诉信息提取到的特征信息包括“断线”、“拔插重启无效”，则基于上述特
征信息，可以确定上述故障投诉信息的故障排查顺序依次为：该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras以及该用户所使用的设备性能排查。
84.实例二，在用户的故障投诉信息包括“上网速度慢，即使计算机用lan线直连ont都只有88mbps，用wifi更只有19mbps，基本排障拔插重启无法解决”的情况下，从上述故障投诉信息提取到的特征信息包括“网速慢”和“wifi信号弱”，则基于上述特征信息，可以确定上述故障投诉信息的故障排查顺序依次为：该用户终端的测速、该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras以及该用户所使用的设备性能排查。
85.实例三，在用户的故障投诉信息包括“计算机直连ont在某一游戏平台玩游戏会断线，基本排障拔插重启无法解决”的情况下，从上述故障投诉信息提取到的特征信息包括“业务问题”和“断线”，则基于上述特征信息，可以确定上述故障投诉信息的故障排查顺序依次为：该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras、该用户所使用的业务对应的指标数据、业务ip分析服务器ping以及dns分析。
86.实例四，在用户的故障投诉信息包括“通过某一业务无法访问目标业务，现象是目标业务会不停转圈，基本排障拔插重启无法解决”从上述故障投诉信息提取到的特征信息包括“业务问题”和“无法并行”，则基于上述特征信息，可以确定上述故障投诉信息的故障排查顺序依次为：该用户终端是否可以通过浏览器打开另一终端、该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras、该业务ip分析上述目标业务的服务器ping以及dns分析。
87.基于xdr数据，按照故障排查顺序对用户对应的各网元设备进行故障排查，进而在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
88.基于上述各实施例的内容，基于xdr数据，在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因之后，还包括：基于故障网元设备和/或故障原因，确定故障投诉信息对应的处理建议。
89.图2为本发明提供的网络故障定位方法中实例一的流程示意图之一。图3为本发明提供的网络故障定位方法中实例一的流程示意图之二。实例一中基于xdr数据，按照上述故障投诉信息对应的故障排查顺序对该用户对应的各网元设备进行故障排查的流程如图2和图3所示。
90.首先，可以基于xdr数据，确定该用户对应的各网元设备中，是否存在质差ont设备。
91.需要说明的是，基于xdr数据确定该用户对应的各网元设备中是否存在质差ont设备的具体过程，可以参加上述各实施例的内容，本发明实施例中不再赘述。
92.同时，可以基于dpi采集该用户对应的aaa下线记录，确认20-21点是否存在频繁下线或异常下线。如图2所示，在上述两个条件均满足的情况下，则认为该用户对应的ont是故障网元设备，处理建议可以包括排查上述ont，对上述ont实施替换等。
93.其中，aaa系统可以实现管理用户，包括用户的权限、开通的业务等信息，并提供用户身份与服务资格的认证和授权，以及计费等服务，可以通过radius进行aaa日志记录的采
集，来分析客户上下线的行为。
94.其次，如图2和图3所示，上述两个条件未均满足的情况下，则需要继续排查该用户对应的端到端网元设备，依次为onu(ont)、pon口、olt和bras，例如检查ont或pon口是否存在接收光功率异常，若存在异常，则处理建议包括排查该用户对应的光纤链路是否存在弯折或损毁等。
95.最后，如图2和图3所示，若该用户对应的端到端网元设备均无异常，则进一步排查该用户topo路由上的设备，是否存在性能指标异常。若该用户topo路由上的设备存在设备性能指标异常，则处理建议包括排查在人员高峰期时，该用户对应的olt/bra是否存在性能瓶颈，是否需要扩容或者调优。
96.需要说明的是，上述性能指标异常的定量规则可以参加上述各实施例中的内容。
97.需要说明的是，不同设备和/或不同光的波长，对应的光功率是不一样的。根据常规经验，可以大体认为其范围如下，具体可以根据项目情况进行二次配置：olt的发送光功率[2dbm, 7dbm]，接收光功率为[-27dbm,
ꢀ‑
6dbm]；ont的发送光功率[-1dbm, 4dbm]，接收光功率为[-24dbm,
ꢀ‑
8dbm]。
[0098]
图4本发明提供的网络故障定位方法中实例二的流程示意图之一。图5本发明提供的网络故障定位方法中实例二的流程示意图之二。实例二中基于xdr数据，按照上述故障投诉信息对应的故障排查顺序对该用户对应的各网元设备进行故障排查的流程如图4和图5所示。
[0099]
首先，可以对该用户终端的实际网速进行测试。
[0100]
在该用户终端的实际网速小于网速阈值的情况下，可以进一步对该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras以及该用户所使用的设备性能排查。上述排查过程可以参见实例一的故障排查流程，此处不再赘述。
[0101]
需要说明的是，由于特征信息还包括“wifi信号弱”，因此在排查到光猫或pon端口光功率异常时，除了要排查光纤链路是否存在弯折或损毁等情况外，还需要该用户终端接收到的wifi信号进行检查，若该用户终端存在wifi信号弱，则处理建议包括与客户沟通是否存在穿墙或距离过远导致的wifi信号差的现象。
[0102]
图6本发明提供的网络故障定位方法中实例三的流程示意图之一。图7本发明提供的网络故障定位方法中实例三的流程示意图之二。实例三中基于xdr数据，按照上述故障投诉信息对应的故障排查顺序对该用户对应的各网元设备进行故障排查的流程如图6和图7所示。
[0103]
需要说明的是，对该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras的排查，可以参见实例一的故障排查流程，此处不再赘述。
[0104]
在上述排查均无异常的情况下，可以检查该用户所使用的业务对应的指标数据，例如：该用户在18-19点玩游戏，从登录成功率和登录时延两个指标看，与同pos端口下的其他用户相比，该用户的登录成功率较低，登录时延较高。与同pon端口、同olt、同bras下的其他用户对比，指标较差的现象更加明显。
[0105]
在该用户所使用的业务对应的指标数据存在异常的情况下，可以进一步对上述指
标数据进行钻取，排查提供该业务的具体服务器的指标情况，在该用户的tcp一二次握手成功率等指标较低，且按照各个服务器维度来分析，只有当前用户所访问的服务器对应的用户平均指标较差，其他几个服务器对应的用户平均指标均较好的情况下，可以确认由于上述服务器的性能等原因，导致该用户访问游戏会出现断线。
[0106]
其中，tcp一二次握手，指客户端发出syn后服务器端收到该syn报文，同时服务端发出syn ack的回复报文后客户端收到syn ack的报文。
[0107]
图8本发明提供的网络故障定位方法中实例四的流程示意图之一。图9本发明提供的网络故障定位方法中实例四的流程示意图之二。实例四中基于xdr数据，按照上述故障投诉信息对应的故障排查顺序对该用户对应的各网元设备进行故障排查的流程如图8和图9所示。
[0108]
首先，由于客户反馈通过某一业务无法访问目标业务，需要先通过浏览器访问上述目标业务。若通过浏览器可以访问上述目标业务，则上述故障投诉信息对应的故障原因可以确认为上述某一业务的客户端的限制，对上述某一业务的客户端进行重新设置即可。若无法通过浏览器访问上述目标业务，则需要按照述故障投诉信息对应的故障排查顺序继续排查。
[0109]
需要说明的是，对该用户对应的ont和该用户对应的下线记录、该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras以及该业务ip分析上述目标业务的服务器ping的排查，可以参见实例三的故障排查流程，此处不再赘述。
[0110]
在tcp一二次成功率为0的情况下，可以说明该用户终端未与业务服务器未建立成功连接，则进一步通过dns分析，查看dns指标情况。
[0111]
分析dns情况，一般考虑如下几种场景：第一，dns解析正常。可能是服务器不可访问，或者服务器ip不正确导致。
[0112]
第二，dns解析失败。可能的原因是ont的dns地址配置被错改，导致dpi能获取到发出去的dns请求，但是未获取到dns反馈的信息，呈现出解析失败的现象。
[0113]
第三，无dns记录。可能的原因是该用户终端有上述目标业务的dns缓存记录，所以没有再发出dns请求，呈现出无dns记录情况。而该用户终端无法访问上述目标业务，则说明缓存中的dns内容是错误，导致了该用户终端无法正常访问。
[0114]
本发明实施例响应于用户的故障投诉信息，基于dpi采集到的多维度的xdr数据和从上述故障投诉信息中提取的特征信息，有针对性的提供了不同的故障定位和处理流程，能进一步提高网络中用户侧网元设备的故障定位和故障原因分析的效率。
[0115]
基于上述各实施例的内容，对故障投诉信息进行特征提取之后，还包括：在未从故障投诉信息提取到特征信息的情况下，按照预设故障排查顺序对用户对应的各网元设备进行故障排查，进而在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
[0116]
具体地，在用户的故障投诉信息中的信息量较少或均为无效信息的情况下，例如用户的故障投诉信息仅包括“网络出现故障”，难以从用户的故障投诉信息中提取到特征信息。
[0117]
在未从用户的故障投诉信息中提取到特征信息的情况下，则可以基于预设故障排查顺序，对该用户对应的各网元设备进行故障排查，从而可以在该用户对应的各网元设备
中确定故障网元设备，和/或，确定上述故障投诉信息对应的故障原因。
[0118]
需要说明的是，上述预设故障排查顺序可以是根据先验知识和/或实际情况预先确定的。例如，上述预设故障排查顺序可以包括该用户对应的onu、该用户对应的pon端口、该用户对应的olt、该用户对应的bras以及该用户所使用的设备性能排查。
[0119]
本发明实施例响应于用户的故障投诉信息，在上述故障投诉信息不包括特征信息的情况下，提供了统一的故障定位和处理流程，能进一步提高网络中用户侧网元设备的故障定位和故障原因分析的效率。
[0120]
基于上述各实施例的内容，基于深度数据包检测采集目标维度的xdr数据之后，还包括：基于xdr数据，获取目标范围内每一用户终端的用户维度指标值。
[0121]
具体地，基于dpi获取目标维度的xdr数据之后，还可以通过数值计算、数理统计等方式，获取目标范围内每一用户终端的用户维度指标值。
[0122]
可选地，本发明实施例中的用户维度指标，包括该用户终端当日累计流量、该用户终端http平均下载速率以及该用户对应的onu接收到的光功率。
[0123]
基于每一用户终端的用户维度指标值，在各用户终端中确定质差用户终端。
[0124]
具体地，获取目标范围内每一用户终端的用户维度指标值之后，可以判断上述每一用户终端的用户维度指标值是否满足预设条件，进行可以基于判断结果，确定每一用户终端是否为存在故障风险的质差用户终端，进而可以在上述各用户终端中确定质差用户终端。
[0125]
可选地，上述预设条件可以包括：用户终端当日累计流量大于第十四预设值、该用户终端http平均下载速率小于第十五目标值以及该用户对应的onu接收到的光功率小于第十五预设值。
[0126]
其中，第十四预设值的取值范围在80m至120m之间；第十五目标值基于与该用户终端对应的olt的http平均下载速率确定；第十五预设值的取值范围在-25dbm至-29dbm之间。
[0127]
优选地，获取目标范围内每一用户终端的用户维度指标值之后，若任一用户终端当日累计流量大于100m，该用户终端http平均下载速率小于与该用户终端对应的olt的http平均下载速率的50%，且该用户对应的onu接收到的光功率小于-27dbm，则可以将该用户终端确定为存在故障风险的质差用户终端。
[0128]
本发明实施例以dpi作为关键突破点，基于dpi进行多维度的xdr数据的采集，并通过对上述xdr数据的分解和分析，获取目标范围内每一用户终端的用户维度指标值，从而能更准确、更高效的获知上述每一用户终端的运行负荷和设备性能，能更准确、更高效的确定上述用户终端是否存在故障风险，能提高用户感知。
[0129]
图10是本发明提供的网络故障定位系统的结构示意图。下面结合图10对本发明提供的网络故障定位系统进行描述，下文描述的网络故障定位系统与上文描述的本发明提供的网络故障定位方法可相互对应参照。如图10所示，该装置包括：数据采集模块1001、数据评价模块1002和故障定位模块1003。
[0130]
数据采集模块1001，用于基于深度数据包检测采集目标维度的xdr数据。
[0131]
数据评价模块1002，用于基于xdr数据，获取目标范围内每一网元设备的评价指标值。
[0132]
故障定位模块1003，用于基于每一网元设备的评价指标值，在各网元设备中确定
质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
[0133]
具体地，数据采集模块1001、数据评价模块1002和故障定位模块1003电连接。
[0134]
可选地，故障定位模块1003还用于在获取到用户的故障投诉信息的情况下，响应于故障投诉信息，基于xdr数据，在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
[0135]
可选地，故障定位模块1003具体用于基于每一网元设备的设备类型，获取每一网元设备对应的质差判定条件；判断每一网元设备的评价指标值是否满足每一网元设备对应的质差判定条件；在每一网元设备的评价指标值满足每一网元设备对应的质差判定条件的情况下，将每一网元设备确定为质差网元设备。
[0136]
故障定位模块1003还具体用于对故障投诉信息进行特征提取；在从故障投诉信息中提取到特征信息的情况下，基于特征信息，获取故障投诉信息对应的故障排查顺序；基于xdr数据，按照故障排查顺序对用户对应的各网元设备进行故障排查，进而在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
[0137]
故障定位模块1003还具体用于在未从故障投诉信息提取到特征信息的情况下，按照预设故障排查顺序对用户对应的各网元设备进行故障排查，进而在用户对应的各网元设备中确定故障网元设备，和/或，确定故障投诉信息对应的故障原因。
[0138]
故障定位模块1003还具体用于基于xdr数据，获取目标范围内每一用户的用户维度指标值；基于每一用户的用户维度指标值，在各用户中确定质差用户。
[0139]
本发明实施例中的网络故障定位系统，以dpi作为关键突破点，基于dpi进行多维度的xdr数据的采集，并通过对上述xdr数据的分解和分析，获取目标范围内每一网元设备的评价指标值，从而能更准确、更高效的获知上述每一网元设备的运行负荷和设备性能，能为网络故障定位提供数据支撑，能提高网络故障定位的准确率和效率，能有效支撑网元设备的及时维护、维修和调优工作，还能基于上述xdr数据实现各区域短板分析，进行地市间、区县间横向对比，能从宏观上掌握全区域网络故障情况、质差情况、业务发展情况及业务感知情况，能更及时的发现问题点，能在影响用户正常使用前进行问题修复，能保持用户网络的正常使用。
[0140]
基于上述各实施例的内容，网络故障定位系统，还包括：用户交互界面；用户交互界面用于显示xdr数据、每一网元设备的评价指标值以及质差网元设备的设备信息中的至少一种。
[0141]
可选地，用户交互界面可以通过多种方式，例如：表格、图形以及文字等，显示上述xdr数据、每一网元设备的评价指标值以及质差网元设备的设备信息中的至少一种。
[0142]
本发明实施例中的网络故障定位系统还包括用户交互界面，能更直观、更便捷的向运维人员进行数据展示，便于运维人员进行数据查看和数据分析，能提高运维人员的工作效率。
[0143]
图11示例了一种电子设备的实体结构示意图，如图11所示，该电子设备可以包括：处理器(processor)1110、通信接口(communications interface)1120、存储器(memory)1130和通信总线1140，其中，处理器1110，通信接口1120，存储器1130通过通信总线1140完成相互间的通信。处理器1110可以调用存储器1130中的逻辑指令，以执行网络故障定位方
法，该方法包括：基于深度数据包检测采集目标维度的xdr数据；基于xdr数据，获取目标范围内每一网元设备的评价指标值；基于每一网元设备的评价指标值，在各网元设备中确定质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
[0144]
此外，上述的存储器1130中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器（rom，read-only memory）、随机存取存储器（ram，random access memory）、磁碟或者光盘等各种可以存储程序代码的介质。
[0145]
另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的网络故障定位方法，该方法包括：基于深度数据包检测采集目标维度的xdr数据；基于xdr数据，获取目标范围内每一网元设备的评价指标值；基于每一网元设备的评价指标值，在各网元设备中确定质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
[0146]
又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的网络故障定位方法，该方法包括：基于深度数据包检测采集目标维度的xdr数据；基于xdr数据，获取目标范围内每一网元设备的评价指标值；基于每一网元设备的评价指标值，在各网元设备中确定质差网元设备；其中，评价指标包括业务指标，或者业务指标和性能指标。
[0147]
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
[0148]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。
[0149]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。