CN102571498A - 故障注入控制方法和装置 - Google Patents

Abstract

本发明实施例提供一种故障注入控制方法和装置。该方法包括：向被测设备执行故障注入操作；当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。本发明各实施例是提供的故障注入控制方法和装置，通过在被测设备失效时，向被测设备发送设备控制指令来变更设备的状态，从而能够实现在故障注入过程中对被测设备进行控制，有助于继续执行故障注入操作。

Description

故障注入控制方法和装置

技术领域

本发明涉及数据处理技术，尤其涉及一种故障注入控制方法和装置。

背景技术

高端容错计算机需要保证用户业务在系统出现一定程度的故障时，仍然能够正常运行，这也是体现高端容错计算机的价值所在。为了验证系统的容错能力，需要进行故障注入。故障注入技术是验证容错系统设计正确性和评价容错性能的重要方法，它有意识地向系统中引入故障以加速容错系统的评估过程。

传统的故障注入手段包括软件注入和硬件注入。软件故障注入通常是基于被测设备操作系统(Operating System，简称OS)进行注入。向被测设备的用户层程序发送故障参数后，用户层程序再将故障参数通过系统调用进入内核态，然后内核再调用驱动或者故障注入接口进行故障注入，然后在OS上观察故障注入的效果。硬件故障注入通常是需要通过探针(Probe)连接到被测设备，探针通常通过“JTAG”接口或者系统管理总线(System Manage BUS，简称SMBUS)来访问硬件。探针通过JTAG接口能够扫描出所有连接到南桥芯片上的设备，并且能够访问相应的设备寄存器，硬件故障注入通过恶意修改被测设备的寄存器来达到触发故障的目的。

但是，当故障注入后，可能由于故障的注入而导致系统出现丢失网络连接或者OS挂死等现象，则本次故障注入结果无法获知，下一次的故障注入也无法继续。

发明内容

本发明实施例提供一种故障注入控制方法和装置，以解决现有技术中故障注入失败导致无法继续执行故障注入操作的缺陷。

本发明实施例一方面提供了一种故障注入控制方法，包括：

向被测设备执行故障注入操作；

当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

本发明实施例另一方面还提供了一种故障注入控制装置，包括：

故障注入模块，用于向被测设备执行故障注入操作；

设备控制模块，用于当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

本发明各实施例是提供的故障注入控制方法和装置，通过在被测设备失效时，向被测设备发送设备控制指令来变更设备的状态，从而能够实现在故障注入过程中对被测设备进行控制，有助于继续执行故障注入操作。

附图说明

图1为本发明实施例一提供的故障注入控制方法的流程图；

图2为本发明实施例二提供的故障注入控制装置的结构示意图；

图3为本发明实施例二所提供故障注入控制装置适用的网络架构示意图；

图4A所示为本发明实施例所提供故障注入控制装置执行的故障注入流程的流程图；

图4B所示为本发明实施例所提供故障注入控制装置执行的软件故障注入流程的流程图；

图4C所示为本发明实施例所提供故障注入控制装置执行的重启流程的流程图；

图4D所示为本发明实施例所提供故障注入控制装置执行的硬件故障注入流程的流程图；

图5为本发明实施例三提供的故障注入控制装置的结构示意图；

图6为本发明实施例三所提供故障注入控制装置适用的网络架构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

图1为本发明实施例一提供的故障注入控制方法的流程图，该方法可以采用故障注入控制装置来执行，该控制装置可以由硬件和软件形式来实现。该方法可通过将故障注入控制装置与被测设备相连来进行故障注入操作，并对故障注入操作进行控制，方法具体包括如下步骤：

步骤110、向被测设备执行故障注入操作；

步骤120、当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

本实施例的技术方案，通过向被测设备发送设备控制指令，能够通过变更设备状态来直接控制设备，从而实现在故障注入的整个流程中，主动控制设备状态的变更，以便在设备失效时，重新恢复设备状态，例如复位或重启设备，从而继续完成故障注入操作，从而解决现有技术中故障注入后导致设备失效而无法继续执行注入操作的缺陷。

具体的，向被测设备发送设备控制指令，以控制被测设备变更设备状态具体可以是向被测设备发送设备重启指令，以控制被测设备重新启动。重启指令具体可以是上、下电等指令，以使得被测设备恢复正常。当然，也可以在故障注入过程中，根据需要发送其他设备控制指令，以控制设备完成其他状态的变更。

被测设备的设备失效信息，典型地是包括通信连接断开信息，即故障注入控制装置与被测设备之间的通信连接断开。这可以通过监测通信连接状态或实时查询设备是否有响应来判断通信连接是否正常。通常，注入故障参数后，可能会发生系统死机而导致通信连接断开的现象。

故障注入控制装置对被测设备的状态控制，可以基于具有设备硬件管理功能的软件来实现。例如，向被测设备发送设备控制指令，以控制被测设备变更设备状态的操作可通过设备管理软件(Device Management Software，简称DMS)或基板管理控制器(Baseboard Management Controller，简称BMC)来执行。

DMS可负责主机上所有硬件的监控和管理，例如，一个承载DMS的服务器可管理多个节点设备上的硬件。BMC则多设置在承载被测设备的单节点设备中，用于对本节点设备进行管理，也可以通过错误寄存器来获取故障的严重级别以及相应的故障信息。DMS和BMC均可执行设备控制指令，来控制设备变更状态，典型的是执行设备的重启操作。通过DMS来控制多节点设备的上下电，尤其适用于故障注入控制装置通过网络对多个节点设备的被测设备进行故障注入测试。上述步骤120中向被测设备发送设备控制指令，以控制被测设备变更设备状态的操作可包括如下步骤：

通过DMS向所连接的一个或多个被测设备发送设备控制指令，以控制各被测设备变更设备状态；或

向一个或多个被测设备中的BMC发送设备控制指令，以控制各被测设备变更设备状态。

上述步骤110中所执行的向被测设备执行故障注入操作可以是执行软件故障注入，也可以是执行硬件故障注入，或者是分别执行两类故障注入。即步骤110具体包括：

基于被测设备的操作系统，通过故障注入客户端向被测设备发送故障参数，以进行软件故障注入操作；和/或

通过与被测设备端口相连的探针，向被测设备发送故障参数，以进行硬件故障注入操作。

由于本发明实施例的技术方案可通过控制设备的状态来使多次故障注入操作连续地执行，所以，对于软件故障注入和硬件故障注入，可以依次顺序执行。其中，软件故障注入操作的具体执行方式可以基于故障注入客户端来向被测设备的操作系统注入故障参数。当控制装置与被测设备建立连接后，若识别到被测设备的操作系统中没有故障注入模块，则可以首先向操作系统提供该软件的下载和安装，该故障注入模块可以被软件注入客户端软件调用。而后驱动故障注入客户端通过操作系统注入故障参数。硬件故障注入操作的具体执行方式基于被测设备上的硬件端口来实现物理连接，通过恶意修改被测设备的寄存器来达到触发故障的目的。例如可通过JTAG接口连接设备，JTAG接口一般用于对设备进行测试和调试，通过JTAG接口可以允许访问到IOH(Input Output Hub，输入输出集线器)上的任何寄存器以及连接在IOH上的南桥组件的任何寄存器。

上述技术方案能够将软件故障注入与硬件故障注入进行整合，简化故障注入工具，便于对容错计算机的进行整体容错性能评估。而且各次故障注入可以连续执行，无需手动逐一启动，因而可以简化故障注入操作，提高测试效率。

在上述实施例的基础上，进一步优选的是，在向被测设备执行故障注入操作之后，还获取从被测设备采集的故障注入反馈信息；并可以进一步对故障注入反馈信息进行分析和显示。基于前述技术方案，可实现多次故障注入操作的连续执行，所以优选是实时采集故障注入反馈信息，能及时且直观地获知各次故障注入操作的结果。

从被测设备采集故障注入反馈信息的操作可以通过与被测设备端口相连的探针，从被测设备采集故障注入反馈信息且同时接收与被测设备对应的设备管理软件或基板管理控制器上报的故障注入反馈信息。既可以通过硬件端口从设备的寄存器中采集状态参数，也包括采集设备的状态信息，作为故障注入反馈信息，且同时还可以通过管理软件来获取上报的故障注入反馈信息。

实施例二

图2为本发明实施例二提供的故障注入控制装置的结构示意图，该控制装置可由硬件和软件来实现，优选可用于执行本发明任意实施例提供的故障注入控制方法，具备相应的功能模块或硬件结构。该控制装置具体包括：故障注入模块210和设备控制模块220。其中，故障注入模块210用于向被测设备执行故障注入操作；设备控制模块220，用于当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

在上述技术方案的基础上，该故障注入控制装置还可包括信息反馈模块230，用于获取从被测设备采集的故障注入反馈信息，且当故障注入反馈信息为设备失效信息时，向设备控制模块下发设备控制指令。

故障注入反馈信息的采集途径可以有多种，通常，该控制装置可包括软件采集单元215和硬件采集单元214。软件采集单元215用于接收与被测设备对应的DMS或BMC上报的故障注入反馈信息，当故障注入反馈信息为设备失效信息时，向设备控制模块下发设备控制指令。硬件采集单元214用于通过与被测设备端口相连的探针，从被测设备的设备采集故障注入反馈信息，并提供给信息反馈模块230。

本实施例中，设备控制模块220具体包括DMS代理单元221。DMS代理单元221与信息反馈模块230相连，且通过DMS而与一个或多个被测设备相连，用于当信息反馈模块230获取到被测设备的设备失效信息时，接收信息反馈模块230下发的设备控制指令，并通过DMS向所连接的各被测设备发送设备控制指令，以控制各被测设备变更设备状态。该DMS代理单元221还用于接收被测设备上报的故障注入反馈信息，并上报给信息反馈模块230和软件采集单元215。

故障注入模块210可包括软件注入单元211和/或硬件注入单元212，本实施例以两种注入方式的实现单元均存在为例进行说明。软件注入单元211用于基于被测设备的操作系统，通过故障注入客户端向被测设备发送故障参数，以进行软件故障注入操作；硬件注入单元212用于通过与被测设备端口相连的探针，向被测设备发送故障参数，以进行硬件故障注入操作。

为实现智能化管理，该故障注入控制装置还包括注入管理模块240，用于根据输入的故障注入脚本形成顺序排列的待注入故障序列，并根据识别的故障注入脚本类型，将故障注入脚本依次提供给所述软件注入单元211或硬件注入单元212。

为配合网络中各设备系统的故障注入测试，还可在故障注入控制装置中设置网管模块250，与注入管理模块240和信息反馈模块230相连，用于向注入管理模块240下发故障注入脚本，且从信息反馈模块230获取故障注入反馈信息，并进行分析和显示。

下面基于上述完整架构的故障注入控制装置来详细介绍其工作过程。图3为本发明实施例二所提供故障注入控制装置适用的网络架构示意图，除图2所示故障注入控制装置之外，还包括多个被测设备310，各设备310的节点服务器管理网口均通过交换机320连接至承载DMS的DMS服务器330，来实现硬件管理，且一个或多个设备310的JTAG接口与硬件注入单元212通过探针213相连。被测设备中均安装有OS，软件注入单元211与被测设备的OS通过网络实现通信。

在故障注入控制装置中，网管模块250主要负责提供用户界面操作的接口，包括供用户选择故障注入脚本、输入故障注入脚本的停止/执行命令、解析并显示故障注入后系统的故障注入反馈信息等功能。

注入管理模块240(Inject Manager)主要负责选择故障注入脚本的路径，控制故障注入脚本的执行过程。例如，识别网管模块250提供的故障注入脚本为软件故障注入脚本还是硬件故障注入脚本，而后相应地提供给故障注入单元。

软件注入单元211(Software injector)主要负责软件故障注入，其与OS之间通过诸如局域网(Local Area Network，简称LAN)等网络进行通信，负责将软件故障注入脚本作为故障参数注入到OS中，并且当需要加载故障注入客户端时，为OS提供并加载故障注入模块。优选可以设置一软件代理模块270，在其中集成软件注入单元211和软件采集单元215。软件采集单元215用于接收与被测设备310对应的DMS或BMC上报的故障注入反馈信息，当故障注入反馈信息为设备失效信息时，向设备控制模块220下发设备控制指令。例如，当检测到与OS间的网络连接丢失或超时时，可直接向DMS代理单元221下发设备控制命令，然后再由DMS代理单元221向DMS服务器330下发设备控制命令，由DMS服务器330控制各设备310进行重启。

硬件注入单元212一般与探针213(Probe)配合，将从注入管理模块240获取的故障注入脚本作为故障参数注入到设备中。具体可以首先对故障注入脚本进行封装，封装成探针能够识别的信息再注入。优选可以设置一硬件代理模块260(Probe Agent)，在其中集成硬件注入单元212和硬件采集单元214，硬件采集单元214用于通过与被测设备310端口相连的探针213，从被测设备310采集故障注入反馈信息，并提供给信息反馈模块230。既通过探针213注入硬件故障，还可通过探针213基于硬件端口采集并解析设备的寄存器状态信息或状态信息，作为故障注入反馈信息提供给信息反馈模块230。

探针213一端通过JTAG接口与被测设备310连接，另一端则可通过例如通过通用串行总线(Universal Serial Bus，简称USB)与承载故障注入控制装置的PC进行通信，实际上是与PC上的硬件代理模块260进行通信，例如分别与硬件采集单元214和硬件注入单元212相互通信。探针213主要负责与被测设备310和硬件代理模块260进行通信，接收硬件代理模块260下发的故障注入脚本信息，将故障参数注入到被测设备310中，并且将硬件注入的结果及错误信息作为故障注入反馈信息返回给硬件代理模块260。

信息反馈模块230(Error Collector)主要负责收集DMS代理单元221和硬件代理模块260上报的故障注入反馈信息，且基于此使DMS代理单元221下发控制命令，并将整理后的故障注入反馈信息上报至网管模块250，信息反馈模块230会根据错误类型与级别，决定是否要向DMS代理单元221发送设备控制命令，例如设备重启指令等。

DMS代理单元221(DMS Agent)负责与DMS服务器330进行通信。可以在DMS服务器330上增加一个侦听器(Listener)，一旦当DMS服务器330收集到各设备310中BMC上报的故障注入反馈信息后，同样也将反馈信息发送到DMS代理单元221和软件采集单元215，然后由DMS代理单元221向信息反馈模块230上报故障注入反馈信息。

基于上述架构的故障注入控制装置，可分别执行整体故障注入循环流程、软件故障注入流程、重启流程和硬件故障注入流程。

其中，图4A所示为本发明实施例所提供故障注入控制装置执行的故障注入流程的流程图，该流程包括如下步骤：

步骤411、网管模块下发故障注入脚本至注入管理模块；

步骤412、注入管理模块对故障注入脚本进行解析，并且创建脚本注入队列，开始对故障注入脚本进行逐个注入，并如下所述进入脚本故障注入的循环；

步骤413、注入管理模块判断所有的故障注入脚本是否执行完，如果执行完毕，则结束整个故障注入循环，否则进入步骤414，即单个脚本故障注入流程；

步骤414、进入单个脚本故障注入流程，首先进行脚本执行准备，例如完成脚本信息格式转换等常规准备操作；

步骤415、判断故障注入脚本的类型是软件注入模式还是硬件注入模式，若为软件注入模式，则下发至软件注入单元，执行软件故障注入流程，如果是硬件注入模式，则下发至硬件注入单元，执行硬件故障注入流程；

步骤416、结束单个脚本故障注入流程，并回到步骤413。

图4B所示为本发明实施例所提供故障注入控制装置执行的软件故障注入流程的流程图，该流程包括如下步骤：

步骤421、软件故障注入流程开始；

步骤422、软件采集单元判断软件注入单元与OS之间是否建立通信，如果通信建立失败，相当于获取到设备失效状态信息，则下发设备重启指令，通知DMS代理单元进行重启，进入重启流程，若软件采集单元等待软件注入单元与OS间建立通信后，通过保活手段，例如心跳线，实时监测软件注入单元是否与OS保持通信连接，在通信建立成功的状态下，执行步骤423；

在上述重启流程之后，若重启成功，则判断是否返回软件故障注入流程，若是，则继续执行步骤423，否则本次故障注入流程结束。

步骤423、软件注入单元检查OS是否需要安装故障注入模块，如果已经安装，则直接向被测设备注入故障，执行步骤425；否则先执行步骤424；

步骤424、安装故障注入模块；

步骤425、进行软件故障注入操作；

步骤426、DMS服务器接收通过BMC上报的错误事件；

步骤427、DMS服务器将错误事件中记录的错误级别和相应的错误信息告知DMS代理单元，作为故障注入反馈信息；

步骤428、DMS代理单元再上报至信息反馈模块；

步骤429、此时信息反馈模块再告知硬件采集单元，让其收集硬件故障反馈信息；

步骤4210、硬件采集单元收集完成后，上报给信息反馈模块；

步骤4211、信息反馈模块根据收到的故障注入反馈信息进行整理，并将整理后的错误信息发送至网管模块；

步骤4212、同时，信息反馈模块根据收到的故障注入反馈信息进行评估，评估是否需要重启，如果需要重启，则由信息反馈模块向DMS代理单元下发设备重启指令，并执行步骤4213，否则，收集完故障注入反馈信息之后，本次的软件故障注入流程结束，返回整体故障注入循环流程；

步骤4213、DMS代理单元向DMS服务器发送设备重启指令，并可返回步骤422，等待设定时间以判断是否重启成功。

图4C所示为本发明实施例所提供故障注入控制装置执行的重启流程的流程图，该流程包括如下步骤：

步骤431、当接收到设备重启指令时，重启流程开始；

步骤432、DMS代理单元通知DMS服务器对设备进行重启操作；

步骤433、软件采集单元尝试与OS进行连接，并且每隔1s发起一次连接；

步骤434、软件采集单元监测连接建立是否成功，若是，则退出重启流程，并返回软件故障注入流程，如果连接建立失败的话，则执行步骤435；

步骤435、将连接耗时加1s，并更新当前连接耗时；

步骤436、软件采集单元判断连接花费时长是否超过预设的启动最大花费时间，如果超过则退出故障注入循环，并提示用户进行检查，结束本次故障注入流程；如果没有超时的话，则返回步骤433，继续循环执行重启流程。

图4D所示为本发明实施例所提供故障注入控制装置执行的硬件故障注入流程的流程图，该流程包括如下步骤：

步骤441、硬件故障注入流程开始；

步骤442、硬件注入单元进行故障注入前期准备，对注入管理模块的故障注入脚本进行封装，封装成探针能够识别的信息；

步骤443、硬件注入单元通过探针向被测设备进行故障注入；

步骤444、DMS服务器收到通过BMC上报的错误事件；

步骤445、DMS服务器将错误级别和相应的信息告知DMS代理单元，作为故障注入反馈信息；

步骤446、DMS代理单元再上报至信息反馈模块；

步骤447、信息反馈模块再告知硬件采集单元，让其收集硬件错误信息；

步骤448、硬件采集单元收集完成后，上报给信息反馈模块；

步骤449、信息反馈模块根据收到的故障注入反馈信息进行整理，并将整理后的故障注入反馈信息发送至网管模块；

步骤4410、同时，信息反馈模块根据收到的故障注入反馈信息进行评估，评估是否需要重启，如果需要重启，则由信息反馈模块通知DMS代理单元向DMS服务器发送设备重启指令，触发重启流程，否则当收集完成故障注入反馈信息之后，本次故障注入结束，返回整体故障注入循环流程。

上述过程为一优选实施方案，在整体故障注入循环流程中，分别触发执行软件故障注入流程、重启流程和硬件故障注入流程，以执行各类型故障注入的连续执行，且可控制设备以及能及时获取故障注入反馈的结果。

实施例三

图5为本发明实施例三提供的故障注入控制装置的结构示意图，本实施例与实施例二的区别在于，设备控制模块220优选包括基板管理代理单元222；基板管理代理单元222与信息反馈模块230相连，用于当信息反馈模块230获取到被测设备的设备失效信息时，接收信息反馈模块230下发的设备控制指令，向一个或多个被测设备中的BMC发送设备控制指令，以控制各被测设备变更设备状态。

图6为本发明实施例三所提供故障注入控制装置适用的网络架构示意图，本实施例和实施例二的区别在于由多个设备310的节点构成一个服务器，而每个设备310节点都有一个BMC 340，因此如果需要对整个服务器进行控制时，则可能需要基板管理代理单元222与多台设备310的BMC340进行连接，并且设备控制命令分别发送给各BMC 340。本实施例的其他操作流程与实施例二类似。

本发明各实施例的技术方案有效解决了现有技术中的缺陷，即当注入的故障设备无法处理而导致系统死机、OS无响应等现象时需要人为重启设备的缺陷。本发明实施例的可以直接对被测设备进行控制。故障注入控制装置能够对容错计算机进行控制，从而实现故障注入的自动化。

本发明实施例的技术方案还进一步可以将软件故障注入和硬件故障注入整合在一起，仅需要一次注入过程，较完整、全面地的评估容错计算机系统的整体容错性能。

通过采集故障注入反馈信息，可以形成错误日志，使故障注入效果可视化，通过故障注入控制装置的网管模块能够查看收集到的错误日志，并能够判断故障注入是否成功，相应的系统容错功能是否实现，系统当前重要参数(例如寄存器的值)，故障建议的修复动作等信息。

本发明实施例的技术方案可以适用于包括容错计算机、小型机、机架式服务器在内的任何分布式计算机系统，进行故障注入操作。可广泛应用于铁路、航空航天指挥系统等多领域的系统故障注入测试。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (15)

1.一种故障注入控制方法，其特征在于，包括：

向被测设备执行故障注入操作；

当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

2.根据权利要求1所述的故障注入控制方法，其特征在于，向被测设备发送设备控制指令，以控制被测设备变更设备状态包括：

通过设备管理软件向所连接的一个或多个被测设备发送设备控制指令，以控制各被测设备变更设备状态；或

向一个或多个被测设备中的基板管理控制器发送设备控制指令，以控制各被测设备变更设备状态。

3.根据权利要求1或2所述的故障注入控制方法，其特征在于，向被测设备发送设备控制指令，以控制被测设备变更设备状态包括：

向被测设备发送设备重启指令，以控制被测设备重新启动。

4.根据权利要求1或2所述的故障注入控制方法，其特征在于：所述被测设备的设备失效信息包括通信连接断开信息。

5.根据权利要求1或2所述的故障注入控制方法，其特征在于，在向被测设备执行故障注入操作之后，还包括：

获取从被测设备采集的故障注入反馈信息；

对故障注入反馈信息进行分析和显示。

6.根据权利要求5所述的故障注入控制方法，其特征在于，获取从被测设备采集的故障注入反馈信息包括：

通过与被测设备端口相连的探针，从被测设备采集故障注入反馈信息，且同时接收与被测设备对应的设备管理软件或基板管理控制器上报的故障注入反馈信息。

7.根据权利要求1或2所述的故障注入控制方法，其特征在于，向被测设备执行故障注入操作包括：

基于被测设备的操作系统，通过故障注入客户端向被测设备发送故障参数，以进行软件故障注入操作；和/或

通过与被测设备端口相连的探针，向被测设备发送故障参数，以进行硬件故障注入操作。

8.一种故障注入控制装置，其特征在于，包括：

故障注入模块，用于向被测设备执行故障注入操作；

设备控制模块，用于当获取到被测设备的设备失效信息时，向被测设备发送设备控制指令，以控制被测设备变更设备状态。

9.根据权利要求8所述的故障注入控制装置，其特征在于，还包括：

信息反馈模块，用于获取从被测设备采集的故障注入反馈信息，且当故障注入反馈信息为设备失效信息时，向设备控制模块下发设备控制指令。

10.根据权利要求9所述的故障注入控制装置，其特征在于，还包括：

软件采集单元，用于接收与被测设备对应的设备管理软件或基板管理控制器上报的故障注入反馈信息，当故障注入反馈信息为设备失效信息时，向设备控制模块下发设备控制指令；

硬件采集单元，用于通过与被测设备端口相连的探针，从被测设备的设备采集故障注入反馈信息，并提供给信息反馈模块。

11.根据权利要求9或10所述的故障注入控制装置，其特征在于，所述设备控制模块包括设备管理软件代理单元或基板管理代理单元；其中，

设备管理软件代理单元，与信息反馈模块相连，且通过设备管理软件而与一个或多个被测设备相连，用于当信息反馈模块获取到被测设备的设备失效信息时，接收信息反馈模块下发的设备控制指令，并通过设备管理软件向所连接的各被测设备发送设备控制指令，以控制各被测设备变更设备状态；

基板管理代理单元，与信息反馈模块相连，用于当信息反馈模块获取到被测设备的设备失效信息时，接收信息反馈模块下发的设备控制指令，向一个或多个被测设备中的基板管理控制器发送设备控制指令，以控制各被测设备变更设备状态。

12.根据权利要求11所述的故障注入控制装置，其特征在于：所述设备管理软件代理单元还用于接收被测设备上报的故障注入反馈信息，并上报给信息反馈模块和软件采集单元。

13.根据权利要求9或10所述的故障注入控制装置，其特征在于，故障注入模块包括：

软件注入单元，用于基于被测设备的操作系统，通过故障注入客户端向被测设备发送故障参数，以进行软件故障注入操作；和/或

硬件注入单元，用于通过与被测设备端口相连的探针，向被测设备发送故障参数，以进行硬件故障注入操作。

14.根据权利要求13所述的故障注入控制装置，其特征在于，还包括：

注入管理模块，用于根据输入的故障注入脚本形成顺序排列的待注入故障序列，并根据识别的故障注入脚本类型，将故障注入脚本依次提供给所述软件注入单元或硬件注入单元。

15.根据权利要求14所述的故障注入控制装置，其特征在于，还包括：

网管模块，与注入管理模块和信息反馈模块相连，用于向注入管理模块下发故障注入脚本，且从信息反馈模块获取故障注入反馈信息，并进行分析和显示。

Images