系统应急处理的方法、装置、电子设备及存储介质与流程

1.本技术涉及数据处理技术领域，尤其涉及一种系统应急处理的方法、装置、电子设备及存储介质。


背景技术：

2.传统的应急处置需要运维人员依靠经验或者应急预案通过手工的方式输入处理命令，以便快速恢复应用系统的业务处理能力。前一种方式对运维人员的个人能力和经验依赖较强，后一种方式则高度依赖预案的质量并且响应速度较慢，无论哪一种手工输入处理命令都有可能因为操作失误而带来附加的影响。


技术实现要素：

3.有鉴于此，本技术提供了一种系统应急处理的方法、装置、电子设备及存储介质，以解决现有技术中在进行系统应急处理时人为处理效率低、易出错，处理质量低的问题。
4.为实现上述目的，本技术提供如下技术方案：
5.本技术第一方面公开了一种系统应急处理的方法，包括：
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.图1为为本技术实施例公开的一种系统应急处理方法的流程图；
57.图2为本技术另一实施例公开的步骤s103的一种实施方式的流程图；
58.图3为本技术另一实施例公开的步骤s104的一种实施方式的流程图；
59.图4为本技术另一实施例公开的一种系统应急处理预警装置的示意图；
60.图5为本技术另一实施例公开的一种电子设备的示意图。
具体实施方式
61.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
62.在本技术中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没
有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
63.并且，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
64.本技术实施例提供了一种系统应急处理的方法，具体如图1所示，具体包括：
65.s101、接收异常告警信息。
66.需要说明的是，当应用监控、日志监控、资源监控、进程监控等监控数据超过系统设定的阈值时，会产生主要告警或者次要告警的异常告警信息，告警接收器接收异常告警信息。其中，主要告警和次要告警可以通过阈值或者对业务的影响程度来区分：比如针对cpu高的问题，阈值设定80％-95％之间发布的是次要告警，这个时候预示着系统比较繁忙，但是这种繁忙可能是正常的，比如正好是业务高峰期，或者有批处理运行，也可能是异常的，比如异常的批量调用导致系统无法负载；阈值设定95％以上为主要告警，这个时候系统明显已经过载了，必须要介入处理了，确认是否对应用产生了影响，是否需要执行重启等应急处理操作。再比如对进程的监控，应用进程掉线了，显然是无法提供服务了，这个就属于主要告警。
67.可选的，在本技术的另一实施例中，执行步骤s101之后，还可以包括：
68.对异常告警信息进行关键字提取。
69.需要说明的是，在接收到异常告警信息之后，则对异常告警信息进行关键字提取，识别出告警系统、告警时间、告警类型、告警字段等信息。
70.s102、基于异常告警信息进行异常指标分析，得到问题定位信息，其中，问题定位信息包括问题类型、问题编码、问题源识别码、系统编码。
71.需要说明的是，数据采集器根据异常告警信息收集告警系统的健康检查报告、应用监控数据、技术监控数据、告警历史数据，提供给智能定位组件进行异常指标分析，得到问题定位信息，其中，问题定位信息包括问题类型、问题编码、问题源识别码、系统编码。其中问题类型说明定位到的问题归属的大类，如基础设施故障、应用故障、中间件故障、数据库故障等；问题编码用于说明问题的具体原因，以基础设施故障为例又可分为nas存储故障、接入交换机故障、核心路由器故障等不同的设备设施；问题源识别码与问题编码共同确定某一故障点，如识别到应用中的某一交易码交易量突增导致了cpu使用率高，则问题源识别码为该交易码；系统编码用于记录问题系统或问题影响的系统的范围，主要供应急处理影响性分析和实施效果监测。
72.可选的，在本技术的另一实施例中，步骤s102的一种实施方式，可以包括：
73.基于异常告警信息，确定出异常组件。
74.对异常组件进行异常指标分析，得到问题定位信息。
75.需要说明的是，基于异常告警信息，确定出异常组件，具体的，当当异常告警信息指向当前系统的组件时，智能定位组件进行当前系统的异常指标分析；当异常告警信息指向关联组件时，智能定位组件调度数据采集器获取应用架构视图数据，识别全链路交易线和链路各节点系统的指标情况，从而分析确定异常引发的实际组件；当以上检查指标均无异常时，分析本次告警时间前后t时间范围内的其他告警数据，调度数据采集器获取技术架
构视图数据，识别多个告警系统是否存在共用的基础设施或公共基础组件，并通过设备健康检查等手段提取公共设备或组件的健康情况，从而确定引发问题的基础设施或组件。确定出异常组件之后，则对异常组件进行异常指标分析，得到问题定位信息。
76.s103、基于问题定位信息，从预先构建的应急解决方案库中筛选出应急方案。
77.需要说明的是，基于问题定位信息，从预先构建的应急解决方案库中筛选出应急方案。其中，该应急解决方案库为根据历史应急解决方案数据构建得到，一个问题编码可对应多件应急解决方案。
78.可选的，在本技术的另一实施例中，步骤s103的一种实施方式，如图2所示，可以包括：
79.s201、基于问题编码，从应急解决方案库中筛选出问题编码对应的所有应急方案。
80.需要说明的是，基于问题定位信息中的问题编码，从应急解决方案库中筛选出问题编码对应的所有应急方案。
81.s202、针对每一个应急方案，提取应急方案的影响因子。
82.需要说明的是，针对每一个应急方案，提取应急方案的影响因子，其中，影响因子分为条件因子和权重因子：
83.1、条件因子是方案依赖的必要条件，如系统是否具有系统级流控，当衡量系统级流控方案时，该因子就是条件因子，即如果条件不满足，则无法选择该方案；
84.2、当条件因子均满足的情况下，权重因子用来衡量方案的优先级。
85.s203、针对每一个应急方案，基于影响因子，计算出应急方案的优先级评分。
86.需要说明的是，首先获取每个方案的条件因子集合{c1,c2,
……
,cm}，再获取每个方案的权重因子集合{w1,w2,
……
,wn}，每个权重因子有一组匹配不同分类数据的基准值b，比如按系统级别a类系统权重为5，b类为3，c类为1，则系统级别的权重因子基准为再根据系统的实际情况s，如a类系统值为|1 0 0|，计算行列式的乘积得到系统级别的权重系数，将所有权重因子计算得出的权重系数相加得到总权重值，整体的计算公式如下：
[0087][0088]
其中，i是方案编号，m是该方案的条件因子个数，n是该方案的权重因子个数，p是某一权重因子的分类个数，vi是方案i的优先值，cj是当前系统条件因子j的取值，wk是当前系统权重因子k的权重值，swk是当前系统wk权重因子的取值，bwk是权重因子wk的基准值，sw
kp
是当前系统wk权重因子在分类p上的值，bw
kp
是权重因子wk在分类p上的基准值。
[0089]
s204、筛选优先级评分最高的应急方案作为可执行的应急方案。
[0090]
需要说明的是，计算出应急方案的优先级评分后，根据得分高低排定方案实施的优先级，并筛选优先级评分最高的应急方案作为可执行的应急方案。
[0091]
s104、按照应急方案执行应急处理，并得到处理结果。
[0092]
需要说明的是，按照应急方案的具体内容执行应急处理，并对处理过程进行监控，得到处理结果，在执行应急处理时，为了避免出错，可执行备份操作，包括当前应急处置方案通用的备份脚本和系统之前设定的专用备份脚本，对配置文件、日志记录、处理中的交易报文和数据等进行备份，以便后续排查分析问题、操作回退或者账务数据自动恢复处理等场景使用。
[0093]
可选的，在本技术的另一实施例中，步骤s104的一种实施方式，如图3所示，可以包括：
[0094]
s301、获取应急方案的方案触发时间。
[0095]
需要说明的是，在确定应急处理方案之后，首先获取应急方案的方案触发时间。
[0096]
s302、当到达方案触发时间时，则执行应急方案。
[0097]
s303、按照预设的时间周期获取执行应急方案的系统的指标参数，并基于指标参数判断系统是否恢复正常。
[0098]
需要说明的是，在执行应急方案的过程中，按照预设的时间周期获取执行应急方案的系统的指标参数，时间周期可以根据实际情况进行设定，例如5分钟。并根据指标参数是否恢复到健康范围内，判断系统是否恢复正常。
[0099]
s304、若判断出系统恢复正常或者执行应急方案的时长达到预设的阈值，则停止执行应急方案，并生成处理结果。
[0100]
需要说明的是，当判断出系统恢复正常，则停止执行应急方案，并生成问题已解决的处理结果。同时，每种应急方案都有一个建议的恢复监测时长，不可能无限制的等待下去，且系统的恢复时间指标很大程度上决定了该在何时触发一个影响更大但可能更有效的方案。因此，当判断出执行应急方案的时长达到预设的阈值时，则停止执行应急方案，并生成问题未解决的处理结果。比如对系统采取流控措施在大部分应用场景下比应用重启的影响范围更小，但是如果实施了流控设置后到达该方案的恢复监测时长，系统各项指标尚未得到明显的恢复，或者考虑到应用重启需要消耗的时间t等已知的非功能测试结果，应该停止执行当前方案，以便后续在系统恢复时间指标t-t的时间前执行应用重启的方案。
[0101]
s105、若处理结果为问题已解决，则结束应急处理流程。
[0102]
需要说明的是，如果处理结果为问题已解决，说明系统已恢复正常，则结束应急处理流程。
[0103]
s106、若处理结果为问题未解决，则返回执行基于问题定位信息，从预先构建的应急解决方案库中筛选出问题定位信息对应的应急方案，直至得到处理结果为问题已解决为止。
[0104]
需要说明的是，如果处理结果为问题未解决，则返回执行基于问题定位信息，从预先构建的应急解决方案库中筛选出问题定位信息对应的应急方案，即步骤s103，重新选择出另一应急方案进行应急处理，直至得到处理结果为问题已解决为止。
[0105]
本技术实施例提供的一种系统应急处理的方法中，首先接收异常告警信息。基于异常告警信息进行异常指标分析，得到问题定位信息，其中，问题定位信息包括问题类型、问题编码、问题源识别码、系统编码。然后基于问题定位信息，从预先构建的应急解决方案库中筛选出应急方案。按照应急方案执行应急处理，并得到处理结果。若处理结果为问题已解决，则结束应急处理流程。若处理结果为问题未解决，则返回执行基于问题定位信息，从
预先构建的应急解决方案库中筛选出问题定位信息对应的应急方案，直至得到处理结果为问题已解决为止。由此可知，利用本技术的方法，通过自动根据异常告警信息分析得到问题定位信息，根据识别的问题定位信息采取不同的自动应急处理方案，提升应急处理效率，提高应急处理质量。解决了现有技术中在进行系统应急处理时人为处理效率低、易出错，处理质量低的问题。
[0106]
可选的，在本技术的另一实施例中，上述系统应急处理的方法，还可以包括：
[0107]
对应急处理流程进行后处理和后评估。
[0108]
需要说明的是，应急处理完成后还有一部分收尾工作，包括对系统应急处理过程中导致的异常交易的处理，以及处理结束后与处理方案相对应的配置恢复等后续工作。例如针对账务类交易，为保证一致性，需要根据过程记录的疑似问题交易，通过交易查询、交易冲正等方式实现自动对账和错账处理。
[0109]
此外，还要对本次自动化应急的处理过程进行评估，以便对异常系统和自动化应急处理系统本身进行改进。对异常系统来说，还需要进一步分析引发本次问题的根本原因，是否可以通过某些技术手段进行解决，针对应急处理过程中的一些步骤和处理脚本是否需要进行调整。对自动化应急处理系统来说，这一次处理的效果、处理过程中各时段的时长等信息，都是完善应急方案库和各项影响因子的输入。
[0110]
在本技术的另一实施例还公开了一种系统应急处理的装置，如图4所示，具体包括：
[0111]
接收单元401，用于接收异常告警信息。
[0112]
分析单元402，用于基于异常告警信息进行异常指标分析，得到问题定位信息，其中，问题定位信息包括问题类型、问题编码、问题源识别码、系统编码。
[0113]
筛选单元403，用于基于问题定位信息，从预先构建的应急解决方案库中筛选出应急方案。
[0114]
处理单元404，用于按照应急方案执行应急处理，并得到处理结果。
[0115]
结束单元405，用于若处理结果为问题已解决，则结束应急处理流程。
[0116]
返回执行单元406，用于若处理结果为问题未解决，则返回执行基于问题定位信息，从预先构建的应急解决方案库中筛选出问题定位信息对应的应急方案，直至得到处理结果为问题已解决为止。
[0117]
本实施例中，接收单元401、分析单元402、筛选单元403、处理单元404、结束单元405、返回执行单元406的具体执行过程，可参见对应上述图1方法实施例内容，此处不再赘述。
[0118]
本技术实施例提供的一种系统应急处理的装置中，首先接收单元401接收异常告警信息。分析单元402基于异常告警信息进行异常指标分析，得到问题定位信息，其中，问题定位信息包括问题类型、问题编码、问题源识别码、系统编码。然后筛选单元403基于问题定位信息，从预先构建的应急解决方案库中筛选出应急方案。处理单元404按照应急方案执行应急处理，并得到处理结果。若处理结果为问题已解决，结束单元405则结束应急处理流程。若处理结果为问题未解决，返回执行单元406则返回执行基于问题定位信息，从预先构建的应急解决方案库中筛选出问题定位信息对应的应急方案，直至得到处理结果为问题已解决为止。由此可知，利用本技术的方法，通过自动根据异常告警信息分析得到问题定位信息，
根据识别的问题定位信息采取不同的自动应急处理方案，提升应急处理效率，提高应急处理质量。解决了现有技术中在进行系统应急处理时人为处理效率低、易出错，处理质量低的问题。
[0119]
可选的，在本技术的另一实施例中，上述系统应急处理的装置，还可以包括：
[0120]
提取单元，用于对异常告警信息进行关键字提取。
[0121]
本实施例中，提取单元的具体执行过程，可参见对应上述方法实施例内容，此处不再赘述。
[0122]
可选的，在本技术的另一实施例中，上述分析单元402的一种实施方式，可以包括：
[0123]
确定子单元，用于基于异常告警信息，确定出异常组件。
[0124]
分析子单元，用于对异常组件进行异常指标分析，得到问题定位信息。
[0125]
本实施例中，确定子单元、分析子单元的具体执行过程，可参见对应上述方法实施例内容，此处不再赘述。
[0126]
可选的，在本技术的另一实施例中，上述筛选单元403的一种实施方式，可以包括：
[0127]
第一筛选子单元，用于基于问题编码，从应急解决方案库中筛选出问题编码对应的所有应急方案。
[0128]
提取子单元，用于针对每一个应急方案，提取应急方案的影响因子。
[0129]
计算子单元，用于针对每一个应急方案，基于影响因子，计算出应急方案的优先级评分。
[0130]
第二筛选子单元，用于筛选优先级评分最高的应急方案作为可执行的应急方案。
[0131]
本实施例中，第一筛选子单元、提取子单元、计算子单元、第二筛选子单元的具体执行过程，可参见对应图2方法实施例内容，此处不再赘述。
[0132]
可选的，在本技术的另一实施例中，上述处理单元404的一种实施方式，可以包括：
[0133]
获取子单元，用于获取应急方案的方案触发时间。
[0134]
执行子单元，用于当到达方案触发时间时，则执行应急方案。
[0135]
判断子单元，用于按照预设的时间周期获取执行应急方案的系统的指标参数，并基于指标参数判断系统是否恢复正常。
[0136]
停止子单元，用于若判断出系统恢复正常或者执行应急方案的时长达到预设的阈值，则停止执行应急方案，并生成处理结果。
[0137]
本实施例中，获取子单元、执行子单元、判断子单元、停止子单元的具体执行过程，可参见对应图3方法实施例内容，此处不再赘述。
[0138]
本技术另一实施例还提供了一种电子设备，如图5所示，具体包括：
[0139]
一个或多个处理器501。
[0140]
存储装置502，其上存储有一个或多个程序。
[0141]
当一个或多个程序被一个或多个处理器501执行时，使得一个或多个处理器501实现如上述实施例中任意一项方法。
[0142]
本技术另一实施例还提供了计算机存储介质，其上存储有计算机程序，其中，计算机程序被处理器执行时实现如上述实施例中任意一项方法。
[0143]
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或
系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
[0144]
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0145]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。