CN117931492A - 一种风险处理方法、装置及计算设备 - Google Patents

Abstract

本申请实施例公开了一种风险处理方法、装置及计算设备，涉及通信技术领域，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理。方法包括：获取诊断任务；基于诊断任务指示的待诊断的日志范围，确定待诊断的目标日志；基于诊断脚本，对目标日志进行诊断，确定诊断结果；基于诊断结果，对存在故障风险的风险设备创建修复任务。

Description

一种风险处理方法、装置及计算设备

技术领域

本申请实施例涉及通信技术领域，尤其涉及一种风险处理方法、装置及计算设备。

背景技术

随着计算机和互联网的发展，能够提供算力资源的互联网技术IT设备的数量随之增加，这类设备通常由大量的零部件组成，不同的零部件一般由不同的厂商提供，而零部件中可能存在批次性问题。

当前，针对这类设备的维护，通常是在服务器设备发生故障后，需运维人员通过人工对该设备的故障进行分析和修复，这种方式存在滞后性，影响IT设备正常处理业务。

发明内容

本申请实施例提供了一种风险处理方法、装置及计算设备，通过诊断脚本和待诊断的目标日志，确定存在故障风险的风险设备，并创建对应的修复任务，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理，提高修复风险设备的效率。

第一方面，本申请实施例提供了一种风险处理方法，该方法包括：获取诊断任务，诊断任务指示了待诊断的日志范围和诊断脚本；基于诊断任务指示的待诊断的日志范围，确定待诊断的目标日志；基于诊断脚本，对目标日志进行诊断，确定诊断结果，诊断结果指示了存在故障风险的风险设备；基于诊断结果，对存在故障风险的风险设备创建整改修复任务。

可以理解的是，获取了待检测是否存在故障风险的互联网技术IT设备的日志，获取诊断任务对应的诊断脚本，并对上述日志进行诊断，根据对应的诊断结果，能够确定存在故障风险的风险设备，进而针对风险设备创建修复任务，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理，提高修复风险设备的效率。

在一种可能的实现方式中，计算设备响应于诊断任务创建指令，根据接收到的诊断任务设置参数，创建诊断任务；诊断任务设置参数至少包括诊断脚本标签、待诊断日志标签和/或任务启动时间参数。

可以理解的是，根据接收到的诊断任务设置参数，来创建诊断任务，提高了设置诊断任务时的灵活性，提高了对目标日志进行诊断的效率和准确度。

在一种可能的实现方式中，计算设备基于诊断任务指示的待诊断的日志范围，确定待诊断的目标日志，包括：若诊断任务设置参数包括待诊断日志标签，从预设日志库中筛选得到待诊断日志标签对应的日志；根据日志对应的时间标签，从日志中筛选得到符合预设时间段的日志为待诊断的目标日志。

可以理解的是，通过诊断任务设置参数中的待诊断日志标签、日志的时间标签来获取目标日志，能够将一些明确不会涉及到的设备的日志，以及不符合预设时间段的日志提前排除在诊断任务范围外，提高获取待诊断的目标日志的速度，减少无效计算，进而提升了诊断效率。

在一种可能的实现方式中，基于诊断脚本，对目标日志进行诊断，确定诊断结果，包括：若诊断任务设置参数包括任务启动时间参数，确定任务启动时间参数对应的可用计算节点；可用计算节点用于进行分布式计算；将诊断脚本部署到可用计算节点上；响应于触发诊断任务，基于可用计算节点运行诊断脚本，对目标日志进行诊断，确定诊断结果。

可以理解的是，通过诊断任务设置参数中的任务启动时间参数，来确定启动诊断任务的时刻，提高了规划诊断任务的合理性和灵活性，避开计算资源紧张的时间段，保证了系统整体的负载均衡，提高系统的稳定性。

在一种可能的实现方式中，基于可用计算节点运行诊断脚本，对目标日志进行诊断，确定诊断结果，包括：根据可用计算节点的计算能力，分配对应数量的日志分析任务；若可用计算节点完成日志分析任务，并且仍存在未被诊断的日志，继续向计算节点分配未诊断的日志对应的日志分析任务；若全部日志均存在对应的诊断结果，根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

可以理解的是，根据可用计算节点的计算能力，先后分不同批次为计算节点分配对应数量的日志分析任务，可以提高可用计算节点的利用率，进而提高诊断任务的执行效率。

在一种可能的实现方式中，基于诊断脚本，对目标日志进行诊断，确定诊断结果，包括：从日志中读取设备信息；确定设备信息与诊断脚本中包含的目标设备信息匹配成功；根据诊断脚本，确定日志中的故障指纹日志；故障指纹日志包含用于诊断目标设备是否存在目标故障发生的风险的特征信息；根据诊断脚本，对故障指纹日志中的特征信息进行诊断，确定诊断结果；根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

可以理解的是，在设备信息匹配成功的情况下，根据对故障指纹日志中的特征信息进行诊断后的诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备，可以提高诊断效率和准确度。

在一种可能的实现方式中，接收上传的日志；根据日志，生成日志对应的日志形态标签、时间标签和/或关联关系标签；将各标签存储至预设日志库中。

可以理解的是，通过给不同的日志生成对应的标签并存储至预设日志库中，实现了日志在多个不同维度上的分类，可以提高从预设日志库中读取目标日志时的效率和准确度。

在一种可能的实现方式中，基于诊断结果，对存在故障风险的风险设备创建修复任务，包括：获取用于修复目标故障的修复脚本；从预设档案库中获取风险设备的设备信息、所在地理位置信息；根据地理位置信息、风险设备的设备信息和修复脚本，创建修复任务。

可以理解的是，在确定存在目标故障发生风险的风险设备后，获取对应的修复脚本、设备信息以及所在地理位置信息来对创建修复任务，能够用于指示相关人员或设备对风险设备的目标故障进行修复，提高对修复风险设备的效率，提高设备的安全性。

在一种可能的实现方式中，在根据修复脚本对风险设备进行修复前，计算设备从风险设备获取预设时间段的日志；根据诊断脚本，对日志进行诊断，确定风险设备存在目标故障。

可以理解的是，在对风险设备的目标故障进行修复前，再次根据诊断脚本确定风险设备存在目标故障，可以避免不必要的修复流程，降低误操作率，进而提高维护的效率和准确率。

第二方面，本申请实施例提供了一种风险处理装置，该风险处理装置用于执行上述第一方面提供的任意一种风险处理方法。

在一种可能的实现方式中，本申请实施例可以根据上述第一方面提供的方法，对该风险处理装置进行功能模块的划分。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。示例性的，本申请实施例可以按照功能将该风险处理装置划分为获取模块、确定模块、诊断模块以及修复模块等。上述划分的各个功能模块执行的可能的技术方案和有益效果的描述均可以参考上述第一方面或其相应的可能的实现方式提供的技术方案，此处不再赘述。

第三方面，本申请实施例提供了一种计算设备，计算设备包含处理器和存储器，处理器与存储器耦合；该存储器用于存储计算机指令，该计算机指令由处理器加载并执行以使计算设备实现如上述方面所述的风险处理方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质中存储有至少一条计算机程序指令，所述计算机程序指令由处理器加载并执行以实现如上述方面所述的风险处理方法。

第五方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算设备执行上述第一方面的各种可选实现方式中提供的风险处理方法。

本申请实施例中第二方面到第五方面及其各种实现方式的具体描述，可以参考第一方面及其各种实现方式中的详细描述；并且，第二方面到第五方面及其各种实现方式的有益效果，可以参考第一方面及其各种实现方式中的有益效果分析，此处不再赘述。

本申请实施例的这些方面或其他方面在以下的描述中会更加简明易懂。

附图说明

图1是根据一示例性实施例示出的一种应用场景的示意图；

图2是根据一示例性实施例示出的一种计算设备的示意图；

图3是根据一示例性实施例示出的一种风险处理方法的流程示意图；

图4是图3所示实施例中涉及的一种诊断任务的创建和执行的流程示意图；

图5是图3所示实施例中涉及的一种诊断脚本的调用方式的流程示意图；

图6是图3所示实施例中涉及的一种修复任务准备的界面示意图；

图7是图3所示实施例中涉及的一种修复任务设置的界面示意图；

图8是图3所示实施例中涉及的一种修复任务结果展示的示意图；

图9是图3所示实施例中涉及的一种修复任务结果的提交结果的界面示意图；

图10是本申请实施例涉及的一种标准脚本编写流程的示意图；

图11是根据一示例性实施例示出的另一种风险处理方法的流程示意图；

图12是本申请一个示例性实施例提供的风险处理装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

并且，在本申请实施例的描述中，除非另有说明，“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。同时，在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。

首先，对本申请实施例的应用场景进行示例性介绍。

当前，针对互联网技术(internet technology，IT)设备进行维护时，通常是在IT设备所运行的业务活动出现问题时，再启动维护流程，而当故障问题是硬件故障问题时，还会涉及到硬件的维修、更换甚至是返厂，这将导致设备停摆的时间进一步延长，造成损失和影响进一步加大，而且硬件故障通常是部件批次性问题，这种问题在同一种业务配置下，存在较大批量爆发的风险，需要提前进行修复处理。

而在相关技术中，针对上述IT设备的运维活动主要采用故障发生后处理的方式，这种方式仅能针对已经发生故障的现场设备进行修复，而且需要运维人员对相关设备进行问题定位和排查，耗时较长且存在严重的滞后性问题。

有鉴于此，本申请下述实施例提供了一种风险处理方法，能够基于诊断任务指示的诊断脚本确定目标日志的诊断结果，进而根据诊断结果确定存在故障风险的风险设备并创建相应的修复任务，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理，提高修复风险设备的效率。

图1示出了本申请实施例提供的一种应用场景的示意图，其中图1左侧为现场设备，即IT设备，例如现场设备可以包括IT设备A、IT设备B等多台IT设备，其中可以包括机架服务器、高密服务器、图形处理器(graphics processing unit，GPU)服务器等各类服务器设备。其中各个IT设备可以是互相独立的，也就是说各个IT设备可以处于不同的配置、不同的地理位置为不同的目标对象提供相应的服务。

上述IT设备在日常运行中会产生相应的日志文件，例如可以包括记录了设备操作人员下发或通过设置相关的自动化任务下发的命令的操作日志、记录了设备的运行状况或执行流程中的一些关键信息的运行日志以及用于定位设备故障问题的调试日志和错误日志等等。

图1右侧是远程的计算设备集群，该计算设备集群可以由多台计算设备组成，例如计算设备A、计算设备B等等，并且具有提供软件即服务(software as a service，SaaS)的功能，其中，SaaS是指一种基于云技术的软件交付模式，具体而言，是由云技术提供商开发和维护云技术应用软件，提供自动软件更新，并通过互联网以即用即付费的方式将软件提供给客户，其中所有的基础结构、中间件、应用软件和应用数据都位于对应的计算设备集群中。其中，计算设备集群中的计算设备可以是服务器，并且在计算设备集群中的每个计算设备中可以包括用于分布式计算的计算节点。

其中，分布式计算是一种与集中式计算是相对的计算方法，通常是将一个需要巨大的计算能力才能解决的问题分成多个小任务，并分配给多台计算设备进行处理，最后将各计算设备的处理结果进行集中，得到最终结果。

现场设备与计算设备集群之间具有通信的功能，具体可以是通过互联网传输或者通过物理的存储设备进行传输，本申请实施例对此并不作限制。

本申请实施例中计算设备集群可以获取诊断任务，其中诊断任务可以指示待诊断的目标日志范围和诊断脚本，其中待诊断的目标日志是现场设备产生和导出的，进而计算设备集群可以采取分布式计算的方式，基于诊断脚本对待诊断的目标日志进行诊断，确定诊断结果，进而针对诊断结果指示的存在故障风险的风险设备，创建修复任务，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理，提高修复风险设备的效率。

其次，对本申请实施例的系统架构进行示例性介绍。

图2示出了本申请实施例提供的一种计算设备的示意图。在硬件方面，该计算设备100可以包括处理器101、存储器102等，该计算设备还与显示终端110相连接，其中，处理器101可以包括中央处理器(central processing unit，CPU)、基板管理控制器(baseboardmanagement controller，BMC)等具有数据处理功能的电子部件。在软件方面，该计算设备100可以具有创建和执行诊断任务的功能，也就是说该计算设备100可以获取待诊断的的目标日志，并根据诊断脚本，对目标日志进行诊断，确定存在故障风险的风险设备。

需要说明的，下述实施例中描述的计算设备100执行某个步骤(如以下的S101至S104)可以理解为是：处理器101执行该步骤。

其中，存储器102可以存储有下述实施例中描述的计算设备100执行某个步骤对应的逻辑代码。

需要说明的，本申请实施例描述的系统架构以及应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

为了便于理解，以下结合附图对本申请提供的风险处理方法进行示例性介绍，该风险处理方法适用于图1所示的计算设备。

图3示出了本申请一个示例性实施例提供的风险处理方法的流程示意图。该风险处理方法包括如下步骤：

S101，获取诊断任务。

其中，诊断任务指示了待诊断的日志范围和诊断脚本。

在一种可能的实现方式中，计算设备可以创建诊断任务并获取诊断任务，计算设备通过连接的显示终端展示诊断任务创建界面，并接收用户按照实际需求进行设置的诊断任务设置参数，在计算设备接收到诊断任务创建指令时，可以根据接收到的诊断任务设置参数，创建诊断任务；其中，诊断任务设置参数至少包括诊断脚本标签、待诊断日志标签和/或任务启动时间参数。示例性的，图4是本申请实施例涉及的一种诊断任务创建和执行的流程示意图。

其中，各个诊断任务设置参数的说明如下：

a.任务名称，用于标识当前诊断任务的目的。

b.日志范围，用于在预设的日志库中筛选出待诊断的目标日志，其中，日志范围可以是从预设的日志库中选取一个或多个待诊断日志标签，例如：A区全网设备日志，通过设置日志范围能够避免产生大量无效运算，进而提高诊断的效率。

c.诊断脚本，用于在筛选出的目标日志中识别目标故障，诊断脚本可以是用户上传的，也可以是从预设的脚本库中选择的。

d.任务启动时间，用于确定诊断任务的启动时间，可以包括立即开始和指定时间开始，若当前具有可用的计算资源时，可选用立即开始；若当前没有可用的计算资源，需错峰执行时，可指定启动时间。其中，延时开始在实现上可以采用延时队列方案，如采用远程字典服务(remote dictionary server，Redis)的延时队列。

在创建诊断任务时，用户可以设置上述诊断任务设置参数中的一个或多个参数，而用户未进行设置的参数可以采用预设的默认参数。例如，用户未设置日志范围对应的待诊断日志标签时，可以默认对预设日志库中的全部日志进行诊断。基于上述方式，能够实现灵活设置诊断任务，通过设置日志范围提高计算设备获取目标日志的速度，减少无效计算，而且通过设置任务启动时间，避开计算资源紧张的时间段，保证了系统整体的负载均衡，提高系统的稳定性。

进而在执行上述步骤S101时，计算设备在获取诊断任务时，可以获取到上述诊断任务设置参数，从而实现了诊断任务对待诊断的日志范围和诊断脚本的指示。进一步地，计算设备在创建诊断任务后，可以执行图4中的步骤S201，消息生成、步骤S202，部署诊断脚本。

在步骤S201中，计算设备会生成诊断任务信息、日志分析任务信息和结果标注任务信息。

其中，诊断任务信息包括诊断任务设置参数，计算设备根据其中的任务启动时间确定可用计算节点，并将诊断脚本直接部署到可用计算节点上。

日志分析任务信息，包括具体的待诊断设备的设备号和日志，用于诊断任务开始执行后，分配给可用计算节点进行诊断。

结果标注任务信息，包括待诊断设备的设备号、所属客户关联信息以及待标注的诊断结果，用于执行诊断任务时，记录各待诊断设备对应的诊断结果，以便后续进行进一步的分析和统计。

在步骤S202中，计算设备会按照上述步骤S201中生成的诊断任务信息，将诊断脚本直接部署到可用计算节点上。

需要说明的是，由于图1中的步骤S103、S104分别包含了图4中的步骤S203、S204中的内容，所以图4中的步骤S203、S204的内容中在下面介绍步骤S103、S104的内容时一并进行解释说明，在此不再单独进行解释说明。

S102，基于诊断任务指示的待诊断的日志范围，确定待诊断的目标日志。

在执行上述步骤S102时，本申请实施例提供了一种可能的实现方式，若诊断任务设置参数包括待诊断日志标签，则计算设备从预设日志库中筛选得到待诊断日志标签对应的日志；根据日志对应的时间标签，从日志中筛选得到符合预设时间段的日志。

示例性的，若待诊断日志标签为B区全网设备日志，预设时间段为2023/11/01-2023/11/02，则计算设备会从预设日志库中筛选B区全网设备日志对应的日志，并且在这些日志中进一步筛选出2023/11/01-2023/11/02时间段中的日志。

这样，计算设备通过待诊断日志标签、时间标签能够高效准确的从预设日志库中确定目标日志，减少无效计算，提升诊断效率。

其中，上述待诊断的目标日志可以存储在预设的日志库中，而预设的日志库中的日志，可以是计算设备响应于日志获取指令从IT设备获取的，也可以是按照预设的时间间隔获取IT设备的日志，还可以是被动获取IT设备的日志，即接收IT设备主动的上传日志。

上述IT设备通常具备日志导出的功能，包括通过网络传输、导出到连接的例如移动硬盘之类的存储设备等多种传输方式，本申请实施例对此并不作限制。

在一种可能的实现方式中，计算设备在接收上传的日志后，可以根据日志包含的特征信息，生成日志对应的日志形态标签、时间标签和/或关联关系标签；将各标签存储至预设档案数据日志库中。

其中，日志可以是通过网络传输、从连接的设备导入等多种传输方式上传到计算设备的，本申请实施例对此并不作限制。

上述日志形态标签可以包括：系统日志、应用程序日志等；时间标签可以包括：采集时间标签和上传时间标签等；关联关系标签可以包括：设备类型标签和设备所属客户标签等。

这样，可以将接收到的日志以压缩格式进行存储，减少存储所需的空间资源，并通过各类生成的标签，提高了查找日志时的速度和准确度。执行上述步骤S102时，计算设备可以根据诊断任务中指定的诊断脚本名称去预设脚本库中读取该诊断脚本，或者是接收用户上传的诊断脚本。

计算设备在执行上述步骤S101-S102后，获取到了待检测的目标日志和用于检测目标日志关联的设备是否存在故障风险的诊断脚本。

S103，基于诊断脚本，对目标日志进行诊断，确定诊断结果。

其中，诊断结果指示了存在故障风险的风险设备，例如诊断结果为存在故障风险，则可以确定该诊断结果对应的目标日志所关联的设备为风险设备。

在执行上述步骤S103时，本申请实施例提供了多种可能的实现方式，包括：

1)若诊断任务设置参数包括任务启动时间参数，计算设备确定任务启动时间参数对应的可用计算节点；其中，可用计算节点用于进行分布式计算；将诊断脚本部署到可用计算节点上；响应于触发诊断任务，基于可用计算节点运行诊断脚本，对待诊断的目标日志进行诊断，确定存在目标故障发生风险的风险设备。

示例性的，任务启动时间参数为2023/11/05/19：00，计算设备确定该时间存在3个可用计算节点，分别为计算节点A、计算节点B、计算节点C，计算设备将诊断脚本A部署到上述3个计算节点上，当时间满足时，诊断任务被触发，计算节点A、计算节点B、计算节点C运行已经部署好的诊断脚本A，对待诊断的目标日志进行诊断，确定存在目标故障发生风险的风险设备。

基于上述实现方式，计算设备通过在多个计算节点上运行诊断脚本，基于分布式计算，确定目标日志的诊断结果，进而计算设备根据诊断结果和日志的关联关系标签，确定风险设备，这样能够提高系统中计算资源的利用率，从而提高诊断任务的执行效率。进一步地，在一种可能的实现方式中，计算设备在基于可用计算节点运行诊断脚本，对待诊断的目标日志进行诊断，确定存在目标故障发生风险的风险设备时，可以根据可用计算节点的计算能力，分配对应数量的日志分析任务；响应于可用计算节点完成分配的日志分析任务，若仍存在未被诊断的日志，计算设备可以继续向计算节点分配未诊断的日志对应的日志分析任务；若全部日志均存在对应的诊断结果，根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

例如，待诊断的目标日志包括了100个日志，计算设备分别根据可用计算节点A、可用计算节点B、可用计算节点C的计算能力，向可用计算节点A分配30个日志的日志分析任务，向可用计算节点B分配20个日志的日志分析任务，向可用计算节点C分配30个日志的日志分析任务，当可用计算节点A完成了分配的日志分析任务时，继续向可用计算节点A分配未诊断的20个日志的日志分析任务，当可用计算节点A、可用计算节点B、可用计算节点C分别完成了各自分配的日志分析任务，计算设备可以将收集全部的诊断结果，进而根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

基于上述实现方式，能够充分利用可用计算节点的计算资源，提高确定诊断结果和风险设备的速度。

2)计算设备还可以从日志中读取设备信息；确定设备信息与诊断脚本中包含的目标设备信息匹配成功时；根据诊断脚本，确定日志中的故障指纹日志，其中，故障指纹日志包含用于诊断目标设备是否存在目标故障发生的风险的特征信息，计算设备根据诊断脚本，对故障指纹日志中的特征信息进行诊断，确定诊断结果，进而根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

S104：基于诊断结果，对存在故障风险的风险设备创建修复任务。

在该步骤中，计算设备基于待诊断的目标日志的诊断结果，以及目标日志的关联关系标签，确定存在故障风险的风险设备，进而针对风险设备创建修复任务。示例性的，计算设备确定目标日志指示关联的设备存在故障风险，根据该日志的关联标签，确定风险设备的设备号为“SN123654”，属于“X公司”，所在地理位置信息为“A国B市C区XX街道XXX号”，计算设备根据上述信息以及故障风险对应的诊断脚本和修复脚本，创建对应的修复任务。

这样，能够提高修复风险设备的效率和准确度，实现对IT设备的主动运维模式，保证正常业务处理不受影响。基于上述步骤S101-S104，计算设备能够根据诊断脚本和待诊断的目标日志，确定存在故障风险的风险设备，并创建对应的修复任务，实现了主动检测IT设备的故障风险，保证IT设备进行正常的业务处理。

下面结合图5对上述2)中可能的实现方式进行说明，图5是本申请实施例涉及的一种诊断脚本的调用方式的流程示意图，包括：

S301：文件解压。

该步骤中，如果日志是压缩格式的文件则需要先执行上述步骤S301，以便计算设备对日志的具体内容进行读取，但在计算设备可以直接读取日志的具体内容时，则无需执行步骤S301。

S302：设备号读取。

其中，设备号是每台IT设备都具备的一种唯一标识，在步骤S302中，计算设备读取日志中的设备号。

S303：设备号比对。

该步骤中，计算设备将步骤S302中读取到的设备号与诊断脚本中包含的设备号信息进行对比，确定当前诊断的日志关联的设备与诊断脚本所指定的设备是一致的，避免目标设备被误诊的情况。

S304：确定故障指纹文件。

在该步骤中，计算设备将从多个日志文件中确定诊断脚本所指定的故障指纹文件，例如可以是通过读取文件名称中包含诊断脚本中指定字符的日志，或读取诊断脚本中指定路径下的日志等方式。

其中，故障指纹文件是指日志中的一部分特殊的日志，这类日志是由诊断脚本中指定的，且包含着用于诊断目标设备是否存在目标故障发生的风险的特征信息的日志。

S305：提取特征信息。

计算设备将根据诊断脚本读取上述故障指纹文件中的特征信息，例如，计算设备可以读取诊断脚本指定的故障指纹文件中第100行和第500行的文本信息，或者是读取诊断脚本指定的故障指纹文件中包含“错误”或“error”等指定关键字符的特征信息。

S306：诊断运算。

在该步骤中，计算设备根据诊断脚本对获取到的特征信息进行一系列的诊断运算，包括例如求交运算、求并运算和因果推断等等，以确定各特征信息以及之间的关系是否符合诊断脚本中的诊断逻辑，确定诊断结果。

S307：确定风险设备。

在该步骤中，计算设备根据各日志对应的诊断结果，确定诊断结果为存在目标故障发生风险的日志，并根据这些日志与设备之间的关联关系标签，进而确定存在目标故障发生风险的设备为风险设备。

基于上述步骤S301-S307，计算设备能够实现调用对诊断脚本，对待诊断的目标日志进行诊断，进而实现了对IT设备的故障风险进行主动式检测，保证IT设备进行正常的业务处理。

基于上述内容，计算设备能够基于诊断脚本，对目标日志进行诊断，确定诊断结果，进而确定风险设备，并创建相应的修复任务。为了修复风险设备的故障风险，进一步提高IT设备的安全性，下面将对风险设备进行故障修复的过程进行解释说明。

在一种可能的实现方式中，计算设备可以通过连接的显示终端展示修复任务所涉及的多个界面，并且可以接收用户输入的参数、脚本等内容，并且可以响应针对上述界面中各控件的点击等操作。这样能够提高执行修复任务时的灵活性，方便相关人员了解修复进度和相关故障信息，提高修复质量和效率。

在一种可能的实现方式中，计算设备基于诊断结果，对存在故障风险的风险设备创建修复任务时，可以获取用于修复目标故障的修复脚本；从预设档案库中获取风险设备的设备信息、所在地理位置信息；根据地理位置信息、风险设备的设备信息和修复脚本，创建修复任务。

其中，在对风险设备的目标故障进行修复时，可以根据实际需求采用远程修复或现场修复。

例如，计算设备获取用于修复目标故障的修复脚本A，并且从预设档案库中获取到风险设备的设备信息为A类设备，其设备号为SN13579、该设备的所在地理位置信息为A区，若计算设备可以控制该设备，则可以根据上述信息可以对该设备的目标故障进行远程修复。若计算设备无法控制该设备，则需根据上述信息，创建修复任务，将设备信息和修复脚本打包下发给A区关联的修复工程师对应的设备上。

基于上述实现方式，计算设备在确定存在目标故障发生风险的风险设备后，通过获取对应的修复脚本、设备信息以及所在地理位置信息来对创建修复任务，可以提高修复风险设备的效率。

在一种可能的实现方式中，计算设备在创建修复任务后，可以将修复任务存档至预设档案库中，这样可以统计执行修复进度，检验修复质量，进而有助于后续对风险处理流程进行进一步的优化。在一种可能的实现方式中，计算设备或工程师在根据修复脚本对风险设备进行修复前，可以从风险设备获取预设时间段的日志；根据诊断脚本，对日志进行诊断，确定风险设备存在目标故障。

基于上述实现方式，能够实现在进行修复前，再次诊断设备的状态，以确定是否要进行修复，避免不必要的修复流程，降低因误诊而对IT设备处理业务造成的影响。

在一种可能的实现方式中，诊断脚本可以集成到现场处理工具，或通过软件汇总的方式集成到计算设备上，这样在修复前对风险设备进行再次诊断时只需选择并运行相应的诊断脚本即可，提高了执行修复任务的准确度和效率。如图6所示，图6是本申请实施例涉及的一种修复任务准备的界面示意图，在进行修复前，计算设备或工程师可以通过获取风险设备的IP，保证通信畅通，并输入访问该风险设备所需的账号密码，以从风险设备获取最新的或者某个时间段的日志，然后设置目标故障对应的诊断脚本，对上述日志进行诊断，以再次确定该风险设备是否存在目标故障，避免对风险设备的误诊以及不必要的修复流程，进而提高修复任务的执行效率。

在一种可能的实现方式中，计算设备根据地理位置信息、风险设备的设备信息和修复脚本，对风险设备的目标故障进行修复时，计算设备可以基于选择的修复脚本，通过连接的显示终端展示对应的修复建议信息和问题描述信息，并且响应于修复脚本的运行指令，运行修复脚本对风险设备的目标故障进行修复，进而实现风险设备的故障修复，提高IT设备的安全性。

如图7所示，图7是本申请实施例涉及的一种修复任务设置的界面示意图，在对风险设备进行修复时，可以通过计算设备所连接的显示终端，和/或风险设备所连接的显示终端展示对应的修复建议信息和问题描述信息，以便相关人员了解故障和修复的相关信息。

在修复脚本执行结束后，展示如图8所示的界面，图8是本申请实施例涉及的一种修复任务结果展示的示意图，以便相关人员对了解修复结果的相关情况。

进一步地，若计算设备接收到针对提交结果的点击操作，还可以通过显示终端进一步展示如图9所示的界面，图9是本申请实施例涉及的一种修复任务结果的提交结果的界面示意图，以提示相关人员。

在一种可能的实现方式中，对风险设备进行故障修复之后，计算设备或现场处理工具可以再次对其导出的日志进行诊断，这样能够确定该故障是否彻底消除，实现诊断、修复、再诊断的流程闭环，进一步保证了IT设备的安全性。需要说明的是，为了进一步提高诊断及修复的效率和准确度，上述内容提到的诊断脚本和修复脚本均由一套公共的编码模式及调用方式，通过约定的编码模式的标准入参、出参、启动、处理控制，简化了脚本编写的过程，规范脚本的管理，参见图10，图10是本申请实施例涉及的一种标准脚本编写流程的示意图，即用户按照约定的标准脚本设计流程，即可输出对应的标准脚本。

基于上述编码模式及调用方式，能够实现计算设备在同时执行多个诊断脚本时，只需根据一个诊断脚本进行文件解压即可，无需重复解压，减少无效计算，而且通过规范脚本的输出，能够提高诊断和修复的效率和准确度。其中，关于诊断脚本的调用方式已在上述步骤S301-S307进行介绍，在此不再赘述。

图11是可适用于本申请另一实施例的流程示意图，其中现场设备中可以包括一个或多个服务器设备(仅示出了一个)。图11仅为示意图，并不构成对本申请实施例提供的技术方案的适用场景的限定。下面结合图11对本公开进行说明，在图11中，可以划分为两大模块，包括：现场设备模块和远程服务模块，其中，现场设备模块可以包括：IT设备单元和现场单元，远程服务模块可以包括：日志管理单元、分析单元、档案管理单元和作业派发单元，具体执行步骤包括：

S401：从现场设备中导出日志。

其中，现场设备是指互联网IT设备，也即本申请实施例中需要维护的对象，其可以提供导出日志、下发配置、重启服务等接口，以便于远程服务模块中的各单元与现场设备进行通信和控制。

示例性的，运维人员将现场设备的日志通过电子邮件的方式发送给远程服务模块。

S402：日志入库。

在该步骤中，可以由远程服务模块中的日志管理单元在接收到现场设备的日志，在接收到现场设备的日志后，日志管理单元可以直接将日志数据保存到预设的日志库中，也可以对日志进行分析、处理后，例如根据日志内容生成对应的日志上传时间标签、设备的关联关系标签等多个标签，之后再将日志压缩后和生成的标签一起保存到预设的日志库中。其中，日志管理单元可以是指部署在远程服务器上的软件或算法，也可以是指一种物理的计算设备，可以提供日志上传、下载的接口，并具有生成日志在不同维度上的标签的功能。

S403：问题定位。

在该步骤中，基于工程师或算法模型对已经发生故障的现场设备的日志进行问题定位，能够确定目标故障和日志内容的关联关系，并编写可以用于自动化检测目标设备是否存在目标故障发生的风险的诊断脚本。

S404：诊断脚本编码。

在该步骤中，可以由是对上述步骤S403中编写的诊断脚本进行编码，也可以对用户从预设的诊断脚本库中选择的诊断脚本进行编码，以使分析单元中的计算设备能够运行该诊断脚本。

S405：从预设的日志库中拉取日志。

在该步骤中，分析单元可以从日志库中读取日志，在读取日志时，还可以是根据获取到的诊断任务设置参数中的日志标签，从日志库中读取带有该标签的日志，这样能够提高日志读取的效率。其中，分析单元可以提供诊断任务创建、诊断结果查询等接口，并且具有诊断任务的创建及管理、脚本的导入及管理，日志分析任务的调度及执行，分析诊断结果等功能。

S406：创建诊断任务。

在该步骤中，分析单元可以根据用户设置的诊断任务设置参数创建诊断任务，例如创建一个名称为“XX零件批次性问题诊断”、诊断范围为C区全网设备最新日期的日志的、立即启动的、采用诊断脚本B的诊断任务。

S407：执行诊断任务。

这里，分析单元将基于多个计算节点通过分布式计算对待诊断的目标日志进行诊断，并确定每个日志对应的诊断结果，并且根据诊断结果和日志的关联关系标签，确定存在目标故障发生风险的风险设备。

S408：范围标注。

在该步骤中，档案管理单元将根据上述步骤S407中确定的风险设备，整理并存档。

例如，整理后的信息中的一个示例可以为：设备号：SN2468、客户：A公司、诊断结果：存在目标故障发生风险。

其中，档案管理单元可以提供结果标注接口、结果导出等接口，并且具有分析结果的收集及风险设备、风险客户的标注的功能。

S409：导出范围。

在该步骤中，档案管理单元将整理后的标注结果文档发送给作业系统，以使作业系统能够根据该标注结果文档进行修复任务创建等操作。

S410：发布脚本。

在该步骤中，运维人员将向作业派发单元发布与目标故障对应的诊断脚本和修复脚本。

S411：派发修复任务。

在该步骤中，作业派发单元将根据接收到的标注结果文档、诊断脚本以及修复脚本向现场单元对应的工程师关联的设备派发修复任务，修复任务可以包括待修复设备的设备信息，例如设备号，以及修复脚本，还可以包括用于现场进行再次诊断的诊断脚本。并且，作业派发单元将根据待修复设备所在的地理位置信息，按照就近原则确定现场单元对应的工程师，以及其所关联的设备。

其中，作业派发单元可以提供脚本发布、任务派发、修复结果收集等接口，并且具有发布诊断脚本及修复脚本、根据档案管理单元导出的标注结果文档生成现场任务、根据地理位置信息等信息自动派发修复任务的功能。

S412：实施修复。

在该步骤中，现场单元包括具体分为现场诊断单元和现场修复单元。

其中，现场诊断单元具有诊断脚本的导入、连接设备、收集日志、现场诊断等功能，可用于修复前诊断及修复后诊断确认；现场修复单元具有修复脚本的导入、连接设备、配置下发、数据恢复、结果反馈标注的功能。也就是说，本申请实施例中的诊断脚本和修复脚本既支持在远程服务模块上基于分布式计算运行，也支持在现场单元上本地运行。在具体实施时，现场单元可以是一名IT设备修复工程师，也可以是远程的服务器设备。

S413：结果反馈。

在该步骤中，现场单元将向作业派发单元反馈对应的修复结果，以便远程服务模块进行记录和存档，而且远程服务模块接收结果反馈，还可以进一步展示多个修复任务的处理进度。

基于上述步骤S401-S413，能够实现针对IT设备的主动运维模式，在故障风险尚未发生时，提前进行修复故障发生的风险，消除隐患，提高IT设备的可用性，并且通过回收修复结果，能够提高评价修复质量的准确度。

上述主要从方法的角度对本申请实施例的方案进行了介绍。可以理解的是，软件升级装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和软件模块中的至少一个。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对风险处理装置进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

示例性的，图12示出了本申请一个示例性实施例提供的风险处理装置1200的结构示意图。该风险处理装置1200应用于计算设备中，或者，该风险处理装置1200可以是计算机设备。该风险处理装置1200包括：

获取模块1210，用于获取诊断任务，所述诊断任务指示了待诊断的日志范围和诊断脚本。

确定模块1220，用于基于所述诊断任务指示的所述待诊断的日志范围，确定待诊断的目标日志。

诊断模块1230，基于所述诊断脚本，对所述目标日志进行诊断，确定诊断结果，所述诊断结果指示了存在故障风险的风险设备。

修复模块1240，用于基于所述诊断结果，对所述存在故障风险的风险设备创建修复任务。例如，结合图3，获取模块1210可以用于执行如图3所示的S101，确定模块1220可以用于执行如图3所示的S102，诊断模块1230可以用于执行如图3所示的S103，修复模块1240可以用于如图3所示的S104。

在一种可能的实现方式中，所述第一获取模块1210，还用于响应于诊断任务创建指令，根据接收到的诊断任务设置参数，创建诊断任务；所述诊断任务设置参数至少包括诊断脚本标签、待诊断日志标签和/或任务启动时间参数。

在一种可能的实现方式中，所述获取模块1210，还用于若所述诊断任务设置参数包括待诊断日志标签，从预设日志库中筛选得到所述待诊断日志标签对应的日志；根据所述日志对应的时间标签，从所述日志中筛选得到符合预设时间段的日志为待诊断的目标日志。

在一种可能的实现方式中，所述确定模块1220，还用于若所述诊断任务设置参数包括任务启动时间参数，确定所述任务启动时间参数对应的可用计算节点；所述可用计算节点用于进行分布式计算；将所述诊断脚本部署到所述可用计算节点上；响应于触发所述诊断任务，基于所述可用计算节点运行所述诊断脚本，对所述目标设备的日志进行诊断，确定诊断结果。

在一种可能的实现方式中，所述诊断模块1230，还用于根据所述可用计算节点的计算能力，分配对应数量的日志分析任务；若所述可用计算节点完成所述日志分析任务，并且仍存在未被诊断的日志，继续向所述计算节点分配所述未诊断的日志对应的日志分析任务；若全部所述日志均存在对应的诊断结果，根据所述诊断结果和所述日志的关联关系标签，确定存在所述目标故障发生风险的风险设备。

在一种可能的实现方式中，所述诊断模块1230，还用于从所述日志中读取设备信息；

确定所述设备信息与所述诊断脚本中包含的目标设备信息匹配成功；

根据所述诊断脚本，确定所述日志中的故障指纹日志；所述故障指纹日志包含用于诊断所述目标设备是否存在所述目标故障发生的风险的特征信息；

根据所述诊断脚本，对所述故障指纹日志中的所述特征信息进行诊断，确定诊断结果；

根据所述诊断结果和所述日志的关联关系标签，确定存在所述目标故障发生风险的风险设备。

在一种可能的实现方式中，还包括日志管理模块1250，所述日志管理模块1250用于接收上传的日志；根据所述日志，生成所述日志对应的日志形态标签、时间标签和/或关联关系标签；将各所述标签存储至预设日志库中。

在一种可能的实现方式中，所述修复模块1240用于获取用于修复所述目标故障的修复脚本；从预设档案库中获取所述风险设备的设备信息、所在地理位置信息；根据所述地理位置信息、所述风险设备的设备信息和所述修复脚本，创建修复任务。

在一种可能的实现方式中，所述诊断模块1230，还用于从所述风险设备获取预设时间段的日志；根据所述诊断脚本，对所述日志进行诊断，确定所述风险设备存在所述目标故障。

关于上述可选方式的具体描述可以参见前述的方法实施例，此处不再赘述。此外，上述提供的任一种风险处理装置的解释以及有益效果的描述均可参考上述对应的方法实施例，不再赘述。

作为示例，结合图1，风险处理装置中的获取模块1210、确定模块1220诊断模块1230以及修复模块1240中的部分或全部实现的功能可以通过图2中的计算设备100执行，获取模块1210、确定模块1220、诊断模块1230以及修复模块1240可以通过图1中的计算设备100的处理器101、存储器102以及计算设备100连接的显示终端110协同执行。

其中，计算设备100与显示终端110的连接方式可以是通过例如高清多媒体接口(High Definition Multimedia Interface，HDMI)数据线等有线通信方式进行连接的，还可以是通过蓝牙、无线保真(Wireless Fidelity，Wi-Fi)等无线通信方式进行连接的，本公开对此并不作限制。

在一示例性实施例中，还提供了一种计算机可读存储介质，用于存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述内存故障预测方法中的全部或部分步骤。例如，该计算机可读存储介质可以是只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、只读光盘(compact disc read-only memory，CD-ROM)、磁带、软盘和光数据存储设备等。

在一示例性实施例中，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算设备执行上述图3任一实施例所示方法的全部或部分步骤。

在一些实施例中，本申请实施例所示的方法可以实施为以机器可读格式被编码在计算机可读存储介质上的或者被编码在其它非瞬时性介质或者制品上的计算机程序指令。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种风险处理方法，其特征在于，所述方法包括：

获取诊断任务，所述诊断任务指示了待诊断的日志范围和诊断脚本；

基于所述诊断任务指示的所述待诊断的日志范围，确定待诊断的目标日志；

基于所述诊断脚本，对所述目标日志进行诊断，确定诊断结果，所述诊断结果指示了存在故障风险的风险设备；

基于所述诊断结果，对所述存在故障风险的风险设备创建修复任务。

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

响应于诊断任务创建指令，根据接收到的诊断任务设置参数，创建诊断任务；所述诊断任务设置参数至少包括诊断脚本标签、待诊断日志标签和/或任务启动时间参数。

3.根据权利要求2所述的方法，其特征在于，所述基于所述诊断任务指示的所述待诊断的日志范围，确定待诊断的目标日志，包括：

若所述诊断任务设置参数包括待诊断日志标签，从预设日志库中筛选得到所述待诊断日志标签对应的日志；

根据所述日志对应的时间标签，从所述日志中筛选得到符合预设时间段的日志为待诊断的目标日志。

4.根据权利要求2-3任一所述的方法，其特征在于，所述基于所述诊断脚本，对所述目标日志进行诊断，确定诊断结果，包括：

若所述诊断任务设置参数包括任务启动时间参数，确定所述任务启动时间参数对应的可用计算节点；所述可用计算节点用于进行分布式计算；

将所述诊断脚本部署到所述可用计算节点上；

响应于触发所述诊断任务，基于所述可用计算节点运行所述诊断脚本，对所述目标日志进行诊断，确定诊断结果。

5.根据权利要求4所述的方法，其特征在于，所述基于所述可用计算节点运行所述诊断脚本，对所述目标日志进行诊断，确定诊断结果，包括：

根据所述可用计算节点的计算能力，分配对应数量的日志分析任务；

若所述可用计算节点完成所述日志分析任务，并且仍存在未被诊断的日志，继续向所述计算节点分配所述未诊断的日志对应的日志分析任务；

若全部所述日志均存在对应的诊断结果，根据所述诊断结果和所述日志的关联关系标签，确定存在所述目标故障发生风险的风险设备。

6.根据权利要求1-5任一所述的方法，其特征在于，所述基于所述诊断脚本，对所述目标日志进行诊断，确定诊断结果，包括：

从所述目标日志中读取设备信息；

确定所述设备信息与所述诊断脚本中包含的目标设备信息匹配成功；

根据所述诊断脚本，确定所述日志中的故障指纹日志；所述故障指纹日志包含用于诊断所述目标设备是否存在所述目标故障发生的风险的特征信息；

根据所述诊断脚本，对所述故障指纹日志中的所述特征信息进行诊断，确定诊断结果；

根据所述诊断结果和所述日志的关联关系标签，确定存在所述目标故障发生风险的风险设备。

7.根据权利要求1-6任一所述的方法，其特征在于，所述方法还包括：

接收上传的日志；

根据所述日志，生成所述日志对应的日志形态标签、时间标签和/或关联关系标签；

将各所述标签存储至预设日志库中。

8.根据权利要求1-7任一所述的方法，其特征在于，所述基于所述诊断结果，对所述存在故障风险的风险设备创建修复任务包括：

获取用于修复所述目标故障的修复脚本；

从预设档案库中获取所述风险设备的设备信息、所在地理位置信息；

根据所述地理位置信息、所述风险设备的设备信息和所述修复脚本，创建修复任务。

9.根据权利要求8所述的方法，其特征在于，在根据所述修复脚本对所述风险设备进行修复前，所述方法还包括：

从所述风险设备获取预设时间段的日志；

根据所述诊断脚本，对所述日志进行诊断，确定所述风险设备存在所述目标故障。

10.一种计算设备，其特征在于，所述计算设备包括处理器和存储器；所述处理器与所述存储器耦合；所述存储器用于存储计算机指令，所述计算机指令由所述处理器加载并执行以使计算设备实现如权利要求1至9任一所述的风险处理方法。