CN107332722A - 一种故障信息的排除方法及系统 - Google Patents

Abstract

本申请公开了一种故障信息的排除方法，包括：获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；从所述故障处理信息中提取具体处理数据，得到故障处理方案；依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。该排除方法为故障信息列举出所有具体的故障排除方案，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少存储系统异常停机时间过长所造成的损失。本申请还同时公开了一种故障信息的排除系统，具有上述有益效果。

Description

一种故障信息的排除方法及系统

技术领域

本申请涉及故障排除领域，特别涉及一种故障信息的排除方法及系统。

背景技术

随着互联网、大数据等技术的发展，存储系统作为一个必不可少的数据存储机制是研究的重点。

存储是一个复杂的系统，现有的存储系统基本都带有故障检测机制，通常是检测到发生故障后进行报错并记录日志。数据和业务的重要性使得存储系统对维护人员的要求较高，系统发生故障后通常需要具备一定专业知识的人员去排除故障。而在实际系统发生的故障当中，很大比例是可以通过插拔或者更换FRU(Field Replace Unit，现场可更换单元)可恢复的故障，如果每次都求助于专门的技术人员进行故障排除，即不利于简单故障的快速排除，同时高昂的现场服务费用也不利于公司成本控制。

所以，如何提供一种时效性更强、运维成本更低、故障排除方法更加灵活的故障信息排除机制是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种故障信息的排除方法及系统，其为故障信息列举出所有具体的故障排除方案，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少因存储系统异常所造成的损失。

为解决上述技术问题，本申请提供一种故障信息的排除方法，该排除方法包括：

获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；

从所述故障处理信息中提取具体处理数据，得到故障处理方案；

依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。

可选的，获取各底层模块运行过程中产生的故障信息，包括：

利用安装于各所述底层模块的驱动管理器进行参数采集，得到各所述底层模块运行过程中产生的实时参数；

判断所述实时参数是否处于预设范围内；

若否，则生成与所述实时参数相对应的故障信息。

可选的，利用所述故障信息和预设对应关系查得对应的故障处理信息，包括：

将所述故障信息按所述预设规则映射为故障事件；

利用所述故障事件和故障与对应的处理方法的对应关系，查得与所述故障事件对应的故障处理信息。

可选的，在从所述故障处理信息中提取具体处理数据，得到故障处理方案之后，还包括：

按照成本优先级的顺序对所述故障处理方案进行排序，得到故障排除优先顺序表。

可选的，在依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息之后，还包括：

记录所述故障信息被排除时使用的故障处理方案，得到故障处理日志；

在预设周期内利用所述故障处理日志统计所述故障信息被解决时各所述处理方案分别占的比例。

可选的，该排除方法还包括：

当所述故障被排除时，通过预设路径发送故障已排除的通知信息。

本申请还提供了一种故障信息的排除系统，该排除系统包括：

信息获取单元，用于获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；

数据提取单元，用于从所述故障处理信息中提取具体处理数据，得到故障处理方案；

故障排除单元，用于依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。

可选的，所述信息获取单元包括

实时参数获取子单元，用于利用安装于各所述底层模块的驱动管理器进行参数采集，得到各所述底层模块运行过程中的实时参数；

范围判断子单元，用于判断所述实时参数是否处于预设范围内；

故障信息生成子单元，用于生成与所述实时参数相对应的故障信息；

映射子单元，用于将所述故障信息按所述预设规则映射为故障事件；

故障处理信息查询子单元，用于利用所述故障事件和故障与对应的处理方法的对应关系，查得与所述故障事件对应的故障处理信息。

可选的，该排除系统还包括：

优先级排序单元，用于按照成本优先级的顺序对所述故障处理方案进行排序，得到故障排除优先顺序表。

可选的，该排除系统还包括：

日志记录单元，用于记录所述故障信息被排除时使用的故障处理方案，得到故障处理日志；

比例分析单元，用于在预设周期内利用所述故障处理日志统计所述故障信息被解决时各所述处理方案分别占的比例。

本申请所提供的一种故障信息的排除方法，通过获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；从所述故障处理信息中提取具体处理数据，得到故障处理方案；依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。

显然，本申请所提供的技术方案，首先根据故障信息查得对应的故障处理信息，接着从故障处理信息中得到包含的故障处理方案，依次按照故障处理方案进行故障排除操作，直至故障被排除。该排除方法为故障信息列举出所有具体的故障排除方案，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少存储系统异常停机时间过长所造成的损失。本申请同时还提供了一种故障信息的排除系统，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例所提供的一种故障信息的排除方法的流程图；

图2为本申请实施例所提供的另一种故障信息的排除方法的流程图；

图3为本申请实施例所提供的又一种故障信息的排除方法的流程图；

图4为本申请实施例所提供的一种故障信息的排除系统的结构框图；

图5为本申请实施例所提供的一种故障信息的排除方法的实际流程示意图；

图6为本申请实施例所提供的一种故障信息的排除系统中故障排除单元的实际流程示意图。

具体实施方式

本申请的核心是提供一种故障信息的排除方法及系统，其通过为故障信息列举出所有具体的故障排除方案，以此来指导工作人员进行故障排除，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少因存储系统异常所造成的损失。

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

以下结合图1，图1为本申请实施例所提供的一种故障信息的排除方法的流程图。

其具体包括以下步骤：

S101：获取各底层模块运行过程中产生的故障信息，并利用故障信息和预设对应关系查得对应的故障处理信息；

本步骤旨在从组成存储系统的各底层模块上获取到运行过程中产生的故障信息，并根据该故障信息和预设的对应关系查得对应的故障处理信息。

通常情况下存储系统会由数量众多的底层模块共同组成，这些底层模块根据需要可以灵活设置，并通过一种模块专门完成一种工作。其中，该故障信息的获取方式多种多样，例如，可以通过内置于各底层模块的驱动管理器实现该模块参数的采集，并据此进行判断；也可以利用设置在各模块上的各式传感器实现所需参数的采集；还可以利用该模块本身输出的参数结合一些专门的算法计算得到目的参数等等，此处并不作具体限定，应视实际情况结合模块型号、生产厂家以及设置习惯等各影响因素综合考虑。

在得到各底层模块根据采集到的参数，并判断出该参数是在该模块处于异常状态所产生的情况下，可以利用预设的对应关系根据获取到的故障信息查得对应的故障处理信息。

其中，该对应关系是提前预设好的，是根据形成存储系统的各底层模块及可能会存在的各种故障信息，为每个故障信息设定其专属的故障处理信息。该对应关系的表现方式也有很多，例如，将该一对一的对应关系置于对应表当中，便于利用一项查得另一项；还可以通过映射关系直接得到对应的一项等等，有时不同的故障信息可能对应同一故障处理信息，此处并不作具体限定，应视实际情况做出具体分析和选择。

该故障处理信息可以由很多信息组成，例如，故障处理方式简称、具体的故障处理方案、需要更换实体硬件的位置和型号等等，此处的故障处理信息可以尽可能的详细，以便于使用人员能够根据该故障处理信息自行排除一些简单的故障。

S102：从故障处理信息中提取具体处理数据，得到故障处理方案；

在S101的基础上，本步骤旨在从对应得到的故障处理信息中提取得到具体处理数据，得到故障处理方案。其中，根据S101中提及的故障处理信息所包含的各式内容，从中提取得到所需的具体的故障处理方案，同一故障的故障处理方案可能有多个，例如，就某个器件因高温而报故障，其对应的故障处理方案就可以为：(1)降温处理；(2)器件更换；(3)模组更换；(4)请专业的技术人员上门维修等多个方案，即多种方式均能解决同一问题。

同时，在具体的故障处理方案中可以包含具体的更换模组的型号、位置以及其它能够帮助维修人员进行故障排除的信息。进一步的，如同上面例子的各方案，不同方案的代价也不尽相同，维修难度也不一致，可以结合维修难度和维修成本进行综合考虑，设置得到方案优先级，例如，按照尽可能降低维修成本的原则，将多个故障处理方案按维修成本从低到高进行优先级排序；也可以按照其它排序方式，诸如故障排除速度、污染程度、损失程度等等，此处并不作具体限定。还可以将该方案优先级体现在顺序表或其它类似的信息中，以便于按照优先级读取得到第一故障处理方案。

更进一步的，即使按照预设的优先级设定了方案优先级顺序表，但实际情况往往可能较为特殊，例如，按第一优先级设定的方案需要较多人员进行大面积施工，但此时无法提供足够的维修人员，就还可以根据此时的维修人员结合特殊的实际情况，对优先级进行灵活调整。

当然，还存在其它方式可以实现优先级的设定和调整，此处并不作具体限定，应视实际情况下的设定方式、特殊要求等各影响因素综合考虑和制定。

S103：依次按照故障处理方案对产生故障信息的底层模块进行故障排除，直至排除故障信息。

在S102的基础上，本步骤旨在依次利用故障处理方案对产生该故障信息的底层模块尝试进行故障排除，直至成功将该故障信息排除。由于电子设备的集成化，各器件、模块间相互关联，有时反应出的故障信息虽对应着多种具体的故障处理方案，但表象一致的情况下其产生的原因可能不一致，故不确定哪种故障处理方案一定能够排除故障，所以本步骤通过每次尝试一种故障解决方案试图排除故障，直至该故障信息消失代表故障已经被排除。

可以通过一个较为形象的例子来说明，假设一个产生的故障信息对应着的具体的故障处理方案有三个，那么第一次尝试使用第一故障处理方案对故障进行排除，若该故障信息消失，则代表该故障已被第一故障处理方案排除；若该故障信息并未存在，说明该第一故障处理方案并未成功排除故障，此时使用第二故障处理方案对该故障进行排除，若该故障信息消失，则代表该故障已被第二故障处理方案排除；若该故障信息依然存在，说明该第二故障处理方案并未成功排除故障，此时使用第三故障处理方案对该故障进行排除，依次类推，直至该故障被排除。

若三个故障处理方案均未成功排除该故障，则可以请专业的技术人员进行故障排除，也可以直接将请专业技术人员进行故障排除设为一个故障处理方案，并在利用优先级进行故障处理方案的优先级排序时，可以将请专业技术人员进行故障排除这个故障处理方案放在最后的优先级顺序上，此处并不作具体限定，应视实际情况做出适应性修改。

进一步的，在该故障成功被排除后，还可以将具体使用的哪个故障处理方案排除了该故障记录下来，生成日志文件，以便于后续其它流程使用。更进一步的，还可以在预设周期内利用该日志文件记录的信息对同一故障被排除时所使用的方案各自出现的比例进行统计，以便于根据统计得到的数据对优先级进行调整，减少尝试的次数，优化故障排除机制。

更进一步的，由于故障排除时实际情况不可完全预料，还可以在该故障被成功排除时，按预设路径发送故障已排除的通知信息，以使维修人员快速确定故障排除状态，准备后续操作步骤。其中，该预设路径可以包括：邮件、即时通讯软件或其它社交沟通途径以及弹窗提示音等等，此处并不做具体限定，可以根据工作环境以及其它影响因素综合考虑和选择。

基于上述技术方案，本申请实施例提供的一种故障信息的排除方法，首先根据故障信息查得对应的故障处理信息，接着从故障处理信息中得到包含的故障处理方案，依次按照故障处理方案进行故障排除操作，直至故障被排除。该排除方法为故障信息列举出所有具体的故障排除方案，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少存储系统异常停机时间过长所造成的损失。

以下结合图2，图2为本申请实施例所提供的另一种故障信息的排除方法的流程图。

本实施例是针对上一实施例中S101中如何获取故障信息以及如何得到对应的故障处理信息所做出的一个具体限定，其它步骤与上一实施例大体相同，相同部分可参见上一实施例相关部分，在此不再赘述。

其具体包括以下步骤：

S201：利用安装于各底层模块的驱动管理器进行参数采集，得到各底层模块运行过程中产生的实时参数；

S202：判断实时参数是否处于预设范围内；

S203：生成与实时参数相对应的故障信息；

S201、S202以及S203旨在利用安装于各底层模块的驱动管理器实现所需参数的采集，并将采集得到的实时参数与预设范围进行比较，该预设范围包括该模块处于正常工作状态时可能会出现的所有参数，即所有未处于该预设范围的实时参数均可以被认定为是在该模块异常工作时生成的。在由该实时参数判断得到该模块工作异常后，则生成与该实时参数对应的故障信息。

故障信息中包含内容的相关描述可以参见实施例一中S101的描述，S101中的描述与本实施例大体相同，在此不再赘述。

S204：将故障信息按预设规则映射为故障事件；

S205：利用故障事件和故障与对应的处理方法的对应关系，查得与故障事件对应的故障处理信息。

S204和S205旨在利用预设规则首先将该故障信息映射为固定格式的故障事件，之所以存在这一步骤，是因为故障信息包括所有底层模块上可能存在的故障描述，表述长短不一、方法五花八门，不适合直接用于寻找对应的故障处理信息，故此处利用该预设规则将该故障信息映射为固定格式的故障时间，便于利用对应关系查得对应的故障处理信息。

能够实现此目的的方法有很多，例如可以利用哈希算法得到唯一对应的编码，或者利用常见的MD5算法得到特征值，并将该特征值作为该故障事件的表现等等，此处并不作具体限定，应视实际情况做出合适的选择。

以下结合图3，图3为本申请实施例所提供的又一种故障信息的排除方法的流程图。

本实施例是针对上一实施例中对故障处理方法又进行了何种处理以及其它增加内容所做出的描述，其它步骤与上一实施例大体相同，相同部分可参见上一实施例相关部分，在此不再赘述。

其具体包括以下步骤：

S301：从故障处理信息中提取具体处理数据，得到故障处理方案；

S302：按照成本优先级的顺序对故障处理方案进行排序，得到故障排除优先顺序表；

在S301的基础上，本步骤旨在按照本优先级的顺序对存在的所有故障处理方案进行成本优先级排序，得到故障排除优先顺序表。

S303：按照故障排除优先顺序表中对故障处理方案进行排序以此进行故障排除，直至故障信息被排除；

在S302的基础上，本步骤旨在利用生成的故障排除优先顺序表依次对故障进行排除，直至该故障信息消失、被排除。

S304：记录故障信息被排除时使用的故障处理方案，得到故障处理日志；

S305：在预设周期内利用故障处理日志统计故障信息被解决时各处理方案分别占的比例。

S304和S305与S104中部分内容相同，可以参见S104中相关内容，在此不再赘述。

基于上述技术方案，本申请实施例提供的一种故障信息的排除方法，首先根据故障信息查得对应的故障处理信息，接着从故障处理信息中得到包含的故障处理方案，并按照成本优先顺序对所有故障处理方案进行排除，以按照排序结果依次进行故障排除操作，直至故障被排除。该排除方法为故障信息列举出所有具体的故障排除方案，很大程度上无需求助专门的技术人员，使得故障排除方法更加灵活，时效性更强、运维成本更低，能够显著减少存储系统异常停机时间过长所造成的损失。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到更具本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图4，图4为本申请实施例所提供的一种故障信息的排除系统的结构框图。

该排除系统可以包括：

信息获取单元100，用于获取各底层模块运行过程中产生的故障信息，并利用故障信息和预设对应关系查得对应的故障处理信息；

数据提取单元200，用于从故障处理信息中提取具体处理数据，得到故障处理方案；

故障排除单元300，用于依次按照故障处理方案对产生故障信息的底层模块进行故障排除，直至排除故障信息。

其中，信息获取单元100可以包括：

实时参数获取子单元，用于利用安装于各底层模块的驱动管理器进行参数采集，得到各底层模块运行过程中的实时参数；

范围判断子单元，用于判断实时参数是否处于预设范围内；

故障信息生成子单元，用于生成与实时参数相对应的故障信息；

映射子单元，用于将故障信息按预设规则映射为故障事件；

故障处理信息查询子单元，用于利用故障事件和故障与对应的处理方法的对应关系，查得与故障事件对应的故障处理信息。

进一步的，该排除系统还可以包括：

优先级排序单元，用于按照成本优先级的顺序对故障处理方案进行排序，得到故障排除优先顺序表；

日志记录单元，用于记录故障信息被排除时使用的故障处理方案，得到故障处理日志；

比例分析单元，用于在预设周期内利用故障处理日志统计故障信息被解决时各处理方案分别占的比例；

通知信息发送单元，用于当故障被排除时，通过预设路径发送故障已排除的通知信息。

以上各单元可以应用于以下的一个具体的实际例子中，可以参见图5和图6，图5为本申请实施例所提供的一种故障信息的排除方法的实际流程示意图；图6为本申请实施例所提供的一种故障信息的排除系统中故障排除单元的实际流程示意图。

主要分为三个环节：

(1)故障检测环节：该环节主要有各个底层模块实现，如网卡驱动负责检测网络端口的链路状态，当有网口断开时上报网口断开故障；光纤卡驱动检测光纤端口的链路状态，当有光纤口断开时上报光纤端口断开故障。

(2)产生事件环节：错误检测环节检测到故障发生后，会将故障码(表明哪种故障，比如网口断开故障还是光纤口断开故障)和故障数据(故障补充信息，比如故障端口号)上报给相应的软件模块；该模块会将故障信息(包含故障码和故障数据)映射为事件，并按照该事件既定的错误数据格式解析错误数据，此外，每个事件关联相应的错误处理信息，每个错误处理信息包含下列信息，如图5所示：

(2.1)Error code(故障代码)：这里的Error code与上文所述的故障码的区别在于，故障码表明一种故障，而这里的error code对应一套故障处理方法。以IO卡举例，故障码可能为ETH_CARD_FAULT(网卡故障)或者FC_CARD_FAULT(FC卡故障)，由于每种卡的故障后处理方式相同，因此这两个故障码对应的Error Code可能同为CARD_REPLACE(卡更换)；

(2.2)Service action(服务动作)：描述每个Error Code对应的具体操作。例如对于端口断开故障，其Service action为(a)更换线缆；(b)更换IO卡；(c)联系技术支持人员；

(2.3)Real FRU list(确认FRU清单)：列出可能导致该故障的FRU；

(2.4)Error Code Text：Error code描述文本。

(3)理事件环节：该环节由管理软件的GUI模块实现，主要是将(2.2)中的serviceaction呈现在界面上，用于指导客户恢复故障。其流程如图6所示：GUI会将当前需要的操作展示在界面上，客户完成操作后点击界面的“已完成”按钮，设备会自动检查故障是否恢复，并根据故障是否恢复决定输出下一步操作指导或者结束流程。

以端口链路断开故障为例，由于链路断开可能是线缆有问题，也有可能是卡上的端口有问题，因此上述修复流程中Service Action1可能为“更换线缆”，客户完成线缆更换后点击界面上的“已完成”按钮，系统自动检查故障是否排除；若故障仍然存在，则输出Service Action2“更换接口卡”；客户完成操作后系统再次判断，若故障仍然存在，则输出Service Action3“联系技术支持人员处理”。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种故障信息的排除方法，其特征在于，包括：

获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；

从所述故障处理信息中提取具体处理数据，得到故障处理方案；

依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。

2.根据权利要求1所述的排除方法，其特征在于，获取各底层模块运行过程中产生的故障信息，包括：

利用安装于各所述底层模块的驱动管理器进行参数采集，得到各所述底层模块运行过程中产生的实时参数；

判断所述实时参数是否处于预设范围内；

若否，则生成与所述实时参数相对应的故障信息。

3.根据权利要求2所述的排除方法，其特征在于，利用所述故障信息和预设对应关系查得对应的故障处理信息，包括：

将所述故障信息按所述预设规则映射为故障事件；

利用所述故障事件和故障与对应的处理方法的对应关系，查得与所述故障事件对应的故障处理信息。

4.根据权利要求1至3任一项所述的排除方法，其特征在于，在从所述故障处理信息中提取具体处理数据，得到故障处理方案之后，还包括：

按照成本优先级的顺序对所述故障处理方案进行排序，得到故障排除优先顺序表。

5.根据权利要求4所述的排除方法，其特征在于，在依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息之后，还包括：

记录所述故障信息被排除时使用的故障处理方案，得到故障处理日志；

在预设周期内利用所述故障处理日志统计所述故障信息被解决时各所述处理方案分别占的比例。

6.根据权利要求5所述的排除方法，其特征在于，还包括：

当所述故障被排除时，通过预设路径发送故障已排除的通知信息。

7.一种故障信息的排除系统，其特征在于，包括：

信息获取单元，用于获取各底层模块运行过程中产生的故障信息，并利用所述故障信息和预设对应关系查得对应的故障处理信息；

数据提取单元，用于从所述故障处理信息中提取具体处理数据，得到故障处理方案；

故障排除单元，用于依次按照所述故障处理方案对产生所述故障信息的底层模块进行故障排除，直至排除所述故障信息。

8.根据权利要求7所述的排除系统，其特征在于，所述信息获取单元包括

实时参数获取子单元，用于利用安装于各所述底层模块的驱动管理器进行参数采集，得到各所述底层模块运行过程中的实时参数；

范围判断子单元，用于判断所述实时参数是否处于预设范围内；

故障信息生成子单元，用于生成与所述实时参数相对应的故障信息；

映射子单元，用于将所述故障信息按所述预设规则映射为故障事件；

故障处理信息查询子单元，用于利用所述故障事件和故障与对应的处理方法的对应关系，查得与所述故障事件对应的故障处理信息。

9.根据权利要求7或8所述的排除系统，其特征在于，还包括：

优先级排序单元，用于按照成本优先级的顺序对所述故障处理方案进行排序，得到故障排除优先顺序表。

10.根据权利要求9所述的排除系统，其特征在于，还包括：

日志记录单元，用于记录所述故障信息被排除时使用的故障处理方案，得到故障处理日志；

比例分析单元，用于在预设周期内利用所述故障处理日志统计所述故障信息被解决时各所述处理方案分别占的比例。