AIOps探索 | 从单一告警管理到统一告警管理-编程知识

原作者：擎创科技资深产品专家布博士

前言

最近发现我们的一些客户，仍在使用十多年前的流程和思想来思考业务和产品的未来。我们认为做产品必须明确该产品未来的业务发展方向，否则研发出的东西只是应对当前可见的需求（即项目需求而非产品需求）。只有精准把握业务未来的方向，才能设计出长期、分阶段、持续可销售且有价值产品。

本文，将从统一事件管理的过去、现在和未来进行分析，探讨统一事件管理的未来发展趋势，主要包括：

单一告警管理
统一告警管理
统一事件（incident）管理（在后续文章里）
智能事件（incident）分析及处置（在后续文章里）
总结

单一告警管理

面临问题

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

主要特征

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

技术上：大多数系统都是单体应用，系统复杂性非常低，在这个阶段不同的监控工具监控不同的专业领域（机房环境、主机、网络等）。
告警种类：比较单一，一般只有有限一种或几种，因此告警的处理也比较简单，很容易让人掌握。
人员组成：由于告警的种类单一，对人员的学习成本就会比较低。各不同应用厂商会提供对系统运维的日常手册，出了问题运维团队不需要太多的技术能力和专业技能，只要能够按照手册进行处理即可，如果不能解决只能升级到厂商即可。
组织流程：由于分散的监控工具，需要一个统一的地方和流程能够配合进行告警的分配和处置，

因此早期阶段会采用工单系统。产生告警后进入手工流程或工单系统（较大型组织），进行告警工单的分派和流转，流程通常都比较短，这时处置会比较高效。

业务功能范围

主要业务功能包括：

监控系统生成异常事件：监控源配置阈值或异常检测算法，生成异常事件(event)。
对告警进行源端压缩：在配置告警策略时，会一并配置针对告警对象在一定时间范围内连续达到多少次异常之后会生成告警。
生成告警：生成告警并存储。
告警通知：会配置相应的通知模板、通知策略并完成对告警的通知。
告警中心：会有一个告警中心，针对当前监控源产生的告警进行统一存放。
同步工单：一些流程化比较规范的组织，会通过一些工单类的系统完成对告警转工单的开立，由工单来驱动告警的处置。

统一告警管理

面临问题

在进行统一告警的建设之前，我们发现如下问题：

告警量大：由于云战略和数字化转型，导致系统的复杂性、应用的数量增加，使得监控对象、监控方法工具等产生的告警量成倍增长。
人员增长：由于告警量的增大，以及不同领域的组件问题突出，造成人员规模的增长。
成本增加：人员的增长直接导致成本的巨大支出。
告警噪音：虽然人员的增长很大，但是依旧不能处理所有的告警，很多告警是无效的，需要对告警进行有效的降噪处理。
工具重复建设：告警的处理流程基本是一致的，但是因为监控工具的分散，导致不同的流程需要在不同的监控工具进行落地，如：告警工作台、告警分析处置、告警数据的丰富、告警的通知等，不同工具的相同功能重复建设。

主要特征

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

技术上：基于SOA和分布式系统架构的复杂系统已经成为常态。系统变得越来越复杂，因此需要越来越多的监控工具，例如应用监控、用户体验监控、基础设置监控、数据库监控、存储设备、中间件、交易链路等，监控工具不断丰富。
告警种类：由于技术复杂性的提高，需要更多的监控工具，进而产生越来越多的告警种类和告警。
人员组成：不同的技术组件以及系统架构的复杂性，要求具有不同领域的专家来专职负责本领域的运维工作，如ORACLE DBA、存储、网络、应用领域的专家等。对应本领域内的专家仅专攻本领域内的问题分析及处置，因此随着系统复杂性的增加，运维团队也需要成倍增加。
组织流程：随着人员规模的增加，管理方面迫切需要一些有效的流程来协调人员、加速决策效率。以下列出两种不同的做法，它们在不同的流程选择上所带来的系统研发成本、人力投入成本、管理成本、流程线路拉长程度是完全不同的：

方法一：我们看到一些南方小城商行采取的做法是，在告警生成后第一时间发出通知，然后完成与工单系统的集成，将告警同步到工单系统中。接下来，工单系统将驱动告警的分派、确认、指派、分析、处置和关闭等操作。运维人员在接收到告警后，还需要登录工单系统进行认领。在分析处置环节，需要登录统一告警查看告警基本信息、登录监控源查看指标曲线以验证告警是否真实，然后再登录自动化平台手动执行一些代码或脚本，容易出错。总结如下缺点：

流程过长：不利于快速处理告警。
集成成本高：需要建立同工单系统的双向信息同步。
调查分析效率低：由于工单系统本身是一套流程性的平台，不适合进行调查和分析。这就导致当人们接收到工单后，无法从一个统一的界面完成告警的调查、分析、处置等操作，导致效率过低。

方法二：我们也观察到很多银行和头部的券商企业并不会墨守成规，会对流程进行适当的调整。为了快速处置告警并恢复生产，他们会进行以下优化：

缩短流程：由于每个告警都已经明确指定了负责处理的运维团队，因此一旦告警产生，相应的运维人员会在第一时间得到通知。运维人员可以立即登录到统一告警平台，并利用该平台的集成能力获取推荐的信息和知识进行分析，以提高排障效率。对于严重的告警，生产恢复后会在工单系统中补充工单以备审计，整个流程非常高效。
调查分析速度快：统一告警定位为运维人员的日常工作平台，完成了与指标、日志、trace等的集成，并提供了一些自动化或智能化的数据分析功能，帮助运维人员快速分析和处置告警，加速生产恢复。
集成信息：为了满足运维人员分析和处理告警的需求，统一告警平台与指标、日志、trace、变更单、知识库等进行了集成。

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

业务功能范围

主要业务功能包括：

集成：拥有不同监控源告警的集成、变更、自动化平台、指标、日志等的集成能力。
数据清洗及标准化：企业为了后续告警的分析、处置需求，通常会制定统一的告警数据模型规范。该系统可以针对不同厂商的监控源系统所产生的告警进行统一的数据清洗及标准化操作，然后将数据存入统一告警管理平台。
数据丰富：由于监控源为了保障快速对接入的指标进行监控的需求，一般只会抛出告警对象、发生时间、发生了什么问题、什么指标发生的问题这四个重要信息，但为了满足对告警的通知、分析、处理需求，需要通过一些数据源完成告警数据的丰富。
过滤及维护期：针对被运维人员识别为告警噪音的告警需要进行过滤处理。对于在变更阶段所产生的告警，不需要进行通知，这就需要维护期管理的能力。
压缩降噪：是该系统的核心能力。它可以针对同一告警对象、同一时间段的多个重复告警进行压缩，以降低告警噪音量。
通知：针对压缩之后的告警，按合适的时间、通过合适的渠道、通知给正确的人进行处置。
告警工作台是运维人员的统一告警管理工作平台。它可以查看权限控制范围内的告警列表、详情、压缩的原始告警列表、自动收集近期变更及日志和指标信息并展示相关曲线，以及针对告警的认领、指派、关闭、恢复、静默等操作的能力。