故障处理方法、装置、计算机设备和存储介质与流程

本申请涉及计算机应用领域，特别是涉及一种故障处理方法、装置、计算机设备和计算机存储介质。

背景技术：

随着计算机技术的发展，出现了运维技术。运行维护是对服务运行的状态进行监控，便于及时发现服务的运行异常和资源消耗的情况。当故障发生时，运维工程师对服务出现的任何异常进行及时处理，尽可能避免问题的扩大化甚至中止服务。并且运维工程师需要针对各类服务异常制定处理的预案，以便问题出现时可以手动执行预案达到止损的目的。

然而，目前的运维方式，存在自动化不足的问题。

技术实现要素：

基于此，有必要针对自动化不足的技术问题，提供一种能够减少告警风暴以及自动处理故障告警信息的故障处理方法、装置、计算机设备和计算机存储介质。

一种故障处理方法，该方法包括：获取故障告警信息；将该故障告警信息进行收敛处理，并转化成故障告警问题；根据该故障告警问题从数据库获取对应的故障处理规则；按照该故障处理规则进行故障处理。

在其中一个实施例中，在获取故障告警信息之前，还包括：获取故障告警问题和解决该故障告警问题的脚本；将该脚本拆分成子处理操作；重组该子处理操作形成故障处理规则；将该故障告警问题和该故障处理规则存储在该数据库中。

在其中一个实施例中，将该故障告警信息进行收敛处理，并转化成故障告警问题，包括：将在预设时间内出现的相同故障告警信息收敛成一条故障告警信息；将该故障告警信息转化成对应的故障告警问题。

在其中一个实施例中，根据该故障告警问题从数据库获取对应的故障处理规则包括：根据该故障告警问题匹配数据库中的故障告警问题；当该故障告警问题与该数据库中的故障告警问题匹配成功时，调用该数据库中的故障告警问题对应的数据库中的故障处理规则。

在其中一个实施例中，该方法还包括：当该故障告警问题与该数据库中的故障告警问题匹配失败时，上报该故障告警问题；根据该故障告警问题获取输入的故障处理规则；将该故障告警问题和该输入的故障处理规则对应存储在该数据库中。

在其中一个实施例中，根据该故障告警问题从数据库获取对应的故障处理规则，还包括：当该故障告警问题与该数据库中的故障告警问题匹配失败时，识别该故障告警问题得到故障子问题；根据该故障子问题匹配对应的故障处理规则；将该故障子问题对应的故障处理规则组成该故障告警问题对应的故障处理规则。

在其中一个实施例中，该数据库中的数据采用redis方式存储。

一种故障处理装置，该装置包括：获取模块，用于获取故障告警信息；用于根据该故障告警问题从数据库获取对应的故障处理规则；转化模块，用于将该故障告警信息进行收敛处理，并转化成故障告警问题；处理模块，用于按照该故障处理规则进行故障处理。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：获取故障告警信息；将该故障告警信息进行收敛处理，并转化成故障告警问题；根据该故障告警问题从数据库获取对应的故障处理规则；按照该故障处理规则进行故障处理。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：获取故障告警信息；将该故障告警信息进行收敛处理，并转化成故障告警问题；根据该故障告警问题从数据库获取对应的故障处理规则；按照该故障处理规则进行故障处理。

上述故障处理方法、装置、计算机设备和存储介质，通过获取故障告警信息并对该信息进行收敛处理，能有效减少告警风暴，避免重复接收告警信息，节省故障处理时间和占用的存储资源；将故障告警信息转化成故障告警问题，根据该故障告警问题获取故障处理规则，并进行故障处理，能解决自动化不足的问题，自动处理故障告警信息。

附图说明

图1为一个实施例中故障处理方法的应用环境图；

图2为一个实施例中故障处理方法的流程示意图；

图3为一个实施例中故障处理规则生成的流程示意图；

图4为另一个实施例中故障处理方法的流程示意图；

图5为又一个实施例中故障处理方法的流程示意图；

图6为再一个实施例中故障处理方法的流程示意图；

图7为另一个实施例中故障处理方法的应用场景图；

图8为一个实施例中故障处理装置的结构框图；

图9为另一个实施例中故障处理装置的结构框图；

图10为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的故障处理方法，可以应用于如图1所示的应用环境中。其中，第一服务器102通过网络与第二服务器104通过网络进行通信。其中，第一服务器102和第二服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现，并且第一服务器102可以是异构数据库系统，该异构数据库系统是相关的多个数据库系统的集合，可以实现数据的共享和透明访问。异构数据库的各个组成部分具有自身的自治性，实现数据共享的同时，每个数据库系统仍保有自己的应用特性、完整性控制和安全性控制。

在一个实施例中，如图2所示，提供了一种故障处理方法，以该方法应用于图1中的第二服务器104为例进行说明，包括以下步骤：

步骤202，获取故障告警信息。

其中，故障告警信息是指当第一服务器102发生故障时产生的故障告警信息。该故障告警信息可包括服务器宕机、服务异常停止、磁盘空间不够和服务器ping不通等。

具体地，第二服务器104从第一服务器102获取当第一服务器102发生故障时产生的故障告警信息。第二服务器104包括前置接收器，该前置接收器提供接口，用于自动拉取或接收其他告警信息源，接收告警信息源中的故障告警信息，并将故障告警信息推送至故障转化器。

其中，该告警信息源包括zabbix、open-falcon、naglos和cmdb(configurationmanagementdatabase，配置管理数据库)等，该告警信息源用于监视网络系统、终端、数据库、服务和进程等。

zabbix是一种提供分布式系统监视以及网络监视功能的企业级的开源解决方案，能监视各种网络参数，保证服务器系统的安全运营。

open-falcon是一款企业级、高可用、可扩展的开源监控解决方案。

naglos是一种开源的电脑系统和网络监视工具，能有效监控windows系统、linux系统和unix系统的主机状态。

其中，linux系统是一套类unix操作系统，是一个多用户端、多任务、支持多线程和多cpu(centralprocessingunit，中央处理器)的操作系统。

unix操作系统，是一个强大的多用户端、多任务操作系统，支持多种处理器架构，按照操作系统的分类，属于分时操作系统。

cmdb(configurationmanagementdatabase，配置管理数据库)用于存储与管理企业架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值。

通过从不同的告警信息源中获取故障告警信息，能保证故障告警信息的一致性以及准确性，减少数据的冗余，不需要将该故障告警信息存放于第二服务器104中的不同地方，减少管理成本。

步骤204，将该故障告警信息进行收敛处理，并转化成故障告警问题。

其中，收敛处理指的是将相同的故障告警信息收敛成一条故障告警信息。

具体地，第二服务器104将从第一服务器102获取的相同的故障告警信息收敛成同一条故障告警信息，并转化成与故障告警信息对应的故障告警问题。

步骤206，根据该故障告警问题从数据库获取对应的故障处理规则。

其中，故障处理规则指的是解决该故障告警问题的方案。

具体地，第二服务器104根据故障告警问题从数据库中获取已存储的解决该故障告警问题的方案，该数据库可以位于第二服务器104中，也可以独立于第二服务器104。

步骤208，按照该故障处理规则进行故障处理。

具体地，第二服务器104按照从数据库中获取的故障处理规则对该故障处理问题进行故障处理。

本实施例中，当前置接收器收到“zabbix告警系统出现了应用服务器宕机的情况，大量ping不可达消息”的故障告警信息，故障转化器将该故障告警信息转化为“服务器ping故障”，调用数据库中的故障处理规则，执行“重启服务器”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到服务异常停止的故障告警问题时，调用数据库中的故障处理规则，执行“重启服务”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到磁盘空间不足或性能问题的故障告警问题时，则调用数据库中的故障处理规则，执行“清理日志文件及杀进程”脚本，按照该故障处理规则进行故障处理。

本实施例中，完成故障处理后，第二服务器104还可以实时反馈故障处理结果给用户端，方便进行二次核对处理。

上述故障处理方法中，通过获取故障告警信息并对该信息进行收敛处理，能有效减少告警风暴，避免重复接收告警信息，节省故障处理时间和占用的存储资源；将故障告警信息转化成故障告警问题，根据该故障告警问题获取故障处理规则，并进行故障处理，能解决自动化不足的问题，自动处理故障告警信息。

在一个实施例中，如图3所示，在获取故障告警信息之前，该故障处理方法还包括：

步骤302，获取故障告警问题和解决该故障告警问题的脚本。

其中，解决该故障告警问题的脚本即为解决该故障告警问题的解决方案。

具体地，第二服务器104获取用户端输入的或者从其他终端或系统导入的故障告警问题和解决该故障告警问题的脚本。

步骤304，将该脚本拆分成子处理操作。

其中，子处理操作指的是该脚本中的处理步骤，该处理步骤对应解决一个基础问题，也是最小的故障处理单位。

具体地，第二服务器104将该解决故障告警问题的脚本拆成单个的子处理操作。

本实施例中，在运维技术领域中，大部分操作可以通过执行脚本完成。第二服务器104将每个脚本的子处理操作作为原子，将大量的子处理操作存储在原子库中，该原子库位于第二服务器104中。

步骤306，重组该子处理操作形成故障处理规则。

具体地，第二服务器104通过重组该脚本中的处理步骤形成解决该故障告警问题的方案。

本实施例中，第二服务器104可以从原子库中获取该子处理操作，形成脚本处理的步骤，通过对应故障处理问题，调度所需要的子处理操作，编排成故障处理规则。在整个过程中，很多原子是可以重用的，所以针对特定的故障告警问题，可以在原子库中将所需要的原子组合成故障处理规则。

步骤308，将该故障告警问题和该故障处理规则对应存储在该数据库中。

具体地，第二服务器104将该故障告警问题和解决该故障告警问题的故障处理规则一一对应存储在该数据库中。该数据库还用于保存配置信息，故障处理的执行日志等内容。

本实施例中，第二服务器104将该故障告警问题存储为故障告警表的形式但不限于此，同时定义故障处理规则表，配置好故障告警问题与故障处理规则的对应关系后，将该故障告警问题和该故障处理规则对应存储在该数据库中。

上述故障处理方法中，通过获取故障告警问题和解决该问题的方案，将脚本拆分成子处理操作以解决基础问题，且该子处理操作可以重复使用；再通过重组该子处理操作形成不同的故障处理规则，可以减少占用空间，并且解决更多的故障告警问题，节省编写时间以及响应时间，而不需每个故障告警问题都重新编写一次脚本；将故障告警问题和故障处理规则对应存储在数据库中，使得调用更加迅速、直观。

在一个实施例中，将该故障告警信息进行收敛处理，并转化成故障告警问题，包括：将在预设时间内出现的相同故障告警信息收敛成一条故障告警信息；将该故障告警信息转化成对应的故障告警问题。

其中，故障告警信息是指预设时间为0至24小时但不限于此，本实施例中以5分钟作为预设时间。

具体地，第二服务器104将在预设时间内即5分钟内但不限于5分钟的相同的故障告警信息收敛合并成同一条故障告警信息，并通过故障转化器将该故障告警信息转化为与该故障告警信息对应的故障告警问题。

本实施例中，当前置告警器接收到第一服务器102发送的“告警系统出现了应用服务器宕机情况，大量的ping不可达消息”的故障告警信息，在5分钟内出现几百条告警，则造成了告警风暴。实际上该告警风暴是同一个问题，通过对该告警信息的收敛处理，则第二服务器104可以只接收到一条故障告警信息。故障转化器将该故障告警信息转化为“服务器ping故障”，并从数据库中调用该“服务器ping故障”对应的故障告警规则例如“重启服务器”的脚本以解决该“服务器ping故障”的问题。

本实施例中，故障转化器内还有故障类别库，包括：可直接处理类、提醒后处理类和需人工介入处理类。具体地，当该故障告警问题已存储在数据库中，则该故障告警问题归入可直接处理类；当该故障告警问题为较复杂的故障告警问题，不能立刻解决，则将该故障告警问题归入提醒后处理类；当该故障告警问题为新型的故障告警问题且无法立即解决时，将该故障告警问题归入需人工介入处理类。

上述故障处理方法中，通过将相同的故障告警信息收敛成同一条故障告警信息，减少了告警风暴，避免重复接收告警信息，能节省故障处理时间和占用的存储资源。

在一个实施例中，根据该故障告警问题从数据库获取对应的故障处理规则包括：根据该故障告警问题匹配数据库中的故障告警问题；当该故障告警问题与该数据库中的故障告警问题匹配成功时，调用该数据库中的故障告警问题对应的数据库中的故障处理规则。

具体地，第二服务器104根据故障告警问题从数据库中的故障告警问题表中匹配故障告警问题，当匹配成功时，从数据库中的故障处理规则表中调用该故障处理问题对应的故障处理规则。

上述故障处理方法中，通过根据故障处理问题查找数据库中的故障处理问题，并调用故障处理规则，能够达到故障自愈的效果，并且故障响应迅速，减少人工操作的失误率。

在一个实施例中，如图4所示，该故障处理方法还包括：

步骤402，当该故障告警问题与该数据库中的故障告警问题匹配失败时，上报该故障告警问题。

具体地，当第二服务器104中的故障告警问题无法与数据库中的故障告警问题匹配时，第二服务器104上报该故障告警问题。

步骤404，根据该故障告警问题获取输入的故障处理规则。

具体地，用户端根据该故障告警问题创建该故障告警问题对应的故障处理规则，并将该故障处理规则上传至第二服务器104，第二服务器104获取该用户端输入的故障处理规则。

步骤406，将该故障告警问题和该输入的故障处理规则对应存储在该数据库中。

具体地，第二服务器104将该故障告警问题按照故障告警问题表的形式但不限于此与该输入的故障处理规则对应存储在数据库中。

上述故障处理方法中，通过获取输入的故障处理规则，能有效解决数据库中无法解决的故障告警问题，将故障告警问题和对应的故障处理规则存储在数据库中，扩大数据库的存储量，并且能加强数据库解决问题的能力。

在一个实施例中，如图5所示，根据该故障告警问题从数据库获取对应的故障处理规则，还包括：

步骤502，当该故障告警问题与该数据库中的故障告警问题匹配失败时，识别该故障告警问题得到故障子问题。

其中，故障子问题指的是该故障告警问题中的较小单位，即该故障告警问题可以被拆分为多个故障子问题。

具体地，当该故障告警问题与该数据库中的故障告警问题匹配失败时，即数据库中未储存该故障告警问题时，第二服务器104识别该故障告警问题，得到两个或多个故障子问题。

步骤504，根据该故障子问题匹配对应的故障处理规则。

具体地，第二服务器104根据该故障告警问题拆分出的故障子问题与数据库中的故障告警问题进行匹配，若匹配成功则调用该故障子问题对应的故障处理规则。

步骤506，将该故障子问题对应的故障处理规则组成该故障告警问题对应的故障处理规则。

具体地，第二服务器104将该故障子问题对应的故障处理规则按照故障子问题分解时对应的顺序一一将该故障子问题对应的故障处理规则排列整齐，得到该故障告警问题对应的故障处理规则。

上述故障处理方法中，通过将故障告警问题拆分为两个或多个对应的故障子问题，能细化解决故障告警问题的步骤，同时不用再次编写该故障告警问题对应的故障告警规则，节省了时间和减少了占用的资源。

在一个实施例中，该数据库中的数据采用redis方式存储。

其中，redis是一个存储系统，它会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现主从同步。

具体地，由于故障告警信息并非结构化数据，需要通过非结构化存储引擎存储，并且需要清洗及计算处理成故障告警问题，则需要缓存高速处理，故采用redis存储。

在一个实施例中，该故障处理方法采用插件管理。每个告警信息源对应一个故障告警插件，则当告警信息源改变时，例如从zabbix告警信息源变成了open-falcon告警信息源，则通过重新配置前置接收器中的适配器接口即可进行故障处理。上述故障处理方法，通过从采用插件管理的方式，可以适配多种告警信息源，增强可扩展性。

在一个实施例中，该故障处理方法还包括通过管控控制台提供系统管理界面，通过该系统管理界面进行系统调控和插件的配置。

在一个实施例中，如图6所示，提供了一种故障处理方法，包括以下步骤：

步骤602，获取故障告警问题和解决该故障告警问题的脚本。

具体地，第二服务器104获取用户端输入的或者从其他终端或系统导入的故障告警问题和解决该故障告警问题的脚本。

步骤604，将该脚本拆分成子处理操作。

具体地，第二服务器104将该解决故障告警问题的脚本拆成单个的子处理操作。

本实施例中，第二服务器104将每个脚本的子处理操作细化成原子，将大量的子处理操作存储在原子库中，该原子库位于第二服务器104中的数据库中。

步骤606，重组该子处理操作形成故障处理规则。

具体地，第二服务器104通过重组该脚本中的处理步骤形成解决该故障告警问题的方案。

本实施例中，第二服务器104可以从原子库中获取该子处理操作，形成脚本处理的步骤，通过对应故障处理问题，调度所需要的子处理操作，编排成故障处理规则。在整个过程中，很多原子是可以重用的，所以针对特定的故障告警问题，可以在原子库中将所需要的原子组合成故障处理规则。

步骤608，将该故障告警问题和该故障处理规则对应存储在该数据库中。

具体地，第二服务器104将该故障告警问题和解决该故障告警问题的故障处理规则一一对应存储在该数据库中。该数据库还用于保存配置信息，故障处理的执行日志等内容。

本实施例中，第二服务器104将该故障告警问题存储为故障告警表的形式但不限于此，同时定义故障处理规则表，配置好故障告警问题与故障处理规则的对应关系后，将该故障告警问题和该故障处理规则对应存储在该数据库中。

步骤610，从告警信息源获取故障告警信息。

具体地，第二服务器104从第一服务器102获取当第一服务器102发生故障时产生的故障告警信息。第二服务器104包括前置接收器，该前置接收器提供接口，用于接收自动拉取或接受其他告警信息源，该告警信息源包括zabbix、open-falcon、naglos和cmdb等，该告警信息源可用于监视网络系统、终端、数据库、服务和进程等。第二服务器104接收告警信息源中的故障告警信息，并将故障告警信息推送至故障转化器。

步骤612，将该故障告警信息进行收敛处理，并转化成故障告警问题。

具体地，第二服务器104将从第一服务器102获取的相同的故障告警信息收敛成同一条故障告警信息，并通过故障转化器转化成与故障告警信息对应的故障告警问题。

本实施例中，当前置告警器接收到第一服务器102发送的“告警系统出现了应用服务器宕机情况，大量的ping不可达消息”的故障告警信息，在5分钟内出现几百条告警，则造成了告警风暴。实际上该告警风暴是同一个问题，通过对该告警信息的收敛处理，则第二服务器104可以只接收到一条故障告警信息。故障转化器将该故障告警信息转化为“服务器ping故障”，并从数据库中调用该“服务器ping故障”对应的故障告警规则例如“重启服务器”的脚本以解决该“服务器ping故障”的问题。

本实施例中，故障转化器内还有故障类别库，包括：可直接处理类、提醒后处理类和需人工介入处理类。具体地，当该故障告警问题已存储在数据库中，则该故障告警问题归入可直接处理类；当该故障告警问题为较复杂的故障告警问题，不能立刻解决，则将该故障告警问题归入提醒后处理类；当该故障告警问题为新型的故障告警问题且无法立即解决时，将该故障告警问题归入需人工介入处理类。

步骤614，根据该故障告警问题从数据库获取对应的故障处理规则。

具体地，第二服务器104根据故障告警问题从数据库中的故障告警问题表中匹配故障告警问题，当匹配成功时，从数据库中的故障处理规则表中调用该故障处理问题对应的故障处理规则。

本实施例中，当第二服务器104中的故障告警问题无法与数据中的故障告警问题匹配时，第二服务器104上报该故障告警问题。用户端根据该故障告警问题创建该故障告警问题对应的故障处理规则，并将该故障处理规则上传至第二服务器104，第二服务器104获取该用户端输入的故障处理规则，并该故障告警问题按照故障告警问题表的形式但不限于此与该输入的故障处理规则对应存储在数据库中。

本实施例中，当该故障告警问题与该数据库中的故障告警问题匹配失败时，即数据库中未储存该故障告警问题时，第二服务器104识别该故障告警问题，得到两个或多个故障子问题。第二服务器104根据该故障告警问题拆分出的故障子问题与数据库中的故障告警问题进行匹配，若匹配成功则调用该故障子问题对应的故障处理规则。第二服务器104将该故障子问题对应的故障处理规则按照故障子问题分解时对应的顺序一一将该故障子问题对应的故障处理规则排列整齐，得到该故障告警问题对应的故障处理规则。

步骤616，按照该故障处理规则进行故障处理。

具体地，第二服务器104按照从数据库中获取的故障处理规则对该故障处理问题进行故障处理。

本实施例中，当前置接收器收到“zabbix告警系统出现了应用服务器宕机的情况，大量ping不可达消息”的故障告警信息，故障转化器将该故障告警信息转化为“服务器ping故障”，调用数据库中的故障处理规则，执行“重启服务器”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到服务异常停止的故障告警问题时，调用数据库中的故障处理规则，执行“重启服务”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到磁盘空间不足或性能问题的故障告警问题时，则调用数据库中的故障处理规则，执行“清理日志文件及杀进程”脚本，按照该故障处理规则进行故障处理。

本实施例中，完成故障处理后，第二服务器104还可以实时反馈故障处理结果给用户端，方便进行二次核对处理。

本实施例中，该故障处理方法还包括通过管控控制台提供系统管理界面，通过该系统管理界面进行系统调控和插件的配置。

在一个实施例中，以该故障处理方法应用于图7中的应用场景为例进行说明。第二服务器104包括前置接收器、故障解释器、处理器以及数据库，该数据库中还包括原子库。

具体地，第二服务器104从前置接收器拉取或接受告警信息源，从告警信息源中接收故障告警信息，将该故障告警信息呈队列推送至故障转化器。故障转化器将故障告警信息收敛成同一条故障告警信息，并转化成与故障告警信息对应的故障告警问题。处理器根据从数据库中获取的故障处理规则对该故障告警问题进行处理。该数据库内有原子库，原子库用于存储子处理操作。该数据库还用于保存模板内容、配置信息、执行日志等。另外，管控控制台用于提供系统管理界面，通过该界面调系统和插件配置。

本实施例中，当前置接收器收到“zabbix告警系统出现了应用服务器宕机的情况，大量ping不可达消息”的故障告警信息，故障转化器将该故障告警信息转化为“服务器ping故障”，处理器调用数据库中的故障处理规则，执行“重启服务器”脚本，按照该故障处理规则进行故障处理。

本实施例中，当告警信息源改变时，例如从zabbix告警源变成了open-falcon告警源，则通过重新配置前置接收器中的适配器接口即可进行故障处理。

应该理解的是，虽然图2-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-6中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图8所示，提供了一种故障处理装置，包括：获取模块802、转化模块804和处理模块806，其中：

获取模块802，用于获取故障告警信息；还用于根据所述故障告警问题从数据库获取对应的故障处理规则。

具体地，获取模块802用于从第一服务器102获取当第一服务器102发生故障时产生的故障告警信息，自动拉取或接受其他告警信息源，接收告警信息源中的故障告警信息，并将故障告警信息推送至故障转化器。其中，该告警信息源包括zabbix、open-falcon、naglos和cmdb等，该告警信息源用于监视网络系统、终端、数据库、服务和进程等。

具体地，获取模块802还用于根据故障告警问题从数据库中获取已存储的解决该故障告警问题的方案。

转化模块804，用于将所述故障告警信息进行收敛处理，并转化成故障告警问题。

具体地，转化模块804用于将从第一服务器102获取的相同的故障告警信息收敛成同一条故障告警信息，并转化成与故障告警信息对应的故障告警问题。

处理模块806，用于按照所述故障处理规则进行故障处理。

具体地，处理模块806用于按照从数据库中获取的故障处理规则对该故障处理问题进行故障处理。

本实施例中，当前置接收器收到“zabbix告警系统出现了应用服务器宕机的情况，大量ping不可达消息”的故障告警信息，故障转化器将该故障告警信息转化为“服务器ping故障”，处理模块806用于调用数据库中的故障处理规则，执行“重启服务器”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到服务异常停止的故障告警问题时，处理模块806用于调用数据库中的故障处理规则，执行“重启服务”脚本，按照该故障处理规则进行故障处理。

本实施例中，当第二服务器104接收到磁盘空间不足或性能问题的故障告警问题时，则处理模块806用于调用数据库中的故障处理规则，执行“清理日志文件及杀进程”脚本，按照该故障处理规则进行故障处理。

本实施例中，完成故障处理后，处理模块806可以用于实时反馈故障处理结果给用户端，方便进行二次核对处理。

在一个实施例中，如图9所示，该故障处理装置还包括拆分模块808、重组模块810和存储模块812，各模块间并不严格按照图9的顺序执行。其中，在获取模块802获取故障告警问题信息之前，还用于获取故障告警问题和解决该故障告警问题的脚本。

具体地，获取模块802用于获取用户端输入的或者从其他终端或系统导入的故障告警问题和解决该故障告警问题的脚本。

拆分模块808，用于将该脚本拆分成子处理操作。具体地，拆分模块808用于将该解决故障告警问题的脚本拆成单个的子处理操作。本实施例中，拆分模块808还用于将每个脚本的子处理操作细化成原子，将大量的子处理操作存储在原子库中。

重组模块810，用于重组该子处理操作形成故障处理规则。具体地，重组模块810用于通过重组该脚本中的处理步骤形成解决该故障告警问题的方案。

本实施例中，重组模块810用于从原子库中获取该子处理操作，形成脚本处理的步骤，通过对应故障处理问题，调度所需要的子处理操作，编排成故障处理规则。

存储模块812，用于将该故障告警问题和该故障处理规则对应存储在该数据库中。具体地，存储模块812用于将该故障告警问题和解决该故障告警问题的故障处理规则一一对应存储在该数据库中。该数据库中的数据采用redis存储装置。具体地，由于故障告警信息并非结构化数据，需要通过非结构化存储引擎存储，并且需要清洗及计算处理成故障告警问题，则需要缓存高速处理，故采用redis存储装置进行存储。本实施例中，存储模块812用于将该故障告警问题存储为故障告警表的形式但不限于此，同时定义故障处理规则表，配置好故障告警问题与故障处理规则的对应关系后，将该故障告警问题和该故障处理规则对应存储在该数据库中。

在一个实施例中，转化模块804还用于将在预设时间内出现的相同故障告警信息收敛成一条故障告警信息；将该故障告警信息转化成对应的故障告警问题。

具体地，转化模块804还用于将在预设时间内即5分钟内但不限于5分钟的相同的故障告警信息收敛合并成同一条故障告警信息，并通过故障转化器将该故障告警信息转化为与该故障告警信息对应的故障告警问题。

本实施例中，当获取模块802接收到第一服务器102发送的“告警系统出现了应用服务器宕机情况，大量的ping不可达消息”的故障告警信息，在5分钟内出现几百条告警，则造成了告警风暴。实际上该告警风暴是同一个问题，转化模块804还用于通过对该多条故障告警信息的收敛处理转化为一条故障告警信息。转化模块804还用于将该故障告警信息转化为“服务器ping故障”。

本实施例中，转化模块804还用于将故障分类，该分类包括：可直接处理类、提醒后处理类和需人工介入处理类。具体地，当该故障告警问题已存储在数据库中，则转化模块804还用于将该故障告警问题归入可直接处理类；当该故障告警问题为较复杂的故障告警问题，不能立刻解决，则转化模块804还用于将该故障告警问题归入提醒后处理类；当该故障告警问题为新型的故障告警问题且无法立即解决时，转化模块804还用于将该故障告警问题归入需人工介入处理类。

在一个实施例中，获取模块802还用于根据该故障告警问题匹配数据库中的故障告警问题；当该故障告警问题与该数据库中的故障告警问题匹配成功时，调用该数据库中的故障告警问题对应的数据库中的故障处理规则。

具体地，获取模块802还用于根据故障告警问题从数据库中的故障告警问题表中匹配故障告警问题，当匹配成功时，从数据库中的故障处理规则表中调用该故障处理问题对应的故障处理规则表。

在一个实施例中，获取模块802还用于当该故障告警问题与该数据库中的故障告警问题匹配失败时，上报该故障告警问题；根据该故障告警问题获取输入的故障处理规则；将该故障告警问题和该输入的故障处理规则对应存储在该数据库中。

具体地，当故障告警问题无法与数据库中的故障告警问题匹配时，获取模块802还用于上报该故障告警问题，获取用户端输入的该故障告警问题对应的故障处理规则，并将该故障处理规则对应存储在数据库中。

在一个实施例中，获取模块802还用于当该故障告警问题与该数据库中的故障告警问题匹配失败时，识别该故障告警问题得到故障子问题；根据该故障子问题匹配对应的故障处理规则；将该故障子问题对应的故障处理规则组成该故障告警问题对应的故障处理规则。

具体地，当该故障告警问题与该数据库中的故障告警问题匹配失败时，即数据库中未储存该故障告警问题时，获取模块802还用于识别该故障告警问题，得到两个或多个故障子问题并根据该故障告警问题拆分出的故障子问题与数据库中的故障告警问题进行匹配，若匹配成功则调用该故障子问题对应的故障处理规则。获取模块802还用于将该故障子问题对应的故障处理规则按照分解时对应的顺序一一将该故障子问题对应的故障处理规则排列整齐，得到该故障告警问题对应的故障处理规则。

关于故障处理装置的具体限定可以参见上文中对于故障处理方法的限定，在此不再赘述。上述故障处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图10所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储故障处理数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种故障处理方法。

本领域技术人员可以理解，图10中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：获取故障告警信息；将该故障告警信息进行收敛处理，并转化成故障告警问题；根据该故障告警问题从数据库获取对应的故障处理规则；按照该故障处理规则进行故障处理。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：获取故障告警问题和解决该故障告警问题的脚本；将该脚本拆分成子处理操作；重组该子处理操作形成故障处理规则；将该故障告警问题和该故障处理规则存储在该数据库中。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：将在预设时间内出现的相同故障告警信息收敛成一条故障告警信息；将该故障告警信息转化成对应的故障告警问题。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据该故障告警问题匹配数据库中的故障告警问题；当该故障告警问题与该数据库中的故障告警问题匹配成功时，调用该数据库中的故障告警问题对应的数据库中的故障处理规则。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：当该故障告警问题与该数据库中的故障告警问题匹配失败时，上报该故障告警问题；根据该故障告警问题获取输入的故障处理规则；将该故障告警问题和该输入的故障处理规则对应存储在该数据库中。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：当该故障告警问题与该数据库中的故障告警问题匹配失败时，识别该故障告警问题得到故障子问题；根据该故障子问题匹配对应的故障处理规则；将该故障子问题对应的故障处理规则组成该故障告警问题对应的故障处理规则。

在一个实施例中，该数据库中的数据采用redis方式存储。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：将该故障告警信息进行收敛处理，并转化成故障告警问题；根据该故障告警问题从数据库获取对应的故障处理规则；按照该故障处理规则进行故障处理。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：获取故障告警问题和解决该故障告警问题的脚本；将该脚本拆分成子处理操作；重组该子处理操作形成故障处理规则；将该故障告警问题和该故障处理规则存储在该数据库中。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：将在预设时间内出现的相同故障告警信息收敛成一条故障告警信息；将该故障告警信息转化成对应的故障告警问题。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据该故障告警问题匹配数据库中的故障告警问题；当该故障告警问题与该数据库中的故障告警问题匹配成功时，调用该数据库中的故障告警问题对应的数据库中的故障处理规则。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：当该故障告警问题与该数据库中的故障告警问题匹配失败时，上报该故障告警问题；根据该故障告警问题获取输入的故障处理规则；将该故障告警问题和该输入的故障处理规则对应存储在该数据库中。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：当该故障告警问题与该数据库中的故障告警问题匹配失败时，识别该故障告警问题得到故障子问题；根据该故障子问题匹配对应的故障处理规则；将该故障子问题对应的故障处理规则组成该故障告警问题对应的故障处理规则。

在一个实施例中，该数据库中的数据采用redis方式存储。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。