大家对智能问答系统都很熟悉，目前许多APP都有智能问答系统——后台是一个机器人，而不是真正的人回答问题。当前众多研究者在对智能问答系统进行研究，提出了许多算法和技术，Google Scholar上关于智能问答系统的文章有30多万不到35万篇。但实际上，智能问答系统远没有达到真正的智能，回答的结果时常是答非所问，那么就会造成海量的算法和技术与差强人意的效果之间的偏差。
智能运维到现在大概有六七年的发展历程，在此期间智能运维算法一直在快速地发展，包括对性能指标的时间序列的数据、对日志告警的数据以及近两年对CMDB、调用链等图的数据。算法的类型和效果也在不断提升，包括指标异常检测、容量预测、日志聚类、日志日常检测、告警中的场景挖掘、根因定位等。接下来的内容主要涉及指标异常检测、日志智能分析、告警数据分析三个类别。
指标异常检测是一个落地最多的智能运维场景，因为它数据容易准备，效果容易验证，准确率、召回率的指标容易量化。目前许多公司对大规模指标进行异常检测，比如1万个指标、10万个指标。
针对指标的异常检测，研究者提出了大量的异常检测算法，比如单指标、多指标检测，基于统计、基于深度学习的模型，无监督、有监督的算法，以及近两年许多公司和机构开源了异常检测数据集和算法。但是，往往在落地的场景中应用的效果不尽如人意，主要问题如下：
目前，大量企业上线了日志实时聚类和基于日志的异常检测，主要解决了人工难以处理海量日志数据、基于规则的方法维护性差的问题。典型场景对海量日志做实时聚类，再做基于日志的异常检测，比如变量取值异常、模板数量异常、语义异常等，但日志智能分析实践同样存在若干问题。
近年来告警相关项目快速增长，每天有成千上万的告警，由于告警数量太多，运维人员难以有效处理和派单，因此通过算法进行告警压缩、场景挖掘、根因定位越来越受重视。在告警智能处理中存在两个典型问题：
我们在前面对于智能运维的现状和具体的类别及相关问题进行了梳理，那么接下来是我个人的一些思考。我认为算法落地效果不尽如人意有两个深层次原因：
我们时常认为智能运维的算法是开箱即用，但其实效果远不是如此，算法需要不断迭代优化。算法最开始的时候一般是一个通用算法，到具体在企业部署之后，它一定会成为一个定制化的算法。因为对于每一个具体的项目，算法需要和运维数据、业务特点、运维目标等深度融合，需要不断进行打磨和适配。
对于“这个异常我不需要，后续检测中不要再报了”、“这两个模板应该合并掉，变量不能被泛化”之类的反馈，当前的模型尤其是深度学习模型很难有效吸收，其中主要是两种能力的缺失：
对于算法而言，最重要的是标签数据和对算法结果的快速反馈，但是相关领域的专家可能熟悉机理却不熟悉算法，由于沟通链条长、沟通成本高，运维专家和算法人员在一定程度上是脱离的。
系统故障本身是一个超低频的事件，严重的故障基本可能只出现一次，并且会被快速解决，不可能再出现。而算法需要基于历史数据学规律进行优化提升，如果之前发现的故障后来很可能不再出现了，那么这其实是一个悖论。
我们前面也有提到完全依靠算法来实现自动化运维，至少在目前阶段我觉得其实是不现实的，我们仅仅做异常检测、日期类都没有做得非常的好，那么我们相信现在算法能达到自动化运维吗？我觉得更现实的目标是将算法作为一种让运维更高效的辅助手段。
因为在因果推断里有些链条比较长，需要考虑的方面比较多，人的思考其实并没有那么发达，所以算法在这些方面是可以帮助提高精度的。
这是一种非常重要的能力，因为在很多项目里，算法结果的分析工作非常劳累辛苦。
如果只让运维专家给10个异常/10个模板打标签，应该怎么做？
首先可以通过异常置信度、日志模板置信度从2000个异常中选择10个异常，然后通过异常立方体更加系统的能力对异常进行交互式探索，使异常可视化。
当我们希望将一个Excel或CSV的记录人的电话、传真信息的表格变成结构化数据进行处理时，我们可以通过算法进行自动转化。通过我们给的少量样本，算法能够自动识别我们的目标，从而达成这个目标，这就是基于样例的算法。基于样例的算法在智能运维领域中同样大有可为，另外还有一种方法是小样本算法，通过给定少量标签或案例快速达成目标是我们正在进行的尝试。
人可以问类似以下自然语言的问题，能够自动转成SQL并出结果，具有高易用性，便于运维人员进行个性化数据探索。
用于事件关联的快速发现,如下图所示的HDFS日志，我们想查询其中三个模板是否经常一起出现，PLQ查询能够更加简洁高效，SQL查询则会更加复杂。
智能运维中的算法正在发挥越来越大的作用，但同时算法落地仍有大量问题需要解决。算法不能一蹴而就，需要有持续优化的能力。不妨将算法作为一种运维的辅助手段，使运维人员也能灵活地分析数据，在运维过程中使其变得更高效。
| 留言与评论（共有 0 条评论） “” |
