CN114285730A - 确定故障根因的方法，装置以及相关设备 - Google Patents

确定故障根因的方法，装置以及相关设备 Download PDF

Info

Publication number
CN114285730A
CN114285730A CN202010986439.1A CN202010986439A CN114285730A CN 114285730 A CN114285730 A CN 114285730A CN 202010986439 A CN202010986439 A CN 202010986439A CN 114285730 A CN114285730 A CN 114285730A
Authority
CN
China
Prior art keywords
fault information
information
root cause
alarms
fault
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
Application number
CN202010986439.1A
Other languages
English (en)
Inventor
田智勇
谢青
王继禹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010986439.1A priority Critical patent/CN114285730A/zh
Priority to PCT/CN2021/107015 priority patent/WO2022057428A1/zh
Priority to EP21868257.3A priority patent/EP4206927A4/en
Publication of CN114285730A publication Critical patent/CN114285730A/zh
Priority to US18/185,910 priority patent/US20230231760A1/en
Pending legal-status Critical Current

Links

Images

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/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0627—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time by acting on the notification or alarm source
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • 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/12—Discovery or management of network topologies
    • 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/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • 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/0677—Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例公开了一种确定故障根因的方法，可以应用于信息技术领域。该方法包括：获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数；基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警；基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。其中，利用和第一故障信息匹配的已知故障信息确定第一故障信息的根因，可以降低运维人员的工作难度，提升排障效率。

Description

确定故障根因的方法，装置以及相关设备
技术领域
本申请涉及信息技术领域，尤其涉及确定故障根因的方法，装置以及相关设备。
背景技术
随着网络规模的扩大，各类网络设备的增多，这些网络设备会产生海量的各类型的告警，给运营支撑***(operations,support,system,OSS)带来了很大的压力。
除了上述原因，在这些海量告警中，还存在大量的无效告警，重复告警等不需要关注的告警，而运维人员无法从海量的告警中准确识别出故障根因，导致排障效率低，产生大量的无效派单，浪费人力，运维成本高。为了提高排障效率，***根据时间关联度，拓扑关联度等划分事件，得到一个个较小的告警事件集合，也可以称为situation。并且通过展示告警事件集合的拓扑图，提升告警事件集合的直观程度，帮助运维人员对根因进行分析。在运维人员确定根因后，可以在拓扑图中进行标注，根据该标注进行派单。
虽然通过在拓扑上标注根因提升了运维人员的排障效率，但是需要每个运维人员都有专业的技术知识，从而对进一步提升排障效率产生了限制。
发明内容
本申请提供了一种确定故障根因的方法，装置以及相关设备，可以提升排障效率。
本申请第一方面提供了一种确定故障根因的方法。
该方法包括：确定故障根因的设备获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数，为了描述简单，下面将确定故障根因的设备称为第一设备。在获取第一故障信息后，第一设备基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数。并且第一设备还基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
其中，利用和第一故障信息匹配的已知故障信息确定第一故障信息的根因，可以降低运维人员的工作难度，提升排障效率。
在第一方面的一种可选设计中，第一设备基于第一故障信息中的M条告警和第一已知故障信息中的P条告警确定第一故障信息与第一已知故障信息的第一相似度，其中第一已知故障信息包含于N份已知故障信息，P为大于等于1的整数。第一设备还基于确定第一相似度的方法，计算第一故障信息分别与N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度。基于获取的第一相似度和N-1个相似度，第一设备确定与第一故障信息匹配的至少一份已知故障信息。其中，通过N个相似度确定与第一故障信息匹配的故障信息，可以提升匹配的准确性，进而提升确定的与第一故障信息的根因相关的信息的准确性。
在第一方面的一种可选设计中，第一设备获取第一故障信息对应的第一向量集合，第一向量集合包括M个第一向量，M个第一向量与M条告警一一对应，M个第一向量中每个第一向量的部分或全部特征用于表征M条告警中的一条告警对网络的影响和/或产生一条告警的原因。第一设备获取第一向量集合和第二向量集合的第一相似度，第二向量集合包括P个第二向量，P个第二向量与P条告警一一对应。其中，当两个故障事件合集中的故障根因相同时，两个故障事件合集对网络的影响和/或产生该故障合集的原因应当是相似的。第一向量集合体现了第一故障信息对网络的影响和/或产生该故障信息的原因；第二向量合集体现了P条告警对应的故障信息对网络的影响和/或产生该故障信息的原因。因此，通过第一向量合集和第二向量集合计算第一相似度，可以提升确定的与第一故障信息的根因相关的信息的准确性。
在第一方面的一种可选设计中，与第一故障信息匹配的至少一份已知故障信息为N份已知故障信息中与第一故障信息的相似度最高的已知故障信息；或与第一故障信息匹配的至少一份已知故障信息为N份已知故障信息中与第一故障信息的相似度超过预定值的至少一份已知故障信息。其中，通过上述方法，可以避免运维人员每次都需要看N份已知故障信息，简化运维人员的操作，提升确定故障根因的效率。
在第一方面的一种可选设计中，第一设备基于至少一份已知故障信息的故障根因确定第一故障信息的根因；或者，第一设备基于至少一份已知故障信息的故障根因确定与第一故障信息中的一条告警相关的实体是否是第一故障信息的根因。
在第一方面的一种可选设计中，至少一份已知故障信息的故障根因对应的告警的类型与第一故障信息的根因对应的告警的类型相同。其中，当第一故障信息只包括一条告警与至少一份故障信息的故障根因对应的告警的类型相同时，则可以确定该告警对应的实体设备为第一故障信息的根因。因此，可以无需分析第一故障信息对应的拓扑图，简化获取根因的过程。
在第一方面的一种可选设计中，当与第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时，第一设备确定与多份已知故障信息分别对应的多份与第一故障信息的根因相关的候选信息，并通过展示界面展示多份的后选信息，接收根因选择信息，该根因选择信息表征选定了某份后选信息。第一设备基于根因选择信息，从多份候选信息中确定与第一故障信息的根因相关的信息。其中，通过推荐多份后选信息供运维人员选择，可以利用运维人员自身的技术知识，提升确定的与第一故障信息的根因相关的信息的准确性。
本申请第二方面提供了一种确定故障根因的装置。
该装置包括：获取模块，用于获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数；
第一确定模块，用于基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；
第二确定模块，用于基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
在第二方面的一种可选设计中，第一确定单元具体用于基于第一故障信息中的M条告警和第一已知故障信息中的P条告警确定第一故障信息与第一已知故障信息的第一相似度，其中第一已知故障信息包含于N份已知故障信息，其中P为大于等于1的整数；第一确定单元具体用于基于确定第一相似度的方法，计算第一故障信息分别与N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度；第一确定单元具体用于基于第一相似度和N-1个相似度，确定与第一故障信息匹配的至少一份已知故障信息。
在第二方面的一种可选设计中，第一确定单元具体用于获取第一故障信息对应的第一向量集合，第一向量集合包括M个第一向量，M个第一向量与M条告警一一对应，M个第一向量中每个第一向量的部分或全部特征用于表征M条告警中的一条告警对网络的影响和/或产生一条告警的原因；第一确定单元具体用于获取第一向量集合和第二向量集合的第一相似度，第二向量集合包括P个第一向量，P个第一向量与P条告警一一对应。
在第二方面的一种可选设计中，与第一故障信息匹配的至少一份已知故障信息包括：N份已知故障信息中与第一故障信息的相似度最高的已知故障信息；或N份已知故障信息中与第一故障信息的相似度超过预定值的至少一份已知故障信息。
在第二方面的一种可选设计中，第二确定单元具体用于基于至少一份已知故障信息的故障根因确定第一故障信息的根因；或者，第二确定单元具体用于基于至少一份已知故障信息的故障根因确定与第一故障信息中的一条告警相关的实体是否是第一故障信息的根因。
在第二方面的一种可选设计中，至少一份已知故障信息的故障根因对应的告警的类型与第一故障信息的根因对应的告警的类型相同。
在第二方面的一种可选设计中，当与第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时：第二确定单元具体用于确定与多份已知故障信息分别对应的多份与第一故障信息的根因相关的候选信息；第二确定单元具体用于接收根因选择信息；第二确定单元具体用于基于根因选择信息，从多份候选信息中确定与第一故障信息的根因相关的信息。
本申请第三方面提供了一种确定故障根因的设备。
该设备包括：处理器和存储器，存储器中存储有N份已知故障信息；处理器用于获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数；处理器还用于基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；处理器还用于基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
本申请第四方面提供了一种计算机存储介质，其特征在于，所述计算机存储介质中存储有指令，所述指令在计算机上执行时，使得所述计算机执行如第一方面或第一方面任意一种实施方式所述的方法。
本申请第五方面提供了一种计算机程序产品，其特征在于，所述计算机程序产品在计算机上执行时，使得所述计算机执行如第一方面或第一方面任意一种实施方式所述的方法。
附图说明
图1为本申请实施例中的框架示意图；
图2为本申请实施例中获取第二向量集合的流程示意图；
图3为本申请实施例中第二故障信息对应的拓扑图；
图4为本申请实施例中依据列表的一个结构示意图；
图5为本申请实施例中导致资源上报ETH_LOS的可能原因的流程示意图；
图6为本申请实施例中的一个拓扑图；
图7为本申请实施例中依据列表的另一个结构示意图；
图8为本申请实施例中确定故障根因的流程示意图；
图9为本申请实施例中确定故障根因的装置的结构示意图；
图10为本申请实施例中确定故障根因的设备的结构示意图。
具体实施方式
本申请实施例提供了一种确定故障根因的方法，装置以及相关设备，应用于信息技术领域，可以提升排障效率。需要理解的是，在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
首先，对本申请中的部分用语进行解释说明，以便使本领域技术人员理解。
1)告警事件集合，也可以称为situation,是根据时间关联度，拓扑关联度，文本相似度中的至少一个维度，对一个可能的故障对应的一系列告警事件进行聚合得到的，举例说明：假设原始告警事件的集合为A＝[a1，a2，…，ai]聚合后的所有situation记为S,S＝{S1[a1，…，ak]，S2[at,…，sy]，…Sr[am,…，ai}，其中r是situation的数量，l<＝k,t,y,m<i,即每一个situation都是一系列告警事件的集合，其中，所述告警事件集合可以是通过聚合的方式得到的，也可以是人工确定的。在本申请实施例中，第一故障信息是一个故障事件集合，已知的N份故障信息是N个故障事件集合，至少一份已知故障信息是至少一个故障事件集合。
2)告警名称与类型，用于表征告警事件的属性，可以表征具体的故障原因，可选地，告警名称还会对应一个恢复操作建议。其中，告警名称可以用离散的中文或者英文的字符串表示，例如，告警名称可以为ETH_LOS，MPLS_TUNNEL_LOCV，ETH_APS_LOST，TUNNEL_DOWN、整机用户数降到最小阈值等。一个告警名称一般对应于一种类型的告警，例如网元1和网元2都上报了ETH_LOS，则认为这两个ETH_LOS是一个类型的告警。
3)故障根因和根因，故障根因用于表征在一个situation中的根因告警事件，例如一个situation包括ETH_LOS，MPLS_TUNNEL_LOCV，ETH_APS_LOST三个告警。在这三个告警中，由ETH_LOS导致了MPLS_TUNNEL_LOCV和ETH_APS_LOST的产生。当解决ETH_LOS产生的原因后，MPLS_TUNNEL_LOCV和ETH_APS_LOST也相应被消除。在这情况下，则称ETH_LOS是该situation的故障根因。根因是与故障根因对应的实体设备产生的问题，例如与ETH_LOS对应的根因可能是光纤1断开，为了方便描述，有时也称ETH_LOS与光纤1对应。在实际应用中，有着存在根因，但是不存在故障根因的情况。例如某个网元虽然发生了故障，却没有正常上报告警。通过本申请实施例中确定故障根因的方法，可以在此情况下也能确定出根因。在后续的描述，将会对此详细阐述。
4)告警严重等级，用于表征告警的紧急程度，可以用中文或者英文的字符串表示，例如，用中文表示时可以为紧急、重要、次要、提醒、未知5个等级，在数据处理时，可以将中文字符串处理为对应的特征，由于告警严重等级间存在递进的关系，需要进行单独编码，因此紧急、重要、次要、提醒、未知可以分别处理成5,4,3,2,1等告警严重等级特征，告警事件在上报时携带告警严重等级，假设，一个situation中有4条告警事件，告警严重等级分别为紧急、重要、重要，重要，则该4条告警事件的告警严重等级特征分别为5,4,4,4编码也可以为其它形式，本申请对其不做限定。
随着网络规模的扩大，各类网络设备的增多，这些网络设备会产生海量的各类型的告警，给OSS带来了很大的压力。除了上述原因，在这些海量告警中，还存在大量的无效告警，重复告警等不需要关注的告警，而运维人员无法从海量的告警中准确识别出故障根因，导致排障效率低，产生大量的无效派单，浪费人力，运维成本高。为了提高排障效率，***根据时间关联度，拓扑关联度等划分事件，得到一个个较小的situation。并且通过展示告警事件集合的拓扑图，提升告警事件集合的直观程度，帮助运维人员对根因进行分析。在运维人员确定根因后，可以在拓扑图中进行标注，根据该标注进行派单。虽然通过拓扑图提升了运维人员的排障效率，但是需要每个运维人员都有专业的技术知识，从而对进一步提升排障效率产生了限制。为了进一步提升排障效率，本申请提供了一种确定故障根因的方法。在该方法中，将第一故障信息与已知的多份故障信息对比，在已知的N份故障信息中确定至少一份与第一故障信息匹配的已知故障信息，从而可以根据该已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
本申请实施例中的执行主体为确定故障根因的设备，称为第一设备。第一设备可以是一个单独的服务器，还可以是网管设备等具有处理能力的设备。请参阅图1，图1为本申请实施例中的框架示意图。图1包括网元101，第一设备102，0SS103。网元101可以是交换机，路由器，防火墙，负载均衡设备，接入网设备等。第一设备102接收各网元101发送的告警，对告警进行situation构建，将至少一个告警聚合为至少一个告警事件集合，得到第一故障信息。并且第一设备102对第一故障信息进行根因识别，确定第一故障信息中的故障根因，将故障根因对应的根因派单给OSS。应当确定的是，在本申请实施例中，situation构建和根因识别可以在一台设备中完成，也可以多台设备中完成。例如第二设备进行situation构建，将完成后的situation发送给第一设备102，由第一设备102完成根因识别的步骤。
由于第一设备102需要将第一故障信息与已知的N份已知故障信息匹配，因此在第一设备102做相关匹配前，第一设备102需要获取N份已知故障信息。其中，N份已知故障信息包括第二故障信息。在描述本申请实施例中对第一故障信息的处理前，下面先对获取第二故障信息对应的第二向量集合的内容进行相应描述。请参阅图2，图2为本申请实施例中获取第二向量集合的流程示意图。
在步骤201中，第一设备获取第二故障信息。
第二故障信息是一个situation，第一设备在获取网元发送的多个告警后，可以在多个告警中得到该situation。第二故障信息包括P条告警，P为大于等于1的整数。
在步骤202中，第一设备展示第二故障信息对应的拓扑图。
假设第二故障信息包括ETH_LOS，MPLS_TUNNEL_LOCV，NE_NOT_LOGIN三个告警。将三个告警的故障映射到局部拓扑图中，同时将这些告警关联的资源对象也在这个拓扑图上展示出来，这些资源对象就组成了可选的根因标注集合，包括网元、网元端口、光纤/光缆和tunnel等。第二故障信息对应的局部拓扑图如图3所示。图3为本申请实施例中第二故障信息对应的拓扑图。拓扑图中包括网元301，网元302，…，网元306。网元304上报了ETH_LOS，网元303上报了NE_NOT_LOGIN，网元306上报了MPLS_TUNNEL_LOCV。应当说明的是，物理层中的网元303和应用tunnel层的网元303是同一个设备，只是用于方便区分软件故障和硬件故障。该拓扑图只是一个示例，本申请实施例并不限定如何确定拓扑图以及展示拓扑图的方式。需要说明的是，与第二故障信息中的任意一个告警相关的网元，单板，光纤等，都应当认为是和第二故障信息相关的实体。例如，实体2发出告警1。其中，与告警1相关的实体1可以理解为实体1与实体2直接相连，或告警1产生的故障影响了实体1的正常网络通信。和第二故障信息相关的实体可以全部或部分的体现在展示的拓扑图中。例如在图3中，网元304并未展示单板。
在步骤203中，第一设备在拓扑图上接收选定故障根因的指令。
第二故障信息中NE_NOT_LOGIN与网元303对应。NE_NOT_LOGIN表征网元303未登陆。造成网元303未登陆的原因可能是用户未登陆网元303，或用户登陆失败，或通讯中断。假设运维人员在分析拓扑图后，认为网元303是第二故障信息的根因，则可以选定网元303作为第二故障信息的根因。
在步骤204中，第一设备根据指令展示依据列表，依据列表包括多个依据项目。
在步骤203中的描述了，假设该指令选定网元303作为第二故障信息的根因。在接收到该指令后，第一设备展示依据列表。依据列表包括多个依据项目，多个依据项目中的部分或全部特征用于描述NE_NOT_LOGIN对网络的影响和/或产生该NE_NOT_LOGIN是原因。为了方便说明，下面举例说明依据列表的具体内容，如图4所示。图4为本申请实施例中依据列表的一个结构示意图。在图4的第一列中，具体展示了依据项目的内容，例如依据项目1网元上是否承载有隧道tunnel和虚链路(pseudo wire，pw)业务，依据项目2承载的tunnel和pw主备业务是否均受影响，依据项目3直连的对端网元是否是网关网元等。依据项目的内容的来源可以包括多种方式，例如以下两种方式中的任意一种或多种方式。
1)导致资源上报告警的可能原因。例如以NE_COMMU_BREAK为例进行说明，NE_COMMU_BREAK是脱管告警，表征网元和网管通信中断。若网元303的对端网元304的端口未使能，会导致网元303脱管；网元304和网元303之间的光纤中断或机房停电也会导致网元303脱管。又例如以ETH_LOS为例，ETH_LOS为网元连接丢失告警，该告警表征以太网端口接收不到以太网信号。请参阅图5，图5为本申请实施例中导致资源上报ETH_LOS的可能原因的流程示意图。网元304上报ETH_LOS的原因包括设备掉电，单板故障，温度高和光纤损坏。若网元304掉电，则会导致网元304上报RMT_POWER_OFF，退服，上报ETH_LOS。若网元304单板故障或温度高，则会导致网元304分别上报Hard_ERR和TEMP_OVER，并导致光模块发光弱和收光弱，网元304上报ETH_LOS。若网元304和网元303之间的光纤损坏，则会导致链路光衰大，从而导致收光弱，网元304上报ETH_LOS。具体可能导致某告警产生的原因均可以通过查看官方的告警手册来订阅查找，作为标注的依据项目。
2)资源上报告警后的可能影响。还是以NE_COMMU_BREAK为例。网元303上报NE_COMMU_BREAK后，可能只会影响一侧的TUNNEL和PW业务，也有可能会影响其承载的所有业务；除此以外，网元303连接的对端网元可能只有一端上报ETH_LOS告警，也有可能对端网元都上报ETH_LOS告警。这里需要说明的是，告警的可能影响遵循的是从下层往上层查找的顺序，也支持水平查找，但不支持从上层往下层查找，这种查找方式符合故障从下层往上层逐层衍生告警的逻辑。上下层是指上层业务承载在下层链路上，类似于计算机网络的分层架构，第一层是光纤，第二层是承载在光纤上的链路，第三层是承载在链路上的业务，如隧道等，第四层又是承载在隧道业务上的其他业务，比如虚拟专用网(Virtual PrivateNetwork，VPN)业务等，上下层其实就是一种承载关系。
在图4的第二列中包括是/否选项，用于展示与第一列对应的依据项目的选中情况，例如对于依据项目1，图示中通过在“是”的选项中打勾，从而依据项目1的选中情况为“是”。类似的，其它依据项目的选中情况也可以在第二列中找到对应的选项。在依据项目的内容确定的情况下，第二列的内容可以人工填入，也可以第一设备根据收集的信息自动填入。例如对于依据项目1，第一设备可以查询网元303的资料，从而确定网元303是否承载有tunnel和pw业务。查询结果为“是”的情况下，则在依据项目1对应的选项中的“是”中打勾。进一步地，对于第一设备自动填入的选项，运维人员可以对其进行修正，以便提升数据的准确性。
在图4中除了包括上述依据项目和是/否选项，在第三列中还可以包括重要程度，该重要程度用于描述不同是/否选项之间的权重关系，在后续的计算中，将会有关于该重要程度的描述。
本申请的主旨在于用第一故障信息和已知故障信息对比，已知故障信息包括第二故障信息。但是在第二故障信息的处理中，便可以在一定程度上辅助运维人员准确的确定第二故障信息的根因。下面进行相关阐述。
在图3对应的第二故障信息的场景中，网元304上报了ETH_LOS，该ETH_LOS用于表征网元304与网元303之间的光纤断开。在网元304与网元303之间光纤断开或者上报NE_NOT_LOGIN的网元303掉电退服的情况下，都会导致图3中所示的故障场景，即对应的资源上报图中所示的告警，构建图3所示的拓扑图。通过构建依据项目，可以辅助运维人员识别真正的根因。例如网元303掉电退服时，以网元303为源宿的Tunnel和PW业务均会受影响，从而上报MPLS_TUNNEL_LOCV或者MPLS_PW_LOCV告警，而在光纤断开导致的网元303未登录故障场景中，由于Tunnel和PW业务有主备倒换机制的保护，所以只有一侧的业务，而不是所有的业务都会受影响。当运维人员在观看图4所示的依据项目时，发现图4第二列第二行对应的选项为“否”。运维人员若不信任第一设备给出的选项结果，运维人员可以去验证网元303的Tunnel和PW主备业务是否均受影响。运维人员若信任第一设备给出的选项结果，则可以以此确定网元303不是第二故障信息的根因，从而对在步骤203选定的根因进行修改。因此，项目依据以及是/否选项的组合，可以辅助运维人员确定第二故障信息的根因。
上面还描述了网元304上报ETH_LOS的可能原因，因此，若运维人员根据项目依据确定网元303不是根因，重新选择网元304和网元303之间的端口或光纤作为根因，则运维人员可以依据网元304上报ETH_LOS的可能原因确定网元304和网元303之间的端口或光纤是否为根因，此处描述的网元304上报ETH_LOS的可能原因也可以理解为依据项目。
在步骤205中，第一设备根据对多个选项的选定结果获取一个第二向量。
在上述步骤204中，第一设备展示了NE_NOT_LOGIN对应的多个选项，具体可以参阅图4。根据图4中第二列，即是/否选项中的选定结果，第一设备获得一个第二向量(1,1,1,1,1,1)。其中，如果是/否选项中的选定结果为“是”，则赋值为1，为“否”则赋值为0，并按照依据项目的排列顺序进行赋值。若NE_NOT_LOGIN不是故障根因，即网元303不是根因，故障根因其实是ETH_LOS，根因是网元303和网元304之间的光纤，则第一设备获取的第二向量应当是(1,0,1,1,1,1)。这意味着同一告警在不同的故障场景中可以被表示为不同的向量，向量的特征值来源于对依据项目的选中情况。
上面描述了第一设备获取一个告警NE_NOT_LOGIN对应的一个第二向量，在步骤202中，假设了第二故障信息包括ETH_LOS，MPLS_TUNNEL_LOCV，NE_NOT_LOGIN三个告警。类似的，第一设备可以通过上述方法再获取ETH_LOS对应的一个第二向量和MPLS_TUNNEL_LOCV对应的一个第二向量。根据这三个第二向量，得到第二向量集合P2：
Figure BDA0002689414170000081
其中，第二向量集合中的第一行为NE_NOT_LOGIN对应的第二向量，假设第二行为与ETH_LOS对应的第二向量，第三行为与MPLS_TUNNEL_LOCV对应的第二向量。需要说明的是，null表示为空，即ETH_LOS对应的依据项目只有5个选项。因此，第二向量集合中每个向量的长度可以不同。在图4中，还包括了NE_NOT_LOGIN对应的第二向量的权重，此处补充其它两个告警对应的第二向量的权重，形成权重矩阵Q2：
Figure BDA0002689414170000082
其中，Q2中每个特征值与P2中的相同位置的特征值对应。例如，Q2中第一行第二列的0.8与P2中第一行第二列中的1对应。应当说明的是，为了不重复赘述，本申请实施例并未提供类似图4的对ETH_LOS和MPLS_TUNNEL_LOCV的描述，因此，假设了Q2中第二行和第三行的内容。
可选地，除了图4所示的依据列表，在实际应用中，依据列表中还可以包括依据项目“是否存在与选定告警相同的告警”。请参阅6，图6为本申请实施例中的一个拓扑图。图6包括网元601-608，以及基站609，基站610。在图6所示的场景中，网元605掉电退服会导致网元605、网元606、网元607和网元608这四个网元都产生NE_NOT_LOGIN告警，即NE_NOT_LOGIN告警对应了四个资源对象。此时，将这种一种告警对应多个资源对象的关系映射到依据列表中，可以基于原来一种告警对应一个资源对象下得到的第二向量进行扩展和修改。例如对原来图5中的依据列表中，增加依据项目“是否存在多个网元未登陆脱管”。如果该依据项目的选中结果为0，说明只有一个网元脱管告警；如果该依据项目的选中结果为1，说明有多个网元脱管告警。具体的依据列表请参阅图7，图7为本申请实施例中依据列表的另一个结构示意图。在图6的场景中，依据图7中第二列的选中结果，第一设备可以得到NE_NOT_LOGIN对应的第二向量为(1,1,1,1,1,1,1)。在图4的场景中，依据图7中第二列的选中结果，第一设备可以得到NE_NOT_LOGIN对应的第二向量为(0,1,1,1,1,1,1)。应当说明的是，本申请不限定依据项目的内容的具体文字表达，只需表达的含义类似即可。并且，图7中的依据列表中的依据项目不一定要完全包括图5所示的依据列表中的依据项目。例如可以删除图7中的最后一个依据项目，得到只有6个依据项目的依据列表。通过依据项目“是否存在与选定告警相同的告警”，提升了在一种告警对应多个资源对象的场景下，利用本申请实施例中确定故障根因的方法的准确性。
上面对第二故障信息的处理进行了描述，第二故障信息属于已知的N份故障信息中的一份故障信息。为了不重复赘述，除了第二故障信息以外其它的故障信息的处理，可以参照上述对第二故障信息的处理流程。自此，第一设备得到了N份已知故障信息。在此基础上，第一设备在获取第一故障信息后，根据该N份已知故障信息确定与第一故障信息的根因相关的信息。下面将对此进行相应描述。其中，与第一故障信息的根因相关的信息可以是第一故障信息的根因，也可以是第一故障信息的故障根因。
请参阅图8，图8为本申请实施例中确定故障根因的流程示意图。
在步骤801中，第一设备获取第一故障信息，第一故障信息包括M条告警。
该步骤可以参考前述图2中步骤201的描述。P和M可以相同，也可以不同，在上面的描述中，假设了P等于3，于在此处，假设M等2。
在步骤802中，第一设备基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息。
此处，可以理解为第一故障信息与N份已知故障信息的匹配过程。为了方便描述，此处以第二故障信息与第一故障信息的匹配流程进行描述，其它已知故障信息与第一故障信息的匹配流程可以参考第二故障信息与第一故障信息的匹配流程。假设第一故障信息包括ETH_LOS和NE_NOT_LOGIN两个告警。第一故障信息对应的拓扑图可以参考图3中的物理层部分。当然，第一故障信息对应的拓扑图与第二故障信息对应的拓扑图的物理层不同时，也不影响本申请实施例利用确定故障根因的方法确定第一故障信息的根因。
为了确定第一故障信息和第二故障信息是否匹配，第一设备需要获取第一向量集合P1。为了获取P1，需要获取ETH_LOS对应的第一向量和NE_NOT_LOGIN对应的第一向量。此处以获取NE_NOT_LOGIN对应的第一向量为例进行阐述。在本申请实施例中，每个相同类型的告警对应的多个依据项目可以相同。第一故障信息中的NE_NOT_LOGIN和第二故障信息中的NE_NOT_LOGIN的告警类型相同，则可以共用多个依据项目。对于第一故障信息中的NE_NOT_LOGIN对应的依据列表的结构示意图，可以参照前述图4。应当说明的是，虽然两个NE_NOT_LOGIN的多个依据项目相同，但在不同的situation中，图4中第二列的选中结果可能会不同。例如在第二故障信息中，NE_NOT_LOGIN对应的依据列表的第二列第四行中的选定结果为“是”，但在第一故障信息中，NE_NOT_LOGIN对应的依据列表的第二列第四行中的选定结果为“否”。假设第一故障信息中NE_NOT_LOGIN对应的第一向量为(1,1,1,0,1,1)。其中，如果是/否选项中的选定结果为“是”，则赋值为1，为“否”则赋值为0，并按照依据项目的排列顺序进行赋值。需要说明的是，第一向量可以通过第一设备收集的信息自动得到，也可以通过展示依据列表，接收运维人员输入的是/否选项中的选定结果得到。至此，第一设备得到了第一故障信息中NE_NOT_LOGIN对应的第一向量。与类似的，第一设备获取第一故障信息中ETH_LOS对应的第一向量。在得到第一故障信息中所有的告警的第一向量后，第一设备获取第一向量集合P1：
Figure BDA0002689414170000101
其中，第一向量集合中的第一行为NE_NOT_LOGIN对应的第一向量，假设第二行为与ETH_LOS对应的第一向量，第三行表示与MPLS_TUNNEL_LOCV对应的第一向量。由于第一故障信息中不包括MPLS_TUNNEL_LOCV，因此在P1中，第三行的特征值为null。
在前述图2的步骤205中，第一设备获取了第二故障信息对应的P2。在获取P1和P2后，第一设备通过P1和P2计算第一故障信息和第二故障信息的相似度。具体公式如下：
Figure BDA0002689414170000102
similarity(P1，P2)表示获取P1和P2的相似度。n表示第一故障信息和第二故障信息中告警个数较大的值，例如，在本申请实施例中，第一故障信息包括2个告警，第二故障信息包括3个告警，因此n为3。n也可以理解为P1和P2的行数。m为依据列表中依据项目的个数，或者为P1中每一行的特征值的数量，例如在P1中，第一行的m为6，第二行m为5。
Figure BDA0002689414170000103
为依据列表中重要程度的权重值，具体参阅上述Q1。Wi为告警的紧急程度。
Figure BDA0002689414170000104
表示P1中第i个告警的第j个特征值。
Figure BDA0002689414170000105
表示P2中第i个告警的第j个特征值，用表示中第i个告警的第j个属性特征值。Z是两个故障信息进行相似度计算时其中选取的告警的个数，这几个变量都是会根据故障场景的不同而发生变化的，其中Z的取值可以遵循以下原则：
1)两个向量集合的同一行只要有一个不全是Null，Z就加1；
2)两个向量集合的同一行全是Null，不对Z进行处理。
通过上述公式，第一设备得到了第一故障信息和第二故障信息的相似度similarity(P1，P2)。采用类似的方法，第一设备可以得到第一故障信息与其它N-1份已知故障信息的N-1个相似度。需要说明的是，此处只是举例说明第一故障信息和第二故障信息的相似度的算法，在实际应用中，本领域技术人员可以采用其它相似度的算法，或则根据需求进行改动。例如可以不使用Wi或Q1，又例如不需要向量集合P1和P2，单纯以向量的形式进行计算。又例如第一向量不以1和0进行编码，而是以其它数值进行编码等。
通过上述计算公式可以看到，相似度的计算仅仅依赖于第一向量和第二向量，和具体的故障场景无关，因此该算法的通用性和鲁棒性较强。并且，即使P1没有MPLS_TUNNEL_LOCV相关的向量，即第一故障信息没有MPLS_TUNNEL_LOCV，只要P1和P2匹配，第一设备也能依据后续的描述确定出与第一故障信息的根因相关的信息。
自此，第一设备得到了第一故障信息与N份已知故障信息的N个相似度。第一设备采用以下任意一种方式进行后续处理。
1)第一设备在N个相似度中选定与第一故障信息相似度最高的已知故障信息作为与第一故障信息匹配的故障信息。
2)第一设备在N个相似度中选定相似度大于预定值的至少一份已知故障信息作为与第一故障信息匹配的故障信息。
在步骤803中，第一设备基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
在上述步骤802中，第一设备确定了与第一故障信息匹配的一个或多个已知故障信息。下面描述第一设备如果和一个或多个已知故障信息中确定与第一故障信息的根因相关的信息。
若与第一故障信息匹配的是多个已知故障信息，第一设备可以展示该多份已知故障信息对应的多份候选信息。例如，如表一所示。第一设备确定了与第一故障信息匹配的是2个已知故障信息，分别是已知故障信息A和已知故障信息B。已知故障信息A的故障根因为ETH_LOS，根因为端口A，与第一故障信息的相似度为0.87。第一设备展示这2份候选信息给运维人员选择。运维人员根据候选信息以及自己的判断，选定一个候选信息。选定的操作对于第一设备而言便是根因选择信息。在第一设备接收到根因选择信息后，第一设备得到了一个选定的与第一故障信息匹配的已知故障信息。
故障信息名称 故障根因 根因 相似度
已知故障信息A NE_NOT_LOGIN 网元A 0.87
已知故障信息B MPLS_TUNNEL_LOCV 网元B的tunnel层 0.85
表一
若与第一故障信息匹配的是一个已知故障信息，则该一个已知故障信息就默认是选定的与第一故障信息匹配的已知故障信息。为了方便阐述，此处称一个已知故障信息为目标已知故障信息。下面将阐述如果根据目标已知故障信息确定与第一故障信息的根因相关的信息。
在前面的阐述可知，目标故障信息对应一个故障根因和根因，例如前述第二故障信息的故障根因为NE_NOT_LOGIN，根因为网元303。为了方便说明，此处假设目标故障信息是第二故障信息。若第一故障信息中也包括与NE_NOT_LOGIN相同类型的告警，第一设备确定第一故障信息中的故障根因为NE_NOT_LOGIN，根因为NE_NOT_LOGIN对应的网元。若第一故障信息中不包括NE_NOT_LOGIN，则第一设备可以将第一故障信息的拓扑图和目标故障信息的拓扑图比较，在第一故障信息的拓扑图中得到与网元303对应的网元，并将该网元作为第一故障信息的根因。在这种情况下，第一故障信息不存在故障根因，只存在根因。并且，由于该网元是第一故障信息的根因，则该网元和第一故障信息中的一个或多个告警相关。
上面对本申请实施例中确定故障根因的方法进行了描述，需要说明的是，上述不同的步骤可以在不同的设备中执行，例如获取P1和P2的步骤可以在不同的设备中执行，或者N份已知故障信息是不同的设备得到的。下面对本申请实施例中确定故障根因的装置进行描述。
请参阅图9，图9为本申请实施例中确定故障根因的装置的结构示意图。
该装置包括：获取模块901，用于获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数；
第一确定模块902，用于基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；
第二确定模块903，用于基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
在一种可选设计中，第一确定单元902具体用于基于第一故障信息中的M条告警和第一已知故障信息中的P条告警确定第一故障信息与第一已知故障信息的第一相似度，其中第一已知故障信息包含于N份已知故障信息，其中P为大于等于1的整数；第一确定单元902具体用于基于确定第一相似度的方法，计算第一故障信息分别与N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度；第一确定单元902具体用于基于第一相似度和N-1个相似度，确定与第一故障信息匹配的至少一份已知故障信息。
在一种可选设计中，第一确定单元902具体用于获取第一故障信息对应的第一向量集合，第一向量集合包括M个第一向量，M个第一向量与M条告警一一对应，M个第一向量中每个第一向量的部分或全部特征用于表征M条告警中的一条告警对网络的影响和/或产生一条告警的原因；第一确定单元902具体用于获取第一向量集合和第二向量集合的第一相似度，第二向量集合包括P个第一向量，P个第一向量与P条告警一一对应。
在一种可选设计中，与第一故障信息匹配的至少一份已知故障信息包括：N份已知故障信息中与第一故障信息的相似度最高的已知故障信息；或N份已知故障信息中与第一故障信息的相似度超过预定值的至少一份已知故障信息。
在一种可选设计中，第二确定单元903具体用于基于至少一份已知故障信息的故障根因确定第一故障信息的根因；或者，第二确定单元903具体用于基于至少一份已知故障信息的故障根因确定与第一故障信息中的一条告警相关的实体是否是第一故障信息的根因。
在一种可选设计中，至少一份已知故障信息的故障根因对应的告警的类型与第一故障信息的根因对应的告警的类型相同。
在一种可选设计中，当与第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时：第二确定单元903具体用于确定与多份已知故障信息分别对应的多份与第一故障信息的根因相关的候选信息；第二确定单元903具体用于接收根因选择信息；第二确定单元903具体用于基于根因选择信息，从多份候选信息中确定与第一故障信息的根因相关的信息。
上面对本申请实施例中确定故障根因的装置进行了描述，下面对本申请实施例中的确定故障根因的设备进行描述。
请参阅图10，图10为本申请实施例中确定故障根因的设备的结构示意图。
确定故障根因的设备1000包括存储器1020和处理器1010。故障根因的设备1000可以是图2和/或图8所述的第一设备。处理器1010可以是专用集成电路(application-specific integrated circuit，ASIC)，或数字信号处理器(digital signal processing，DSP),或其它具体处理功能的芯片，例如基带芯片，或其任意组合。处理器1010可以是指一个处理器，也可以包括多个处理器。
存储器1020可以设置在处理器1010内部，也可以设置在处理器1010外部，存储器1020存储了如下的元素，可执行模块或者数据结构，或者它们的子集，或者它们的扩展集:操作指令：包括各种操作指令，用于实现各种操作。操作***：包括各种***程序，用于实现各种基础业务以及处理基于硬件的任务。处理器1010用于根据操作指令，以实现图2和图8任一图中第一设备可以执行的全部或部分操作。
具体地，存储器1020中存储有N份已知故障信息；
处理器1010用于获取第一故障信息，第一故障信息包括M条告警，其中M为大于等于1的整数；基于M条告警从N份已知故障信息中确定与第一故障信息匹配的至少一份已知故障信息，N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；基于至少一份已知故障信息的故障根因确定与第一故障信息的根因相关的信息。
在一种可选设计中，处理器1010具体用于基于第一故障信息中的M条告警和第一已知故障信息中的P条告警确定第一故障信息与第一已知故障信息的第一相似度，其中第一已知故障信息包含于N份已知故障信息，其中P为大于等于1的整数；基于确定第一相似度的方法，计算第一故障信息分别与N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度；基于第一相似度和N-1个相似度，确定与第一故障信息匹配的至少一份已知故障信息。
在一种可选设计中，处理器1010具体用于获取第一故障信息对应的第一向量集合，第一向量集合包括M个第一向量，M个第一向量与M条告警一一对应，M个第一向量中每个第一向量的部分或全部特征用于表征M条告警中的一条告警对网络的影响和/或产生一条告警的原因；获取第一向量集合和第二向量集合的第一相似度，第二向量集合包括P个第一向量，P个第一向量与P条告警一一对应。
在一种可选设计中，与第一故障信息匹配的至少一份已知故障信息包括：N份已知故障信息中与第一故障信息的相似度最高的已知故障信息；或N份已知故障信息中与第一故障信息的相似度超过预定值的至少一份已知故障信息。
在一种可选设计中，处理器1010具体用于基于至少一份已知故障信息的故障根因确定第一故障信息的根因；或者，处理器1010具体用于基于至少一份已知故障信息的故障根因确定与第一故障信息中的一条告警相关的实体是否是第一故障信息的根因。
在一种可选设计中，至少一份已知故障信息的故障根因对应的告警的类型与第一故障信息的根因对应的告警的类型相同。
在一种可选设计中，当与第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时：处理器1010具体用于确定与多份已知故障信息分别对应的多份与第一故障信息的根因相关的候选信息；接收根因选择信息；基于根因选择信息，从多份候选信息中确定与第一故障信息的根因相关的信息。
在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：闪存盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (17)

1.一种确定故障根因的方法，其特征在于，包括：
获取第一故障信息，所述第一故障信息包括M条告警，其中M为大于等于1的整数；
基于所述M条告警从N份已知故障信息中确定与所述第一故障信息匹配的至少一份已知故障信息，所述N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；
基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息的根因相关的信息。
2.根据权利要求1所述的方法，其特征在于，所述基于所述多条告警从N份已知故障信息中确定与所述第一故障信息匹配的至少一份已知故障信息，所述N份已知故障信息中的每一份均包括多条告警包括：
基于所述第一故障信息中的所述M条告警和第一已知故障信息中的P条告警确定所述第一故障信息与所述第一已知故障信息的第一相似度，其中所述第一已知故障信息包含于所述N份已知故障信息，其中P为大于等于1的整数；
基于确定所述第一相似度的方法，计算所述第一故障信息分别与所述N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度；
基于所述第一相似度和所述N-1个相似度，确定与所述第一故障信息匹配的至少一份已知故障信息。
3.根据权利要求2所述的方法，其特征在于，所述基于所述第一故障信息中的所述M条告警和第一已知故障信息中的P条告警确定所述第一故障信息与所述第一已知故障信息的第一相似度包括：
获取所述第一故障信息对应的第一向量集合，所述第一向量集合包括M个第一向量，所述M个第一向量与所述M条告警一一对应，所述M个第一向量中每个第一向量的部分或全部特征用于表征所述M条告警中的一条告警对网络的影响和/或产生所述一条告警的原因；
获取所述第一向量集合和第二向量集合的所述第一相似度，所述第二向量集合包括P个第二向量，所述P个第二向量与所述P条告警一一对应。
4.根据权利要求1至3中任一项所述的方法，其特征在于，与所述第一故障信息匹配的至少一份已知故障信息包括：
所述N份已知故障信息中与所述第一故障信息的相似度最高的已知故障信息；或
所述N份已知故障信息中与所述第一故障信息的相似度超过预定值的至少一份已知故障信息。
5.根据权利要求1至4中任一项所述的方法，其特征在于，所述基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息的根因相关的信息包括：
基于所述至少一份已知故障信息的故障根因确定所述第一故障信息的根因；
或者，基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息中的一条告警相关的实体是否是所述第一故障信息的根因。
6.根据权利要求5所述的方法，其特征在于，所述至少一份已知故障信息的故障根因对应的告警的类型与所述第一故障信息的根因对应的告警的类型相同。
7.根据权利要求1至6中任一项所述的方法，其特征在于，当与所述第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时，所述基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息的根因相关的信息包括：
确定与所述多份已知故障信息分别对应的多份与所述第一故障信息的根因相关的候选信息；
接收根因选择信息；
基于所述根因选择信息，从所述多份候选信息中确定与所述第一故障信息的根因相关的信息。
8.一种确定故障根因的装置，其特征在于，包括：
获取模块，用于获取第一故障信息，所述第一故障信息包括M条告警，其中M为大于等于1的整数；
第一确定模块，用于基于所述M条告警从N份已知故障信息中确定与所述第一故障信息匹配的至少一份已知故障信息，所述N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；
第二确定模块，用于基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息的根因相关的信息。
9.根据权利要求8所述的装置，其特征在于，
所述第一确定单元具体用于基于所述第一故障信息中的所述M条告警和第一已知故障信息中的P条告警确定所述第一故障信息与所述第一已知故障信息的第一相似度，其中所述第一已知故障信息包含于所述N份已知故障信息，其中P为大于等于1的整数；
所述第一确定单元具体用于基于确定所述第一相似度的方法，计算所述第一故障信息分别与所述N份已知故障信息中剩余的N-1份已知故障信息的N-1个相似度；
所述第一确定单元具体用于基于所述第一相似度和所述N-1个相似度，确定与所述第一故障信息匹配的至少一份已知故障信息。
10.根据权利要求9所述的装置，其特征在于，
所述第一确定单元具体用于获取所述第一故障信息对应的第一向量集合，所述第一向量集合包括M个第一向量，所述M个第一向量与所述M条告警一一对应，所述M个第一向量中每个第一向量的部分或全部特征用于表征所述M条告警中的一条告警对网络的影响和/或产生所述一条告警的原因；
所述第一确定单元具体用于获取所述第一向量集合和第二向量集合的所述第一相似度，所述第二向量集合包括P个第二向量，所述P个第二向量与所述P条告警一一对应。
11.根据权利要求8至10中任一项所述的装置，其特征在于，与所述第一故障信息匹配的至少一份已知故障信息包括：
所述N份已知故障信息中与所述第一故障信息的相似度最高的已知故障信息；
或所述N份已知故障信息中与所述第一故障信息的相似度超过预定值的至少一份已知故障信息。
12.根据权利要求8至11中任一项所述的装置，其特征在于，
所述第二确定单元具体用于基于所述至少一份已知故障信息的故障根因确定所述第一故障信息的根因；
或者，所述第二确定单元具体用于基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息中的一条告警相关的实体是否是所述第一故障信息的根因。
13.根据权利要求12所述的装置，其特征在于，所述至少一份已知故障信息的故障根因对应的告警的类型与所述第一故障信息的根因对应的告警的类型相同。
14.根据权利要求8至13中任一项所述的装置，其特征在于，当与所述第一故障信息匹配的至少一份已知故障信息为多份已知故障信息时：
所述第二确定单元具体用于确定与所述多份已知故障信息分别对应的多份与所述第一故障信息的根因相关的候选信息；
所述第二确定单元具体用于接收根因选择信息；
所述第二确定单元具体用于基于所述根因选择信息，从所述多份候选信息中确定与所述第一故障信息的根因相关的信息。
15.一种确定故障根因的设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有N份已知故障信息；
所述处理器用于获取第一故障信息，所述第一故障信息包括M条告警，其中M为大于等于1的整数；
所述处理器还用于基于所述M条告警从所述N份已知故障信息中确定与所述第一故障信息匹配的至少一份已知故障信息，所述N份已知故障信息中的每一份均包括多条告警，其中N为大于等于2的整数；
所述处理器还用于基于所述至少一份已知故障信息的故障根因确定与所述第一故障信息的根因相关的信息。
16.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有指令，所述指令在计算机上执行时，使得所述计算机执行如前述权利要求1-7中任意一种实施方式所述的方法。
17.一种计算机程序产品，其特征在于，所述计算机程序产品在计算机上执行时，使得所述计算机执行如前述权利要求1-7中任意一种实施方式所述的方法。
CN202010986439.1A 2020-09-18 2020-09-18 确定故障根因的方法，装置以及相关设备 Pending CN114285730A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202010986439.1A CN114285730A (zh) 2020-09-18 2020-09-18 确定故障根因的方法，装置以及相关设备
PCT/CN2021/107015 WO2022057428A1 (zh) 2020-09-18 2021-07-19 确定故障根因的方法，装置以及相关设备
EP21868257.3A EP4206927A4 (en) 2020-09-18 2021-07-19 METHOD AND APPARATUS FOR DETERMINING THE ROOT CAUSE OF A FAULT AND ASSOCIATED APPARATUS
US18/185,910 US20230231760A1 (en) 2020-09-18 2023-03-17 Method and Apparatus for Determining Fault Root Cause and Related Device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010986439.1A CN114285730A (zh) 2020-09-18 2020-09-18 确定故障根因的方法，装置以及相关设备

Publications (1)

Publication Number Publication Date
CN114285730A true CN114285730A (zh) 2022-04-05

Family

ID=80775880

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010986439.1A Pending CN114285730A (zh) 2020-09-18 2020-09-18 确定故障根因的方法，装置以及相关设备

Country Status (4)

Country Link
US (1) US20230231760A1 (zh)
EP (1) EP4206927A4 (zh)
CN (1) CN114285730A (zh)
WO (1) WO2022057428A1 (zh)

Citations (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2031474A1 (fr) * 2007-08-27 2009-03-04 Peugeot Citroën Automobiles Société Anonyme Procédé et dispositif de diagnostic de pannes multiples survenues dans des matériels
WO2011015135A1 (zh) * 2009-08-04 2011-02-10 华为技术有限公司 一种***故障检测的方法及装置
US20110078163A1 (en) * 2008-04-21 2011-03-31 Andras Veres Method and system for network fault management
EP2700197A1 (en) * 2011-04-21 2014-02-26 Telefonaktiebolaget LM Ericsson (PUBL) Recovery from multiple faults in a communications network
CN105471659A (zh) * 2015-12-25 2016-04-06 华为技术有限公司 一种故障根因分析方法和分析设备
CN105812177A (zh) * 2016-03-08 2016-07-27 华为技术有限公司 一种网络故障处理方法和处理设备
CN107171819A (zh) * 2016-03-07 2017-09-15 北京华为数字技术有限公司 一种网络故障诊断方法及装置
CN108452526A (zh) * 2017-11-28 2018-08-28 腾讯科技（上海）有限公司 游戏故障原因的查询方法和装置、存储介质、电子装置
CN109218114A (zh) * 2018-11-12 2019-01-15 西安微电子技术研究所 一种基于决策树的服务器故障自动检测***及检测方法
CN109407649A (zh) * 2018-10-09 2019-03-01 宁波大学 一种基于故障特征变量选择的故障类型匹配方法
CN109428647A (zh) * 2017-08-31 2019-03-05 华为技术有限公司 实现故障原因定位的方法、装置及存储介质
CN109684181A (zh) * 2018-11-20 2019-04-26 华为技术有限公司 告警根因分析方法、装置、设备及存储介质
CN110309009A (zh) * 2019-05-21 2019-10-08 北京云集智造科技有限公司 基于情境的运维故障根因定位方法、装置、设备及介质
CN110460460A (zh) * 2019-07-08 2019-11-15 阿里巴巴集团控股有限公司 业务链路故障定位方法、装置及设备
CN110493042A (zh) * 2019-08-16 2019-11-22 中国联合网络通信集团有限公司 故障诊断方法、装置及服务器
CN110609759A (zh) * 2018-06-15 2019-12-24 华为技术有限公司 一种故障根因分析的方法及装置
CN111158977A (zh) * 2019-12-12 2020-05-15 深圳前海微众银行股份有限公司 一种异常事件根因定位方法及装置
CN111193627A (zh) * 2019-12-31 2020-05-22 ***通信集团江苏有限公司 信息处理方法、装置、设备及存储介质
WO2020123417A2 (en) * 2018-12-13 2020-06-18 Carrier Corporation A method for commissioning and maintenance of alarm systems
CN111385106A (zh) * 2018-12-11 2020-07-07 华为技术有限公司 一种用于故障根因的识别方法、装置和设备
CN111431736A (zh) * 2020-02-27 2020-07-17 华为技术有限公司 告警关联规则生成方法和装置
CN111555921A (zh) * 2020-04-29 2020-08-18 平安科技（深圳）有限公司 告警根因的定位方法、装置、计算机设备和存储介质
CN111669282A (zh) * 2019-03-08 2020-09-15 华为技术有限公司 识别疑似根因告警的方法、装置及计算机存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008149975A1 (ja) * 2007-06-06 2008-12-11 Nec Corporation 通信網の障害原因分析システムと障害原因分析方法、及び障害原因分析用プログラム
CN109597392A (zh) * 2017-09-30 2019-04-09 西门子公司 有助于故障诊断的方法、装置和设备以及机器可读介质
CN108009040B (zh) * 2017-12-12 2021-05-04 杭州时趣信息技术有限公司 一种确定故障根因的方法、***和计算机可读存储介质
US20190361759A1 (en) * 2018-05-22 2019-11-28 At&T Intellectual Property I, L.P. System and method to identify failed points of network impacts in real time

Patent Citations (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2031474A1 (fr) * 2007-08-27 2009-03-04 Peugeot Citroën Automobiles Société Anonyme Procédé et dispositif de diagnostic de pannes multiples survenues dans des matériels
US20110078163A1 (en) * 2008-04-21 2011-03-31 Andras Veres Method and system for network fault management
WO2011015135A1 (zh) * 2009-08-04 2011-02-10 华为技术有限公司 一种***故障检测的方法及装置
EP2700197A1 (en) * 2011-04-21 2014-02-26 Telefonaktiebolaget LM Ericsson (PUBL) Recovery from multiple faults in a communications network
CN105471659A (zh) * 2015-12-25 2016-04-06 华为技术有限公司 一种故障根因分析方法和分析设备
CN107171819A (zh) * 2016-03-07 2017-09-15 北京华为数字技术有限公司 一种网络故障诊断方法及装置
CN105812177A (zh) * 2016-03-08 2016-07-27 华为技术有限公司 一种网络故障处理方法和处理设备
CN109428647A (zh) * 2017-08-31 2019-03-05 华为技术有限公司 实现故障原因定位的方法、装置及存储介质
CN108452526A (zh) * 2017-11-28 2018-08-28 腾讯科技（上海）有限公司 游戏故障原因的查询方法和装置、存储介质、电子装置
CN110609759A (zh) * 2018-06-15 2019-12-24 华为技术有限公司 一种故障根因分析的方法及装置
CN109407649A (zh) * 2018-10-09 2019-03-01 宁波大学 一种基于故障特征变量选择的故障类型匹配方法
CN109218114A (zh) * 2018-11-12 2019-01-15 西安微电子技术研究所 一种基于决策树的服务器故障自动检测***及检测方法
CN109684181A (zh) * 2018-11-20 2019-04-26 华为技术有限公司 告警根因分析方法、装置、设备及存储介质
CN111385106A (zh) * 2018-12-11 2020-07-07 华为技术有限公司 一种用于故障根因的识别方法、装置和设备
WO2020123417A2 (en) * 2018-12-13 2020-06-18 Carrier Corporation A method for commissioning and maintenance of alarm systems
US20210365021A1 (en) * 2018-12-13 2021-11-25 Carrier Corporation A method for commissioning and maintenance of alarm systems
CN111669282A (zh) * 2019-03-08 2020-09-15 华为技术有限公司 识别疑似根因告警的方法、装置及计算机存储介质
CN110309009A (zh) * 2019-05-21 2019-10-08 北京云集智造科技有限公司 基于情境的运维故障根因定位方法、装置、设备及介质
CN110460460A (zh) * 2019-07-08 2019-11-15 阿里巴巴集团控股有限公司 业务链路故障定位方法、装置及设备
CN110493042A (zh) * 2019-08-16 2019-11-22 中国联合网络通信集团有限公司 故障诊断方法、装置及服务器
CN111158977A (zh) * 2019-12-12 2020-05-15 深圳前海微众银行股份有限公司 一种异常事件根因定位方法及装置
CN111193627A (zh) * 2019-12-31 2020-05-22 ***通信集团江苏有限公司 信息处理方法、装置、设备及存储介质
CN111431736A (zh) * 2020-02-27 2020-07-17 华为技术有限公司 告警关联规则生成方法和装置
CN111555921A (zh) * 2020-04-29 2020-08-18 平安科技（深圳）有限公司 告警根因的定位方法、装置、计算机设备和存储介质

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
叶昊;范牛军;刘宝峰;李青志;: "基于代码书的电力二次***故障定位方法", 清华大学学报(自然科学版), no. 12 *
沈晓慧等: "自动化运维管理***故障处理机制的设计与实现", 《电子世界》 *
沈晓慧等: "自动化运维管理***故障处理机制的设计与实现", 《电子世界》, no. 15, 14 August 2020 (2020-08-14) *
陆路: "网络故障告警关联技术的讨论", 《职业》 *
陆路: "网络故障告警关联技术的讨论", 《职业》, no. 33, 25 November 2013 (2013-11-25) *

Also Published As

Publication number Publication date
EP4206927A4 (en) 2024-01-17
EP4206927A1 (en) 2023-07-05
US20230231760A1 (en) 2023-07-20
WO2022057428A1 (zh) 2022-03-24

Similar Documents

Publication Publication Date Title
US20210099336A1 (en) Fault root cause analysis method and apparatus
US7725774B2 (en) Methods, systems, and media to correlate errors associated with a cluster
US7500142B1 (en) Preliminary classification of events to facilitate cause-based analysis
US10462027B2 (en) Cloud network stability
US20230318906A1 (en) Fault recovery plan determining method, apparatus, and system, and computer storage medium
US20130212257A1 (en) Computer program and monitoring apparatus
CN111193605A (zh) 一种故障定位方法、装置及存储介质
JP6280862B2 (ja) イベント分析システムおよび方法
CN110932976A (zh) 基于气象灾害的电网故障业务的恢复方法、装置及设备
CN113656252B (zh) 故障定位方法、装置、电子设备以及存储介质
CN117729576A (zh) 告警监控方法、装置、设备及存储介质
WO2021103800A1 (zh) 故障修复操作推荐方法、装置及存储介质
CN115630073B (zh) 基于边缘计算的电力物联网数据处理方法及平台
JP2006025434A (ja) 大容量障害相関システム及び方法
CN117389779A (zh) 一种微服务故障根因定位方法
CN114285730A (zh) 确定故障根因的方法，装置以及相关设备
CN113922347B (zh) 一种基于失配度评价指标的接地保护定值优化方法、***及存储介质
CN113271216B (zh) 一种数据处理方法及相关设备
CN114095394A (zh) 网络节点故障检测方法、装置、电子设备及存储介质
US8836466B2 (en) Monitoring system, device, monitoring method, and monitoring program
JP7189085B2 (ja) 異常箇所推定装置及び方法
Gardner et al. Finding geographic vulnerabilities in multilayer networks using reduced network state enumeration
WO2024105817A1 (ja) 決定装置、決定方法、及びプログラム
CN116166407A (zh) 资源池业务画像构建方法及***
CN118282041A (zh) 一种新能源电力***的能源管理方法和装置

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
AD01 Patent right deemed abandoned

Effective date of abandoning: 20240227

AD01 Patent right deemed abandoned