运维工程师在数据挖掘方面的“三大痛点”，看完有共鸣了

本文根据必示科技算法总监隋楷心在2020国际AIOps挑战赛的主题演讲整理而成，重点介绍了必示科技在INFOCOM 2020 、ICSE SEIP 2020、ESEC/FSE 2020发表的三篇论文成果以及核心方法，为业界在告警数据挖掘方向的研究提供新思路。

首先介绍下背景，从大型互联网公司过去一年遇到的服务故障可以看到，服务故障对企业效益和用户体验造成了非常大的影响。比如，亚马逊2018年Prime Day活动，1小时宕机时间就引发了约1亿美元的损失。

目前很多工作在关注运维领域的服务质量保证和可靠性提升，但由于大规模软件服务的复杂性，故障总不可避免。

告警数据挖掘的方向及痛点

为了保证软件服务质量和用户体验、减少经济损失，故障智能分析至关重要，主要聚焦在三个方向：

• 故障发现，即如何及时、准确发现故障；
• 故障诊断，即如何快速、准确诊断出故障的根因；
• 故障预测，即如何提前预警故障，规避故障。

对已有的监控告警数据进行智能分析，即告警数据挖掘在故障智能分析中，能够起到什么作用、解决什么痛点？

我们发现，在故障发现领域，告警定级策略不合理会影响故障发现的时效性；故障诊断过程中，运维工程师通常遇到的告警风暴会严重影响诊断的效率；在故障预测方面，告警信息在故障引发业务损失之前就已经有了大量的征兆，这说明，告警中的隐患信号未被有效捕捉，故障预警非常困难。

对此，我们提出了相应的告警数据挖掘的方法：

自适应的告警动态定级；
告警风暴摘要；
基于告警的事件预测。

下面，我针对痛点问题进行具体讲解：

01

告警定级策略不合理，影响故障发现时效性

告警和故障发现，通常是两个步骤。第一步异常检测，检测到异常后，通过第二步聚合和定级策略产生告警信号。告警信号是运维工程师发现故障、处理故障、介入故障的重要来源。

由于软件服务规模越来越大、复杂性越来越高，故障发生时往往会产生大量告警。在大量告警发生时，运维工程师陷入了困惑：哪个告警最严重？应该先看哪个告警？经验丰富的运维工程师可以抽丝剥茧，一下命中肯綮，但更多时候呈现出一团乱麻的状态。

举个实际案例，曾有金融客户在早上10点45分通过用户电话报障发现故障，但在10点45分之前就已有一些与故障相关的告警，比如说响应时间上升到500ms。不过由于人工设置的阈值导致告警级别不够高，并没有引起工程师的注意。

不准确的告警定级方式会导致严重告警的漏报，工程师排障时也会花费很多时间去处理没有意义的非严重告警。这表明，准确的告警定级算法有助于及时的故障发现。

02

告警风暴影响故障诊断的效率

这是运维人都会遇到的痛点。软件架构复杂化，业务拓扑之间的关系都会导致告警。一个系统引发告警，很多系统会随之呈现风暴式告警。软件架构如此，硬件拓扑网络也是如此。如果底层路由器会引发问题，整个硬件从底到上都会传导告警，形成告警风暴。

需要注意的是，服务故障和告警风暴产生时，应用架构有很多组件，且每个组件都有自己的监控数据，会产生相应的告警。同时，硬件拓扑和软件会发生复杂依赖关系，导致这些告警和故障之间会不断传导。

处于告警风暴情况下，运维管理员的难题在于：到底发生了什么事、哪些告警跟故障相关、告警风暴的核心内容是什么。如果手工检查所有的告警，不仅耗时、耗力，还容易出错。

03

告警的隐患信号未被有效捕捉，故障预警困难

学术界现有的故障预测方法有一些限制。在第一届挑战赛时，我曾跟大家介绍过在微软做的利用磁盘SMART数据做磁盘故障预测的论文。后来，我们实验室也用交换机日志做交换机故障预测，用节点性能指标做节点故障预测，还用工业设备日志去做设备故障预测。

但是，大多数方法专门为一种故障设计，比如磁盘故障、节点故障、交换机故障等，不具备泛化性。同时，这些方法大多是利用指标和日志数据来提取有预测作用的征兆特征，训练开销非常大。此外，我们希望用轻量级的告警数据来做事件预测，但已有的一些方法仅仅考虑了每类告警的数量作为特征，实际表现并不理想。

以上是学术界的情况，但是工业界也没有用告警数据做故障预测的有效方案。

首先，我们常常听到，大家会基于专家知识和运维经验，去总结事件预测的规则。比如当线上的告警满足规则，就认为要发生相应的事件。不过，基于规则的预测方法，在实际中经常会出现误报、漏报。我们分析其原因在于：维护和制定规则需要足够的运维经验，且耗费时间；不同工程师制定规则的偏好不一样，很难有统一的标准；服务系统总是会经历不停的迭代变更，固定的规则很难适应动态的环境。

其次，基于频繁项集挖掘去做探索，我们认为经常一起出现的告警会有一些征兆表现，而实际落地尝试中，金融行业工程师反馈这类方法覆盖面比较小。由于告警数据的复杂性和告警内容中混杂的参数，大多数事件都没有对应的频繁项告警，所以这类方法在金融数据中心可用性并不高。