CN118312339A - 一种故障处理系统、故障处理方法及相关设备 - Google Patents

Abstract

本申请提供了一种故障处理系统，包括目标设备以及诊断设备，该诊断设备包括操作系统(OS)、基板管理控制器(BMC)、待诊断部件；目标设备用于处理业务；诊断设备用于获取OS采集的待诊断部件的第一状态信息，或获取BMC采集的待诊断部件的第二状态信息，并利用诊断算法，根据第一状态信息或第二状态信息进行故障诊断，得到故障诊断结果，从而根据目标设备上的业务，确定待诊断部件对应的故障处理策略，并根据故障诊断结果以及故障处理策略，指示目标设备执行目标操作。如此，可以摆脱BMC的有限算力对于诊断算法的精度限制，提高故障诊断的准确性，降低故障部件对于目标设备处理业务的影响。此外，本申请还提供了对应的故障处理方法及相关设备。

Description

一种故障处理系统、故障处理方法及相关设备

技术领域

本申请涉及故障处理技术领域，尤其涉及一种故障处理系统、故障处理方法及相关设备。

背景技术

在设备运行过程中，该设备中的一个或者多个部件可能会发生故障，如该设备中的内存中的部分存储区域可能发生故障等，从而容易导致设备存储业务数据出错或者数据存储失败，影响该设备正常处理业务。因此，该设备通常会对内部的多个部件分别进行故障检测以及诊断，并基于诊断结果执行相应的故障修复、故障隔离等操作。

目前，当设备中的部件发生故障时，通常是由设备中的基板管理控制器(baseboard management controller，BMC)利用固定配置的诊断算法进行故障诊断，如诊断部件故障原因、部件中的故障位置等，并通知设备中的基本输入输出系统(basic inputoutput system，BIOS)在该部件中执行故障隔离操作。

但是，在BMC中固定配置的诊断算法，故障部件的诊断准确率较低，而且，BMC通知BIOS执行故障隔离操作，也会影响设备对于业务的处理，如造成业务卡顿或业务响应变慢等问题。

发明内容

有鉴于此，本申请实施例提供了一种故障处理系统，以提高针对设备中的故障部件的诊断准确率、降低故障的部件对于设备处理业务的影响。本申请还提供了对应的故障处理方法、诊断设备、计算设备集群、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供一种故障处理系统，其特征在于，该故障处理系统包括目标设备以及诊断设备，该诊断设备包括操作系统(OS)、基板管理控制器(BMC)以及待诊断部件，该待诊断部件例如可以是目标设备中的处理器、内存、存储器等部件；其中，目标设备用于处理业务，如图像识别任务、计算任务等；诊断设备用于获取OS采集的待诊断部件的第一状态信息，或获取BMC采集的待诊断部件的第二状态信息，或者同时获取该第一状态信息以及第二状态信息，并利用待诊断部件对应的诊断算法，根据第一状态信息或第二状态信息对待诊断部件进行故障诊断(包括同时根据第一状态信息以及第二状态信息进行故障诊断)，得到故障诊断结果，该故障诊断结果用于指示待诊断部件发生故障，具体可以指示在当前时刻或者未来时刻发生故障，从而根据目标设备上的业务，确定待诊断部件对应的故障处理策略，并根据故障诊断结果以及故障处理策略，指示目标设备针对待诊断部件执行目标操作，如软件隔离操作或者硬件隔离操作等。

由于诊断算法独立于目标设备进行部署，这使得能够选用算力要求较高但是算法精度更高的诊断算法对待诊断部件进行故障诊断，从而摆脱了目标设备中的BMC的有限算力对于诊断算法的精度限制，提高故障诊断的准确性，降低故障部件对于目标设备处理业务的影响。而且，诊断设备在确定待诊断部件发生故障后，并非直接指示目标设备对该部件执行故障修复、故障隔离等操作，而是先根据目标设备上的业务确定该待诊断部件对应的故障处理策略，如此，基于故障处理策略指示目标设备执行目标操作(如故障修复、故障隔离等)后，可以进一步降低执行目标操作对于目标设备处理业务的影响。

在一种可能的实施方式中，诊断设备，用于确定待诊断部件对应的AI模型，该AI模型基于待诊断部件对应的诊断算法完成构建，从而诊断设备利用该AI模型对第一状态信息或第二状态信息进行推理(包括同时对第一状态信息以及第二状态信息进行推理)。如此，诊断设备可以利用AI模型的推理能力实现对部件的故障诊断，有助于进一步提高故障诊断的准确率。

在一种可能的实施方式中，AI模型通过至少一组训练样本完成训练，训练样本包括待诊断部件在历史时间段内的历史状态信息、待诊断部件在历史时间段内的故障状态。如此，可以利用待诊断部件在过去一段时间内的历史经验数据，指导推理待诊断部件在当前或者未来时刻的故障情况，以此可以提高AI模型的推理准确性。

在一种可能的实施方式中，诊断设备用于当目标设备上业务的类型为第一类型(如时延敏感型业务)，或者目标设备上业务的状态为第一状态(如业务繁忙状态)时，确定待诊断部件对应的故障处理策略为第一故障处理策略，第一故障处理策略用于指示OS针对待诊断部件执行目标操作；当目标设备上业务的类型为第二类型(如该业务对于时延要求较低)，或者目标设备上业务的状态为第二状态(如业务为空闲状态)时，确定待诊断部件对应的故障处理策略为第二故障处理策略，第二故障处理策略用于指示BMC针对待诊断部件执行目标操作。如此，对于目标设备上不同类型或者而不同状态的业务，采用不同的故障处理策略对待诊断部件进行处理，以此可以进一步降低执行目标操作对于目标设备处理业务的影响。

在一种可能的实施方式中，待诊断部件包括用于存储数据的部件，用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

可选地，待诊断部件也可以是包括用于计算数据或者传输数据的部件，如处理器、网卡等。

在一种可能的实施方式中，诊断设备部署于云端，或者，诊断设备上还部署有网管软件。如此，可以通过将诊断设备部署于不同的位置，为一个或者多个目标设备提供故障诊断的云服务或者本地服务，从而满足不同应用场景下的需求。

第二方面，本申请提供一种故障处理方法，该方法应用于故障处理系统，故障处理系统包括目标设备以及诊断设备，诊断设备包括操作系统OS、基本输入输出系统BIOS以及待诊断部件，方法包括：诊断设备获取OS采集的待诊断部件的第一状态信息，或获取BMC采集的待诊断部件的第二状态信息；诊断设备利用待诊断部件对应的诊断算法，根据第一状态信息或第二状态信息对待诊断部件进行故障诊断，得到故障诊断结果，故障诊断结果用于指示待诊断部件发生故障；诊断设备根据目标设备上的业务，确定待诊断部件对应的故障处理策略；诊断设备根据故障诊断结果以及故障处理策略，指示目标设备针对待诊断部件执行目标操作。

在一种可能的实施方式中，诊断设备利用待诊断部件对应的诊断算法，根据第一状态信息或第二状态信息对待诊断部件进行故障诊断，包括：诊断设备确定待诊断部件对应的人工智能AI模型，AI模型基于待诊断部件对应的诊断算法完成构建；诊断设备利用AI模型对第一状态信息或第二状态信息进行推理。

在一种可能的实施方式中，AI模型通过至少一组训练样本完成训练，训练样本包括待诊断部件在历史时间段内的历史状态信息、待诊断部件在历史时间段内的故障状态。

在一种可能的实施方式中，诊断设备根据目标设备上的业务，确定待诊断部件对应的故障处理策略，包括：当目标设备上业务的类型为第一类型，或者目标设备上业务的状态为第一状态时，诊断设备确定待诊断部件对应的故障处理策略为第一故障处理策略，第一故障处理策略用于指示OS针对待诊断部件执行目标操作；当目标设备上业务的类型为第二类型，或者目标设备上业务的状态为第二状态时，诊断设备确定待诊断部件对应的故障处理策略为第二故障处理策略，第二故障处理策略用于指示BMC针对待诊断部件执行目标操作。

在一种可能的实施方式中，待诊断部件包括用于存储数据的部件，用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

在一种可能的实施方式中，诊断设备部署于云端，或者，诊断设备上还部署有网管软件。

值得注意的是，第二方面提供的故障处理方法，对应于第一方面提供的故障处理系统，故第二方面以及第二方面中任一实施方式所具有的技术效果，可参见第一方面或者第一方面的相应实施方式所具有的技术效果。

第三方面，本申请提供一种诊断设备，诊断设备包括：数据获取模块，用于获取目标设备中的操作系统OS采集的目标设备中待诊断部件的第一状态信息，或获取目标设备中的基板管理控制器BMC采集的待诊断部件的第二状态信息；故障诊断模块，用于利用待诊断部件对应的诊断算法，根据第一状态信息或第二状态信息对待诊断部件进行故障诊断，得到故障诊断结果，故障诊断结果用于指示待诊断部件发生故障；决策模块，用于根据目标设备上的业务，确定待诊断部件对应的故障处理策略；故障处理模块，用于根据故障诊断结果以及故障处理策略，指示目标设备针对待诊断部件执行目标操作。

在一种可能的实施方式中，故障诊断模块，用于：确定待诊断部件对应的人工智能AI模型，AI模型基于待诊断部件对应的诊断算法完成构建；利用AI模型对第一状态信息或第二状态信息进行推理。

在一种可能的实施方式中，AI模型通过至少一组训练样本完成训练，训练样本包括待诊断部件在历史时间段内的历史状态信息以及待诊断部件的故障状态。

在一种可能的实施方式中，决策模块，用于：当目标设备上业务的类型为第一类型，或者目标设备上业务的状态为第一状态时，诊断设备确定待诊断部件对应的故障处理策略为第一故障处理策略，第一故障处理策略用于指示OS针对待诊断部件执行目标操作；当目标设备上业务的类型为第二类型，或者目标设备上业务的状态为第二状态时，诊断设备确定待诊断部件对应的故障处理策略为第二故障处理策略，第二故障处理策略用于指示BMC针对待诊断部件执行目标操作。

在一种可能的实施方式中，待诊断部件包括用于存储数据的部件，用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

在一种可能的实施方式中，诊断设备部署于云端，或者，诊断设备上还部署有网管软件。

值得注意的是，第三方面提供的诊断设备，对应于第一方面提供的故障处理系统，故第三方面以及第三方面中任一实施方式所具有的技术效果，可参见第一方面或者第一方面的相应实施方式所具有的技术效果。

第四方面，本申请提供一种计算设备集群，所述计算设备包括至少一个计算设备，所述至少一个计算设备包括至少一个处理器和至少一个存储器；所述至少一个存储器用于存储指令，所述至少一个处理器执行所述至少一个存储器存储的该指令，以使所述计算设备集群执行上述第二方面或第二方面任一种可能实现方式中的故障处理方法。需要说明的是，该存储器可以集成于处理器中，也可以是独立于处理器之外。所述至少一个计算设备还可以包括总线。其中，处理器通过总线连接存储器。其中，存储器可以包括可读存储器以及随机存取存储器。

第五方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在至少一个计算设备上运行时，使得所述至少一个计算设备执行上述第二方面或第二方面任一种可能实现方式中的故障处理方法。

第六方面，本申请提供了一种包含指令的计算机程序产品，当其在至少一个计算设备上运行时，使得所述至少一个计算设备执行上述第二方面或第二方面任一种可能实现方式中的故障处理方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请提供的一示例性故障处理系统的结构示意图；

图2为本申请提供的一种故障处理方法的流程示意图；

图3为本申请提供的一示例性配置界面的示意图；

图4为本申请提供的一示例性交互界面的示意图；

图5为本申请提供的一种诊断设备的硬件结构示意图；

图6为本申请提供的一种计算设备集群的结构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请提供的实施例中的方案进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。

参见图1，为一种故障处理系统的结构示意图。如图1所示，故障处理系统10包括待诊断的目标设备100以及诊断设备200，并且，目标设备100与诊断设备200之间可以通过有线或者无线的方式建立通信连接。图1中是以故障处理系统10包括两个设备为例进行说明，实际应用时，故障处理系统10可以包括多个目标设备，或者可以包括多个诊断设备，对此不做限定。

其中，目标设备100中包括操作系统(operating system，OS)101、基板管理控制器(baseboard management controller，BMC)103、硬件(hardware)104，实际应用中，目标设备100还包括基本输入输出系统(basic input output system，BIOS)102等器件。并且，不同器件之间可以通过总线进行通信，如通过内部集成电路(inter-integrated circuit，I2C)总线、系统管理总线(system management bus，SMB)、串行外围接口(serialperipheral interface，SPI)总线、低引脚数(low pin count，LPC)总线、联合测试工作组(joint test action group，JTAG)总线、局部总线(local bus)中的一种或者多种，也可以是其它类型总线，本实施例对此并不进行限定。

其中，硬件104通常可以包括处理器(如CPU)、内存(memory)、硬盘等部件。若由目标设备100针对硬件104中的一个或者多个部件进行故障诊断，则通常会在BMC103中固定部署相应的诊断算法，并通过带内故障处理或者带外故障处理两种方式进行处理。

当采用带内故障处理方式时，在硬件104触发异常并上报到BMC103后，BMC103会利用固定配置的诊断算法进行故障诊断，并将故障诊断结果上报给OS101，以便由OS101确定部件存在故障后，执行相应的故障处理操作。

当采用带外故障处理方式时，在硬件104触发异常并上报到BMC103后，BMC103会利用固定配置的诊断算法进行故障诊断，并在确定故障存在故障后，BMC103直接通知BIOS102执行相应的故障处理操作。

但是，鉴于BMC103非常有限的数据处理能力，在BMC103中固定配置的诊断算法只能是资源消耗很少的算法，这会导致所配置的诊断算法的精度不高，从而导致针对故障部件的诊断准确率较低，如容易将故障部件误诊为正常部件等，从而该存在故障的部件容易对目标设备100处理业务产生影响，如容易导致业务数据处理出错等。

并且，当采用带外故障处理方式时，BMC103在确定部件存在故障后，会直接通知BIOS102执行故障隔离等操作，这需要占用目标设备100较多的资源，从而影响设备对于业务的处理，如造成业务卡顿或业务响应变慢等问题。

另外，由于诊断算法在BMC103中固定配置，这会导致针对诊断算法的更新难度以及更新代价较高。比如，实际应用场景中，当存在较多数量的目标设备时，需要对每个目标设备统一执行更新BMC中的诊断算法的操作，算法更新所需的资源消耗较大、针对大量目标设备的算法更新难度也较大。

基于此，在本申请实施例提供的故障处理系统10中，可以由诊断设备200对目标设备100中的部件进行故障诊断，以提高针对目标设备100中的故障部件的诊断准确率、降低故障的部件对于目标设备100处理业务的影响。

具体实现时，如图1所示，诊断设备200中包括数据获取模块201、故障诊断模块202、决策模块203、故障处理模块204。在对目标设备100进行故障诊断和处理的过程中，数据获取模块201获取目标设备100中待诊断部件的状态信息，该待诊断部件如可以是目标设备100中的处理器、硬盘等部件，数据获取模块201所获取的状态信息可以包括OS101采集的待诊断部件的第一状态信息，或者包括BMC103采集的待诊断部件的第二状态信息，或者同时包括第一状态信息以及第二状态信息，然后，数据获取模块201并将所获取的状态信息提供给故障诊断模块202。故障诊断模块202利用该待诊断部件对应的诊断算法，根据获取的状态信息对该待诊断部件进行故障诊断，得到故障诊断结果，该故障诊断结果用于指示该待诊断部件是否发生故障，并将故障诊断结果提供给故障处理模块204。故障处理模块204在根据诊断结果确定待诊断部件发生故障后，可以指示决策模块203反馈该待诊断部件对应的故障处理策略。决策模块203根据目标设备上的业务，确定该待诊断部件对应的故障处理策略，并将其反馈给故障处理模块204。从而，故障处理模块204根据故障诊断结果以及故障处理策略，指示目标设备100针对该待诊断部件执行目标操作，该目标操作例如可以是故障隔离操作或者故障修复操作等。

由于诊断算法部署于诊断设备200，即独立于目标设备100进行部署，这使得诊断设备200能够选用算力要求较高但是算法精度更高的诊断算法对待诊断部件进行故障诊断，从而摆脱了目标设备100中的BMC103的有限算力对于诊断算法的精度限制，提高故障诊断的准确性，降低故障部件对于目标设备处理业务的影响。并且，当目标设备的数量较多时，若需要对诊断算法进行更新，则仅在诊断设备200中进行诊断算法即可，相比于对大量的目标设备更新诊断算法的方式而言，能够显著降低算法更新难度以及算法更新所需的资源消耗。

另外，诊断设备200在确定待诊断部件发生故障后，并非直接指示目标设备100对该部件执行故障修复、故障隔离等操作，而是根据目标设备100上的业务考虑确定对该待诊断部件进行故障处理所采用的策略，如此，可以进一步降低故障处理对于目标设备100处理业务的影响。

值得注意的是，图1所示的故障处理系统10的具体结构仅作为一种实现示例，在其它可能的实施方式中，故障处理系统10可以包括更多数量的目标设备或者诊断设备，每个诊断设备可以负责对一个或者多个目标设备进行故障诊断；或者，诊断设备200中还可以包括更多的功能模块，以支持诊断设备200实现更多其它的功能；或者，诊断设备200中各个模块的功能划分并不局限于图1所示示例，如可以将故障处理系统10的多个模块合并为一个模块，或者可以将故障处理系统10中的部分模块拆分成多个模块等，本实施例并不限定诊断设备200的具体结构局限于图1所示示例。

作为一些示例，诊断设备200可以被部署于云端，用于为用户提供故障处理的云服务，此时，诊断设备200例如可以是由云端的计算设备或者计算设备集群实现。或者，诊断设备200可以被部署于本地，从而可以为用户提供本地的故障处理服务。比如，诊断设备200还运行有网管软件，并且，诊断设备200在利用网管软件对本地网络进行管理和配置的同时，可以对本地网络中的各个设备进行故障诊断以及处理。

实际应用时，上述诊断设备200中的各个功能模块，可以通过软件实现，或者可以通过硬件实现。

诊断设备200中的各个功能模块作为软件功能单元的一种举例，可以包括运行在计算实例上的代码。其中，计算实例可以包括主机、虚拟机、容器中的至少一种。进一步地，上述计算实例可以是一台或者多台。例如，诊断设备200中的各个功能模块可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。进一步地，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone，AZ)中，也可以分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。

同样，用于运行该代码的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud，VPC)中，也可以分布在多个VPC中。其中，通常一个VPC设置在一个region内，同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。

诊断设备200中的各个功能模块作为硬件功能单元的一种举例，诊断设备200可以包括至少一个计算设备，如服务器等，诊断设备200中的每个功能模块可以由一个或者多个计算设备实现。或者，诊断设备200中的每个功能模块也可以是利用专用集成电路(application-specific integrated circuit，ASIC)实现、或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)、数据处理单元(data processing unit，DPU)、人工智能(artificial intelligence，AI)芯片或其任意组合实现。

诊断设备200包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。诊断设备200包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。同样，诊断设备200包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

接下来，对故障处理过程的各种非限定性的具体实施方式进行详细描述。

参阅图2，为本申请实施例中一种故障处理方法的流程示意图。该方法可以应用于上述图1所示的故障处理系统10中，或者也可以是应用于其它可适用的故障处理系统中。下面以应用于图1所示的故障处理系统10为例进行说明。

图2所示的故障处理方法具体可以包括：

S201：数据获取模块201获取OS101采集的待诊断部件的第一状态信息，和/或，获取BMC103采集的待诊断部件的第二状态信息。

本实施例中，目标设备100中的待诊断部件，具体可以是用于存储数据的部件，例如可以是内存、缓存、硬盘等部件。

其中，内存，例如可以是存储级存储器(storage class memory，SCM)、动态随机存取存储器(dynamic random access memory，DRAM)、可抹除可编程只读存储器(erasableprogrammable read only memory，EPROM)、双列直插式存储器模块或双线存储器模块(dual in-line memory module，简称DIMM)中一种或者多种，或者可以是其它类型的存储器。

缓存，例如可以是静态随机存取存储器(static random access memory，SRAM)、异步(asynchronous)SRAM中的一种或者多种，或者可以是其它类型的存储器。

硬盘，例如可以是机械硬盘(hard disk drive，HDD)、固态硬盘(Solid StateDisk,SSD)中的一种或者多种，或者可以是其它类型的硬盘。

或者，目标设备100中的待诊断部件，也可以是用于数据计算的部件(如CPU等)、数据通信的部件(如网络接口等)，或者可以是其它类型的部件，本实施例对此并不进行限定。

待诊断部件在运行过程中，可能会发生故障，并且，该待诊断部件发生故障后，可能会对目标设备100处于业务产生影响。例如，当待诊断部件具体为内存时，若内存中的部分存储区域发生故障，则可能会导致目标设备100存储业务数据出错或者数据存储失败，从而导致目标设备100处理业务产生异常。

本实施例中，诊断设备200中的数据获取模块201可以获取待诊断部件的状态信息，以便根据该状态信息判断该待诊断部件是否存在异常。其中，状态信息，用于指示待诊断部件在运行过程中的状态。以待诊断部件为内存为例，状态信息具体可以是内存利用率、内存剩余存储空间等性能数据，或者可以是针对该内存的设备检查异常(machine checkexception，MEC)信息，或者可以是内存的可纠正错误(correctable error，CE)/不可纠正错误(uncorrectable error，UCE)的日志等。当待诊断部件为硬盘时，状态信息例如可以是自我监测、分析及报告技术(self-monitoring analysis and reporting technology，smart)信息，或者可以是硬盘的误码率、温度、设备连接状态等。

在一种可能的实施方式中，数据获取模块201可以通过带内的OS101或者带外的BMC103获取待诊断部件的状态信息。具体地，当通过带内的OS101获取状态信息时，OS101可以在硬件104上报异常后，可以采集待诊断部件的smart信息、性能数据作为第一状态信息，并通过目标设备100上的通信接口将该第一状态信息发送给数据获取模块201。当通过带外的BMC103获取状态信息时，BMC103可以采集待诊断部件的温度、误码率、CE/UCE日志、设备连接状态等信息，并将这些信息作为第二状态信息通过目标设备100上的通信接口发送给数据获取模块201。或者，数据获取模块201可以一并收到OS101采集的第一状态信息以及BMC103采集的第二状态信息，如此，可以增加故障诊断所依据数据的维度，从而可以提高故障诊断的准确性。

值得注意的是，上述实现方式仅作为一种示例性说明，在其它实施例中，OS101所采集的第一状态信息以及BMC103所采集的第二状态信息，可以存储于云端的数据湖中，从而数据获取模块201通过访问数据湖，获取待诊断部件对应的状态信息。

数据获取模块201在获取到待诊断部件对应的状态信息后，将其提供给故障诊断模块202。

S202：故障诊断模块202利用待诊断部件对应的诊断算法，根据第一状态信息和/或第二状态信息对该待诊断部件进行故障诊断，得到故障诊断结果，该故障诊断结果用于指示待诊断部件发生故障。

实际应用时，故障诊断模块202中可以预先配置有多个不同的部件分别对应的诊断算法，不同部件对应的诊断算法可以不同。这样，故障诊断模块202在获取到待诊断部件的状态信息后，可以先从多个诊断算法中查找出待诊断部件对应的诊断算法，以便利用该诊断算法对待诊断部件进行故障诊断。

作为一种故障诊断的实现示例，故障诊断模块202所配置的诊断算法，具体可以是基于该诊断算法所构建的AI模型，该AI模型例如可以是基于梯度提升决策树(gradientboosting decision tree，GBDT)等机器学习算法所构建的AI模型，或者可以是基于随机森林(random forest，RF)等监督式算法所构建的AI模型，或者可以是基于深度神经网络(Deep Neural Networks，DNN)算法所构建的AI模型等。故障诊断模块202在确定待诊断部件对应的AI模型后，可以将待诊断部件对应的状态信息输入至该AI模型，并将该AI模型输出的推理结果确定为故障诊断结果。其中，AI模型输出的故障诊断结果，可以用于指示待诊断部件在当前时刻是否发生故障；或者，故障诊断结果，可以用于预测待诊断部件在未来某个时刻发生故障(即当前时刻尚未发生故障)。

其中，故障诊断模块202中的AI模型，可以预先通过至少一组训练样本完成训练，该训练样本可以包括待诊断部件在历史时间段内的历史状态信息以及待诊断部件在历史时间段内的故障状态。具体地，以故障诊断模块202训练AI模型为例，故障诊断模块202可以将历史状态信息作为AI模型的输入，获得AI模型根据该历史状态信息进行推理所得到的推理结果，该推理结果用于指示待诊断部件在历史时间段内是否发生故障。然后，故障诊断模块202可以将该推理结果与训练样本中的实际故障状态进行比较，并根据比较情况对AI模型中的参数进行调整，以此完成对AI模型的训练。在其它实施例中，AI模型也可以是利用其它设备进行训练，并由其它设备将完成训练的AI模型提供给诊断设备200中。实际应用时，目标设备100中的不同部件，可以采用不同结构的AI模型的进行故障诊断，或者采用不同的模型训练算法完成训练，或者采用不同的模型输入格式等，本实施例对此并不进行限定。

作为另一种故障诊断的实现示例，故障诊断模块202所配置的诊断算法中，可以配置有预设的故障阈值，这样，故障诊断模块202在获取到待诊断部件对应的状态信息后，可以将该状态信息中的值与预设的故障阈值进行比较。当状态信息中的值大于标准阈值时，则故障诊断模块202可以生成用于指示待诊断部件当前发生故障的故障诊断结果；而当状态信息中的值小于标准阈值时，则故障诊断模块202可以生成用于指示待诊断部件未发生故障的故障诊断结果。比如，假设状态信息中包括待诊断部件的温度，则，故障诊断模块202可以比较状态信息中的温度是否超出预先设定的标准温度，如果超过，则确定待诊断部件发生故障，否则，确定待诊断部件未发生故障。或者，状态信息中包括待诊断部件的可纠正错误(CE)的日志，则，故障诊断模块202可以根据该日志，预测该待诊断部件未来是否发生不可纠正错误(UCE)。

进一步地，故障诊断模块202还可以根据待诊断部件的状态信息的变化，预测待诊断部件在未来时刻是否发生故障。比如，假设待诊断部件的状态信息中包括温度，则故障诊断模块202可以状态信息分析待诊断部件的温度变化趋势为持续的上升趋势，则预测待诊断部件可以预测待诊断部件在未来某个时刻的温度超出标准温度，从而生成用于指示待诊断部件在未来时刻发生故障的故障诊断结果。

进一步地，故障诊断模块202所生成的故障诊断结果，还可以用于指示待诊断部件中发生故障的相关信息，如故障的位置、故障原因、发生故障的时间等信息，以便后续针对该待诊断部件进行针对性的故障处理。

故障诊断模块202在生成故障诊断结果，可以将其提供给决策模块203。

S203：决策模块203根据目标设备100上的业务，确定待诊断部件对应的故障处理策略。

本实施例中，在确定故障诊断结果指示待诊断部件当前发生故障或者在未来某一时刻发生故障后，决策模块203可以根据目标设备上的业务，确定待诊断部件对应的故障处理策略，该故障处理策略用于指示针对故障的部件所采用的处理方式。

具体实现时，决策模块203可以先确定目标设备100上运行的业务，例如决策模块203可以向目标设备100请求其当前正在运行的业务的相关信息，如业务的名称、业务类型、业务运行状态等信息。示例性地，业务类型例如可以根据时延敏感情况划分为时延敏感型和非时延敏感型，或者根据业务数据的副本数量划分为单副本类型以及多副本类型，又或者是根据业务的迁移能力划分为可热迁移类型和不可热迁移类型等；业务运行状态，例如可以根据所要处理的业务数据的数量，划分为高负载状态、低负载状态等。

然后，决策模块203可以根据获取的业务相关信息，从预先针对待诊断部件配置的多条故障处理策略中，查找与该业务相关信息相匹配的故障处理策略。其中，决策模块203中可以预先针对待诊断部件配置多条故障处理策略，并且，不同故障处理策略适用于不同类型的业务或者适用于不同的运行状态的业务。示例性地，故障处理系统10还可以包括客户端，该客户端例如可以是故障处理系统10对外提供的网络浏览器，或者可以是运行在用户终端上的应用程序(application)，从而故障处理系统10可以通过该客户端呈现针对故障处理策略的配置界面，例如可以呈现图3所示的配置界面，以便用户(如测试人员)在该配置界面上为目标设备100中的各个部件配置相应的一个或者多个故障处理策略。相应地，故障处理系统10可以将用户针对各个部件配置的故障处理策略部署于决策模块203中。

这样，当获取的业务相关信息指示目标设备上业务的类型为第一类型，或者目标设备上业务的状态为第一状态时，决策模块203可以从多个故障处理策略中，确定该待诊断部件对应的故障处理策略为第一故障处理策略。而当获取的业务相关信息指示目标设备上业务的类型为第二类型，或者目标设备上业务的状态为第二状态时，决策模块203可以从多个故障处理策略中，确定该待诊断部件对应的故障处理策略为第二故障处理策略。

举例来说，假设待诊断部件为内存，则可以预先在决策模块203中针对内存配置策略1、策略2以及策略3，其中，策略1用于指示在确定待诊断部件发生故障后延时处理，策略2用于指示在确定待诊断部件发生故障后立即处理，策略3用于指示在预测到待诊断部件在未来的目标时刻发生故障时提前进行处理。

这样，若故障诊断结果指示待诊断部件已经发生故障，则在获取的业务相关信息指示目标设备100当前运行的业务为时延敏感型业务，或者业务的运行状态为高负载状态时，决策模块203可以确定内存对应的故障处理策略为策略1，即延后一段时间对故障内存进行处理，以避免针对故障内存的处理操作影响目标设备100处理业务。而在获取的业务相关信息指示目标设备100当前运行的业务为非时延敏感型业务，且业务的运行状态为低负载状态时，决策模块203可以确定内存对应的故障处理策略为策略2，此时，目标设备100即使基于策略2立即对故障的内存部分进行处理，也不会对目标设备100处理业务产生影响，或者产生的影响在该业务所能容忍的范围内。

而若故障诊断结果指示待诊断部件在未来的目标时刻预测会发生故障，则在获取的业务相关信息指示目标设备100当前运行的业务为可热迁移类型的业务时，决策装置203可以确定内存对应的故障处理策略为策略3，该策略3例如可以指示目标设备100提前将处理业务的虚拟机进行迁移，然后再对故障的内存进行隔离或者修复后重新上线，最后再将虚拟机迁回至目标设备100中。而在获取的业务相关信息指示目标设备100当前运行的业务为不可热迁移类型的业务时，决策装置203可以确定内存对应的故障处理策略为策略1或者策略2。

上述实施方式中，决策模块203是从预先配置的多条故障处理策略中选择一种故障处理策略，而其它可能的实施方式中，决策模块203也可以根据获取的业务相关信息，按照预先设定的规则，动态生成针对待诊断部件的故障处理策略。比如，所获取的业务相关信息中指示了目标设备100上的业务当前的负载情况，则，决策模块203可以根据该业务的负载情况，动态生成与该业务当前的负载相匹配的延时处理故障部件的策略，其中，业务负载与故障处理的时延呈正相关，即业务的负载越大，针对该待诊断部件进行故障处理的时延越大。又比如，所获取的业务相关信息中指示了目标设备100上的业务为非时延敏感型业务，则，决策模块203可以根据硬盘(即待诊断部件)的坏块数量，动态生成与该坏块数量相匹配的故障处理策略，如当坏块数量较少时，故障处理策略指示对硬盘中的坏块进行隔离；而当坏块数量较多时，故障处理策略指示目标设备100将该硬盘剔除存储池，并对该硬盘进行坏块隔离、上下电等操作进行修复，当该硬盘经过故障修复后能够继续使用，再将该硬盘重新接入存储池以提供数据读写服务。

决策模块203在确定待诊断部件对应的故障处理策略后，可以将该处理处理策略与故障诊断结果一并提供给故障处理模块204。

S204：故障处理模块204根据故障诊断结果以及故障处理策略，指示目标设备100针对待诊断部件执行目标操作。

具体实现时，故障处理模块204可以根据故障诊断结果以及故障处理策略生成操作指令，该操作指令用于指示对待诊断部件所需执行的目标操作。示例性地，故障处理模块204指示目标设备100执行的目标操作，例如可以是故障隔离操作、故障修复操作等，可以根据故障处理策略所指示的针对待诊断部件的处理方式进行确定。

进一步地，该操作指令还可以携带有待诊断部件中发生故障的位置或者发生故障的时间，以指示目标设备100针对该故障位置进行处理，或者在到达故障时间(或者到达故障时间之前)对该待诊断部件进行故障处理。

其中，故障处理模块204在指示目标设备100执行目标操作时，可以指示目标设备100通过带内的软件处理方式执行目标操作，或者可以指示目标设备100通过带外的硬件处理方式执行目标操作。具体地，当故障处理模块204所接收到的故障处理策略为上述第一故障处理策略时，故障处理模块204可以指示目标设备100中的OS101针对待诊断部件执行软件隔离或者软件修复的目标操作。比如，OS101可以针对内存执行离线故障页面(bad pageofflining)等操作，针对硬盘可以执行覆写、磁头隔离等操作。当故障处理模块204所接收到的故障处理策略为上述第二故障处理策略时，故障处理操作模块204可以指示目标设备100中的BMC103针对待诊断部件执行硬件隔离或者硬件修复的目标操作。比如，BMC103可以针对内存执行自适应双设备更正(adaptive double device data correction，ADDDC)、行隔离(post pacakge repair，PPR)等操作，针对硬盘可以执行坏块隔离、复位等操作。本实施例中，对于待诊断部件的故障修复所执行的目标操作并不进行限定。

实际应用时，故障处理模块204还可以生成相应的日志，该日志用于记录故障处理系统10针对目标设备100中的待诊断部件的故障处理记录，该记录可以包括待诊断部件的标识、故障原因、故障发生时间、故障处理时间、故障处理操作、所采用的故障处理策略等信息，以便后续基于该日志进行故障回溯分析，或者基于该日志对待诊断部件进行维护等。

进一步地，故障处理系统10还可以将针对该待诊断部件的故障处理记录呈现给用户。具体实现时，故障处理模块204可以将故障处理记录发送给故障处理系统10对外呈现的客户端，并由该客户端在相应的交互界面上将该故障处理记录呈现给用户。其中，客户端所呈现的交互界面例如可以是如图4所示，以便用户感知目标设备100中的部件在运行过程中的故障情况以及修复情况。

需要说明的是，上述步骤S201至步骤S204中所呈现的各个模之间的数据交互方式仅作为一种示例性说明，在其它实现示例中，如图2所示，故障诊断模块202在生成故障诊断结果后，可以将该故障诊断结果发送给故障处理模块204，由故障处理模块204在确定待诊断部件当前存在故障或者即将发生故障后，向决策模块203请求该待诊断部件对应的故障处理策略，从而决策模块203响应该请求，生成故障处理策略并将其反馈给故障处理模块204，以便故障处理模块204根据接收到的故障诊断结果以及故障处理策略，指示目标设备100执行相应的目标操作。

本实施例中，由于诊断算法部署于诊断设备200，即独立于目标设备100进行部署，这使得诊断设备200能够选用算力要求较高但是算法精度更高的诊断算法对待诊断部件进行故障诊断，从而摆脱了目标设备100中的BMC103的有限算力对于诊断算法的精度限制，提高故障诊断的准确性，降低故障部件对于目标设备处理业务的影响。

并且，当目标设备的数量较多时，若需要对诊断算法进行更新，则仅在诊断设备200中进行诊断算法即可，相比于对大量的目标设备更新诊断算法的方式而言，能够显著降低算法更新难度以及算法更新所需的资源消耗。

另外，诊断设备200在确定待诊断部件发生故障后，并非直接指示目标设备100对该部件执行故障修复、故障隔离等操作，而是根据目标设备100上的业务考虑确定对该待诊断部件进行故障处理所采用的策略，如此，可以进一步降低故障处理对于目标设备100处理业务的影响。并且，根据目标设备100上的业务类型、业务运行状态等信息，指示目标设备100通过带内的软件处理方式或者通过带外的硬件处理方式执行目标操作，以此可以提高故障处理的灵活性，进一步降低故障处理对于业务的影响。

下面，基于硬件设备实现的角度，对故障处理的过程中所涉及的诊断设备进行详细介绍。

图5示出了一种诊断设备的结构示意图，诊断设备500可以是云环境中的计算设备(如服务器)，或边缘环境中的计算设备，或终端设备等具体可以用于实现上述图2所示实施例中数据获取模块201、故障诊断模块202、决策模块203、故障处理模块204的功能，也即实现上述诊断设备200的功能。

如图5所示，诊断设备500包括处理器510、存储器520、通信接口530和总线540。处理器510、存储器520和通信接口530之间通过总线540通信。总线540可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extendedindustry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口530用于与外部通信，例如接收OS101采集的待诊断部件的第一状态信息，或者BMC103采集的待诊断部件的第二状态信息等。

其中，处理器510可以为中央处理器(central processing unit，CPU)、专用集成电路(application specific integrated circuit,ASIC)、图形处理器(graphicsprocessing unit,GPU)或者一个或多个集成电路。处理器510还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，诊断设备中各个模块的功能可以通过处理器510中的硬件的集成逻辑电路或者软件形式的指令完成。处理器510还可以是通用处理器、数据信号处理器(digital signal process,DSP)、现场可编程逻辑门阵列(field programmablegate array,FPGA)或者其他可编程逻辑器件，分立门或者晶体管逻辑器件，分立硬件组件，可以实现或者执行本申请实施例中公开的方法、步骤及逻辑框图。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，结合本申请实施例所公开的方法可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器、闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器520，处理器510读取存储器520中的信息，结合其硬件完成诊断设备中的部分或全部功能。

存储器520可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器520还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，HDD或SSD。

存储器520中存储有可执行代码，处理器510执行该可执行代码以执行前述诊断设备所执行的方法。

具体地，在实现图2所示实施例的情况下，执行图2中的数据获取模块201、故障诊断模块202、决策模块203、故障处理模块204的功能所需的软件或程序代码存储在存储器520中，数据获取模块201与其它设备的交互通过通信接口530实现，处理器用于执行存储器520中的指令，实现上述诊断设备200所执行的方法。

图6示出的一种计算设备集群的结构示意图。其中，图6所示的计算设备集群60包括多个计算设备，上述诊断设备200包括的多个功能模块可以分布式地部署在该计算设备集群60中的多个计算设备上。如图6所示，计算设备集群60包括多个计算设备600，每个计算设备600包括存储器610、处理器620、通信接口630以及总线640，其中，存储器610、处理器620、通信接口630通过总线640实现彼此之间的通信连接。

处理器620可以采用CPU、GPU、ASIC或者一个或多个集成电路。处理器620还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述诊断设备200的部分功能可用通过处理器620中的硬件的集成逻辑电路或者软件形式的指令完成。处理器620还可以是DSP、FPGA、通用处理器、其他可编程逻辑器件，分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的部分方法、步骤及逻辑框图。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器、闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器610，在每个计算设备600中，处理器620读取存储器610中的信息，结合其硬件可以完成诊断设备200的部分功能。

存储器610可以包括ROM、RAM、静态存储设备、动态存储设备、硬盘(例如SSD、HDD)等。存储器610可以存储程序代码，例如，用于实现数据获取模块201的部分或者全部程序代码、用于实现故障诊断模块202的部分或者全部程序代码、用于实现决策模块203的部分或者全部程序代码、用于实现故障处理模块204的部分或者全部程序代码等。针对每个计算设备600，当存储器610中存储的程序代码被处理器620执行时，处理器620基于通信接口630执行诊断设备200所执行的部分方法，如其中一部分计算设备600可以用于执行上述数据获取模块201所执行的方法，另一部分计算设备600用于执行上述故障诊断模块202所执行的方法，又一部分计算设备600用于执行上述决策模块203所执行的方法，再一部分计算设备600用于执行上述故障处理模块204所执行的方法。存储器610还可以存储数据，例如：处理器620在执行过程中产生的中间数据或结果数据，例如，上述第一状态信息、第二状态信息、故障诊断结果以及故障处理策略等。

每个计算设备600中的通信接口603用于与外部通信，例如与其它计算设备600进行交互等。

总线640可以是外设部件互连标准总线或扩展工业标准结构总线等。为便于表示，图6中每个计算设备600内的总线640仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

上述多个计算设备600之间通过通信网络建立通信通路，以实现诊断设备200的功能。任一计算设备可以是云环境中的计算设备(例如，服务器)，或边缘环境中的计算设备，或终端设备。

此外，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在一个或者多个计算设备上运行时，使得该一个或者多个计算设备执行上述实施例诊断设备200的各个模块所执行的方法。

此外，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品被一个或者多个计算设备执行时，所述一个或者多个计算设备执行前述故障处理方法中的任一方法。该计算机程序产品可以为一个软件安装包，在需要使用前述故障处理方法的任一方法的情况下，可以下载该计算机程序产品并在计算机上执行该计算机程序产品。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

Claims (20)

1.一种故障处理系统，其特征在于，所述故障处理系统包括目标设备以及诊断设备，所述诊断设备包括操作系统OS、基板管理控制器BMC以及待诊断部件；

所述目标设备用于处理业务；

所述诊断设备用于获取所述OS采集的所述待诊断部件的第一状态信息，或获取所述BMC采集的所述待诊断部件的第二状态信息；并利用所述待诊断部件对应的诊断算法，根据所述第一状态信息或所述第二状态信息对所述待诊断部件进行故障诊断，得到故障诊断结果，所述故障诊断结果用于指示所述待诊断部件发生故障；根据所述目标设备上的所述业务，确定所述待诊断部件对应的故障处理策略；根据所述故障诊断结果以及所述故障处理策略，指示所述目标设备针对所述待诊断部件执行目标操作。

2.根据权利要求1所述的故障处理系统，其特征在于，所述诊断设备，用于：

确定所述待诊断部件对应的人工智能AI模型，所述AI模型基于所述待诊断部件对应的诊断算法完成构建；

利用所述AI模型对所述第一状态信息或所述第二状态信息进行推理。

3.根据权利要求2所述的故障处理系统，其特征在于，所述AI模型通过至少一组训练样本完成训练，所述训练样本包括所述待诊断部件在历史时间段内的历史状态信息、所述待诊断部件在所述历史时间段内的故障状态。

4.根据权利要求1至3任一项所述的故障处理系统，其特征在于，所述诊断设备用于：

当所述目标设备上业务的类型为第一类型，或者所述目标设备上业务的状态为第一状态时，确定所述待诊断部件对应的故障处理策略为第一故障处理策略，所述第一故障处理策略用于指示所述OS针对所述待诊断部件执行所述目标操作；

当所述目标设备上业务的类型为第二类型，或者所述目标设备上业务的状态为第二状态时，确定所述待诊断部件对应的故障处理策略为第二故障处理策略，所述第二故障处理策略用于指示所述BMC针对所述待诊断部件执行所述目标操作。

5.根据权利要求1至4任一项所述的故障处理系统，其特征在于，所述待诊断部件包括用于存储数据的部件，所述用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

6.根据权利要求1至5任一项所述的故障处理系统，其特征在于，所述诊断设备部署于云端，或者，所述诊断设备上还部署有网管软件。

7.一种故障处理方法，其特征在于，所述方法应用于故障处理系统，所述故障处理系统包括目标设备以及诊断设备，所述诊断设备包括操作系统OS、基本输入输出系统BIOS以及待诊断部件，所述方法包括：

所述诊断设备获取所述OS采集的所述待诊断部件的第一状态信息，或获取所述BMC采集的所述待诊断部件的第二状态信息；

所述诊断设备利用所述待诊断部件对应的诊断算法，根据所述第一状态信息或所述第二状态信息对所述待诊断部件进行故障诊断，得到故障诊断结果，所述故障诊断结果用于指示所述待诊断部件发生故障；

所述诊断设备根据所述目标设备上的业务，确定所述待诊断部件对应的故障处理策略；

所述诊断设备根据所述故障诊断结果以及所述故障处理策略，指示所述目标设备针对所述待诊断部件执行目标操作。

8.根据权利要求7所述的方法，其特征在于，所述诊断设备利用所述待诊断部件对应的诊断算法，根据所述第一状态信息或所述第二状态信息对所述待诊断部件进行故障诊断，包括：

所述诊断设备确定所述待诊断部件对应的人工智能AI模型，所述AI模型基于所述待诊断部件对应的诊断算法完成构建；

所述诊断设备利用所述AI模型对所述第一状态信息或所述第二状态信息进行推理。

9.根据权利要求8所述的方法，其特征在于，所述AI模型通过至少一组训练样本完成训练，所述训练样本包括所述待诊断部件在历史时间段内的历史状态信息、所述待诊断部件在所述历史时间段内的故障状态。

10.根据权利要求7至9任一项所述的方法，其特征在于，所述诊断设备根据所述目标设备上的业务，确定所述待诊断部件对应的故障处理策略，包括：

当所述目标设备上业务的类型为第一类型，或者所述目标设备上业务的状态为第一状态时，所述诊断设备确定所述待诊断部件对应的故障处理策略为第一故障处理策略，所述第一故障处理策略用于指示所述OS针对所述待诊断部件执行所述目标操作；

当所述目标设备上业务的类型为第二类型，或者所述目标设备上业务的状态为第二状态时，所述诊断设备确定所述待诊断部件对应的故障处理策略为第二故障处理策略，所述第二故障处理策略用于指示所述BMC针对所述待诊断部件执行所述目标操作。

11.根据权利要求7至10任一项所述的方法，其特征在于，所述待诊断部件包括用于存储数据的部件，所述用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

12.根据权利要求7至11任一项所述的方法，其特征在于，所述诊断设备部署于云端，或者，所述诊断设备上还部署有网管软件。

13.一种诊断设备，其特征在于，所述诊断设备包括：

数据获取模块，用于获取目标设备中的操作系统OS采集的所述目标设备中待诊断部件的第一状态信息，或获取所述目标设备中的基板管理控制器BMC采集的所述待诊断部件的第二状态信息；

故障诊断模块，用于利用所述待诊断部件对应的诊断算法，根据所述第一状态信息或所述第二状态信息对所述待诊断部件进行故障诊断，得到故障诊断结果，所述故障诊断结果用于指示所述待诊断部件发生故障；

决策模块，用于根据所述目标设备上的业务，确定所述待诊断部件对应的故障处理策略；

故障处理模块，用于根据所述故障诊断结果以及所述故障处理策略，指示所述目标设备针对所述待诊断部件执行目标操作。

14.根据权利要求13所述的诊断设备，其特征在于，所述故障诊断模块，用于：

确定所述待诊断部件对应的人工智能AI模型，所述AI模型基于所述待诊断部件对应的诊断算法完成构建；

利用所述AI模型对所述第一状态信息或所述第二状态信息进行推理。

15.根据权利要求14所述的诊断设备，其特征在于，所述AI模型通过至少一组训练样本完成训练，所述训练样本包括所述待诊断部件在历史时间段内的历史状态信息以及所述待诊断部件的故障状态。

16.根据权利要求13至15任一项所述的诊断设备，其特征在于，所述决策模块，用于：

当所述目标设备上业务的类型为第一类型，或者所述目标设备上业务的状态为第一状态时，所述诊断设备确定所述待诊断部件对应的故障处理策略为第一故障处理策略，所述第一故障处理策略用于指示所述OS针对所述待诊断部件执行所述目标操作；

当所述目标设备上业务的类型为第二类型，或者所述目标设备上业务的状态为第二状态时，所述诊断设备确定所述待诊断部件对应的故障处理策略为第二故障处理策略，所述第二故障处理策略用于指示所述BMC针对所述待诊断部件执行所述目标操作。

17.根据权利要求13至16任一项所述的诊断设备，其特征在于，所述待诊断部件包括用于存储数据的部件，所述用于存储数据的部件包括内存、缓存、硬盘中的一种或者多种。

18.根据权利要求13至17任一项所述的诊断设备，其特征在于，所述诊断设备部署于云端，或者，所述诊断设备上还部署有网管软件。

19.一种计算设备集群，其特征在于，包括至少一个计算设备，每个计算设备包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算设备集群执行权利要求7至12中任一项所述的方法。

20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在至少一个计算设备上运行时，使得所述至少一个计算设备执行如权利要求7至12任一项所述的方法。