CN114363149A

CN114363149A - 故障处理方法及装置

Info

Publication number: CN114363149A
Application number: CN202111593680.9A
Authority: CN
Inventors: 王晗
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2021-12-23
Filing date: 2021-12-23
Publication date: 2022-04-15
Anticipated expiration: 2041-12-23
Also published as: CN114363149B

Abstract

本申请提供故障处理方法及装置，其中所述故障处理方法包括：在监测到目标业务服务出现故障的情况下，获取目标故障信息；获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；若是，基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论，通过本方法，可以自动定位故障位置，推导故障原因，辅助业务人员及时处理故障，提升故障定位的效率和准确率。

Description

故障处理方法及装置

技术领域

本申请涉及互联网技术领域，特别涉及一种故障处理方法。本申请同时涉及一种故障处理装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

随着互联网业务的发展，每天会有大量的上线变更或配置变更等发生，而通过对过往的故障进行分析发现，大部分的生产事故是由某种变更而触发的，那么当出现问题时，能自动地、迅速而准确地检测到问题的发生，可以有效提高变更执行的安全性，保证业务和服务安全可用。

在传统的解决方案中是针对业务指标波动进行监控报警，将采集到的监控数据保存在时序数据库中，根据配置定时去拉取各个节点的数据，传统的监控报警解决方案中，只能及时发现单条异常报警，但对于报警发生的根因以及当报警大规模出现时的根因归纳没有有效的应对手段，只能人工紧急排查，效率低下且高度依赖历史排查经验，准确度较低。

发明内容

有鉴于此，本申请实施例提供了一种故障处理方法。本申请同时涉及一种故障处理装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的故障定位依赖于人工排查，定位效率低、准确度差的问题。

根据本申请实施例的第一方面，提供了一种故障处理方法，包括：

在监测到目标业务服务出现故障的情况下，获取目标故障信息；

获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；

判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；

若是，基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。

根据本申请实施例的第二方面，提供了一种故障处理装置，包括：

监测模块，被配置为在监测到目标业务服务出现故障的情况下，获取目标故障信息；

创建模块，被配置为获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；

判断模块，被配置为判断预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；

若所述判断模块的运行结果为是，则运行推理模块；

所述推理模块，被配置为基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述故障处理方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述故障处理方法的步骤。

本申请提供的故障处理方法，在监测到目标业务服务出现故障的情况下，获取目标故障信息；获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；若是，基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。

本申请一实施例实现了当出现故障时，及时获取故障信息，通过与已有的故障推理进行比对获得故障原因，若没有响应的故障推理链路，则确定与业务服务相关的事件信息集合，通过在事件信息集合中进行过滤筛选，辅助业务人员找到故障的原因，通过本方法，可以自动定位故障位置，推导故障原因，辅助业务人员及时处理故障，提升故障定位的效率和准确率。

附图说明

图1是本申请一实施例提供的一种故障处理方法的流程图；

图2是本申请一实施例提供的可视化界面的示意图；

图3是本申请一实施例提供的接口故障的故障推理链路的示意图；

图4是本申请一实施例提供的消息队列堆积故障的故障推理链路的示意图；

图5是本申请一实施例提供的故障定位系统的架构示意图；

图6是本申请一实施例提供的一种应用于处理消息堆积故障的故障处理方法的处理流程图；

图7是本申请一实施例提供的一种故障处理装置的结构示意图；

图8是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着互联网业务的发展，每天会有大量的上线变更或配置变更等事件发生，而实际生产中的生产事故大部分是由某种变更而触发的，那么如果出现问题时，能自动地、迅速而准确地检测到问题的发生，可以有效提高变更执行的安全性，保证业务和服务的可用。

传统的解决方案中，通常将采集到的监控数据保存在时序数据库中，根据配置定时拉取各个节点的数据，但是这种方法只能及时发现单条异常报警，对于报警发生的根因以及报警大规模出现时的根因归纳没有有效的应对手段，只能依靠业务人员的排查，非常依赖业务人员的个人经验，排查效率低且准确率较差。

基于此，在本申请中，提供了一种故障处理方法，本申请同时涉及一种故障处理装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种故障处理方法的流程图，具体包括以下步骤：

步骤102：在监测到目标业务服务出现故障的情况下，获取目标故障信息。

其中，目标业务服务是指在实际应用中的具体业务服务，例如直播业务服务、游戏业务服务、购物业务服务、某业务的接口服务、消息处理服务等等，在实际应用中，当一个业务服务正常应用时，其可以提供正常的服务，若该业务服务无法提供正常的服务，则说明该目标业务服务出现故障。

在业务提供方的基础设施建设中，会设置有专门的监测服务器，监测服务器用于对业务服务是否可以用进行监测，具体的，在监测到目标业务服务出现故障之前，所述方法还包括：

监测目标业务服务的服务状态信息和/或所述目标业务服务对应的业务服务器的服务器状态信息；

若所述服务状态信息或所述服务器状态信息异常，则确定所述目标业务服务出现故障；

生成故障事件信息，并添加所述故障事件信息至所述事件数据库。

ZooKeeper是一个分布式、开源的分布式应用程序协调服务，为分布式应用提供一致性服务。在业务提供方部署业务服务的过程中，可以通过Zookeeper作为服务发现中间件监测目标业务服务是否出现故障。具体的，可以监测目标业务服务的服务状态信息，即目标业务服务是否可用；还可以监测部署目标业务服务的服务器的状态信息，例如服务器的CPU、内存、磁盘IO(磁盘的写入和读取)等信息。

通过监测目标业务服务的服务状态信息和/或部署目标业务服务对应的业务服务器的服务器状态信息可以定期获取到目标业务服务的服务状态信息或服务器状态信息是否有异常，例如目标业务服务无法正常提供服务、业务服务器内存被占满、业务服务器的磁盘IO异常等等，当监测到的服务状态信息或服务器状态信息出现异常时，可以确定目标业务服务出现故障。

当监测到目标业务服务出现故障时，可以生成目标业务服务的目标故障信息，同时生成故障事件信息，用于记录本次故障事件对应的相关信息，具体可以包括事件标题、事件发生平台、事件开始时间、事件结束事件等等信息，并将故障事件信息保存至事件数据库。

事件数据库是用于保存事件相关数据信息的数据库，在业务提供方，通常会涉及到服务发布、配置变更、数据库工单提交、运营后台修改等等事件，为了监测每个事件对故障发生会不会带来影响，需要将上述变更事件标准化为一个完整事件并保存到事件数据库，当目标业务服务出现故障时，可以通过查询事件数据库来查看在故障发生之前发生了哪些事件，进而排查哪些事件可能会对故障带来影响。

在实际应用中，事件数据库除了会保存故障事件信息，还会保存各类事件信息，例如服务发布、配置修改等等，基于此，所述方法还包括：

采集目标业务事件信息；

添加所述目标业务事件信息至所述事件数据库。

在实际应用中，还设置事件收集脚本、故障收集脚本，当业务提供方有服务发布、配置修改等事件发生，由事件收集脚本收集各项变更事件；当有故障事件发生时，由故障收集脚本收集各项故障事件。再由事件收集脚本和故障收集脚本生成对应的事件消息，并将事件消息添加到消息队列中。同时还设置有事件中心管理器，事件中心管理器监听消息队列，从消息队列中获取事件消息，并保存至事件数据库中，便于后续的故障定位和故障排查。

除了收集变更事件信息、故障事件信息之前，业务人员还可以对目标业务服务进行标记，具体的，所述方法还包括：

可视化所述事件数据库；

接收针对所述事件数据库的事件标记指令；

基于所述事件标记指令生成标记事件信息，并将所述标记事件信息添加至所述事件数据库。

参见图2，图2示出了本申请一实施例提供的可视化界面的示意图，业务人员进入事件数据库可视化后的前端页面，在页面中可以按时间线由近及远的顺序看到各时间点的事件，且可以按照事件的开始时间、结束时间、产品线、标签等维度进行细化筛选，业务人员还可以针对该界面进行事件的维护和补充，发出事件标记指令，如用户流量迁移、主从服务器切换等，生成标记事件信息，并将标记事件信息添加至事件数据库，为后续故障发生时进行故障定位提供依据。

进一步的，为了标准化各项事件，便于将各项事件信息进行统一，可以将事件的定义为如下表1所示的形式，表1示出了本申请一实施例提供的事件定义表的示意格式：

表1

在监测到目标业务服务出现故障时，会生成故障信息，相应的，获取目标故障信息，包括：

获取所述目标业务服务的目标业务服务标识、故障开始时间点、目标业务服务对应的业务线标识、故障描述信息。

进一步的，目标故障信息中具体可以包括目标业务服务的目标业务服务标识、故障开始时间点、目标业务服务对应的业务线标识、故障描述信息等等。例如，目标业务服务为A服务的b接口服务出现故障，生成故障信息包括“目标业务服务标识-b接口、故障开始时间点-15:35:57、业务线标识-A服务、故障描述信息-b接口不可用……”。

步骤104：获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合。

预设故障推理链路集合中用于保存对于已知业务服务故障的故障结论，故障推理链路用于确定业务服务的故障结论。例如对于A服务的b接口不可用，曾经出现过该故障，对应的故障定位顺序为先判断部署A服务的服务器是否运行正常，再判断b接口对应的下游服务是否正常……。

在实际应用中，业务服务间的引用是很频繁的，某一个服务的现象可能是另一个服务的原因，在故障定位的场景中，大部分事件间有明确的规则，可以通过预设故障推理链路集合来保存，基于现有的规则来推理事件间的关系，一个功能完善的故障推理链路集合是需要大量的训练数据来构造基础规则的，但是在实际应用中，通常不会出现大量的故障用于训练，因此，可以基于历史排查方式来构建预设故障推理链路集合，因此，预设故障推理链路集合可以通过历史故障信息和所述历史故障信息对应的故障处理链路创建。

具体的，获取历史故障信息和该历史故障信息对应的故障处理链路，再根据历史故障信息和故障处理链路来创建故障推理链路，从而将关于该故障的故障推理链路添加至预设故障推理链路集合，当该故障再次出现时，可以在预设故障推理链路集合中找到该条故障推理链路，来对该故障进行推理排查，提高故障定位效率。

参见图3，图3示出了本申请一实施例提供的接口故障的故障推理链路的示意图，如图3所示，A服务的b接口不可用，其对应的推理链路为“1.判断A服务的物理机状态是否正常；2.判断b接口的下游依赖是否正常；3.检查A服务在5分钟内的部署发布事件；4.检查A服务在5分钟内的配置修改事件；5.A服务的数据库在5分钟内的变更工单事件；6.数据库在5分钟内的事件集合”。

参见图4，图4示出了本申请一实施例提供的消息队列堆积故障的故障推理链路的示意图，如图4所示，消息队列堆积，其对应的推理链路为“1.判断物理机状态是否正常；2.判断消息队列入口写入量是否增多；3.判断消息队列出口消费量是否减少；4.服务在预设时间内发布的服务变更事件；5.数据库在预设时间内的事件集合”。

步骤106：判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路。

其中，所述故障推理链路用于确定业务服务的故障结论。在实际应用中，预设故障推理链路集合中保存了多条故障推理链路，当出现故障时，需要判断该故障是否存在对应的故障推理链路，具体的，判断预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，包括：

获取所述目标故障信息中的故障描述信息；

根据所述故障描述信息在所述预设故障推理链路集合中进行查询，判断是否有与所述故障描述信息对应的目标故障推理链路。

目标故障信息中包括故障描述信息，例如“A服务的b接口不可用”、“消息队列堆积”等等，在故障推理链路会对应的有故障的描述信息，可以根据目标故障信息中的故障描述信息，与故障推理链路中的故障描述信息进行比对，当匹配成功时，可以确定在预设故障推理链路集合存在与故障描述信息对应的目标故障推理链路；当匹配失败时，可以确定在预设故障推理链路集合不存在与故障描述信息对应的目标故障推理链路。

若确定在预设故障推理链路集合存在与故障描述信息对应的目标故障推理链路，则执行后续步骤108。

步骤108：基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。

在确定预设故障推理链路集合中存在目标故障推理链路后，基于所述目标故障推理链路处理所述目标业务服务，来获得目标业务服务对应的目标故障结论。

在本申请提供的一具体实施方式中，参见图3，以A服务的b接口不可用的故障为例进行解释说明，首先要判断A服务的物理机状态是否为正常，物理机即部署A服务的服务器，若部署A服务的物理机出现CPU故障、内存故障灯，则可以确定出现该故障的原因是部署A服务的物理机出现故障；若部署A服务的物理机状态正常，则进一步判断b接口的下游依赖是否正常，即使用b接口的下游服务是否正常，若下游服务出现问题，则可以确定出现该故障的原因是使用b接口的下游服务出现故障；若使用b接口的下游服务也正常，则检查A服务在5分钟内的部署发布事件，即A服务在5分钟内是否发生过部署发布事件；再检查A服务在5分钟内的配置修改事件，即检查服务A在5分钟内是否修改过配置；再检查A服务的数据库在5分钟内是否出现过变更工单事件，以及获取A服务的数据库在5分钟内的查询、增加、修改、删除等事件的集合。通过将部署发布事件、配置修改事件、变更工单事件、数据库操作事件等事件进行处理，构建事件集合的上下游依赖，例如事件发生的时间顺序、事件因果等等，再结合事件上下游依赖确定本次故障的故障结论。

在本申请提供的一具体实施方式中，参见图4，以消息队列堆积阻塞为例进行解释说明，首先要判断用于部署消息队列的物理机状态是否正常，若用于部署消息队列的物理机硬件出现故障，则无法正常处理消息队列中的消息，进而得出该故障的原因是物理机出现故障；若部署消息队列的物理机状态正常，进一步判断消息队列的入口处的写入量是否增多，若是，则可以确定出现该故障的原因是消息写入量增加；若写入量没有增加，则进一步判断消息队列出口的消费量是否减少，若是，则确定出现该故障的原因是消息的消费量减少；若消费量没有减少，则获取各项服务在预设时间内发布的服务变更事件、数据库在预设时间内的操作事件集合，进而构建事件上下游依赖，从而在事件上下游依赖中查找故障结论。

在本申请提供的另一具体实施方式中，还存在预设故障推理链路集合不存在与故障描述信息对应的目标故障推理链路的情况，基于此，所述方法还包括：

根据所述目标故障信息在事件数据库中获取与所述目标业务服务对应的事件信息集合，并反馈所述事件信息集合，其中，所述事件数据库保存业务事件信息。

具体的，若未检索到目标故障推理链路，则说明没有该故障的故障推理链路，即可能在历史上没有出现过该故障，此时需要对为什么出现该故障进行排查。

在实际应用中，根据目标故障信息在事件数据库中获取与该目标业务服务对应的事件信息集合，在实际应用中，业务提供方会提供很多服务，相应的，事件数据库中的事件信息会有很多，如果选取所有的事件不利于查找目标业务服务的故障定位，因此，要在事件数据库中将与目标业务服务相关的事件信息筛选出来，并对于目标业务服务相关的事件信息进行分析。

具体的，根据所述目标故障信息在事件数据库中获取与所述目标业务服务对应的事件信息集合，包括：

解析所述目标故障信息，获取故障开始时间点和业务线标识；

根据所述故障开始时间点确定故障定位时间区间；

在事件数据库中获取在所述故障定位时间区间内与所述业务线标识对应的事件信息集合。

虽然是根据与目标业务服务相关的事件信息进行分析，但是在实际应用中，目标业务服务相关的事件信息也会有很多，而且对于一些时间比较久远的事件对本次故障的影响会比较低，因此我们首选最近发生的一些事件信息作为参考。同时，虽然是目标业务服务出现故障，但是服务之间通常会有依赖关系，在同一个业务线内对其他的业务服务进行调整之后，也有可能对目标业务服务产生影响。

基于此，解析目标故障信息，获得故障开始时间点和业务线标识，其中，故障开始时间点具体是指出现该故障的时间点，业务线标识具体是指目标业务服务对应的业务线。

根据故障开始时间点进一步可以确定故障定位时间区间，故障定位时间区间具体是指用于确定与故障相关的事件的时间区间。例如从故障开始点前的5分钟、10分钟等等，如果故障开始时间点为15:05，则可以确定故障定位时间区间为15：00-15:05或14:50-15:05，时间区间的范围以实际应用为准，在本申请中不做限定。

在确定故障定位时间区间之后，即可获取在该故障定位时间区间内于业务线标识对应的事件信息集合，即收集在该故障定位时间区间内发生在该目标业务服务对应的业务线上的事件信息，组成事件信息集合。通过该事件信息集合可以协助业务人员定位故障原因，及时解决目标业务服务出现的故障。

事件信息集合中通常包括多个事件信息，反馈至业务人员处，也不太方便业务人员进行梳理，因此，反馈所述事件信息集合，进一步包括：

基于所述事件信息集合创建事件发生链路；

反馈所述事件发生链路。

其中，对事件信息集合中的多个事件信息进行整理，将存在上下游依赖的事件进行拼接，创建事件发生链路，将事件信息间的先后顺序、因果缘由进行梳理，并添加到目标故障信息中反馈给业务人员，便于业务人员进行故障定位，提升了故障定位的定位效率和准确率。

本申请提供的故障处理方法，在监测到目标业务服务出现故障的情况下，获取目标故障信息；获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；若是，基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。通过本申请实施例提供的方法，当出现故障时，可以及时获取故障信息，通过与已有的故障推理进行比对获得故障原因，若没有响应的故障推理链路，则确定与业务服务相关的事件信息集合，通过在事件信息集合中进行过滤筛选，辅助业务人员找到故障的原因，通过本方法，可以自动定位故障位置，推导故障原因，辅助业务人员及时处理故障，提升故障定位的效率和准确率。

参见图5，图5示出了本申请一实施例提供的故障定位系统的架构示意图，故障定位系统包括报警拦截中间件、变更事件收集脚本、故障收集脚本、前端服务、事件中心管理域、事件中心推理域等服务。

其中，变更事件收集脚本负责收集业务提供方的服务发布、配置中心变更、运营后台变更、数据库工单事件等等。

故障收集脚本负责轮询服务发现中心和服务监控中心的数据，进而确定业务服务是否可用、业务服务对应的服务器是否有异常信息等等。

报警拦截中间件用于拦截由于故障触发的报警信息，并将报警信息发送给事件中心推理域。

事件中心推理域接收到报警后，先与故障推理链路集合进行故障推理链路的比对，当有匹配的故障推理链路时，根据匹配成功的故障推理链路得出故障结论，当没有匹配的故障推理链路时，在事件数据库中进行检索，查找预设时间区间内的事件信息集合，并将存在有上下游依赖的事件信息组成事件发生链路，并附加到报警信息中发送至业务人员。

事件中心管理域和事件中心推理域通过数据库进行数据交互。

前端服务用于将故障定位系统进行可视化，展示给业务人员，便于业务人员进行浏览、标记。

下述结合附图6，以本申请提供的故障处理方法在处理消息堆积故障的应用为例，对所述故障处理方法进行进一步说明。其中，图6示出了本申请一实施例提供的一种应用于处理消息堆积故障的故障处理方法的处理流程图，具体包括以下步骤：

步骤602：监测到消息队列发生消息堆积、处理不及时的故障，并获取目标故障信息。

步骤604：获取目标故障信息中的故障描述信息，即消息队列堆积。

步骤606：根据所述故障描述信息在所述预设故障推理链路集合中查询目标故障推理链路。

步骤608：判断是否存在该目标故障推理链路，若是，则执行步骤610，若否，则执行步骤612。

步骤610：基于所述目标故障推理链路定位消息队列堆积故障的故障原因。

步骤612：解析该目标故障信息，获取故障开始时间点和业务线标识。

步骤614：根据该故障开始时间点确定故障定位时间区间。

步骤616：在事件数据库中获取在所述故障定位时间区间内与所述业务线标识对应的事件信息集合。

步骤618：基于该事件信息集合创建事件发生链路，并反馈该事件发生链路至业务人员。

与上述故障处理方法实施例相对应，本申请还提供了故障处理装置实施例，图7示出了本申请一实施例提供的一种故障处理装置的结构示意图。如图7所示，该装置包括：

监测模块702，被配置为在监测到目标业务服务出现故障的情况下，获取目标故障信息；

创建模块704，被配置为获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；

判断模块706，被配置为判断预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；

若所述判断模块的运行结果为是，则运行推理模块708；

所述推理模块708，被配置为基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。

可选的，所述装置还包括：

信息监测模块，被配置为监测目标业务服务的服务状态信息和/或所述目标业务服务对应的业务服务器的服务器状态信息；

确定模块，被配置为若所述服务状态信息或所述服务器状态信息异常，则确定所述目标业务服务出现故障；

生成模块，被配置为生成故障事件信息，并添加所述故障事件信息至所述事件数据库。

可选的，所述监测模块702，进一步被配置为：

可选的，所述判断模块706，进一步被配置为：

获取所述目标故障信息中的故障描述信息；

可选的，所述装置还包括获取模块，所述获取模块，被配置为：

若所述预设故障推理链路集合中未存在与所述目标故障信息对应的目标故障推理链路，则根据所述目标故障信息在事件数据库中获取与所述目标业务服务对应的事件信息集合，并反馈所述事件信息集合，其中，所述事件数据库保存业务事件信息。

可选的，所述获取模块，进一步被配置为：

根据所述故障开始时间点确定故障定位时间区间；

可选的，所述获取模块，进一步被配置为：

基于所述事件信息集合创建事件发生链路；

反馈所述事件发生链路。

可选的，所述装置还包括：

采集模块，被配置为采集目标业务事件信息；

第一添加模块，被配置为添加所述目标业务事件信息至所述事件数据库。

可选的，所述装置还包括：

可视化模块，被配置为可视化所述事件数据库；

标记接收模块，被配置为接收针对所述事件数据库的事件标记指令；

第二添加模块，被配置为基于所述事件标记指令生成标记事件信息，并将所述标记事件信息添加至所述事件数据库。

本申请提供的故障处理装置，在监测到目标业务服务出现故障的情况下，获取目标故障信息；获取历史故障信息和所述历史故障信息对应的故障处理链路，并基于所述历史故障信息和所述故障处理链路创建预设故障推理链路集合；判断所述预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，其中，所述故障推理链路用于确定业务服务的故障结论；若是，基于所述目标故障推理链路处理所述目标业务服务，获得并反馈所述目标业务服务对应的目标故障结论。通过本申请实施例提供的装置，当出现故障时，可以及时获取故障信息，通过与已有的故障推理进行比对获得故障原因，若没有响应的故障推理链路，则确定与业务服务相关的事件信息集合，通过在事件信息集合中进行过滤筛选，辅助业务人员找到故障的原因，通过本方法，可以自动定位故障位置，推导故障原因，辅助业务人员及时处理故障，提升故障定位的效率和准确率。

上述为本实施例的一种故障处理装置的示意性方案。需要说明的是，该故障处理装置的技术方案与上述的故障处理方法的技术方案属于同一构思，故障处理装置的技术方案未详细描述的细节内容，均可以参见上述故障处理方法的技术方案的描述。

图8示出了根据本申请一实施例提供的一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。

计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备800还可以是移动式或静止式的服务器。

其中，处理器820执行所述计算机指令时实现所述的故障处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的故障处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述故障处理方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述故障处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的故障处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述故障处理方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims

1.一种故障处理方法，其特征在于，包括：

2.如权利要求1所述的故障处理方法，其特征在于，所述方法还包括：

3.如权利要求1所述的故障处理方法，其特征在于，获取目标故障信息，包括：

4.如权利要求1所述的故障处理方法，其特征在于，判断预设故障推理链路集合中是否存在与所述目标故障信息对应的目标故障推理链路，包括：

获取所述目标故障信息中的故障描述信息；

5.如权利要求1所述的故障处理方法，其特征在于，所述方法还包括：

6.如权利要求5所述的故障处理方法，其特征在于，根据所述目标故障信息在事件数据库中获取与所述目标业务服务对应的事件信息集合，包括：

根据所述故障开始时间点确定故障定位时间区间；

7.如权利要求5所述的故障处理方法，其特征在于，反馈所述事件信息集合，包括：

基于所述事件信息集合创建事件发生链路；

反馈所述事件发生链路。

8.如权利要求1-7任意一项所述的故障处理方法，其特征在于，所述方法还包括：

采集目标业务事件信息；

添加所述目标业务事件信息至所述事件数据库。

9.如权利要求1-7任意一项所述的故障处理方法，其特征在于，所述方法还包括：

可视化所述事件数据库；

接收针对所述事件数据库的事件标记指令；

10.一种故障处理装置，其特征在于，包括：

若所述判断模块的运行结果为是，则运行推理模块；

11.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述计算机指令时实现权利要求1-9任意一项所述方法的步骤。

12.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1-9任意一项所述方法的步骤。