AIOps探索 | 面向多告警源，如何进行统一事件管理（下）

文章来源：公众号ID-布博士（擎创科技资深产品专家）

书接上期，本期我们继续分享“统一事件管理”和“智能事件分析与处置”，新来的朋友点这里，

AIOps探索 | 面向多告警源，如何进行统一事件管理（上）

一键回看上期精彩内容，文章较长，干货多多，建议先马后看

一、统一事件管理

1.面临问题

在进入本阶段之前，企业运维仍存在以下问题：

（1）告警量大：尽管在统一告警阶段已经对告警进行了统一的管理、过滤和压缩治理，但要处理的告警量仍然很大，需要一种方法能够更进一步地完成告警的收敛。

（2）关系复杂：难以识别相互之间的影响。

（3）人员增长：为了应对数字化转型带来的压力，人员规模持续增长。

（4）协作不畅：传统的团队分工以及基于工单的流程系统导致相互之间的协作不畅。每次出现事件，需要不同团队之间反复沟通以确认业务上技术上的影响范围，然后再通过工单流系统发起工单，效率低下。

2.主要特征

本阶段的主要特征类似于统一告警管理阶段，但在管理对象、业务流程、组织结构等方面发生了很大的变化：

（1）技术发展，处置效率提升：由于数字化转型的需求，对研发效率、系统稳定性、快速满足客户需求等方面提出了更高的要求。因此大型企业要同时面对老旧的系统架构和新的分布式架构所带来的挑战。即使是规模较小的新创业团队也会采用复杂的分布式应用来保障应用程序的灵活性和高开发效率。

（2）组织结构向服务发展：一切皆服务。服务所有权模型是一种用于管理现代IT系统的有效模型。它能够将运维团队、开发团队和测试团队连接起来，促进协作，快速响应所运维的IT服务设施，并按服务方式对业务系统的模块进行细粒度的拆分和管理。

这种模型更符合现代分布式架构的研发及运维一体化团队组成结构。（后续我会整理针对传统IT架构下的服务所有权模型如何自治建模，以及在应急及事件处置场景下如何替代CMDB使之更容易落地）

（3）管理及处置对象更清晰：由传统的告警转变为事件 (incident)。当发生告警时，可以按照告警路由规则路由到不同的服务模型，对告警进行进一步的收敛生成事件。并将收敛后的事件信息通过各种通知渠道通知给所在的运维团队。其所带来的价值改变如下图所示：

（4）人员增长速度放缓：由于推行了一系列有效的管理手段、服务所有权模型、告警收敛为事件，人员规模不再像统一告警阶段那样无限制地增长。

（5）流程更简洁：通过实行服务所有权，业务服务和技术服务得以有效结合。客户的业务投诉和内部用户的电话或工单报障会首先同步到统一事件管理平台，并根据客户投诉所在的业务服务自动创建相应的事件，驱动分析和处理。当事件处理完成后，最新的结果和状态信息会同步给客户服务渠道和工单系统，然后由客户服务团队通知最终用户，避免中间工单环节流转来流转去，加快效率。

3.统一事件管理业务功能

统一事件管理平台在统一告警管理平台的基础上增强了以下能力：

（1）服务模型管理能力更强：服务模型管理是统一事件管理平台的一个增强能力。服务模型除了兼容传统技术架构，可以对业务系统的模块进行细粒度的拆分和管理，还能更好地适应分布式微服务架构，很好地表达服务之间的相互依赖关系。通过服务模型管理，无论是业务服务还是技术服务出现问题，都能更快地定位问题，快速恢复服务，提高系统的稳定性和可靠性。

（2）服务可视化及影响分析更及时：可以通过可视化的方式展示业务服务由哪些技术服务组件构成，以及它们之间的依赖关系。并可以通过可视化的方式来展示服务之间的关联关系。当发生问题时，通过服务可视化及影响分析，可以追踪一个事件的起源以及它的上下游的影响情况，帮助企业快速了解问题的规模和范围，并采取相应的措施。

（3）告警关联生成事件（incident）：处理的对象不再是告警，而是有关联关系的事件。可以通过多种方式（如下图所示）将相互之间有关联关系或影响关系的告警组合成事件。运维人员在处理事件时，可以提供更丰富的告警上下文信息，并可以有效降低要处理的告警数量，加速对事件的分析及恢复过程。

（4）用户组绑定服务模型：通过用户组的管理方式将开发、测试、运维团队形成对服务的所有权管理模式，构建开发、运维一体化团队，确保每一个服务都有对应的用户组进行运维。当发生问题时，初级问题由用户组内部的运维团队负责解决，而高级问题则可以直接由测试或开发人员来完成，增强协作效率。

（5）通知事件（incident）而非告警：通过单个告警会形成大量的噪音干扰，而对最终的运维团队而言，更想知道发生了什么业务、什么服务、什么系统在什么时间发生了什么问题。例如：[二代支付系统]的[跨行转帐服务(1000089)]交易缓慢，支持该业务的3台应用服务器出现GCCOUNT、CPU使用率等5种类型的告警，共计33条关联告警。事件编码:INC202308281535401001，发生时间:2023年08月28日15:35:40。

（6）事件（incident）管理工作台：形成统一的事件管理工作台，不同的用户群组可以根据自己的数据权限查看相应的事件，并在该工作台上完成对事件的调查、分析和处理操作。

二、智能事件分析及处置

1.面临问题

在进入本阶段的设计之前，主要存在如下问题：

（1）历史处置方案及知识难以有效借鉴。

（2）占用大量的专家资源，专家经验难以工具化。

（3）处置效率慢，缺乏自动化排查及分析手段，无法快速定位并修复问题。

（4）难以从历史事件中获取更深入的洞见。

2.主要特征

（1）积极推行SRE的运维文化：SRE文化的核心是通过事后的复盘分析找到问题的根本原因，通过工程的方法将问题彻底解决，防止下次再次发生，或不能彻底杜绝的情况下可以通过自动化的手段来再次捕捉问题，并进行自动化的响应。通过该文化的落地使运维团队不断治理发现的事件，从而使开发运维团队从告警噪音中解放出来，有更多的时间和精力放到如何优化现有的工具、系统，为客户创造更大的价值上。

（2）专家经验需要沉淀：通过管理流程和技术手段相结合的方式，使专家对事件的处置经验沉淀到系统中。当再次发生类似的事件时，可以快速借鉴之前类似事件的分析过程和处置方案，加速业务恢复过程。

（3）可编排的自动化能力：不同情境下的事情是变化的，但是针对人类进行问题排查的过程是相同的。因此，需要一套可编排的自动化排查系统（产品级的），能够根据不同事件情境进行参数化配置。通过按照运维人员针对不同情境的事件变化配置不同的排查策略，当事件发生时能够快速触发排查并产生结论报告，以节省大量的人力，提高排查分析及自动化处置的效率。

例如：

验证告警与实际情况是否相符：当数据库主机DOWN机时，主机管理员通常会首先使用ping方法进行主机探活操作，以验证是否误报。通过自动化的方法，可以大大降低这类告警的噪音，同时会节省人工排查的时间成本。

某行二代支付系统故障排查：当发现二代支付系统故障时，首先需要根据告警信息来判断是来报异常、往报异常、渠道异常等情况。如果是来报异常，则可以判断是行外系统异常而非行内系统。这时需要排查前置机是否出现异常。如果前置机未出现异常，则会认为是他行给到的交易出现了问题。重点排查哪个银行发来的交易引起了问题。

（4）推行智能化：包括智能化的根因推荐、智能化的相似事件识别、已知事件的识别和判断、以及针对事件推送相应的知识和处置建议。同时，结合可编排的自动化能力，最终实现数据中心的自治和自愈能力。

（5）人员规模：由于SRE运维文化的导入，自动化和智能化的普及，团队规模的工作负载会越来越少。

（6）成为企业数字化转型必不可少的基础设施：智能事件分析及处置平台将成为企业数字化转型必不可少的基础设施。通过该中心，可以链接监控源、变更管理、自动化平台、知识库、通知渠道、客户服务团队、IT服务团队、测试及开发团队，驱动协调整个体系使其高效运转，从而将IT风险最小化。

3.智能事件分析及处置业务功能

在统一事件管理平台的基础上，智能事件分析及处置提供了如下能力：

（1）相似事件识别

在事件处理完成后，需要将事件的分析处理过程记录到智能事件分析和处置平台。当下次类似事件发生时，智能算法会根据事件的特征识别出来，并推荐历史上针对该类事件的处置策略，从而加速事件处理过程。

（2）可编排的自动化分析能力

可编排的自动化分析能力是实现AIOPS的最后一公里的关键。在2018年，PAGERDUTY以1亿美金收购了RUNDECK，splunk以3.5亿美金收购了Phantom，以加强其可编排的自动能力。这种能力是智能化运维的核心组件。

下面我们看一个主机down机的用例，来看一下该产品所具备的能力：

首先，设置一个触发器来捕捉告警或事件。在这个例子中，我们针对服务器宕机告警进行配置。如上图中圈1位置所示，当告警产生时，如果alert_source='zabbix'且alert_title='SERVER_DOWN'，则触发该分析流程。

进入流程逻辑处理层：

第一步：如上图圈2所示，先执行ping指令进行主机探活。执行完成后，解析脚本执行的结果，并生成针对该步骤的中间变量存放在上图圈5所在的位置，以供全局流程使用。
第二步：如上图圈3所示，执行主机探活返回结果状态的判断。如果STATUS=TRUE，则表示当前主机处于活动状态。
第三步：如上图圈4所示，如果主机可以ping通，则表明当前告警为误报，需要执行“告警操作”中的“告警关闭”，这样就不会产生告警噪音的通知。如果主机ping不通，则表明主机确实已经down机，当前流程即结束。

（3）根因推荐

当完成告警聚合为事件后，事件中可能包含多个告警的异常信号。为了找到问题是由什么告警所引起的，系统需要推荐可能的根因，将其推送到运维人员的事件详情页面上以协助其进行判断。运维人员进行分析后，会将结果反馈给系统，算法将重新优化算法的推荐结果。

（4）已知事件识别

在事件处理过程中，运维人员会总结出大量规律，形成已知事件。针对这些已知事件，会配置快速恢复策略。当出现这种问题时，会触发全自动化或半自动化的处置策略。

例如：

①：当 WEBLOGIC 出现 FULLGC 告警，并且在同一时间段出现应用交易响应时间过长的告警时，应该针对该告警主机上 WEBLOGIC 进行的DUPMP 信息收集和服务重启操作，以快速解决该事件。
②：当某交易的处理时间变长，且在同一时段出现了该交易的某台AP主机打开文件句柄超限的告警。如果出现这两种类型的告警，则需要对该AP主机进行重启操作。

在识别出已知事件之后，可以向运维人员推荐处理动作，如上图所示，由运维人员经过判断之后手动触发执行。

（5）处置方案推荐

如上图所示，针对已知事件识别之后可以推荐其处置方案。

（6）知识推荐

如上图所示，针对已知事件识别之后可以推荐其相关知识和手册。

（7）自动化处置库管理

在进行自动化处置时，必须将每个对象类型及其可执行的操作关联起来。这样，在出现已知故障或运维人员分析之后，可以快速锁定针对告警对象可执行的操作列表。可执行的操作一般由自动化平台、云管平台等同步过来，并进行有效的分类管理。真正的执行操作由统一事件管理平台调用自动化平台或云管平台提供的API完成最终的执行动作。