监控报警应急方法、系统、装置、设备和介质与流程

1.本公开涉及人工智能技术领域，更具体地，涉及一种监控报警应急方法、装置、设备、介质和程序产品。


背景技术：

2.数据中心通常采用值班制度，即由值班人员关注监控报警，如遇重大生产故障，联系对应运维人员启动应急处理。而在非工作时间，运维人员经常无法第一时间在一线响应，此时就需要值班人员首先针对报警现象进行原因判断，然后根据事先准备好的应急预案进行手工应急。
3.随着业务的发展，数据中心所运行应用的整体架构越来越复杂、应用功能越来越细化，可能具有不同的报警类型，且每个报警类型还可能由于不同的报警原因导致，对应值班人员难以掌握所有应用的应急场景。并且需要手工实施应急预案对故障进行处置，而各种应急工具可能部署在不同的平台系统中，且使用方法各不相同，值班人员难以全部熟练掌握。因此，如何减少人工应急步骤，以达到快速应急和提高业务连续性的目的是当前亟待解决的问题。


技术实现要素：

4.鉴于上述问题，本公开提供了一种能够自动排查及自动实施对应应急预案的监控报警应急方法、系统、装置、设备、介质和程序产品。
5.本公开实施例的一个方面，提供了一种监控报警应急方法，包括：确定监控报警信息中的报警应用和报警类型；根据所述报警类型匹配预先配置的应急决策树模型，所述应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，所述n条应急决策规则基于所述报警类型的n个报警原因预先配置，n大于或等于1；按照所述应急决策树模型的决策路径，将所述监控报警信息与所述n条应急决策规则进行匹配，其中，所述n条应急决策规则包括与所述n个报警原因一一对应的应急预案信息；根据匹配到的应急决策规则，调用对应的应急预案对所述报警应用进行应急处理。
6.根据本公开的实施例，在所述确定监控报警信息中的报警应用和报警类型之后，还包括：确定所述报警应用涉及的m个业务场景，m大于或等于1；确定所述m个业务场景中每个业务场景涉及所述报警应用的交易链路，其中，所述交易链路包括所述报警应用在内的至少两个应用，所述报警应用与所述交易链路中其余至少一个应用具有数据交互；查询每个所述交易链路中其余应用的监控报警信息和/或应用变更信息。
7.根据本公开的实施例，在确定所述报警应用涉及的m个业务场景之前，所述还包括：查询所述报警应用的应用变更信息；若查询到所述报警应用的应用变更信息，则将所述报警应用回退到变更前状态；若未查询到所述报警应用的应用变更信息，则继续执行所述确定所述报警应用涉及的m个业务场景。
8.根据本公开的实施例，在确定所述报警应用涉及的m个业务场景之前，所述方法还
包括：确定所述每个业务场景涉及的s个应用，s大于或等于1；根据所述s个应用在所属业务场景中的数据交互确定至少一个交易链路；和/或，以所述每个业务场景为维度，配置所述s个应用中每个应用关联的至少一个应急预案。
9.根据本公开的实施例，所述方法还包括预先配置应急决策规则，具体包括：根据所述每个应用的历史监控报警信息，确定该应用的q种报警类型，和其中每种报警类型对应的n个报警原因，所述q种报警类型包括所述监控报警信息中的报警类型，q大于或等于1；针对所述每种报警类型对应的n个报警原因配置n条应急决策规则。
10.根据本公开的实施例，所述方法还包括预先配置应急决策树模型，具体包括：针对所述每种报警类型，根据该报警类型下每个报警原因的特征构造k个条件节点，其中每个条件节点包括用于匹配所述监控报警信息的特征判断条件，k大于或等于1；将该报警类型构造为根节点，及该报警类型下的n条应急决策规则构造为n个叶节点，其中，所述决策路径包括从所述根节点经由所述k个条件节点至所述n个叶节点的任一条路径；根据所述根节点、所述k个条件节点和所述n个叶节点，得到该种报警类型相匹配的应急决策树模型。
11.根据本公开的实施例，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括：将所述监控报警信息与集群或园区报警规则进行匹配，所述集群或园区报警规则包括检查所述报警应用所属的服务器集群或服务器园区内的监控报警信息；和/或将所述监控报警信息与性能容量报警规则进行匹配，所述性能容量报警规则包括检查性能容量报警信息。
12.根据本公开的实施例，所述调用对应的应急预案对所述报警应用进行应急处理包括：若所述报警应用当前所属地内监控报警数量在预设阈值以上，隔离所述报警应用的当前所属地，和/或将所述报警应用从当前所属地切换至其他所属地。
13.根据本公开的实施例，所述调用对应的应急预案对所述报警应用进行应急处理包括：若查询到所述性能容量报警信息，执行以下至少一个操作：扩大容量、查杀异常进程和重启所述报警应用所属服务器；若未查询到所述性能容量报警信息，熔断异常服务。
14.根据本公开的实施例，所述报警类型包括可用性报警类型，所述应急决策树模型包括可用性类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配还包括：将所述监控报警信息与持续报警规则进行匹配，所述持续报警规则包括检查所述报警应用在多个时间点的监控报警信息。
15.根据本公开的实施例，所述报警类型包括批量报警类型，所述应急决策树模型包括批量类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：批量作业中断决策路径，用于批量作业中断的报警原因；批量作业超时决策路径，用于批量作业超时的报警原因；以及批量时间异常决策路径，用于批量开始时间过晚，或批量结束时间过晚的报警原因。
16.根据本公开的实施例，所述报警类型包括交易报警类型，所述应急决策树模型包括交易类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：交易量下降决策路径，用于交易量下降的报警原因；交易成功率下降决策路径，用于交易成功率下降的报警原因；以及交易时间异常决策路径，用于交易时间缓慢或超时的报警原因。
17.本公开实施例的另一方面提供了一种监控报警应急系统，所述系统包括：监控系
统，用于获取监控报警信息；应急预案决策系统，用于与所述监控系统交互以确定报警应用和报警类型，并执行权利要求如上任一项所述的方法；应急系统，用于响应于所述应急预案决策系统调用应急预案的请求，执行所述应急预案以对所述报警应用进行应急处理。
18.本公开实施例的另一方面提供了一种监控报警应急装置，包括：确定模块，用于确定监控报警信息中的报警应用和报警类型；匹配模块，用于根据所述报警类型匹配预先配置的应急决策树模型，所述应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，所述n条应急决策规则基于所述报警类型的n个报警原因预先配置，n大于或等于1；决策模块，用于按照所述应急决策树模型的决策路径将所述监控报警信息与所述n条应急决策规则进行匹配，其中，所述n条应急决策规则包括与所述n个报警原因一一对应的应急预案信息；应急模块，用于根据匹配到的应急决策规则，调用对应的应急预案对所述报警应用进行应急处理。
19.所述监控报警应急装置包括分别用于执行如上所述任意一项所述的方法的各个步骤的模块。
20.本公开实施例的另一方面提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行如上所述的方法。
21.本公开实施例的另一方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行如上所述的方法。
22.本公开实施例的另一方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如上所述的方法。
23.上述一个或多个实施例具有如下有益效果：由于同一个报警类型可能对应不同的报警原因，因此根据报警类型匹配预先配置的应急决策树模型，自动将监控报警信息与n条应急决策规则进行匹配，并能够根据匹配结果自动调用对应的应急预案对所述报警应用及时进行应急处理，能够满足应用日益提高的生产安全稳定运行和业务连续性要求，避免了目前值班人员人工应急的方式存在的较大风险，如处置不及时或人为误操作会影响应急时效，扩大故障影响等问题。
附图说明
24.通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：
25.图1示意性示出了根据本公开实施例的监控报警应急系统的交互流程图；
26.图2示意性示出了根据本公开实施例的监控报警应急方法的流程图；
27.图3示意性示出了根据本公开实施例的全交易链路查询的流程图；
28.图4示意性示出了根据本公开实施例的业务场景和交易链路确定流程图；
29.图5示意性示出了根据本公开实施例的预先配置应急决策规则的流程图；
30.图6示意性示出了根据本公开实施例的预先配置应急决策树模型方法的流程图；
31.图7示意性示出了根据本公开实施例的基于交易类模型应急的流程图；
32.图8示意性示出了根据本公开实施例的基于可用性类模型应急的流程图；
33.图9示意性示出了根据本公开实施例的基于批量类模型应急的流程图；
34.图10示意性示出了根据本公开实施例的监控报警应急装置的结构框图；
35.图11示意性示出了根据本公开实施例的适于实现监控报警应急方法的电子设备的方框图。
具体实施方式
36.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
37.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
38.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
39.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
40.例如各大金融机构和大型银行数据中心都采用7*24小时值班制度，而值班人员的人工应急处置方式存在较大风险。例如值班人员难以掌握所有应用的应急场景，目前多是通过查阅录入在系统中或张贴在公共园地的应急预案对照处理，而这些应急预案由于需要运维人员日常手工维护，容易存在因应急预案未及时更新而对目前的故障场景不适用的情况。另外值班人员需要手工实施应急预案对故障进行处置，而各种应急工具可能部署在不同的平台系统中，且使用方法各不相同，值班人员难以全部熟练掌握。当应急预案存在需要客户化的内容而不能完全套用时，值班人员可能出现误操作继而导致引发次生灾难。
41.本公开的实施例提供了一种监控报警应急方法，由于同一个报警类型可能对应不同的报警原因，因此根据报警类型匹配预先配置的应急决策树模型，自动将监控报警信息与n条应急决策规则进行匹配，并能够根据匹配结果自动调用对应的应急预案对报警应用及时进行应急处理，能够满足应用日益提高的生产安全稳定运行和业务连续性要求，避免了目前值班人员人工应急的方式存在较大风险，处置不及时或人为误操作会影响应急时效，扩大故障影响等问题。
42.图1示意性示出了根据本公开实施例的监控报警应急系统的交互流程图。
43.如图1所示，监控报警应急系统100可以包括监控系统110、应急预案决策系统120和一键式应急系统130。在一些实施例中，还可以包括变更管理系统140。监控系统110用于获取监控报警信息。应急预案决策系统120用于与监控系统110交互以确定报警应用和报警类型，并执行本公开实施例的监控报警应急方法。一键式应急系统130用于响应于应急预案决策系统调用应急预案的请求，执行应急预案以对报警应用进行应急处理。
44.示例性地，监控系统110负责日常生产故障的报警展现，按不同的实现方式和作用可分为可用性监控、批量监控、交易监控等。监控系统首先对报警进行粗过滤，筛除应急时效较低、无需立即处理的报警，此处的过滤规则需要由前期录入的监控参数报警级别和运维人员提前指定的其他定制化规则共同构成。对紧急程度高的报警，监控系统实时将报警信息上送至应急预案决策系统。在一些实施例中，可以由监控系统从报警信息提炼出应用名称+报警类型+报警详情(包括服务器ip，服务、交易名，作业名等)并上送。
45.示例性地，应急预案决策系统120存储有各个报警类型对应的应急决策树模型，并能够与监控系统110、一键式应急系统130和变更管理系统140进行交互。应急预案决策系统120中可以记录各重点应急场景的应急预案、步骤。另外，该系统支持实时从变更管理系统140中按照应用+时间范围搜寻故障发生时点前是否实施过与发生故障应用相关的变更，并拉取该变更的回退方案作为应急回退措施。
46.示例性地，一键式应急系统130集合各种标准化快速应急场景的一键式执行流程，包括但不限于网络负载均衡园区级隔离恢复、应用云启停容器、配置中心动态变量调整、作业提交、应用版本自动化安装管理自定义策略等应急预案，以应用名+一键式流程编号为主键存储执行流程策略，根据应急预案决策系统输出的应急预案，一键式触发既定策略。对于应急流程中需要客户化的内容(非统一的参数值)，高亮显示并支持从报警系统发生报警时直接拉取台账信息，也支持由值班人员手工调整。
47.以上系统中的应急预案、一键式流程等在开发每次发布版本时随版本包一起交付生产，作为版本投产内容的一部分，经过运维人员审核后即可在系统中发布，避免每次由运维人员手工维护带来的更新不及时问题。
48.示例性地，变更管理系统140可以对应用进行变更(如版本更新或漏洞修复等)并记录，且配置对应的变更回退方案。支持响应应急预案决策系统120的变更查询和回退指令，提供变更信息和回退方案。
49.在一些实施例中，参照图1，在监控报警应急系统100运行过程中，监控系统110将获取到的监控报警信息(如包括报警应用和报警类型)上送至应急预案决策系统120(s01)，应急预案决策系统120根据监控系统110上送的监控报警信息确定报警应用和报警类型，可以反查监控系统110是否其他需要的报警信息(如集群、园区级报警、持续性报警或性能容量报警等)(s02)。应急预案决策系统120向变更管理系统140是否有报警应用预定时间段内的变更信息(s03)，若有，则拉取该变更的回退方案作为应急回退措施。若没有，则查询各交易链路的其他应用预定时间段内的变更信息，若查询到，则拉取变更应用的回退方案作为应急回退措施，若其他应用也没有变更，根据报警类型匹配至对应的应急决策树模型，最终触发应急流程(s04)。一键式应急系统130响应于应急预案决策系统120的调用请求(如应用名+一键式流程编号)，自动执行应急预案，并将执行结果返回至应急预案决策系统120(s04)，若未执行成功，则人工介入。若执行成功，应急预案决策系统120可以查询监控系统110是否还存在报警(s02)。
50.尤其说明的是，虽然图1和上述以先后顺序描述了s01-s05，但是本公开并不限定于依次执行s01-s05，例如s03和s04可以同时执行，也可以执行s01后，不执行s02，直接执行s03和/或s04。
51.根据本公开的实施例，整合了监控系统、应急预案系统、一键式应急系统和变更管
理系统的基础上，建立了智能化、自动化的监控报警应急系统，能够根据报警信息自动排查故障原因，定位出现故障的应用，一键式实施对应应急预案，减少值班人工步骤，以达到快速应急，提高业务连续性的目的。换言之，基于监控系统、应急预案决策系统、一键式应急系统和变更管理系统，可通过多个系统间联动交互，实现无人工或少人工干预的监控报警、定位故障、实施应急一体化流程，并可在应急完成后形成应急报告。
52.以下将基于图1描述的系统，通过图2～图9对本公开实施例的监控报警应急方法进行详细描述。
53.图2示意性示出了根据本公开实施例的监控报警应急方法的流程图。
54.如图2所示，该实施例的监控报警应急方法包括操作s210～操作s240。
55.在操作s210，确定监控报警信息中的报警应用和报警类型。
56.示例性地，可以直接接收监控系统110上送的报警应用和报警类型。也可以接收监控系统110上送的监控报警信息并解析得到报警应用和报警类型。
57.在操作s220，根据报警类型匹配预先配置的应急决策树模型，应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，n条应急决策规则基于报警类型的n个报警原因预先配置，n大于或等于1。
58.示例性地，应急决策树模型是一颗由多个节点组成的树型结构。通常，一棵决策树包含一个根结点(报警类型)、若干条件节点和若干叶节点(应急决策规则)，从根节点经由一个或多个条件节点进行特征判断，进而在每条决策路径的最末枝确定出叶节点，能够对所关心报警原因的应急处理作出最佳判断。
59.在操作s230，按照应急决策树模型的决策路径将监控报警信息与n条应急决策规则进行匹配，其中，所述n条应急决策规则包括与所述n个报警原因一一对应的应急预案信息。
60.示例性地，每一条决策路径包括从根节点开始经由若干个条件节点到某叶节点结束的一条节点序列。操作s230中匹配的过程包括沿着某条决策路径进行一次或多次条件判断，根据每次条件节点输出的判断结果决定分支的走向，并最终在最末枝确定匹配到的叶节点，也就确定了匹配到的应急决策规则，便于获取该规则中的应用预案信息。应用预案信息包括对应应急预案的内容、调用标识、预案描述、应急场景编号、应用名、报警原因、应急步骤序号和一键式流程编号等。
61.在操作s240，根据匹配到的应急决策规则，调用对应的应急预案对报警应用进行应急处理。应用预案包括针对报警原因预先部署的策略，可以响应于调用请求或触发条件自动执行策略中的操作。应急处理用于解决导致报警信息出现的原因，使报警应用恢复正常服务。或者用于防止报警应用因出现报警而导致损失扩大化，例如切换至别的应用提供服务。
62.示例性地，应急决策系统120可以向一键式应急系统130调用匹配到的应急决策规则所对应的应急预案，并由一键式应急系统130自动执行应急预案中的多个自动化步骤来对报警应用进行应急处理。
63.根据本公开的实施例，通过联动监控、应急预案决策和一键式应急系统，实现了自动化报警处理和应急实施，值班人员无需熟练掌握所有应用的监控报警判别办法和应急场景人工处置方法，降低了值班培训成本，减少运维人员的值班压力，提高了应急时效，规避
了人工操作带来的风险和次生灾难。
64.根据本公开的实施例，由于同一个报警类型可能对应不同的报警原因，因此根据报警类型匹配预先配置的应急决策树模型，自动将监控报警信息与n条应急决策规则进行匹配，并能够根据匹配结果自动调用对应的应急预案对报警应用及时进行应急处理，能够满足应用日益提高的生产安全稳定运行和业务连续性要求，避免了目前值班人员人工应急的方式存在的较大风险，如处置不及时或人为误操作会影响应急时效，扩大故障影响等问题。
65.在一些实施例中，可以查询报警应用的应用变更信息。查询变更信息的过程可以嵌入到应急决策树模型中，具体查询规则可以作为一个或多个条件节点进行参数判断。查询变更信息的过程也可以独立于操作s220～操作s240，在操作s220～操作s240之前、之后或同时执行。
66.示例性地，若查询到报警应用的应用变更信息，则将报警应用回退到变更前状态。若未查询到报警应用的应用变更信息，则继续执行确定报警应用涉及的m个业务场景，以下通过图3展开介绍。
67.根据本公开的实施例，考虑到报警应用发生故障可能是由预定时间段内的变更操作导致的，故在查询到应用变更信息时，将报警应用回退到变更前的状态，以便更快速的进行应急处理，若回退到变更前的状态不再发生故障，则还可以进一步发现变更漏洞。
68.图3示意性示出了根据本公开实施例的全交易链路查询的流程图。
69.在确定监控报警信息中的报警应用和报警类型之后，如图3所示，该实施例的全交易链路查询包括操作s310～操作s330。
70.在操作s310，确定报警应用涉及的m个业务场景，m大于或等于1。
71.示例性地，在m个业务场景中，报警应用作为其中的某个环节参与进来，以向客户提供完整的服务。
72.在操作s320，确定m个业务场景中每个业务场景涉及报警应用的交易链路，其中，交易链路包括报警应用在内的至少两个应用，报警应用与交易链路中其余至少一个应用具有数据交互。
73.其中，交易链路包括业务场景中的交易链条和路径，其中多个应用进行数据交互完成各个交易环节。每个业务场景可能涉及多个交易链路。
74.在操作s330，查询每个交易链路中其余应用的监控报警信息和/或应用变更信息。
75.示例性地，查询每个交易链路中其余每个应用的监控报警信息，若存在报警，则查询应用变更信息。若查询到应用变更信息，则将变更应用回退到变更前的状态。若查询到报警但是没有变更，则可以将查询到的每个交易链路中其余应用的监控报警信息与各自匹配的应急决策树模型进行自动应急处理。若不存在报警，继续查询下一个应用。
76.相关技术中，在交易场景复杂，交易链路长，且交易链路上存在多应用交互的情况下，一旦发生问题，非日常负责该应用运维的值班人员难以第一时间排查定位故障所在，继而也无法快速定位到正确的应急方案。
77.根据本公开的实施例，能够自动进行全交易链路的变更或监控报警信息的排查，对于报警应用涉及的一个或多个业务场景，以及每个业务场景中的一个或多个交易链路，可以快速定位到正确的应急方案。
78.图4示意性示出了根据本公开实施例的业务场景和交易链路确定流程图。
79.如图4所示，该实施例的业务场景和交易链路确定包括操作s410～操作s420。
80.在操作s410，确定每个业务场景涉及的s个应用，s大于或等于1。其中，可以预先梳理出多个业务场景。
81.在操作s420，根据s个应用在所属业务场景中的数据交互确定至少一个交易链路。和/或，以每个业务场景为维度，配置s个应用中每个应用关联的至少一个应急预案。
82.由于同一个报警现象可能对应不同的报警原因，因此对所有可能出现的原因逐一录入应急预案决策系统120形成决策树模型，并在叶节点关联对应的应急预案。
83.同时，由于目前普遍存在交易链路复杂，链路上应用交互多的情况，因此某一应用报警可能涉及交易链路上多应用同步联动应急，为方便梳理故障涉及的应用清单，定位故障原因，以重点业务场景为维度，将该场景下所有涉及的应用及其应急预案均进行录入，应急预案的录入需要按照步骤的执行顺序列出每一个应急步骤，每个应急步骤中须包括文字描述和关联的对应一键式流程。以应急场景编号+应用名+报警原因+应急步骤序号为主键存储。其中，多个应急步骤序号形成一个应急预案。其中，以业务场景为维度是指将该场景下的应用、交易链路和应急预案建立关联关系。
84.根据本公开的实施例，能够梳理数据中心中各个应用所涉及的业务场景和交易链路，从而在应急预案决策过程中实现自动化、快速化的故障定位和应急处理。
85.图5示意性示出了根据本公开实施例的预先配置应急决策规则的流程图。
86.如图5所示，该实施例的预先配置应急决策规则包括操作s510～操作s520。
87.在操作s510，根据每个应用的历史监控报警信息，确定该应用的q种报警类型，和其中每种报警类型对应的n个报警原因，q大于或等于1。
88.可以统计每个应用的历史数据中出现的监控报警信息(例如按照业务场景和交易链路统计)，并根据专家经验确定q种报警类型，以及各自的报警原因。
89.在操作s520，针对每种报警类型对应的n个报警原因配置n条应急决策规则。
90.每个报警原因可以配置一条应急决策规则，例如在自动化排除是否是该报警原因过程中，可以通过该报警原因各项特征进行多次判断来最终定位到叶节点。其中应急决策规则可以包括关于如何解决因为该报警原因出现的故障的应急预案信息(如应用预案的调用标识)，从而调用对应的应急预案。
91.根据本公开的实施例，确定业务场景、交易链路、报警类型和报警原因之间的联系，便于准确实现无人工或少人工干预的监控报警、定位故障、实施应急一体化流程。
92.图6示意性示出了根据本公开实施例的预先配置应急决策树模型方法的流程图。
93.如图6所示，该实施例预先配置应急决策树模型包括针对每种报警类型执行操作s610～操作s620。
94.在操作s610，根据该报警类型下每个报警原因的特征构造k个条件节点，其中每个条件节点包括用于匹配所述监控报警信息的特征判断条件，k大于或等于1。条件节点又叫决策树的内部节点或中间节点。每个报警原因的特征包括每当因该原因出现报警时所表征的一项或多项特征(如具体参数值、报警持续时间等)，条件节点的特征判断条件可以判断监控报警信息中是否包括符合上述特征的信息，从而实现匹配过程。
95.在操作s620，将该报警类型构造为根节点，及该报警类型下的n条应急决策规则构
造为n个叶节点，其中，所述决策路径包括从所述根节点经由所述k个条件节点至所述n个叶节点的任一条路径；
96.尤其说明的是，虽然图6以先后顺序描述了操作s610-操作s620，但是本公开并不限定于依次执行操作s610-操作s620，例如可以同时执行，也可以先执行操作s620。
97.在操作s630，根据根节点、k个条件节点和n个叶节点，得到该种报警类型相匹配的应急决策树模型。可以根据每个报警原因确定各个条件节点之间的先后关系从而形成决策路径，直至到达末尾的叶节点。
98.根据本公开的实施例，各种报警类型具有对应的应急决策树模型，当报警类型和报警原因存在一对多的映射关系时，通过引入决策树模型来实现应急处理的准确性和有效性。
99.在一些实施例中，将监控报警信息与n条应急决策规则进行匹配包括：将监控报警信息与集群或园区报警规则进行匹配，集群或园区报警规则包括检查报警应用所属的服务器集群或服务器园区内的监控报警信息。和/或将监控报警信息与性能容量报警规则进行匹配，性能容量报警规则包括检查性能容量报警信息。
100.示例性地，集群或园区报警规则和性能容量报警规则可以作为各种报警类型对应应急决策树模型的叶节点。其中，服务器集群可以包括多台服务器，服务器园区可以包括多个服务器集群。性能容量报警信息可以包括内存容量不足、服务器性能指标到达历史峰值等信息。
101.在一些实施例中，调用对应的应急预案对报警应用进行应急处理包括：若报警应用当前所属地内监控报警数量在预设阈值以上，隔离所述报警应用的当前所属地，和/或将所述报警应用从当前所属地切换至其他所属地。
102.例如所属地包括服务器集群或服务器园区。若查询到服务器集群或服务器园区内频繁发出报警(如部署的多个应用皆报警)，可能是由于集群或园区内的硬件或软件导致的故障，则可以直接隔离或切换集群或园区，从而提高应急处理速度。
103.在一些实施例中，调用对应的应急预案对报警应用进行应急处理包括：若查询到性能容量报警信息，执行以下至少一个操作：扩大容量、查杀异常进程和重肩报警应用所属服务器。若未查询到性能容量报警信息，熔断异常服务。扩大容量包括扩大内存容量，或增加服务器的性能。
104.其中，异常进程和异常服务可以由应急预案决策系统120从监控系统110获得，具体操作可以由一键式应急系统130执行。
105.下面通过图7～图9示出多个应急决策树架构图，其中交易报警、可用性报警和批量报警分别为各自决策树中的根节点，各个条件节点用菱形表示，用于执行判断调节。每条决策路径的尾部节点为叶节点。
106.图7示意性示出了根据本公开实施例的基于交易类模型应急的流程图。
107.如图7所示，报警类型包括交易报警类型，应急决策树模型包括交易类模型，按照应急决策树模型的决策路径将监控报警信息与n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：交易量下降决策路径、交易成功率下降决策路径和交易时间异常决策路径，分别用于交易量下降、交易成功率下降和交易时间异常(交易缓慢、超时)报警原因。
108.监控系统110确定报警应用名称(举例：应用a，所属业务场景α)和报警类型(类型：交易报警，原因：a交易成功率下降)并初步筛选需要尽快处理，将以上信息打包上送应急预案决策系统120。
109.在操作s701，当应急预案决策系统120获取到监控系统上送的报警信息时，根据报警类型匹配到交易报警的映射模型中(即交易类模型)。
110.在操作s702，若报警原因为交易量下降，则匹配到该交易量下降决策路径。
111.在操作s703，若报警原因为交易成功率下降，则匹配到该交易成功率下降决策路径。
112.在操作s704，若报警原因为交易缓慢、超时，则匹配到该交易时间异常决策路径。
113.尤其说明的是，虽然图7仅示出了在操作s702～操作s704之后执行操作s705来查询本应用是否变更，但是在操作s705之前，各个决策路径还可以设置有多个叶节点，例如交易量下降决策路径下可以包括流量是否超过峰值导致宕机、记账服务是否正常或网络是否正常等叶节点。一键式应急系统130触发应急流程后返回执行结果至应急预案决策系统120，若执行失败，则高亮提示值班人员人工介入。若执行成功，应急预案决策系统120持续调用监控系统观察报警是否恢复，若仍未恢复，则高亮提示值班人员人工介入。
114.在操作s705，从变更管理系统140中按照应用+时间范围搜寻故障发生时点前是否实施过与发生故障应用相关的变更。若是，则执行操作s706。若否，则执行操作s707。
115.在操作s706，拉取本应用的回退方案实施回退。例如搜寻当前时间节点的24小时内是否实施过a应用相关变更，若搜索到，则拉取回退方案自动实施。
116.在操作s707，从变更管理系统140中查询与本应用处于同一链路中的其他应用是否变更。若是，则执行操作s708。若否，则执行操作s710。
117.在操作s708，判断同一链路的其他应用是否异常报警。若是，则执行操作s709。若否，则判断下一应用。
118.在操作s709，拉取该应用的回退方案实施回退。还可以继续查询下一个。例如扩大范围循环反查a应用所在业务场景α的交易链路中其他应用b，c是否实施过相关变更，若搜索到，则同时回调监控系统搜索同时段是否有该应用报警，如有，则拉取该应用的回退方案自动实施。
119.在一些实施例中，如图7中虚线部分可以取消执行，例如无论该应用是否异常报警，考虑到两个应用可能变更后不兼容的问题，则皆可以直接实施回退，并回退后查看报警应用是否恢复正常。
120.在操作s711、操作s710执行集群或园区报警规则匹配。
121.在操作s710，判断是否同一集群/园区级大量报警。若是则认为匹配到该规则，则执行操作s711。若否，则执行操作s712。
122.在操作s711，服务器集群/园区隔离、切换。例如持续观察监控系统110在一定时间内其他应用同园区或集群内是否有报警，报警数量达到一定阈值后，动态升级应急预案，执行园区级隔离或切换。
123.在操作s712、操作s713执行性能容量报警规则匹配。
124.在操作s712，判断是否同时有性能容量报警。若是则认为匹配到该规则，则执行操作s713。若否，则执行操作s714。
125.在操作s713，扩容、查杀异常进程，或重启报警应用所属服务器。
126.在操作s714，熔断异常服务。
127.尤其说明的是，本公开并不限定于如上的先后顺序，例如操作s707与操作s710可以同时执行，操作s712～操作s714可以在操作s710之前执行。
128.如图7所示，操作s706、操作s709、操作s711、操作s713和操作s714是树的最末叶节点，为可以匹配到的应急决策规则，皆关联有对应的应急预案。
129.示例性地，在整体应急流程完成后，整合多个系统中的信息自动形成一份应急报告，报告中体现具体故障应用和故障原因、影响范围和实施的每一步应急操作以及耗时，以供后续生产问题复盘和分析使用。
130.通过建立监控报警应急系统100的统一一键式应急平台标准化应急流程，有利于生产运维管理及切换流程的保鲜，可以进一步提升生产应急保障平台的集约化和可靠性。此外，一旦发生基础设施层的故障，需要同时切换多个应用时，可以解决可能存在的人力资源瓶颈问题。
131.图8示意性示出了根据本公开实施例的基于可用性类模型应急的流程图。
132.如图8所示，报警类型包括可用性报警类型，应急决策树模型包括可用性类模型，将监控报警信息与n条应急决策规则进行匹配还包括：将监控报警信息与持续报警规则进行匹配，持续报警规则包括检查报警应用在多个时间点的监控报警信息。
133.在操作s801，应急预案决策系统120根据可用性报警类型匹配到可用性类模型中。
134.在操作s802，若报警原因为服务器/容器断线，则匹配到该服务器/容器断线决策路径。应知的是，服务器/容器断线仅为可用性报警的其中的一个报警原因，可以根据实际需要添加其他报警原因，并配置对应的决策规则以形成决策路径。
135.在操作s803，判断是否持续报警，即匹配持续报警规则，检查报警应用是否在多个时间点具有监控报警信息，例如每分钟报警一次。若是，则执行操作s804。若否，则执行操作s807。
136.在操作s804，判断是否同时有同一集群/园区其他报警。若是，则执行操作s805。若否，则执行操作s806。
137.在操作s805，执行服务器集群/园区的隔离、切换。
138.在操作s806，重启报警应用所在的单一服务器/容器。
139.在操作s807，忽略该次监控报警信息。
140.尤其说明的是，在图8所示的决策树模型中，如操作s705～操作s709的应用变更查询，或如操作s712～操作s714的性能容量查询独立于该决策树执行。在一些实施例中，也可以嵌入到可用性类模型中执行。
141.图9示意性示出了根据本公开实施例的基于批量类模型应急的流程图。
142.如图9所示，该实施例的报警类型包括批量报警类型，应急决策树模型包括批量类模型，按照应急决策树模型的决策路径将监控报警信息与n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：批量作业中断决策路径、批量作业超时决策路径和批量开始时间或结束时间异常决策路径。批量作业中断决策路径用于批量作业中断的报警原因；批量作业超时决策路径用于批量作业超时的报警原因；以及批量时间异常决策路径用于批量开始时间过晚，或批量结束时间过晚的报警原因。
143.在操作s901，应急预案决策系统120根据批量报警类型匹配到批量类模型中。
144.在操作s902，若报警原因为批量作业中断，则匹配到该批量作业中断决策路径，该路径可以包括操作s902～操作s906。
145.在操作s903，判断断点重提是否通过。若是，则结束本次应急。若否，则执行操作s904。
146.在操作s904，判断是否可跳过。若是，则执行操作s905。若否，则执行操作s906。
147.在操作s905，跳过中断作业并提醒运维人员次日补处理。
148.在操作s906，值班人员或运维人员人工介入处理。
149.在操作s907，若报警原因为批量作业超时，则匹配到该批量作业超时决策路径，该路径可以包括操作s907～操作s911。
150.在操作s908，判断是否特殊日期。若是，则执行操作s909。若否，则执行操作s913。
151.在操作s909，继续等待。
152.在操作s910，判断是否晚于最晚等待时间。若是，则执行操作s911。若否，则执行操作s909，继续等待过程中恢复正常则结束。
153.在操作s911，值班人员或运维人员人工介入处理。
154.在操作s912，值班人员或运维人员人工介入处理。
155.在操作s913，若报警原因为批量开始/结束时间过晚，则匹配到该批量开始时间或结束时间异常决策路径，该路径可以包括操作s908～操作s911，以及操作s914～操作s915。其中，批量作业超时决策路径和批量开始时间或结束时间异常决策路径有重叠。
156.在操作s914，判断前项作业是否中断。若是，则执行操作s915。若否，则执行操作s908。
157.在操作s915，等待前项处理完成。
158.当系统无法实现自动处置时也提供了人工介入渠道作为兜底策略，在应急完成后系统能形成应急报告展现报警原因、故障发生时采集的各项数据和日志和实施的应急步骤，作为后期复盘的材料。
159.基于上述监控报警应急方法，本公开还提供了一种监控报警应急装置。以下将结合图10对该装置进行详细描述。
160.图10示意性示出了根据本公开实施例的监控报警应急装置的结构框图。
161.如图10所示，该实施例的监控报警应急装置1000包括确定模块1010、匹配模块1020、决策模块1030和应急模块1040。
162.确定模块1010可以执行操作s210，用于确定监控报警信息中的报警应用和报警类型。
163.匹配模块1020可以执行操作s220，用于根据报警类型匹配预先配置的应急决策树模型，应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，n条应急决策规则基于报警类型的n个报警原因预先配置，n大于或等于1。
164.决策模块1030可以执行操作s230，用于按照应急决策树模型的决策路径将监控报警信息与n条应急决策规则进行匹配。
165.决策模块1030还可以执行图7～图9所示的各个步骤。
166.应急模块1040可以执行操作s240，用于根据匹配到的应急决策规则，调用对应的
应急预案对报警应用进行应急处理。
167.监控报警应急装置1000还可以包括链路应急模块，用于执行操作s310～操作s330，在此不做赘述。
168.监控报警应急装置1000还可以包括配置模块，用于执行操作s410～操作s420，操作s510～操作s520，操作s610～操作s620，在此不做赘述。
169.监控报警应急装置1000包括分别用于执行图2～图9所示或如上描述的任意一个实施例的各个步骤的模块。
170.需要说明的是，装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。
171.根据本公开的实施例，确定模块1010、匹配模块1020、决策模块1030和应急模块1040中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。
172.根据本公开的实施例，确定模块101 0、匹配模块1020、决策模块1030和应急模块1040中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，确定模块1010、匹配模块1020、决策模块1030和应急模块1040中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
173.图11示意性示出了根据本公开实施例的适于实现监控报警应急方法的电子设备的方框图。
174.如图11所示，根据本公开实施例的电子设备1100包括处理器1101，其可以根据存储在只读存储器(rom)1102中的程序或者从存储部分1108加载到随机访问存储器(ram)1103中的程序而执行各种适当的动作和处理。处理器1101例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))等等。处理器1101还可以包括用于缓存用途的板载存储器。处理器1101可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
175.在ram 1103中，存储有电子设备1100操作所需的各种程序和数据。处理器1101、rom 1102以及ram 1103通过总线1104彼此相连。处理器1101通过执行rom 1102和/或ram 1103中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除rom 1102和ram 1103以外的一个或多个存储器中。处理器1101也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
176.根据本公开的实施例，电子设备1100还可以包括输入/输出(i/0)接口1105，输入/输出(i/o)接口1105也连接至总线1104。电子设备1100还可以包括连接至i/0接口1105的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1106。包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1107。包括硬盘等的存储部分1108。以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网
络执行通信处理。驱动器1110也根据需要连接至i/0接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。
177.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的。也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
178.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 1102和/或ram 1103和/或rom 1102和ram 1103以外的一个或多个存储器。
179.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的方法。
180.在该计算机程序被处理器1101执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
181.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分11 09被下载和安装，和/或从可拆卸介质1111被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
182.在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被处理器1101执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
183.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c++，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
184.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代
表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
185.本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
186.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

技术特征：
1.一种监控报警应急方法，包括：确定监控报警信息中的报警应用和报警类型；根据所述报警类型匹配预先配置的应急决策树模型，所述应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，所述n条应急决策规则基于所述报警类型的n个报警原因预先配置，n大于或等于1；按照所述应急决策树模型的决策路径，将所述监控报警信息与所述n条应急决策规则进行匹配，其中，所述n条应急决策规则包括与所述n个报警原因一一对应的应急预案信息；根据匹配到的应急决策规则，调用对应的应急预案对所述报警应用进行应急处理。2.根据权利要求1所述的方法，其中，在所述确定监控报警信息中的报警应用和报警类型之后，还包括：确定所述报警应用涉及的m个业务场景，m大于或等于1；确定所述m个业务场景中每个业务场景涉及所述报警应用的交易链路，其中，所述交易链路包括所述报警应用在内的至少两个应用，所述报警应用与所述交易链路中其余至少一个应用具有数据交互；查询每个所述交易链路中其余应用的监控报警信息和/或应用变更信息。3.根据权利要求2所述的方法，其中，在确定所述报警应用涉及的m个业务场景之前，所述还包括：查询所述报警应用的应用变更信息；若查询到所述报警应用的应用变更信息，则将所述报警应用回退到变更前状态；若未查询到所述报警应用的应用变更信息，则继续执行所述确定所述报警应用涉及的m个业务场景。4.根据权利要求2所述的方法，其中，在确定所述报警应用涉及的m个业务场景之前，所述方法还包括：确定所述每个业务场景涉及的s个应用，s大于或等于1；根据所述s个应用在所属业务场景中的数据交互确定至少一个交易链路；和/或，以所述每个业务场景为维度，配置所述s个应用中每个应用关联的至少一个应急预案。5.根据权利要求4所述的方法，其中，所述方法还包括预先配置应急决策规则，具体包括：根据所述每个应用的历史监控报警信息，确定该应用的q种报警类型，和其中每种报警类型对应的n个报警原因，所述q种报警类型包括所述监控报警信息中的报警类型，q大于或等于1；针对所述每种报警类型对应的n个报警原因配置n条应急决策规则。6.根据权利要求5所述的方法，其中，所述方法还包括预先配置应急决策树模型，具体包括：针对所述每种报警类型，根据该报警类型下每个报警原因的特征构造k个条件节点，其中每个条件节点包括用于匹配所述监控报警信息的特征判断条件，k大于或等于1；将该报警类型构造为根节点，及该报警类型下的n条应急决策规则构造为n个叶节点，其中，所述决策路径包括从所述根节点经由所述k个条件节点至所述n个叶节点的任一条路径；
根据所述根节点、所述k个条件节点和所述n个叶节点，得到该种报警类型相匹配的应急决策树模型。7.根据权利要求1～6任一项所述的方法，其中，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括：将所述监控报警信息与集群或园区报警规则进行匹配，所述集群或园区报警规则包括检查所述报警应用所属的服务器集群或服务器园区内的监控报警信息；和/或将所述监控报警信息与性能容量报警规则进行匹配，所述性能容量报警规则包括检查性能容量报警信息。8.根据权利要求7所述的方法，其中，所述调用对应的应急预案对所述报警应用进行应急处理包括：若所述报警应用当前所属地内监控报警数量在预设阈值以上，隔离所述报警应用的当前所属地，和/或将所述报警应用从当前所属地切换至其他所属地。9.根据权利要求7所述的方法，其中，所述调用对应的应急预案对所述报警应用进行应急处理包括：若查询到所述性能容量报警信息，执行以下至少一个操作：扩大容量、查杀异常进程和重启所述报警应用所属服务器；若未查询到所述性能容量报警信息，熔断异常服务。10.根据权利要求7所述的方法，其中，所述报警类型包括可用性报警类型，所述应急决策树模型包括可用性类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配还包括：将所述监控报警信息与持续报警规则进行匹配，所述持续报警规则包括检查所述报警应用在多个时间点的监控报警信息。11.根据权利要求7所述的方法，其中，所述报警类型包括批量报警类型，所述应急决策树模型包括批量类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：批量作业中断决策路径，用于批量作业中断的报警原因；批量作业超时决策路径，用于批量作业超时的报警原因；以及批量时间异常决策路径，用于批量开始时间过晚，或批量结束时间过晚的报警原因。12.根据权利要求7所述的方法，其中，所述报警类型包括交易报警类型，所述应急决策树模型包括交易类模型，所述将所述监控报警信息与所述n条应急决策规则进行匹配包括按照以下至少一个决策路径进行匹配：交易量下降决策路径，用于交易量下降的报警原因；交易成功率下降决策路径，用于交易成功率下降的报警原因；以及交易时间异常决策路径，用于交易时间缓慢或超时的报警原因。13.一种监控报警应急系统，所述系统包括：监控系统，用于获取监控报警信息；应急预案决策系统，用于与所述监控系统交互以确定报警应用和报警类型，并执行权利要求1～12任一项所述的方法；应急系统，用于响应于所述应急预案决策系统调用应急预案的请求，执行所述应急预
案以对所述报警应用进行应急处理。14.一种监控报警应急装置，包括：确定模块，用于确定监控报警信息中的报警应用和报警类型；匹配模块，用于根据所述报警类型匹配预先配置的应急决策树模型，所述应急决策树模型通过将n条应急决策规则构造为n个叶节点获得，所述n条应急决策规则基于所述报警类型的n个报警原因预先配置，n大于或等于1；决策模块，用于按照所述应急决策树模型的决策路径将所述监控报警信息与所述n条应急决策规则进行匹配，其中，所述n条应急决策规则包括与所述n个报警原因一一对应的应急预案信息；应急模块，用于根据匹配到的应急决策规则，调用对应的应急预案对所述报警应用进行应急处理。15.一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～12中任一项所述的方法。16.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～12中任一项所述的方法。17.一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～12中任一项所述的方法。

技术总结
本公开提供了一种监控报警应急方法，涉及人工智能领域。该方法包括：确定监控报警信息中的报警应用和报警类型；根据所述报警类型匹配预先配置的应急决策树模型，所述应急决策树模型通过将N条应急决策规则构造为N个叶节点获得，所述N条应急决策规则基于所述报警类型的N个报警原因预先配置，N大于或等于1；按照所述应急决策树模型的决策路径，将所述监控报警信息与所述N条应急决策规则进行匹配，其中，所述N条应急决策规则包括与所述N个报警原因一一对应的应急预案信息；根据匹配到的应急决策规则，调用对应的应急预案对所述报警应用进行应急处理。本公开还提供了一种监控报警应急装置、系统、设备、存储介质和程序产品。存储介质和程序产品。存储介质和程序产品。


技术研发人员：林黎
受保护的技术使用者：中国工商银行股份有限公司
技术研发日：2023.05.08
技术公布日：2023/8/24