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

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

一、背景提要

最近在落地案例时，发现有些企业，仍在使用十多年前的流程和思想来思考业务和产品的未来。做产品必须明确该产品未来的业务发展方向，否则研发出的东西只是应对当前可见的需求（即项目需求而非产品需求），在企业战略调整乃至社会经历变化后，这些产品很容易站不住脚从而被边缘化。这也是楼主写这篇文章的初衷，希望大家能精准把握业务未来的方向，这样才能设计出长期、分阶段、持续可销售且有价值产品。

本次分享将从统一事件管理的过去、现在和未来进行分析，探讨统一事件管理的未来发展趋势，以帮助企业更好地处理告警系统所带来的挑战和问题。

由于干货较多，文章篇幅过长，所以本期主要跟大家说一说单一告警管理和统一告警管理这两个问题。下期我们再整体讨论下统一事件管理与智能事件分析，感兴趣的朋友可以右上角关注一波~~

二、单一告警管理

1.面临问题

在这个阶段，由于所运维的系统架构简单，而且数据比较少，运维团队还能够很好地应对系统进行运维，并无任何不适。

2.主要特征

本阶段的告警管理大约可以追溯到15年前，相关特征可总结如下：

（1）技术上：大多数系统都是单体应用，系统复杂性非常低，在这个阶段不同的监控工具监控不同的专业领域（机房环境、主机、网络等）。

（2）告警种类：比较单一，一般只有有限一种或几种，因此告警的处理也比较简单，很容易让人掌握。

（3）人员组成：由于告警的种类单一，对人员的学习成本就会比较低。各不同应用厂商会提供对系统运维的日常手册，出了问题运维团队不需要太多的技术能力和专业技能，只要能够按照手册进行处理即可，如果不能解决只能升级到厂商即可。

（4）组织流程：由于分散的监控工具，需要一个统一的地方和流程能够配合进行告警的分配和处置，因此早期阶段会采用工单系统。产生告警后进入手工流程或工单系统（较大型组织），进行告警工单的分派和流转，流程通常都比较短，这时处置会比较高效。

3.单一告警管理的业务功能

（1）监控系统生成异常事件：监控源配置阈值或异常检测算法，生成异常事件(event)。

（2）对告警进行源端压缩：在配置告警策略时，会一并配置针对告警对象在一定时间范围内连续达到多少次异常之后会生成告警。

（3）生成告警：生成告警并存储。

（4）告警通知：会配置相应的通知模板、通知策略并完成对告警的通知。

（5）告警中心：会有一个告警中心，针对当前监控源产生的告警进行统一存放。

（6）同步工单：一些流程化比较规范的组织，会通过一些工单类的系统完成对告警转工单的开立，由工单来驱动告警的处置。

三、统一告警管理

1.面临问题

我们在一些企业里落地统一告警的建设之前，经常会发现如下问题：

（1）告警量大：由于云战略和数字化转型，导致系统的复杂性、应用的数量增加，使得监控对象、监控方法工具等产生的告警量成倍增长。

（2）团队规模短时间内增长明显：由于告警量的增大，以及不同领域的组件问题突出，造成人员规模的增长。

（3）成本增加：人员的增长直接导致成本的巨大支出。

（4）告警噪音：虽然人员的增长很大，但是依旧不能处理所有的告警，很多告警是无效的，需要对告警进行有效的降噪处理。

（5）工具重复建设：告警的处理流程基本是一致的，但是因为监控工具的分散，导致不同的流程需要在不同的监控工具进行落地，如：告警工作台、告警分析处置、告警数据的丰富、告警的通知等，不同工具的相同功能重复建设。

2.主要特征

本阶段大约在7年前，相关的特征可总结如下：

（1）系统复杂性明显：基于SOA和分布式系统架构的复杂系统已经成为常态。系统变得越来越复杂，因此需要越来越多的监控工具，例如应用监控、用户体验监控、基础设置监控、数据库监控、存储设备、中间件、交易链路等，监控工具不断丰富。

（2）告警种类多：由于技术复杂性的提高，需要更多的监控工具，进而产生越来越多的告警种类和告警。

（3）团队规模增长明显：不同的技术组件以及系统架构的复杂性，要求具有不同领域的专家来专职负责本领域的运维工作，如ORACLE DBA、存储、网络、应用领域的专家等。对应本领域内的专家仅专攻本领域内的问题分析及处置，因此随着系统复杂性的增加，运维团队也需要成倍增加。

（4）组织流程复杂：随着人员规模的增加，管理方面迫切需要有效的流程来协调人员、加速决策效率。

以下有两种不同的做法，它们在不同的流程选择上所带来的系统研发成本、人力投入成本、管理成本、流程线路拉长程度是完全不同的。

做法一：

某些南方小城商行采取的做法是，在告警生成后第一时间发出通知，然后完成与工单系统的集成，将告警同步到工单系统中。接下来，工单系统将驱动告警的分派、确认、指派、分析、处置和关闭等操作。

运维人员在接收到告警后，还需要登录工单系统进行认领。

在分析处置环节，需要登录统一告警查看告警基本信息、登录监控源查看指标曲线以验证告警是否真实，然后再登录自动化平台手动执行一些代码或脚本。

总体来说这种做法有如下缺陷：

①流程过长：容易出错，不利于快速处理告警。

②集成成本高：需要建立同工单系统的双向信息同步。

③调查分析效率低：由于工单系统本身是一套流程性的平台，不适合进行调查和分析。这就导致当人们接收到工单后，无法从一个统一的界面完成告警的调查、分析、处置等操作，导致效率过低。

做法二：

很多银行和头部的券商企业并不会墨守成规，会对流程进行适当的调整。比如：

（1）缩短流程：由于每个告警都已经明确指定了负责处理的运维团队，因此一旦告警产生，相应的运维人员会在第一时间得到通知。运维人员可以立即登录到统一告警平台，并利用该平台的集成能力获取推荐的信息和知识进行分析，以提高排障效率。对于严重的告警，生产恢复后会在工单系统中补充工单以备审计，整个流程非常高效。

（2）加快调查分析速度：统一告警定位为运维人员的日常工作平台，完成了与指标、日志、trace等的集成，并提供了一些自动化或智能化的数据分析功能，帮助运维人员快速分析和处置告警，加速生产恢复。

（3）集成信息：为了满足运维人员分析和处理告警的需求，统一告警平台与指标、日志、trace、变更单、知识库等进行了集成。

（4）依赖告警平台提供的信息及集成能力：也有一些银行表示他们的二线从来不会登录告警平台，只进工单系统。我认为本质原因是他们没有认识到工单系统仅仅是一个流程平台。对于告警的分析和处理，他们已经习惯了用最传统的方法——登录不同的平台去查信息、手动分析告警。而不是通过工具系统提高信息收集和分析的效率，以及将分析结果提供给人来做决策，从而提高效率。

3.统一告警管理业务功能

（1）集成：拥有不同监控源告警的集成、变更、自动化平台、指标、日志等的集成能力。

（2）数据清洗及标准化：企业为了后续告警的分析、处置需求，通常会制定统一的告警数据模型规范。该系统可以针对不同厂商的监控源系统所产生的告警进行统一的数据清洗及标准化操作，然后将数据存入统一告警管理平台。

（3）丰富数据：由于监控源为了保障快速对接入的指标进行监控的需求，一般只会抛出告警对象、发生时间、发生了什么问题、什么指标发生的问题这四个重要信息，但为了满足对告警的通知、分析、处理需求，需要通过一些数据源完成告警数据的丰富。

（4）过滤及维护期：针对被运维人员识别为告警噪音的告警需要进行过滤处理。对于在变更阶段所产生的告警，不需要进行通知，这就需要维护期管理的能力。

（5）压缩降噪：是该系统的核心能力。它可以针对同一告警对象、同一时间段的多个重复告警进行压缩，以降低告警噪音量。

（6）通知：针对压缩之后的告警，按合适的时间、通过合适的渠道、通知给正确的人进行处置。

告警工作台是运维人员的统一告警管理工作平台。它可以查看权限控制范围内的告警列表、详情、压缩的原始告警列表、自动收集近期变更及日志和指标信息并展示相关曲线，以及针对告警的认领、指派、关闭、恢复、静默等操作的能力。

本期的分享就到这里了，下期我们继续说说运维中统一事件（incident）管理与智能事件（incident）分析及处置相关干货，感兴趣的朋友可以蹲一波~

擎创科技，Gartner连续推荐的AIOps领域标杆供应商。公司专注于通过提升企业客户对运维数据的洞见能力，为运维降本增效，充分体现科技运维对业务运营的影响力。

行业龙头客户的共同选择

了解更多运维干货与行业前沿动态

可以右上角一键关注

我们是深耕智能运维领域近十年的

连续多年获Gartner推荐的AIOps标杆供应商

下期我们不见不散~