0 写在最前

文中所提及的事件并不仅限于故障，还包括运维工作中的告警、异常等。

“An incident is an unplanned interruption to an IT Service or a reduction in the Quality of an IT Service.” Source: Incident Management -ITIL

1 背景

在《AIOps在美团的探索与实践——故障发现篇》一文中，我们探讨了AIOps在异常检测的实践。Horae（美团AIOps平台）在单时序异常检测方面已有较多积累，智能告警功能作为底层能力支撑了监控系统和异常检测场景。服务运维团队在此基础上开展AIOps在事件管理领域的相关工作，本文主要分享过去两年的探索与实践，希望能对大家有所帮助或启发。

事件管理的复杂性体现在两个方面：

1. 数据繁多：

   • 数据多样化：运维工作需要各种类型的数据来识别、诊断、处理问题，包括告警、链路、指标、日志、变更（含发版）等。
   • 数据实时性强、关系复杂：运维数据通常需要实时采集和处理。这些数据之间的关系错综复杂，如链路数据与告警数据、指标数据与日志数据等可能存在密切的关联，需要精细的统一处理。
   • 领域知识强：运维领域涉及的知识广泛，包括网络、硬件、系统、数据库、应用等多个层面，业务运维更需要不同的领域知识，这对运维人员和运维工具提出了较高的要求。

2. 流程复杂：

   • 事件管理的时间线如下，每个环节都需要提效才能达成事件管理的效率提升。

面对上述挑战，美团运维团队在过去几年建设了丰富的工具体系，基于专家经验、规则配置、流程管控等方式进行事件管理。本文聚焦的AIOps实践，是对上述工作的赋能，可拆解为四个模块：

• 风险预防——变更风险智能检测：以用户和实体为对象，结合规则以及机器学习模型，对用户行为进行分析和异常检测。
• 故障发现——智能识别指标异常：基于统计算法和机器学习算法识别指标的异常模式，帮助用户快速发现故障。
• 事件处理——诊断和预案推荐：通过多模态数据和算法规则引擎来帮助用户快速定位故障，推荐止损预案。
• 事件运营——相似故障推荐：基于NLP技术推荐相似故障复盘，挖掘共性问题。

2 事件管理中AI能力总览

AIOps在事件管理领域中的能力框架如下：

3 AIOps之事件管理场景

3.1 事前预防

3.1.1 风险识别

变更检测分成前、中、后三个阶段。变更前风险预警的收益相对较高，因为它能够拦截异常的发生。但由于变更动作尚未发生，变更前检查所能获取到的参考信息少，检测难度比较大。变更中、后检测可以参考灰度组的变化情况以及是否有异常指标的出现，检测的参考信息更多，准确度更高。我们和MCM-线上变更管理平台（美团变更管控系统，后文简称MCM）合作，共同探索了对变更前、变更中和变更后的一些异常进行检测与识别。

变更前

配置变更风险的检测和识别。当用户进行配置变更时，我们会进行配置项变更风险检查。我们根据该配置项的历史合法变更数据挖掘出该配置项的约束规则，对当前变更值进行风险检测。约束项包括结构文本合法性、分隔符合法性、前后结构一致性等风险规则。

变更中/后

当灰度变更时部分系统指标会变化，比如集群中灰度机器的QPS、4XX、5XX指标可能会因为变更发生变化。系统需要识别出因为错误变更而导致的异常，屏蔽灰度变更影响导致的异常。

我们需要注意，如果直接采用全量未变更分组进行参考组对待检测组进行异常识别，会有一些干扰和噪声。同一个集群的机器会由于自身配置、承载流量任务等差异，其机器指标会产生出不同的分布和聚类情况。将实际差异较大的机器指标作为参考组，会干扰异常检测的结果。因此，我们需要筛选出和待检测指标相近的数据作为参考组，再在类内距离较近的多指标数据中识别出该指标是否符合正常模式。

以灰度变更组的数据为待检测数据点，以未变更组时序数据、变更历史时序数据作为参考组进行异常识别。算法思路如下：

1. 剔除参考数据的离群序列：找到和检测数据相近的参考组，再做异常检测。我们使用优化后的自适应DBSCAN^[1]进行聚类，排除参考组的离群时序序列。
2. 检测待检测数据是否异常：识别待检测的时序数据在参考组中是否存在异常情况，包括点异常、上下文异常、子序列模式异常等异常特征。

该功能已经上线到MCM，用于某核心平台系统集群变化后的变更复检。检测效果效果如下：

当用户进行集群变更时，会触发集群维度和机器维度的变更检查，识别核心指标（QPS、4XX、5XX）是否有一些异常。当指标中存在异常时，指标数据详细展示区会有额外展示：

• 异常点标记线：检测异常的时间点上会有红色的竖线标记。
• 异常项详细展示区：详细展示出检测到异常的服务器主机名、时间点、指标值、与比对基线的偏离情况。
• 标记误报按钮：如果发现异常为误报，可以点击按钮进行标记，便于后期算法复盘优化。

3.2 事中快恢

当故障事件发生后，需要尽可能降低服务的异常对其他用户的影响，提升服务的可用性。可以从MTTD（平均检测时间）、MTTT（最短定位时间）、MTTR（平均修复时间）这三个指标入手。

3.2.1 异常发现

故障发现需要快速、准确。为避免误报，服务运维团队开发了一种基于历史上邻近的点分布相似（时序特征相似）思想的智能异常检测算法。如果当前待检测点相较其他历史参考点相对异常（存在点异常或者模式异常），检测流程会将异常点识别出来，并告知用户待测指标出现异常现象。

在进行实时检测流程中，待检测点会先进入预检测流程。预检测组件会拦截绝大多数正常点，而当预检测异常时，才会执行特征提取阶段，进入模型异常分类；同时分类结果通过反馈机制可以增加到样本集，提高模型泛化能力和精召率。整个算法流程训练、检测、反馈闭环。

该项能力为美团监控系统提供无阈值的时序检测能力。目前检测流程中的分类器在真实线上样本的精确率和召回率均在98%以上。团队会每周定时抽样核心指标并对检测结果进行复盘，核心指标的异常检出准确率在90%左右。

3.2.2 根因诊断

在事件处理阶段，事件根因的自动定位可以大幅度降低定位时间（MTTT），帮助用户快速处理事件。由于美团现有系统规模极其庞大且复杂，因此不能用一种简单的定位方式来涵盖所有的错误根因。我们从多个方面来定位故障根因，包括链路异常、日志堆栈异常、服务异常等故障场景。这里我们将从两个方面来探讨根因定位的探索和实践。

异常链路拓展

雷达系统是美团的统一的事件管理平台，用于高效处理告警、事件和故障，同时也提供对公司内微服务系统的根因定位能力（后文简称为雷达）。识别微服务系统中的故障链路是重要且具有挑战性的工作，根据服务的调用情况构建服务调用图，并通过异常检测进行扩展和剪枝，以获得准确的异常链路图。拓扑图过大或过小都不利于根因定位。链路异常检测工作有如下要求：

1. 实时性高：由于服务调用实时变化，异常计算工作不能过于耗时，过长的滞后结果将会导致拓扑图更新的延迟，异常检测没有价值。
2. 计算量大：美团每分钟产生几十万级别的链路数据，并且每一种链路数据都包含调用次数、TP耗时等关键指标。
3. 精召率高：我们需要准确识别出当前链路是否存在异常，精准识别可以防止拓扑爆炸或者根因节点缺失。

为了解决以上问题，我们和数据库平台研发组合作，研发了一套基于预训练的大容量异常检测服务来进行链路异常检测，其具有大容量，低时延，准确率高的特点。算法使用了历史长时序来挖掘时序特征参数，并在实时检测中参考临近120分钟进行了波动过滤，可以在较短的时间内快速识别指标的异常程度，实现了每分钟百万级别的异常检测。整体检测的平均流程耗时在1.5-3ms，检测的异常点精确率在81%，异常点召回率在82%，F1值为81%。

我们使用编排好的训练流程对单指标进行单模型参数建模，存放到离线模型数据库中。在实时检测过程中从数据库中加载对应的预训练参数，根据检测流程进行实时监测。

该工作的核心思想是：将大量的复杂的计算异步化，在实时流检测的过程中，大幅度降低实时浮点计算量，提高整体的计算容量。该项工作对接了雷达链路中的流量和TP线的识别，支持雷达在故障诊断的过程中，获取异常节点与邻接节点之间的调用量、耗时的波动，来获取准确的故障全景图，并获取节点间调用异常的准确情况。

异常拓扑图效果如下图所示，雷达链路的拓展根据流量异常、失败率上涨、耗时等多个方面进行拓展，可以有效地找到核心故障链路图：

指标多维度根因定位

大盘有一部分是多维度的指标，由于其业务特性比较强，这些指标波动很难用通用系统指标进行异常定位。我们目前探索了从指标自身维度的异常特征来进行异常维度定位的工作。

总的KPI指标异常，需要处理人员人工下钻到不同维度分析。如果指标的维度较多，人工分析成本巨大。该项工作的困难和挑战有以下两个方面。 - 首先，不同的组合的KPI是相互依赖和影响的，真正的根因元素的KPI异常，可导致其他维度的KPI也发生变化，很难对KPI指标的根因做一个量化的判断。 - 其次，由于KPI拥有多维度的属性，因此随着维度的增加或粒度的细化，元素的数目往往呈现指数级增长的趋势，可能需要从成千上万的多维属性空间进行搜索；此外，对如此多的维度快速做预测也是一个挑战。

在算法的应用场景中，我们需要考虑算法的可落地性。什么时候触发、如何提升结果的准确度、有效性是我们需要解决的问题。

上图是我们执行异常维度定位的简易流程，我们在Squeeze²的基础上针对美团业务特性做了优化， 其具有以下特点：

1. 自动化框定检测时间范围：使用变点检测等算法自动框定时间区间，用户无需人工框定所需要的检测时间区间即可自动化的进行异常维度定位操作，并且该项工作提高了下钻的性能和准确度。
2. 多时间戳下钻，定位结果汇总：为了减少因为单点抖动而产生的错误下钻，提高算法的精确度，通过多时间戳的方式并行下钻分析，然后根据各个指标的不同特征，区分汇总结果，提高结果的可用性。
3. 裁剪非关键根因，减少干扰维度的影响：对于最后的根因维度，会计算每一个子维度的整体重要占比，裁剪非重要根因，减少无意义维度带来的干扰。将下钻的根因编码解析，提高定位结果的可读性。

结果展示

当核心大盘指标出现异常时，系统就会自动触发下钻分析，将异常维度的分析结果推送到群里，帮助用户快速定位该指标的异常维度是什么。

3.2.3 相似事件推荐

雷达系统中经常出现相似事件，它们往往有着相似的根因，如同一个业务的促销活动、某个中间件故障等。如果我们能够根据当前事件的异常现象，找到历史上最相似的一些Case推荐给处理人，则能为事件的定位和处理提供参考，提高处理效率。我们实现了一套相似事件推荐算法，通过NLP技术和规则过滤，找到每个事件的Top历史相似事件并推荐给处理人。算法的整体流程如下：

整体而言，算法在离线阶段使用NLP技术，将每个历史雷达事件进行向量化并存储；在实时推荐时，算法将新的雷达事件进行向量化后，通过向量相似度搜索到最接近的历史事件，并通过一些规则计算的特征进行排序和过滤，得到最终可推荐给用户的Top相似事件。下面对一些实现细节进行介绍。

离线训练阶段

1）数据类型区分

一个雷达事件中包含的数据可以分为两种类型：结构化数据和文本数据。它们主要的区别如下：

如上表所示，这两类数据的特点和作用有着很大的不同，且它们的可重复度也不一样。如果我们把两类数据都放到一个语料库中去训练一个向量化模型，会导致在后续的实时推荐阶段中，对于文本数据较多的事件产生“不公平”的现象：由于用户生成的文本数据的可重复度低，它们之间的相似度“天花板”会远低于结构化类型的数据，这就意味着一个事件的群聊越丰富，就越不容易找到相似的事件，这不符合我们的预期。

所以我们针对这两类数据分别构建语料库，通过文本向量化算法分别得到两个向量集，以便后续做更精细化的控制。

2）分词&向量化

分词（tokenization）是将文档分解为以字词为单位的基本要素，方便后续处理。对于雷达事件中的文本类型数据，需要采用分词器进行分词，并去除停用词后得到tokens（即分词后的词语列表）；对于结构化字段，则直接提取属性值或通过一些规则处理得到tokens。

为提升文本分词效果，预先加载了IT领域词库、公司Appkey列表、公共服务名称作为分词器的词库。经过分词后，对事件进行词频统计，再通过Tfidf算法计算各词语的权重。Tfidf算法得到的向量长度等于词库的大小，向量第i个位置上的值表示词库中第i个词在事件中的权重，计算方式会综合考虑词语在当前事件的出现次数和在历史所有事件中的出现次数：

$$ 词i权重\approx\frac{词i在当前事件中的出现次数}{词i在多少个历史事件中出现} $$

一个词语在当前事件中出现得越多，且在越少的历史事件中出现过，说明它是一个比较关键的词语，Tfidf算法将给予它比较大的权重。

注意，以上公式只是概念化表示，不是Tfidf算法的实际公式，对于Tfidf算法的具体实现感兴趣的读者可自行搜索了解。我们对事件的结构化数据和文本数据分别经过以上步骤进行处理，每个事件将被用两个Tfidf向量表征并存储起来，用于后续在实时推荐阶段计算事件相似度。

实时推荐阶段

1）基于向量相似度召回候选事件

在实时推荐阶段，我们同样将新的雷达事件分为结构化和文本类型数据，分别进行分词并向量化。然后，我们计算它们与历史事件向量的相似度，得到结构化和文本数据与所有历史事件的相似度。我们设定不同的阈值来召回候选的历史相似事件，在实践中，设定的文本数据相似度阈值要低于结构化数据的相似度。两类数据召回的相似事件取并集，作为候选的相似事件列表，它们是与当前事件具有一定相似度的历史事件，量级在1000个以下。

2）基于规则计算特征进行排序

一个历史事件是否值得推荐给用户，除了与当前事件的相似度之外，还需要考虑更多的维度，例如事件本身是否具有足够的文本内容可以参考，以及距离当前事件的时间是否比较接近。为了使值得推荐的事件被展现给用户，我们对每个候选事件通过规则计算一系列特征，用于后续的排序：

• 文本丰富度：衡量历史事件的内容质量，其中群聊、通告、反馈等文本数据较丰富的，能够提供更多关于处理、定位过程的信息，为当前事件的处理提供更多参考。
• 时效性：衡量历史事件发生时间与当前事件的距离，越临近当前事件发生时间的历史事件，参考价值越大。
• 根因匹配度：判断历史事件诊断根因是否与当前事件诊断根因一致，如果一致那么很有可能背后是同一个原因导致的问题。
• 告警匹配度：衡量两个事件告警列表的相似程度，计算过程中会降低通用兜底类告警的权重，提高具有明确业务含义告警的权重。

以上特征，再加上召回阶段已经计算好的结构化数据、文本数据相似度，进行加权求和，得到最终的推荐得分，用于对候选事件进行排序。我们还需要对其进行过滤，去除不希望推荐给用户的历史事件。过滤的依据主要包括：对于系统发现事件，告警匹配度需要足够大，对于人为发现事件，推荐的历史事件的文本内容需要足够丰富。

3）关键信息提取&用户展示

为了使用户能够更快速地从历史事件中获取有效信息输入，我们从每个待推荐的历史事件提取出关键信息，包括由用户反馈的历史事件的根因、解决方案等信息，把这些附在推荐项上，在事件处理过程中推送到群里，辅助用户提高事件处理效率。同时，在Web端页面也会展示Top相似事件列表，以供用户参考。

案例展示：

该功能上线后，有相似事件的Case覆盖率为70%左右，对于系统发现且有推荐历史相似事件的Case，其平均故障处理时长比无相似事件的Case缩短28%。为了评估推荐的准确率，我们对有推荐相似事件处理经验且用户反馈了真实根因的Case进行了人工复盘，若推荐的历史事件与当前事件有类似的根因或解决方案，则标记为推荐准确，由此统计得到的推荐准确率约为76%。

在复盘过程中，我们发现，推荐的准确率很大程度上取决于用户所配置的告警质量，对于粒度较粗的通用兜底类告警（如域名5xx告警）所产生的事件，推荐准确率会低于细粒度的、具有明确业务含义的告警所产生的事件。原因也是显然的：粗粒度的告警背后的根因可能千差万别，所以即使一个历史事件有着同样的告警，也会有很大可能不是同一个根因导致的故障；而细粒度的告警则与之相反。

在后续的优化中，对于相似事件的排序策略，我们可能需要根据事件中告警的粒度，来调整不同告警类型对于相似度的贡献大小，而告警的粒度如何衡量，则需要结合公司具体的现状和我们的经验判断。总而言之，在数据驱动的算法之外，需要结合一些专家知识来弥补数据的不足，从而使算法的输出更好地服务于用户。

3.3 事后运营

在故障事后，用户对于故障的运营和复盘有利于经验沉淀，避免相同的问题再次发生，对于稳定性的长期提升有着重要作用。

COE（Correction Of Error）是美团的故障复盘系统，以文本形式记录了公司大量的历史故障复盘内容。我们在COE系统中基于主题分析等NLP技术，实现了故障复盘的主题展示和相似推荐能力，旨在帮助用户找到更多相似的故障，挖掘出共性问题。目前该功能处于初期建设阶段，正在迭代和探索的过程中。

4 总结和未来展望

本文简单介绍了团队在AIOps在事件管理这一领域的探索和实践。我们从三个关键的运维阶段——事前预防、事中处理以及事后运营，深入探讨AIOps在这些场景中的具体应用和优势。

之后我们也会从多个方面进一步探索AIOps在美团场景下的可能性。这里我们简单列举了几个可能且有价值的发展方向。

智能日志检测

日志异常检测通常由四个模块组成，包括日志收集上报、日志解析、特征提取以及异常检测器。我们期望通过提取日志的计数、序列、语义等特征，来动态识别当前服务的日志是否存在异常情况，

我们计划从两个方面进行探索：

• 日志模版时序异常：通过Drain3等日志模版挖掘技术，将服务日志转化成日志模版时序。基于时序异常检测算法，可以识别日志模版徒增、异常日志出现等风险点。
• 日志模版语义异常：通过解析日志模版的语义特征，结合机器学习和深度学习算法，识别当前日志是否存在语义异常。

智能化变更识别

对于配置类型的变更（如：分布式内存配置变更、营销活动配置变更等），一旦变更人员疏忽填写错误或遗漏，会导致线上问题。同时，这类配置可能数量极其庞大，我们需要去动态分析识别每一配置对应的模型信息。

对于历史上正常完结没有回滚的配置变更，根据其变更值进行特征提取，学习该配置的Key、Value变化规律，从统计学、数据建模等多个角度构造每个配置值的特征组。当新变更到来时，就转化成了特征相似匹配，从而发现人工填写错误的问题。

5 本文作者

政东、迎港、张霖、俊峰等，均来自美团基础研发平台。

6 参考文献

• [1] Ester M, Kriegel H P, Sander J, et al. A Density-Based Algorithm for Discovering Clusters in Large Spatial Databases with Noise. AAAI Press. 1996.
• [2] Li Z, Pei D, Luo C, et al. Generic and Robust Localization of Multi-dimensional Root Causes. 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE), IEEE. 2019.
• [3] He P, Zhu J, Zheng Z, et al. Drain: An Online Log Parsing Approach with Fixed Depth Tree. 2017 IEEE International Conference on Web Services (ICWS), IEEE. 2017.
• [4] M Du, F Li. Spell: Streaming Parsing of System Event Logs. 2016 IEEE 16th International Conference on Data Mining (ICDM). 2016.
• [5] IBM. Drain3. https://github.com/IBM/Drain3
• [6] Akiko A. An information-theoretic perspective of tf–idf measures. Information Processing and Management. 2003.
• [7] David B, Andrew Ng, Michael J. Latent Dirichlet Allocation. Journal of Machine Learning Research. 2003.
• [8] 曹臻, 威远. 基于AI算法的数据库异常监测系统的设计与实现. https://tech.meituan.com/2022/09/01/database-monitoring-based-on-ai.html

7 招聘信息

基础技术部-服务运维部-故障管理开发组主要负责故障发现、故障定位、故障恢复、故障运营、告警中心、风险管理、数据仓库等工作。目前团队诚招高级工程师、技术专家。欢迎有兴趣的同学投送简历至 [email protected]。（邮件主题注明：运维工具）