CN117459365A - 故障原因确定方法、装置、设备及存储介质 - Google Patents
故障原因确定方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN117459365A CN117459365A CN202311576309.0A CN202311576309A CN117459365A CN 117459365 A CN117459365 A CN 117459365A CN 202311576309 A CN202311576309 A CN 202311576309A CN 117459365 A CN117459365 A CN 117459365A
- Authority
- CN
- China
- Prior art keywords
- data
- target
- alarm
- fault
- determining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 76
- 238000003860 storage Methods 0.000 title claims abstract description 25
- 230000001364 causal effect Effects 0.000 claims abstract description 55
- 238000012545 processing Methods 0.000 claims description 73
- 230000002159 abnormal effect Effects 0.000 claims description 44
- 230000005856 abnormality Effects 0.000 claims description 7
- 238000012216 screening Methods 0.000 claims description 7
- 238000001514 detection method Methods 0.000 abstract description 12
- 238000004891 communication Methods 0.000 abstract description 11
- 230000004888 barrier function Effects 0.000 description 57
- 238000004458 analytical method Methods 0.000 description 27
- 230000003287 optical effect Effects 0.000 description 27
- 238000012360 testing method Methods 0.000 description 18
- 230000006870 function Effects 0.000 description 13
- 238000012423 maintenance Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 8
- 238000013461 design Methods 0.000 description 7
- 238000005520 cutting process Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000013473 artificial intelligence Methods 0.000 description 2
- 238000013499 data model Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000008447 perception Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 241000282414 Homo sapiens Species 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000001212 derivatisation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000005764 inhibitory process Effects 0.000 description 1
- 238000003058 natural language processing Methods 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
- H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请公开了一种故障原因确定方法、装置、设备及存储介质，涉及通信技术领域，用于提高不同类型的设备的群体性故障的检测效率，以及提高确定造成群体性故障的原因的准确度，包括：获取目标网络的多个目标告警数据和多个目标工单数据；从多个目标告警数据中确定出多组故障数据，并从多个目标工单数据中确定出多组申告数据；基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
Description
技术领域
本申请涉及通信技术领域，尤其涉及一种故障原因确定方法、装置、设备及存储介质。
背景技术
随着通信网络的不断发展，网络覆盖范围不断扩大，造成网络故障的原因也多种多样。特别是出现群体性故障时，大量设备发出告警，或者大量用户发出申告给运营商，运营商根据告警或申告信息进行群体性故障的确定，并基于相关运维人员的经验进行处理。
目前只有针对接入网等有源设备发出告警进行群体性故障的确定，并构建知识图谱进行处理，缺少对各种无源设备的群体性故障的确定和处理；并且，在构建知识图谱后，还需要相关运维人员依据个人经验对群体性故障的原因进行分析，进而进行故障处理。因此，针对不同类型的设备的群体性故障的检测效率较低，确定造成群体性故障的原因的准确度较低。
发明内容
本申请提供一种故障原因确定方法、装置、设备及存储介质，用于提高不同类型的设备的群体性故障的检测效率，以及提高确定造成群体性故障的原因的准确度。
为达到上述目的，本申请采用如下技术方案：
第一方面，提供了一种故障原因确定方法，该方法包括：获取目标网络的多个目标告警数据和多个目标工单数据，多个目标告警数据为构成目标网络的多个网络设备发出的告警信息，多个目标工单数据为用户通过终端设备发出的网络异常申告，多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度；从多个目标告警数据中确定出多组故障数据，并从多个目标工单数据中确定出多组申告数据，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同；基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
在一种可能的实现方式中，获取目标网络的多个目标告警数据和多个目标工单数据，包括：获取目标网络的多个告警数据和多个工单数据；确定多个告警数据中的每个告警数据所指示的异常设备，和多个工单数据中的每个工单数据所指示的异常设备；基于每个异常设备所执行的网络业务，从多个告警数据中筛选出多个目标告警数据，并从多个工单数据中筛选出多个目标工单数据。
在一种可能的实现方式中，从多个目标告警数据中确定出多组故障数据，包括：确定多个目标告警数据中的每个目标告警数据的告警类型；基于每个目标告警数据的告警类型，将多个目标告警数据划分为多组告警数据，多组告警数据中的每组告警数据包括同一告警类型的目标告警数据；针对多组告警数据中的任一组告警数据，基于任一组告警数据对应的预设模型，从任一组告警数据中的目标告警数据中确定出多组故障数据，每组告警数据对应不同的预设模型。
在一种可能的实现方式中，方法还包括：基于多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级，一组故障数据的优先级与包括的目标告警数据的数量成正比。
在一种可能的实现方式中，从多个目标工单数据中确定出多组申告数据，包括：确定多个目标工单数据中的每个目标工单数据所属的目标区域范围，目标区域范围为多个预设区域范围中的区域范围；基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量；在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将任一预设区域范围内包含的目标工单数据确定为一组申告数据。
在一种可能的实现方式中，基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因，包括：基于多个对象中的任意两个对象之间的因果关系，构建目标知识图谱；针对任一告警数据或任一工单数据，确定目标知识图谱中任一告警数据或任一工单数据对应的目标节点；确定目标知识图谱中，与目标节点具有因果关系的至少一个第一邻节点，至少一个第一邻节点为与目标节点直接相邻或间接相邻的节点，至少一个第一邻节点为事件对象的节点；从至少一个第一邻节点中确定出第二邻节点，第二邻节点为至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点；基于第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
第二方面，提供了一种故障原因确定装置，该故障原因确定装置包括：获取单元和处理单元；获取单元，用于获取目标网络的多个目标告警数据和多个目标工单数据，多个目标告警数据为构成目标网络的多个网络设备发出的告警信息，多个目标工单数据为用户通过终端设备发出的网络异常申告，多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度；处理单元，用于从多个目标告警数据中确定出多组故障数据，并从多个目标工单数据中确定出多组申告数据，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同；处理单元，还用于基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；处理单元，还用于基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
在一种可能的实现方式中，获取单元，具体用于获取目标网络的多个告警数据和多个工单数据；处理单元，具体用于确定多个告警数据中的每个告警数据所指示的异常设备，和多个工单数据中的每个工单数据所指示的异常设备；处理单元，具体用于基于每个异常设备所执行的网络业务，从多个告警数据中筛选出多个目标告警数据，并从多个工单数据中筛选出多个目标工单数据。
在一种可能的实现方式中，处理单元，具体用于确定多个目标告警数据中的每个目标告警数据的告警类型；处理单元，具体用于基于每个目标告警数据的告警类型，将多个目标告警数据划分为多组告警数据，多组告警数据中的每组告警数据包括同一告警类型的目标告警数据；处理单元，具体用于针对多组告警数据中的任一组告警数据，基于任一组告警数据对应的预设模型，从任一组告警数据中的目标告警数据中确定出多组故障数据，每组告警数据对应不同的预设模型。
在一种可能的实现方式中，处理单元，还用于基于多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级，一组故障数据的优先级与包括的目标告警数据的数量成正比。
在一种可能的实现方式中，处理单元，具体用于确定多个目标工单数据中的每个目标工单数据所属的目标区域范围，目标区域范围为多个预设区域范围中的区域范围；处理单元，具体用于基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量；处理单元，具体用于在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将任一预设区域范围内包含的目标工单数据确定为一组申告数据。
在一种可能的实现方式中，处理单元，具体用于基于多个对象中的任意两个对象之间的因果关系，构建目标知识图谱；处理单元，具体用于针对任一告警数据或任一工单数据，确定目标知识图谱中任一告警数据或任一工单数据对应的目标节点；处理单元，具体用于确定目标知识图谱中，与目标节点具有因果关系的至少一个第一邻节点，至少一个第一邻节点为与目标节点直接相邻或间接相邻的节点，至少一个第一邻节点为事件对象的节点；处理单元，具体用于从至少一个第一邻节点中确定出第二邻节点，第二邻节点为至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点；处理单元，具体用于基于第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
第三方面，一种电子设备，包括：处理器以及存储器；其中，存储器用于存储一个或多个程序，一个或多个程序包括计算机执行指令，当电子设备运行时，处理器执行存储器存储的计算机执行指令，以使电子设备执行如第一方面的一种故障原因确定方法。
第四方面，提供了一种存储一个或多个程序的计算机可读存储介质，该一个或多个程序包括指令，上述指令当被计算机执行时使计算机执行如第一方面的一种故障原因确定方法。
本申请提供了一种故障原因确定方法、装置、设备及存储介质，应用于确定网络故障的场景中。首先获取构成目标网络的多个网络设备发出的多个目标告警数据，并获取用户通过终端设备发出的网络异常申告的多个目标工单数据，并且多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度。然后从多个目标告警数据中确定出多组故障数据，其中每组故障数据中的目标告警数据的告警类型相同；并从多个目标工单数据中确定出多组申告数据，其中每组申告数据中的目标工单数据所属的地理区域范围相同。进一步，基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，进而基于多个对象中的任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。通过上述方法，可以根据网络的多个目标告警数据和多个目标工单数据，确定多组故障数据和多组申告数据，进而确定任意两个对象之间的因果关系，从而确定任一告警数据或任一工单数据的根本故障原因。因此，有效提高了网络中不同类型的设备的群体性故障的检测效率，并且提高了确定故障的根本原因的准确度。
附图说明
图1为本申请的实施例提供的一种故障原因确定系统结构示意图；
图2为本申请的实施例提供的一种故障原因分析系统结构示意图；
图3为本申请的实施例提供的一种故障原因确定方法流程示意图一；
图4为本申请的实施例提供的一种故障原因确定方法流程示意图二；
图5为本申请的实施例提供的一种故障原因确定方法流程示意图三；
图6为本申请的实施例提供的一种故障原因确定方法流程示意图四；
图7为本申请的实施例提供的一种故障原因确定方法流程示意图五；
图8为本申请的实施例提供的一种故障原因确定方法流程示意图六；
图9为本申请的实施例提供的一种知识图谱结构示意图；
图10为本申请的实施例提供的一种故障原因确定装置结构示意图；
图11为本申请的实施例提供的一种电子设备结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
在本申请的描述中，除非另有说明，“/”表示“或”的意思，例如，A/B可以表示A或B。本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。此外，“至少一个”“多个”是指两个或两个以上。“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
在网络运营过程中，可能发生网络的群体性故障(又称为群障)，严重影响用户的使用体验，而通过各种技术手段，对影响用户的网络问题进行分析，确定故障原因及其用户影响面至关重要。通过确定故障原因及其用户影响面，可以使网络运维人员更准确的确定网络故障的业务影响、服务于客服人员更准确的回复用户投诉。
目前对网络故障或群障的分析，主要为接入网的群障，没有光纤、机房动力环境监控等方面的群障分析；并且对无源设备(例如分光器、线缆)导致的群障没有诊断能力；没有对群障的原因进行分析，造成运维人员故障分析时长较长；没有以小区、行政区域为群障对象的申告群障，并且对没有发出申告的，但影响用户感知的网络运营事件没有进行及时管理；没有发现的网络运营事件之间的关系。
本申请实施例提供的一种故障原因确定方法，可以适用于故障原因确定系统。图1示出了该故障原因确定系统的一种结构示意图。如图1所示，故障原因确定系统20包括：电子设备21和多个网络设备22。
多个网络设备22可以为运营商对应的多个网络设备，为用户提供的专线业务网络，例如互联网专网络、传输专线网络，也可以为用户提供的家庭宽带业务网络。
电子设备21可以获取多个网络设备22的多个目标告警数据和多个目标工单数据，然后从多个目标告警数据中确定告警类型相同的多组故障数据，并从多个目标工单数据中确定出所属的地理区域范围相同的多组申告数据，进一步根据多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，从而确定导致任一告警数据或任一工单数据的根本故障原因。
示例性的，如图2所示，为电子设备中包含的故障原因分析系统结构示意图。故障原因分析系统包括：告警采集处理模块、工单事件采集模块、业务影响分析模块、故障群障分析模块、申告群障分析模块、运营事件根因分析模块和网络运营事件图谱。
其中，告警采集处理模块包括：接入网告警采集、数据网告警采集、传送网告警采集、光缆告警采集和动环告警采集。
工单事件采集模块包括：故障单采集、申告单采集、割接单采集和群障单采集。
业务影响分析模块包括：网络组网拓扑、网络设备资源信息、业务资源信息和业务状态主动探测。
故障群障分析模块包括：端口群障、设备群障、同设备下多端口群障、同机房下多设备群障、哑资源群障和跨域同向群障。
申告群障分析模块包括：小区申告群障、行政区申告群障和跨域同向申告群障。
运营事件根因分析模块包括：告警根因定位、跨事件根因定位、割接单工程预约、多级故障群障根因定位和多级申告群障根因定位。
网络运营事件图谱包括：申告单创建拦截、申告单域群障单合并、用户业务状态查询、群障单关联抑制和故障单与群障单合并。
下面结合附图对本申请实施例提供的一种故障原因确定方法进行描述。如图3所示，本申请实施例提供的一种故障原因确定方法，包括：
S201、获取目标网络的多个目标告警数据和多个目标工单数据。
其中，多个目标告警数据为构成目标网络的多个网络设备发出的告警信息，多个目标工单数据为用户通过终端设备发出的网络异常申告，多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度。
具体的，首先可以通过各种专业的网管系统等方式，来获取目标网络的多个告警数据，并通过用户电话申诉或应用程序申诉等方式，来获取多个工单数据，再确定多个告警数据中的每个告警数据所指示的异常设备，和多个工单数据中的每个工单数据所指示的异常设备，进而根据异常设备所执行的网络业务，确定出多个目标告警数据和多个目标工单数据。
S202、从多个目标告警数据中确定出多组故障数据。
其中，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同。
具体的，可以首先确定每个目标告警数据的告警类型，并将相同告警类型的数据划分到一组，进而对每组的告警数据进行分析，得到多组故障数据。
S203、从多个目标工单数据中确定出多组申告数据。
其中，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同。
具体的，可以确定多个目标工单数据中的每个目标工单数据所属的目标区域范围，进而确定每个预设区域范围内包含的目标工单数据的数量，从而判断任一预设区域范围内包含的目标工单数据的数量是否大于预设阈值，并将目标工单数据的数量大于预设阈值的任一预设区域范围内包含的目标工单数据确定为一组申告数据。
S204、基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系。
其中，多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备。
可选的，多个事件对象可以包括以下任一项：网络告警事件、故障群障事件、申告群障事件、故障工单事件、申告工单事件或割接工单事件。其中，网络告警事件：由网管系统产生的网络异常事件，由“告警采集处理模块”创建。故障群障事件：根据网络告警事件及其业务影响，基于决策模型判断生成的群障事件，由“故障群障分析模块”创建。申告群障事件：根据用户申报的网络质量事件，基于决策模型判断生成的群障事件，由“申告群障分析模块”创建。故障工单事件：由各类监控系统生成，对需要人工关注并处置的告警事件派发工单，由“工单事件采集模块”创建。申告工单事件：由用户申报的网络质量事件，由“工单事件采集模块”创建。割接工单事件：由网络运维人员针对网络变更所创建的割接工单。
可选的，多个业务对象可以包括以下任一项：专线业务或家庭宽带业务。其中，专线业务：由网络运营商提供的专线业务，包含互联网专线、传输专线等业务。家庭宽带业务：由网络运营商提供的家庭宽带业务。
可选的，因果关系可以包括以下任一项：导致、影响或衍生。其中，导致：表示一个事件导致另一个或多个事件发生。影响：表示一个事件对一个或多个业务产生影响。衍生：表示一个事件是由另一个事件衍生的。
具体的，根据多个对象以及因果关系，可以确定任意两个对象之间的因果关系。
可选的，任意两个对象之间的因果关系是双向的。特别是，在根据任意两个对象之间的因果关系构建目标知识图谱时，两个对象之间的因果关系是一致的(例如A对象与B对象之间的因果关系为导致，则无论对于A对象还是B对象来说，A对象与B对象之间的因果关系均为导致)，因此可以忽略在目标知识图谱构建时会存在时延，并且避免在全局搜索导致的性能损失。
可选的，故障群障事件与故障群障事件之间：对于单设备多端口群障，如果单设备关联的端口告警产生了单端口群障，则定义单设备多端口群障导致单端口群障；对于机房群障，如果机房关联的设备告警产生了单设备群障，则定义机房群障导致单设备群障。
网络告警事件与故障群障事件之间：根据各类故障群障创建时统计到的网络告警，定义是由故障群障导致的网络告警。
网络告警事件与故障工单事件之间：对于故障工单，根据故障工单创建时使用的告警流水号，关联网络告警，定义由网络告警事件衍生故障工单事件。
网络告警事件与割接工单事件之间：对于割接工单，根据割接工单对应工程实施的网络对象，将割接工单对应工程在预约时间段内产生的告警，定义为由割接工单事件导致网络告警事件。
故障群障事件与申告群障事件之间：根据申告群障关联的申告工单，查询申告工单业务号码是否能关联到活动的故障群障。对于通过申告工单关联次数最多的故障群障，定义该故障群障事件导致了申告群障事件。
申告工单事件与申告群障事件之间：对于各类申告群障，根据每类申告群障创建时统计到的申告工单，定义是由申告群障事件导致的这些申告工单事件。
网络告警事件与业务对象之间：取其UDM中的业务影响，定义为网络告警事件影响了业务对象。
故障群障事件与业务对象之间：取故障群障关联的网络告警的实际业务影响的并集，定义为故障群障事件影响了业务对象。
申告群障事件与业务对象之间：取申告群障关联的申告工单关联业务的并集，定义为申告群障事件影响了业务对象。
申告工单事件与业务对象之间：取申告工单中业务号码来查询业务，定义为业务对象衍生了申告工单事件。
可选的，确定多个对象后，对每个对象赋值其通用属性。其中通用数据可以包括以下至少一项：事件状态、事件对象名称、事件唯一定位符、事件源、事件现象、事件对象、事件处置部门、事件开始时间、事件结束时间和事件集。事件状态：事件是否为活动事件。事件对象名称包括：网络告警事件、故障群障事件、申告群障事件、故障工单事件、申告工单事件或割接工单事件。事件唯一定位符：对于群障或告警类的事件，事件唯一定位符为告警流水号；对于工单类的事件，事件唯一定位符为工单编号。事件源：事件创建的对象，指由什么系统创建。事件现象：派单人员或系统对于事件现象的描述。事件对象：事件处置的对象，对于故障、割接等事件，事件对象为网络设备、端口、板卡、机房等物理对象。对于申告、工单等事件，事件对象为业务对象。事件处置部门：根据事件对象，根据业务影响分析模块，预设的处置部门。事件开始时间：事件的开始时间。事件结束时间：事件的结束时间。事件集：将确定根本性原因的事件对象放置在事件集中。
可选的，在后续对目标网络的故障进行修复后，会产生对应的清除事件。因此，可以通过事件唯一定位符查询相关对象，并在目标知识图谱确定相关的节点，并修改节点的事件状态的属性为清除，从而将节点删除，保证目标知识图谱的时效性。
S205、基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
具体的，可以根据任意两个对象之间的因果关系，构建知识图谱，进而在知识图谱中，可以利用根本原因分析方法(Root Cause Analysis，RCA)，对数据进行分析，从而可以得到造成网络群障的根本原因，进而帮助网络运维人员对网络进行修复。
具体的，可以根据构建的目标知识图谱，首先确定任一目标节点，再确定目标节点具有因果关系的第一邻节点，并确定多个邻节点中与其他邻节点相邻数量最多的第二邻节点，即为根本节点，从而确定该目标节点的根本故障原因。
本申请实施例中，首先获取构成目标网络的多个网络设备发出的多个目标告警数据，并获取用户通过终端设备发出的网络异常申告的多个目标工单数据，并且多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度。然后从多个目标告警数据中确定出多组故障数据，其中每组故障数据中的目标告警数据的告警类型相同；并从多个目标工单数据中确定出多组申告数据，其中每组申告数据中的目标工单数据所属的地理区域范围相同。进一步，基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，进而基于多个对象中的任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。通过上述方法，可以根据网络的多个目标告警数据和多个目标工单数据，确定多组故障数据和多组申告数据，进而确定任意两个对象之间的因果关系，从而确定任一告警数据或任一工单数据的根本故障原因。因此，有效提高了网络中不同类型的设备的群体性故障的检测效率，并且提高了确定故障的根本原因的准确度。
在一种设计中，如图4所示，本申请实施例提供的一种故障原因确定方法，上述步骤S201中的方法，具体可以包括步骤S301-S303：
S301、获取目标网络的多个告警数据和多个工单数据。
可选的，可以通过各种专业的网管系统，来获取目标网络的多个告警数据。各种专业网管系统包括：接入专业网管，主要覆盖接入层无源光纤网络(Passive OpticalNetwork，PON)；数通专业网管，主要覆盖城域网路由器(Route)、交换机(Switch)等设备；传输专业网管，主要覆盖同步数字体系(Synchronous Digital Hierarchy，SDH)、光传送网(Optical Transport Network，OTN)等设备；动环监控系统，主要覆盖各机房动力相关设备，例如市电配电、发电机、电源等；光缆监控系统，主要通过仪表，覆盖核心、汇聚各局点间光缆。
可选的，可以通过系统包括的告警采集处理模块，通过发送/订阅消息传输协议或方式(例如Socket协议、Jms协议、Kafka协议等)，来获取各种专业告警数据；或者，通过系统包括的工单事件采集模块，获取各种工单数据，并将各告警数据和各工单数据映射至统一数据模型(Unified Data Model，UDM)中，进一步将报文数据推送至消息总线(MessageBus)用于后续数据处理。
可选的，除了获取目标网络的多个告警数据和多个工单数据，还需要获取目标网络中的各类网络资源信息。可以通过网络资源管理系统进行获取各类网络资源信息，包括网络组网拓扑信息、设备管理维护信息、客户业务路由信息、客户业务基本信息、局站基本信息等。其中，客户业务路由信息包括专线业务、家庭宽带业务。
需要说明的是，虽然存在多个告警数据和多个工单数据，但部分告警数据或工单数据对网络业务的影响度较小，无需进行故障的根本原因分析，因此，从多个告警数据和多个工单数据中，筛选出对网络业务的影响度大于预设影响度的多个目标告警数据和多个目标工单数据，进而进行分析，判断出根本故障原因，进而由运维人员进行处理，保证网络的正常使用。
具体的，可以首先确定多个告警数据中的每个告警数据和多个工单数据中的每个工单数据中网络异常的设备，进而对网络异常的设备所对应的网络业务进行测试，判断是否对网络业务的影响度大于预设影响度。
可选的，筛选出多个目标告警数据和多个目标工单数据，除了可以用于构建目标知识图谱，确定根本故障原因，还可以直接将多个目标告警数据和多个目标工单数据以及指示的异常设备的位置信息，告知相关运维人员，对告警或工单事件进行处理。
S302、确定多个告警数据中的每个告警数据所指示的异常设备，和多个工单数据中的每个工单数据所指示的异常设备。
具体的，可以通过系统包括的业务影响分析模块，根据UDM中的各告警数据和各工单数据，确定多个告警数据中的每个告警数据和多个工单数据中的每个工单数据所指示的异常设备，以及异常设备在目标网络中的拓扑位置，进而可以确定异常设备所执行的网络业务。
可选的，多个告警数据中的每个告警数据和多个工单数据中的每个工单数据所指示的异常设备可能是局站(动环)、光缆、设备、板卡、端口、子端口、时隙。
S303、基于每个异常设备所执行的网络业务，从多个告警数据中筛选出多个目标告警数据，并从多个工单数据中筛选出多个目标工单数据。
可选的，基于每个异常设备所执行的网络业务，首先可以根据预设的告警经验库中基于专家经验构建的告警(或工单)对网络业务的影响，确定告警数据(或工单数据)对网络业务的可能的影响，初步筛选出可能对网络业务的影响度大于预设影响度的告警数据(或工单数据)，进一步利用拨测技术，综合判断网络业务的主动探测结果，得到主动探测结论，确定出影响度大于预设影响度的多个目标告警数据和多个目标工单数据。
可选的，在使用告警经验库筛选出的告警数据和工单数据的数据量较多，如果全部使用拨测技术进行探测，所消耗的时间较长，从而影响系统的时效性，并且，同一个告警数据(或同一个工单数据)可能同时影响多种类型的业务，例如城域网设备故障同时影响互联网专线接入服务(Dedicated Internet Access，DIA)业务与家庭宽带，因此，可以采用抽样拨测，综合判断多个告警数据和多个工单数据对网络业务的影响度。
示例性的，根据每个异常设备所执行的网络业务，首先判断业务类型，为专线业务，还是家庭宽带业务，并将每个异常设备所执行的网络业务存放在受影响的专线业务列表或受影响的家庭宽带业务列表中，再使用拨测技术筛选确定出多个目标告警数据和多个目标工单数据的决策模型的描述如下：
输入:
受影响的专线业务列表：C，受影响的家庭宽带业务列表：I，拨测上限数：T，拨测正常门限：Y
输出:
拨测总结论；专线业务拨测结论；家庭宽带业务拨测结论
决策模型:
1、分别对C、I进行抽样，Cn为受影响的专线业务的数量，In为受影响的家庭宽带业务的数量。
2、如果Cn小于或等于T，则取C作为拨测专线业务清单Ci；如果Cn大于T，则在C中随机抽取T个专线业务，作为Ci。
3、如果In小于或等于T，则取I作为拨测专线业务清单Ii；如果In大于T，则在I中随机抽取T个专线业务，作为Ii。
4、对Ci与Ii进行拨测流程，获得Cr、Ir作为拨测异常业务清单。
5、计算拨测结果中正常业务占所有业务的比例Pc、Pi。
6、如果Pc大于Y则认为专线业务拨测正常，如果Pi大于Y则认为专线业务拨测正常。
7、如果两种类型的业务拨测均为正常，则认为业务正常，如果业务拨测存在不正常，则认为业务不正常，对应筛选确定出多个目标告警数据和多个目标工单数据。
可选的，除了使用拨测技术确定多个目标告警数据和多个目标工单数据，还可以通过AAA系统，根据用户登录使用的业务号码，获取在线鉴权信息，如用户的网络业务离线，则认为此网络业务受到告警影响，计入实际影响业务。对于不支持AAA系统的业务，可以通过业务拓扑得知用户终端上联链路，通过指令系统，登录节点设备，通过下发指令获取此业务相关端口信息，如获取不到对端的mac地址信息，则认为此业务受影响，计入实际影响业务。另外，还可以在用户侧部署探针，来确定告警是否影响网络业务。特别的，对于传输业务(SDH、OTN)，判断其支路侧是否有业务信号丢失告警，如果有业务信号丢失告警，则认为此业务受影响，计入目标告警数据或目标工单数据。
其中，AAA系统是通过远程用户拨号认证系统(Remote Authentication Dial InUser Service，Radius)协议实现对网络接入设备的验证、授权、计费功能，包含用户业务相关认证信息。指令系统是通过远程终端协议(telnet协议)等登录网络设备，获取设备当前运行信息，包括端口在线状态和对端mac地址等信息。
需要说明的是，在基于告警经验库对各告警数据或各工单数据进行判断可能的影响度时，对于例如环网保护、1+1保护、1:1保护等各类设备的保护部分所产生的告警数据，均认为对网络业务可能的影响度大于预设影响度。因此，可以屏蔽各种保护策略，仅确定较大的可能影响网络业务的范围，下一步通过拨测，确定具体的对网络业务的影响度。
本申请实施例中，通过获取多个告警数据和多个工单数据，进而确定各告警数据和各工单数据所指示的异常设备，可以首先通过告警知识库，确定可能对网络业务产生影响的告警数据和工单数据，进一步通过拨测等方式，确定出对网络业务存在影响的多个目标告警数据和多个目标工单数据，保证数据源对网络业务的影响的准确度，从而更好对网络业务存在影响的数据进行分析，确定出根本故障原因。
在一种设计中，如图5所示，本申请实施例提供的一种故障原因确定方法，上述步骤S202中的方法，具体可以包括步骤S401-S403：
S401、确定多个目标告警数据中的每个目标告警数据的告警类型。
需要说明的是，由于目标告警数据所属网络层级、所属设备、所属机房、承载业务的特性、影响用户的等级等信息存在不同，因此不同的目标告警数据存在不同的告警类型，并且不同的告警类型具有不同的决策分析方法，因此，需要将多个目标告警数据按设备类型，划分不同的告警类型。
示例性的，告警类型可以包括以下至少一项：单端口告警、单板卡告警、单设备告警、单设备多端口告警、机房告警和分光器告警等。
其中，单设备多端口告警为多个端口发出告警数据，而多个端口位于同一台设备上。机房告警为机房内动环或设备发出告警数据，而动环上报的动力告警数据或特定数量的设备上报的脱网告警等告警数据来自同一个机房。分光器告警为多个光网络单元(Optical Network Unit，ONU)发出告警数据，而根据网络拓扑，采用路径公共点分析算法，可以确定多个光网络单元挂载在同一分光器上。
S402、基于每个目标告警数据的告警类型，将多个目标告警数据划分为多组告警数据。
其中，多组告警数据中的每组告警数据包括同一告警类型的目标告警数据。
具体的，根据每个目标告警数据的告警类型，将告警类型相同的目标告警数据划分到一组告警数据中，从而将多个目标告警数据划分为多组告警数据中。
S403、针对多组告警数据中的任一组告警数据，基于任一组告警数据对应的预设模型，从任一组告警数据中的目标告警数据中确定出多组故障数据。
其中，每组告警数据对应不同的预设模型。
具体的，基于预设模型，将多组告警数据中的每组告警数据按照告警类型进行不同方案的分析处理，从而得到包含群障的多组故障数据。
可选的，对于告警类型为单设备多端口告警、机房告警和分光器告警的组告警数据，因为涉及多个告警数据作为该组故障数据的触发条件，因此，可以采用滑动时间窗算法，通过位于滑动窗口内的活动告警信息，判断是否达到该组故障数据的触发条件。
需要说明的是，采用滑动时间窗算法是为了避免在固定时间窗的固定阈值的情况下，跨窗口的事件会被分割到不同的窗口中，造成时间截断的问题，从而导致告警数据达不到阈值而无法确定为群障。采取滑动时间窗算法可以在告警数据达到阈值的情况下即可确定为群障，减少被窗口截断的可能，提高群障判断准确性，减少了重复事件。
需要说明的是，本申请采用规则引擎(Business Rules Management System)来实现的决策模型，具体的决策模型采用决策模型标记规则(Decision Model and Notation，DMN)进行定义。为方便相关领域的技术人员理解，本申请的决策模型采用文字和公式进行描述。
示例性的，根据告警类型为单端口告警、单板卡告警或单设备告警的目标告警数据，确定目标告警数据对应的告警数据流水号，以及与目标告警数据相关联的影响网络业务的数量，再根据预设模型中的单告警决策模型进行分析处理，确定该组告警数据。
示例性的，预设模型中的单告警决策模型的描述如下：
输入:
当前告警数据流水号：serialNo
当前告警类型：objType；
受影响的专线业务数量：Cn；
受影响的家庭宽带业务数量：In。
单设备专线业务触发门限：T1
单设备家庭宽带业务触发门限：T2
单端口、单板卡专线业务触发门限：T3
单端口、单板卡家庭宽带业务触发门限：T4
当前活动群障列表：L
输出:
是否产生故障群障
决策模型：
1、判断流水号为serialNo的告警数据是否在L中已经出现过，若已出现，则说明此告警数据已记录过，从而不产生新的群障，结束决策判断。
2、如果告警类型objType为单设备，并且Cn大于或等于T1(或In大于或等于T2)，则确定为一组故障数据。
3、如果告警类型objType为单端口(或单板卡)，并且Cn大于或等于T3(或In大于或等于T4)，则确定为一组故障数据。
示例性的，将告警类型为单设备多端口告警的目标告警数据，存放在活动端口告警列表中，然后根据滑动时间窗算法中的滑动窗口触发周期、窗口大小和当前滑动时间窗中的活动群障列表，并使用预设模型中的单设备多端口决策模型进行分析处理，从而确定该组告警数据。
示例性的，预设模型中的单设备多端口决策模型的描述如下：
输入：
活动端口告警列表：L
滑动窗口触发周期：P
窗口大小：S
单设备下故障端口数量门限：T1
当前活动群障列表：M
输出：
需产生多端口群障的设备清单
决策模型：
1、每P分钟，取L中告警创建时间距当前时间在S内的端口告警数据L1，需注意的是此处P需远小于S。
2、判断这些端口告警数据是否出现在M中，若已出现，则说明此告警数据已记录过，从而结束决策判断。
3、根据L1中告警对象端口所属设备对L1进行分组，得到每台设备在L1中活动告警数量。
4、返回大于门限T1的该设备，以及与该设备关联的多个端口的告警数据作为一组故障数据。
示例性的，根据告警类型为机房告警的目标告警数据，判断机房告警为动环告警或设备脱网告警，若机房告警为动环告警，则将机房告警存放在活动动环告警中，若机房告警为设备脱网告警，则将机房告警存放在活动设备脱网告警列表中，然后根据滑动时间窗算法中的滑动窗口触发周期、窗口大小和当前滑动时间窗中的活动机房群障列表，并使用预设模型中的机房决策模型进行分析处理，从而确定该组告警数据。
示例性的，预设模型中的机房决策模型的描述如下：
输入：
活动动环告警：N
活动设备脱网告警列表：L
滑动窗口触发周期：P
窗口大小：S
机房内设备离线数量门限：T1
活动机房群障列表：M
输出：
需产生机房群障的机房编码清单
决策模型：
a1、如果输入的是N，则判断此告警中的机房编码是否在M中出现，如果已出现，则结束决策判断；如果未出现，则产生机房群障，并确定为一组故障数据。
b1、如果输入的是L，则每P分钟，取L中告警创建时间距当前时间在S内设备告警列表L1，需注意的是P需远小于S。
b2、判断设备告警列表L1中的机房设备是否出现在M中，如果已出现，则结束决策判断。
b3、根据L1中告警的机房设备所在机房，并进行分组，得到每个机房中告警数据的数量。
b4、返回告警数据的数量大于门限T1的机房编码，以及机房包括的机房设备的告警数据，从而确定为一组故障数据。
示例性的，将告警类型为分光器告警的目标告警数据，存放在活动ONU离线告警清单中，然后根据滑动时间窗算法中的活动分光器群障列表，并使用预设模型中的分光器决策模型进行分析处理，从而确定该组告警数据。
示例性的，预设模型中的分光器决策模型的描述如下：
输入：
活动ONU离线告警清单：L
活动分光器群障列表：M
分光器下挂异常门限比例：R
分光器下挂ONU总数阈值：T
输出：
需产生分光器群障的分光器名称
决策模型：
1、首先判断ONU离线告警是否出现在M中出现，如果已出现，则结束决策判断。
2、根据获取的每个ONU上联的一级分光器信息和二级分光器信息，确定每级分光器下挂的ONU的异常数量。
3、如果分光器下挂的ONU的异常数量小于T，则该分光器不构成群障，则结束决策判断。
4、计算每个分光器下挂的异常比例，异常比例为分光器下挂的ONU的异常数量与分光器下挂的ONU总数的比值。如果异常比例大于R，则认为此分光器构成群障，并将ONU离线告警数据确定为一组故障数据。
需要说明的是，由ONU离线告警确定的ONU异常数量为离线的ONU数量，并且已排除因ONU设备断电原因造成的ONU设备离线。因为，在通常意义上，用户侧终端的掉电不认为是网络原因导致的故障，因此不用进行群障判断，并生成故障数据。
本申请实施例中，通过路径公共点分析等方法，实现对无源设备的故障进行监测，并且将机房、分光器等作为管理对象，确定是否产生群障，并确定多组故障数据，用于构建目标知识图谱，从而确定根本故障原因。
在一种设计中，如图6所示，本申请实施例提供的一种故障原因确定方法中，上述方法具体还可以包括步骤S501：
S501、基于多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级。
其中，一组故障数据的优先级与包括的目标告警数据的数量成正比。
可以理解，通过确定多组故障数据中的每组故障数据的优先级，可以得知每个故障数据的重要性，从而，由相关运维人员根据优先级的高低顺序进行维修，保证对业务影响较大的优先级较高的故障优先处理，提高用户的使用体验，并且可以对已经安排维修的故障的申告进行抑制，减少重复工单，避免资源浪费。
示例性的，根据多组故障数据中的每组故障数据包括的目标告警数据，可以确定与目标告警数据相关联的影响网络业务的数量，再根据故障处置优先级决策模型进行分析处理，确定每组故障数据的优先级。
可以理解，一组故障数据包括的目标告警数据的数量越多，则目标告警数据相关联的影响网络业务的数量就越大，因此优先级越高。
示例性的，可以使用故障处置优先级决策模型进行优先级的确定：
输入：
受影响的专线业务数量：cn，受影响的家庭宽带业务数量：in
输出：
故障级别：L
决策模型：
初始化故障级别为L＝C2。
如果cn在预设Lc与Uc的范围内，则将L更新为C1。
如果cn大于Uc，则将L更新为C1Plus。
如果in在预设Li与Ui的范围内，则将L更新为C1。
如果in大于Ui，则将L更新为C1Plus。
返回L。
可以理解，每组故障数据的优先级顺序为C1Plus大于C1，且C1大于C2。
本申请实施例中，通过确定每组故障数据的优先级，可以有效帮助运营商确定故障处理顺序，从而对目标网络进行故障的维修，并且对重复工单进行抑制，减少资源浪费。
在一种设计中，如图7所示，本申请实施例提供的一种故障原因确定方法中，上述步骤S203中的方法，具体可以包括步骤S601-S603：
S601、确定多个目标工单数据中的每个目标工单数据所属的目标区域范围。
其中，目标区域范围为多个预设区域范围中的区域范围。
可以理解，由于目标网络中多个目标工单数据是来自用户申告，而用户申诉时所属行政区、小区、业务类型等存在不同，因此，需要首先确定多个目标工单数据中的每个目标工单数据所属的目标区域范围，进而根据目标区域范围，并判断预设区域范围是否构成群障，从而保证在预设区域范围中未进行申告的用户的网络质量，进一步可以构建多组申告数据，对影响用户感知的事件进行识别并管理。
可选的，预设区域范围可以包括小区、地级行政区、省份等区域范围。
可选的，可以通过系统包括的工单事件采集模块获取的各种业务类型的多个工单数据，并根据工单中的业务编码，通过系统包括的业务影响分析模块获取其路由信息，并确定该路由信息中的落地端所在的预设区域范围中的目标区域范围，并获取该目标区域范围所属的地级行政区、维护部门等信息。
可选的，对于使用互联网专线的用户，该用户对应的目标工单数据包括的路由信息说明了所属的目标区域范围为用户所在小区；对于使用传输点对点专线的用户，该用户对应的目标工单数据包括的路由信息说明了所属的目标区域范围为专线传输的两端地级行政区；对于使用家庭宽带业务的用户，该用户对应的目标工单数据包括的路由信息说明了所属的目标区域范围为家庭所在小区；对于使用跨省专线的用户，该用户对应的目标工单数据包括的路由信息说明了所属的目标区域范围为使用跨省专线的对端省份。
示例性的，对于使用跨省专线的申告数据，应将跨省的对端省份作为目标区域范围。例如存在一条a省和b省的国内专线电路(Domestic Private Leased Circuit，DPLC)，而该电路在a省存在一条申告，则本端指a省，而b省作为跨省专线的对端省份，该目标工单数据所属的目标区域范围则是作为跨省专线的对端省份的b省。
可选的，在对多个目标工单数据中的每个目标工单数据所属的目标区域范围进行描述时，可以按目标区域范围进行分类描述，从而得到触发对象字段，用于后续每个预设区域范围内包含的目标工单数据的数量的统计。
示例性的，对于小区申告数据的触发对象字段可以取“小区标识”拼接“-”，再拼接“业务类型”，例如“a小区-家庭宽带业务”；对于行政区申告数据的触发对象字段可以取“行政区”拼接“-”，再拼接“业务类型”，例如“b市-互联网专线”；对于跨域专线申告数据的触发对象字段可以取“对端省份”拼接“-”，再拼接“跨域专线”，例如“c省-跨域专线”。
S602、基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量。
具体的，可以根据对多个目标工单数据中的每个目标工单数据所属的目标区域范围的触发对象字段进行分类统计，从而获取触发对象字段相同，工单编号不同的工单数量，计为每个预设区域范围内包含的目标工单数据的数量。
S603、在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将任一预设区域范围内包含的目标工单数据确定为一组申告数据。
可选的，任一组申告数据中包括以下至少一项：群障主题、群障区域、群障级别、群障处置部门、群障业务影响清单。
可选的，可以采用滑动时间窗算法，对申告时间在窗口内的申告工单，先进行查询，若该工单编号已出现在其他活动的申告数据中，则将其排除。
需要说明的是，本申请采用规则引擎来实现的目标工单数据对应的决策模型，具体的决策模型采用领域特定语言(domain-specific language，DSL)进行定义。为方便相关领域的技术人员理解，本申请的决策模型采用文字和公式进行描述。
示例性的，根据每个目标工单数据所属的目标区域范围，可以确定任一预设区域范围内包含的目标工单数据，并根据滑动时间窗算法中当前活动申告群障列表，再通过任一组申告数据的决策模型进行分析处理，确定任一预设区域范围内包含的一组申告数据。
示例性的，确定任一组申告数据的决策模型的描述如下：
输入：
区域范围与此区域范围关联申告工单：M
当前活动申告群障列表：L
该类型申告群障的申告门限：T
输出：
需产生申告群障的区域
决策模型：
1、判断M中的区域触发对象是否在L中，如果已出现，则结束决策判断，并从M中剔除。
2、对于M中的各个目标区域范围，如果每个目标区域范围关联的目标工单数据的数量(申告单数量)大于T，则认为触发该目标区域范围的该类型申告群障，并确定为一组申告数据。
需要说明的是，不同一组申告数据对应的预设阈值为不同的。
本申请实施例中，通过对用户申告进行统计，并确定目标区域范围，从而确定小区、地级行政区、跨域专线省份等维度是否构成申告群障，进一步可以得知特定区域的用户业务投诉与运行情况，并对出现的网络故障进行分析处理。
在一种设计中，如图8所示，本申请实施例提供的一种故障原因确定方法中，上述步骤S205中的方法，具体可以包括步骤S701-S705：
S701、基于多个对象中的任意两个对象之间的因果关系，构建目标知识图谱。
可以理解，知识图谱是一种以图形结构存储和表示知识的技术。知识图谱中的节点表示对象，边表示对象之间的关系。知识图谱可以用来存储各种各样的知识，包括人物、地点、事件、概念、术语等。知识图谱的目的是帮助机器理解人类的语言和思维方式，从而更好地处理自然语言处理、语义搜索、问答系统、智能对话等任务。
具体的，根据多个对象和多个对象中的任意两个对象之间的因果关系，可以将多个对象中的每个对象作为目标知识图谱中的节点，而多个对象中的任意两个对象之间的因果关系作为目标知识图谱中节点之间的边。
S702、针对任一告警数据或任一工单数据，确定目标知识图谱中任一告警数据或任一工单数据对应的目标节点。
可选的，目标节点一般是作为群障的某组故障数据或某组申告数据。因为作为群障的某组故障数据或某组申告数据对应在目标网络中的影响范围较大，受影响的用户数量较多，因此需要对造成该群障的原因进行分析，从而进行处理，保障目标网络的正常使用。
具体的，由于确定的目标知识图谱中运营事件、用户数量较多，并且在大量的关联事件中进行查询的效率较低，目标知识图谱的关系维护成本较高，关系探索不直观等问题，同时运营事件由于其具有时效性的特征，本申请从目标节点出发，将整体目标知识图谱进行逻辑拆分，在整体目标知识图谱中确定拆分出与目标节点相关的邻节点构成的子图谱，从而在子图谱中确定根本故障原因。
S703、确定目标知识图谱中，与目标节点具有因果关系的至少一个第一邻节点。
其中，至少一个第一邻节点为与目标节点直接相邻或间接相邻的节点，至少一个第一邻节点为事件对象的节点。
具体的，可以将确定的目标节点作为种子节点，在目标知识图谱中，从种子节点出发，逐跳回溯每个节点的因果关系，将因果关系为导致本节点的其他节点添加至第一邻节点，直到无法回溯，并暂时确定此节点为根节点。再从根节点出发，逐跳获取与本节点的因果关系为导致的节点，并添加至第一邻节点中，直到无下一跳，再确定与第一邻节点中的告警数据所指示的节点存在导致关系的节点添加至第一邻节点中。因此，可以从作为种子节点的目标节点出发，找到所有可能存在因果关系为“导致”的第一邻节点以及因果链路。
S704、从至少一个第一邻节点中确定出第二邻节点。
其中，第二邻节点为至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点。
具体的，从至少一个第一邻节点中确定告警数据所指示的节点，并确定与告警数据所指示的节点之间的因果关系为导致的至少一个公共节点，再计算每个公共节点关联的告警数据所指示的节点的数量，选取数量最大的公共节点作为第二邻节点，也是根因节点。如果数量相同，则选取非群障节点。
可选的，除了可以使用相邻数量最多的节点确定第二邻节点，还可以采用聚类等人工智能(Artificial Intelligence，AI)算法来确定。
示例性的，如图9所示，目标节点对应的知识图谱结构示意图。若目标节点为“故障群障-A-PON口中断-影响30个家庭宽带”，则从目标节点出发，向上可以确定根节点“故障群障-A-OLT-ABCD-多端口中断-影响121个家庭宽带”，再从根节点出发向下确定导致的各节点“申告群障-a小区-A公寓-12个家庭宽带用户申告”、“故障群障-A-PON口中断-影响30个家庭宽带”、“故障群障-B-PON口中断-影响23个家庭宽带”、“故障群障-C-PON口中断-影响14个家庭宽带”和“故障群障-D-PON口中断-影响54个家庭宽带”，再向下可以确定“申告群障-a小区-A公寓-12个家庭宽带用户申告”导致的“申告单-021A-家庭宽带用户”、“申告单-021B-家庭宽带用户”和“申告单-021C-家庭宽带用户”；“故障群障-A-PON口中断-影响30个家庭宽带”导致的“网络告警-A-PON口中断”；“故障群障-B-PON口中断-影响23个家庭宽带”导致的“网络告警-B-PON口中断”；“故障群障-C-PON口中断-影响14个家庭宽带”导致的“网络告警-C-PON口中断”；“故障群障-D-PON口中断-影响54个家庭宽带”导致的“网络告警-D-PON口中断”。再确定导致告警数据所指示节点的节点，即从“网络告警-A-PON口中断”、“网络告警-B-PON口中断”、“网络告警-C-PON口中断”和“网络告警-D-PON口中断”可以确定导致节点“割接单-A-OLT-ABCD-PON口”和“割接单-B-OLT-CD-PON口”。然后再将与所有节点存在因果关系为“衍生”关系的节点添加至第一节点中，即将“业务-家庭宽带-021C”也添加至第一节点中，用于后续确定根本故障原因所关联的业务，便于对业务进行查询等功能。进一步可以根据“割接单-A-OLT-ABCD-PON口”和“割接单-B-OLT-CD-PON口”所关联告警数据所指示节点的数量，得到“割接单-A-OLT-ABCD-PON口”对应4个告警数据所指示节点，而“割接单-B-OLT-CD-PON口”对应2个告警数据所指示节点，因此第二邻节点为“割接单-A-OLT-ABCD-PON口”。
S705、基于第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
具体的，根据第二邻节点，可以确定第二邻节点所指示的事件对象，进而确定目标节点的根本故障原因。
可选的，除了可以确定任一告警数据或任一工单数据的根本故障原因，还可以根据目标知识图谱，将后续获取到的申告数据等，添加至目标知识图谱中，并将关联的衍生事件合并，从而减少网络运营的人工投入，缩短网络故障分析与修复的时间、提高网络的运营效率。
可选的，对导致任一告警数据或任一工单数据的根本故障原因的确定，可以直接对保存在数据库的目标知识图谱进行查询，也可以采用主动消息流推送的方式，向运营商提供群障或运营事件的根本原因分析、用户业务状态查询等功能。
示例性的，结合图9所示，可以得知影响“故障群障-A-PON口中断-影响30个家庭宽带”的根本故障原因为“割接单-A-OLT-ABCD-PON口”，因此，运营商可以针对性的将割接单对应工程加快操作，或暂时使用替代接口保证用户可以正常使用，要确保网络性能提升的同时，保证用户体验。
本申请实施例中，通过构建目标知识图谱，从任一告警数据或任一工单数据出发，确定导致该告警数据或工单数据的根本故障原因，从而使运维人员直观的判断当前运营事件的原因、处置情况、业务影响等信息，并对目标网络进行操作，保证用户使用体验。
本申请提供了一种故障原因确定方法，首先获取构成目标网络的多个网络设备发出的多个目标告警数据，并获取用户通过终端设备发出的网络异常申告的多个目标工单数据，并且多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度。然后从多个目标告警数据中确定出多组故障数据，其中每组故障数据中的目标告警数据的告警类型相同；并从多个目标工单数据中确定出多组申告数据，其中每组申告数据中的目标工单数据所属的地理区域范围相同。进一步，基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，进而基于多个对象中的任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。通过上述方法，可以根据网络的多个目标告警数据和多个目标工单数据，确定多组故障数据和多组申告数据，进而确定任意两个对象之间的因果关系，从而确定任一告警数据或任一工单数据的根本故障原因。因此，有效提高了网络中不同类型的设备的群体性故障的检测效率，并且提高了确定故障的根本原因的准确度。
上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对一种故障原因确定装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。可选的，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
图10为本申请实施例提供的一种故障原因确定装置的结构示意图。如图10所示，一种故障原因确定装置100用于提高不同类型的设备的群体性故障的检测效率，以及提高确定造成群体性故障的原因的准确度，例如用于执行图3所示的一种故障原因确定方法。该故障原因确定装置100包括：获取单元1001和处理单元1002；
获取单元1001，用于获取目标网络的多个目标告警数据和多个目标工单数据，多个目标告警数据为构成目标网络的多个网络设备发出的告警信息，多个目标工单数据为用户通过终端设备发出的网络异常申告，多个目标告警数据和多个目标工单数据对网络业务的影响度大于预设影响度；
处理单元1002，用于从多个目标告警数据中确定出多组故障数据，并从多个目标工单数据中确定出多组申告数据，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同；
处理单元1002，还用于基于多组故障数据和多组申告数据，确定多个对象中的任意两个对象之间的因果关系，多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；
处理单元1002，还用于基于任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
在一种可能的实现方式中，在本申请实施例提供的一种故障原因确定装置100中，获取单元1001，具体用于获取目标网络的多个告警数据和多个工单数据；
处理单元1002，具体用于确定多个告警数据中的每个告警数据所指示的异常设备，和多个工单数据中的每个工单数据所指示的异常设备；
处理单元1002，具体用于基于每个异常设备所执行的网络业务，从多个告警数据中筛选出多个目标告警数据，并从多个工单数据中筛选出多个目标工单数据。
在一种可能的实现方式中，在本申请实施例提供的一种故障原因确定装置100中，处理单元1002，具体用于确定多个目标告警数据中的每个目标告警数据的告警类型；
处理单元1002，具体用于基于每个目标告警数据的告警类型，将多个目标告警数据划分为多组告警数据，多组告警数据中的每组告警数据包括同一告警类型的目标告警数据；
处理单元1002，具体用于针对多组告警数据中的任一组告警数据，基于任一组告警数据对应的预设模型，从任一组告警数据中的目标告警数据中确定出多组故障数据，每组告警数据对应不同的预设模型。
在一种可能的实现方式中，在本申请实施例提供的一种故障原因确定装置100中，处理单元1002，还用于基于多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级，一组故障数据的优先级与包括的目标告警数据的数量成正比。
在一种可能的实现方式中，在本申请实施例提供的一种故障原因确定装置100中，处理单元1002，具体用于确定多个目标工单数据中的每个目标工单数据所属的目标区域范围，目标区域范围为多个预设区域范围中的区域范围；
处理单元1002，具体用于基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量；
处理单元1002，具体用于在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将任一预设区域范围内包含的目标工单数据确定为一组申告数据。
在一种可能的实现方式中，在本申请实施例提供的一种故障原因确定装置100中，处理单元1002，具体用于基于多个对象中的任意两个对象之间的因果关系，构建目标知识图谱；
处理单元1002，具体用于针对任一告警数据或任一工单数据，确定目标知识图谱中任一告警数据或任一工单数据对应的目标节点；
处理单元1002，具体用于确定目标知识图谱中，与目标节点具有因果关系的至少一个第一邻节点，至少一个第一邻节点为与目标节点直接相邻或间接相邻的节点，至少一个第一邻节点为事件对象的节点；
处理单元1002，具体用于从至少一个第一邻节点中确定出第二邻节点，第二邻节点为至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点；
处理单元1002，具体用于基于第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
在采用硬件的形式实现上述集成的模块的功能的情况下，本申请实施例提供了上述实施例中所涉及的电子设备的另外一种可能的结构示意图。如图11所示，一种电子设备110，用于提高不同类型的设备的群体性故障的检测效率，以及提高确定造成群体性故障的原因的准确度，例如用于执行图3所示的一种故障原因确定方法。该电子设备110包括处理器1101，存储器1102以及总线1103。处理器1101与存储器1102之间可以通过总线1103连接。
处理器1101是通信装置的控制中心，可以是一个处理器，也可以是多个处理元件的统称。例如，处理器1101可以是一个通用中央处理单元(central processing unit，CPU)，也可以是其他通用处理器等。其中，通用处理器可以是微处理器或者是任何常规的处理器等。
作为一种实施例，处理器1101可以包括一个或多个CPU，例如图11中所示的CPU 0和CPU 1。
存储器1102可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
作为一种可能的实现方式，存储器1102可以独立于处理器1101存在，存储器1102可以通过总线1103与处理器1101相连接，用于存储指令或者程序代码。处理器1101调用并执行存储器1102中存储的指令或程序代码时，能够实现本申请实施例提供的一种故障原因确定方法。
另一种可能的实现方式中，存储器1102也可以和处理器1101集成在一起。
总线1103，可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外围设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
需要指出的是，图11示出的结构并不构成对该电子设备110的限定。除图11所示部件之外，该电子设备110可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
作为一个示例，结合图10，电子设备中的获取单元1001和处理单元1002实现的功能与图11中的处理器1101的功能相同。
可选的，如图11所示，本申请实施例提供的电子设备110还可以包括通信接口1104。
通信接口1104，用于与其他设备通过通信网络连接。该通信网络可以是以太网，无线接入网，无线局域网(wireless local area networks，WLAN)等。通信接口1104可以包括用于接收数据的接收单元，以及用于发送数据的发送单元。
在一种设计中，本申请实施例提供的电子设备中，通信接口还可以集成在处理器中。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能单元的划分进行举例说明。在实际应用中，可以根据需要而将上述功能分配由不同的功能单元完成，即将装置的内部结构划分成不同的功能单元，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机执行该指令时，该计算机执行上述方法实施例所示的方法流程中的各个步骤。
本申请的实施例提供一种包含指令的计算机程序产品，当指令在计算机上运行时，使得计算机执行上述方法实施例中的一种故障原因确定方法。
其中，计算机可读存储介质，例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘。随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、寄存器、硬盘、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的人以合适的组合、或者本领域数值的任何其他形式的计算机可读存储介质。
一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于特定用途集成电路(Application Specific Integrated Circuit，ASIC)中。
在本申请实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
由于本申请的实施例中的电子设备、计算机可读存储介质、计算机程序产品可以应用于上述方法，因此，其所能获得的技术效果也可参考上述方法实施例，本申请实施例在此不再赘述。
以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。
Claims (14)
1.一种故障原因确定方法，其特征在于，所述方法包括：
获取目标网络的多个目标告警数据和多个目标工单数据，所述多个目标告警数据为构成所述目标网络的多个网络设备发出的告警信息，所述多个目标工单数据为用户通过终端设备发出的网络异常申告，所述多个目标告警数据和所述多个目标工单数据对网络业务的影响度大于预设影响度；
从所述多个目标告警数据中确定出多组故障数据，并从所述多个目标工单数据中确定出多组申告数据，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同；
基于所述多组故障数据和所述多组申告数据，确定多个对象中的任意两个对象之间的因果关系，所述多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；
基于所述任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
2.根据权利要求1所述的方法，其特征在于，所述获取目标网络的多个目标告警数据和多个目标工单数据，包括：
获取所述目标网络的多个告警数据和多个工单数据；
确定所述多个告警数据中的每个告警数据所指示的异常设备，和所述多个工单数据中的每个工单数据所指示的异常设备；
基于每个异常设备所执行的网络业务，从所述多个告警数据中筛选出所述多个目标告警数据，并从所述多个工单数据中筛选出所述多个目标工单数据。
3.根据权利要求1或2所述的方法，其特征在于，所述从所述多个目标告警数据中确定出多组故障数据，包括：
确定所述多个目标告警数据中的每个目标告警数据的告警类型；
基于每个目标告警数据的告警类型，将所述多个目标告警数据划分为多组告警数据，所述多组告警数据中的每组告警数据包括同一告警类型的目标告警数据；
针对所述多组告警数据中的任一组告警数据，基于所述任一组告警数据对应的预设模型，从所述任一组告警数据中的目标告警数据中确定出多组故障数据，每组告警数据对应不同的预设模型。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
基于所述多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级，一组故障数据的优先级与包括的目标告警数据的数量成正比。
5.根据权利要求1或2所述的方法，其特征在于，所述从所述多个目标工单数据中确定出多组申告数据，包括：
确定所述多个目标工单数据中的每个目标工单数据所属的目标区域范围，所述目标区域范围为多个预设区域范围中的区域范围；
基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量；
在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将所述任一预设区域范围内包含的目标工单数据确定为一组申告数据。
6.根据权利要求1或2所述的方法，其特征在于，所述基于所述任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因，包括：
基于所述多个对象中的任意两个对象之间的因果关系，构建目标知识图谱；
针对任一告警数据或任一工单数据，确定所述目标知识图谱中所述任一告警数据或所述任一工单数据对应的目标节点；
确定所述目标知识图谱中，与所述目标节点具有因果关系的至少一个第一邻节点，所述至少一个第一邻节点为与所述目标节点直接相邻或间接相邻的节点，所述至少一个第一邻节点为事件对象的节点；
从所述至少一个第一邻节点中确定出第二邻节点，所述第二邻节点为所述至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点；
基于所述第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
7.一种故障原因确定装置，其特征在于，所述故障原因确定装置包括：获取单元和处理单元；
所述获取单元，用于获取目标网络的多个目标告警数据和多个目标工单数据，所述多个目标告警数据为构成所述目标网络的多个网络设备发出的告警信息，所述多个目标工单数据为用户通过终端设备发出的网络异常申告，所述多个目标告警数据和所述多个目标工单数据对网络业务的影响度大于预设影响度；
所述处理单元，用于从所述多个目标告警数据中确定出多组故障数据，并从所述多个目标工单数据中确定出多组申告数据，每组故障数据包括至少一个目标告警数据，每组故障数据中的目标告警数据的告警类型相同，每组申告数据包括至少一个目标工单数据，每组申告数据中的目标工单数据所属的地理区域范围相同；
所述处理单元，还用于基于所述多组故障数据和所述多组申告数据，确定多个对象中的任意两个对象之间的因果关系，所述多个对象包括：多个事件对象和多个业务对象，一个事件对象用于指示一组故障数据或一组申告数据，一个业务对象用于指示一个网络设备；
所述处理单元，还用于基于所述任意两个对象之间的因果关系，确定导致任一告警数据或任一工单数据的根本故障原因。
8.根据权利要求7所述的故障原因确定装置，其特征在于，所述获取单元，具体用于获取所述目标网络的多个告警数据和多个工单数据；
所述处理单元，具体用于确定所述多个告警数据中的每个告警数据所指示的异常设备，和所述多个工单数据中的每个工单数据所指示的异常设备；
所述处理单元，具体用于基于每个异常设备所执行的网络业务，从所述多个告警数据中筛选出所述多个目标告警数据，并从所述多个工单数据中筛选出所述多个目标工单数据。
9.根据权利要求7或8所述的故障原因确定装置，其特征在于，所述处理单元，具体用于确定所述多个目标告警数据中的每个目标告警数据的告警类型；
所述处理单元，具体用于基于每个目标告警数据的告警类型，将所述多个目标告警数据划分为多组告警数据，所述多组告警数据中的每组告警数据包括同一告警类型的目标告警数据；
所述处理单元，具体用于针对所述多组告警数据中的任一组告警数据，基于所述任一组告警数据对应的预设模型，从所述任一组告警数据中的目标告警数据中确定出多组故障数据，每组告警数据对应不同的预设模型。
10.根据权利要求7所述的故障原因确定装置，其特征在于，所述处理单元，还用于基于所述多组故障数据中的每组故障数据包括的目标告警数据的数量，确定每组故障数据的优先级，一组故障数据的优先级与包括的目标告警数据的数量成正比。
11.根据权利要求7或8所述的故障原因确定装置，其特征在于，所述处理单元，具体用于确定所述多个目标工单数据中的每个目标工单数据所属的目标区域范围，所述目标区域范围为多个预设区域范围中的区域范围；
所述处理单元，具体用于基于每个目标工单数据所属的目标区域范围，确定每个预设区域范围内包含的目标工单数据的数量；
所述处理单元，具体用于在任一预设区域范围内包含的目标工单数据的数量大于预设阈值的情况下，将所述任一预设区域范围内包含的目标工单数据确定为一组申告数据。
12.根据权利要求7或8所述的故障原因确定装置，其特征在于，所述处理单元，具体用于基于所述多个对象中的任意两个对象之间的因果关系，构建目标知识图谱；
所述处理单元，具体用于针对任一告警数据或任一工单数据，确定所述目标知识图谱中所述任一告警数据或所述任一工单数据对应的目标节点；
所述处理单元，具体用于确定所述目标知识图谱中，与所述目标节点具有因果关系的至少一个第一邻节点，所述至少一个第一邻节点为与所述目标节点直接相邻或间接相邻的节点，所述至少一个第一邻节点为事件对象的节点；
所述处理单元，具体用于从所述至少一个第一邻节点中确定出第二邻节点，所述第二邻节点为所述至少一个第一邻节点中具有的邻节点为第一邻节点的数量最多的第一邻节点；
所述处理单元，具体用于基于所述第二邻节点所指示的事件对象，确定导致任一告警数据或任一工单数据的根本故障原因。
13.一种电子设备，其特征在于，包括：处理器以及存储器；其中，所述存储器用于存储一个或多个程序，所述一个或多个程序包括计算机执行指令，当所述电子设备运行时，处理器执行所述存储器存储的所述计算机执行指令，以使所述电子设备执行权利要求1-6中任一项所述的一种故障原因确定方法。
14.一种存储一个或多个程序的计算机可读存储介质，其特征在于，所述一个或多个程序包括指令，所述指令当被计算机执行时使所述计算机执行如权利要求1-6中任一项所述的一种故障原因确定方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311576309.0A CN117459365A (zh) | 2023-11-23 | 2023-11-23 | 故障原因确定方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311576309.0A CN117459365A (zh) | 2023-11-23 | 2023-11-23 | 故障原因确定方法、装置、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117459365A true CN117459365A (zh) | 2024-01-26 |
Family
ID=89583642
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311576309.0A Pending CN117459365A (zh) | 2023-11-23 | 2023-11-23 | 故障原因确定方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117459365A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117715040A (zh) * | 2024-02-06 | 2024-03-15 | 国网四川省电力公司信息通信公司 | Dplc模组的配网通信方法及装置 |
| CN118354345A (zh) * | 2024-03-27 | 2024-07-16 | 北京唯得科技有限公司 | 5g mimo移频双路系统的告警管理方法和系统 |
-
2023
- 2023-11-23 CN CN202311576309.0A patent/CN117459365A/zh active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117715040A (zh) * | 2024-02-06 | 2024-03-15 | 国网四川省电力公司信息通信公司 | Dplc模组的配网通信方法及装置 |
| CN117715040B (zh) * | 2024-02-06 | 2024-04-30 | 国网四川省电力公司信息通信公司 | Dplc模组的配网通信方法及装置 |
| CN118354345A (zh) * | 2024-03-27 | 2024-07-16 | 北京唯得科技有限公司 | 5g mimo移频双路系统的告警管理方法和系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108900541B (zh) | 一种针对云数据中心sdn安全态势感知系统及方法 | |
| CN117459365A (zh) | 故障原因确定方法、装置、设备及存储介质 | |
| CN103001811B (zh) | 故障定位方法和装置 | |
| CN102158360B (zh) | 一种基于时间因子因果关系定位的网络故障自诊断方法 | |
| CN101582807B (zh) | 一种基于北向接口实现网络管理的方法及系统 | |
| CN102447570B (zh) | 一种基于健康度分析的监控装置及方法 | |
| CN104852927A (zh) | 基于多源异构的信息安全综合管理系统 | |
| CN103166794A (zh) | 一种具有一体化安全管控功能的信息安全管理方法 | |
| CN103338128A (zh) | 一种具有一体化安全管控功能的信息安全管理系统 | |
| CN111355655B (zh) | 一种量子密码网络量子路由检测方法和服务器 | |
| CN102611713A (zh) | 基于熵运算的网络入侵检测方法和装置 | |
| CN118509336B (zh) | 一种考虑电力消耗的通信网络优化方法、装置及设备 | |
| CN115297007A (zh) | 针对合作网络的网络空间资产信息地图的构建方法及系统 | |
| CN110752959A (zh) | 一种智能变电站过程层物理链路故障定位系统 | |
| CN112333020A (zh) | 一种基于五元组的网络安全监测及数据报文解析系统 | |
| Calyam et al. | Topology-aware correlated network anomaly event detection and diagnosis | |
| CN118487990A (zh) | 服务器集群流量控制方法、装置和服务器集群 | |
| US20040158780A1 (en) | Method and system for presenting neighbors of a device in a network via a graphical user interface | |
| Jukić et al. | Service monitoring and alarm correlations | |
| CN114257414A (zh) | 一种网络安全智能值班方法及系统 | |
| Lad et al. | Inferring the origin of routing changes using link weights | |
| CN114500230B (zh) | 一种基于时间轴的光传输故障录播方法及系统 | |
| CN111917609B (zh) | 网络设备连通性监控方法及系统 | |
| CN118764323B (zh) | 一种基于流量监测的网络安全态势感知平台 | |
| Shidanjie et al. | Research on fault early warning technology of key operation nodes in power communication network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |