算法落地探究：智能运维远没有说得“智能” - 运维 - dbaplus社群：围绕Data、Blockchai...

算法落地探究：智能运维远没有说得“智能”

分享概要

一、智能运维现状

二、问题分析

三、探索工作

一、智能运维现状

大家对智能问答系统都很熟悉，目前许多APP都有智能问答系统——后台是一个机器人，而不是真正的人回答问题。当前众多研究者在对智能问答系统进行研究，提出了许多算法和技术，Google Scholar上关于智能问答系统的文章有30多万不到35万篇。但实际上，智能问答系统远没有达到真正的智能，回答的结果时常是答非所问，那么就会造成海量的算法和技术与差强人意的效果之间的偏差。

智能运维到现在大概有六七年的发展历程，在此期间智能运维算法一直在快速地发展，包括对性能指标的时间序列的数据、对日志告警的数据以及近两年对CMDB、调用链等图的数据。算法的类型和效果也在不断提升，包括指标异常检测、容量预测、日志聚类、日志日常检测、告警中的场景挖掘、根因定位等。接下来的内容主要涉及指标异常检测、日志智能分析、告警数据分析三个类别。

1、指标异常检测

指标异常检测是一个落地最多的智能运维场景，因为它数据容易准备，效果容易验证，准确率、召回率的指标容易量化。目前许多公司对大规模指标进行异常检测，比如1万个指标、10万个指标。

针对指标的异常检测，研究者提出了大量的异常检测算法，比如单指标、多指标检测，基于统计、基于深度学习的模型，无监督、有监督的算法，以及近两年许多公司和机构开源了异常检测数据集和算法。但是，往往在落地的场景中应用的效果不尽如人意，主要问题如下：

1）误报太多

• 设置阈值严，为了消除漏报，往往造成大量的误报

• 异常数量多，运维人员难以处理，不得不忽略所有的指标异常告警

2）模型/参数难以设置

• 不同类型的指标，往往适合不同类型的模型和参数

• 无法单独设置模型和参数，进行分类则效果不佳

3）缺乏有效的反馈和修正机制

• 缺乏问题发现能力，难以对指标异常进行类型、主机、时间段、业务等方面的展示和分析，难以对异常进行交互式探索，因此无法判断异常是否应该报

• 缺乏基于反馈的模型调整能力，难以应对“这个不是我们认为的异常，后续检测中不要再报了”的个性化需求

2、日志智能分析

目前，大量企业上线了日志实时聚类和基于日志的异常检测，主要解决了人工难以处理海量日志数据、基于规则的方法维护性差的问题。典型场景对海量日志做实时聚类，再做基于日志的异常检测，比如变量取值异常、模板数量异常、语义异常等，但日志智能分析实践同样存在若干问题。

1）模板质量难以有效评估

• 日志聚类完之后，在将其聚到若干模板中时，模板质量难以有效评估，尤其是在实施过程或上线过程中，模板数量大，逐个人工判断耗时太长，可能运维人员没有充足的时间逐个人工判断

• 不同的应用目标对模板的要求不同，可能做某类型的日志异常检测时该模板不应该被泛化，但做另外一件事情可能就需要泛化，模板是否需要被泛化是一件非常主观的事情

2）缺乏有效的反馈和修正机制

• 缺乏基于反馈的模板调整能力，难以应对“这种模板应该根据这个变量拆分”、“这个变量应该被泛化”之类的个性化需求

• 运维专家和算法人员的沟通难，运维专家与算法团队之间隔着实施团队，反馈链条长，且不是直接反馈

3、告警数据分析

近年来告警相关项目快速增长，每天有成千上万的告警，由于告警数量太多，运维人员难以有效处理和派单，因此通过算法进行告警压缩、场景挖掘、根因定位越来越受重视。在告警智能处理中存在两个典型问题：

1）告警模板提取效果不佳

• 告警数据更为灵活多变，不同运维人员的告警描述方式存在差异

• 包含大量中文，告警模板提取效果不尽如人意

2）根因定位效果欠佳

• CMDB质量有待提高，可能存在系统变更但CMDB没有及时变更到最新场景的情况

• 可能真正的故障原因不存在于告警数据中，无法进行根因定位

• 标签数据缺失，一方面故障数量少，另一方面企业由于涉及隐私等原因不愿意给予标签

二、问题分析

我们在前面对于智能运维的现状和具体的类别及相关问题进行了梳理，那么接下来是我个人的一些思考。我认为算法落地效果不尽如人意有两个深层次原因：

1、算法需要不断迭代优化

我们时常认为智能运维的算法是开箱即用，但其实效果远不是如此，算法需要不断迭代优化。算法最开始的时候一般是一个通用算法，到具体在企业部署之后，它一定会成为一个定制化的算法。因为对于每一个具体的项目，算法需要和运维数据、业务特点、运维目标等深度融合，需要不断进行打磨和适配。

1）算法本身：普遍缺乏反馈修正能力

对于“这个异常我不需要，后续检测中不要再报了”、“这两个模板应该合并掉，变量不能被泛化”之类的反馈，当前的模型尤其是深度学习模型很难有效吸收，其中主要是两种能力的缺失：

• 发现问题的能力。比如说我们一天报2000个异常，能否有半小时或一小时的时间将这2000个异常过一遍，判断其中哪些异常应该报，哪些不应该报，目前很少有人能够在短时间内做到这点。

• 模型自动修正能力。比如给了很多“这个要报，那个不要报”之类的很多反馈，模型是否能够很好地适应，因为这个适应其实是个百分百的适应，有的可能一个都不要报，有些是一定要报出来，这种对于模型也是比较难的。

2）实施过程：运维专家和算法人员的脱离

对于算法而言，最重要的是标签数据和对算法结果的快速反馈，但是相关领域的专家可能熟悉机理却不熟悉算法，由于沟通链条长、沟通成本高，运维专家和算法人员在一定程度上是脱离的。

2、系统故障本身是超低频事件

系统故障本身是一个超低频的事件，严重的故障基本可能只出现一次，并且会被快速解决，不可能再出现。而算法需要基于历史数据学规律进行优化提升，如果之前发现的故障后来很可能不再出现了，那么这其实是一个悖论。

我们前面也有提到完全依靠算法来实现自动化运维，至少在目前阶段我觉得其实是不现实的，我们仅仅做异常检测、日期类都没有做得非常的好，那么我们相信现在算法能达到自动化运维吗？我觉得更现实的目标是将算法作为一种让运维更高效的辅助手段。

1）数据量太大，用算法来提高效率。

• 对每天几百TB的日志自动提取模板和变量

• 对上万的指标自动进行异常检测

2）在某些场景下，用算法来提高精度。

因为在因果推断里有些链条比较长，需要考虑的方面比较多，人的思考其实并没有那么发达，所以算法在这些方面是可以帮助提高精度的。

3）作为一种定位故障过程的辅助手段，帮助运维人员灵活快速地查询和探索数据。

这是一种非常重要的能力，因为在很多项目里，算法结果的分析工作非常劳累辛苦。

4）算法作为一种积累知识的方式，构建知识图谱。

三、探索工作

1、如何高效地支持反馈

如果只让运维专家给10个异常/10个模板打标签，应该怎么做？

1）快速发现问题的能力

首先可以通过异常置信度、日志模板置信度从2000个异常中选择10个异常，然后通过异常立方体更加系统的能力对异常进行交互式探索，使异常可视化。

2）模型自动修正的能力

当我们希望将一个Excel或CSV的记录人的电话、传真信息的表格变成结构化数据进行处理时，我们可以通过算法进行自动转化。通过我们给的少量样本，算法能够自动识别我们的目标，从而达成这个目标，这就是基于样例的算法。基于样例的算法在智能运维领域中同样大有可为，另外还有一种方法是小样本算法，通过给定少量标签或案例快速达成目标是我们正在进行的尝试。

2、作为辅助手段的数据探索技术

1）基于自然语言的问答系统

人可以问类似以下自然语言的问题，能够自动转成SQL并出结果，具有高易用性，便于运维人员进行个性化数据探索。

• 在2019/11/28 11:25发生突增异常的指标有哪些？

• A应用发生异常次数最多的主机是哪台？

• B应用告警次数最多的告警种类是什么？

• 最近一周内存使用率最高的十台主机是哪些？

• 最近十天发生异常次数最多的应用是什么？

• 最近一周内失败率最高的应用是哪个？

2）基于时间关联的复杂查询

用于事件关联的快速发现,如下图所示的HDFS日志，我们想查询其中三个模板是否经常一起出现，PLQ查询能够更加简洁高效，SQL查询则会更加复杂。

3）基于拖拽式的分析流程实现

• 便于领域专家结合不同分析算法搭建分析流程

• 融合了异常检测、聚类、场景挖掘等多种算法

• 支持不同语言开发的算法

• 支持输入数据格式的智能学习

四、总结

智能运维中的算法正在发挥越来越大的作用，但同时算法落地仍有大量问题需要解决。算法不能一蹴而就，需要有持续优化的能力。不妨将算法作为一种运维的辅助手段，使运维人员也能灵活地分析数据，在运维过程中使其变得更高效。