CN109088773A - 故障自愈方法、装置、服务器及存储介质 - Google Patents

Abstract

本发明公开了一种故障自愈方法、装置、服务器及存储介质，通过控制第一作业平台查询故障事件；指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台；指示第二作业平台根据自愈信息查找相应的API；指示第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果的技术手段。本发明的技术方案解决了每个平台单独作业时存在的问题，如蓝鲸运维平台各流程节点间的数据无法传递、无法实现流程暂停并等待审批确认后继续执行的问题，以及stackstorm无法跨集群作业的问题，通过多个作业平台之间相互协调作业，优化了故障自愈流程，同时，可以保证用户明确故障自愈的各节点，便于用户对故障自愈过程进行监控。

Description

故障自愈方法、装置、服务器及存储介质

技术领域

本发明实施例涉及运维技术领域，尤其涉及一种故障自愈方法、装置、服务器及存储介质。

背景技术

多维度运维监控系统每时每刻都在产生着大量的告警信息，排查告警故障并恢复系统正常运行是系统运维工程师日常工作中最耗费时间和精力的部分。如何快速的自动化排查告警故障并恢复系统正常，成为了急需要解决的问题。

现有技术中故障告警并恢复系统采用的方法一般依赖于腾讯蓝鲸运维平台或Stackstorm。其中，腾讯蓝鲸运维平台内置有作业平台，用于流程编排与执行，最大的优点是，可以跨集群执行远程作业，但存在如下问题：1.无法实现各流程节点间的数据传递；2.无法实现流程暂停并等待审批确认后继续执行。stackstorm是一个事件驱动的自动化流程编排引擎，可以轻松的实现故障诊断和自动修复。在故障诊断和自动修复的过程中，stackstorm可以实现各流程节点间的数据传递。但Stackstorm也有其不足之处：1.无法跨集群执行作业任务；2.对于其他平台上的业务，如蓝鲸作业平台作业任务，若全部废弃掉改写成stackstorm的工作流程或者流程编排是工作量巨大的。

因此，发明人实现本发明的过程中，发现现有技术中各故障自愈平台均存在不足之处，使得各故障自愈平台无法更好的为用户提供服务。

发明内容

本发明提供一种故障自愈方法、装置、服务器及存储介，以实现多个故障自愈作业平台之间相互协调作业，优化自动化的故障自愈流程。

第一方面，本发明实施例提供了一种故障自愈方法，包括：

控制第一作业平台查询故障事件；

指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台；

指示所述第二作业平台根据所述自愈信息查找相应的应用程序编程接口(Application Programming Interface，API)；

指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

进一步的，所述指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台包括：

指示所述第一作业平台根据所述故障事件确定故障类型以及故障位置；

指示所述第一作业平台根据所述故障类型查找对应的自愈类型；

指示所述第一作业平台将所述自愈类型以及故障位置封装成自愈信息并发送至第二作业平台。

进一步的，所述指示所述第二作业平台根据所述自愈信息查找相应的API包括：

指示所述第二作业平台获取所述自愈信息中的自愈类型以及故障位置；

指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式，所述键值表达式表示所述故障类型；

指示所述第二作业平台将所述故障位置写入所述键值表达式。

进一步的，所述键值表达式包括设定符号，所述设定符号用于指示故障位置；

所述指示所述第二作业平台将所述故障位置写入所述键值表达式包括：

指示所述第二作业平台将预设字符替换所述键值表达式的设定符号中，以得到目标表达式；

指示所述第二作业平台利用正则表达式对所述目标表达式中的预设字符进行识别，以确定所述预设字符对应的故障位置；

指示所述第二作业平台将所述故障位置与所述预设字符进行关联。

进一步的，所述指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式之前，还包括：

指示所述第二作业平台确定所述自愈信息的类别为预设的可识别类别。

进一步的，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果包括：

指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用；

指示所述第二作业平台将写入故障位置的键值表达式作为所述自愈程序的输入；

指示第二作业平台获取自愈程序运行的自愈结果，所述自愈结果是所述第三作业平台对所述自愈程序运行后的返回值进行编译的结果。

进一步的，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，还包括：

指示所述第二作业平台读取所述自愈结果中的开始标记；

若所述开始标记为第一开始标记，则指示第二作业平台从第一开始标记开始，读取第一标记符号所在行的程序信息，以实现对所述自愈结果的识别；

若所述开始标记为第二开始标记，则指示第二作业平台读取所述第二开始标记之后的程序信息；

若是读取到结束标记，则指示第二作业平台将第二开始标记与结束标记之间的程序信息作为自愈结果，以实现对所述自愈结果的识别。

进一步的，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之前包括：

指示所述第二作业平台对所述第三作业平台进行鉴权。

进一步的，所述指示所述第二作业平台根据所述自愈信息查找相应的API之后或之前，还包括：

指示所述第二作业平台根据所述自愈信息查找相应的联系客户端；

相应的，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用之后，还包括：

指示所述第二作业平台确定满足通知生成条件；

指示所述第二作业平台将通知信息发送至所述联系客户端。

具体的，所述通知生成条件包括：自愈程序中子节点完成运行。

具体的，所述通知信息包括：自愈程序的ID，所述子节点的运行起始时间和结束时间以及所述故障类型。

进一步的，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，还包括：

指示所述第二作业平台将审批请求信息发送至所述联系客户端，并指示所述第二作业平台接收到所述联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

具体的，所述审批信息包括：审批请求题目、故障类型、故障位置以及审批链接。

具体的，所述审批链接为审批详情的地址链接，所述审批详情包括：自愈程序运行流程信息以及审批请求题目对应的审批请求内容。

第二方面，本发明实施例还提供了一种故障自愈装置，包括：

控制模块，用于控制第一作业平台查询故障事件；

自愈信息确定指示模块，用于指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台；

接口查找指示模块，用于指示所述第二作业平台根据所述自愈信息查找相应的应用程序编程接口API；

调用指示模块，用于指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

进一步的，所述装置还包括：

客户端查找模块，用于在指示所述第二作业平台根据所述自愈信息查找相应的API之后或之前，指示所述第二作业平台根据所述自愈信息查找相应的联系客户端；

条件确定模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用之后，指示所述第二作业平台确定满足通知生成条件；

通知信息发送模块，用于指示所述第二作业平台将通知信息发送至所述联系客户端。

进一步的，所述装置还包括：

请求信息发送模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，指示所述第二作业平台将审批请求信息发送至所述联系客户端；

故障清除模块，用于指示所述第二作业平台接收到所述联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

第三方面，本发明实施例还提供了一种服务器，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的故障自愈方法。

第四方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面中所述的故障自愈方法。

上述提供的故障自愈方法、装置、服务器及存储介质，通过控制第一作业平台查询故障事件；指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台；指示第二作业平台根据自愈信息查找相应的API；指示第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果的技术手段。通过多个故障自愈作业平台协同作业，解决了每个平台单独作业时存在的问题，例如，腾讯蓝鲸运维平台各流程节点间的数据无法传递、无法实现流程暂停并等待审批确认后继续执行的问题，以及stackstorm无法实现跨集群作业的问题，通过多个故障自愈作业平台之间相互协调作业，优化了自动化的故障自愈流程，同时，可以保证用户明确故障自愈的各节点，便于用户对故障自愈过程进行监控。

附图说明

图1是本发明实施例一中的故障自愈方法的流程图；

图2是本发明实施例二中的故障自愈方法的流程图；

图2a是本发明实施例二中的故障类型和故障位置的显示界面示意图；

图2b是本发明实施例二中的故障类型和自愈类型的显示界面示意图；

图3是本发明实施例三中的故障自愈方法的流程图；

图3a是本发明实施例三中的联系客户端通知信息的显示界面的示意图。；

图3b是本发明实施例三中的审批页面的显示示意图；

图3c是本发明实施例三中的联系客户端待审清单显示界面的示意图；

图4是本发明实施例四提供的故障自愈装置的结构示意图；

图5是本发明实施例五提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1是本发明实施例一中的故障自愈方法的流程图。本实施例可适用于设备故障恢复或自愈的情况，本实施例提供的故障自愈方法可以由故障自愈设备执行，该故障自愈设备可以通过软件和/或硬件的方式实现，该故障自愈设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。该故障自愈设备可以是计算机，笔记本电脑，手机，平板或交互智能平板等。在本实施例中，以计算机为故障自愈设备为例进行描述。

在本实施例中，计算机中可以安装有一个操作系统，也可以安装有多个操作系统，且具体的安装的操作系统的类型实施例不作限定。在计算机内部设置有第一作业平台、第二作业平台和第三作业平台集成的故障自愈平台。各作业平台可以通过应用程序的方式实现，各应用程序安装在操作系统中，其可以是操作系统自带的应用程序，也可以是计算机从第三方服务器中下载的应用程序。其中，第一作业平台是告警平台，其可以通过搜集监控系统发出的告警信息聚合成故障事件，并且可以将故障事件通知到对应的工作运维人员。第二作业平台是基于Apache License 2.0的自动化流程编排引擎，其包括：流程编排ActionChain和工作流程WorkFlow，其中，ActionChain和WorkFlow可以实现流程编排和流程各流程节点间的数据传递，同时基于审批模块Inquiry可实现流程暂停及审批确认后继续执行自愈流程。第三作业平台是可以实现流程编排与执行，同时可以跨集群执行远程作业，实施例中，第三作业平台是蓝鲸运维平台。需要说明的是，同一集群内的机器是可以直连互相访问的，不同集群间无法直连，想要互相访问必须使用代理。第三作业平台能够跨集群执行作业，是因为第三作业平台在部署代理Agent时，配置的Agent为可实现跨集群作业的Agent。具体的，跨集群作业是指一个或多个集群，不管从集群的内部和外部访问服务，都有一致的体验。例如，如果在国内部署作业任务，想要在美国服务器远程执行，第三作业平台会成功执行作业任务。

具体的，如图1所示，本实施例提供的故障自愈方法具体包括如下步骤：

S110、控制第一作业平台查询故障事件。

在实施例中，第一作业平台是指查询或者接收系统故障事件，并且对故障事件进行告警的告警平台。实施例中设定，第一作业平台是基于蓝鲸运维平台研发的告警平台。实际应用中，第一作业平台还可以是其他研发方式生成的平台。

具体的，故障事件包括但不限于：异常告警和健康预警。异常告警是指由于各种原因导致的业务异常、或伪业务异常。常见异常告警主要有：网络或互联网数据中心(Internet Data Center，IDC)异常导致的业务异常、关键模块性能问题导致的业务异常、主机硬件或系统异常导致的业务异常、以及无效误告引发的伪业务异常等。其中，主机硬件或系统异常导致的业务异常出现的比例最高。健康预警是指获取的系统的各类指标，各类指标用于对系统进行故障的评估和检测。可以理解的是，健康预警可以理解为系统的体检报告，用于在与指标值进行对比后，以便发现是否存在异常点，异常点即可视为故障事件。

进一步的，控制第一作业平台实时进行监控查询，以保证故障事件的实效性。例如，在发生异常告警时，向第一作业平台发送异常信息，以使第一作业平台查询到故障事件。又如，控制第一作业平台定时获取操作系统的各类指标，以确定是否查询到故障事件。

可选的，第一作业平台还可以向对应的人员发送故障事件。其中，故障事件的发送方式实施例不作限定。例如，通过向企业微信号发送故障事件。再如，通过预先存储的电话号码，以短信的方式发送故障事件。这样做的好处是，可以使人员快速明确故障事件。

S120、指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台。

在实施例中，第一作业平台根据故障事件可以确定故障描述、故障类型、故障等级、故障位置以及自愈信息等。其中，故障位置是指发生故障的机器的信息，例如可以是故障机器的IP地址、故障机器的MAC码等，也可以是故障机器中的虚拟存储器，如C盘、D盘等。故障类型是指根据故障发生的情况不同对故障进行的分类，例如是硬件故障、软件故障或者网络故障等，故障等级是指根据故障影响程度和紧急程度的评估制定的故障的优先级，即故障处理顺序。自愈信息是指用于执行自愈流程的相关信息。进一步的，自愈信息至少包括自愈类型和故障位置。自愈类型是指故障恢复需要执行的自愈流程的名称。其中，自愈类型与故障类型一一对应。

示例性的，第一作业平台根据故障事件确定故障类型以及故障位置为例进行描述。具体的，第一作业平台解析故障事件，获取故障事件中存储的故障类型以及故障位置，或者，第一作业平台在预设的第一数据库中进行查询，查询故障事件对应的故障类型，并且读取故障事件中的故障位置。其中，第一数据库中预先存储故障事件与故障类型的对应关系，进一步的，故障事件与故障类型的对应关系可以由程序开发人员进行设计，也可以由使用故障自愈设备的运维工作人员根据使用习惯进行设计。

具体的，第一作业平台根据故障类型查找对应的自愈类型可以是第一作业平台在预设的第二数据库中进行查询，查询故障类型对应的自愈类型，其中，第二数据库中预先存储故障类型与自愈类型的对应关系。可选的，第二数据库和第一数据库可以是相同的数据库或者是不同的数据库。进一步的，故障类型与自愈类型的对应关系可以由程序开发人员进行设计，也可以由使用故障自愈设备的运维工作人员根据使用习惯进行设计。

进一步的，第一作业平台将自愈类型以及故障位置封装成成一个数据包，并将数据包发送至第二作业平台。其中，具体的封装方式实施例不作限定。可选的，实施例中设定第二作业平台为Stackstorm。

S130、指示第二作业平台根据自愈信息查找相应的API。

在实施例中，API是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

具体的，第二作业平台接收第一作业平台发送的自愈信息，先判断自愈信息的类别是否为预设的可识别类别，当自愈信息的类别为预设的可识别类别时，获取自愈信息中的自愈类型以及故障位置。其中，预设的可识别类别是指第二作业平台中预先存储的可进行故障自愈的类别。进一步的，确定与自愈类型对应的API。其可以是预先存储各自愈类型与API的对应关系，之后通过对应关系确定与自愈类型对应的API。

典型的，API至少包括：通知API、第三作业平台API、审批请求API和审批响应API；通知API，用于将通知信息发送至客户端；第三作业平台API，用于对第三作业平台的自愈流程进行调用；审批请求API，用于将审批请求信息发送至客户端，其中，审批请求是指在执行故障自愈的过程中，需要经过工作人员审批通过之后才能继续执行，审批请求信息是指包含审批请求的信息，审批请求信息由第二作业平台根据第三作业平台返回的自愈结果确定。审批响应API，用于接收运维工作人员输入的与审批请求信息对应的信息，审批响应信息是指与审批请求信息对应的信息。API是指调用自愈程序的编程接口。实施例中，设定根据自愈类型确定API是指根据自愈类型确定第三作业平台API。例如，当第二作业平台接收到自愈信息后，根据自愈类型与第三作业平台API的对应关系查找第三作业平台API。同时，查找与该自愈类型对应的通知API，以实现将该自愈类型发送至对应的联系客户端。其中，联系客户端包括但不限于手机、笔记本电脑等。其中，不同自愈类型可以对应不同的通知API，也可以对应相同的通知API。进一步的，当第三作业平台的自愈程序执行过程中需要用户审批时，第二作业平台根据自愈类型调取相应的审批请求API和审批响应API，以通过审批请求API向联系客户端发送审批请求信息，并通过审批响应API接收联系客户端反馈的审批响应信息，进而将审批响应信息通过第三作业平台API通知第三作业平台的自愈程序，以便于自愈程序根据审批响应信息执行后续的自愈流程。

可选的，考虑到实际应用中，不同的故障位置可能会产生同一故障类型，那么在进行故障自愈时，同一自愈类型需要对应不同的故障位置，因此，在第二作业平台调取第三作业平台API时，需要自愈程序明确具体的故障位置。实施例中设定，每个自愈类型对应一个键值表达式。其中，键值表达式是自愈程序可识别的字符表达式。进一步的，将故障位置写入键值表达式中，以便于自愈程序确定具体的故障位置。其中，故障位置写入键值表达式的具体方式实施例不作限定，例如，键值表达式存在设定符号，该设定符号的位置用于添加故障位置。即在键值表达式中设定符号的位置添加故障位置的信息。

S140、指示第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果。

示例性的，自愈程序是指系统根据预设的程序修复故障的程序。其中，自愈程序由运维工作人员根据长期的经验积累得到，运维工作人员将大部分已经固化的告警排查和故障恢复，进行自动化处理，形成自愈程序，使得机器或者系统发生故障时，系统自动执行自愈程序，避免运维工作人员多次手动进行已经固化的告警排查和故障恢复，进而减少运维工作人员的工作强度。第三作业平台是指腾讯蓝鲸运维平台，其可以实现跨集群作业。

具体的，指示第二作业平台通过API对第三作业平台中的自愈程序进行调用，是指调用第三作业平台中的自愈程序来实现故障恢复和自愈，同时，不需要对第三作业平台已经成熟的自愈程序进行大范围的改写。第三作业平台执行自愈程序结束之后，将自愈程序的自愈结果发送至第二作业平台，第二作业平台获取自愈结果，并通过通知API将自愈结果发送至联系客户端。

本实施例通过控制第一作业平台查询故障事件，指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台，指示第二作业平台根据自愈信息查找相应的API，指示第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果的技术手段。实现了通过多个故障自愈作业平台协同作业，解决了每个平台单独作业时存在的问题，例如，腾讯蓝鲸运维平台各流程节点间的数据无法传递、无法实现流程暂停并等待审批确认后继续执行的问题，以及stackstorm无法实现跨集群作业的问题，通过多个故障自愈作业平台之间相互协调作业，优化自动化的故障自愈流程。

实施例二

图2是本发明实施例二中的故障自愈方法的流程图，本实施例在上述各实施例的基础上，进一步优化了故障自愈方法。如图2所示，优化后的故障自愈方法主要包括如下步骤：

S201、控制第一作业平台查询故障事件。

S202、指示第一作业平台根据故障事件确定故障类型以及故障位置。

具体的，指示第一作业平台对查询到的故障事件进行解析，以确定具体的故障类型以及故障位置。其中，具体的解析方式实施例不作先动。例如，根据故障事件确定计算机中C盘的最大容量为100G，当前实际容量为99.5G，那么可以确定故障位置为C盘，故障类型为磁盘空间不足。

S203、指示第一作业平台根据故障类型查找对应的自愈类型。

具体的，第一作业平台中预先存有各故障类型与自愈类型的对应关系，并根据对应关系确定当前的故障类型对应的自愈类型。

S204、指示第一作业平台将自愈类型以及故障位置封装成自愈信息并发送至第二作业平台。

其中，具体的封装方式可以根据实际情况设定。

可选的，在实际应用中，为了使联系客户端确定故障类型和故障位置，可以通过第一作业平台向联系客户端通知故障类型和故障位置。此时，第一作业平台和第二作业平台共有相同的通讯录，且第一作业平台同样可以根据自愈类型调取相应的通知API。其中，故障类型和故障位置在联系客户端的具体显示方式实施例不作限定。例如，图2a是本发明实施例二中的故障类型和故障位置的显示界面示意图。如图2a所示，在故障自愈的过程中，第一作业平台在计算机界面显示故障类型以及故障位置，以便于运维工作人员通过计算机的界面查询故障事件。需要说明的是，图2a仅以名称为磁盘空间不足告警的故障类型为例进行说明。在图2a中，“添加告警类型”是故障自愈流程过程中，确定故障类型的流程节点的名称。添加告警类型是指第一作业平台根据故障事件确定故障类型以及故障位置的过程，“键值表达式支持通配符匹配并提取参数，例如：当表达式为disk.io[*,*],提取参数为：disk1，disk2时，可以匹配disk.io[vda,vdb],且disk1＝vda，disk2＝vdb”是对“添加告警类型”这个流程节点功能的解释说明。“名称”下方的文本框中的内容表示故障类型的名称。图2a中的故障类型的名称为：磁盘空间不足告警。键值表达式表示的是故障类型的字符表达式。进一步的，故障类型的名称与键值表达式一一对应。“提取参数”下方的文本框中需要输入故障位置。“请输入参数变量”用于提示运维工作人员需要输入的内容。进一步的，本实施例中的提取参数由第一作业平台根据故障事件确定。“确认”和“取消”是两个可以点击的按钮，当第一作业平台检测到“确认”按钮被点击后，在后续执行自愈流程中，默认使用运维工作人员在“请输入参数变量”中输入的内容，当第一作业平台检测到“取消”按钮被点击后，在后续执行自愈流程中，默认使用自愈程序原始的参数。

需要说明的是，实际应用中，第一作业平台通过计算机显示故障类型和故障位置后，还可以通过计算机显示故障类型和自愈类型。具体的，图2b是本发明实施例二中的故障类型和自愈类型的显示界面示意图。图2b仅以磁盘空间不足告警的故障事件为例进行说明。在图2b中，“告警名称”后方的文本框中的内容表示故障类型的名称。图2b中的故障类型的名称为：磁盘空间不足告警。“自愈类型”后方的文本框中的内容表示与故障类型对应的自愈类型。此时，磁盘空间不足告警对应的自愈类型是：bk_job_api.disk_alert。“参数列表”后方的文本框中的内容表示故障位置。需要说明的是，图2b中并未添加具体的故障位置。“状态”后方的文本框中的内容表示自愈信息的类别。自愈信息的类别由第一作业平台根据自愈类型进行自动识别并添加。

S205、指示第二作业平台获取自愈信息中的自愈类型以及故障位置。

具体的，第二作业平台接收第一作业平台发送的自愈信息后，对自愈信息进行解析，以得到自愈信息中的自愈类型和故障位置。其中，对自愈信息进行解析的过程可以理解为解封装的过程。

S206、指示第二作业平台查找与自愈类型对应的API及键值表达式，键值表达式表示故障类型。

具体的，设定第二作业平台查找的API为第三作业平台API。当第二作业平台工作通过API调用自愈程序时，需要让自愈程序明确具体的故障位置。据此，实施例引入了键值表达式。其中，键值表达式预先存在第二作业平台中，每个自愈类型均有对应的键值表达式。一般而言，键值表达式为预先设定好的字符表达式。键值表达式包括设定符号和预设字符串，其中，预设字符串用于表示故障类型，其通常是不可变的，设定符号是用于进行替换的字符。例如，磁盘空间不足的故障事件时，故障位置作为关键参数将会被第一作业平台提取，并和自愈类型一同发送至第二作业平台。第二作业平台根据自愈类型查找到对应的键值表达式为vfs.fs.size[*,free]，其中，键值表达式中包括设定符号“*”，设定符号所代表的部分为可替换的字符，即可以将“*”替换为故障位置。需要说明的是，运维工作人员可以根据实际需要设计其他的设定符号，例如“#”、“@”或“&”等特殊符号。

进一步的，为了保证第二作业平台接收到的自愈类型为自身可处理的类型，实施例中设定在指示第二作业平台查找与自愈类型对应的API及键值表达式之前还包括：指示第二作业平台确定自愈信息的类别为预设的可识别类别。

具体的，自愈信息的类别表示当前自愈信息所属的类别，其可以根据自愈类型确定。其具体的分类方式可以根据实际情况设定。例如，根据自愈类型确定故障位置属于固定位置，此时，将该类自愈信息归为一类。同时，根据自愈类型确定故障位置不固定。例如，磁盘空间不足可以对应C盘、D盘等，此时，将该类自愈信息归为一类。通常，对自愈信息进行分类后，在第二作业平台中对将各类别存储为可识别类别，即第二作业平台可以识别该自愈信息，进而执行后续操作。

典型的，当第二作业平台接收到自愈信息后，指示第二作业平台根据自愈信息的自愈类型确定该自愈信息的类别，并确定该自愈信息的类别是否属于可识别类别，若是，则执行S206，否则，指示第二作业平台向第一作业平台发送不可识别信息，以提示第一作业平台当前故障事件不可自愈。

例如，磁盘空间不足时，自愈信息对应的可识别类别为enabled。此时，第二作业平台可以通过如下的程序确定自愈信息的类别为预设的可识别类别。ItemKeyActionChain.Objects，filter(status＝‘enabled’)。进一步的，当第二作业平台确定自愈信息为可识别类别enable后，执行S206。

S207、指示第二作业平台将故障位置写入键值表达式。

在本实施例中，键值表达式包括设定符号，设定符号用于指示故障位置。具体的，指示第二作业平台将故障位置写入设定符号所在的位置，以便于第三作业平台API所调用的自愈程序可以识别该键值表达式，进而确定故障位置。

进一步的，该步骤具体包括：

S2071、指示第二作业平台将预设字符替换键值表达式的设定符号中，以得到目标表达式。

具体的，预设字符是可以为自愈程序识别的，表示故障位置的字符。此时，无论故障位置是否变化，该预设字符不变。进一步的，预设字符的具体内容可以根据实际情况设定，只需可别自愈程序识别为表示故障位置的字符即可。典型的，进行字符替换后，将得到表达式记为目标表达式。

S2072、指示第二作业平台利用正则表达式对目标表达式中的预设字符进行识别，以确定预设字符对应的故障位置。

具体的，正则表达式是计算机科学的一个概念。通常被用来检索、替换那些符合某个规则的文本。实施例中，指示第二作业平台利用正则表达式思想，对目标表达式进行识别。进一步的，对目标表达式识别后，便可以检索出目标表达式中的预设字符，进而对预设字符进行识别便可以确定该预设字符标识某一故障位置。

S2073、指示第二作业平台将故障位置与预设字符进行关联。

进一步的，将预设字符与自愈流程中的故障位置进行关联。以保证自愈程序在读到预设字符后，可以根据预设字符与故障位置的关联关系确定具体的故障位置。

可选的，上述对键值表达式中设定字符进行替换的过程通过如下程序来实现：

rex＝re,compile(item_key_action_chain,item_key,teigger_key,replace(“*”,“(\S+)”),replace(“[”,“\[”),replace(“]”,“\]”))；

res＝re,search(rex,item_key)。

S208、指示第二作业平台通过API对第三作业平台中的自愈程序进行调用。

具体的，该API表示第三作业平台API。

S209、指示第二作业平台将写入故障位置的键值表达式作为自愈程序的输入。

具体的，写入故障位置的键值表达式可以理解为带有与故障位置关联的预设符号的目标表达式。进一步的，指示第二作业平台将写入故障位置的键值表达式作为自愈程序的输入，以在第三作业平台运行自愈程序时，确定需要明确故障位置时，可以通过调用写入故障位置的键值表达式确定具体的故障位置。

S210、指示第二作业平台获取自愈程序运行的自愈结果，自愈结果是第三作业平台对自愈程序运行后的返回值进行编译的结果。

在本实施例中，自愈结果是指第三作业平台执行自愈程序得到的结果，自愈结果可以是自愈程序某个中间节点执行的结果，也可以是自愈程序执行结束后将故障恢复的情况。第二作业平台通过自愈结果可以掌握当前自愈程序的执行情况。一般而言，第三作业平台运行自愈程序后，得到的结果为一个或一串字符，实施例中将该结果记为返回值。为了保证第二作业平台准备识别该返回值，需要对返回值进行编译，以得到自愈结果。其中，编译的具体过程可以根据实际情况进行设定。一般而言，编译规则中包括在自愈结果中添加开始标记，以便第二作业平台明确自愈结果的具体位置。

S211、指示第二作业平台读取自愈结果中的开始标记。

具体的，指示第二作业平台对自愈结果进行反编译处理。一般而言，第二作业平台和第三作业平台共享编译规则，以便于第二作业平台准确识别自愈结果。进一步的，根据S210中的描述可知，自愈结果中添加了开始标记。因此，在执行本步骤时，指示第二作业平台识别自愈结果中的开始标记。通常，第二作业平台预先明确开始标记的具体内容。进一步的，如果第二作业平台识别到开始标记，则确认获取到自愈结果，否则，指示第二作业平台向第三作业平台进行反馈，以使第三作业平台明确自愈结果识别失败。

具体的，实施例中设定，编辑规则中对于一行和多行的返回值进行编译时，开始标记的具体内容不同，此时，设定一行返回值对应的开始标记为第一开始标记，多行返回值对应的开始标记为第二开始标记。因此，第二作业平台在识别开始标记时，可以同步确定开始标记的具体内容，以确定该开始标记属于第一开始标记还是第二开始标记。若是第一开始标记，则执行S211。若是第二开始标记，则执行S212。

S211、若开始标记为第一开始标记，则指示第二作业平台从第一开始标记开始，读取第一标记符号所在行的程序信息，以实现对自愈结果的识别。

具体的，若开始标记为第一开始标记，则第二作业平台可以根据编辑规则确定返回值仅有一行字符，因此，指示第二作业平台从第一开始标记开始，读取第一标记符号所在行的程序信息确定为自愈结果的具体内容，进而对上述程序信息进行识别，以实现识别自愈结果。

S212、若开始标记为第二开始标记，则指示第二作业平台读取第二开始标记之后的程序信息，若是读取到结束标记，则指示第二作业平台将第二开始标记与结束标记之间的程序信息，以实现对自愈结果的识别。

具体的，若开始标记为第二开始标记，则第二作业平台可以根据编辑规则确定返回值有多行字符。此时，指示第二作业平台继续读取第二开始标记之后的程序信息，并在识别到结束标记时，确定读取完毕。其中，第三作业平台和第二作业平台共享结束标记的具体内容，并将结束标记作为指示自愈结果结束的标记。进一步的，第二作业平台读取到结束标记后，获取第二开始标记与结束标记之间的程序信息，并对该程序信息进行识别，以实现对自愈结果的识别。

例如，第三作业平台支持shell，python，perl等脚本，常用的以linux shell为主，此时，设定以shell脚本为例，制定一个第三作业平台对自愈程序运行后的返回值进行编译的规则。此时，设定若第三作业平台对自愈程序运行后的返回值为一行内容时，该行以“＝＝st2.cmd.var＝＝”开头，设定第三作业平台对自愈程序运行后的返回值为多行内容时，返回值以“＝＝st2.cmd.express.start＝＝”开始，以”＝＝st2.cmd.express.end＝＝”结束。

此时，若第二作业平台读取到line.startswith(‘＝＝st2.cmd.var＝＝’)，则仅仅将line.startswith(‘＝＝st2.cmd.var＝＝’)之后的一行程序信息作为自愈结果。若读取到line.startswith(‘＝＝st2.cmd.express.start＝＝’)，则第二作业平台将读取到line.startswith(‘＝＝st2.cmd.express.start＝＝’)之后的多行程序内容，直至读取到结束标记line.startswith(‘＝＝st2.cmd.express.end＝＝’)后，停止独权，此时，第二作业平台将第二开始标记line.startswith(‘＝＝st2.cmd.express.start＝＝’)和结束标记line.startswith(‘＝＝st2.cmd.express.end＝＝’)之间的所有程序信息作为自愈结果。

可选的，由于第二作业平台通过API调用第三作业平台中的自愈程序进行故障自愈，因此，为了保证自愈流程的安全性，实施例中设定第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果之前，包括：指示第二作业平台对第三作业平台进行鉴权。

具体的，鉴权是指验证访问者是否拥有访问系统的权利。实施例中，第二作业平台对第三作业平台进行鉴权是指第二作业平台确认是否有访问第三作业平台的权利。其中，具体的鉴权内容可以根据实际情况进行设定，如通过密码进行鉴权。具体的，若第二作业平台有调用第三作业平台的权限，则执行S208。若第二作业平台没有调用第三作业平台的权限，则第二作业平台停止通过API对第三作业平台中的自愈程序进行调用。这样可以避免没有工作权限的用户调用第三作业平台中的自愈程序，保证了工作平台和系统的安全性。

本实施例中通过第二作业平台获取自愈信息中的自愈类型以及故障位置；并查找与自愈类型对应的API及键值表达式，将故障位置写入键值表达式，然后第二作业平台通过API对第三作业平台中的自愈程序进行调用；并将写入故障位置的键值表达式作为自愈程序的输入；最后获取自愈程序运行的自愈结果的技术手段，通过多个故障自愈作业平台协同作业，解决了每个平台单独作业时存在的问题，例如，腾讯蓝鲸运维平台各流程节点间的数据无法传递、无法实现流程暂停并等待审批确认后继续执行的问题，以及stackstorm无法实现跨集群作业的问题，通过多个故障自愈作业平台之间相互协调作业，优化了自动化的故障自愈流程，同时，可以保证用户明确故障自愈的各节点，便于用户对故障自愈过程进行监控。

实施例三

图3是本发明实施例三中的故障自愈方法的流程图，本实施例在上述各实施例的基础上，进一步优化了故障自愈方法。如图3所示，优化后的故障自愈方法主要包括如下步骤：

S310、控制第一作业平台查询故障事件。

S320、指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台。

S330、指示第二作业平台根据自愈信息查找相应的联系客户端。

需要说明的是，该步骤也可以在S340之后执行，实施例不作限定。

具体的，联系客户端是指运维工作人员所使用的客户端。第二作业平台中预先存有各联系客户端的联系地址。可选的，由于不同的自愈类型可能需要不同的运维工作人员进行运维，因此，设定不同的自愈类型对应的联系客户端可以不同。此时，可以指示第二作业平台根据自愈信息中的自愈类型确定对应的联系客户端。同样的，也可以设定所有自愈类型对应相同的联系客户端。此时，可以指示第二作业平台接收到自愈信息后，确定全部的联系客户端。

S340、指示第二作业平台根据自愈信息查找相应的API。

S350、指示第二作业平台通过API对第三作业平台中的自愈程序进行调用。

S360、指示第二作业平台确定满足通知生成条件。

其中，通知生成条件是指自愈程序进行中需要向联系客户端进行自愈节点汇报的条件，其具体的内容可以根据实际情况设定。实施例中，设定通知生成条件包括：自愈程序中子节点完成运行。一般而言，自愈程序在运行过程中，其包括多个子节点。因此，实施例中设定每个子节点运行完成后，第三作业平台向第二作业平台发送子节点完成的相关信息，以使第二作业平台确定满足通知生成条件。

S370、指示第二作业平台将通知信息发送至联系客户端。

具体的，当第二作业平台确定满足通知生成条件后，生成通知信息，并将通知信息发送至联系客户端。其中，第二作业平台通过通知API接口向联系客户端发送的通知信息。

进一步的，通知信息是指使联系客户端明确子节点具体的运行情况的信息。其具体内容可以根据实际情况设定。在本实施例中，通知信息包括：自愈程序的ID，子节点的运行起始时间和结束时间以及故障类型。其中，每个自愈程序均有对应的ID，第二作业平台通过第三作业平台API调用自愈程序时，可以确定其ID。子节点的运行起始时间和结束时间可以由第三作业平台通知第二作业平台。具体的，通知信息的具体封装方式实施例不作限定。

可选的，指示第二作业平台将通信信息发送至联系客户端可以是发送至联系客户端的微信公众号中，或者是以短信的方式发送至联系客户端中。

举例而言，当第二作业平台确定满足通知生成条件后，通过“core.st2.generic.inquiry”事件的触发器实现向联系客户端发送通知信息。具体的，当触发“core.st2.generic.inquiry”事件时，第二作业平台确传递trigger.id和trigger.route两个参数给联系客户端。此时，在第二作业平台查找到相应的联系客户端之后，将自愈流程ID和联系客户端的联系地址放在trigger.route中，进而实现向通知客户端发送自愈流程ID。进一步的，自愈流程ID和联系地址之间采用第一符号进行分开，以便于触发器识别自愈流程ID和联系地址。其中，第一符号可以根据实际情况设定，例如第一符号为冒号。若存在多个联系客户端，则将各联系客户端的联系地址之间采用第二符号进行分开，其中，第二符号可以根据实际情况设定，例如第二符号为分号。需要说明的是，联系地址的具体内容可以根据实际情况设定，如联系名称或IP地址等。

此时，将自愈流程ID和联系地址只能放在trigger.route可以采用如下程序实现：route:”{{action_context.parent_id}}:{{unames}}”。

S380、指示第二作业平台获取自愈结果。

S390、指示第二作业平台将审批请求信息发送至联系客户端。

在本实施例中，审批请求是指在执行故障自愈的过程中，需要经过工作人员审批通过之后才能继续执行。审批请求信息是指包含审批请求的信息。实施例中设定，审批请求信息至少包括：审批请求题目、故障类型、故障位置以及审批链接中的至少一种，实际应用中，还包括其他的内容。审批请求题目是指发送至联系客户端的审批请求信息的题目，其中审批请求题目由自愈结果决定。例如，审批请求题目可以是“是否删除占用内存最多的进程？”。审批链接为审批详情的地址链接，审批详情包括：自愈程序运行流程信息以及审批请求题目对应的审批请求内容。其中，自愈程序的运行流程信息是指在自愈程序的运行过程中生成的，表示具体运行流程的信息。审批请求题目对应的审批请求内容是指审批请求的具体内容。例如，审批请求题目是“是否删除占用内存最多的进程？”时，审批请求内容可以包括希望删除的进程的相关详细信息，如进程题目、进程类型、进行占用的具体内存等。

可选的，指示第二作业平台发送审批请求信息时，在联系客户端中同时显示审批结果的虚拟按键。实施例中，设定虚拟按键包括审批和驳回。其中，审批表示运维工作人员同意该自愈结果，驳回表示运维工作人员不同意该自愈结果。此时，运维工作人员不必输入繁复的控制指令，使得审批过程更加的方便快捷，节省工作时间。

举例而言，图3a是本发明实施例三中的联系客户端通知信息的显示界面的示意图。如图3a所示，区域301表示自愈开始这个节点对应的通知信息，其主要包括：节点信息为自愈开始，故障位置为site-monitor-10.31.55.7，其为故障主机的名称，故障类型为site-monitor-127.0.0.1-test_err_msg。区域302表示的是审批请求信息在联系客户端的显示内容。主要包括审批请求信息的题目为“是否删掉多占用内存最多的进程？”，故障位置为site-monitor-10.31.55.7，故障类型为site-monitor-127.0.0.1-test_err_msg。“点击进入审批页面”是审批详情，即审批详情的地址链接，点击可以进入为审批详情页。

图3b是本发明实施例三中的审批页面的显示示意图。如图3b所示，审批页面中包括：自愈程序运行流程信息以及审批请求题目对应的审批请求内容。其中，自愈程序运行流程信息包括创建时间和状态，创建时间表示自愈程序的子节点的执行时间，状态表示的是子节点的执行状态，其可以是成功、等待或者失败等。具体的，区域311中的“开始”表示是开始运行自愈程序的子节点，“创建：2018-06-20 18:09:12”表示执行该子节点的开始时间为2018-06-20 18:09:12。“状态：succeeded”表示开始节点执行成功。区域312中的“统计TOP10内存”表示是执行自愈程序中统计TOP10内存的子节点，“创建：2018-06-20 18:09:13”表示该子节点的开始时间为2018-06-20 18:09:13。“状态：succeeded”表示统计TOP10内存的动作是执行成功的。区域313表示的审批请求内容，“创建：2018-06-20 18:09:17”表示审批请求消息的创建时间为2018-06-20 18:09:13。“状态：peding”表示目前在等待运维工作人员进行审批。“审批：[必填]：ture”表示在审批过程中必须填入ture，自愈流程才会继续执行。“[类型]：string”表示审批的类型为string。“[描述]是否删掉多占用内存最多的进程？”表示审批内容的中文描述。“审批”和“驳回”表示两个虚拟按键，运维工作人员可以根据自愈流程的执行情况和服务器工作的详情，进行判断并选择。运维工作人员点击“审批”按键表示通过审批，此时，自愈流程继续执行，运维工作人员点击“驳回”按钮表示没通过审批，此时，自愈流程中断执行。需要说明的是，图3b中审批请求题目和审批的中文描述内容相同，实际应用中，也可以不同。

S3100、指示第二作业平台接收到联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

在本实施例中，审批响应信息是指运维工作人员在联系客户端输入的信息，实施例中设定审批响应信息是指运维工作人员同意自愈结果。进一步的，第二作业平台接收到审批响应信息后，根据自愈结果进行故障清除。以审批请求信息的题目为：是否删掉多占用内存最多的进程为例，此时，第二作业平台根据自愈结果进行故障清除只是删掉多占用内存最多的进程。其中，故障清除由第二作业平台通过调用第三作业平台的自愈程序来完成，当故障清理完毕之后，第三作业平台将故障清理完毕的信息返回值第二作业平台，第二作业平台再次调用通知API将自愈结束的信息发送至联系客户端，至此，故障自愈流程执行完毕。

可选的，实际应用中，第二作业平台也可以接收到拒绝执行自愈结果的信息，此时，第二作业平台停止调用第三作业平台的自愈程序。

进一步的，第二作业平台在第一预设时间内没有接收到联系客户端返回的审批响应信息时，将审批请求信息存放至待审清单，等待运维工作人员进行审核。若放入待审清单后，第二作业平台在第二预设时间内依旧没有接收到联系客户端返回的审批响应信息，则根据计算机操作系统预设的程序继续执行故障自愈流程或者退出故障自愈流程。其中，待审清单用于存放审批请求信息，以防止运维工作人员错过审批请求信息。第一预设时间和第二预设时间可以根据实际情况设定。例如，图3c是本发明实施例三中的联系客户端待审清单显示界面的示意图。如图3c所示，待审清单中显示审批请求信息时，显示的具体内容包括故障位置、故障类型和审批请求题目对应的审批请求内容。需要说明的是，图3c中仅以待审清单中存在一个审批请求信息为例，进行说明。实际应用中，待审清单中存在多个审批请求信息时，多个审批请求信息依次排列显示在待审清单中。可选的，图3c页面顶部还设置有“执行详情”和“待审清单”的按钮，通过上述两个按钮可以在通知信息的显示界面和待审批清单的显示界面可以进行切换。

本实施例通过第一作业平台查询故障事件，根据故障事件确定自愈信息并发送至第二作业平台；第二作业平台根据自愈信息查找相应的联系客户端和API，通过API对第三作业平台中的自愈程序进行调用以获取自愈结果；然后确定满足通知生成条件；将通知信息发送至联系客户端；并且第二作业平台将审批请求信息发送至联系客户端并接收客户端反馈的审批响应信息时，根据自愈结果进行故障清除的技术手段，将自愈流程的节点通知信息和审批请求信息发送至客户端，并接收客户端的反馈信息，根据反馈信息清楚故障，实现了审批结束之后继续实行自愈流程，且实现了多个自愈作业平台之间相互协调作业。

实施例四

图4是本发明实施例四提供的故障自愈装置的结构示意图，本实施例可适用于系统的故障恢复或者故障自愈的情况，如图4所示，该故障自愈装置的主要包括如下结构：

控制模块401，用于控制第一作业平台查询故障事件。

自愈信息确定指示模块402，用于指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台。

接口查找指示模块403，用于指示第二作业平台根据所述自愈信息查找相应的API。

调用指示模块404，用于指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

本实施例通过控制第一作业平台查询故障事件，指示第一作业平台根据故障事件确定自愈信息并将自愈信息发送至第二作业平台，指示第二作业平台根据自愈信息查找相应的应用程序编程接口API，指示第二作业平台通过API对第三作业平台中的自愈程序进行调用以获取自愈结果的技术手段。通过多个故障自愈作业平台协同作业，解决了每个平台单独作业时存在的问题，例如，腾讯蓝鲸运维平台各流程节点间的数据无法传递、无法实现流程暂停并等待审批确认后继续执行的问题，以及stackstorm无法实现跨集群作业的问题，通过多个故障自愈作业平台之间相互协调作业，优化了自动化的故障自愈流程，同时，可以保证用户明确故障自愈的各节点，便于用户对故障自愈过程进行监控。

进一步的，自愈信息确定指示模块402包括：

类型及位置确定单元，用于指示所述第一作业平台根据所述故障事件确定故障类型以及故障位置。

自愈类型查找单元，用于指示所述第一作业平台根据所述故障类型查找对应的自愈类型。

自愈信息封装单元，用于指示所述第一作业平台将所述自愈类型以及故障位置封装成自愈信息并发送至第二作业平台。

进一步的，所述接口查找指示模块403包括：

类型及位置获取单元，用于指示所述第二作业平台获取所述自愈信息中的自愈类型以及故障位置。

API查找单元，用于指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式，所述键值表达式表示所述故障类型。

写入单元，用于指示所述第二作业平台将所述故障位置写入所述键值表达式。

优选的，所述键值表达式包括设定符号，所述设定符号用于指示故障位置。

相应的，所述写入单元包括：

替换子单元，用于指示所述第二作业平台将预设字符替换所述键值表达式的设定符号中，以得到目标表达式。

识别子单元，用于指示所述第二作业平台利用正则表达式对所述目标表达式中的预设字符进行识别，以确定所述预设字符对应的故障位置。

关联子单元，用于指示所述第二作业平台将所述故障位置与所述预设字符进行关联。

进一步的，所述接口查找指示模块403还包括：

类型确定单元，用于在指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式之前，指示所述第二作业平台确定所述自愈信息的类别为预设的可识别类别。

进一步的，所述调用指示模块404包括：

第三作业平台调用单元，用于指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用。

输入单元，指示所述第二作业平台将写入故障位置的键值表达式作为所述自愈程序的输入。

获取单元，用于指示第二作业平台获取自愈程序运行的自愈结果，所述自愈结果是所述第三作业平台对所述自愈程序运行后的返回值进行编译的结果。

进一步的，所述调用指示模块404还包括：

开始标记读取单元，用于指示所述第二作业平台读取所述自愈结果中的开始标记。

第一程序信息读取单元，若所述开始标记为第一开始标记，则指示第二作业平台从第一开始标记开始，读取第一标记符号所在行的的程序信息，以实现对所述自愈结果的识别。

第二程序信息读取单元，用于若所述开始标记为第二开始标记，则指示第二作业平台读取所述第二开始标记之后的程序信息，若是读取到结束标记，则则指示第二作业平台将第二开始标记与结束标记之间的程序信息作为自愈结果，以实现对所述自愈结果的识别。

进一步的，所述调用指示模块404还包括：

鉴权单元，用于指示所述第二作业平台对所述第三作业平台进行鉴权。

进一步的，所述装置还包括：

客户端查找模块，用于在指示所述第二作业平台根据所述自愈信息查找相应的API之后或之前，指示所述第二作业平台根据所述自愈信息查找相应的联系客户端。

条件确定模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用之后，指示所述第二作业平台确定满足通知生成条件。

通知信息发送模块，用于指示所述第二作业平台将通知信息发送至所述联系客户端。

具体的，所述通知生成条件包括：自愈程序中子节点完成运行。

具体的，所述通知信息包括：自愈程序的ID，所述子节点的运行起始时间和结束时间以及所述故障类型。

进一步的，所述装置还包括：

请求信息发送模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，指示所述第二作业平台将审批请求信息发送至所述联系客户端。

故障清除模块，用于指示所述第二作业平台接收到所述联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

具体的，所述审批信息包括：审批请求题目、故障类型、故障位置以及审批链接。

具体的，所述审批链接为审批详情的地址链接，所述审批详情包括：自愈程序运行流程信息以及审批请求题目对应的审批请求内容。

本发明实施例所提供的故障自愈装置集成在故障自愈设备中，可执行本发明任意实施例所提供的故障自愈方法，具备执行方法相应的功能模块和有益效果。

实施例五

图5为本发明实施例五提供的一种服务器示意图，如图5所示，该服务器包括处理器510、存储器520、输入装置530和输出装置540；该服务器中的处理器510的数量可以是一个或多个，图5中以一个处理器510为例；该服务器中的处理器510、存储器520、输入装置530和输出装置540可以通过总线或其他方式连接，图5中以通过总线连接为例。

存储器520作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的故障自愈方法对应的程序指令/模块(例如，故障自愈装置中的控制模块、自愈信息确定指示模块、接口查找指示模块和调用指示模块)。处理器510通过运行存储在存储器520中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的故障自愈方法。

存储器520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器520可进一步包括相对于处理器510远程设置的存储器，这些远程存储器可以通过网络连接至服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置530可用于接收输入的数字或字符信息，以及产生与服务器的用户设置以及功能控制有关的键信号输入。输出装置540可包括显示屏等显示设备。

本发明实施例所提供的服务器可执行本发明任意实施例所提供的故障自愈方法，具备执行方法相应的功能模块和有益效果。

实施例六

本发明实施例六还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如实现本发明实施例所提供的故障自愈方法，所述方法包括：

控制第一作业平台查询故障事件；

指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台；

指示所述第二作业平台根据所述自愈信息查找相应的应用程序编程接口API；

指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (19)

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

控制第一作业平台查询故障事件；

指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台；

指示所述第二作业平台根据所述自愈信息查找相应的应用程序编程接口API；

指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

2.根据权利要求1所述的故障自愈方法，其特征在于，所述指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台包括：

指示所述第一作业平台根据所述故障事件确定故障类型以及故障位置；

指示所述第一作业平台根据所述故障类型查找对应的自愈类型；

指示所述第一作业平台将所述自愈类型以及故障位置封装成自愈信息并发送至第二作业平台。

3.根据权利要求2所述的故障自愈方法，其特征在于，所述指示所述第二作业平台根据所述自愈信息查找相应的API包括：

指示所述第二作业平台获取所述自愈信息中的自愈类型以及故障位置；

指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式，所述键值表达式表示所述故障类型；

指示所述第二作业平台将所述故障位置写入所述键值表达式。

4.根据权利要求3所述的故障自愈方法，其特征在于，所述键值表达式包括设定符号，所述设定符号用于指示故障位置；

所述指示所述第二作业平台将所述故障位置写入所述键值表达式包括：

指示所述第二作业平台将预设字符替换所述键值表达式的设定符号中，以得到目标表达式；

指示所述第二作业平台利用正则表达式对所述目标表达式中的预设字符进行识别，以确定所述预设字符对应的故障位置；

指示所述第二作业平台将所述故障位置与所述预设字符进行关联。

5.根据权利要求3所述的故障自愈方法，其特征在于，所述指示所述第二作业平台查找与所述自愈类型对应的API及键值表达式之前，还包括：

指示所述第二作业平台确定所述自愈信息的类别为预设的可识别类别。

6.根据权利要求3所述的故障自愈方法，其特征在于，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果包括：

指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用；

指示所述第二作业平台将写入故障位置的键值表达式作为所述自愈程序的输入；

指示第二作业平台获取自愈程序运行的自愈结果，所述自愈结果是所述第三作业平台对所述自愈程序运行后的返回值进行编译的结果。

7.根据权利要求1所述的故障自愈方法，其特征在于，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，还包括：

指示所述第二作业平台读取所述自愈结果中的开始标记；

若所述开始标记为第一开始标记，则指示第二作业平台从第一开始标记开始，读取第一标记符号所在行的程序信息，以实现对所述自愈结果的识别；

若所述开始标记为第二开始标记，则指示第二作业平台读取所述第二开始标记之后的程序信息；

若是读取到结束标记，则指示第二作业平台将第二开始标记与结束标记之间的程序信息作为自愈结果，以实现对所述自愈结果的识别。

8.根据权利要求1所述的故障自愈方法，其特征在于，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之前包括：

指示所述第二作业平台对所述第三作业平台进行鉴权。

9.根据权利要求1所述的故障自愈方法，其特征在于，所述指示所述第二作业平台根据所述自愈信息查找相应的API之后或之前，还包括：

指示所述第二作业平台根据所述自愈信息查找相应的联系客户端；

所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用之后，还包括：

指示所述第二作业平台确定满足通知生成条件；

指示所述第二作业平台将通知信息发送至所述联系客户端。

10.根据权利要求9所述的故障自愈方法，其特征在于，所述通知生成条件包括：自愈程序中子节点完成运行。

11.根据权利要求10所述的故障自愈方法，其特征在于，所述通知信息包括：自愈程序的ID，所述子节点的运行起始时间和结束时间以及所述故障类型。

12.根据权利要求9所述的故障自愈方法，其特征在于，所述指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，还包括：

指示所述第二作业平台将审批请求信息发送至所述联系客户端，并指示所述第二作业平台接收到所述联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

13.根据权利要求12所述的故障自愈方法，其特征在于，所述审批请求信息包括：审批请求题目、故障类型、故障位置以及审批链接。

14.根据权利要求13所述的故障自愈方法，其特征在于，所述审批链接为审批详情的地址链接，所述审批详情包括：自愈程序运行流程信息以及审批请求题目对应的审批请求内容。

15.一种故障自愈装置，其特征在于，包括：

控制模块，用于控制第一作业平台查询故障事件；

自愈信息确定指示模块，用于指示所述第一作业平台根据所述故障事件确定自愈信息并将所述自愈信息发送至第二作业平台；

接口查找指示模块，用于指示所述第二作业平台根据所述自愈信息查找相应的应用程序编程接口API；

调用指示模块，用于指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果。

16.根据权利要求15所述的故障自愈装置，其特征在于，还包括：

客户端查找模块，用于在指示所述第二作业平台根据所述自愈信息查找相应的API之后或之前，指示所述第二作业平台根据所述自愈信息查找相应的联系客户端；

条件确定模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用之后，指示所述第二作业平台确定满足通知生成条件；

通知信息发送模块，用于指示所述第二作业平台将通知信息发送至所述联系客户端。

17.根据权利要求16所述的故障自愈装置，其特征在于，还包括：

请求信息发送模块，用于在指示所述第二作业平台通过所述API对第三作业平台中的自愈程序进行调用以获取自愈结果之后，指示所述第二作业平台将审批请求信息发送至所述联系客户端；

故障清除模块，用于指示所述第二作业平台接收到所述联系客户端反馈的审批响应信息时，根据自愈结果进行故障清除。

18.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-14中任一所述的故障自愈方法。

19.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-14中任一所述的故障自愈方法。