故障处理方法、系统、装置、存储介质和电子设备与流程

1.本公开涉及计算机技术领域，尤其涉及一种故障处理方法、系统、装置、存储介质和电子设备。


背景技术：

2.kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式项目配置和编排的自动化。kubernetes的稳定性在实际运行中至关重要，目前业界主要采用prometheus开源报警工具对kubernetes进行监控，并在故障发生时触发报警，以通知集群管理员及时处理。
3.但是，目前的通常接收kubernetes集群报警的是运维人员，而在解决kubernetes集群中故障时往往需要具备专业能力的研发人员介入。这样就导致运维人员很难在故障发生的第一时间做出专业的判断和处理，导致问题无法以最有效的方式解决。
4.因此，目前的kubernetes集群中故障诊断效率较低。


技术实现要素：

5.本公开提供了一种故障处理方法、系统、装置、存储介质和电子设备，进而提高kubernetes集群中故障诊断和故障处理效率。
6.第一方面，本公开一个实施例提供了一种故障处理方法，应用于开源平台，用于对待处理对象进行运维处理，该方法包括：
7.获取针对运维开源文件的地址标识；
8.基于地址标识从开发端调用运维开源文件，并基于运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型；
9.基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流；其中，运维进程库中包含多个运维进程；
10.基于目标运维工作流对待处理对象进行故障处理。
11.在本公开一个可选的实施例中，在基于故障类型调用运维进程库中的至少两个运维进程之前，该方法还包括：
12.获取在进行故障诊断时的诊断监控参数；
13.确定诊断监控参数是否超出预设阈值范围；
14.若诊断监控参数超出预设阈值范围，则基于故障类型调用运维进程库中的至少两个运维进程。
15.在本公开一个可选的实施例中，在基于故障类型调用运维进程库中的至少两个运维进程之前，该方法还包括：
16.确定诊断监控参数与预设的正则匹配模型是否匹配；
17.若诊断监控参数与预设的正则匹配模型相匹配，则基于故障类型调用运维进程库中的至少两个运维进程。
18.在本公开一个可选的实施例中，获取在进行故障诊断时的诊断监控参数，包括：
19.在进行故障诊断时，从待处理对象对应的监控系统、性能管理系统或日志系统中的至少两个系统中获取诊断监控参数。
20.在本公开一个可选的实施例中，诊断监控参数至少包括：故障标识、故障诊断节点标识、诊断凭证标识中的任一种。
21.在本公开一个可选的实施例中，基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流，包括：
22.获取针对目标故障类型的目标运维进程序列表；其中，目标运维进程序列表中包括用于处理目标故障类型的故障的，按照预设序列排列的多个运维进程；
23.基于目标运维进程序列表对调用的运维进程库中的至少两个运维进程进行编排，以生成目标有向无环图；其中，目标有向无环图用于指示目标运维工作流。
24.在本公开一个可选的实施例中，该方法还包括：
25.获取基于目标运维工作流对待处理对象进行故障处理期间内各个时刻的故障处理信息；
26.基于各故障处理信息生成故障处理日志。
27.第二方面，提供了一种故障处理系统，包括：
28.管理组件，用于获取运维开源文件，以及运维开源文件对应的地址标识；
29.基于地址标识调用运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型；
30.基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流；其中，运维进程库中包含多个运维进程；
31.执行组件，用于基于目标运维工作流对待处理对象进行故障处理中的故障进行处理
32.第三方面，提供了一种故障处理装置，该装置包括：
33.获取模块，用于获取运维开源文件，以及运维开源文件对应的地址标识；
34.确定模块，用于基于地址标识调用运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型；
35.生成模块，用于基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流；其中，运维进程库中包含多个运维进程；
36.处理模块，用于基于目标运维工作流对待处理对象进行故障处理。
37.在本公开一个可选的实施例中，该处理模块还用于，
38.获取在进行故障诊断时的诊断监控参数；
39.确定诊断监控参数是否超出预设阈值范围；
40.若诊断监控参数超出预设阈值范围，则基于故障类型调用运维进程库中的至少两个运维进程。
41.在本公开一个可选的实施例中，该处理模块用于，
42.确定诊断监控参数与预设的正则匹配模型是否匹配；
43.若诊断监控参数与预设的正则匹配模型相匹配，则基于故障类型调用运维进程库中的至少两个运维进程。
44.在本公开一个可选的实施例中，该处理模块用于，
45.在进行故障诊断时，从待处理对象对应的监控系统、性能管理系统或日志系统中的至少两个系统中获取诊断监控参数。
46.在本公开一个可选的实施例中，该诊断监控参数至少包括：故障标识、故障诊断节点标识、诊断凭证标识中的任一种。
47.在本公开一个可选的实施例中，该生成模块用于，
48.获取针对目标故障类型的目标运维进程序列表；其中，目标运维进程序列表中包括用于处理目标故障类型的故障的，按照预设序列排列的多个运维进程；
49.基于目标运维进程序列表对调用的运维进程库中的至少两个运维进程进行编排，以生成目标有向无环图；其中，目标有向无环图用于指示目标运维工作流。
50.在本公开一个可选的实施例中，该处理模块还用于，
51.获取基于目标运维工作流对待处理对象进行故障处理期间内各个时刻的故障处理信息；
52.基于各故障处理信息生成故障处理日志。
53.第四方面，本公开一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上的方法。
54.第五方面，本公开一个实施例提供了一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行如上的方法。
55.本公开的技术方案具有以下有益效果：
56.上述故障处理方法，先基于运维开源文件的地址标识从开发端调用得到的运维开源文件，然后在运维端基于运维文件、运维程序等进行故障诊断和故障处理，也就是说，本公开实施例将运维端与开发端分别对应的文件、程序、功能等通过运维端与开发端两个不同的端口清晰的划分开来。在出现故障时，运维人员和开发人员只需要通过其对应的端口负责处理其对应的任务模块即可，避免了传统技术中，在出现故障时需要运维人员与开发人员一起进行故障原因分析，先确定当前的故障的处理归属，最后才能由对应的专业工作人员进行故障处理而导致的故障诊断与故障处理效率低下的问题。本公开实施例通过为运维人员与开发人员提供不同的端口，可以清晰的界定不同角色的维护模块，开发人员与运维人员通过不同的端口在进行故障诊断和故障处理过程中，执行各自的维护和处理模块，可以大大提高故障诊断与故障处理的效率。
57.同时，本公开实施例先通过确定待处理对象对应的故障类型，然后基于故障类型确定对应的目标运维工作流，最后基于得到的目标运维工作流实现对待处理对象中对应类型故障的自动化故障处理，从而大大提高故障诊断与故障处理的自动化程度与效率。
58.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
59.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施方式，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以
根据这些附图获得其他的附图。
60.图1示出本示例性实施方式中一种故障处理方法的应用场景示意图；
61.图2示出本示例性实施方式中一种故障处理方法的流程图；
62.图3示出本示例性实施方式中一种故障处理方法的流程图；
63.图4示出本示例性实施方式中一种故障处理方法的流程图；
64.图5示出本示例性实施方式中一种故障处理方法的流程图；
65.图6示出本示例性实施方式中一种故障处理方法中的有向无环图；
66.图7示出本示例性实施方式中一种故障处理方法的流程图；
67.图8示出本示例性实施方式中一种故障处理装置结构示意图；
68.图9示出本示例性实施方式中一种电子设备的结构示意图。
具体实施方式
69.现在将参考附图更全面地描述示例性实施方式。然而，示例性实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例性实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
70.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
71.附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
72.相关技术中，kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式项目配置和编排的自动化。kubernetes的稳定性在实际运行中至关重要，目前业界主要采用prometheus开源报警工具对kubernetes进行监控，并在故障发生时触发报警，以通知集群管理员及时处理。但是，目前的通常接收kubernetes集群报警的是运维人员，而在解决kubernetes集群中故障时往往需要具备专业能力的研发人员介入。这样就导致运维人员很难在故障发生的第一时间做出专业的判断和处理，导致问题无法以最有效的方式解决。因此，目前的kubernetes集群中故障诊断效率较低。
73.鉴于上述问题，本公开实施例提供了一种故障处理方法，先基于运维开源文件的地址标识从开发端调用得到的运维开源文件，然后在运维端基于运维文件、运维程序等进行故障诊断和故障处理，也就是说，本公开实施例将运维端与开发端对应的文件、程序、功能等通过运维端与开发端两个不同的端口清晰的划分开来。在出现故障时，运维人员和开
发人员只需要通过其对应的端口负责处理其对应的任务模块即可，避免了传统技术中，在出现故障时需要运维人员与开发人员一起进行故障原因分析，先确定当前的故障的处理归属，最后才能由对应的专业工作人员进行故障处理而导致的故障诊断与故障处理效率低下的问题。本公开实施例通过为运维人员与开发人员提供不同的端口，可以清晰的界定不同角色的维护模块，开发人员与运维人员通过不同的端口在进行故障诊断和故障处理过程中，执行各自的维护和处理模块，可以大大提高故障诊断与故障处理的效率。
74.同时，本公开实施例先通过确定待处理对象对应的故障类型，然后基于故障类型确定对应的目标运维工作流，最后基于得到的目标运维工作流实现对待处理对象中对应类型故障的自动化故障处理，从而大大提高故障诊断与故障处理的自动化程度与效率。
75.以下对本公开实施例提供的故障处理方法的应用环境作简单介绍：
76.请参见图1，本公开实施例提供的故障处理方法应用于故障运维处理系统10，该故障运维处理系统10至少包括：开发端101和运维端102。其中，开发端101是指开发人员工作的设备终端，用于存储及运行由开发人员开发的用于进行故障诊断、故障处理等功能的运维开源文件；运维端102是指运维人员或测试人员等工作的设备终端，用于对软件、程序等对象进行故障诊断、测试、处理等工作。运维端102可以搭载有一开源平台，运维人员可以基于开发人员开发的故障诊断程序、故障处理程序等对待处理对象进行运维处理。需要指出的是，开发端101和运维端102可以为两种不同的终端设备，也可以为同一终端设备中的两种不同节点，分别由开发人员与运维人员进行维护。该终端设备可以为服务器、服务器集群、计算机、笔记本电脑等，本实施例不作具体限定，可根据实际情况具体选择或者设定。
77.下面以上述运维端102为执行主体，将该故障处理方法应用于上述的运维端102中的开源平台，对待处理对象进行运维处理为例进行举例说明。请参见图2，本公开实施例提供的故障处理方法包括如下步骤201
‑
步骤204。
78.步骤201、运维端获取针对运维开源文件的地址标识。
79.其中，运维开源文件是指由开发人员开发并存储于开发端的，用于对软件、程序等对象进行故障诊断的程序文件。该运维开源文件可以包括有：源代码、注册信息等，其中，该注册信息具体可以包括例如：http、https、协议、地址标识等信息。需要指出的是，该地址标识用于表征运维开源文件的存储位置，以方便对该运维开源文件进行准确且快速的定位。该地址标识的形式可以为端口号 ip地址等，本实施例对于该地址标识的具体形式不作任何限定，可根据实际情况具体设定。运维端可以通过网络链路从开发端实时获取该地址标识，也可以通过工作人员将该地址标识直接输入至运维端，从而使得运维端获取得到该地址标识，本实施例对于获取该地址标识的具体途径和方式不作任何限定，可根据实际情况具体设定。
80.步骤202、运维端基于地址标识从开发端调用运维开源文件，并基于运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型。
81.运维开源文件存储于开发端，由开发人员进行日常维护，每个运维开源文件对应有其地址标识。在运维人员需要对软件、程序等待处理对象进行故障诊断时，将该待处理对象接入运维端，并同时基于步骤201得到的地址标识从开发端调用位于该地址标识对应的地址上的运维开源文件，以通过该运维开源文件对待处理对象进行故障诊断。运维开源文件在执行时对待处理对象的运行状态进行实时监测，并通过异常参数或异常节点确定该待
处理对象当前的故障类型，例如响应时间大于预设阈值，则判断当前待处理对象出现延时故障。
82.步骤203、运维端基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流。
83.其中，该运维进程库中包含多个运维进程，不同的运维进程用于执行不同的运维处理功能，运维进程库中的多个运维进程可以按照一定的预设次序排列，以方便后续可以对不同的运维进程进行快速且准确的定位。不同类型的故障具有不同的处理方式，因此，运维端按照当前故障的故障类型调用与该故障类型对应的至少两个运维进程，并对该至少两个运维进行的执行顺序进行编排，形成针对该类型故障的具有固定处理路径的目标运维工作流。需要指出的是，不同类型的故障对应的运维进程的数量、类别以及形成的目标工作流中的若干个运维进程编排顺序也不尽相同，对此，本实施例不作具体限定，可根据实际情况具体处理。
84.步骤204、运维端基于目标运维工作流对待处理对象进行故障处理。
85.该目标运维工作流是针对目标类型的故障，将多个运维进程按照一定顺序编排得到的，形成了固定的处理路径，也就是说，针对不同类型的故障具有对应的固定处理路径。运维端在得到目标运维工作流后，便可以针对性的对其对应的类型的故障进行自动化的处理，从而大大提高故障处理的自动化程序与高效性。
86.第一方面，本公开实施例提供的故障处理方法是基于运维开源文件的地址标识从开发端调用得到的运维开源文件，然后在运维端基于运维文件、运维程序等进行故障诊断和故障处理，也就是说，本公开实施例将运维端与开发端对应的文件、程序、功能等通过运维端与开发端两个不同的端口清晰的划分开来。在出现故障时，运维人员和开发人员只需要通过其对应的端口负责处理其对应的任务模块即可，避免了传统技术中，在出现故障时需要运维人员与开发人员一起进行故障原因分析，先确定当前的故障的处理归属，最后才能由对应的专业工作人员进行故障处理而导致的故障诊断与故障处理效率低下的问题。本公开实施例通过为运维人员与开发人员提供不同的端口，可以清晰的界定不同角色的维护模块，开发人员与运维人员通过不同的端口在进行故障诊断和故障处理过程中，执行各自的维护和处理模块，可以大大提高故障诊断与故障处理的效率。
87.第二方面，本公开实施例先通过确定待处理对象对应的故障类型，然后基于故障类型确定对应的目标运维工作流，最后基于得到的目标运维工作流实现对待处理对象中对应类型故障的自动化故障处理，从而大大提高故障诊断与故障处理的自动化程度与效率。
88.请参见图3，在本公开一个可选实施例中，在步骤203运维端基于故障类型调用运维进程库中的至少两个运维进程之前，该方法还包括如下步骤301
‑
步骤303：
89.步骤301、运维端获取在进行故障诊断时的诊断监控参数。
90.运维端通过接入的事件报警程序等具有监测功能的程序对诊断过程进行实时监控，以使得运维端可以实时获取得到在诊断过程中的各诊断监控参数。该诊断监控参数可以为在诊断过程中产生的节点状态、运行参数等，例如各节点的响应时长等。
91.步骤302、运维端确定诊断监控参数是否超出预设阈值范围。
92.运维端通过步骤301获取得到在进行故障诊断时的诊断监控参数，然后判断当前的诊断监控参数是否超过预设阈值范围。例如针对上述步骤301中的各节点的响应时长，预
设阈值范围为0～3s，若当前的响应时长为4s，则确定当前的诊断监控参数已经超出了预设阈值范围，若当前的响应时长为2s，则确定当前的诊断监控参数未超出预设阈值范围。当然，本实施例中的诊断监控参数还包括其他，例如复制延迟时长、复制余量、复制状态、线程堆栈大小、日志文件大小、声明缓存大小、连接大小等，本实施例在此不作穷举。
93.步骤303、若诊断监控参数超出预设阈值范围，运维端则基于故障类型调用运维进程库中的至少两个运维进程。
94.若当前的诊断监控参数超出了预设阈值范围，则意味着当前的待处理对象可能发生了故障。运维端可以基于当前的监控参数确定故障类型，并基于得到的故障类型从预先设定并存储的故障处理列表中查找得到与该故障类型对应的至少两个运维进程，最后再从内部存储的运维进程库中调用该至少两个运维进程。
95.本公开实施例提供的故障处理方法先通过从预先在运维端中的开源平台内配置的，或者通过端口接入的外接的事件报警程序等获取得到在进行故障诊断时的诊断监控参数，然后基于该诊断监控参数确定当前待处理对象是否发生了故障，将对于待处理对象运行过程中的参数诊断任务交由外接程序执行，在保证监控效果的前提下可以大大减小运维端的数据处理压力，以提高后续的故障诊断与故障处理的效率。同时，本公开实施例还可以基于该诊断监控参数确定当前的故障类型，最后基于得到的故障类型有针对性的从运维进程库中调用与该故障类型对应的至少两个运维进程，可以提高故障类型诊断的精准性，从而进一步提高本公开实施例提供的故障处理方法的故障处理效率与处理效果。
96.请参见图4，在本公开一个可选实施例中，在步骤203运维端基于故障类型调用运维进程库中的至少两个运维进程之前，该方法还包括如下步骤401
‑
步骤402：
97.步骤401、运维端确定诊断监控参数与预设的正则匹配模型是否匹配。
98.其中，正则匹配模型是指由普通的字符(例如字符a到z)以及特殊字符(元字符)组成的文字模式，用于描述在查找模板主体时待匹配的一个或多个字符串，以进行模式匹配和替换的规范的模型。通俗的讲，该正则匹配模型是作为一个模板，将某个字符模式与所查找的字符串进行匹配。一般，通过外接事件报警程序获取的诊断监控参数一般为字符串形式，每个字符串后面必然会有对应有一个或多个具有逻辑判断含义的通配符，例如“^？”表示任意字符，“^#”表示任意数字，“@”表示要查找的字符中包含一个以上的前一字符，“*”表示代替任意多个字符。不同的通配符具有不同的含义，因此，本实施例只需要基于正则模型对获取得到的争端监控参数进行判断，也就是对其进行匹配即可，可以大大提高故障诊断的效率。例如，得到的诊断监控参数为“kubepodcrashlooping”，若预设的正则匹配模型为“kubepodcrashloop$”，则两者无法匹配；若预设的正则匹配模型为“kubepod.*”，则两者相匹配，则意味着当前的故障处于本公开预先设定的诊断策略与处理策略中。
99.步骤402、若诊断监控参数与预设的正则匹配模型相匹配，运维端则基于故障类型调用运维进程库中的至少两个运维进程。
100.第一种情况，若诊断监控参数与预设的正则报警模板相匹配，则意味着当前的故障处于本公开预先设定的诊断策略与处理策略中，因此，则基于确定得到的故障类型调用运维进程库中的至少两个运维进程，对出现的故障进行处理。第二种情况，若诊断监控参数与预设的正则报警模板不匹配，则意味着当前的故障不处于本公开预先设定的诊断策略与处理策略中，因此不再继续进一步处理，从而避免因处理无关信息而降低故障诊断与故障
处理的效率，进一步提高本公开实施例提供的故障诊断与故障处理效率。
101.当然，在上述的第二种情况下，本公开提供的故障处理方法虽然不对该不处于本公开预先设定的诊断策略与处理策略中的故障进行如上的自动化故障诊断与自动化故障处理，但是，本公开实施例在运维端的运维开源平台配置有日志系统，该日志系统不仅会对当前进行自动化故障诊断与自动化故障处理过程中的故障处理信息进行记录，同时也会记录未进行故障诊断与故障处理的故障信息，并将该故障信息通过例如短信、微信、qq等通讯软件发送至运维人员和/或与开发人员，以供运维人员和/或开发人员进行进一步的分析处理，以进一步提高本公开实施例提供的故障处理方法针对故障处理的全面性。
102.本公开实施例提供的故障处理方法是基于预设的正则匹配模型与得到的诊断监控参数之间是否匹配来确定是否需要进一步调用运维进程库中的运维进程，也就是确定是否进行故障处理。正则匹配模型可以根据实际情况进行设定，灵活性较高，同时，正则匹配模型一旦设定好后，其对诊断监控参数的匹配度判断方法简单，高效且可靠，可以进一步提高本公开实施例提供的故障处理方法的效率与可靠性。
103.在本公开一个可选实施例中，步骤203运维端获取在进行故障诊断时的诊断监控参数，包括如下步骤a：
104.步骤a、运维端在进行故障诊断时，从待处理对象对应的监控系统、性能管理系统或日志系统中的至少一个系统中获取诊断监控参数。
105.运维端搭载有运维开源平台，例如kubernetes等，在该运维开源平台从开发端调用开发端的运维开源文件对待处理对象进行故障诊断。同时，在运维端还配置有例如监控系统、性能管理系统以及日志系统等对故障诊断过程进行实时监控。因此，可以通过监控系统、性能管理系统或日志系统中的任一个或者多个系统中获取得到针对待处理对象的诊断监控参数。本公开实施例通过监控系统、性能管理系统或日志系统中的至少一个系统中获取诊断监控参数，诊断监控参数来源可靠，且维度更广，可以提高得到的诊断监控参数的可靠性，进一步提高对于故障类型确定的可靠性，以及本公开实施例对故障处理的可靠性。
106.在本公开一个可选实施例中，诊断监控参数至少包括：故障标识、故障诊断节点标识、诊断凭证标识中的任一种。
107.其中，故障标识是指故障类型，具体内容等；故障诊断节点标识用于表征在对待处理对象进行故障诊断时，待处理对象出现故障的具体节点位置；诊断凭证标识是指在诊断过程中对待处理对象进行诊断前后的标识信息，用于表征对该节点未进行诊断或已经进行了诊断。本公开实施例的诊断监控参数可以为故障标识、故障诊断节点标识与诊断凭证标识中任一种参数或任意组合，通过故障标识、故障诊断节点标识与诊断凭证标识可以最大程度上提高诊断监控参数的针对性，以提高本公开实施提供的故障处理方法的针对性与处理效率。同时，当诊断监控参数包括故障标识、故障诊断节点标识和诊断凭证标识时可以最大程度上提高诊断监控参数的全面性，进一步提高故障诊断与故障处理的可靠性。
108.请参见图5，在本公开一个可选实施例中，步骤203运维端基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流，包括如下步骤501
‑
步骤502：
109.步骤501、运维端获取针对目标故障类型的目标运维进程序列表。
110.其中，目标运维进程序列表中包括用于处理目标故障类型的故障的，按照预设序
列排列的多个运维进程。在进行故障诊断与故障处理之前，运维人员首先根据历史经验确定待处理对象容易出现的多个类型的故障，并确定在实际处理过程中针对每种类型故障处理时所需要的若干个运维进程，以及该若干个运维进程的执行顺序，并进一步构建针对每种类型故障的运维进程序列表。需要指出的是，每种类型的故障对应一个运维进程序列表，每个运维进程序列表中包括用于处理该故障类型的故障的，按照预设序列排列的多个运维进程。运维人员在得到的多个运维进程序列表后将其存储于运维端，例如开源平台中，以便后续进行查找。运维端在基于确定得到的目标故障类型，然后从预先存储的多个运维进程表中进行查询，即可得到与该目标故障类型对应的目标运维进程序列表，目标运维进程的获取方式简单高效，且获取得到的运维进程无需进行复杂的中间转换、计算等过程，结果更为可靠。
111.步骤502、运维端基于目标运维进程序列表对调用的运维进程库中的至少两个运维进程进行编排，以生成目标有向无环图。
112.其中，目标有向无环图用于指示目标运维工作流。运维端在得到目标运维进程序列表中的至少两个运维进程后，通过对其进行编排形成有向无环图。多个运维进程作为有向无环图的不同节点输入，在对不同类型的故障进行处理时，可以按照设定好的处理路径调用位于不同节点的运维进程，从而去中心化地并行执行相应的多个运维进程，且每个目标运维工作流，以及各目标运维工作流中的多个运维进程都是相互独立，互不影响，从而使得在进行故障处理过程中可以同时对不同类型的故障进行处理，避免了传统技术中存在的每次只能单独进行一种类型的故障的处理，大大提高了故障处理的效率。
113.本公开实施例提供的故障处理方法通过先获取针对目标故障类型的目标运维进程序列表，可以大大提高故障处理的效率；同时，基于目标运维进程序列表对调用的运维进程库中的至少两个运维进程进行编排，以生成用于指示目标运维工作流的目标有向无环图。有向无环图是去中心化的，可以指示不同的节点调用不同的运维进程，因此，本公开实施例提供的故障处理方法可以同时处理多个类型的故障，大大提高对于故障处理的效率。
114.请参见图6，如图6为一个示例性的，包含有目标运维工作流1、目标运维工作流2和目标运维工作流3的一个有向无环图。其中，目标运维工作流1包括的运维进程有：运维进程1、运维进程2、运维进程4和运维进程5；目标运维工作流2包括的运维进程有：运维进程1、运维进程3、运维进程5和运维进程6；目标运维工作流3包括的运维进程有：运维进程1、运维进程2、运维进程3、运维进程5和运维进程6；也就是说，在形成的所有的目标运维工作流中均会涉及到运维进程1和运维进程5，但是各目标运维工作流相互独立，均可各自独立的调用运维进程1与运维继承5，且相互无干扰，独立工作。
115.同时，如图6中的目标运维工作流3，运维进程1、运维进程2与运维进程3之间为并行关系，并非线性关系，运维进程1、运维进程2与运维进程3均可以相互独立工作，互不影响，即本公开实施例即使在同一个目标运维工作流中也可以相互独立的调用各运维进程，而不相互干扰，形成一个高效且可靠的目标运维工作流，以独立的处理各类型的故障，故障处理不仅效率高，且可靠性更高。
116.请参见图7，在本公开一个可选实施例中，本公开实施例提供的故障处理方法还包括如下步骤701
‑
步骤702：
117.步骤701、运维端获取基于目标运维工作流对待处理对象进行故障处理期间内各
个时刻的故障处理信息。
118.故障处理的周期一般较长，工作人员很难在现场进行全程监控，因此，在进行故障处理期间通过监控程序等对类似于故障处理节点、各节点处理结果等处理过程中产生的参数等故障处理信息进行实时记录。
119.步骤702、运维端基于各故障处理信息生成故障处理日志。
120.通过步骤701获取得到处理期间的各故障处理信息，然后通过类似于生成器之类的工具生成针对本次故障处理的故障处理日志，以便工作人员后续可以进一步溯源，分析等。需要指出的是，本公开实施例所提出的先获取故障处理信息然后再生成故障处理日志，并非指在全程的故障处理信息均生成完成后再统一生成故障处理信息，而是指实时生产，也就是在生成某一时刻的故障信息后，将该时刻的故障处理信息添加至当前的故障处理日志，以对故障处理日志进行实时更新。
121.本公开实施例提供的故障处理方法对故障处理期间各时刻的故障处理新消息进行实时获取，并基于得到的各故障处理信息生成故障处理日志，以方便记录，以及为后续工作人员进行进一步分析提供数据支持。
122.本公开一个实施例提供了一种故障处理系统，包括：
123.管理组件，用于获取运维开源文件，以及运维开源文件对应的地址标识；基于地址标识调用运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型；基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流；其中，运维进程库中包含多个运维进程；
124.例如，当该故障处理系统中的开源平台为kubernetes，则对应的管理组件为master组件，master组件用于开发人员与运维人员定义配置，当该配置合法时，将被master组件所接收，并控制其他组件进行执行。master组件基于确定的故障类型，然后计算对应的处理路径，并确定所需要的运维进程，也就是确定对应的目标运维工作流，最后通过该目标运维工作流控制其他执行组件执行对应的功能。其中，master组件可以包括如下模块：
125.图构建器graphbuilder，用于根据目标工作流中定义的各运维进程生成有向无环图并计算出各故障类型对应的处理路径，以方便后续高效且相互独立的进行故障处理。
126.报警管理器alertmanager，用于接收外接事件报警器，例如prometheus等的报警并根据触发器trigger中定义的报警模型创建故障处理日志等。
127.事件管理器eventer，用于接收开源平台例如kubernetes event并根据触发器trigger中定义的模型创建故障处理日志等。
128.报警管理器elasticalerting，用于接收报警信息并根据触发器trigger中定义的模型创建故障处理日志等。
129.执行组件，用于基于目标运维工作流对待处理对象进行故障处理中的故障进行处理。
130.当该故障处理系统中的开源平台为kubernetes，则对应的执行组件可以为agent组件。agent组件负责实际故障诊断与故障处理的执行并内置多个常用诊断操作。当目标工作流创建后，agent组件会根据目标工作流中对应的至少两个运维进程执行诊断工作流，诊断工作流是包括多个诊断操作的集合。
131.其中，agent组件可以包括executor模块，用于负责执行目标运维工作流。目标运
维工作流中包含表征诊断工作流的有向无环图和所有的诊断路径。诊断路径表示诊断过程中的排查路径，通过执行某个诊断路径中每个运维进程可以对问题进行排查处理。如果某个诊断路径的所有诊断操作均执行成功，则该次诊断被标记为成功。如果所有诊断路径均执行失败，则该次诊断被标记为失败。
132.本公开实施例提供的故障处理系统，将故障处理过程分为管理组件与执行组件两个模块，开发人员与运维人员可以分别通过不同的模块执行不同的操作，角色划分清晰，可大大提高故障诊断与处理的效率。
133.请参见图8，为了实现上述业务处理方法，本公开的一个实施例中提供一种故障处理装置800。图8示出了故障处理装置800的示意性架构图。
134.其中，该故障处理装置800包括获取模块810、确定模块820、生成模块830和处理模块840。
135.该获取模块810，用于获取运维开源文件，以及运维开源文件对应的地址标识；
136.该确定模块820，用于基于地址标识调用运维开源文件对待处理对象进行故障诊断，以确定待处理对象的故障类型；
137.该生成模块830，用于基于故障类型调用运维进程库中的至少两个运维进程，并对至少两个运维进程进行编排，以生成目标运维工作流；其中，运维进程库中包含多个运维进程；
138.该处理模块840，用于基于目标运维工作流对待处理对象进行故障处理。
139.在一个可选的实施例中，该处理模块840还用于，获取在进行故障诊断时的诊断监控参数；确定诊断监控参数是否超出预设阈值范围；若诊断监控参数超出预设阈值范围，则基于故障类型调用运维进程库中的至少两个运维进程。
140.在一个可选的实施例中，该处理模块840还用于，确定诊断监控参数与预设的正则匹配模型是否匹配；若诊断监控参数与预设的正则匹配模型相匹配，则基于故障类型调用运维进程库中的至少两个运维进程。
141.在一个可选的实施例中，该处理模块840具体用于，在进行故障诊断时，从待处理对象对应的监控系统、性能管理系统或日志系统中的至少两个系统中获取诊断监控参数。
142.在一个可选的实施例中，诊断监控参数至少包括：故障标识、故障诊断节点标识、诊断凭证标识中的任一种。
143.在一个可选的实施例中，该生成模块830具体用于，获取针对目标故障类型的目标运维进程序列表；其中，目标运维进程序列表中包括用于处理目标故障类型的故障的，按照预设序列排列的多个运维进程；基于目标运维进程序列表对调用的运维进程库中的至少两个运维进程进行编排，以生成目标有向无环图；其中，目标有向无环图用于指示目标运维工作流。
144.在一个可选的实施例中，该处理模块840还用于，获取基于目标运维工作流对待处理对象进行故障处理期间内各个时刻的故障处理信息；基于各故障处理信息生成故障处理日志。
145.本公开的示例性实施方式还提供了一种计算机可读存储介质，可以实现为一种程序产品的形式，其包括程序代码，当程序产品在电子设备上运行时，程序代码用于使电子设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。
在一种实施方式中，该程序产品可以实现为便携式紧凑盘只读存储器(cd
‑
rom)并包括程序代码，并可以在电子设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
146.程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
147.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
148.可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
149.可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
150.在本公开中一个实施例中，计算机可读存储介质中存储的程序代码被执行时可以实现如上任一个步骤。
151.请参见图9，本公开的示例性实施方式还提供了一种电子设备900，可以是信息平台的后台服务器。下面参考图9对该电子设备900进行说明。应当理解，图9显示的电子设备900仅仅是一个示例，不应对本公开实施方式的功能和使用范围带来任何限制。
152.如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：至少一个处理单元1010、至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030。
153.其中，存储单元存储有程序代码，程序代码可以被处理单元1010执行，使得处理单元1010执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元1010可以执行如图2所示的方法步骤等。
154.存储单元1020可以包括易失性存储单元，例如随机存取存储单元(ram)1021和/或高速缓存存储单元1022，还可以进一步包括只读存储单元(rom)1023。
155.存储单元1020还可以包括具有一组(至少一个)程序模块1025的程序/实用工具
1024，这样的程序模块1025包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
156.总线1030可以包括数据总线、地址总线和控制总线。
157.电子设备900也可以与一个或多个外部设备1100(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过输入/输出(i/o)接口1040进行。电子设备900还可以通过网络适配器1050与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1050通过总线1030与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
158.在本公开中一个实施例中，电子设备中存储的程序代码被执行时可以实现如上任一个步骤。
159.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
160.所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
161.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限定。