故障修复方法、装置、计算机设备及存储介质与流程

本公开涉及互联网技术领域，尤其涉及一种故障修复方法、装置、计算机设备及存储介质。

背景技术：

dns(domainnamesystem，域名系统)是因特网的一项核心服务，它作为可以将域名和ip(internetprotocol，互联网协议)地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网。当dns发生故障时，会导致用户无法正常浏览网页，且dns服务为基础服务，大量服务依赖dns服务，如果dns异常，下游会出现雪崩式的异常。因此，当dns发生故障时，需要尽快解决，减少对用户的影响。

相关技术中，是由监控系统监测dns是否出现故障，当监控系统监测到dns出现故障时，会发出报警信息，管理人员在接收到报警信息之后，手动对故障进行修复处理。

但是，管理人员在接收到报警信息之后，对故障进行修复处理的时间不可控，可能会由于一些特殊原因，管理人员并不能及时对故障进行修复处理，另外，管理人员需要检查发生dns在哪个位置发生了故障，发生的故障类型，并采取相应的措施进行解决，从故障开始至故障修复结束耗时较久，对用户的正常使用影响较大。

技术实现要素：

本公开提供一种故障修复方法、装置、计算机设备及存储介质，以至少解决相关技术中人工修复dns速度较慢，影响用户正常使用的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种故障修复方法，包括当确定域名系统dns发生故障时，根据故障发生对应的目标时间段的日志数据，获取所述故障的故障特征；

根据所述故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定所述故障的故障类型；

根据所述故障类型，从故障类型和修复处理信息的对应关系中，确定所述故障类型对应的修复处理信息，所述修复处理信息包括所述故障的可能定位信息以及修复指令，所述可能定位信息指示可能发生故障的至少一个系统组成；

运行所述修复指令，对所述dns中与所述故障的可能定位信息指示的所述至少一个系统组成进行修复。

在一种可能实现方式中，所述根据故障发生对应的目标时间段的日志数据，获取所述故障的故障特征，包括下述任一步骤：

按照所述dns的系统组成之间的联动关系，将所述日志数据中来源于具有联动关系的系统组成的日志数据进行聚合，得到多个第一日志数据组，每个第一日志数据组中的日志数据来源于具有联动关系的系统组成，根据所述多个第一日志数据组，提取每个第一日志数据组的第一故障特征；

按照所述日志数据的生成时间点，将所述日志数据进行聚合，得到多个第二日志数据组，每个第二日志数据组内的日志数据的生成时间点在所述目标时间段的同一个子时间段内，根据所述多个第二日志数据组，提取每个第二日志数据组的第二故障特征。

在一种可能实现方式中，所述根据所述故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定所述故障的故障类型，包括：

将所述故障的故障特征与所述多个故障类型的故障特征进行对比，获取所述故障的故障特征与每个故障类型的故障特征的匹配度；

将匹配度最高的故障特征对应的故障类型作为所述故障的故障类型。

在一种可能实现方式中，所述运行所述修复指令，对所述dns中与所述故障的可能定位信息指示的所述至少一个系统组成进行修复，包括：

基于所述至少一个系统组成的联动关系，确定修复所述至少一个系统组成的修复顺序；

按照所述修复顺序，运行所述修复指令，依次对所述至少一个系统组成进行修复。

在一种可能实现方式中，在所述运行所述修复指令之前，所述方法还包括：

向所述至少一个系统组成中的任一系统组成发送测试指令；

若接收到所述任一系统组成基于所述测试指令反馈的信息，则所述任一系统组成未发生故障；

若未接收到所述任一系统组成基于所述测试指令反馈的信息，则执行所述运行所述修复指令的步骤。

在一种可能实现方式中，在所述运行所述修复指令之后，所述方法还包括：

当所述至少一个系统组成修复失败时，将所述至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。

在一种可能实现方式中，在所述运行所述修复指令之前，所述方法还包括：

若dns中包括所述至少一个系统组成的备用系统组成时，将所述至少一个系统组成上的业务切换至所述备用系统组成中；

在所述至少一个系统组成修复成功之后，将所述业务从所述备用系统组成切换至修复后的至少一个系统组成中。

在一种可能实现方式中，在所述运行所述修复指令，对所述dns中与所述故障的可能定位信息指示的所述至少一个系统组成进行修复之后，所述方法还包括：

每隔预设检测周期，根据所述dns在所述预设检测周期内生成的日志数据，获取所述预设检测周期内生成的日志数据的至少一个数据特征；

若所述至少一个数据特征中的第一数据特征不属于所述多个故障类型的故障特征，且不属于正常数据的数据特征，则确定所述第一数据特征对应的日志数据为可疑数据。

在一种可能实现方式中，所述方法还包括下述任一步骤：

当确定所述dns发生故障时，发出报警信息，在所述故障修复成功后，停止发出所述报警信息；

在运行所述修复指令之后，基于所述故障类型、所述修复处理信息、修复时长或者修复结果中的至少一项，发出第一通知信息；

在获取可疑数据之后，基于所述可疑数据，发出第二通知信息。

根据本公开实施例的第二方面，提供一种故障修复装置，包括：

获取单元，被配置为执行当确定域名系统dns发生故障时，根据故障发生对应的目标时间段的日志数据，获取所述故障的故障特征；

第一确定单元，被配置为执行根据所述故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定所述故障的故障类型；

第二确定单元，被配置为执行根据所述故障类型，从故障类型和修复处理信息的对应关系中，确定所述故障类型对应的修复处理信息，所述修复处理信息包括所述故障的可能定位信息以及修复指令，所述可能定位信息指示可能发生故障的至少一个系统组成；

修复单元，被配置为执行运行所述修复指令，对所述dns中与所述故障的可能定位信息指示的所述至少一个系统组成进行修复。

在一种可能实现方式中，所述获取单元，被配置为执行下述任一步骤：

按照所述dns的系统组成之间的联动关系，将所述日志数据中来源于具有联动关系的系统组成的日志数据进行聚合，得到多个第一日志数据组，每个第一日志数据组中的日志数据来源于具有联动关系的系统组成，根据所述多个第一日志数据组，提取每个第一日志数据组的第一故障特征；

按照所述日志数据的生成时间点，将所述日志数据进行聚合，得到多个第二日志数据组，每个第二日志数据组内的日志数据的生成时间点在所述目标时间段的同一个子时间段内，根据所述多个第二日志数据组，提取每个第二日志数据组的第二故障特征。

在一种可能实现方式中，所述第一确定单元，被配置为执行将所述故障的故障特征与所述多个故障类型的故障特征进行对比，获取所述故障的故障特征与每个故障类型的故障特征的匹配度；将匹配度最高的故障特征对应的故障类型作为所述故障的故障类型。

在一种可能实现方式中，所述修复单元包括：

确定子单元，被配置为执行基于所述至少一个系统组成的联动关系，确定修复所述至少一个系统组成的修复顺序；

修复子单元，被配置为执行按照所述修复顺序，运行所述修复指令，依次对所述至少一个系统组成进行修复。

在一种可能实现方式中，所述修复单元包括：

发送子单元，被配置为执行向所述至少一个系统组成中的任一系统组成发送测试指令；

修复子单元，被配置为执行若接收到所述任一系统组成基于所述测试指令反馈的信息，则所述任一系统组成未发生故障；若未接收到所述任一系统组成基于所述测试指令反馈的信息，则执行所述运行所述修复指令的步骤。

在一种可能实现方式中，所述装置还包括：

切换单元，被配置为执行当所述至少一个系统组成修复失败时，将所述至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。

在一种可能实现方式中，所述装置还包括：

切换单元，被配置为执行若dns中包括所述至少一个系统组成的备用系统组成时，将所述至少一个系统组成上的业务切换至所述备用系统组成中；

所述切换单元，还被配置为执行在所述至少一个系统组成修复成功之后，将所述业务从所述备用系统组成切换至修复后的至少一个系统组成中。

在一种可能实现方式中，所述获取单元，还被配置为执行每隔预设检测周期，根据所述dns在所述预设检测周期内生成的日志数据，获取所述预设检测周期内生成的日志数据的至少一个数据特征；

所述第一确定单元，还被配置为执行若所述至少一个数据特征中的第一数据特征不属于所述多个故障类型的故障特征，且不属于正常数据的数据特征，则确定所述第一数据特征对应的日志数据为可疑数据。

在一种可能实现方式中，所述装置还包括信息发出单元，所述信息发出单元，被配置为执行下述任一步骤：

当确定所述dns发生故障时，发出报警信息，在所述故障修复成功后，停止发出所述报警信息；

在运行所述修复指令之后，基于所述故障类型、所述修复处理信息、修复时长或者修复结果中的至少一项，发出第一通知信息；

在获取可疑数据之后，基于所述可疑数据，发出第二通知信息。

根据本公开实施例的第三方面，提供一种计算机设备，包括：

一个或多个处理器；

用于存储所述一个或多个处理器可执行指令的一个或多个存储器；

其中，所述一个或多个处理器被配置为执行上述目标方面任一项所述的故障修复方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述存储介质中的指令由计算机设备的处理器执行时，使得计算机设备能够执行上述目标方面任一项所述的故障修复方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开实施例提供的一种故障修复方法、装置、计算机设备及存储介质，在检测到dns发生故障时，能够基于故障发生对应的目标时间段内的日志数据，获取故障的故障特征，并基于历史发生过的故障匹配该故障的故障类型，之后，根据故障类型获取修复处理信息，实现对故障的自动修复，无需人工干预，加快了修复速度，减少了对用户正常使用的影响，也减少了人力成本的投入。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种故障修复方法的流程图。

图2是根据一示例性实施例示出的一种故障修复方法的流程图。

图3是根据一示例性实施例示出的一种故障修复方法的流程图。

图4是根据一示例性实施例示出的一种故障修复方法的流程图。

图5是根据一示例性实施例示出的一种故障修复方法的流程图。

图6是根据一示例性实施例示出的一种故障修复装置的框图。

图7是根据一示例性实施例示出的另一种故障修复装置的框图。

图8是根据一示例性实施例示出的一种终端的框图。

图9是根据一示例性实施例示出的一种服务器的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种故障修复方法的流程图，如图1所示，该故障修复方法用于计算机设备中，包括以下步骤。

在步骤s11中，当确定域名系统dns发生故障时，根据故障发生对应的目标时间段的日志数据，获取故障的故障特征。

在步骤s12中，根据故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定故障的故障类型。

在步骤s13中，根据故障类型，从故障类型和修复处理信息的对应关系中，确定故障类型对应的修复处理信息，修复处理信息包括故障的可能定位信息以及修复指令，该可能定位信息指示可能发生故障的至少一个系统组成。

在步骤s14中，运行修复指令，对dns中与故障的可能定位信息指示的至少一个系统组成进行修复。

本公开实施例提供的故障修复方法，在检测到dns发生故障时，能够基于故障发生对应的目标时间段内的日志数据，获取故障的故障特征，并将故障特征与多个故障类型的故障特征进行匹配得到故障的故障类型，之后，根据故障类型获取修复处理信息，实现对故障的自动修复，无需人工干预，加快了修复速度，减少了对用户正常使用的影响，也减少了人力成本的投入，同时排除了人为操作失误的可能性。

在一种可能实现方式中，根据故障发生对应的目标时间段的日志数据，获取故障的故障特征，包括下述任一步骤：

按照dns的系统组成之间的联动关系，将日志数据中来源于具有联动关系的系统组成的日志数据进行聚合，得到多个第一日志数据组，每个第一日志数据组中的日志数据来源于具有联动关系的系统组成，根据多个第一日志数据组，提取每个第一日志数据组的第一故障特征；

按照日志数据的生成时间点，将日志数据进行聚合，得到多个第二日志数据组，每个第二日志数据组内的日志数据的生成时间点在目标时间段的同一个子时间段内，根据多个第二日志数据组，提取每个第二日志数据组的第二故障特征。

在一种可能实现方式中，根据故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定故障的故障类型，包括：

将故障的故障特征与多个故障类型的故障特征进行对比，获取故障的故障特征与每个故障类型的故障特征的匹配度；

将匹配度最高的故障特征对应的故障类型作为故障的故障类型。

在一种可能实现方式中，运行修复指令，对dns中与故障的可能定位信息指示的至少一个系统组成进行修复，包括：

基于至少一个系统组成的联动关系，确定修复至少一个系统组成的修复顺序；

按照修复顺序，运行修复指令，依次对至少一个系统组成进行修复。

在一种可能实现方式中，在运行修复指令之前，方法还包括：

向至少一个系统组成中的任一系统组成发送测试指令；

若接收到该任一系统组成基于测试指令反馈的信息，则该任一系统组成未发生故障；

若未接收到任一系统组成基于测试指令反馈的信息，则执行运行修复指令的步骤。

在一种可能实现方式中，在运行修复指令之后，方法还包括：

当至少一个系统组成修复失败时，将至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。

在一种可能实现方式中，在运行修复指令之前，方法还包括：

若dns中包括至少一个系统组成的备用系统组成时，将至少一个系统组成上的业务切换至备用系统组成中；

在至少一个系统组成修复成功之后，将业务从备用系统组成切换至修复后的至少一个系统组成中。

在一种可能实现方式中，在运行修复指令，对dns中与故障的可能定位信息指示的至少一个系统组成进行修复之后，方法还包括：

每隔预设检测周期，根据dns在预设检测周期内生成的日志数据，获取预设检测周期内生成的日志数据的至少一个数据特征；

若至少一个数据特征中的第一数据特征不属于多个故障类型的故障特征，且不属于正常数据的数据特征，则确定第一数据特征对应的日志数据为可疑数据。

在一种可能实现方式中，方法还包括下述任一步骤：

当确定dns发生故障时，发出报警信息，在故障修复成功后，停止发出报警信息；

在运行修复指令之后，基于故障类型、修复处理信息、修复时长或者修复结果中的至少一项，发出第一通知信息；

在获取可疑数据之后，基于可疑数据，发出第二通知信息。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图2是根据一示例性实施例示出的一种故障修复方法的流程图，如图2所示，该故障修复方法用于计算机设备中，包括以下步骤：

在步骤s20中，当域名系统dns的日志数据达到任一监控项的监控阈值时，计算机设备确定该dns发生故障。

其中，dns可以由一台服务器构成，也可以由若干台服务器组成的服务器集群构成。计算机设备可以为dns中的任意一个服务器，也可以是位于dns之外的任一具有计算能力的设备，例如，电脑、平板电脑、手机等设备，该计算机设备与构成dns的至少一个服务器通过有线或者无线连接。本公开实施例对计算机设备是否属于dns系统不做限定，只需保证计算机设备能够获取到dns的日志数据即可。

其中，dns在运行过程中会生成日志数据，日志数据可以记录每个用户的每次请求、dns的启动信息、dns中硬件设备的运行情况等dns的任一运行情况，该日志数据用于表示dns的运行状态。而当dns发生故障时生成的日志数据会与dns正常运行时生成的日志数据不同，例如，当dns的服务器a出现故障时，dns生成的日志数据中可能会出现大量“xxxxremotefatal”字段。根据日志数据可以确定dns是否发生故障，以及dns中可能发生故障的系统组成。

由于dns发生的故障不同，对dns的正常运行的影响也不同，因此，可以基于每种故障对dns造成的不同影响来相应设置监控项，该监控项用于根据dns的日志数据监控dns的运行状态。例如，dns的硬件存在故障，会造成可用内存大量减少，因此，可以设置一个监控项用于监控可用内存的大小，并为该监控项设置一个监控阈值，当日志数据中记录的可用内存小于该监控项的监控阈值时，则确定dns发生故障。

在一种可能实现方式中，在计算机设备还可以运行有监控系统，该监控系统可以设置有多个监控项，监控系统通过对该多个监控项的监控，来监控dns是否发生故障。

其中，计算机设备通过对监控项的监控，来监控dns是否发生故障的具体方式可以为：每个监控项都设置有其对应的监控阈值，该监控阈值为表示dns运行状态的某种类型信息中的数值被允许的最大值或者最小值。当日志数据中的某种信息类型与监控项的监控信息类型相同，且该种类型信息中的数值超出被允许的最大值或者低于被允许的最小值时，确定日志数据达到该监控项的监控阈值。例如：日志数据中记录了当前可用内存为15％，而某个监控项用于监控可用内存占比，且该监控项的监控阈值为20％，由于该日志数据记录的当前可用内存小于监控阈值，因此，该日志数据达到该监控项的监控阈值，dns发生故障。又如：日志数据中记录了用户a解析失败，某个监控项用于监控用户连续解析失败次数，且监控阈值为7次，每当日志数据中记录用户a解析失败时，该监控项均会将用户a解析失败的次数加1，直至用户a解析成功，若在用户a解析成功之前，用户a解析失败次数达到7次，则日志数据达到该监控项的监控阈值，dns发生故障。

另外，在监控系统确定dns发生故障之后，监控系统可以发出报警信息，该报警信息用于提示管理人员该dns发生故障。其中，报警信息可以为声音信息或者提示信息中的至少一项。

需要说明的是，dns中可以设置有两套系统组成，包括主用系统组成和备用系统组成，在计算机设备确定dns发生故障之后，可以先将发生故障的至少一个系统组成上的业务切换至备用系统组成中，在发生故障的至少一个系统组成修复成功之后，将业务从备用系统组成切换至修复后的至少一个系统组成中。其中，主用系统组成为dns在启动后正常运行的系统组成，该备用系统组成在dns正常运行时可以处于休眠状态，该备用系统组成用于替换发生故障的系统组成。当dns发生故障时，将发生故障的系统组成上的业务切换至备用系统组成上，无需考虑备用系统的承受能力，保证了业务的不间断运行。

另外，dns中还可以设置一套系统组成，在dns启动后，该套系统组成正常运行，当至少一个系统组成出现故障之后，可以将该至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。通过将业务切换至dns的其他正常运行的系统组成中，保证了业务的不间断运行，且无需设置备用系统组成，节约了系统资源，降低了开发成本。

其中，将业务切换至备用系统组成的步骤为可选步骤，如果执行该步骤的话，无论发生故障的系统组成是否修复成功，都能保证业务的正常运行；如果不执行该步骤的话，减少了切换步骤，可以加快修复故障的速度。

在步骤s21中，计算机设备获取故障发生对应的目标时间段的日志数据，根据该日志数据获取故障的故障特征。

其中，故障发生对应的目标时间段可以在确定dns发生故障时刻的前目标时间段，例如，确定dns发生故障的时刻为09:05:23，则获取09:05:21至09:05:23之间生成的日志数据。该故障发生对应的目标时间段还可以是达到监控阈值的监控项所记录数据的时间段，例如：监控项中记录了用户a连续解析失败10次，根据监控项中记录的用户a每次解析失败的时间，获取用户a解释失败10次所对应的10个日志数据；或者，根据用户a第一次解析失败的时间点和用户a最后一次解析失败的时间点，确定两个时间点之间的时间段，获取该时间段内dns生成的日志数据。

另外，系统组成之间可能具有联动关系，该联动关系是指连续触发关系。当一个系统组成运行时，下一个系统组成一定会运行，则代表这两个系统组成之间具有联动关系。因此，当一个系统组成出现故障时，与该系统组成具有联动关系的其他系统组成可能也无法正常运行。在一种可能实现方式中，根据日志数据获取故障的故障特征的具体过程可以为：计算机设备按照dns的系统组成之间的联动关系，将日志数据中来源于具有联动关系的系统组成的日志数据进行聚合，得到多个第一日志数据组，每个第一日志数据组中的日志数据来源于具有联动关系的系统组成，根据多个第一日志数据组，提取每个第一日志数据组的第一故障特征。由于根据系统组成的联动关系对日志数据进行分组，得到了一个故障造成的全部错误日志数据，通过对全部错误日志数据进行特征提取，提取到的故障特征更加准确，以便后续准确获取故障的故障类型。

另外，由于故障发生对应的目标时间段内会产生大量的日志数据，为了更加准确地获取故障的故障特征，可以将日志数据分为多组数据，分别对每组数据提取特征。在另一种可能实现方式中，根据日志数据获取故障的故障特征的具体过程还可以为：计算机设备按照日志数据的生成时间点，将日志数据进行聚合，得到多个第二日志数据组，每个第二日志数据组内的日志数据的生成时间点在目标时间段的同一个子时间段内，根据多个第二日志数据组，提取每个第二日志数据组的第二故障特征。按照日志数据的生成时间点，将大量的日志数据分成多组，分别对每组数据进行特征提取，提取到的特征更加准确，并且还能获取故障特征随着时间的变化趋势，以便后续能够根据每个故障特征以及故障特征的变化趋势匹配到准确的故障类型。

需要说明的是，本公开实施例仅是以上述两种方式提取日志数据的特征为例进行说明，在一些实施例中，还可以根据其他方式来提取特征，本公开实施例对提取特征的具体方式不做限定。

在步骤s22中，计算机设备根据故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定该故障的故障类型。

其中，历史日志数据包括dns正常运行时生成的日志数据和dns发生故障时生成的日志数据。通过对历史日志数据进行特征提取，能够获取正常日志数据的数据特征以及故障的日志数据的故障特征，并按照故障类型对故障特征进行分类，即可得到故障类型的故障特征。由于故障类型的故障特征是根据历史数据得到的，则说明之前dns出现过该故障并且成功修复，因此，通过将本次故障与历史出现的故障进行匹配，能够准确确定故障类型以及修复处理信息，并成功修复故障。

其中，步骤s22的具体实现方式可以为：计算机设备将故障的故障特征与多个故障类型的故障特征进行对比，获取故障的故障特征与每个故障类型的故障特征的匹配度；将匹配度最高的故障特征对应的故障类型作为故障的故障类型。通过故障特征之间的匹配，能够准确得到故障的故障类型。

另外，计算机设备中还运行有特征库系统，该特征库系统用于对历史日志数据进行特征提取并分类，该特征库系统还用于对故障发生对应的目标时间段的日志数据进行特征提取，并获取故障对应的故障类型。监控系统在确定dns发生故障之后，可以将故障发生对应的目标时间段的日志数据发送至特征库系统，由特征库系统对该日志数据进行特征提取得到故障的故障特征，并根据故障的故障特征和基于历史数据所确定的多个故障类型的故障特征，确定故障的故障类型。

在步骤s23中，计算机设备根据该故障类型，从故障类型和修复处理信息的对应关系中，确定该故障类型对应的修复处理信息，修复处理信息包括故障的可能定位信息以及修复指令。

其中，修复处理信息为故障对应的修复策略，用于对故障进行修复，修复处理信息中的可能定位信息指示可能发生故障的至少一个系统组成，包括可能发生故障的至少一个系统组成的信息，该信息可以为系统组成的名称、系统组成的位置等能够指示唯一系统组成的信息。该修复处理信息可以由管理人员录入，也可以是管理人员在手动修复dns时，由计算机设备根据管理人员的操作自动录入。在计算机设备中，修复处理信息与其对应的故障类型对应存储。

其中，一个故障类型对应至少一个修复处理信息，当一个故障类型对应一个修复处理信息时，计算机设备可以直接将该修复处理信息作为该故障对应的修复处理信息。

当一个故障类型对应多个修复处理信息时，计算机设备可以按照每个修复处理信息的优先级，从多个修复处理信息中选择优先级最高的修复处理信息作为故障对应的修复处理信息，对故障进行处理，当对故障修复失败时，还可以按照优先级选择下一修复处理信息对故障进行处理。该预设优先级可以根据修复处理信息修复故障的成功次数确定，还可以由管理人员设置。通过赋予修复处理信息优先级，并按照优先级最高的修复处理信息对故障进行处理，尽可能地使dns能够一次修复成功，确保了在最短的时间内能够修复故障，并且，在故障修复失败时，还会按照优先级，依次尝试其他修复处理信息，提高了故障修复的成功率。

另外，相同类型的故障，由于故障程度不同对应的修复处理信息可能也不同。当一个故障类型对应多个修复处理信息时，计算机设备还可以按照故障的故障程度，从多个修复处理信息中确定符合该故障程度的修复处理信息。通过故障程度确定修复处理信息保证了一次修复成功的概率。

需要说明的是，在本公开实施例中是以一个故障类型对应至少一个修复处理信息为例进行说明，在一些实施例中，一个故障类型还可以对应一个修复处理信息，一个修复处理信息中包括至少一个修复指令，按照上述优先级或者故障程度，从多个修复指令中确定一个符合条件的修复指令，本公开实施例对修复处理信息和修复指令的具体形式不做限定。

在步骤s24中，计算机设备向故障的可能定位信息指示的至少一个系统组成发送测试指令，确定该至少一个系统组成是否发生故障。

其中，至少一个系统组成可以是硬件组成，也可以是软件组成。由于系统组成之间具有联动关系，因此有些系统组成输出异常是由于与该系统组成具有联动关系的其他系统组成发生故障造成的。在根据修复处理信息中的可能定位信息中确定对应的至少一个系统组成之后，可以先确定该系统组成是真的发生故障，还是由于具有联动关系的其他系统组成发生故障，导致的该系统组成输出异常。

其中，计算机设备确定系统组成是否真的故障的具体实现方式可以为：对于至少一个系统组成中的任一系统组成，计算机设备向该任一系统组成发送测试指令，若接收到该任一系统组成基于测试指令反馈的信息，则该任一系统组成未发生故障，计算机设备不对该系统组成进行修复；若未接收到该任一系统组成基于测试指令反馈的信息，则该系统组成发生故障，则计算机设备执行运行修复指令的步骤，其中，运行修复指令时，可以只运行该任一系统组成对应的修复指令，这种方式能够准确地判断出发生故障的系统组成，避免了对未发生故障的系统组成进行修复，加快了修复速度。

其中，上述步骤s24为可选执行步骤，若执行步骤s24，则能够避免对未发生故障的系统组成进行修复，加快了故障的修复速度，尽可能地降低故障对用户正常使用的影响。若不执行步骤s24，则可以直接执行步骤s26或步骤s27。

在步骤s25中，在确定至少一个系统组成发生故障之后，计算机设备基于至少一个系统组成的联动关系，确定修复该至少一个系统组成的修复顺序。

其中，该至少一个系统组成的修复顺序可以与至少一个系统组成的启动运行顺序相同，由于对先运行的系统组成进行修复，使得在后续修复后运行的系统组成成功时，能够保证该系统组成的日志数据为正常日志数据，以便根据日志数据来确定系统组成是否修复想成功，简化了判断系统组成修复是否成功的步骤。

其中，步骤s25为可选执行步骤，若执行步骤s25，则可以避免具有联动关系的其他系统组成对该系统组成的影响，可以快速且准确地确定系统组成是否修复成功，以便尽快确定后续执行步骤。若不执行步骤s25，则可以直接执行步骤s26中的运行修复指令。

在步骤s26中，计算机设备按照修复顺序，运行该修复指令，依次对至少一个系统组成进行修复。

计算机设备在运行该修复指令后，会确定至少一个系统组成是否修复成功。其中，计算机设备确定至少一个系统组成是否修复成功的具体方式可以为：获取至少一个系统组成中每一个系统组成的日志数据，确定该日志数据是否为正常日志数据，当该日志数据为正常日志数据时，确定该系统组成修复成功，也即dns的故障修复成功；当该日志数据为异常日志数据时，确定该系统组成修复失败，也即dns的故障修复失败。

计算机设备在运行修复指令之后，无论修复成功还是失败，都可以基于故障类型、修复处理信息、修复时长或者修复结果中的至少一项，发出第一通知信息，例如该第一通知信息为：2019年01月01号12点56分，dns的服务器a进行了故障自愈操作，匹配故障类型为3，修复处理信息为7，修复成功，用时2秒，详情请见xxxx。管理人员可以根据第一通知信息了解到dns在何时发生了何种故障，并通过何种方式进行了修复，以便后续管理人员对修复处理信息进行更新。

当计算机设备在检测到故障时，可以发出报警信息，相应的，在故障修复成功之后，还可以停止发出报警信息。在一种可能实现方式中，计算机设备满足目标条件时，停止发出报警信息，具体过程可以为：在运行修复指令完毕之后，通过监控系统监控至少一个系统组成的日志数据是否为正常日志数据，当该至少一个系统组成的日志数据为正常日志数据，且保持时长超过目标时长后，计算机设备停止发出报警信息，该目标时长可以为30秒等任一时长。

另外，当对至少一个系统组成中的任一系统组成修复失败时，计算机设备将至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。保证了在故障修复失败时，也能实现用户的正常使用，尽可能地降低了故障对用户正常使用造成的影响。

综合上述步骤20至步骤s26，以计算机设备中运行有监控系统和特征库系统为例，对计算机设备修复dns的故障过程进行说明，如图3所示，当监控系统检测到故障发生时，可以获取与该故障相关的日志数据，将该日志数据发送至特征库系统中，由特征库系统检测特征库中是否包括该日志数据的特征，其中，特征库中包括正常日志数据的数据特征以及多个故障类型的故障特征，且特征库中还包括每个故障类型对应的修复处理信息。当特征库系统基于特征库匹配到该日志数据的特征时，根据匹配结果对故障进行修复；当特征库系统基于特征库未匹配到该日志数据的特征时，则将发生故障的至少一个系统组成上的业务切换至备用系统组成中。另外，当故障修复失败时，也可以将业务切换至备用系统组成中。无论通过何种方式修复故障，在修复成功之后，特征库系统可以生成第一通知信息，以告知管理人员。

另外，当修复失败或者未匹配到故障类型时，还可以上报故障发生对应的目标时间段的日志数据，如图4所示，以便后续管理人员根据该日志数据补充特征库。

在步骤s27中，每隔预设检测周期，计算机设备根据dns在预设检测周期内生成的日志数据，获取预设检测周期内生成的日志数据的至少一个数据特征。

其中，预设检测周期可以是一天、一个月等任一时间段，其中获取日志数据的至少一个数据特征的过程与步骤s22中的过程类似，在此不再一一赘述。

另外，为了避免重复对故障造成的错误日志数据进行重复检测，如图5所示，监控系统可以将故障发生对应的目标时间段的日志数据发送至日志分析系统中，或者将能够确定出该日志数据的描述信息发送至日志分析系统，该描述信息可以是该日志数据的生成时间等，用于从全部日志数据中确定出故障发生对应的目标时间段的日志数据，日志分析系统可以在dns生成的全部日志数据中删除该故障发生对应的目标时间段的日志数据，避免了对部分日志数据的重复分析。

在步骤s28中，若至少一个数据特征中的第一数据特征不属于多个故障类型的故障特征，且不属于正常数据的数据特征，则计算机设备确定第一数据特征对应的日志数据为可疑数据。

其中，可疑数据的数据特征与已有的正常日志数据的数据特征不同，且与已有的故障类型对应的故障特征也不同，该可疑数据还可能是正常日志数据，也可能是dns发生故障造成的，该故障的故障类型可以与dns的历史故障的故障类型相同，也可以不同。

需要说明的是，在一些实施例中，第一数据特征也有可能属于某个故障类型的故障特征，该种情况可能是由于dns可能快要出现故障但是还未真的故障造成的，也可能是由于dns出现故障，但是并未达到监控项的监控阈值造成的。在这种情况下，计算机设备可以根据匹配到的故障类型以及修复处理信息对dns进行修复。并且，在修复成功之后，可以将第一数据特征对应的日志数据进行上报，由管理人员对日志数据进行分析，确定引起该种情况的原因，并对监控系统和特征库系统进行相应的调整，使得计算设备自动修复dns故障的机制更加完善。

在步骤s29中，计算机设备基于可疑数据，发出第二通知信息。

其中，第二通知信息用于通知管理人员补充特征库，该第二通知信息中包括该可疑数据，当该可疑数据是由于dns故障引起时，管理人员可以根据该可疑数据在监控系统中补充相应的监控项，以便后续可以通过监控系统来确定dns发生故障，并及时修复该故障，并在特征库系统中补充相应的特征以及对应的故障类型和修复处理信息。当该可疑数据是正常日志数据时，可以由管理人员在特征库中补充该可疑数据对应的数据特征，并将该特征作为正常日志数据的数据特征，后续再接收到该类型的日志数据时，不会重复生成可疑数据。

其中，步骤s27至步骤s29为可选执行步骤，可以基于监控机制的完整性来选择执行，若执行步骤s27至步骤s29有利于完善整个监控机制，进而能够对更多类型的故障进行自动修复。

本公开实施例提供的故障修复方法，在检测到dns发生故障时，能够基于故障发生对应的目标时间段内的日志数据，获取故障的故障特征，并将故障特征与多个故障类型的故障特征进行匹配得到故障的故障类型，之后，根据故障类型获取修复处理信息，实现对故障的自动修复，无需人工干预，加快了修复速度，减少了对用户正常使用的影响，也减少了人力成本的投入。

另外，在故障修复失败时，还可以通过将发生故障的系统组成上的业务切换至其他正常运行的系统组成上，使得在dns发生故障时，用户依然能够正常访问。

另外，在计算机设备还会每隔预设检测周期，对dns生成的所有日志数据进行检测，查看是否存在可疑数据，以便管理人员根据可以数据添加监控项或者修正特征库系统，以完善计算机设备自动修复故障的机制。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图6是根据一示例性实施例示出的一种故障修复装置框图。参照图6，该装置包括获取单元601、第一确定单元602、第二确定单元603和修复单元604。

获取单元601，被配置为执行当确定域名系统dns发生故障时，根据故障发生对应的目标时间段的日志数据，获取该故障的故障特征；

第一确定单元602，被配置为执行根据该故障的故障特征以及基于历史日志数据所确定的多个故障类型的故障特征，确定该故障的故障类型；

第二确定单元603，被配置为执行根据该故障类型，从故障类型和修复处理信息的对应关系中，确定该故障类型对应的修复处理信息，该修复处理信息包括该故障的可能定位信息以及修复指令，可能定位信息指示可能发生故障的至少一个系统组成；

修复单元604，被配置为执行运行该修复指令，对该dns中与该故障的可能定位信息指示的至少一个系统组成进行修复。

本公开实施例提供的故障修复装置，在检测到dns发生故障时，能够基于故障发生对应的目标时间段内的日志数据，获取故障的故障特征，并将故障特征与多个故障类型的故障特征进行匹配得到故障的故障类型，之后，根据故障类型获取修复处理信息，实现对故障的自动修复，无需人工干预，加快了修复速度，减少了对用户正常使用的影响，也减少了人力成本的投入。

在一种可能实现方式中，该获取单元601，被配置为执行下述任一步骤：

按照该dns的系统组成之间的联动关系，将该日志数据中来源于具有联动关系的系统组成的日志数据进行聚合，得到多个第一日志数据组，每个第一日志数据组中的日志数据来源于具有联动关系的系统组成，根据该多个第一日志数据组，提取每个第一日志数据组的第一故障特征；

按照该日志数据的生成时间点，将该日志数据进行聚合，得到多个第二日志数据组，每个第二日志数据组内的日志数据的生成时间点在该目标时间段的同一个子时间段内，根据该多个第二日志数据组，提取每个第二日志数据组的第二故障特征。

在一种可能实现方式中，该第一确定单元602，被配置为执行将该故障的故障特征与该多个故障类型的故障特征进行对比，获取该故障的故障特征与每个故障类型的故障特征的匹配度；将匹配度最高的故障特征对应的故障类型作为该故障的故障类型。

在一种可能实现方式中，如图7所示，该修复单元604包括：

确定子单元6041，被配置为执行基于该至少一个系统组成的联动关系，确定修复该至少一个系统组成的修复顺序；

修复子单元6042，被配置为执行按照该修复顺序，运行该修复指令，依次对该至少一个系统组成进行修复。

在一种可能实现方式中，如图7所示，该修复单元604包括：

发送子单元6043，被配置为执行向该至少一个系统组成发送测试指令；

修复子单元6042，被配置为执行若接收到该任一系统组成中的任一系统组成基于该测试指令反馈的信息，则该任一系统组成未发生故障；若未接收到该任一系统组成基于该测试指令反馈的信息，则执行运行该修复指令的步骤。

在一种可能实现方式中，如图7所示，该装置还包括：

切换单元605，被配置为执行当该至少一个系统组成修复失败时，将该至少一个系统组成上的业务切换至其他正常运行的至少一个系统组成中。

在一种可能实现方式中，如图7所示，该装置还包括：

切换单元605，被配置为执行若dns中包括该至少一个系统组成的备用系统组成时，将该至少一个系统组成上的业务切换至该备用系统组成中；

该切换单元605，还被配置为执行在该至少一个系统组成修复成功之后，将该业务从该备用系统组成切换至修复后的至少一个系统组成中。

在一种可能实现方式中，该获取单元601，还被配置为执行每隔预设检测周期，根据该dns在该预设检测周期内生成的日志数据，获取该预设检测周期内生成的日志数据的至少一个数据特征；

该第一确定单元602，还被配置为执行若该至少一个数据特征中的第一数据特征不属于该多个故障类型的故障特征，且不属于正常数据的数据特征，则确定该第一数据特征对应的日志数据为可疑数据。

在一种可能实现方式中，如图7所示，该装置还包括信息发出单元606，该信息发出单元606，被配置为执行下述任一步骤：

当确定该dns发生故障时，发出报警信息，在该故障修复成功后，停止发出该报警信息；

在运行该修复指令之后，基于该故障类型、该修复处理信息、修复时长或者修复结果中的至少一项，发出第一通知信息；

在获取可疑数据之后，基于该可疑数据，发出第二通知信息。

需要说明的是：上述实施例提供的故障修复装置在修复故障时，仅以上述各功能单元的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元完成，即将故障修复装置的内部结构划分成不同的功能单元，以完成以上描述的全部或者部分功能。另外，上述实施例提供的故障修复装置与故障修复方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。。

图8是本公开实施例提供的一种终端的结构框图。该终端800用于执行上述实施例中计算机设备执行的步骤，可以是便携式移动终端，比如：智能手机、平板电脑、mp3播放器(movingpictureexpertsgroupaudiolayeriii，动态影像专家压缩标准音频层面3)、mp4(movingpictureexpertsgroupaudiolayeriv，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端800还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端800包括有：处理器801和存储器802。

处理器801可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器801可以采用dsp(digitalsignalprocessing，数字信号处理)、fpga(field－programmablegatearray，现场可编程门阵列)、pla(programmablelogicarray，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器801也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(centralprocessingunit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器801可以在集成有gpu(graphicsprocessingunit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器801还可以包括ai(artificialintelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。

存储器802可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器802还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器802中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器801所执行以实现本申请中方法实施例提供的故障修复方法。

在一些实施例中，终端800还可选包括有：外围设备接口803和至少一个外围设备。处理器801、存储器802和外围设备接口803之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口803相连。具体地，外围设备包括：射频电路804、触摸显示屏805、摄像头806、音频电路807、定位组件808和电源809中的至少一种。

外围设备接口803可被用于将i/o(input/output，输入/输出)相关的至少一个外围设备连接到处理器801和存储器802。在一些实施例中，处理器801、存储器802和外围设备接口803被集成在同一芯片或电路板上；在一些其他实施例中，处理器801、存储器802和外围设备接口803中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路804用于接收和发射rf(radiofrequency，射频)信号，也称电磁信号。射频电路804通过电磁信号与通信网络以及其他通信设备进行通信。射频电路804将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路804包括：天线系统、rf收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路804可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2g、3g、4g及5g)、无线局域网和/或wifi(wirelessfidelity，无线保真)网络。在一些实施例中，射频电路804还可以包括nfc(nearfieldcommunication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏805用于显示ui(userinterface，用户界面)。该ui可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏805是触摸显示屏时，显示屏805还具有采集在显示屏805的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器801进行处理。此时，显示屏805还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏805可以为一个，设置终端800的前面板；在另一些实施例中，显示屏805可以为至少两个，分别设置在终端800的不同表面或呈折叠设计；在再一些实施例中，显示屏805可以是柔性显示屏，设置在终端800的弯曲表面上或折叠面上。甚至，显示屏805还可以设置成非矩形的不规则图形，也即异形屏。显示屏805可以采用lcd(liquidcrystaldisplay，液晶显示屏)、oled(organiclight-emittingdiode,有机发光二极管)等材质制备。

摄像头组件806用于采集图像或视频。可选地，摄像头组件806包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及vr(virtualreality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件806还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路807可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器801进行处理，或者输入至射频电路804以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端800的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器801或射频电路804的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路807还可以包括耳机插孔。

定位组件808用于定位终端800的当前地理位置，以实现导航或lbs(locationbasedservice，基于位置的服务)。定位组件808可以是基于美国的gps(globalpositioningsystem，全球定位系统)、中国的北斗系统或俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源809用于为终端800中的各个组件进行供电。电源809可以是交流电、直流电、一次性电池或可充电电池。当电源809包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端800还包括有一个或多个传感器810。该一个或多个传感器810包括但不限于：加速度传感器811、陀螺仪传感器812、压力传感器813、指纹传感器814、光学传感器815以及接近传感器816。

加速度传感器811可以检测以终端800建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器811可以用于检测重力加速度在三个坐标轴上的分量。处理器801可以根据加速度传感器811采集的重力加速度信号，控制触摸显示屏805以横向视图或纵向视图进行用户界面的显示。加速度传感器811还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器812可以检测终端800的机体方向及转动角度，陀螺仪传感器812可以与加速度传感器811协同采集用户对终端800的3d动作。处理器801根据陀螺仪传感器812采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变ui)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器813可以设置在终端800的侧边框和/或触摸显示屏805的下层。当压力传感器813设置在终端800的侧边框时，可以检测用户对终端800的握持信号，由处理器801根据压力传感器813采集的握持信号进行左右手识别或快捷操作。当压力传感器813设置在触摸显示屏805的下层时，由处理器801根据用户对触摸显示屏805的压力操作，实现对ui界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器814用于采集用户的指纹，由处理器801根据指纹传感器814采集到的指纹识别用户的身份，或者，由指纹传感器814根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器801授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器814可以被设置终端800的正面、背面或侧面。当终端800上设置有物理按键或厂商logo时，指纹传感器814可以与物理按键或厂商标志集成在一起。

光学传感器815用于采集环境光强度。在一个实施例中，处理器801可以根据光学传感器815采集的环境光强度，控制触摸显示屏805的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏805的显示亮度；当环境光强度较低时，调低触摸显示屏805的显示亮度。在另一个实施例中，处理器801还可以根据光学传感器815采集的环境光强度，动态调整摄像头组件806的拍摄参数。

接近传感器816，也称距离传感器，通常设置在终端800的前面板。接近传感器816用于采集用户与终端800的正面之间的距离。在一个实施例中，当接近传感器816检测到用户与终端800的正面之间的距离逐渐变小时，由处理器801控制触摸显示屏805从亮屏状态切换为息屏状态；当接近传感器816检测到用户与终端800的正面之间的距离逐渐变大时，由处理器801控制触摸显示屏805从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图8中示出的结构并不构成对终端800的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图9是根据一示例性实施例示出的一种服务器900的框图。该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)901和一个或一个以上的存储器902，其中，存储器902中存储有至少一条指令，至少一条指令由处理器901加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。

服务器900可以用于执行上述故障修复方法中计算机设备所执行的步骤。

在示例性实施例中，还提供了一种计算机可读存储介质，当该存储介质中的指令由计算机设备的处理器执行时，使得计算机设备能够执行本公开实施例提供的故障修复方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。