算法落地思考：如何让智能运维更智能

嘉宾 | 王鹏整理人 | 西狩xs

出品 | CSDN云原生

AIOps是人工智能与运维的结合，能够基于已有的运维数据，利用人工智能算法，通过机器学习的方式帮助企业提升运维效率，解决自动化运维无法管理的问题。

2022年8月30日，在CSDN云原生系列在线峰会第16期“AIOps峰会”上，复旦大学计算机科学技术学院教授、擎创科技首席数据科学家王鹏深入阐述了智能运维的现状，全面分析了智能运维在算法落地时遇到的问题，分享了他在智能运维方向中算法落地的探索与尝试。

智能运维的现状

当前有众多学者对智能问答系统进行研究，提出了诸多算法和技术，在Google Scholar中，与智能问答系统相关的词条高达35万，但智能问答系统在实际生活中的效果却差强人意，并不是真正的“智能”。

近些年来，智能运维算法一直在快速地发展迭代，随着智能运维研究成果和应用场景的不断落地，算法效果也在不断提升。

指标异常检测

指标异常检测是当前落地最多的智能运维场景，该场景下数据容易准备、效果容易验证。对某个指标的某个时间序列进行标注后，很容易看出哪些异常没有被捕获，以及捕获了哪些不应该捕获的异常。

针对指标的异常检测，研究者们提出了大量异常检测算法，包括单指标异常算法、多指标的异常检测算法、基于统计或深度学习的异常检测算法以及有监督、无监督的异常检测算法。

但在实际落地过程中，指标异常检测的效果往往不尽如人意。主要问题如下：

1、误报太多

阈值设置紧，为了消除漏报，造成了大量的误报；
异常数量多，运维人员难处理，不得不忽略所有的指标异常告警。

2、模型/参数难以设置

不同类型的指标，其波动情况、周期性、变化情况不同，所适合的模型和参数也不同；
无法单独为指标设置模型和参数。

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

缺乏问题发现能力，难以对指标异常进行类型、主机、时间段等方面的展示和分析，难以对异常进行交互式探索，无法判断异常是否应该报告；
缺乏基于反馈的模型调整能力，难以应对“这个不是异常，后续检测中不要再报了”的个性化需求。

日志/告警智能分析

当前，大量企业上线了日志实时聚类和基于日志的异常检测，以解决大规模日志无法靠人工处理、基于规则的方法维护性差等问题，但在日志智能分析实践过程中，同样存在若干问题。

1、模板质量难以有效的评估

模板数量非常大，若逐个进行人工判断耗时太长；
不同的应用目标对模板的要求不同，如下图所示，左侧是两条进程消失的告警数据，二者除进程名以外完全一样，应该被合并；而右边的Android日志则需要进行主观判断确定是否需要合并。因此，除选择模板外，模板还与后续应用场景有关系，不能一概而论。

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

缺乏基于反馈的模板调整能力，难以应对“这种模板应该根据这个变量拆分”、“这个变量应该被泛化”之类的个性化需求；
运维专家和算法人员之间的沟通困难，在真实场景中，运维专家与算法团队被实施团队隔离开，反馈链条长，二者沟通不顺畅。

3、根因定位效果欠佳

CMDB质量普遍不高，可能存在系统变更但CMDB无法及时反映最新场景的情况；
真正的故障原因可能不存在告警数据中，无法进行根因分析。

问题分析

从指标异常检测和日志/告警的智能分析两个典型算法场景可以看出，算法在真实运维场景中依然存在着各种各样的问题。

原因1：发现问题困难

发现问题困难是指由算法得出结果的正确性难以判断。

1、算法需要定制化。通用算法只有在定制化之后才能应用在具体场景中，其需要与运维数据、业务特点、运维目标等进行深度融合。因此，算法结果的评判带有一定的主观色彩，无法通过客观因素来衡量。

2、被监测对象的规模非常庞大。算法可能需要监控十万、百万以上的指标，此外，需要监测的日志或告警数据规模也十分庞大，这使得我们难以通过重跑算法对效果进行验证。

3、实施过程中运维专家和算法人员的脱离。运维专家与算法人员之间沟通不畅，会使得标签数据的获取较为困难，难以通过反馈衡量算法效果，进而影响算法的迭代优化。

原因2：解决问题困难

即使发现了上述问题，但想要从算法和训练层面对其进行解决依旧困难重重。

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

2、算法调参困难。异常检测场景下，不同指标适合的模型与参数不同，难以为每个指标都找到最佳模型与参数。此外，“指标规模×模型个数×参数取值个数”所构成的搜索空间巨大，操作实施困难。

误区1：论文中的算法Vs.真实场景需要的算法

学术领域当前有大量关于异常检测的论文，异常检测在学术方面已被研究得非常充分，但这并不代表其能够在实际场景中得到良好运用。以日志模板提取为例，下图列举了一些离线、在线的日志模板提取算法。

这些算法在真实场景中的应用包括两个过程：POC过程和生产环境。根据在线、离线的差异，POC过程可以分为两类：

根据离线数据寻找合适的模板，再基于日志模板进行异常检测；
通过Kafka消费生产环境或测试环境的数据，在线实时处理。

真实生产环境中，数据规模庞大，可以根据一定时间范围内的数据训练模板，确定模板后再进行线上数据的处理。

可以看出，更为合理的日志提取算法应该是：

小批量测试数据上的离线算法；
基于模板集合接上流式数据上的在线算法。

离线和在线算法只是智能运维过程的一部分，此外还需继续完善模板并提供定制化的算法，如长日志模板提取算法、多行日志模板提取算法、特殊日志模板提取算法、反馈算法及参数自动设置算法等。

对于长日志而言，现有算法的普遍处理方法是截取其前面固定长度的词进行分析，显然这可能存在误差。对于多行日志、特殊日志的模板提取，目前的研究并不充分。此外，反馈算法、参数自动设置算法等也比较少。

因此，学术领域中对算法研究的充分程度与真实场景中算法的使用程度之间并不能完全划等号。

误区2：“完全依靠算法实现自动化运维”现实吗？

自动化运维有可能被实现，但仍需要较长时间去探索，更为现实的目标是将算法作为一种辅助手段，让运维更加高效。

在大数据量场景下，用算法提高效率。
算法可以用来提高算法的易用性。
算法可以作为一种定位故障过程的辅助手段，灵活快速地查询和探索数据。
算法作为一种积累知识的方式，构建知识图谱。

智能运维三要素

算法能够落地需要三个要素：算法设计能力、运维场景的理解能力和平台的工程化能力。

算法设计能力。客户的需求是个性化的，需要根据客户的需求设计针对性的算法，此外还需通过反复调参实现数据的个性化。
运维场景的理解能力。算法只是手段，运维才是最终的目标，算法必须结合运维场景，只有深入研究并理解运维场景，才能发挥出算法的效用。
平台的工程化能力。针对目前海量的数据环境，大规模的运维数据处理需要高效稳定的数据平台，此外还要同算法进行高效的结合，提高平台的数据处理分析能力。

探索工作

异常检测

除异常检测算法外，我们目前还在算法和参数推荐、基于可视化的算法选择以及相似异常查询方面做出探索。

1、算法和参数推荐。分别为每一个指标推荐其最适合的算法模型及最优参数，其中涉及每个指标的特征提取，根据特征构建分类树，最后基于分类树匹配各类指标适合的模型。

2、基于可视化的算法选择系统。在该系统中，能够编写类似SQL的查询语言，可以选择要测试的数据集及算法，并强调各个算法的关注维度，如纯性、召回率、性能等。此外，还支持算法效果的可视化，能够清晰地看到不同算法查取异常之间的差异性。

3、相似异常查询。查询工具能够从原始数据中提取出相似的异常，运维专家基于此决定对异常的处理动作。该功能可以促进算法效果反馈效率，运维专家可以批量甄别异常检测情况，无需逐一进行甄别和反馈。

告警精细化管理

在做告警场景之前，会将告警模板区分成不同类型，包括高频事件、周期性事件、新增事件和阶段性事件等。

高频告警是在不同时期都会发生的告警事件，可能由于阈值太严导致，在处理中可以对此类告警进行调整或删除。
周期性告警是在固定周期内发生的告警事件，这种情况的背后可能蕴含了某些问题，值得被关注。
新增告警和阶段性告警是某个时间点开始或结束的告警事件，可以结合业务具体分析。

因此，业务理解及数据的深层次析对于智能运维至关重要。

数据探索工具

在智能运维的探索过程中，数据管理和数据处理的工具必不可少。作为辅助手段的数据探索工具，能够让运维人员也可以灵活地分析数据，进而辅助算法的优化和落地。

1、基于拖拽式的分析流程实现

该流程主要面对实施人员和运维专家，两者可以根据“拖拉拽”的方式，结合不同分析算法搭建分析流程。同时，该流程融合了异常检测、聚类、场景挖掘等多种算法，并支持输入数据格式的智能化学习。

2、基于自然语言的问答系统

在问题出现时，运维人员多会进行假设和判断，该过程需要使用查询工具进行排查和定位。虽然当前有诸多工具能够提供基于SQL、ES的查询，但如果可以基于自然语言进行查询，运维人员就能更方便地进行个性化数据探索。

3、面向时间关联的复杂查询处理系统

如下图所示的HDFS日志示例，当我们想查询其中三个模板是否经常一起出现时，SQL查询较为复杂，PLQ查询更加简洁高效，

4、异构数据的统一查询系统

该系统融合了时间序列、文本序列、CMDB图数据及调用链图数据，实现四种类型数据的统一查询。

总结

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

本篇文章整理来自@ 西狩xs，由CSDN修订完成。