一种玄武盾客户端灾难故障修复方法、装置和存储介质与流程

本申请涉及网络安全技术领域，特别涉及一种玄武盾客户端灾难故障修复方法、装置、系统、电子设备和计算机可读存储介质。

背景技术：

目前玄武盾客户端由于接入了好几万个重要客户的站点，这些站点的可用性要求是非常高的，为了保障这些站点的稳定运行，需要投入大量的人力去对玄武盾客户端的稳定性进行维护，而且当玄武盾客户端出现故障时会存在处理问题不及时的问题，对客户造成非常严重的影响。

技术实现要素：

本申请的目的是提供一种玄武盾客户端灾难故障修复方法，应用于自动化运维平台，能够及时响应处理故障，同时降低了人工运维成本。其具体方案如下：

第一方面，本申请公开了一种玄武盾客户端灾难故障修复方法，应用于自动化运维平台，包括：

获取监控平台发送的灾难告警信息；所述灾难告警信息由所述监控平台对玄武盾客户端进行监控产生；

将所述灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定所述灾难告警修复方案库中与所述灾难告警信息匹配的灾难修复方案；

将所述告警修复方案发送至所述玄武盾客户端，以在所述玄武盾客户端上执行所述告警修复方案进行修复。

可选的，所述将所述灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定所述灾难告警修复方案库中与所述灾难告警信息匹配的灾难修复方案，包括：

识别所述灾难告警信息中所述玄武盾客户端的灾难程度和所述玄武盾客户端的灾难类别；

在所述灾难告警修复方案库中，查找与所述玄武盾客户端的灾难程度和所述玄武盾客户端的灾难类别相匹配的灾难修复方案。

可选的，在查找与所述玄武盾客户端的灾难程度和所述玄武盾客户端的灾难类别匹配的灾难修复方案之前，还包括：

判断所述玄武盾客户端的灾难类型是否属于目标模块对应的故障类型；所述目标模块包括前端接入模块、后端回源模块、和高可用模块中的任意一项或多项；

若否，则利用指定路径发送提示信息至运维人员；

若是，则执行所述查找与所述玄武盾客户端的灾难程度和所述玄武盾客户端的灾难类别匹配的灾难修复方案的步骤。

可选的，在将所述告警修复方案发送至所述玄武盾客户端，以在所述玄武盾客户端上执行所述告警修复方案进行修复之后，还包括：

获取所述监控平台对所述玄武盾客户端的监测数据；

根据所述监测数据，判断所述玄武盾客户端是否修复成功；

若否，则触发所述监控平台发送提示信息至值班运维，以进行人工修复。

可选的，在触发所述监控平台发送提示信息至值班运维，以进行人工修复之后，还包括：

当修复成功后，获取对所述玄武盾客户端进行修复的故障点和对应的修复方案，并将所述故障点和对应的所述修复方案存储至所述灾难告警修复方案库。

第二方面，本申请公开了一种玄武盾客户端灾难故障修复装置，包括：

获取模块，用于获取监控平台发送的灾难告警信息；所述灾难告警信息由所述监控平台对玄武盾客户端进行监控产生；

确定模块，用于将所述灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定所述灾难告警修复方案库中与所述灾难告警信息匹配的灾难修复方案；

发送模块，用于将所述告警修复方案发送至所述玄武盾客户端，以在所述玄武盾客户端上执行所述告警修复方案进行修复。

第三方面，本申请公开了一种玄武盾客户端灾难故障修复系统，包括：

玄武盾客户端，用于接收自动化运维平台发送的告警修复方案，并执行所述告警修复方案进行修复；

监控平台，用于对所述玄武盾客户端进行监控，产生灾难告警信息，并发送所述灾难告警信息至自动化运维平台；

自动化运维平台，用于执行上述的玄武盾客户端灾难故障修复方法的步骤。

可选的，所述监控平台和所述自动化运维平台利用agent对所述玄武盾客户端进行管理。

第四方面，本申请公开了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述玄武盾客户端灾难故障修复方法的步骤。

第五方面，本申请公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述玄武盾客户端灾难故障修复方法的步骤。

本申请提供一种玄武盾客户端灾难故障修复方法，应用于自动化运维平台，包括：获取监控平台发送的灾难告警信息；所述灾难告警信息由所述监控平台对玄武盾客户端进行监控产生；将所述灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定所述灾难告警修复方案库中与所述灾难告警信息匹配的灾难修复方案；将所述告警修复方案发送至所述玄武盾客户端，以在所述玄武盾客户端上执行所述告警修复方案进行修复。

可见，本申请通过监控平台对玄武盾客户端进行监控，能够及时发现玄武盾客户端是否发生故障，当监测到发生故障时能够产生灾难告警信息，自动化运维平台能够接收到监控平台发送的灾难告警信息，并匹配到该灾难告警信息对应的告警修复方案，再将告警修复方案发送到玄武盾客户端，使玄武盾客户端及时的执行告警修复方案进行修复；即本申请利用监控平台能够及时的发现玄武盾客户端是否发生故障，并能够在发生故障时产生灾难告警信息，自动化运维平台能够根据灾难告警信息确定对应的灾难修复方案，以使玄武盾客户端执行告警修复方案进行修复，能够及时响应故障信息，并自动生成告警修复方案进行修复，避免了相关技术中响应不及时，且需投入大量人力进行运维，导致对客户产生极大损失的缺陷，本申请能够及时响应处理故障，同时降低了人工运维成本。本申请同时还提供了一种玄武盾客户端灾难故障修复装置、系统、电子设备和计算机可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例所提供的一种玄武盾客户端灾难故障修复方法的流程图；

图2为本实施例所提供的一种自动化运维平台和监控平台对玄武段客户端进行自动修复的流程示意图；

图3为本申请实施例所提供的一种玄武盾客户端灾难故障修复装置的结构示意图。

具体实施方式

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

目前，针对玄武盾客户端的维护工作需要投入大量人力，浪费人力成本，且还会出现当玄武盾故障时不能及时的发现，造成对客户的极大影响，产生极大损失。基于上述技术问题，本实施例提供一种玄武盾客户端灾难故障修复方法，能够及时响应处理故障，同时降低人工运维成本，具体请参考图1，图1为本申请实施例所提供的一种玄武盾客户端灾难故障修复方法的流程图，具体包括：

s101、获取监控平台发送的灾难告警信息；灾难告警信息由监控平台对玄武盾客户端进行监控产生。

本实施例的执行主体为自动化运维平台。本实施例中的监控平台用来实现对玄武盾客户端的监控，产生灾难告警信息。可以理解的是，监控平台对玄武盾客户端进行监控，可以定时的将监控数据收集到监控平台，并在一定的触发条件下产生灾难告警信息，例如，监控平台可设置告警阈值，当收集到的监控数据大于该告警阈值时，就会产生灾难告警信息。本实施例中并不限定灾难告警信息的具体内容，可以包括灾难类型和灾难程度，还可以包括其他。

s102、将灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定灾难告警修复方案库中与灾难告警信息匹配的灾难修复方案。

本实施例中的灾难告警修复方案库用来存储不同灾难类型的灾难修复方案，本实施例并不限定灾难告警修复方案库的具体内容，只要包含不同的灾难告警信息对应的灾难修复方案即可，具体可根据实际需求进行设定。本实施例中的自动化运维平台接收到监控平台发送的灾难告警信息后，将灾难告警信息与预先制定的灾难告警修复方案库进行匹配，并确定与灾难告警信息匹配的灾难修复方案，以在后续操作中根据该灾难修复方案进行修复。

本实施例并不限定灾难告警信息与灾难告警修复方案库进行匹配来确定相应的灾难修复方案的具体过程。在一种具体的实施例中，将灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定灾难告警修复方案库中与灾难告警信息匹配的灾难修复方案，可以包括：

识别灾难告警信息中玄武盾客户端的灾难程度和玄武盾客户端的灾难类别；

在灾难告警修复方案库中，查找与玄武盾客户端的灾难程度和玄武盾客户端的灾难类别相匹配的灾难修复方案。

即本实施例中通过识别灾难告警信息中对应玄武盾客户端的灾难程度和玄武盾客户端的灾难类别，然后在灾难告警修复方案库中，查找与该灾难程度和灾难类别相匹配的灾难修复方案，该灾难修复方案作为玄武盾客户端出现故障进行修复的方案。

本实施例并不限定灾难告警信息中具体的灾难类型，可以是主机系统故障的灾难类型，可以是网络不可用的灾难类型，还可以是前端接入模块、后端回源模块或高可用模块的灾难类型。本实施例并不对是否划分为灾难类型作具体限定，可以理解的是，当出现以下情况例如cpu使用率较高，或是内存使用率较高的情况即可不归为灾难类型。需要说明的是，本实施例并不限定灾难程度的具体设定方式，例如，当灾难类型属于上述三项的灾难类型时，可以设置当响应时间超过第一预设阈值(例如10分钟)时，灾难程度设为严重；当响应时间超过第二预设阈值(例如8分钟)时，灾难程度设为一般严重，普通告警。或是根据客户的重要程度来设置灾难程度，比较重要的设为重大灾难等。

在一种具体的实施例中，在查找与玄武盾客户端的灾难程度和玄武盾客户端的灾难类别匹配的灾难修复方案之前，还可以包括：

判断玄武盾客户端的灾难类型是否属于目标模块对应的故障类型；目标模块包括前端接入模块、后端回源模块、和高可用模块中的任意一项或多项；

若否，则利用指定路径发送提示信息至运维人员；

若是，则执行查找玄武盾客户端的灾难程度和玄武盾客户端的灾难类别匹配的灾难修复方案的步骤。

即本实施例中通过判断玄武盾客户端的灾难类型是否属于前端接入模块的故障类型、后端回源模块的故障类型、和高可用模块的故障类型中的任意一项或多项，当不属于其中的这三项故障类型时，通过指定路径发送提示信息给运维人员。本实施例并不限定指定路径的具体方式，例如，可以是通过添加指定的钉钉账号，或是短信、电话号码等方式，可根据实际情况进行设定。本实施例也不限定提示信息的具体信息，可以包括灾难告警信息，还可以包括不属于上述的三项故障类型的消息，还可以包括其他内容。当属于上述的这三项故障类型时，才执行查找玄武盾客户端的灾难程度和玄武盾客户端的灾难类别匹配的灾难修复方案的步骤。

s103、将告警修复方案发送至玄武盾客户端，以在玄武盾客户端上执行告警修复方案进行修复。

本实施例在匹配到灾难告警信息对应的灾难修复方案后，将该告警修复方案发送到玄武盾客户端，以使开发人员在玄武盾客户端上执行告警修复方案进行修复。

本实施例并不限定根据灾难修复方案进行修复后的具体操作。在一种具体的实施例中，为了能够修复故障，使玄武盾客户端正常运行，在将告警修复方案发送至玄武盾客户端，以在玄武盾客户端上执行告警修复方案进行修复之后，还可以包括：

获取监控平台对玄武盾客户端的监测数据；

根据监测数据，判断玄武盾客户端是否修复成功；

若否，则触发监控平台发送提示信息至运维人员，以进行人工修复。

本实施例在玄武盾客户端上执行告警修复方案进行修复之后，还获取了监控平台对玄武盾客户端进行监测产生的监测数据，并根据该监测数据判断是否修复成功，当修复未成功的情况下，为了能够修复故障，使玄武盾客户端正常运行，自动化运维平台通过触发监控平台发送提示信息至运维人员，以进行人工修复，直到修复好玄武盾客户端产生的故障。本实施例也不限定提示信息的具体信息，可以包括灾难告警信息，还可以包括不属于上述的三项故障类型的消息，还可以包括其他内容。

本实施例也不限定进行人工修复后的具体操作。在一种具体的实施例中，为了逐步完善整个灾难告警修复方案库，在触发监控平台发送提示信息至运维人员，以进行人工修复之后，还可以包括：

当修复成功后，获取对玄武盾客户端进行修复的故障点和对应的修复方案，并将故障点和对应的修复方案存储至灾难告警修复方案库。

本实施例中在玄武盾客户端的故障修复完成后，将人工介入即运维人员通过排障查明原因后，将新发生的故障点及对应的修复方案再加入到灾难告警修复方案库，逐步完善整个灾难告警修复方案库。

基于上述技术方案，本实施例利用监控平台能够及时的发现玄武盾客户端是否发生故障，并能够在发生故障时产生灾难告警信息，自动化运维平台能够根据灾难告警信息确定对应的灾难修复方案，以使玄武盾客户端执行告警修复方案进行修复，能够及时响应故障信息，并自动生成告警修复方案进行修复，本申请能够及时响应处理故障，同时降低了人工运维成本。即本实施例中利用监控平台的告警功能，自动化运维平台能够解放生产力的优点，将两者进行联动适配玄武盾环境。

下面提供一种基于自动化运维平台和监控平台对玄武段客户端进行自动修复的具体实施例。能够解决当玄武盾客户端出现灾难故障之后，自动化运维平台能够及时自动处理该故障，避免因为人工响应不及时，或者处理不当导致玄武盾客户端长时间不可用，从而对客户造成重要影响的问题。

本实施例中通过搭建两个平台对玄武盾客户端进行纳管，一个监控平台，一个自动化运维平台，都是通过分布式的方式部署，即一台主节点管理多个代理，通过代理去各个不同的平台或不同网络环境进行数据收集，下发配置等。通过自动化运维平台对监控平台的灾难告警信息进行调用，然后自动化运维平台会自动调用事先自定义好的处理方案即灾难修复方案，然后通过在玄武盾客户端上面执行该灾难修复方案，当执行完后，自动化运维平台会再去检测故障是否消除，若没有消除，会执行下一套方案，例如进行人工修复，直到故障消除为止。具体方案如下：

1、对玄武盾客户端进行监控纳管和自动化运维纳管

监控平台和自动化运维平台都是基于c/s的架构进行搭建纳管。网络方面：需要保证监控平台和自动化运维平台均与玄武盾服务器的网络双向通信。本实施例中将监控平台和自动化运维平台是部署在同一台物理机上面，因此平台侧的网络联通方面没有特殊要求。

在数据收集方面，因为玄武盾会部署在客户内网，或者部署在云端，而管理端即监控平台和自动化运维平台也不会完全暴露在公网之上，因此采取分布式代理架构，在每个不同的环境部署一个代理节点，通过代理节点和管理平台的点对点通信，来实现多环境分布式管理维护。

监控平台，通过agent(代理)对玄武盾客户端进行监控，定时将监控的数据收集至监控平台，然后监控平台可以设置告警阈值，一旦收集的数据触发了告警阈值，就会触发监控系统的触发器，触发器会调用监控平台里面自定义的动作，然后将产生的灾难告警信息通过指定路径发送出来(比如钉钉机器人，邮件，电话等)。

自动化运维平台，通过agent对玄武盾客户端进行管理，可以通过平台自动下发脚本管理，无需人工登陆机器进行操作。

关于agent收集数据的功能实现，可利用linux自带的命令、自带的文件、以及自定义的脚本这些方式去收集想要的监控数据。举例说明，当需要查看玄武盾(玄武盾客户端上的组件)每分钟的访问量以及4xx、5xx的比例曲线。

由于玄武盾的访问日志是根据小时来分割的，因此需要通过具体的时间打开对应的日志文件：file＝/waf/ha/log/`date+％y.％m.％d`.$hour.log，从日志里面筛选出最近1分钟的数据保存到临时文件中，cat$file|grep"`date-d"-1minutes"+％h:％m`:">$tmp_file，然后根据不同的响应码去抓取对应的数据，然后做统计分钟级别访问量：cat$tmp_file|awk'{if($8>＝200&&$8<900)print}'|grep-v"is"|wc–l；分钟级别4xx访问量：cat$tmp_file|awk'{if($8>＝400&&$8<500)print}'|grep-v"is"|wc–l；分钟级别5xx访问量：cat$tmp_file|awk'{if($8>＝500&&$8<＝600)print}'|grep-v"is"|wc–l。然后对这些值做数学运算计算出每分钟4xx和5xx的占比，scale_5xx＝$(printf"％.1f"`echo"scale＝1；$line_5xx*100/$line_all"|bc`)，scale_4xx(printf"％.1f"`echo"scale＝1；$line_404*100/$line_all"|bc`)，然后把这些值返回给服务器端进行存储。

关于agent自动化运维的功能实现，服务器通过接口发起命令执行请求，agent收到请求包后根据对应的脚本变量字段，去加载对应的脚本内容、执行用户、脚本类型等，然后调用对应的命令去执行，并且把执行结果返回给服务器

部分请求参数示例：

对应的服务器上面就会执行bashtest，而test的内容就是servicewafrestart

2、设置玄武盾客户端的灾难告警级别即灾难程度

灾难告警信息可以根据触发条件的不同设置不同的等级，可根据玄武盾之前的运维经验，将玄武盾本身分为三大模块：前端接入模块、后端回源模块、高可用模块；针对这三个不同模块设置为告警的灾难类型，因为这三个模块只要有一个出了故障就会导致整个玄武盾不可用，除此之外还需要对主机和网络进行监控告警，因为主机系统故障和网络不可用也会直接导致玄武盾不可用，可将由于主机和网络故障产生的灾难程度定义为严重或者一般严重。上述三大模块的故障灾难程度划分方式可以为：当响应时间超过第一预设阈值(例如10分钟)时，灾难程度设为严重；当响应时间超过第二预设阈值(例如8分钟)时，灾难程度设为一般严重，普通告警；或是根据客户端的重要程度来设置灾难程度，比较重要的设为重大灾难等。

3、将监控平台产生的灾难告警信息发送至自动化运维平台上

通过监控平台的自定义动作，可以通过自定义的脚本将灾难告警信息传输至自动化运维平台，也就是当灾难告警触发之后，监控平台会将灾难告警信息推送到自动化运维平台，同时监控平台也会把灾难告警通过指定路径(比如钉钉机器人，邮件，电话等)发送给运维人员。

当自动化平台收到灾难告警信息后，会执行事先定义好的灾难修复方案，该灾难修复方案通常由一连串的自定义脚本组成，通过运行这些脚本来替代运维人员登陆服务器的操作。

4、设置自动化的告警修复方案

针对上面定义过的三大模块，即前端接入模块，后端回源模块，高可用模块分别制定不同的告警修复方案。

(1)前端接入模块。

自动化运维平台接收到一条类似接入模块不可用的灾难告警信息，通过判断是不是核心进程数量不足，还是机器资源不足(内存耗尽，cpuload过高等)，还是核心进程无故卡死等等；判断完原因后可以先清理内存缓存，将资源释放出来，然后重启核心进程；若没有修复完成，再对其余无用的进程进行查杀，再次重启核心进程；若还未修复完成，则自动重启系统。当重启系统后如果故障还未解决，则会通过电话告警通知运维人员排查故障，从而终止自动修复的过程。

(2)后端回源模块.

自动化运维平台接收到类似访问回源站点不通的灾难告警信息，通过判断网络是否出现故障，比如ip不可用，网络有延时等，排除完网络故障之后；再去判断是否是核心进程由于配置下发出错而出现故障或者是资源不足而出现故障，定位到原因后(非网络原因的情况下)，可以尝试回滚配置文件，或者重启核心进程来修复；若还未修复完成，则自动重启系统。当重启系统后故障还未解决，则会通过电话告警通知运维人员排查故障，从而终止自动修复的过程。

(3)高可用模块。

自动化运维平台接收到高可用进程丢失或者虚拟ip出现脑裂的灾难告警信息，第一类故障可通过重启进程或者重装高可用模块来修复；第二类故障可通过在该节点修改虚拟路由id和密码来修复，若还没有恢复则会通过电话告警通知运维人员排查故障，从而终止自动修复的过程。

图2为本实施例提供的一种自动化运维平台和监控平台对玄武段客户端进行自动修复的流程示意图。在上述这些需要人工介入的方式都会在运维人员通过排障查明原因后，将新发生的故障点及对应的修复方案再加入到灾难告警修复方案库当中，逐步完善灾难告警修复方案库。

基于上述实施例，本申请能够极大改善运维人员需要无时无刻的盯着手机看着监控数据，一收到灾难告警信息就要去立马处理的这种现状，减少了人工成本，也减少了由于人为原因响应不及时或处理不当而导致对客户造成的重大影响。

下面对本申请实施例提供的一种玄武盾客户端灾难故障修复装置进行介绍，下文描述的玄武盾客户端灾难故障修复装置与上文描述的玄武盾客户端灾难故障修复方法可相互对应参照，相关模块均设置于中，参考图3，图3为本申请实施例所提供的一种玄武盾客户端灾难故障修复装置的结构示意图，包括：

在一些具体的实施例中，具体包括：

获取模块301，用于获取监控平台发送的灾难告警信息；灾难告警信息由监控平台对玄武盾客户端进行监控产生；

确定模块302，用于将灾难告警信息与预先制定的灾难告警修复方案库进行匹配，确定灾难告警修复方案库中与灾难告警信息匹配的灾难修复方案；

发送模块303，用于将告警修复方案发送至玄武盾客户端，以在玄武盾客户端上执行告警修复方案进行修复。

在一些具体的实施例中，确定模块302，包括：

识别单元，用于识别灾难告警信息中玄武盾客户端的灾难程度和玄武盾客户端的灾难类别；

查找单元，用于在灾难告警修复方案库中，查找与玄武盾客户端的灾难程度和玄武盾客户端的灾难类别相匹配的灾难修复方案。

在一些具体的实施例中，还包括：

判断单元，用于判断玄武盾客户端的灾难类型是否属于目标模块对应的故障类型；目标模块包括前端接入模块、后端回源模块、和高可用模块中的任意一项或多项；

发送单元，用于若否，则利用指定路径发送提示信息至运维人员；

在一些具体的实施例中，还包括：

获取模块，用于获取监控平台对玄武盾客户端的监测数据；

判断模块，用于根据监测数据，判断玄武盾客户端是否修复成功；

触发模块，用于若否，则触发监控平台发送提示信息至运维人员，以进行人工修复。

在一些具体的实施例中，还包括：

存储模块，用于当修复成功后，获取对玄武盾客户端进行修复的故障点和对应的修复方案，并将故障点和对应的修复方案存储至灾难告警修复方案库。

由于玄武盾客户端灾难故障修复装置部分的实施例与玄武盾客户端灾难故障修复方法部分的实施例相互对应，因此玄武盾客户端灾难故障修复装置部分的实施例请参见玄武盾客户端灾难故障修复方法部分的实施例的描述，这里暂不赘述。

本申请还公开一种玄武盾客户端灾难故障修复系统，包括：

玄武盾客户端，用于接收自动化运维平台发送的告警修复方案，并执行告警修复方案进行修复；

监控平台，用于对玄武盾客户端进行监控，产生灾难告警信息，并发送灾难告警信息至自动化运维平台；

自动化运维平台，用于执行上述的玄武盾客户端灾难故障修复方法的步骤。

在一些具体的实施例中，监控平台和自动化运维平台利用agent对玄武盾客户端进行管理。

由于玄武盾客户端灾难故障修复系统部分的实施例与玄武盾客户端灾难故障修复方法部分的实施例相互对应，因此玄武盾客户端灾难故障修复系统部分的实施例请参见玄武盾客户端灾难故障修复方法部分的实施例的描述，这里暂不赘述。

下面对本申请实施例提供的一种电子设备进行介绍，下文描述的电子设备与上文描述的玄武盾客户端灾难故障修复方法可相互对应参照。

本申请公开一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如上述玄武盾客户端灾难故障修复方法的步骤。

由于电子设备部分的实施例与玄武盾客户端灾难故障修复方法部分的实施例相互对应，因此电子设备部分的实施例请参见玄武盾客户端灾难故障修复方法部分的实施例的描述，这里暂不赘述。

下面对本申请实施例提供的一种计算机可读存储介质进行介绍，下文描述的计算机可读存储介质与上文描述的玄武盾客户端灾难故障修复方法可相互对应参照。

本申请公开一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述玄武盾客户端灾难故障修复方法的步骤。

由于计算机可读存储介质部分的实施例与玄武盾客户端灾难故障修复方法部分的实施例相互对应，因此计算机可读存储介质部分的实施例请参见玄武盾客户端灾难故障修复方法部分的实施例的描述，这里暂不赘述。

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

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种玄武盾客户端灾难故障修复方法、装置、系统、电子设备及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。