一种故障修复数据包的发布方法及服务器转让专利
申请号 : CN201810121899.0
文献号 : CN108322345B
文献日 : 2020-08-21
发明人 : 陈颖聪
申请人 : 平安科技(深圳)有限公司
摘要 :
本发明适用于故障修复技术领域，提供了一种故障修复数据包的发布方法及服务器，包括：接收各个用户终端上传的设备运行日志；基于各个设备运行日志，分别确定各个用户终端包含的故障信息；对所述故障信息进行分类，确定故障信息的故障类型；根据故障类型包含的所述故障信息对应的用户终端，建立故障类型与用户终端之间的对应关系；若获取到用于修复故障类型的故障修复数据包，则基于对应关系，向故障类型对应的用户终端发送故障修复数据包。本发明只向存在相应故障类型的用户终端推送故障修复数据包，从而减少了服务器瞬时并发的数据量，减少了对服务器的硬件以及带宽要求。
权利要求 :
1.一种故障修复数据包的发布方法，其特征在于，包括：
接收各个用户终端上传的设备运行日志；
基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
2.根据权利要求1所述的发布方法，其特征在于，所述基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型，包括：基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，分别计算各个所述故障信息与预设的故障修复库中包含的预存故障类型的匹配度；计算所述匹配度的模型具体为：其中，所述S为所述故障信息与所述故障类型之间的匹配度；所述A1、A2、A3分别为所述故障信息的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述B1、B2、B3分别为所述预存故障类型的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述e为自然常数；
若存在一个所述预存故障类型与所述故障信息的匹配度大于预设的匹配度阈值，则将所述预存故障类型作为所述故障信息的故障类型，并将所述预存故障类型的故障修复数据包发送给所述故障信息所属的用户终端；
若任一所述预存故障类型与所述故障信息的匹配度均小于或等于预设的匹配度阈值，则根据所述故障信息携带的故障模块标识、终端软件版本以及故障响应方式，创建一个故障类型，并将创建的故障类型作为所述故障信息的故障类型。
3.根据权利要求1所述的发布方法，其特征在于，所述若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发布所述故障修复数据包，包括：获取所述故障修复数据包的数据量；
若所述故障修复数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述故障类型对应的各个用户终端发送所述故障修复数据包；
若所述故障修复数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述故障类型对应的各个用户终端发送所述故障修复数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
4.根据权利要求1所述的发布方法，其特征在于，所述基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息，包括：根据所述设备运行日志的开始时刻以及结束时刻，确定所述运行日志的运作时长；
若所述运作时长大于预设的时长阈值，则获取所述设备运行日志的资源消耗参数；
若所述资源消耗参数超过预设的消耗阈值，则识别所述设备运行日志为故障运行日志，并基于所述故障运行日志生成所述故障信息。
5.根据权利要求1-4任一项所述的发布方法，其特征在于，在所述基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包之前，还包括：获取所述用户终端的网络状态；
若所述网络状态满足预设的数据包下载状态，则执行所述基于所述对应关系，向所述故障类型对应的用户终端发布所述故障修复数据包的操作。
6.一种服务器，其特征在于，所述服务器包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下步骤：接收各个用户终端上传的设备运行日志；
基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
7.根据权利要求6所述的服务器，其特征在于，所述基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型，包括：基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，分别计算各个所述故障信息与预设的故障修复库中包含的预存故障类型的匹配度；计算所述匹配度的模型具体为：其中，所述S为所述故障信息与所述故障类型之间的匹配度；所述A1、A2、A3分别为所述故障信息的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述B1、B2、B3分别为所述预存故障类型的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述e为自然常数；
若存在一个所述预存故障类型与所述故障信息的匹配度大于预设的匹配度阈值，则将所述预存故障类型作为所述故障信息的故障类型，并将所述预存故障类型的故障修复数据包发送给所述故障信息所属的用户终端；
若任一所述预存故障类型与所述故障信息的匹配度均小于或等于预设的匹配度阈值，则根据所述故障信息携带的故障模块标识、终端软件版本以及故障响应方式，创建一个故障类型，并将创建的故障类型作为所述故障信息的故障类型。
8.根据权利要求6所述的服务器，其特征在于，所述若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发布所述故障修复数据包，包括：获取所述故障修复数据包的数据量；
若所述故障修复数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述故障类型对应的各个用户终端发送所述故障修复数据包；
若所述故障修复数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述故障类型对应的各个用户终端发送所述故障修复数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
9.根据权利要求6所述的服务器，其特征在于，所述基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息，包括：根据所述设备运行日志的开始时刻以及结束时刻，确定所述运行日志的运作时长；
若所述运作时长大于预设的时长阈值，则获取所述设备运行日志的资源消耗参数；
若所述资源消耗参数超过预设的消耗阈值，则识别所述设备运行日志为故障运行日志，并基于所述故障运行日志生成所述故障信息。
10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述方法的步骤。
说明书 :
一种故障修复数据包的发布方法及服务器
技术领域
[0001] 本发明属于故障修复技术领域，尤其涉及一种故障修复数据包的发布方法及服务器。
背景技术
[0002] 故障修复数据包，例如补丁，作为热修复的重要手段，被广泛用于各种应用程序或系统在运行中出现的故障修复。现有的故障修复数据包的发布方式，采用的是全局统一推送的发布方式，即向安装了故障修复数据包所需修复的应用程序或系统的所有用户终端统一进行的软件更新，以修改软件中所存在的漏洞。
[0003] 然而上述方式，要求同时向所有用户终端推送故障修复数据包，瞬时并发数据量较大，对服务器的硬件要求以及带宽资源要求较高。并且，若部分用户终端并未出现故障情况，也需要下载故障修复数据包，则浪费了该部分用户的数据流量，造成资源浪费，还可能因为安装了故障修复数据包而引起新的故障情况，降低用户的使用体验以及软件的稳定性。
发明内容
[0004] 有鉴于此，本发明实施例提供了一种故障修复数据包的发布方法及服务器，以解决现有的故障修复数据包的发布方法，对服务器的硬件要求以及带宽资源要求较高，以及对于并未出现故障情况的用户终端，造成资源浪费以及降低终端稳定性的问题。
[0005] 本发明实施例的第一方面提供了一种故障修复数据包的发布方法，包括：
[0006] 接收各个用户终端上传的设备运行日志；
[0007] 基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
[0008] 基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
[0009] 根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
[0010] 若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0011] 本发明实施例的第二方面提供了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
[0012] 接收各个用户终端上传的设备运行日志；
[0013] 基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
[0014] 基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
[0015] 根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
[0016] 若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0017] 本发明实施例的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
[0018] 接收各个用户终端上传的设备运行日志；
[0019] 基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
[0020] 基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
[0021] 根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
[0022] 若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0023] 实施本发明实施例提供的一种故障修复数据包的发布方法及服务器具有以下有益效果：
[0024] 本发明实施例通过采集用户终端的设备运行日志，并识别该用户终端中包含的故障信息，继而对该故障信息进行分类，确定该用户终端所包含的故障类型。当获取得到某一故障类型的故障修复数据包，则向存在该故障类型的所有用户终端发送该故障修复数据包，实现故障修复数据包定向发布的目的。与现有的故障修复数据包的发布方法相比，本发明实施例由于并非全局统一推送，只是向存在相应故障类型的用户终端推送故障修复数据包，从而减少了服务器瞬时并发的数据量，减少了对服务器的硬件以及带宽要求。另一方面，本发明实施例是一个定向发布的过程，对于不存在相应故障类型的用户终端并不会进行故障修复数据包的推送，从而避免了资源浪费，也能够提高用户终端的稳定性以及用户的使用体验。
附图说明
[0025] 为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0026] 图1是本发明第一实施例提供的一种故障修复数据包的发布方法的实现流程图；
[0027] 图2是本发明第二实施例提供的一种故障修复数据包的发布方法S103的具体实现流程图；
[0028] 图3是本发明第三实施例提供的一种故障修复数据包的发布方法S105的具体实现流程图；
[0029] 图4是本发明第四实施例提供的一种故障修复数据包的发布方法S102的具体实现流程图；
[0030] 图5是本发明第四实施例提供的一种故障修复数据包的发布方法的具体实现流程图；
[0031] 图6是本发明一实施例提供的一种服务器的结构框图；
[0032] 图7是本发明另一实施例提供的一种服务器的示意图。
具体实施方式
[0033] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0034] 本发明实施例通过采集用户终端的设备运行日志，并识别该用户终端中包含的故障信息，继而对该故障信息进行分类，确定该用户终端所包含的故障类型。当获取得到某一故障类型的故障修复数据包，则向存在该故障类型的所有用户终端发送该故障修复数据包，解决了现有的故障修复数据包的发布方法，对服务器的硬件要求以及带宽资源要求较高，以及对于并未出现故障情况的用户终端，造成资源浪费以及降低终端稳定性的问题。
[0035] 在本发明实施例中，流程的执行主体为服务器，该服务器将生成以及接收得到的故障修复数据包发送给各个对应的终端设备，实现对故障修复的目的。图1示出了本发明第一实施例提供的故障修复数据包的发布方法的实现流程图，详述如下：
[0036] 在S101中，接收各个用户终端上传的设备运行日志。
[0037] 在本实施例中，服务器与各个用户终端进行通信连接，用户终端可以预设的规则向服务器发送设备运行日志。具体地，用户终端在运行的过程中，可以以预设的时间间隔向服务器发送设备运行日志，该预设的时间间隔可以有用户自己进行设备，也可以由服务器统一对所有用户终端进行设备。用户终端还可以接收到关机指令后，在后台创建一条日志上传的进程，通过该进程向服务器发送设备运行日志，并进入拟关机状态；该拟关机状态具体为：用户终端关闭与上传设备运行日志无关的所有模块以及进程，例如，用户终端只保留通信模块以及日志上传的进程，关闭其他所有进程，以使用户终端减少电量消耗。
[0038] 在本实施例中，服务器可以用于修复某一应用程序所产生的故障情况，在该情况下，若用户终端安装有多个应用程序，则同时与各个应用程序对应的服务器进行通信连接，并将用户操作各个应用程序时生成的设备运行日志分别发送给对应的服务器。
[0039] 在本实施例中，服务器可以为不同的用户终端创建对应的数据库，并根据接收到的设备运行日志中携带有的终端标识，将设备运行日志存储至该终端标识对应的用户终端的数据库内，存储完毕后则执行S102的相关操作。
[0040] 在S102中，基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式。
[0041] 在本实施例中，服务器在接收到各个用户终端发送的设备运行日志后，则通过预设的故障信息识别规则，确定该用户终端上传的设备运行日志是否存在故障情况，若存在情况，则基于该设备运行日志生成一个故障信息。其中，该故障信息中包含了故障模块标识、故障软件版本以及故障响应方式。故障模块标识的确定方式具体为：识别设备运行日志中执行操作的设备模块，并将该设备模块的标识作为故障模块标识。故障软件版本的确定方式具体为：获取该设备运行日志中响应请求操作的应用程序，并安装于用户终端上的该应用程序的版本编号，将该版本编号作为终端软件版本。故障响应方式包括但不限于：强制退出、宕机、终端重启以及响应超时。
[0042] 在本实施例中，由于每一个设备运行日志中记录有响应本次操作的响应模块，因此若服务器识别了该设备运行日志为故障运行日志，则可以把设备运行日志中的响应模块的标识作为该故障信息的故障模块标识。设备运行日志中除了记录响应的模块外，还会记录有开始时间以及结束时间，可以将该运行时间与平均运行时间进行比较，确定本次操作是否为超时响应，还可以从设备运行日志中获取该运行进程的结束方式，从而通过上述两个方面，确定该故障信息中的故障响应方式。当然，对于故障软件版本这一信息，可以直接从设备运行日志中提取请求操作所在的环境软件标识，作为该故障信息的终端软件版本。
[0043] 可选地，在本实施例中，用户终端可以在检测到自身出现故障情况时，才将本次操作对应的设备运行记录发送给服务器，则服务器只要接收到终端设备发送的设备运行日志，则可以识别该用户终端出现异常情况，直接从设备运行日志从提取故障信息。
[0044] 当然，若设备运行日志中涉及多个模块协同运作完成一个任务请求，则一个故障信息中可以包含多个故障模块标识，也可以将不同的故障模块标识分为多个不同的故障信息进行记录。同样地，若一个任务请求需要多个应用程序协同完成，则一个故障信息中可以包含多个终端软件标识；也可以为不同的终端软件标识独立生成一个故障信息用以记录。
[0045] 在S103中，基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型。
[0046] 在本实施例中，服务器根据每一个故障信息中包含的故障模块标识、终端软件版本以及故障响应方式对其进行分类，由于通过上述三个特征项，则可以识别得到每一个故障信息所指示的故障情况是否相同或相似，从而确定是否由同一个成因引起的。例如，服务器接收到第一故障信息以及第二故障信息，第一故障信息中上述三个特征项分别为(WIFI模块、Ver1、连接超时)；第二故障信息中上述三个特征项分别为(WIFI模块、Ver1、丢包率高)，由此可见，第一故障信息与第二故障信息中故障模块标识以及终端软件版本编号均相同，并且故障响应方式类似，均是WIFI连接存在故障的常见响应方式，因此，可以将第一故障信息与第二故障信息识别为同一故障类型。通过上述方式，可以将不同用户终端上传的不同故障信息，归类为多个故障类型。
[0047] 在本实施例中，同一个故障类型可以包含多个来自不同故障终端的故障信息。服务器的数据库中还可以记录有已经识别确定了的故障类型。在该情况下，服务器可以将故障信息与已有的故障类型进行匹配，确定是否存在对应的已创建的故障类型，若是，则把匹配的故障类型作为该故障信息的故障类型，并将该故障信息对应的用户终端标识添加到该故障类型预先存储的对应关系表中。若数据库中不存在该故障信息对应的故障类型，则创建一个故障类型，并将该创建的故障类型与其他接收的故障信息进行匹配，确定本次接收到的其他故障信息是否属于该故障类型，从而完成对故障信息的分类操作。
[0048] 在S104中，根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端。
[0049] 在本实施例中，服务器在确定了各个故障信息的故障类型后，则识别每一个故障类型包含的故障信息，并基于各个故障信息所对应的用户终端，建立故障类型与用户终端之间的对应关系，举例性地，该故障对应关系如表1所示。参见表1，服务器可以为每一个故障类型配置一个故障编号，为该故障类型配置一个故障描述语段，并将用户终端的通信地址作为该用户终端的标识。
[0050]故障编号 故障描述 用户终端标识
1 WIFI连接故障 (198.15.255.14)；(185.52.61.243)；
2 触控屏触控错位 (14.56.212.250)；(201.212.85.2)；
1 WIFI连接故障 (198.15.255.14)；(185.52.61.243)；
2 触控屏触控错位 (14.56.212.250)；(201.212.85.2)；
[0051] 表1
[0052] 在本实施例中，服务器在确定了该故障类型后，则可以把该故障类型以及该故障类型包含的故障信息发送给故障修复管理员，以便故障修复管理员根据故障类型确定对应的故障修复方案，继而生成修复该故障类型的故障修复数据包；当然，若服务器中存储有故障修复算法，还可以通过该故障类型中的各个故障信息，搭建多个模拟用户终端，通过改变终端软件版本中的各个参数，以及修改后模拟用户终端的输出反馈，确定该故障类型是否已被修复，若是，则根据修复该故障类型所对应的终端软件的各个参数生成故障修复数据包。
[0053] 在S105中，若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0054] 在本实施例中，服务器可以通过管理员或故障修复算法在本地生成故障修复数据包，还可以接收来自其他设备发送的故障修复数据包，例如接收管理员的终端或上位服务器发送的故障修复数据包。由于故障修复具有一定的滞后性，即接收到用户终端反馈的故障信息，确定故障类型后，到获取到故障修复数据包之间存在一定的时间差，因此，服务器并非在接收到故障信息后马上实现故障修复数据包的发布流程，而是在接收到故障修复数据包后，才向该故障类型对应的用户终端推送该故障修复数据包。
[0055] 在本实施例中，服务器在获取到一个新的故障修复数据包后，则确定该故障修复数据包用于修复的故障类型，并基于S104中生成的对应关系查询存在该故障类型的用户终端有哪些，继而向上述用户终端发送该故障修复数据包，实现向用户终端定向进行故障修复的目的。
[0056] 特别地，服务器若对某一故障类型中的用户终端发送了故障修复数据包后，则可以把该用户终端的终端标识从对应关系中删除或者添加一个已发送标识。在后续的故障信息采集的过程中，当再次检测到某一用户终端反馈的故障信息属于已存在故障修复数据包的故障类型时，可以把新检测到的用户终端添加到该故障类型的对应关系中。若采用的是将已发送故障修复数据包的用户标识从对应关系中删除的方式，则服务器向对应关系表中当前存在的用户终端推送该故障修复数据包；若采用的是添加一个已发送标识的方式进行用户终端的区分，则服务器向已发送标识为空的用户终端发送该故障修复数据包。
[0057] 以上可以看出，本发明实施例提供的一种故障修复数据包的发布方法通过采集用户终端的设备运行日志，并识别该用户终端中包含的故障信息，继而对该故障信息进行分类，确定该用户终端所包含的故障类型。当获取得到某一故障类型的故障修复数据包，则向存在该故障类型的所有用户终端发送该故障修复数据包，实现故障修复数据包定向发布的目的。与现有的故障修复数据包的发布方法相比，本发明实施例由于并非全局统一推送，只是向存在相应故障类型的用户终端推送故障修复数据包，从而减少了服务器瞬时并发的数据量，减少了对服务器的硬件以及带宽要求。另一方面，本发明实施例是一个定向发布的过程，对于不存在相应故障类型的用户终端并不会进行故障修复数据包的推送，从而避免了资源浪费，也能够提高用户终端的稳定性以及用户的使用体验。
[0058] 图2示出了本发明第二实施例提供的一种故障修复数据包的发布方法S103的具体实现流程图。参见图2所示，相对于图1所述实施例，本实施例提供的一种故障修复数据包的发布方法中S103包括S1031～S1033，具体详述如下：
[0059] 在S1031中，基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，分别计算各个所述故障信息与预设的故障修复库中包含的预存故障类型的匹配度；计算所述匹配度的模型具体为：
[0060]
[0061] 其中，所述S为所述故障信息与所述故障类型之间的匹配度；所述A1、A2、A3分别为所述故障信息的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述B1、B2、B3分别为所述故障类型的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述e为自然常数。
[0062] 在本实施例中，服务器中存储有一个故障修复库，该故障修复库中包含多个故障类型，该故障类型可以是在直接采集终端设备的过程中采集并分类得到的故障类型，还可以是管理员在测试过程中发现的故障类型，也可以是接收上位服务器或分布式服务器为了对故障数据库同步而发送的故障类型。在该情况下，不同的服务器可以根据所述地区的不同或所管理的终端类型的不同，对用户终端进行划分，不同的服务器用于管理不同类型的用户终端，而各个服务器之间会以预设的时间间隔同步该故障修复库中的故障类型，从而减少了重复指定故障修复数据包的情况，减少管理员的修复压力，提高故障修复的效率。
[0063] 在本实施例中，服务器在接收到用户终端反馈的故障信息时，可根据该故障信息中包含的故障模块标识、终端版本编号以及故障响应方式，确定该故障信息是否属于已记录的故障类型中的其中一种，因此基于上述三个参数与故障修复库中的故障类型进行匹配度计算。计算各项特征项之间的差异程度，即计算|A1-B1|、|A2-B2|以及|A3-B3|，并将三个差值之和作为故障类型与故障信息之间的偏差度，并基于该偏差度得到匹配度。
[0064] 优选地，服务器基于各个模块之间的关联性，对各个模块进行编号，编号差异较小的则表示两个模块之间功能较为相似，关联性较大。例如，可以将通信模块归为第三大类，而蓝牙模块作为该大类中的第一小类，WIFI模块作为该大类中的第二小类，则蓝牙模块的编号可以为31，WIFI模块的编号可以为32，因此两者之间的差值为1；而显示模块属于第8大类，而显示模块中的触控屏属于第一小类，则触控屏的模块编号为81，因此触控屏模块与蓝牙模块之间的差值为50，从而基于故障模块标识之间的差值的大小，可以确定故障信息与故障类型是否匹配。如上所述，对于故障响应方式也可以通过上述方式进行编号，在此不再一一阐述。
[0065] 特别地，由于软件版本编号是基于版本生成日期的先后次序逐一编号的，因此直接计算版本编号之间的差值，则可以确定两个软件版本之间的差异程度，即作为计算匹配度的因子之一。
[0066] 在S1032中，若存在一个所述预存故障类型与所述故障信息的匹配度大于预设的匹配度阈值，则将所述预存故障类型作为所述故障信息的故障类型，并将所述预存故障类型的故障修复数据包发送给所述故障信息所属的用户终端。
[0067] 在本实施例中，服务器若在故障修复库中查找到一个预存故障类型与当前获取得到的故障信息的匹配度大于预设的匹配阈值，则将该预存故障类型识别为该故障信息对应的故障类型，特别地，若存在多个预存故障类型与该故障信息的匹配度均大于预设的匹配度阈值，则选取匹配度最高的一个预存故障类型，作为该故障信息的故障类型。
[0068] 在本实施例中，每个预存故障类型对应一个用于修改该预存故障类型的故障修复数据包，因此，服务器在确定某一故障信息属于预存故障类型后，可以直接向该故障终端发送该预存故障类型对应的故障修复数据包，从而实现故障修复的目的。
[0069] 在S1033中，若任一所述预存故障类型与所述故障信息的匹配度均小于或等于预设的匹配度阈值，则根据所述故障信息携带的故障模块标识、终端软件版本以及故障响应方式，创建一个故障类型，并将创建的故障类型作为所述故障信息的故障类型。
[0070] 在本实施例中，若故障修复库中各个预存故障类型与该故障信息之间的匹配度均小于或等于匹配度阈值，则表示该故障信息为新出现的故障信息，服务器并为对该故障进行修复，因此，将会基于该故障信息携带的故障模块表示、终端软件版本以及故障响应方式，创建一个故障类型，并将该故障类型存储于故障修复库中，并识别该创建的故障类型作为该故障信息的故障类型，然后执行S104以及S105的相关操作。
[0071] 在本发明实施例中，通过将故障信息与预存故障类型进行匹配，从而避免重复修复、重复存储的情况发生，减少了故障修复的管理员的工作压力，提高了故障修复的效率。
[0072] 图3了本发明第三实施例提供的一种故障修复数据包的发布方法S105的具体实现流程图。参见图3所示，相对于图1所述实施例，本实施例提供的一种故障修复数据包的发布方法中S105还包括S1051～S1053，具体详述如下：
[0073] 在S1051中，获取所述故障修复数据包的数据量。
[0074] 在本实施例中，服务器在发送故障修复数据包前，会先确定该故障修复数据包的数据量，并把该数据量与预设的数据量阈值进行比对，该故障修复数据包的数据量小于预设的数据量阈值，则执行S1052的操作；反之，若数据量大于或等于预设的数据量阈值，则执行S1053的操作。
[0075] 可选地，本实施例的数据量阈值可以由管理员进行手动设置，也可以服务器根据所处网络的带宽资源自动进行调整。例如，服务器设定了发送一个故障修复数据包的预计时长为4秒，且占用的带宽资源不能超过50％，当前的带宽资源为100M/s，由此可见，该数据量阈值则可以为：Vmax＝100M/s*50％*4＝200M。
[0076] 在S1052中，若所述故障修复数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述故障类型对应的各个用户终端发送所述故障修复数据包。
[0077] 在本实施例中，若服务器确定了该故障修复数据包的数据量小于预设的数据量阈值，则表示该故障修复数据包的数据量较小，发送一个数据包所需的时间较短，并不会出现因发送故障修复数据包，而导致发送超出预设时长仍未发送完毕的情况发送，在此基础上，通过主线程进行故障修复数据包的发送效率较高。由于主线程可调用的硬件资源以及带宽资源较多，因此进行数据包发送的效率也较高，但由于服务器在检测主线程运行时，会设置一个最大响应时长，若该响应时长超过预设的响应阈值，则会识别该主线程处于响应异常状态，则会终止该主线程的操作，重新进行响应。因此，若故障修复数据包的数据量较大，服务器则会识别该主线程处于响应异常状态，并反复终止并重发，导致资源浪费以及故障数据包无法正常发送的情况。因此，当故障数据包的数据量较小时，才可以通过主线程进行数据发布。
[0078] 在本实施例中，服务器在确定通过主线程向各个用户终端发送故障修复数据包时，可以根据用户终端上传故障信息的先后次序，作为该用户终端发送故障修复数据包的发送次序。
[0079] 在S1053中，若所述故障修复数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述故障类型对应的各个用户终端发送所述故障修复数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
[0080] 在本实施例中，若服务器在确定了故障修复数据包大于或等于数据量阈值，则表示该故障修复数据包的数据量较大，通过主线程串行方式进行发送的话，容易产生上述的发送超时的情况。因此，在该情况下，将通过子线程并行的方式向各个用户终端发送故障修复数据包。
[0081] 在本实施例中，服务器查询该故障类型的对应关系中记录了用户终端的终端个数，并在主线程下创建与该终端个数相同的子线程的个数，并将各个子线程的运行模式设置为异步并行模式，从而控制各个子线程分别与各个用户终端进行通信连接，通过各个子线程分别向各个用户终端发送故障修复数据包。
[0082] 可选地，若终端个数大于服务器最大子线程数，则创建与最大线程数数量相同的子线程，向部分用户终端进行故障修复数据包的发送操作，在发送完毕后，再对余下部分的用户终端进行发送，直到将该故障类型对应的用户终端均进行数据包发送操作。
[0083] 在本发明实施例中，服务器根据故障修复数据包的数据量大小，选择合适的发送方式进行数据发送，从而提高了发送效率以及发送的成功率。
[0084] 图4了本发明第四实施例提供的一种故障修复数据包的发布方法S102的具体实现流程图。参见图4所示，相对于图1所述实施例，本实施例提供的一种故障修复数据包的发布方法S102包括：S1021～S1023，具体详述如下：
[0085] 在S1021中，根据所述设备运行日志的开始时刻以及结束时刻，确定所述运行日志的运作时长。
[0086] 在本实施例中，各个设备运行日志中记录了本次服务响应操作的开始时刻以及结束时刻，服务器可以基于开始时刻以及结束时刻之间的差值，确定用户终端响应该服务所需的运行时长。
[0087] 可选地，服务器可基于该服务类型，查询该服务类型所对应的时间阈值。由于不同的服务类型所需响应的时间均不相同，因此具有对应的时长阈值。服务器可提取该设备运行日志中包含的服务类型，继而确定该故障类型的时长阈值，然后在将本次采集得到的运行时长与时长阈值进行比对。特别地，服务器可以基于用户终端多次反馈的关于该服务类型的设备运行日志，确定该服务类型的平均运行时长，并将该平均运行时长作为时长阈值。
[0088] 在本实施例中，若服务器检测到运行时长小于预设的时长阈值，则表示本次响应无异常，将该设备运行日志识别为正常运行日志；反之，若该运行时长大于预设的时长阈值，则进行S1022的操作，进一步确认该设备运行日志是否为故障运行日志。
[0089] 在S1022中，若所述运行时长大于预设的时长阈值，则获取所述设备运行日志的资源消耗参数。
[0090] 在本实施例中，由于运行时长大于预设的时长阈值，则表示本次服务响应属于超时响应，因此将获取本次服务时所消耗的用户终端的资源情况。由于对于故障响应，一般对用户终端的硬件资源占用较多，因此可基于资源消耗参数数值的大小，确定该设备运行日志是否为故障运行日志。
[0091] 在本实施例中，资源消耗参数可以为终端内存占用的数值，也可以为运算模块运算资源的占用的百分比。服务器将设备运行日志中的消耗资源参数与预设的消耗阈值进行比对。若并未超过预设的消耗阈值，则识别该设备运行日志为正常运行日志；反之，若超过预设的消耗阈值，则识别为故障运行日志，并执行S1023的操作。
[0092] 在S1023中，若所述资源消耗参数超过预设的消耗阈值，则识别所述设备运行日志为故障运行日志，并基于所述故障运行日志生成所述故障信息。
[0093] 在本实施例中，服务器在确定了响应本次服务所需用户终端的资源消耗参数超过预设的消耗阈值时，则表示本次操作占用了大量的用户终端的资源，确定响应该服务的过程中，存在故障情况，并生成一个故障信息。
[0094] 在本发明实施例中，通过对运行时长以及资源消耗参数判定设备运行日志是否为故障运行日志，从而实现了故障信息自动识别以及提取的目的，提高了故障修复的效率。
[0095] 图5了本发明第五实施例提供的一种故障修复数据包的发布方法的具体实现流程图。参见图5所示，相对于图1至图4所述实施例，本实施例提供的一种故障修复数据包的发布方法在所述基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包之前，还包括：S501以及S502，具体详述如下：
[0096] 在S501中，获取所述用户终端的网络状态。
[0097] 在本实施例中，服务器在向用户终端发送故障修复数据包之前，可以向用户终端发送一个网络状态获取请求，确定当前用户终端的网络状态。该网络状态即为与互联网进行通信联机的具体连接方式，是通过有线网络、无线局域网或是移动网络。用户终端基于当前与服务器通信的网络状态，生成一个网络状态结果返回给服务器。
[0098] 在S502中，若所述网络状态满足预设的数据包下载状态，则执行所述基于所述对应关系，向所述故障类型对应的用户终端发布所述故障修复数据包的操作。
[0099] 在本实施例中，服务器若确定当前用户终端的网络状态为预设的数据包下载状态，则向用户终端发送故障修复数据包。特别地，该数据包下载状态为：无线局域网状态或有线网络状态。
[0100] 可选地，若服务器确定当前网络状态不满足预设的数据包下载状态，则设置一个重发计时器，在重发计时器的计数值大于重发计数值后，返回S501的相关操作，直到用户终端的网络状态满足预设的数据包下载状态，再执行下载操作。
[0101] 可选地，用户终端在接收到网络状态获取请求后，当确定当前状态不满足预设的数据包下载状态时，可进入下载等待状态，当检测到用户终端的网络状态满足数据包下载状态时，主动向服务器发送一个数据包获取请求，以启动数据包下载操作。
[0102] 在本发明实施例中，通过获取用户终端的网络状态，判定是否执行数据包发送，避免用户终端无意下载而浪费大量的数据流量。
[0103] 应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
[0104] 图6示出了本发明一实施例提供的一种服务器的结构框图，该服务器包括的各单元用于执行图1对应的实施例中的各步骤。具体请参阅图1与图1所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。
[0105] 参见图6，所述服务器包括：
[0106] 设备运行日志接收单元61，用于接收各个用户终端上传的设备运行日志；
[0107] 故障信息获取单元62，用于基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
[0108] 故障类型确定单元63，用于基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
[0109] 对应关系确定单元64，用于根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
[0110] 故障数据包发送单元65，用于若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0111] 可选地，故障类型确定单元63包括：
[0112] 匹配度计算单元，用于基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，分别计算各个所述故障信息与预设的故障修复库中包含的预存故障类型的匹配度；计算所述匹配度的模型具体为：
[0113]
[0114] 其中，所述S为所述故障信息与所述故障类型之间的匹配度；所述A1、A2、A3分别为所述故障信息的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述B1、B2、B3分别为所述故障类型的故障模块标识、所述终端软件版本以及所述故障响应方式的参数值；所述e为自然常数；
[0115] 预存故障类型确定单元，用于若存在一个所述预存故障类型与所述故障信息的匹配度大于预设的匹配度阈值，则将所述预存故障类型作为所述故障信息的故障类型，并将所述预存故障类型的故障修复数据包发送给所述故障信息所属的用户终端；
[0116] 故障类型创建单元，用于若任一所述预存故障类型与所述故障信息的匹配度均小于或等于预设的匹配度阈值，则根据所述故障信息携带的故障模块标识、终端软件版本以及故障响应方式，创建一个故障类型，并将创建的故障类型作为所述故障信息的故障类型。
[0117] 可选地，故障数据包发送单元65，包括：
[0118] 数据量确定单元，用于获取所述故障修复数据包的数据量；
[0119] 串行发送单元，用于若所述故障修复数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述故障类型对应的各个用户终端发送所述故障修复数据包；
[0120] 并行发送单元，用于若所述故障修复数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述故障类型对应的各个用户终端发送所述故障修复数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
[0121] 可选地，故障信息获取单元62，包括：
[0122] 运行时长计算单元，用于根据所述设备运行日志的开始时刻以及结束时刻，确定所述运行日志的运作时长；
[0123] 资源消耗确定单元，用于若所述运行时长大于预设的时长阈值，则获取所述设备运行日志的资源消耗参数；
[0124] 故障运行日志确定单元，用于若所述资源消耗参数超过预设的消耗阈值，则识别所述设备运行日志为故障运行日志，并基于所述故障运行日志生成所述故障信息。
[0125] 可选地，所述服务器还包括：
[0126] 网络状态获取单元，用于获取所述用户终端的网络状态；
[0127] 网络状态判定单元，用于若所述网络状态满足预设的数据包下载状态，则执行所述基于所述对应关系，向所述故障类型对应的用户终端发布所述故障修复数据包的操作[0128] 因此，本发明实施例提供的服务器同样可以只向存在相应故障类型的用户终端推送故障修复数据包，从而减少了服务器瞬时并发的数据量，减少了对服务器的硬件以及带宽要求。另一方面，本发明实施例是一个定向发布的过程，对于不存在相应故障类型的用户终端并不会进行故障修复数据包的推送，从而避免了资源浪费，也能够提高用户终端的稳定性以及用户的使用体验。
[0129] 图7是本发明另一实施例提供的一种服务器的示意图。如图7所示，该实施例的服务器7包括：处理器70、存储器71以及存储在所述存储器71中并可在所述处理器70上运行的计算机程序72，例如故障修复数据包的发布程序。所述处理器70执行所述计算机程序72时实现上述各个故障修复数据包的发布方法实施例中的步骤，例如图1所示的S101至S105。或者，所述处理器70执行所述计算机程序72时实现上述各装置实施例中各单元的功能，例如图6所示模块61至65功能。
[0130] 示例性的，所述计算机程序72可以被分割成一个或多个单元，所述一个或者多个单元被存储在所述存储器71中，并由所述处理器70执行，以完成本发明。所述一个或多个单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序72在所述服务器7中的执行过程。例如，所述计算机程序72可以被分割成设备运行日志接收单元、故障信息获取单元、故障类型确定单元、对应关系确定单元以及故障数据包发送单元，各单元具体功能如下：
[0131] 设备运行日志接收单元，用于接收各个用户终端上传的设备运行日志；
[0132] 故障信息获取单元，用于基于各个所述用户终端上传的设备运行日志，分别确定各个所述用户终端包含的故障信息；所述故障信息包括：故障模块标识、终端软件版本以及故障响应方式；
[0133] 故障类型确定单元，用于基于所述故障模块标识、所述终端软件版本以及所述故障响应方式，对所述故障信息进行分类，确定所述故障信息的故障类型；
[0134] 对应关系确定单元，用于根据所述故障类型包含的所述故障信息对应的用户终端，建立所述故障类型与所述用户终端之间的对应关系；所述故障信息对应至少一个所述用户终端；
[0135] 故障数据包发送单元，用于若获取到用于修复所述故障类型的故障修复数据包，则基于所述对应关系，向所述故障类型对应的用户终端发送所述故障修复数据包。
[0136] 所述服务器7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述服务器可包括，但不仅限于，处理器70、存储器71。本领域技术人员可以理解，图7仅仅是服务器7的示例，并不构成对服务器7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器还可以包括输入输出设备、网络接入设备、总线等。
[0137] 所称处理器70可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0138] 所述存储器71可以是所述服务器7的内部存储单元，例如服务器7的硬盘或内存。所述存储器71也可以是所述服务器7的外部存储设备，例如所述服务器7上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器71还可以既包括所述服务器7的内部存储单元也包括外部存储设备。所述存储器71用于存储所述计算机程序以及所述服务器所需的其他程序和数据。所述存储器71还可以用于暂时地存储已经输出或者将要输出的数据。
[0139] 另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0140] 所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
[0141] 以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。