WO2023051097A1 - 网络故障诊断方法、装置、存储介质及电子装置 - Google Patents

Abstract

本公开实施例提供了一种网络故障诊断方法、装置、存储介质及电子装置。该方法包括：分析网络的告警信息将当前网络故障的产生场景组成场景列表；获取适用于所述当前网络故障的诊断建议模型，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；根据所述诊断命令排序列表中的优先级顺序执行诊断命令并接受诊断结果。通过本公开，基于从网络中采集到的网络运维数据，结合场景和诊断建议模型进行网络故障诊断的智能决策，因此，可以在合适的场景下执行相应的诊断命令，提高了诊断的精准性和诊断效率。

Description

网络故障诊断方法、装置、存储介质及电子装置

相关申请的交叉引用

本公开基于2021年9月30日提交的发明名称为“网络故障诊断方法、装置、存储介质和电子装置”的中国专利申请CN202111162407.0，并且要求该专利申请的优先权，通过引用将其所公开的内容全部并入本公开。

技术领域

本公开实施例涉及通信与信息技术领域，具体而言，涉及一种网络故障诊断方法、装置、存储介质和电子装置。

背景技术

随着通信技术的日益更新和第五代移动通信技术(5th Generation Mobile Communication Technology，5G)时代的到来，通信网络的结构越来越复杂，所涉及的通信设备越来越多；同时，社会对于通信网络的依赖度越来越高，无论是传统的计算机和通信行业，还是新兴的自动驾驶领域或物联网技术等，都对通信网络的稳定性有着相当高的要求。在这样的背景下，一旦网络出现故障，就要求能够迅速准确地对故障点进行定位和修复。然而，复杂的网络结构以及种类繁多的网络设备，运维数据的规模越来越大，给故障的快速定位带来了巨大的难度，为了提高网络故障定位的效率，保证网络故障恢复的及时性，一些相应的技术应运而生。

现有成熟的故障诊断中，常见做法是在基于规则库或知识库，结合相关资源分析和人工经验，演进成运维知识图谱，根据传入的告警或工单，借助根因分析，再执行一定诊断手段下发到网元对故障进行诊断，再把诊断结果回填给工单或守护方，整体是一个自动化过程，最后其诊断结果协助故障处理恢复。

这种自动诊断的方法，在传统网络如3G/4G网络中，运营商和设备商协力合作，规则和知识经验不断累积，已经卓有成效。但随着5G网络的建设和5G应用的展开，新的网络、新的场景、新的业务、端到端的业务和运维，都让传统诊断逐渐力不从心，尤其是以下三个方面：

第一个方面，由于传统网络相对固化和简明，所以传统的故障诊断基本上是针对特定专业网，如核心网、无线网或传输网等，而诊断跨域故障，对跨域跨专业的故障，不容易快速定位，如以同环的传输信号丢失(Loss Of Signal，LOS)或脱管告警引发无线的基站退服，再导致小区退服的场景为例，它牵涉了传输网、无线网，以及各自的告警，如传输告警光网络终端(Optical Network Terminal，ONT)信号丢失(LOS)、以太网物理光接口信号丢失(LOS)等告警，无线网发生了4G基站退服告警、长期演进(Long Term Evolution，LTE)小区退服告警等。基于指令的网络故障诊断方法往往需要进行多次尝试(如需要分别在无线网络和传输网络中进行基于指令的故障诊断)才能最终定位到准确的故障点，存在定位效率和定位精 度的问题，同时可能会对相关网络或设备造成额外的资源开销(如多余的网络开销或算力开销)。

第二个方面，新场景新业务的爆发，同样的场景可能有多种诊断手段，不同的业务需要不同的诊断手段，或需要快速初步定位简单重启即可，或需要精准定位，排查细节问题，而传统诊断方式显得过于单一。

第三个方面，故障诊断无论是下沉到网元管理系统(Element Management System，EMS)执行网元相关告警查询，还是下沉到网元执行参数查询或业务查询，都会带来一定网络或者网元、业务的冲击成本，不能随时执行，因此传统诊断方式是通过一定规则执行的，如对小区退服的诊断，规则上即定义一定时间限制范围，如4小时才能重新诊断，这里就有两个问题，一是客观环境已经满足诊断，但时限不够则会耽误诊断时间进而滞缓恢复时间，二是时限是人工根据过往经验设置，也许新环境、新场景时限设置太短导致诊断时冲击网络。因此，随着5G网络和其应用的展开，依靠规则显然无法面对5G网络的新业务的故障诊断，因此需要更灵活更实时的智能诊断防护手段。

发明内容

本公开实施例提供了一种网络故障诊断方法，以至少解决相关技术中依靠规则进行故障诊断的方式已不能满足网络的新业务的故障诊断的问题。

根据本公开的一个实施例，提供了一种网络故障诊断方法，包括：分析网络的告警信息将当前网络故障的产生场景组成场景列表；获取适用于所述当前网络故障的诊断建议模型，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；根据所述诊断命令排序列表中的优先级顺序执行诊断命令。

在一个示例性实施例中，分析网络的告警信息将当前网络故障的产生场景组成场景列表之前，还包括：采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息。

在一个示例性实施例中，分析网络的告警信息将当前网络故障的产生场景组成场景列表，包括：将所述告警信息输入运维知识库，并基于运维知识库中的历史诊断内容确定当前网络故障的产生场景，并组成场景列表。

在一个示例性实施例中，获取适用于所述当前网络故障的诊断建议模型包括：根据所述告警信息从所述运维知识库中确定适用于当前网络故障的诊断建议模型。

在一个示例性实施例中，根据所述诊断命令排序列表中的优先级顺序执行诊断命令，包括：按优先级顺序发送诊断命令到对应的网管或者网元中执行，并接受相应的诊断结果。

在一个示例性实施例中，在执行诊断命令之前或执行诊断命令时，还包括：根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。

在一个示例性实施例中，根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令，包括以下之一：在第一告警信息上报后又有同样的第二告警信息上报，则不执行对应所述第二告警信息的诊断命令，所述第二告警信息的诊断结果复用所述第一告警信息的诊断结果；在发出诊断命令时告警已消失，则停止执行本次诊断命令；本次诊断命令的执行需等待其它诊断结果，则暂缓执行本次诊断命令；诊断对象的资源负荷超出预定比例，暂缓执行本次诊断命令。

在一个示例性实施例中，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表，包括：按照历史有效诊断命令从多到少排序；和/或按照诊断资源消耗从少到多进行排序。

在一个示例性实施例中，根据所述诊断命令排序列表中的优先级顺序执行诊断命令并接受诊断结果之后，还包括：对所述诊断结果进行解析，并将解析后的诊断结果记录到所述运维知识库中。

根据本公开的另一个实施例，提供了一种网络故障诊断装置，包括：

场景分析器，设置为分析网络的告警信息，并将当前网络故障的产生场景组成场景列表；智能决策引擎，设置为获取适用于所述当前网络故障的诊断建议模型，并将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；诊断执行器，设置为根据所述诊断命令排序列表中的优先级顺序执行诊断命令。

在一个示例性实施例中，所述网络故障诊断装置还包括：数据适配器，设置为采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息。

在一个示例性实施例中，所述网络故障诊断装置还包括：运维知识库，设置为根据输入的所述告警信息，确定当前网络故障的产生场景，以及确定适用于当前网络故障的诊断建议模型。

在一个示例性实施例中，所述网络故障诊断装置还包括：诊断监控器，设置为在执行诊断命令之前或执行诊断命令时，根据所述告警信息或诊断对象判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。

在一个示例性实施例中，所述运维知识库，还设置为对当前网络故障的诊断结果进行存储。

根据本公开的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本公开的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

附图说明

图1是根据本公开实施例的运行网络故障诊断方法的计算机终端的硬件结构框图；

图2是根据本公开实施例的网络架构图；

图3是根据本公开实施例的网络故障诊断方法流程图；

图4是根据本公开实施例的网络故障诊断装置的结构框图；

图5是根据本公开另一实施例的网络故障诊断装置的结构框图；

图6是根据本公开另一实施例的网络故障诊断方法流程图；

图7是根据本公开实施例的跨域网络故障分布示意图；

图8是根据本公开实施例的跨域网络故障诊断建议模型示意图；

图9是根据本公开实施例的诊断监控器处理流程示意图；

图10是根据本公开实施例的诊断执行器处理流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本公开的实施例。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

本申请实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本公开实施例的运行网络故障诊断方法的计算机终端的硬件结构框图。如图1所示，计算机终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器(Microcontroller Unit，MCU)或可编程逻辑器件(Field Programmable Gate Array，FPGA)等的处理装置)和用于存储数据的存储器104，其中，上述计算机终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述计算机终端的结构造成限定。例如，计算机终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本公开实施例中的网络故障诊断方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network lnterface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。下面将进一步描述本公开方法实施例所运行的装置的网络架构。图2是本公开实施例的网络架构图。如图2所示，在本公开实施例中，可以与运维系统进行交互，获取网络运维数据，并基于人工智能的运维知识库，对网络故障进行异常感知和故障分析，并可基于故障分析结果生成诊断命令下发至相关网元或网元管理系统进行执行，并接收反馈的诊断结果，从而实现了在综合和网络环境下的故障诊断功能。在本公开实施例中，同时提供了业务层运维和管控层运维两种运维场景下的故障诊断功能，进而能够提供跨专业网或单业网环境上的故障诊断功能。

在本实施例提供的故障网络方法中，能够基于网管设备从网络中采集到的告警、性能、日志和工单等相关运维数据，利用运维知识库中的运维知识进行场景分析和初步诊断方案的选择，再通过智能决策生成诊断命令集以及决策是否可以执行诊断操作，从而能够在合适情景下执行相应诊断命令，协助最终定位恢复故障，并将具体信息作为下一步运维的指导。

图3是根据本公开实施例的网络故障诊断方法流程图，该方法可以运行在图2所示的网络架构中。如图3所示，该流程包括如下步骤：

步骤S302，分析网络的告警信息将当前网络故障的产生场景组成场景列表；

步骤S304，获取适用于所述当前网络故障的诊断建议模型，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；

步骤S306，根据所述诊断命令排序列表中的优先级顺序执行诊断命令。

在本公开的上述实施例中，基于从网络中采集到的网络运维数据，结合场景和诊断建议模型进行网络故障诊断的智能决策，因此，可以在合适的场景下执行相应的诊断命令，提高了诊断的精准性和诊断效率。

在本实施例的步骤S302之前，还可以包括：采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息。

在本实施例的步骤S302中，可以包括：将所述告警信息输入运维知识库，并基于运维知识库中的历史诊断内容确定当前网络故障的产生场景，并组成场景列表。

在本实施例的步骤S302中，可以包括：根据所述告警信息从所述运维知识库中确定适用于当前网络故障的诊断建议模型。

在本实施例的步骤S306中，可以包括：按优先级顺序发送诊断命令到对应的网管或者网元中执行，并接受相应的诊断结果。

在本实施例中，在执行诊断命令之前或执行诊断命令时，还包括：根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。

在本实施例中，根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令，包括以下之一：在第一告警信息上报后又有同样的第二告警信息上报，则不执行对应所述第二告警信息的诊断命令，所述第二告警信息的诊断结果复用所述第一告警信息的诊断结果；在发出诊断命令时告警已消失，则停止执行本次诊断命令；本次诊断命令的执行需等待其它诊断结果，则暂缓执行本次诊断命令；诊断对象的资源负荷超出预定比例，暂缓执行本次诊断命令。

在本实施例的步骤S304中，可以包括：按照历史有效诊断命令从多到少排序；和/或按照诊断资源消耗从少到多进行排序。

在本实施例的步骤S306之后，还可以包括：对所述诊断结果进行解析，并将解析后的诊断结果记录到所述运维知识库中。

通过上述步骤，基于从网络中采集到的告警信息获取场景列表，再结合诊断建议模型进行智能决策，得到诊断命令排序列表。因此，可以在合适的场景下执行相应的诊断命令，达到诊断更加智能化、灵活化的效果，提高5G的智能运维水平。

在本实施例中，基于运维知识库可以实现综合网络环境下的故障诊断功能，即，在本实施例中，同时提供了业务层运维和管控层运维两种场景下的故障诊断功能。解决了在多专业网并存的情况下，基于管控层运维进行的故障诊断判断，存在误诊断或诊断结果并非最终问题点的问题，增强了诊断方法的灵活、健壮性以及准确性，并提升了诊断效率。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。

在本实施例中还提供了一种网络故障诊断装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是根据本公开实施例的网络故障诊断装置的结构框图，如图4所示，该装置包括场景分析器10、智能决策引擎20和诊断执行器30。

场景分析器10，设置为分析网络的告警信息，并将当前网络故障的产生场景组成场景列表。

智能决策引擎20，设置为获取适用于所述当前网络故障的诊断建议模型，并将所述诊断建议模型结合所述场景列表生成诊断命令排序列表。

诊断执行器30，设置为根据所述诊断命令排序列表中的优先级顺序执行诊断命令。

通过本实施例提供的网络故障诊断装置，基于采集到的网络运维数据，结合场景和诊断建议模型进行网络故障诊断的智能决策，因此，可以在合适的场景下执行相应的诊断命令，提高了诊断的精准性和诊断效率。

图5是根据本公开另一实施例的网络故障诊断装置的结构框图，如图5所示，该网络故障诊断装置除包括图4所示的所有模块外，还包括数据适配器40、运维知识库50和诊断监控器60。

数据适配器40，设置为采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息；

运维知识库50，设置为根据输入的所述告警信息，确定当前网络故障的产生场景，以及确定适用于当前网络故障的诊断建议模型；

诊断监控器60，设置为在执行诊断命令之前或执行诊断命令时，根据所述告警信息或诊断对象判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。

在本实施例中，所述运维知识库50，还设置为对当前网络故障的诊断结果进行存储。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

为了便于对本公开所提供的技术方案的理解，下面将结合具体场景的实施例进行详细描述。

本实施例提供了一种网络故障诊断方法，图6是本实施例的网络故障诊断方法流程图，如图6所示，该方法包括如下步骤：

步骤S601，获取运维数据；

具体地，从运维装置中获取工单或故障数据等运维数据；

步骤S602，得到所述网络故障的位置等故障信息；

具体地，通过数据适配器，得到网元位置、专业网和发生时间等故障信息；

步骤S603，得到所述网络故障的产生场景信息；

具体地，借助运维知识库，通过场景分析器得到诊断场景和诊断方向；

步骤S604，进行智能决策；

具体地，借助运维知识库，通过智能决策引擎生成诊断命令顺序、诊断流程，诊断是否 立即执行等决策信息；

步骤S605，执行诊断决策；

具体地，对于立即执行的诊断流程，则调用诊断执行器，生成跨厂商诊断命令，下发诊断执行，并等待和解析执行结果，多次多步执行，直到得到最终的诊断结果；

步骤S606，诊断监控；

具体地，在执行诊断命令之前或执行诊断命令时，对告警信息或诊断对象进行监控，并将监控信息反馈至智能决策引擎，所述智能决策引擎根据监控信息判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令；

步骤S607，诊断结果解析；

具体地，从诊断结果中解析出此次网络故障诊断是否成功、花费的时间、引起的网元或网元管理系统的CPU/内存等数据，并将数据写入运维知识库中，为下一次诊断提供基础；

步骤S608，判断诊断结果是否为最终结果；

具体地，若所述诊断结果是最终结果，则把诊断结果反馈到故障处理系统中；

若所述诊断结果不是最终结果，则返回至步骤S605中继续进行故障诊断；

在本实施例中，除了上述步骤还可包括人工反馈诊断结果，用于完善运维知识库。

在示例性实施例中，图7是跨域网络故障分布示意图，图8是跨域网络故障诊断建议模型示意图。在进行故障诊断之前，需要该复合网络中的历史故障数据和对应的故障诊断方法进行学习，输出离线运维知识库模型用于支撑运行时的运算支撑。下面将基于图7和8对本实施例的网络故障诊断过程进行相应的描述。

1、该网络的所有告警、日志信息被汇总至网管系统，本实施例的故障诊断装置从网管系统中拉取所有告警信息，并将其作为运维知识库的入参。运维知识库通过计算得出该网络属于复合网络场景，且确定网络连接L1上的告警L11为引发众多告警的主要原因，但是引发告警的故障暂未明确。

2、基于运维知识库中针对告警L11已存在的运维模型，运维知识库挑选出一套诊断建议模型，并将诊断建议模型和告警信息一并发送到智能决策引擎。诊断模型中的诊断建议会因为不同的场景而被赋予不同的权重，因此在不同场景下诊断命令序列的排列顺序会有所差异。

3、根据第2步的输出，智能决策引擎优先按诊断建议L111进行诊断操作。

a)将诊断L1111-1转化为统一诊断命令并下发至指令适配器进行适配，指令适配器下发指令并收集该指令的输出。

b)根据步骤3-a的输出，智能决策引擎判定下一步需要根据诊断L1111-2进行诊断，于是将诊断L1111-2转化为统一诊断命令并下发至指令适配器进行适配，指令适配器下发指令并收集该指令的输出。

c)根据步骤3-b的输出，智能决策引擎判定下一步需要根据诊断L1111-2-2进行诊断，于是将诊断L1111-2-2转化为统一诊断命令并下发至指令适配器进行适配。该指令需要分析设备23的日志信息，而网管系统正好采集了该设备的日志信息，于是指令适配器将指令下发至网管系统，获取日志并进行分析。

d)根据步骤3-c的输出，智能决策引擎认定此次诊断结果为最终故障，诊断至此结束。

可以看出，步骤3-c并未按诊断建议模型给出的实际优先级顺序进行诊断，这是由于智能诊断引擎会按照实际的指令执行结果并结合当下的告警数据分析情况自行决策最优的诊断 顺序。

在示例性实施例中，图9是诊断监控器处理流程示意图。在诊断执行过程中或者诊断执行发起前，诊断监控器都支持对诊断进行停止操作。仍然以LTE小区退服为例，至少存在以下4种场景，需要停止诊断：

1、当告警或者工单报上来后，已经发起了诊断，如果又来了一个同样的告警，则对新告警数据不再单独发起诊断，而是诊断结果的复用；

2、如果刚好发出了诊断命令，但诊断监控装置监控到告警已经恢复了，则必须终止本次诊断执行；

3、虽然是发生了LTE小区退服，但诊断监控装置监控到ONT信号丢失恢复，则必须暂缓诊断，等待是否有LTE小区退服恢复，如果告警没有恢复，则在规定时间内延迟诊断；

4、当诊断命令下发前，诊断监控装置监控到网管IO繁忙或者CPU有冲高情况，说明当前业务繁忙，则也必须暂缓诊断，会延迟等待装置空闲时，再进行诊断。

在示例性实施例中，图10是诊断执行器处理流程示意图。本实施以网元上参数配置错误导致的故障为例。在本实施例中，诊断指令要最终下发到具体网元，但不同厂商网元的接口不一致，所以需要指令适配。如图10所示，该处理流程包括以下步骤：

步骤S1001，智能决策引擎选取诊断指令。

具体地，智能决策引擎借助运维知识库决策出相关诊断指令。

步骤S1002，进行指令适配，即适配为被诊断设备支持的诊断指令。

步骤S1003，判断是否为网元设备开放指令，如果否，则执行步骤S1004，如果是，则执行步骤S1005。

步骤S1004，通过EMS网管下发指令。对诊断指令存在多步执行和并发执行，即对不同网元的诊断命令可以同时下发。如果下次指令的参数依赖于上次指令的执行结果，需要多次指令执行；

步骤S1005，下发诊断指令。

当对诊断指令存在多步执行和并发执行，即对不同网元的诊断命令可以同时下发。如果下次指令的参数依赖于上次指令的执行结果，需要多次指令执行。步骤S1006，诊断结果解析。

步骤S1007，组装诊断结果。

上述实例只是用于进行简单说明，实际诊断过程复杂得多，但是均遵循以上处理原则和处理逻辑。本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本公开的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施 例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。

以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (16)

1. 一种网络故障诊断方法，包括：

   分析网络的告警信息将当前网络故障的产生场景组成场景列表；

   获取适用于所述当前网络故障的诊断建议模型，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；

   根据所述诊断命令排序列表中的优先级顺序执行诊断命令。
2. 根据权利要求1所述的方法，其中，分析网络的告警信息将当前网络故障的产生场景组成场景列表之前，还包括：

   采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息。
3. 根据权利要求1所述的方法，其中，分析网络的告警信息将当前网络故障的产生场景组成场景列表，包括：

   将所述告警信息输入运维知识库，并基于运维知识库中的历史诊断内容确定当前网络故障的产生场景，并组成场景列表。
4. 根据权利要求3所述的方法，其中，获取适用于所述当前网络故障的诊断建议模型包括：

   根据所述告警信息从所述运维知识库中确定适用于当前网络故障的诊断建议模型。
5. 根据权利要求1所述的方法，其中，根据所述诊断命令排序列表中的优先级顺序执行诊断命令，包括：

   按优先级顺序发送诊断命令到对应的网管或者网元中执行，并接收相应的诊断结果。
6. 根据权利要求1所述的方法，其中，在执行诊断命令之前或执行诊断命令时，还包括：

   根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。
7. 根据权利要求6所述的方法，其中，根据网络当前状态判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令，包括以下之一：

   在第一告警信息上报后又有同样的第二告警信息上报，则不执行对应所述第二告警信息的诊断命令，所述第二告警信息的诊断结果复用所述第一告警信息的诊断结果；

   在发出诊断命令时告警已消失，则停止执行本次诊断命令；

   本次诊断命令的执行需等待其它诊断结果，则暂缓执行本次诊断命令；

   诊断对象的资源负荷超出预定比例，则暂缓执行本次诊断命令。
8. 根据权利要求1所述的方法，将所述诊断建议模型结合所述场景列表生成诊断命令排序列表，包括：

   按照历史有效诊断命令从多到少排序；和/或

   按照诊断资源消耗从少到多进行排序。
9. 根据权利要求3所述的方法，其中，根据所述诊断命令排序列表中的优先级顺序执行诊断命令并接受诊断结果之后，还包括：

   对所述诊断结果进行解析，并将解析后的诊断结果记录到所述运维知识库中。
10. 一种网络故障诊断装置，包括：

    场景分析器，设置为分析网络的告警信息，并将当前网络故障的产生场景组成场景列表；

    智能决策引擎，设置为获取适用于所述当前网络故障的诊断建议模型，并将所述诊断建议模型结合所述场景列表生成诊断命令排序列表；

    诊断执行器，设置为根据所述诊断命令排序列表中的优先级顺序执行诊断命令。
11. 根据权利要求10所述的诊断装置，还包括：

    数据适配器，设置为采集网络的运维数据和进行相应的数据格式转换，并通过解析所述运维数据获取告警信息。
12. 根据权利要求10所述的诊断装置，，还包括：

    运维知识库，设置为根据输入的所述告警信息，确定当前网络故障的产生场景，以及确定适用于当前网络故障的诊断建议模型。
13. 根据权利要求10所述的诊断装置，还包括：

    诊断监控器，设置为在执行诊断命令之前或执行诊断命令时，根据所述告警信息或诊断对象判断是否继续执行诊断命令、停止执行诊断命令或暂缓执行诊断命令。
14. 根据权利要求10所述的诊断装置，其中，

    所述运维知识库，还设置为对当前网络故障的诊断结果进行存储。
15. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被处理器执行时实现所述权利要求1至9任一项中所述的方法的步骤。
16. 一种电子装置，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述权利要求1至9任一项中所述的方法的步骤。

Images