CN115080284A - 业务系统的故障处理方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种业务系统的故障处理方法、装置、电子设备及计算机可读存储介质；涉及云技术领域的监控和故障检测技术；方法包括：监控业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果；根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点根据故障数据进行第二故障分析处理，得到第二故障分析结果；向运维节点发送第二故障分析结果，根据运维节点针对第二故障分析结果的反馈结果，执行故障处理流程。通过本申请，能够提供故障处理效率，以保证业务系统的稳定运行。

Description

业务系统的故障处理方法、装置及电子设备

技术领域

本申请涉及计算机技术，尤其涉及一种业务系统的故障处理方法、装置、电子设备及计算机可读存储介质。

背景技术

随着云技术领域的监控和故障检测技术的发展，人们日常的学习和生活使用运行在智能手机、平板、电脑的应用的频次越来越高，这些应用产品所依赖的业务系统的稳定运行是人们正常学习和生活的基本保证。

在业务系统运行过程中，若服务器遇到故障，可能会生成故障对应的告警信息，业务系统的运维人员收到对应故障告警时，需要针对所告警的故障进行一一处理，需要较长的处理时间以及较大的人力成本，降低了故障的处理效率，影响了业务系统的稳定运行。

发明内容

本申请实施例提供一种业务系统的故障处理方法、装置、电子设备及计算机可读存储介质，能够高效处理业务系统的故障。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种业务系统的故障处理方法，包括：

监控所述业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果；

根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，以使所述服务器供应方节点根据所述故障数据进行第二故障分析处理，得到第二故障分析结果；

向所述运维节点发送所述第二故障分析结果，根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程。

本申请实施例提供一种业务系统的故障处理装置，包括：

第一分析模块，用于监控所述业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果；

第二分析模块，用于根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，以使所述服务器供应方节点根据所述故障数据进行第二故障分析处理，得到第二故障分析结果；

审核模块，用于向所述运维节点发送所述第二故障分析结果，根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程。

在上述方案中，所述第一分析模块，还用于：接收所述业务系统发送的故障申报请求，所述故障申报请求是所述业务系统进行业务感知处理并确定发生故障的服务器时生成的；或者，接收监控系统发送的故障申报请求，所述故障申报请求是所述监控系统对对所述业务系统进行监控处理并确定发生故障的服务器时生成的；响应于所述故障申报请求，获取所述故障申报请求中携带的申报信息。

在上述方案中，所述代办工单的故障申报请求的来源是所述业务系统和监控系统中的任一个；所述第一分析模块，还用于：当所述故障申报请求的来源是所述业务系统时，向所述运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果。

在上述方案中，所述装置还包括第三分析模块，用于：当所述故障申报请求来源是所述监控系统时，向所述服务器供应方节点发送携带所述故障数据的代办工单，以使所述服务器供应方节点进行第三故障分析处理，得到第三故障分析结果；向所述运维节点发送所述第三故障分析结果，根据所述运维节点针对所述第三故障分析结果的反馈结果，执行故障处理流程。

在上述方案中，所述第一分析模块，还用于：获取包括故障日志以及基础信息的故障数据；将所述故障数据与对应所述故障的代办工单进行绑定处理，并向所述运维节点发送携带所述故障数据的代办工单。

在上述方案中，当所述故障数据包括对应所述故障日志的日志链接以及所述基础信息的信息链接时，所述第一分析模块，用于：向所述运维节点发送携带所述日志链接以及所述信息链接的代办工单，以使所述运维节点执行以下处理：响应于针对所述日志链接以及所述信息链接的数据获取操作，获取所述日志链接对应的故障日志以及所述信息链接对应的基础信息，以呈现所述故障日志以及所述基础信息；其中，所述故障日志以及所述基础信息用于进行所述第一故障分析处理；基于所述故障日志以及所述基础信息进行第一故障分析处理，得到第一故障分析结果。

在上述方案中，所述第一分析模块，还用于：调用第一神经网络模型，执行以下处理：基于所述故障日志以及所述基础信息进行第一故障分析处理，得到所述第一故障分析结果；其中，所述第一神经网络模型的训练样本包括故障样本的故障日志样本以及基础信息样本，所述训练样本的标注数据包括所述故障样本的预标记第一故障分析结果。

在上述方案中，所述第二分析模块，还用于：当满足以下条件至少之一时，向所述服务器供应方节点发送携带所述故障数据的所述代办工单：所述第一故障分析结果表征故障原因不明；所述第一故障分析结果表征故障原因，且所述第一故障分析结果满足复核条件。

在上述方案中，所述第二分析模块，还用于：当所述第一故障分析结果表征故障原因，且所述第一故障分析结果不需要复核时，根据所述第一故障分析结果所表征的故障类型，执行对应所述类型的故障处理流程。

在上述方案中，所述复核条件包括以下条件至少之一：所述故障的历史频次小于频次阈值；所述第一故障分析结果表征所述故障的重要程度大于重要程度阈值；所述第一故障分析结果表征故障原因的置信度小于置信度阈值；所述运维节点的故障分析准确率小于分析准确率阈值。

在上述方案中，所述业务系统中的服务器是由不同的供应方提供的；所述第二分析模块，还用于：获取所述发生故障的服务器的供应方标识；基于所述供应方标识确定提供所述故障的服务器的供应方，向所述供应方的服务器供应方节点发送携带所述故障数据的所述代办工单。

在上述方案中，所述向所述供应方的服务器供应方节点发送携带所述故障数据的所述代办工单之前，所述第二分析模块，还用于：当所述供应方的服务器供应方节点的数目为多个时，执行以下操作中任意一种：基于所述供应方的每个服务器供应方节点的代办工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点；基于所述供应方的每个服务器供应方节点的历史工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点。

在上述方案中，所述第二分析模块，还用于：针对所述供应方的每个服务器供应方节点执行以下处理：获取所述服务器供应方节点的已分配代办工单；对所述服务器供应方节点的每个所述已分配代办工单进行完成时间预测处理，得到每个所述已分配代办工单的预测完成时间；将多个所述已分配代办工单的预测完成时间进行累加处理，得到所述服务器供应方节点的累计完成时间；将具有最小累计完成时间的服务器供应方节点，确定为用于接收所述代办工单的服务器供应方节点。

在上述方案中，所述第二分析模块，还用于：针对所述供应方的每个服务器供应方节点执行以下处理：获取所述服务器供应方节点的历史工单以及对应的表现特征；将所述服务器供应方节点的每个所述历史工单的表现特征进行融合处理，得到所述服务器供应方节点的综合表现特征；确定所述服务器供应方节点的综合表现特征与所述代办工单的表现特征的相似度；将具有最大相似度的服务器供应方节点，确定为用于接收所述代办工单的服务器供应方节点。

在上述方案中，所述审核模块，还用于：根据所述第二故障分析结果所表征的故障类型，执行对应所述故障类型的故障处理流程。

在上述方案中，所述第二分析模块，还用于：确定对应所述第一故障分析结果对应的所述代办工单的紧急程度；查询对应所述紧急程度的发送方式；按照所述发送方式向所述服务器供应方节点发送携带所述故障数据的所述代办工单。

在上述方案中，所述根据所述运维节点针对所述第二故障分析结果的反馈结果执行故障处理流程之前，所述审核模块，还用于：接收所述运维节点发送的针对所述第二故障分析结果的反馈结果；其中，所述反馈结果是所述运维节点执行以下处理中任意一种得到的：响应于针对所述第二故障分析结果的反馈操作，获取所述反馈操作提交的针对所述第二故障分析结果的反馈结果；调用第二神经网络模型对所述第二故障分析结果进行反馈结果预测处理，得到针对所述第二故障分析结果的反馈结果；其中，所述第二神经网络模型的训练样本包括故障样本，所述训练样本的标注数据包括所述故障样本的预标记第二故障分析结果。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于被处理器执行时，实现本申请实施例提供的故障处理方法。

本申请实施例具有以下有益效果：

通过运维节点以及服务器供应方节点之间进行流转协同处理，从而整合了从故障检测到分析以及处理的全流程，实现了业务系统的故障的自动化处理；通过双重故障分析保证了故障分析的可靠性，并且由于故障时分配到多个节点进行处理的，因此可以节约每个节点的工作量，从而提高故障处理的效率。

附图说明

图1是本申请实施例提供的业务系统的故障处理方法的流程示意图；

图2是本申请实施例提供的故障处理系统的架构示意图；

图3是本申请实施例提供的电子设备的结构示意图；

图4A-4D是本申请实施例提供的业务系统的故障处理方法的流程示意图；

图5是本申请实施例提供的故障处理系统的整体架构图；

图6是本申请实施例提供的故障处理方法的数据拉取示意图；

图7是本申请实施例提供的故障处理方法的实时日志获取页面示意图；

图8是本申请实施例提供的故障处理方法的实时日志获取页面示意图；

图9是本申请实施例提供的故障处理方法的带外历史日志获取页面示意图；

图10是本申请实施例提供的故障处理方法的带内历史日志获取页面示意图；

图11是本申请实施例提供的故障处理方法的基础信息拉取示意图；

图12是本申请实施例提供的故障处理方法的附件上传示意图；

图13是本申请实施例提供的故障处理方法的邮件通知示意图；

图14是本申请实施例提供的故障处理方法的供应方节点界面示意图；

图15是本申请实施例提供的故障处理方法的编辑界面图；

图16是本申请实施例提供的故障处理方法的故障解决示意图；

图17是本申请实施例提供的故障处理方法的界面示意图；

图18是本申请实施例提供的故障处理方法的已处理工单页面示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)带内日志：带内日志指服务器操作系统的日志，带内日志包括但不限于dmesg日志、mcelog日志、smart日志以及crash等日志。

2)带外日志：带外日志指的是带外管理的日志，包括SEL日志、SDR日志、寄存器值以及厂商的带外一键日志等等。

3)节点：节点指的是各种角色用户所使用的电子设备，例如运维方所使用的电子设备，包括所使用的终端或者服务器等等。

相关技术中，在业务系统运行发生故障时，会生成故障对应的告警信息，使得业务系统的运维人员所使用的电子设备收到对应故障告警，并通过线下的方式针对所告警的故障进行一一处理，由于故障原因存在不明确的情形，因此上述过程需要耗费较长的处理时间以及较大的人力成本，降低了故障的处理效率，影响了业务系统的稳定运行。

申请人在实施本申请实施例时发现故障处理的流程如果通过多方交互进行，可以提高处理效率以及处理可靠性，多方交互指的是运维方、业务方以及服务器供应方之间的交互，参见图1，图1是本申请实施例提供的业务系统的故障处理方法的流程示意图，当业务系统的服务器发生不明确故障后，产生对应的不明确告警，创建不明确工单到业务节点进行初步判断(不明确故障初步分析)，通过日志判断是否存在硬件问题，如果判断是与硬件相关的硬件问题，将硬件问题发送至运维节点，运维节点会采集服务器的日志进行硬件故障初步分析，如果能明确硬件问题的落点则直接反馈分析结果至业务节点，以使业务节点进行硬件故障建单，如果无法确认故障原因则会将日志汇总以及问题反馈给供应方节点进行疑难问题分析和优化，供应方节点分析后将相应的处理方案(结果反馈)返回至运维节点，运维节点对处理方案进行复核，如果确认复核通过则将处理方案(结果反馈)反馈给业务节点，业务节点收到处理方案后进行相应的故障处理，如果供应方节点确认是硬件问题则创建相应的维护工单(即进行硬件故障建单)进行故障部件的替换，通过上述交互过程可以有效提高故障的处理效率，并保证业务系统的稳定运行。

在一些实施例中，运维节点可以具体为运维方终端，业务节点可以具体为业务方终端，供应方节点可以具体为供应方终端，发生不明确告警的服务器为业务服务器。

本申请实施例提供一种业务系统的故障处理方法、装置、电子设备和计算机可读存储介质，能够提高故障的处理效率，以保证业务系统的正常运行，下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为服务器。下面，将说明电子设备实施为线上诊断分析系统中的诊断分析服务器时的示例性应用。

参见图2，图2是本申请实施例提供的故障处理系统的架构示意图，终端通过网络连接服务器，网络可以是广域网或者局域网，又或者是二者的组合，故障处理系统包括业务系统10、监控系统20、线上诊断分析系统30、业务方终端400-1、运维方终端400-2以及服务器供应方终端400-3，业务系统中包括至少一个业务服务器200-1，监控系统20中包括至少一个监控服务器200-2，线上诊断分析系统30中包括至少一个诊断分析服务器200-3，业务系统中任一个业务服务器或特定的业务服务器会进行故障感知，线上诊断分析系统30可以以云服务的形式提供服务。

在一些实施例中，业务服务器200-1或者监控服务器200-2感知到某个服务器发生了故障之后，向诊断分析服务器200-3报告故障，以创建代办工单；诊断分析服务器200-3获取故障数据，将故障数据以及代办工单发送至运维方终端400-2，以使运维方终端400-2进行第一次分析来确定故障部件；响应于运维方终端400-2确定了故障部件，诊断分析服务器200-3创建对应的故障部件替换工单，并发送至业务方终端400-1以执行部件替换流程，响应于运维方终端400-2未确定故障部件，通过诊断分析服务器200-3将故障数据连同代办工单发送到服务器供应方终端400-3，以使服务器供应方终端400-3进行第二次分析，若服务器供应方400-3确定针对代办工单的解决方案，则服务器供应方400-3将解决方案返回至运维方终端400-2，以使运维方终端400-2对解决方案进行审核，通过后发送到业务方终端400-1执行该解决方案，若服务器供应方400-3确定故障部件，则将针对故障部件的解决方案返回至运维方终端400-2，以使运维方终端400-2对解决方案进行审核，审核通过后诊断分析服务器200-3创建故障部件替换工单，并发送至业务方终端400-1以执行部件替换流程。

在一些实施例中，业务服务器200-1、监控服务器200-2、诊断分析服务器200-3可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本发明实施例中不做限制。

参见图3，图3是本申请实施例提供的电子设备的结构示意图，图3所示的诊断分析服务器200-3包括：至少一个处理器210、存储器250、至少一个网络接口220。服务器200中的各个组件通过总线系统220耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统240。

处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

存储器250可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器210的一个或多个存储设备。

存储器250包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器250旨在包括任意适合类型的存储器。

在一些实施例中，存储器250能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统251，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块252，用于经由一个或多个(有线或无线)网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

在一些实施例中，本申请实施例提供的业务系统的故障处理装置可以采用软件方式实现，图3示出了存储在存储器250中的业务系统的故障处理装置255，其可以是程序和插件等形式的软件，包括以下软件模块：第一分析模块2551、第二分析模块2552、审核模块2553以及第三分析模块2554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分，将在下文中说明各个模块的功能。

将结合本申请实施例提供的服务器的示例性应用和实施，说明本申请实施例提供的业务系统的故障处理方法。

参见图4A，图4A是本申请实施例提供的业务系统的故障处理方法的流程示意图，将结合图4A示出的步骤进行说明，步骤101-103的执行主体为图2的诊断分析服务器200-3。

在步骤101中，监控业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果。

在步骤102中，根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点根据故障数据进行第二故障分析处理，得到第二故障分析结果。

在步骤103中，向运维节点发送第二故障分析结果，根据运维节点针对第二故障分析结果的反馈结果，执行故障处理流程。

下面对本申请实施例提供的业务系统的故障处理方法进行详细说明，参见图4B，图4B是本申请实施例提供的业务系统的故障处理方法的流程示意图，将结合图4B示出的步骤进行说明。

在步骤201中，诊断分析服务器监控业务系统中发生故障的服务器。

作为示例，业务系统可以是由多台服务器构成的服务器集群，服务器集群的规模不限，例如，某个互联网公司的所有服务器构成的服务器集群，某大学的所有服务器构成的服务器集群，为某个产品提供服务的服务器集群。诊断分析服务器监控业务系统中发生故障的服务器的过程可以通过业务系统本身或者监控系统实现。

在一些实施例中，步骤201中监控业务系统中发生故障的服务器，可以通过以下技术方案实现：通过故障监控接口接收业务系统发送的故障申报请求，故障申报请求是业务系统进行业务感知处理并确定发生故障的服务器时生成的；或者，接收监控系统发送的故障申报请求，故障申报请求是监控系统对对业务系统进行监控处理并确定发生故障的服务器时生成的；响应于故障申报请求，获取故障申报请求中携带的申报信息；其中，申报信息的字段包括以下至少之一：服务器的标识、故障现象、紧急程度。

作为示例，通过诊断分析服务器的故障监控接口接收业务系统发送的故障申报请求，故障监控接口由业务系统进行调用，故障申报请求是业务系统进行业务感知处理并确定发生故障的服务器时生成的，业务感知处理包括功能测试以及速度测试等测试处理，通过诊断分析服务器的故障监控接口接收监控系统发送的故障申报请求，故障监控接口由监控系统进行调用，故障申报请求是监控系统对对业务系统进行监控处理并确定发生故障的服务器时生成的，监控系统是由第三方独立于业务系统的服务器构成的，响应于故障申报请求，获取故障申报请求中携带的申报信息；其中，申报信息的字段包括以下至少之一：服务器的标识、故障现象、紧急程度，申报信息的字段是故障监控接口的调用协议规定的。

作为示例，故障监控接口的协议中规范了多个字段，从而可以提高后续的分析效率，故障监控接口需要提供的字段如下：1、机器固资或者网络协议地址信息，用于确定唯一的服务器并供获取对应的日志和基本信息；2、故障现象，用于确定故障分析的范围和方向，以避免不必要的资源浪费；3、业务节点初步分析结果，用于提供业务层面的分析结果，以供运维节点和供应方节点参考(该字段是可选字段)；4、代办工单的紧急程度：用于决定代办工单的处理方式，将代办工单传递至供应方节点进行处理的时效、以及通知方式。

在步骤202中，诊断分析服务器向运维节点发送携带故障数据的代办工单。

在一些实施例中，步骤202中向运维节点发送携带故障数据的代办工单，可以通过以下技术方案实现：获取包括故障日志以及基础信息的故障数据；将故障数据与对应故障的代办工单进行绑定处理，并向运维节点发送携带故障数据的代办工单。

作为示例，故障数据可以包括故障日志(原始数据的形式)以及基础信息(原始数据的形式)，还可以包括故障日志以及基础信息的链接，通常基础信息的数据量较小，因此故障数据可以包括故障日志的链接以及基础信息(原始数据的形式)。

在步骤203中，响应代办工单，运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果。

在一些实施例中，当故障数据包括对应故障日志的日志链接以及基础信息的信息链接时，向运维节点发送携带故障数据的代办工单，以使(响应代办工单)运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果，可以通过以下技术方案实现：向运维节点发送携带日志链接以及信息链接的代办工单，以使运维节点执行以下处理：响应于针对日志链接以及信息链接的数据获取操作，获取日志链接对应的故障日志以及信息链接对应的基础信息，以呈现故障日志以及基础信息；其中，故障日志以及基础信息用于进行第一故障分析处理；基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果。

作为示例，向运维节点发送携带日志的日志链接以及基础信息的信息链接的代办工单，以使运维节点执行以下处理：响应于针对日志链接的数据获取操作，获取日志链接对应的故障日志，当故障日志属于历史日志时，数据获取操作是针对下载控件的触发操作，历史日志是异常发生时自动被采集的日志，被存在诊断分析服务器的某个目录下，响应于针对链接的下载控件的触发操作，从诊断分析服务器获取链接对应的故障日志到本地，当故障日志属于实时日志时，数据获取操作是针对采集控件的触发操作，实时日志是响应于该触发操作才被发送至诊断分析服务器的某个目录下的日志，响应于针对下载控件的触发操作，从诊断分析服务器获取链接对应的故障日志到本地，以进行呈现。呈现故障日志以及基础信息的步骤中，在获取链接对应的故障日志之前即可以呈现基础信息，或者在获取故障日志之后再呈现基础信息，呈现时可以是分页呈现也可以在同一个页面中呈现，针对基础信息的信息链接，则参考针对日志的日志链接的操作执行上述技术方案以进行呈现。

在一些实施例中，当故障数据包括故障日志(原始数据)以及基础信息(原始数据)时；向运维节点发送携带故障日志的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果，可以通过以下技术方案实现：向运维节点发送携带故障日志以及基础信息的代办工单，以使运维节点执行以下处理：呈现故障日志以及基础信息；其中，故障日志以及基础信息用于进行第一故障分析处理；进行第一故障分析处理，得到第一故障分析结果。

作为示例，由于代办工单中直接承载有故障日志以及基础信息，因此，在呈现代办工单时可以直接呈现故障日志以及基础信息。

作为示例，若故障日志的原始数据的数据量超过第一数据量阈值则将故障日志的链接承载在代办工单上进行流转，否则以原始数据的形式承载在代办工单上进行流转，若基础信息的原始数据的数据量超过第二数据量阈值则将基础信息的链接承载在代办工单上进行流转，否则以原始数据的形式承载在代办工单上进行流转。

在一些实施例中，响应于针对链接的数据获取操作之前，通过运维节点对发起数据获取操作的用户进行身份验证；当身份验证通过后，确定继续响应针对链接的数据获取操作。为了增加数据的保密性，在获取各种数据之前需要进行身份验证，在身份验证通过后才能执行获取数据的操作。

在一些实施例中，上述基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果，可以通过以下技术方案实现：调用第一神经网络模型，执行以下处理：基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果；其中，第一神经网络模型的训练样本包括故障样本的故障日志样本以及基础信息样本，训练样本的标注数据包括故障样本的预标记第一故障分析结果。

作为示例，获取训练样本，训练样本包括故障样本的故障日志样本以及基础信息样本，训练样本的标注数据包括故障样本的预标记第一故障分析结果，基于训练样本对第一神经网络模型进行训练，调用经过训练的第一神经网络模型基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果，第一故障分析结果包括对于故障类型的判断，例如故障是否与硬件相关等等，通过第一神经网络模型的方式获取第一故障分析结果的方式有利于提高故障判断的效率。

在一些实施例中，响应于针对故障的分析结果输入操作，从输入操作中提取第一故障分析结果。

作为示例，输入操作的发起者是运维节点的使用者，例如运维方用户，输入操作可以为针对第一故障分析结果的编辑操作，也可以是针对第一故障分析结果的语音输入操作，接收到输入操作后，从输入操作中提取出第一故障分析结果，通过输入操作获取第一故障分析结果的方式，有利于提高故障判断的准确度。

作为示例，通过输入操作获取第一故障分析结果的方式和通过第一神经网络模型的方式获取第一故障分析结果的方式可以是并列的，即执行这两种方式中的至少一种即可，或者串行执行这两种方式，若通过输入操作获取的第一故障分析结果未表征故障原因，则使第一神经网络模型进行分析；首先通过第一神经网络模型的方式获取第一故障分析结果，再通过输入操作获取针对第一故障分析结果的确认结果或修改结果，以更新第一神经网络模型得到的第一故障分析结果。

在步骤204中，运维节点将第一故障分析结果返回至诊断分析服务器。

作为示例，运维节点将第一故障分析结果返回至诊断分析服务器，步骤205可以是通过运维节点向诊断分析服务器主动发送第一故障分析结果，或者是响应于诊断分析服务器的轮询请求向诊断分析服务器发送第一故障分析结果。

在步骤205中，诊断分析服务器根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单。

在一些实施例中，参见图4C，图4C是本申请实施例提供的业务系统的故障处理方法，步骤205中根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单，可以通过步骤2051实现。

在步骤2051中，当满足以下条件至少之一时，向服务器供应方节点发送携带故障数据的代办工单：第一故障分析结果表征故障原因不明；第一故障分析结果表征故障原因，且第一故障分析结果满足复核条件。

作为示例，复核条件包括以下条件至少之一：故障的历史频次小于频次阈值，例如，该故障仅出现了一次，则说明该故障不属于常见故障，因此需要通过供应方节点进行复核，以保证故障处理的可靠性；第一故障分析结果表征故障的重要程度，例如，故障的危害程度大于危害度阈值，例如，该故障会引起较大范围内的影响，则也需要通过供应方节点进行复核，以保证故障处理的可靠性；第一故障分析结果表征故障原因的置信度小于置信度阈值，例如，通过第一神经网络模型得到的故障原因所对应的预测概率(置信度)小于置信度阈值，则有必要通过供应方节点进行复核，以保证故障处理的可靠性；运维节点的故障分析准确率小于分析准确率阈值，例如，该运维节点历史作业数据表征进行故障分析的准确率小于分析准确率阈值，则需要通过供应方节点进行复核，以保证故障处理的可靠性。

作为示例，第一故障分析结果表征故障原因不明时，例如，第一故障分析结果得出故障原因，第一故障分析结果表征故障但是第一故障分析结果满足符合条件，表征虽然第一故障分析结果已得出故障原因，但是为了提升故障处理的可靠性仍然需要进行复核。

在一些实施例中，当第一故障分析结果表征故障原因，且第一故障分析结果不需要复核时，根据第一故障分析结果所表征的故障类型，执行对应类型的故障处理流程。

作为示例，当第一故障分析结果已经具有明确的故障原因，例如，第一故障分析结果表征服务器的某个槽位发生故障需要替换，则执行对应的故障处理流程，例如，当第一故障分析结果为针对硬件的维修方案，调用故障处理接口以使硬件维护节点(或者业务节点)创建对应硬件，且携带维修方案的维修工单，以根据维修工单执行对应维修方案的故障处理流程；当第一故障分析结果为与硬件无关的维修方案以及故障原因，将该维修方案以及故障原因发送至业务节点，以使业务节点执行对应维修方案的故障处理流程。

在一些实施例中，参见图4D，图4D是本申请实施例提供的业务系统的故障处理方法，步骤205中向服务器供应方节点发送携带故障数据的代办工单，可以通过以下步骤2052-2053实现。

在步骤2052中，获取发生故障的服务器的供应方标识。

在步骤2053中，基于供应方标识确定提供故障的服务器的供应方，向供应方的服务器供应方节点发送携带故障数据的代办工单。

作为示例，业务系统中的服务器是由不同的供应方提供的，例如，业务系统中的服务器是由供应方A和供应方B提供的，每个供应方具有独特且唯一的供应方标识，例如，诊断分析服务器在向服务器供应方节点发送携带故障数据的代办工单时，需要先确定接收代办工单的供应方节点，若发生故障的服务器是供应方A提供的，则向供应方A的服务器供应方节点发送携带故障数据的代办工单。

在一些实施例中，步骤2053向供应方的服务器供应方节点发送携带故障数据的代办工单之前，当供应方的服务器供应方节点的数目为多个时，执行以下操作中任意一种：基于供应方的每个服务器供应方节点的代办工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点；基于供应方的每个服务器供应方节点的历史工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点。

作为示例，例如供应方A的服务器供应方节点的数目为3个，则需要执行上述技术方案以从供应方A的3个服务器供应方节点中确定出1个服务器供应方节点作为接收代办工单的供应方节点。

在一些实施例中，上述基于供应方的每个服务器供应方节点的代办工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点，可以通过以下技术方案实现：针对供应方的每个服务器供应方节点执行以下处理：获取服务器供应方节点的已分配代办工单；对服务器供应方节点的每个已分配代办工单进行完成时间预测处理，得到每个已分配代办工单的预测完成时间；将多个已分配代办工单的预测完成时间进行累加处理，得到服务器供应方节点的累计完成时间；将具有最小累计完成时间的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点。

作为示例，获取服务器供应方节点a的已分配代办工单；将服务器供应方节点a的每个已分配代办工单进行完成时间预测处理，得到每个已分配代办工单的预测完成时间，例如，服务器供应方节点a当前具有4个已分配代办工单需要完成，预测每个已分配代办工单的完成时间，得到预测完成时间，完成时间的过程是基于已分配代办工单的难度或者已分配代办工单的历史完成时间进行预测的，将多个已分配代办工单的预测完成时间进行累加处理，得到服务器供应方节点的累计完成时间，相当于预测出服务器供应方节a完成当前已分配工单所需要耗费的时间，按照上述步骤确定另外两个服务器供应方节点完成当前已分配工单所需要耗费的时间，将这3个服务器供应方节点中具有最小累计完成时间的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点，从而加快代办工单的处理速度。

在一些实施例中，上述基于供应方的每个服务器供应方节点的历史工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点，可以通过以下技术方案实现：针对供应方的每个服务器供应方节点执行以下处理：获取服务器供应方节点的历史工单以及对应的表现特征；将服务器供应方节点的每个历史工单的表现特征进行融合处理，得到服务器供应方节点的综合表现特征；确定服务器供应方节点的综合表现特征与代办工单的表现特征的相似度；将具有最大相似度的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点。

作为示例，获取服务器供应方节点a的历史工单以及对应的表现特征，例如，服务器供应方节点a具有3个历史工单，每个历史工单具有对应的表现特征，将这3个历史工单对应的3个表现特征进行融合处理，得到服务器供应方节点a的综合表现特征，确定服务器供应方节点a的综合表现特征与待分配的代办工单的表现特征的相似度，按照上述步骤确定另外两个服务器供应方节点的综合表现特征，将这3个服务器供应方节点中具有最大相似度的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点，例如，某个服务器供应方节点经常处理具有某个故障表现的代办工单，则倾向于通过该服务器供应方节点处理具有类似故障表现的代办工单，从而提高代办工单的分配合理性，进而提高代办工单的处理效率。

在一些实施例中，向服务器供应方节点发送携带故障数据的代办工单之后，从将代办工单发送至服务器供应方节点之后开始计时；当计时时间超过代办工单的处理时限时，向服务器供应方节点发送针对代办工单的催办信息。

在一些实施例中，还可以在向运维节点发送携带故障数据的代办工单之后，从将代办工单发送至运维节点之后开始计时，当计时时间超过代办工单的处理时限时，向运维节点发送针对代办工单的催办信息。

作为示例，由于每个代办工单具有各自对应的紧急程度，因此需要设置有针对代办工单的处理时限，从将代办工单发送至服务器供应方节点/运维节点之后开始计时，当计时时间超过代办工单的处理时限时，向服务器供应方节点/运维节点发送针对代办工单的催办信息，以提高代办工单的处理效率。

在一些实施例中，步骤205中根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单，可以通过以下技术方案实现：确定对应第一故障分析结果对应的代办工单的紧急程度；查询对应紧急程度的发送方式；按照发送方式向服务器供应方节点发送携带故障数据的代办工单。

作为示例，故障的紧急程度为普通级别，则通过邮件的方式通知供应方节点查看代办工单，如果故障的紧急程度为加急级别，则通过电话的方式通知供应方节点查看代办工单，并且供应方节点的对应诊断分析服务器的图形界面上会出现相应的代办工单。

在步骤206中，响应代办工单，服务器供应方节点根据故障数据进行第二故障分析处理，得到第二故障分析结果。

作为示例，步骤206的实施方式可以参考步骤203的实施方式，区别仅在于执行主体由运维节点改为了服务器供应方节点。

在步骤207中，服务器供应方节点将第二故障分析结果返回至诊断分析服务器。

作为示例，步骤207的实施方式可以参考步骤204的实施方式，区别仅在于执行主体由运维节点改为了服务器供应方节点。

在步骤208中，诊断分析服务器向运维节点发送第二故障分析结果。

作为示例，诊断分析服务器向运维节点发送第二故障分析结果时，可以仅发送第二故障分析结果，以将第二故障分析结果更新至运维节点在步骤202中所接收的代办工单，或者直接向运维节点发送携带有第二故障分析结果的新代办工单以替换运维节点在步骤202中所接收的代办工单。

在步骤209中，运维节点确定针对第二故障分析结果的反馈结果。

作为示例，反馈结果是运维节点执行以下处理中任意一种得到的：响应于针对第二故障分析结果的反馈操作，获取反馈操作提交的针对第二故障分析结果的反馈结果；调用第二神经网络模型对第二故障分析结果进行反馈结果预测处理，得到针对第二故障分析结果的反馈结果；其中，第二神经网络模型的训练样本包括故障样本，训练样本的标注数据包括故障样本的预标记第二故障分析结果。

作为示例，获取训练样本，训练样本包括故障样本的故障日志样本以及基础信息样本，训练样本的标注数据包括故障样本的预标记第二故障分析结果，基于训练样本对第二神经网络模型进行训练，调用经过训练的第二神经网络模型对第二故障分析结果进行反馈结果预测处理，得到针对第二故障分析结果的反馈结果，反馈结果包括审核通过、审核不通过、具体理由等等。

作为示例，反馈操作的发起者是运维节点的使用者，例如运维方用户，反馈操作可以为针对反馈结果的编辑操作，也可以是针对反馈结果的语音操作，接收到反馈操作后，从反馈操作中提取出反馈结果，通过反馈操作获取反馈结果的方式，有利于提高故障判断的准确度。

作为示例，通过反馈操作获取反馈结果的方式和通过第二神经网络模型的方式获取反馈结果的方式可以是并列的，即执行这两种方式中的至少一种即可，或者串行执行这两种方式，例如，首先通过第二神经网络模型的方式获取反馈结果，再通过反馈操作获取针对反馈结果的确认结果或修改结果，以更新第二神经网络模型得到的反馈结果，或者根据预先配置来确定具体的获取反馈结果的方式。

在步骤210中，运维节点将反馈结果发送至诊断分析服务器。

作为示例，步骤210的实施方式可以参考步骤204的实施方式。

在步骤211中，诊断分析服务器根据运维节点针对第二故障分析结果的反馈结果，执行故障处理流程。

在一些实施例中，步骤211中根据运维节点针对第二故障分析结果的反馈结果执行故障处理流程，可以通过以下技术方案实现：根据第二故障分析结果所表征的故障类型，执行对应故障类型的故障处理流程。

作为示例，第二故障分析结果表征服务器的某个槽位发生故障需要替换，则执行对应的故障处理流程，例如，当第二故障分析结果为针对硬件的维修方案，调用故障处理接口以使硬件维护节点(或者业务节点)创建对应硬件，且携带维修方案的维修工单，以根据维修工单执行对应维修方案的故障处理流程；当第二故障分析结果为与硬件无关的维修方案以及故障原因，将该维修方案以及故障原因发送至业务节点，以使业务节点执行对应维修方案的故障处理流程。

在一些实施例中，代办工单的故障申报请求的来源是业务系统和监控系统中的任一个；步骤202以及步骤203中向运维节点发送携带故障数据的代办工单，响应代办工单，运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果，可以通过以下技术方案实现：当故障申报请求的来源是业务系统时，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果。当故障申报请求来源是监控系统时，向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点进行第三故障分析处理，得到第三故障分析结果；向运维节点发送第三故障分析结果，根据运维节点针对第三故障分析结果的反馈结果，执行故障处理流程。

作为示例，由于代办工单的故障申报请求具有两个来源，不同的来源可以表征不同的故障类型，例如，来源是业务系统(业务系统感知)和监控系统(监控)中的任一个；向运维节点发送携带故障数据的代办工单，响应代办工单，运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果，可以通过以下技术方案实现：当故障申报请求的来源是业务系统时，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果，并继续基于第一故障分析结果执行后续流程，然而当故障申报请求来源是监控系统时，表征故障申报请求所报告的故障仅与硬件相关，则向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点进行第三故障分析处理，得到第三故障分析结果，即不再向运维节点发送代办工单以进行第一故障分析，而是直接发代办工单至供应方节点进行第三故障分析，仅需要向运维节点发送第三故障分析结果，再根据运维节点针对第三故障分析结果的反馈结果，执行故障处理流程，通过上述实施方式，利用监控系统的监控特性，预先确定了故障的类型，从而简化了处理流程，提高了处理效率。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

在一些实施例中，本申请实施例提供的故障处理方法应用于大型社交应用软件的业务系统故障处理场景，参见图5，图5是本申请实施例提供的故障处理系统的整体架构图，线上诊断分析系统(诊断分析服务器)对外提供接口，为业务系统以及监控系统提供告警接入的途径，业务系统和监控系统(例如，硬件监控系统)调用接口以创建针对某个故障的代办工单，创建针对某个故障的代办工单后，线上诊断分析系统拉取与故障服务器相关的日志和基础信息，例如，带内外日志，机型，维修记录等信息，将拉取的信息汇总后连同代办工单发送至运维节点(服务器运维人员使用的电子设备)，以使运维节点对故障进行初步分析和判断，如果运维节点能直接明确故障部件，则线上诊断分析系统创建故障部件替换工单，并发送至业务节点以通过故障处理系统执行对应的故障部件替换流程，如果运维节点不能直接明确故障部件，仅能确认当前故障属于硬件相关的疑难问题，则运维节点将拉取的信息后连同代办工单通过线上诊断分析系统同步给服务器供应方节点(服务器研发人员使用)，并且运维节点通过邮件电话等方式进行相关通知，当服务器供应方节点确定出针对故障的与硬件无关的解决方案时，将该解决方案通过线上诊断分析系统同步至运维节点以进行审核，审核通过后，将解决方案返回至业务节点，以使业务节点实施解决方案，审核不通过则再次通知服务器供应方节点，以使服务器供应方节点针对故障进行再次分析，当服务器供应方节点确认属于硬件问题且需要维修，则服务器供应方节点提供包括故障部件的解决方案，将该解决方案通过线上诊断分析系统同步至运维节点以进行审核，审核通过后运维节点会直接通过接口的方式请求线上诊断分析系统创建相应的故障部件替换工单，并发送至业务节点以通过故障处理系统执行对应的故障部件替换流程。

在一些实施例中，使创建代办工单的故障监控接口的协议中规范了多个字段，从而可以提高后续的分析效率，故障监控接口需要提供的字段如下：1、机器固资或者网络协议地址信息，用于确定唯一的服务器并供获取对应的日志和基本信息；2、故障现象，用于确定分析的范围和方向，以避免不必要的资源浪费；3、业务节点初步分析结果：用于提供业务层面的分析结果，以供运维节点和供应方节点参考(该字段是可选字段)；4、工单的紧急程度：用于决定该工单的处理方式，传递至供应方节点进行处理的时效、以及通知方式。

在一些实施例中，参见图6，图6是本申请实施例提供的故障处理方法的数据拉取示意图，线上诊断分析系统进行服务器日志拉取时，拉取历史日志以及实时采集的日志，历史日志指在监控到服务器有异常时自动采集的数据，包括带内外的一键日志，采集完成后按照特定格式存放到相应的目录下，以供线上诊断分析系统拉取，实时采集的日志指使式的收集日志，接收到针对控件的触发操作后，调用日志采集逻辑实时采集一键日志、SDR日志、SEL日志、以及message日志等等，并且提供批量导出的功能。参见图7，图7是本申请实施例提供的故障处理方法的实时日志获取页面示意图，该实时日志获取页面603中呈现有不同类型的实时带内日志、实时带外一键日志、实时SDR日志以及实时SEL日志，每类日志均具有采集控件以及下载控件，针对采集控件601的触发操作，对相应日志进行采集，针对下载控件602的触发操作，将所采集的日志下载到本地，其中，批量下发采集控件604用于响应触发操作后，触发对多个日志进行采集，批量导出控件605用于响应触发操作后，触发对多个日志进行下载。参见图8，图8是本申请实施例提供的故障处理方法的实时日志获取页面示意图，该实时日志获取页面703中呈现有不同类型的实时带内日志、实时带外一键日志、实时SDR日志以及实时SEL日志，每类日志均具有采集控件以及下载控件，针对采集控件701的触发操作，对相应日志进行采集，针对下载控件702的触发操作，将所采集的日志下载到本地，其中，批量下发采集控件704用于响应触发操作后，触发对多个日志进行采集，批量导出控件705用于响应触发操作后，触发对多个日志进行下载，当采集成功时，在对应日志处呈现采集成功的提示信息。参见图9，图9是本申请实施例提供的故障处理方法的带外历史日志获取页面示意图，该带外历史日志获取页面803中呈现有多个带外历史日志，每个带外历史日志均具有下载控件(由于历史日志是在发生异常时自动采集，因此不需要再次发起采集的过程)，针对下载控件802的触发操作，将对应的带外历史日志下载到本地，带外历史日志获取页面803中还包括采集控件，用于防止历史采集不成功时进行再次采集，参见图10，图10是本申请实施例提供的故障处理方法的带内历史日志获取页面示意图，该带内历史日志获取页面903中呈现有带内历史日志，带内历史日志具有下载控件，针对下载控件902的触发操作，将对应的带内历史日志下载到本地，其中，针对带外日志切换控件901的触发操作，将切换至图9呈现的带外历史日志获取页面。

在一些实施例中，参见图11，图11是本申请实施例提供的故障处理方法的基础信息拉取示意图，服务器的基础信息包括维修记录，机型信息和配置信息，固件版本信息(FW)等等，运维节点和供应方节点可以通过维修记录查看该服务器所有的历史记录(包括故障次数、替换硬件以及处理建议)，以便对该次故障能有全面了解，机型配置信息指服务器相关的基础信息，硬件配置，机型版本号，机房信息等等，固件版本信息主要是指基本输入输出系统版本，业务管理(BMC)版本和硬盘版本。

在一些实施例中，参见图12，图12是本申请实施例提供的故障处理方法的附件上传示意图，针对属于老旧机型的服务器，业务管理不支持自动一键采集功能，需要人工通过带外网页页面进行下载，另外供应方节点的分析报告和不良分析报告也需要及时反馈给运维节点，因此在线上诊断分析系统上提供了附件上传功能，图12示出了附件管理页面1101，附件管理页面1101上显示了文件1102、附件选择控件1103以及上传附件控件1104，响应于针对附件选择控件1103的触发操作，执行文件选择流程，响应于针对上传附件控件1104的触发操作，执行文件上传流程。

在一些实施例中，如果是业务系统通过接口发送故障申报工单(请求)，线上诊断分析系统在收到故障申报工单后，会先给运维节点分派代办工单，运维节点则会通过日志和故障数据对故障的服务器进行初步分析，只有确定是跟硬件故障相关才会继续升级至供应方节点进行分析，如果运维节点确认是属于非硬件问题，则告知业务节点进行分析，如果是监控系统通过接口发送故障申报工单，则线上诊断分析系统直接给供应方节点派发代办工单，由于监控系统是根据硬件日志进行故障监控确的，因此只有确认与硬件相关才会通过监控系统发出故障申报工单。

在一些实施例中，参见图13，图13是本申请实施例提供的故障处理方法的邮件通知示意图，当运维节点确认故障属于疑难问题(即无法直接确认属于硬件问题或者不属于硬件问题)，在线诊断分析系统会创建相应的代办工单给到供应方节点进行进一步分析，故障的紧急程度为普通级别，则通过邮件的方式通知供应方节点，如果故障的紧急程度为加急级别，则通过电话的方式通知供应方节点，并在供应方节点的系统图形界面上会出现相应的代办工单，参见图14，图14是本申请实施例提供的故障处理方法的供应方节点界面示意图，图14显示了多个工单，并且仅显示了属于同一供应方的代办工单，这是因为不同供应方之间的数据展示是相互隔离的。

在一些实施例中，参见图15，图15是本申请实施例提供的故障处理方法的编辑界面图，供应方节点会根据故障现象和日志(故障数据)进行全面分析，当确定出解决方案后会在代办工单的编辑页面1401上进行编辑记录，编辑记录中包括故障是否明确，分析过程，故障分类等10个字段，供应方节点完成上述字段的编辑流程后，响应于针对提交控件1402的触发操作，通过在线诊断分析系统将解决方案回传给运维节点。

在一些实施例中，通过运维节点对解决方案进行分析合理性以及方案可操作性这两方面去衡量，在线分析诊断系统首次被应用在某个服务器集群时所遇到的问题比较多，随着运维节点与服务器供应方节点之间的长时间交互经验累积，上述针对解决方案的分析过程可以通过智能审核实现，根据故障数据(例如，机型配置、故障现象以及维修历史)，可以智能化判断解决方案的合理性。

在一些实施例中，参见图16，图16是本申请实施例提供的故障处理方法的故障解决示意图，如果供应方节点提供的解决方案被判断合理，并且需要对硬件进行维修，则在线分析诊断系统会自动对接故障处理流程，将需要替换的部件信息和槽位信息传递给到故障处理流程，按照正常的硬件故障处理流程处理，另外如果解决方案不需要替换硬件，则直接将解决方案(例如，升级版本或者压测处理)只需要反馈给业务节点进行处理。

在一些实施例中，参见图17，图17是本申请实施例提供的故障处理方法的界面示意图，故障处理方法所使用的系统是在线分析诊断系统，通常是供应方节点以及运维节点会登陆和使用该系统，图17示出了该系统的代办工单页面，运维节点可以看到所有供应方节点的代办工单，供应方节点之间信息是隔离的，代办工单所有字段均可以作为查询条件进行工单查询，代办工单中展示了工单的基础信息，工单的基础信息包括：服务器型号，版本，故障描述，业务方初步分析结果以及历史工单信息等等，代办工单中提供日志展示的入口，日志包括异常前后的历史日志和实时采集的日志，带外日志包括带外一键日志、SDR日志、SEL日志，带内日志包括message日志、dmesg日志、mcelog日志、以及crashdump日志。参见图18，图18是本申请实施例提供的故障处理方法的已处理工单页面示意图，图18示出了所有已处理的代办工单，图17中的代办工单在处理完成之后将从图17的页面转移至图18的页面进行显示。线上诊断分析系统能自动采集故障的服务器的带内外日志，拉取服务器的基础信息，并提供相应的页面进行展示和下载，通过邮件和电话等方式知会相应的负责人(运维节点和/供应方节点)进行处理和跟进，并对分析的结果进行智能化处理。

在一些实施例中，本申请实施例提供的故障处理方法具有以下优点：1、人力节省，该系统在内测阶段，在3个月内共处理了2080个代办工单，平均每天23单，可节省4.6个人力，并且随着服务器数目的增加，人力节省越多；2、效率提升，该系统内测之前，平均每个代办工单的处理需要5-7天，主要耗时体现在日志采集过程以及无序性的协同处理，该系统参与内测之后，各流程节点均有相应的处理时效，并且有邮件和电话通知，各系统自动对接，实现起单，日志抓取，工单提醒等节点的功能，提高自动化程度以减少人力投入，从而提高处理效率，工单处理的平均时间缩短到17小时；3、流程规范化，故障分析过程以及优化方案形成闭环，有助于对案例积累的过程进行明确化并优化故障上报能力，并且分析过程以及创建代办工单的记录均可查询，任何节点的处理结果和进度透明化，数据都在服务器保留，具有较强的可回溯性。

下面继续说明本申请实施例提供的业务系统的故障处理装置255的实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器250的业务系统的故障处理装置255中的软件模块可以包括第一分析模块2551，用于监控业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果；第二分析模块2552，用于根据第一故障分析结果，向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点根据故障数据进行第二故障分析处理，得到第二故障分析结果；审核模块2553，用于向运维节点发送第二故障分析结果，根据运维节点针对第二故障分析结果的反馈结果，执行故障处理流程。

在一些实施例中，第一分析模块2551，还用于：接收业务系统发送的故障申报请求，故障申报请求是业务系统进行业务感知处理并确定发生故障的服务器时生成的；或者，接收监控系统发送的故障申报请求，故障申报请求是监控系统对对业务系统进行监控处理并确定发生故障的服务器时生成的；响应于故障申报请求，获取故障申报请求中携带的申报信息；其中，申报信息的字段包括以下至少之一：服务器的标识、故障现象、紧急程度。

在一些实施例中，代办工单的故障申报请求的来源是业务系统和监控系统中的任一个；第一分析模块2551，还用于：当故障申报请求的来源是业务系统时，向运维节点发送携带故障数据的代办工单，以使运维节点根据故障数据进行第一故障分析处理，得到第一故障分析结果。

在一些实施例中，装置还包括第三分析模块2554，用于：当故障申报请求来源是监控系统时，向服务器供应方节点发送携带故障数据的代办工单，以使服务器供应方节点进行第三故障分析处理，得到第三故障分析结果；向运维节点发送第三故障分析结果，根据运维节点针对第三故障分析结果的反馈结果，执行故障处理流程。

在一些实施例中，第一分析模块2551，还用于：获取包括故障日志以及基础信息的故障数据；将故障数据与对应故障的代办工单进行绑定处理，并向运维节点发送携带故障数据的代办工单。

在一些实施例中，当故障数据包括对应故障日志的日志链接以及基础信息的信息链接时；第一分析模块2551，还用于：向运维节点发送携带日志链接以及信息链接的代办工单，以使运维节点执行以下处理：响应于针对日志链接以及信息链接的数据获取操作，获取日志链接对应的故障日志以及信息链接对应的基础信息，以呈现故障日志以及基础信息；其中，故障日志以及基础信息用于进行第一故障分析处理；基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果。

在一些实施例中，第一分析模块2551，还用于：调用第一神经网络模型，执行以下处理：基于故障日志以及基础信息进行第一故障分析处理，得到第一故障分析结果；其中，第一神经网络模型的训练样本包括故障样本的故障日志样本以及基础信息样本，训练样本的标注数据包括故障样本的预标记第一故障分析结果。

在一些实施例中，第二分析模块2552，还用于：当满足以下条件至少之一时，向服务器供应方节点发送携带故障数据的代办工单：第一故障分析结果表征故障原因不明；第一故障分析结果表征故障原因，且第一故障分析结果满足复核条件。

在一些实施例中，第二分析模块2552，还用于：当第一故障分析结果表征故障原因，且第一故障分析结果不需要复核时，根据第一故障分析结果所表征的故障类型，执行对应类型的故障处理流程。

在一些实施例中，复核条件包括以下条件至少之一：故障的历史频次小于频次阈值；第一故障分析结果表征故障的重要程度大于重要程度阈值；第一故障分析结果表征故障原因的置信度小于置信度阈值；运维节点的故障分析准确率小于分析准确率阈值。

在一些实施例中，业务系统中的服务器是由不同的供应方提供的；第二分析模块2552，还用于：获取发生故障的服务器的供应方标识；基于供应方标识确定提供故障的服务器的供应方，向供应方的服务器供应方节点发送携带故障数据的代办工单。

在一些实施例中，向供应方的服务器供应方节点发送携带故障数据的代办工单之前，第二分析模块2552，还用于：当供应方的服务器供应方节点的数目为多个时，执行以下操作中任意一种：基于供应方的每个服务器供应方节点的代办工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点；基于供应方的每个服务器供应方节点的历史工单，从多个供应方的服务器供应方节点中确定用于接收代办工单的服务器供应方节点。

在一些实施例中，第二分析模块2552，还用于：针对供应方的每个服务器供应方节点执行以下处理：获取服务器供应方节点的已分配代办工单；将服务器供应方节点的每个已分配代办工单进行完成时间预测处理，得到每个已分配代办工单的预测完成时间；将多个已分配代办工单的预测完成时间进行累加处理，得到服务器供应方节点的累计完成时间；将具有最小累计完成时间的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点。

在一些实施例中，第二分析模块2552，还用于：针对供应方的每个服务器供应方节点执行以下处理：获取服务器供应方节点的历史工单以及对应的表现特征；将服务器供应方节点的每个历史工单的表现特征进行融合处理，得到服务器供应方节点的综合表现特征；确定服务器供应方节点的综合表现特征与代办工单的表现特征的相似度；将具有最大相似度的服务器供应方节点，确定为用于接收代办工单的服务器供应方节点。

在一些实施例中，审核模块2553，还用于：根据第二故障分析结果所表征的故障类型，执行对应故障类型的故障处理流程。

在一些实施例中，第二分析模块2552，还用于：确定对应第一故障分析结果对应的代办工单的紧急程度；查询对应紧急程度的发送方式；按照发送方式向服务器供应方节点发送携带故障数据的代办工单。

在一些实施例中，根据运维节点针对第二故障分析结果的反馈结果执行故障处理流程之前，审核模块2553，还用于：接收运维节点发送的针对第二故障分析结果的反馈结果；其中，反馈结果是运维节点执行以下处理中任意一种得到的：响应于针对第二故障分析结果的反馈操作，获取反馈操作提交的针对第二故障分析结果的反馈结果；调用第二神经网络模型对第二故障分析结果进行反馈结果预测处理，得到针对第二故障分析结果的反馈结果；其中，第二神经网络模型的训练样本包括故障样本，训练样本的标注数据包括故障样本的预标记第二故障分析结果。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备(例如，计算机设备)的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的业务系统的故障处理方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的业务系统的故障处理方法，例如，如图4A-4D示出的业务系统的故障处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EP ROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，通过本申请实施例将服务器的故障在运维节点以及服务器供应方节点之间进行流转协同处理，由于故障是通过多重故障分析进行处理得到的，因此可以提高故障处理的可靠性，由于故障时分摊到多个节点进行处理的，因此可以降低每个节点的工总量，从而提高故障处理的效率以及可靠性。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (15)

1.一种业务系统的故障处理方法，其特征在于，包括：

监控所述业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果；

根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，以使所述服务器供应方节点根据所述故障数据进行第二故障分析处理，得到第二故障分析结果；

向所述运维节点发送所述第二故障分析结果，根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程。

2.根据权利要求1所述的方法，其特征在于，所述代办工单的故障申报请求的来源是所述业务系统和监控系统中的任一个，

所述向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果，包括：

当所述故障申报请求的来源是所述业务系统时，向所述运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果；

所述方法还包括：

当所述故障申报请求来源是所述监控系统时，向所述服务器供应方节点发送携带所述故障数据的代办工单，以使所述服务器供应方节点进行第三故障分析处理，得到第三故障分析结果；

向所述运维节点发送所述第三故障分析结果，根据所述运维节点针对所述第三故障分析结果的反馈结果，执行故障处理流程。

3.根据权利要求1所述的方法，其特征在于，所述向运维节点发送携带故障数据的代办工单，包括：

获取包括故障日志以及基础信息的故障数据；

将所述故障数据与对应所述故障的代办工单进行绑定处理，并向所述运维节点发送携带所述故障数据的代办工单。

4.根据权利要求3所述的方法，其特征在于，当所述故障数据包括对应所述故障日志的日志链接以及所述基础信息的信息链接时，所述向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果，包括：

向所述运维节点发送携带所述日志链接以及所述信息链接的代办工单，以使所述运维节点执行以下处理：

响应于针对所述日志链接以及所述信息链接的数据获取操作，获取所述日志链接对应的故障日志以及所述信息链接对应的基础信息，以呈现所述故障日志以及所述基础信息；

其中，所述故障日志以及所述基础信息用于进行所述第一故障分析处理；

基于所述故障日志以及所述基础信息进行第一故障分析处理，得到第一故障分析结果。

5.根据权利要求1所述的方法，其特征在于，所述根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，包括：

当满足以下条件至少之一时，向所述服务器供应方节点发送携带所述故障数据的所述代办工单：

所述第一故障分析结果表征故障原因不明；

所述第一故障分析结果表征故障原因，且所述第一故障分析结果满足复核条件。

6.根据权利要求1所述的方法，其特征在于，

所述业务系统中的服务器是由不同的供应方提供的；

所述向服务器供应方节点发送携带所述故障数据的所述代办工单，包括：

获取所述发生故障的服务器的供应方标识；

基于所述供应方标识确定提供所述故障的服务器的供应方，向所述供应方的服务器供应方节点发送携带所述故障数据的所述代办工单。

7.根据权利要求6所述的方法，其特征在于，所述向所述供应方的服务器供应方节点发送携带所述故障数据的所述代办工单之前，所述方法还包括：

当所述供应方的服务器供应方节点的数目为多个时，执行以下操作中任意一种：

基于所述供应方的每个服务器供应方节点的代办工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点；

基于所述供应方的每个服务器供应方节点的历史工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点。

8.根据权利要求7所述的方法，其特征在于，所述基于所述供应方的每个服务器供应方节点的代办工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点，包括：

针对所述供应方的每个服务器供应方节点执行以下处理：

获取所述服务器供应方节点的已分配代办工单；

对所述服务器供应方节点的每个所述已分配代办工单进行完成时间预测处理，得到每个所述已分配代办工单的预测完成时间；

将多个所述已分配代办工单的预测完成时间进行累加处理，得到所述服务器供应方节点的累计完成时间；

将具有最小累计完成时间的服务器供应方节点，确定为用于接收所述代办工单的服务器供应方节点。

9.根据权利要求7所述的方法，其特征在于，所述基于所述供应方的每个服务器供应方节点的历史工单，从多个所述供应方的服务器供应方节点中确定用于接收所述代办工单的服务器供应方节点，包括：

针对所述供应方的每个服务器供应方节点执行以下处理：

获取所述服务器供应方节点的历史工单以及对应的表现特征；

将所述服务器供应方节点的每个所述历史工单的表现特征进行融合处理，得到所述服务器供应方节点的综合表现特征；

确定所述服务器供应方节点的综合表现特征与所述代办工单的表现特征的相似度；

将具有最大相似度的服务器供应方节点，确定为用于接收所述代办工单的服务器供应方节点。

10.根据权利要求1所述的方法，其特征在于，所述根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程，包括：

根据所述第二故障分析结果所表征的故障类型，执行对应所述故障类型的故障处理流程。

11.根据权利要求1所述的方法，其特征在于，所述根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，包括：

确定对应所述第一故障分析结果对应的所述代办工单的紧急程度；

查询对应所述紧急程度的发送方式；

按照所述发送方式向所述服务器供应方节点发送携带所述故障数据的所述代办工单。

12.根据权利要求1所述的方法，其特征在于，所述根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程之前，所述方法还包括：

接收所述运维节点发送的针对所述第二故障分析结果的反馈结果；

其中，所述反馈结果是所述运维节点执行以下处理中任意一种得到的：

响应于针对所述第二故障分析结果的反馈操作，获取所述反馈操作提交的针对所述第二故障分析结果的反馈结果；

调用第二神经网络模型对所述第二故障分析结果进行反馈结果预测处理，得到针对所述第二故障分析结果的反馈结果；

其中，所述第二神经网络模型的训练样本包括故障样本，所述训练样本的标注数据包括所述故障样本的预标记第二故障分析结果。

13.一种业务系统的故障处理装置，其特征在于，包括：

第一分析模块，用于监控所述业务系统中发生故障的服务器，向运维节点发送携带故障数据的代办工单，以使所述运维节点根据所述故障数据进行第一故障分析处理，得到第一故障分析结果；

第二分析模块，用于根据所述第一故障分析结果，向服务器供应方节点发送携带所述故障数据的所述代办工单，以使所述服务器供应方节点根据所述故障数据进行第二故障分析处理，得到第二故障分析结果；

审核模块，用于向所述运维节点发送所述第二故障分析结果，根据所述运维节点针对所述第二故障分析结果的反馈结果，执行故障处理流程。

14.一种电子设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至12任一项所述的业务系统的故障处理方法。

15.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至12任一项所述的业务系统的故障处理方法。

Images