CN110321246B - 一种故障处理方法及装置 - Google Patents

Abstract

本申请提供了一种故障处理方法及装置，方法包括：获取前台输入的故障信息；从前台输入的故障信息中提取出故障特征，并确定故障特征对应的业务类型；从后台业务系统中选取与业务类型匹配的后台业务子系统，并获取后台业务子系统记录的最新业务信息；获取系统当前时间；基于故障特征、后台业务子系统记录的最新业务信息及系统当前时间，确定故障处理方案；根据故障处理方案进行故障处理。在本申请中，通过以上方式可以提高故障处理的准确性。

Description

一种故障处理方法及装置

技术领域

本申请涉及自动化技术领域，特别涉及一种故障处理方法及装置。

背景技术

随着民航新一代航班管理系统的发展，航班管理功能逐步从大型主机系统转移至服务器集群，在功能逐步拆分并逐步丰富的同时，也不可避免地带来航班管理系统后台调用的日益复杂。

在后台调用日益复杂的航班管理系统出现故障时，目前，一般可以采用如下故障处理方式：获取故障信息，并根据故障知识库对故障信息进行归类并处理，完成故障原因分析、进行故障处理策略匹配并根据策略自动运行故障处理命令或脚本，完成故障处理。但是，故障信息作为唯一数据源，难以保证数据源的可靠性，导致故障处理的准确性较低。

发明内容

为解决上述技术问题，本申请实施例提供一种故障处理方法及装置，以达到提高故障处理准确性的目的，技术方案如下：

一种故障处理方法，包括：

获取前台输入的故障信息；

从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型；

从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息；

获取系统当前时间；

基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案；

根据所述故障处理方案进行故障处理。

优选的，所述确定所述故障特征对应的业务类型，包括：

将所述故障特征与目标业务类型的特征进行匹配；

若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

优选的，所述从后台业务系统中选取与所述业务类型匹配的后台业务子系统，包括：

在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统；

从后台业务系统中选取与所述业务类型匹配的后台业务子系统。

优选的，所述根据所述故障处理方案进行故障处理，包括：

若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复；

若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

优选的，所述方法还包括：

判断所述故障恢复脚本是否成功运行；

若是，获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果；

若否，反馈所述故障恢复脚本运行失败的结果。

一种故障处理装置，包括：

第一获取模块，用于获取前台输入的故障信息；

第一确定模块，用于从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型；

第二获取模块，用于从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息；

第三获取模块，用于获取系统当前时间；

第二确定模块，用于基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案；

故障处理模块，用于根据所述故障处理方案进行故障处理。

优选的，所述第一确定模块，包括：

匹配子模块，用于将所述故障特征与目标业务类型的特征进行匹配；

第一确定子模块，用于若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

优选的，所述第二获取模块，包括：

查找子模块，用于在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统；

选取子模块，用于从后台业务系统中选取与所述业务类型匹配的后台业务子系统。

优选的，所述故障处理模块，包括：

恢复子模块，用于若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复；

反馈子模块，用于若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

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

判断模块，用于判断所述故障恢复脚本是否成功运行；

第四判断模块，用于若所述故障恢复脚本成功运行，则获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果；

反馈模块，用于若所述故障恢复脚本未成功运行，则反馈所述故障恢复脚本运行失败的结果。

与现有技术相比，本申请的有益效果为：

在本申请中，基于民航管理系统中故障处理与时序存在强关联性的原则，获取后台业务子系统记录的最新业务信息及系统当前时间，在此基础上，在从前台输入的故障信息中提取的故障特征的基础上，增加动态变化的后台业务子系统记录的业务信息及系统时间，利用多维数据源来确定故障处理方案，以此提高故障处理方案的准确性。

附图说明

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

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

图2是本申请提供的一种后台业务子系统之间的调用关系示意图；

图3是本申请提供的另一种故障处理方法的流程图；

图4是本申请提供的再一种故障处理方法的流程图；

图5是本申请提供的再一种故障处理方法的流程图；

图6是本申请提供的再一种故障处理方法的流程图；

图7是本申请提供的再一种故障处理方法的流程图；

图8是本申请提供的一种故障处理装置的逻辑结构示意图。

具体实施方式

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

本申请实施例公开了一种故障处理方法，包括：获取前台输入的故障信息；从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型；从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息；获取系统当前时间；基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案；根据所述故障处理方案进行故障处理。在本申请中，可以提高故障处理的准确性。

接下来对本申请实施例公开的一种故障处理方法进行介绍，请参见图1，可以包括以下步骤：

步骤S11、获取前台输入的故障信息。

前台输入的故障信息可以理解为：前台基于用户反馈的报错种类，输入的故障信息。其中，用户反馈的报错种类由通用民航业务系统中的业务子系统向用户推送的信息。

请参见表1，前台输入的故障信息中包括有故障特征，故障特征可以包括但不局限于：旅客信息、旅客服务类型、错误类型、操作时间或操作入口。

表1

其中，操作入口可以包括但不局限于：营业务传统渠道、代理人传统渠道、营业部电商渠道、代理人电商渠道、自助渠道或CUSS(旅客机场自助值机系统，Common Use Self-Service check-in System)渠道。

旅客服务类型可以包括但不局限于：国内电子客票自愿变更、国际电子客票自愿变更、非自愿同舱改期、非自愿换开、国际自愿退票、国内自愿退票或非自愿退票。

步骤S12、从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

可以理解的是，前台输入的故障信息中可能会包含除故障特征之外的干扰数据，因此需要从前台输入的故障信息中提取出故障特征。

业务类型可以理解为：用户通过通用民航业务系统(包括前台和后台业务系统)所办理的业务类型。而不同的故障特征或不同故障特征的组合会对应不同的业务类型，如，用户从CUSS渠道点击变更按钮后，发起非自愿同舱改期请求，则可以提取到的故障特征为CUSS渠道和非自愿同舱改期，则可以确定CUSS渠道和非自愿同舱改期对应的业务类型为通过CUSS渠道发起的非自愿同舱改期业务类型。

步骤S13、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

每种业务的实施需要与之匹配的后台业务子系统的支持，每种业务类型分别对应有相应的后台业务子系统，在业务类型已知的情况下，可以确定与业务类型匹配的后台业务子系统，并从后台业务系统中选取与业务类型匹配的后台业务子系统。

需要说明的是，可以设置后台业务子系统之间的调用关系，来支持业务的实施。以步骤S12中的通过CUSS渠道发起的非自愿同舱改期业务类型为例，对与业务类型匹配的后台业务子系统之间的调用关系进行说明，例如，根据业务类型与后台业务系统的映射关系表，可以确定与通过CUSS渠道发起的非自愿同舱改期业务类型对应的后台业务子系统如图2所示，其包括：PE子系统、TSI子系统、DOC子系统、BKG子系统、USAS子系统、OPEN TKT子系统、RCT子系统、AV子系统、CM子系统、INV子系统。其中，图2中子系统上方为模块名，如CUSS模块为PE子系统中的一个模块。

图2中的后台业务子系统之间的调用关系可以为：

通过CUSS发起变更请求，请求传达至MCSS；

MCSS作为入口，将用户输入信息传递给后台TRR；

TRR通过PNR编号调用RTDP，获取完整旅客信息；

TRR通过解析旅客信息获取票号，访问USAS获取票面具体信息；

TRR通过票号从OPEN TKT获取旧票信息；

TRR向RCT发起同舱改期请求；

RCT通过旅客信息中分析旅客行程，向AV获取可用航班信息；

RCT向BKG获取可用航班中是否存在VVIP信息，用户后期显示；

RCT调用seamless server访问可用航班的库存；

RCT将符合要求的航班回传给TRR；

TRR将结果封装返回给MCSS；

MCSS将结果返回给CUSS入口。

在本实施例中，不同的后台业务子系统的功能不同，记录的业务信息也不同。如表2所示，其示出了不同的后台业务子系统记录的业务信息。

表2

本实施例中，获取所述后台业务子系统记录的最新业务信息的过程，可以包括：

向后台业务子系统发送获取最新业务信息的请求；

接收后台业务子系统下发的最新业务信息。

基于步骤S12及本步骤的介绍，可以确定不同的故障特征可能会对应不同的业务类型，不同的业务类型对应的后台业务子系统也会不同，如表3所示，实例1与实例2因错误类型不同，涉及的后台子系统也不同；示例3月示例4因旅客信息不同，涉及的后台子系统也不同。

表3

步骤S14、获取系统当前时间。

系统当前时间可以理解为后台业务系统的当前时间。

步骤S15、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

可以理解的是，由于后台业务子系统的信息是随时间的推移而不断变化的(如，一个航班一天可以利用的作为，会随着用户的使用逐渐减少直至不存在可用座位)，因此，为了保障故障处理的准确性，需要获取后台业务子子系统记录的最新业务信息。

由于系统时间是不断变化的，因此对于同一个故障，可能需要根据时间的不同采取不同的处理方式。比如一个运价规则规定航班起飞之前退票不收手续费，航班起飞之后要收5％的退票费，那么在出现故障时，需要结合用户操作时间、系统当前时间、航班实际起飞时间确定故障处理方案。

基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案的过程，可以包括：

A11、从后台业务子系统记录的最新业务信息及所述系统当前时间中提取有效特征；

A12、对所述有效特征与所述故障特征进行比对，根据比对结果确定故障处理方案。

在本实施例中，举例对基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案进行说明，请参见表4，如表4所示，错误类型为其中一项故障特征，属性组合中的内容可以包括：故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间中的一种或多种。

表4

可以理解的是，基于不同的故障特征，获取到的后台业务子系统不同时，后台业务子系统记录的最新业务信息也会不同，在此基础上，故障处理方案会各不相同，如表5所示，示例1与示例2因为从后台业务系统中获取的开关状态不同，因此进行的修复方案不同；示例3与示例4因为用户操作时间不同，判断结果为误报或后台错误。

步骤S16、根据所述故障处理方案进行故障处理。

根据故障处理方案进行故障处理，以达到解决故障的目的。

在本申请中，基于民航管理系统中故障处理与时序存在强关联性的原则，获取后台业务子系统记录的最新业务信息及系统当前时间，在此基础上，在从前台输入的故障信息中提取的故障特征的基础上，增加动态变化的后台业务子系统记录的业务信息及系统时间，利用多维数据源来确定故障处理方案，以此提高故障处理方案的准确性。

需要说明的是，本实施例不限制故障处理方法的应用场景，其可以应用于生产环境或非生产环境。在非生产环境下，允许获取全部可用信息并允许更改后台系统与数据库，提高数据源获取的可靠性。

作为本申请另一可选实施例，参照图3，为本申请提供的一种故障处理方法实施例2的流程示意图，本实施例主要是对上述实施例描述的故障处理方法的细化方案，如图3所示，该方法可以包括但并不局限于以下步骤：

步骤S31、获取前台输入的故障信息。

步骤S31的详细过程可以参见前述实施例中步骤S11的相关介绍，在此不再赘述。

步骤S32、从所述前台输入的故障信息中提取出故障特征，将所述故障特征与目标业务类型的特征进行匹配。

目标业务类型可以理解为：多种业务类型中的其中一种业务类型。

每种业务类型各自均包含其特有的特征，因此目标业务类型的特征可以唯一确定。

需要说明的是，目标业务类型的特征同样可以包括但不局限于：旅客信息、旅客服务类型、错误类型、操作时间和操作入口中的一种或多种。

步骤S33、若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

设定条件可以设置为相似度达到预设值。预设值可以根据需要进行设置。优选的，预设值可以设置为：100％。

步骤S34、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

步骤S35、获取系统当前时间。

步骤S36、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

步骤S37、根据所述故障处理方案进行故障处理。

步骤S34-S37的详细过程可以参见前述实施例中步骤S13-S16的相关介绍，在此不再赘述。

作为本申请另一可选实施例，参照图4，为本申请提供的一种故障处理方法实施例3的流程示意图，本实施例主要是对上述实施例描述的故障处理方法的细化方案，如图4所示，该方法可以包括但并不局限于以下步骤：

步骤S41、获取前台输入的故障信息。

步骤S42、从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

步骤S41-S42的详细过程可以参见前述实施例中步骤S11-S12的相关介绍，在此不再赘述。

步骤S43、在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统。

本实施例中，根据业务类型与后台业务子系统的对应关系，可以预先构建后台业务子系统与业务类型映射表。后台业务子系统与业务类型映射表中记录有业务类型与后台业务子系统的对应关系。

步骤S44、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

步骤S45、获取系统当前时间。

步骤S46、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

步骤S47、根据所述故障处理方案进行故障处理。

步骤S44-S47的详细过程可以参见前述实施例中的步骤S13-S16的相关介绍，在此不再赘述。

作为本申请另一可选实施例，参照图5，为本申请提供的一种故障处理方法实施例4的流程示意图，本实施例主要是对上述实施例描述的故障处理方法的细化方案，如图5所示，该方法可以包括但并不局限于以下步骤：

步骤S51、获取前台输入的故障信息。

步骤S52、从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

步骤S53、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

步骤S54、获取系统当前时间。

步骤S55、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

步骤S51-S55的详细过程可以参见前述实施例中步骤S11-S15的相关介绍，在此不再赘述。

步骤S56、若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复。

可以理解的是，若步骤S55确定出的故障处理方案为故障恢复脚本，则本步骤需要执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复，解决存在故障的后台业务子系统的故障。

作为本申请另一可选实施例，参照图6，为本申请提供的一种故障处理方法实施例5的流程示意图，本实施例主要是对上述实施例描述的故障处理方法的细化方案，如图6所示，该方法可以包括但并不局限于以下步骤：

步骤S61、获取前台输入的故障信息。

步骤S62、从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

步骤S63、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

步骤S64、获取系统当前时间。

步骤S65、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

步骤S61-S65的详细过程可以参见前述实施例中步骤S11-S15的相关介绍，在此不再赘述。

步骤S66、若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

非系统故障可以理解为人为造成的故障，如，用户操作错误或信息误报。

与用户操作错误或信息误报相对应的非系统故障，故障恢复提示信息可以包括：用户操作错误的提示信息或信息误报的提示信息。

反馈故障恢复提示信息可以理解为：反馈故障恢复提示信息至前台，以使前台推送故障恢复提示信息至用户；

或者，直接反馈故障恢复提示信息至前台和/或用户。

在本申请的另一个实施例中，介绍另外一种故障处理方法，请参见图7，可以包括以下步骤：

步骤S71、获取前台输入的故障信息。

步骤S72、从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

步骤S73、从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

步骤S74、获取系统当前时间。

步骤S55、基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

步骤S76、若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复。

步骤S71-S76的详细过程可以参见前述实施例中步骤S51-S56的相关介绍，在此不再赘述。

步骤S77、判断所述故障恢复脚本是否成功运行。

若是，则执行步骤S78；若否，则执行步骤S79。

步骤S78、获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果。

本实施例中，可以反馈结果至前台，由前台推送反馈结果至用户。

或者，可以直接反馈所述结果至前台和/或用户。

步骤S79、反馈所述故障恢复脚本运行失败的结果。

本实施例中，可以反馈故障恢复脚本运行失败的结果至前台，由前台推送故障恢复脚本运行失败的结果至用户。

或者，可以直接反馈故障恢复脚本运行失败的结果至前台和/或用户。

接下来对本申请提供的故障处理装置进行介绍，下文介绍的故障处理装置与上文介绍的故障处理方法可相互对应参照。

请参见图8，故障处理装置可以包括：第一获取模块11、第一确定模块12、第二获取模块13、第三获取模块14、第二确定模块15和故障处理模块16。

第一获取模块11，用于获取前台输入的故障信息。

第一确定模块12，用于从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型。

第二获取模块13，用于从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息。

第三获取模块14，用于获取系统当前时间。

第二确定模块15，用于基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案。

故障处理模块16，用于根据所述故障处理方案进行故障处理。

在本实施例中，第一确定模块12，可以包括：

匹配子模块，用于将所述故障特征与目标业务类型的特征进行匹配；

第一确定子模块，用于若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

在本实施例中，第二获取模块13可以包括：

查找子模块，用于在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统；

选取子模块，用于从后台业务系统中选取与所述业务类型匹配的后台业务子系统。

在本实施例中，恢复子模块，用于若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复；

反馈子模块，用于若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

在本实施例中，故障处理装置还可以包括：

判断模块，用于判断所述故障恢复脚本是否成功运行；

第四判断模块，用于若所述故障恢复脚本成功运行，则获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果；

反馈模块，用于若所述故障恢复脚本未成功运行，则反馈所述故障恢复脚本运行失败的结果。

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

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

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

以上对本申请所提供的一种故障处理方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

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

获取前台输入的故障信息；

从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型；

根据后台业务子系统与业务类型映射表从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息；

获取系统当前时间；

基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案；

根据所述故障处理方案进行故障处理。

2.根据权利要求1所述的方法，其特征在于，所述确定所述故障特征对应的业务类型，包括：

将所述故障特征与目标业务类型的特征进行匹配；

若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

3.根据权利要求1所述的方法，其特征在于，所述从后台业务系统中选取与所述业务类型匹配的后台业务子系统，包括：

在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统；

从后台业务系统中选取与所述业务类型匹配的后台业务子系统。

4.根据权利要求1所述的方法，其特征在于，所述根据所述故障处理方案进行故障处理，包括：

若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复；

若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

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

判断所述故障恢复脚本是否成功运行；

若是，获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果；

若否，反馈所述故障恢复脚本运行失败的结果。

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

第一获取模块，用于获取前台输入的故障信息；

第一确定模块，用于从所述前台输入的故障信息中提取出故障特征，并确定所述故障特征对应的业务类型；

第二获取模块，用于根据后台业务子系统与业务类型映射表从后台业务系统中选取与所述业务类型匹配的后台业务子系统，并获取所述后台业务子系统记录的最新业务信息；

第三获取模块，用于获取系统当前时间；

第二确定模块，用于基于所述故障特征、所述后台业务子系统记录的最新业务信息及所述系统当前时间，确定故障处理方案；

故障处理模块，用于根据所述故障处理方案进行故障处理。

7.根据权利要求6所述的装置，其特征在于，所述第一确定模块，包括：

匹配子模块，用于将所述故障特征与目标业务类型的特征进行匹配；

第一确定子模块，用于若匹配结果符合设定条件，则将所述目标业务类型作为所述故障特征对应的业务类型。

8.根据权利要求6所述的装置，其特征在于，所述第二获取模块，包括：

查找子模块，用于在后台业务子系统与业务类型映射表中查找与所述业务类型匹配的后台业务子系统；

选取子模块，用于从后台业务系统中选取与所述业务类型匹配的后台业务子系统。

9.根据权利要求6所述的装置，其特征在于，所述故障处理模块，包括：

恢复子模块，用于若所述故障处理方案为故障恢复脚本，则执行所述故障恢复脚本，对存在故障的后台业务子系统进行恢复；

反馈子模块，用于若所述故障处理方案为针对非系统故障的故障恢复提示信息，则反馈所述故障恢复提示信息。

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

判断模块，用于判断所述故障恢复脚本是否成功运行；

第四判断模块，用于若所述故障恢复脚本成功运行，则获取对所述存在故障的后台业务子系统进行恢复的结果，并反馈所述结果；

反馈模块，用于若所述故障恢复脚本未成功运行，则反馈所述故障恢复脚本运行失败的结果。