算法落地探索：智能运维远非“智能”人答题。目前，很多研究人员都在研究智能问答系统，提出了很多算法和技术。GoogleScholar上关于智能问答系统的文章超过30万篇，但不到35万篇。但实际上，智能问答系统离真正的智能还差得很远，回答的结果往往不是问题的答案，这会造成海量算法和技术出现偏差，结果不尽如人意。智能运维大概有六七年的发展历史。这期间，智能运维算法发展迅速，包括性能指标的时序数据，日志告警的数据，以及近两年的CMDB和调用。链等值线图数据。算法种类和效果也在不断完善，包括指标异常检测、容量预测、日志聚类、日日志检测、告警场景挖掘、根因定位等。以下内容主要涉及三大类：指标异常检测、日志智能分析、告警数据分析。1.指标异常检测指标异常检测是实现最多的智能运维场景，因为数据准备容易，效果验证容易，准确率和召回率指标容易量化。目前很多公司做大规模指标的异常检测，比如10000个指标，100000个指标。针对指标的异常检测，研究人员提出了大量的异常检测算法，如单指标和多指标检测、基于统计和深度学习的模型、无监督和监督算法等，许多公司和机构已经开源他们在过去的两年里。异常检测数据集和算法。然而，落地场景下的应用效果往往不尽如人意。主要问题如下：1）误报过多，阈值设置过严。,必须忽略所有指标异常告警2)很难为模型/参数设置不同类型的指标，往往适用于不同类型的模型和参数。模型和参数不能单独设置，分类效果不好3）缺乏有效的反馈和纠错机制缺乏发现问题的能力，难以展示和分析类型、主机、时间段、业务等异常指标，难以交互探索异常，无法判断异常是否上报。响应“这不是我们认为的异常，不要在后续检测中报告”的个性化需求2.日志智能分析目前，大量企业已经推出实时日志集群和基于日志的异常检测，主要解决了人工难以处理海量日志数据和基于规则的方法维护性差的问题。典型场景下，对海量日志进行实时集群，进行基于日志的异常检测，如变量值异常、模板数量异常、语义异常等。但是智能日志在实践中也存在几个问题分析。1）模板质量难以有效评价。日志聚类后，聚类成多个模板时，难以有效评价模板质量。尤其是在实施过程或者上线过程中，模板数量多，人工一一判断耗时太长，可能是运维人员没有足够的时间手动判断，不同的应用目标对模板的要求不同。有可能模板在做某类日志异常检测时不应该泛化，但可能需要做另外一件事。,一个模板是否需要泛化是一个很主观的事情2)缺乏有效的反馈和纠错机制缺乏基于反馈的模板调整能力，很难处理“这个模板应该根据这个变量拆分”，“这个变量应该是运维专家和算法人员因为泛化等个性化需求很难沟通，运维专家和算法团队隔着一个实现团队，反馈链条长，而且是3、告警数据分析告警相关项目近年增长迅速，每天告警数以万计，由于告警数量庞大，运维人员难以有效处理和调度订单。因此，告警压缩、场景挖掘、通过算法进行根因定位越来越受到重视。有两大类告警智能处理中存在的主要问题：1）告警模板提取效果不佳。告警数据更加灵活多变，不同运维人员的告警描述方式不同。包含大量中文，报警模板提取效果不理想。2）根本原因定位效果不好。CMDB的质量有待提高。可能是系统有变化但是CMDB没有及时更新到最新的场景。告警数据中可能不存在真正的故障原因，无法定位根本原因。标签数据丢失。一方面，失败的数量少，另一方面，出于隐私等原因，企业也不愿意给标签。2、问题分析我们梳理了智能运维的现状、具体类别和相关问题，接下来我会给出一些个人的思考。我认为算法实现不理想的深层次原因有两个：1、算法需要不断迭代优化。我们常常认为智能运维的算法可以开箱即用，但效果远非如此。该算法需要不断迭代优化。算法一开始一般是通用算法，部署到企业之后，肯定会变成定制化的算法。因为对于每一个具体的项目，算法都需要和运维数据、业务特性、运维目标等进行深度融合，需要不断打磨和适配。1）算法本身：普遍缺乏反馈校正能力。对于“我不需要这个异常，以后检测不要再报”，“这两个模板应该合并，变量不能泛化”等反馈，目前的模型，尤其是深度学习模型是难以有效吸收，主要是缺乏两种能力：发现问题的能力。比如我们一天上报2000个异常，我们能不能有半个小时或者一个小时的时间去把这2000个异常过一遍，判断哪些该报，哪些不该报？目前很少有人能在短时间内做到这一点。模型自动校正能力。比如给定很多“报这个，不报那个”之类的反馈，模型能不能很好的适配，因为这个适配其实是100%的适配，有的可能根本不报，有的必须报出来，这对模型来说也比较困难。2）实现过程：运维专家和算法人员分离，算法最重要的是标签数据和算法结果的快速反馈。然而，相关领域的专家可能熟悉机制而不熟悉算法。由于通信链条长，通信成本高，运维专家和算法人员在一定程度上分离。2.系统故障本身是一个超低频事件。系统故障本身是一个超低频事件。严重的故障可能只出现一次，很快就会解决，不可能再出现。算法需要根据历史数据的规律进行优化和改进。如果之前发现的故障很可能以后就不再出现，那么这其实是一个悖论。前面我们也提到，我们完全依靠算法来实现自动化运维。至少在现阶段，我觉得其实是不现实的。我们只做异常检测，日期类不是很好，所以我们相信目前的算法可以实现自动化。运维？我觉得更现实的目标是把算法作为辅助手段，让运维更加高效。1）数据量过大，使用算法提升效率，每天从数百TB日志中自动提取模板和变量，自动对上万指标进行异常检测2）部分场景，使用算法提升accuracy因为在causalinference中有些链比较长，需要考虑的方面比较多。人的思维其实还没有那么发达，所以算法可以帮助提高这些方面的准确性。3）作为故障定位的辅助手段，帮助运维人员灵活快速地查询和挖掘数据。这是一个很重要的能力，因为在很多项目中，算法结果的分析是很累的。4）算法作为积累知识的方式，构建知识图谱三、探索1、如何高效支持反馈如果你只让运维专家标注10个异常/10个模板，你应该怎么做？1）快速发现问题的能力可以先通过异常置信度和日志模板置信度从2000个异常中选出10个异常，然后利用异常立方体更系统的能力，交互探索异常，可视化异常。2）自动修正模型的能力当我们要将记录人们电话、传真信息的Excel或CSV表格转换成结构化数据进行处理时，我们可以通过算法进行自动转换。通过我们给出的少量样本，算法可以自动识别出我们的目标，从而实现这个目标。这是基于示例的算法。基于实例的算法在智能运维领域也大有可为。另一种方法是小样本算法。是我们一直在尝试的，通过给出少量的标签或案例来快速达到目的。2.作为辅助手段的数据探索技术1）基于自然语言的问答系统人们可以提出类似于以下自然语言的问题，可以自动转换成SQL并产生结果，易用性强，方便运维人员查询个性化数据探索。2019/11/2811:25异常突增的指标是什么？应用程序A中哪台主机出现异常最多？B应用告警次数最多的告警类型是什么？上周内存使用率最高的前十名主机是哪些？最近十天异常最多的应用是什么？上周哪个应用程序的失败率最高？2）基于时间关联的复杂查询，用于快速发现事件关联。对于下图所示的HDFS日志，我们想查询三个模板是否经常一起出现。PLQ查询可以更简洁高效，而SQL查询可以更复杂。3）拖放式分析流程的实现，方便领域专家组合不同的分析算法构建分析流程。集成了异常检测、聚类、场景挖掘等多种算法。支持不同语言开发的算法，支持输入数据格式的智能学习。四、小结算法在智能运维中发挥着越来越重要的作用，但与此同时，算法的实现还存在很多问题需要解决。算法不可能一蹴而就，需要不断优化的能力。不妨将算法作为运维的辅助手段，让运维人员在运维过程中也可以灵活的分析数据，使其更加高效。作者简介：王鹏，复旦大学教授/博士生导师，复旦大学计算机学院教授，??博士生导师。主要研究方向包括：工业物联网大数据、智能运维等。2012年获得教育部自然科学奖二等奖（第三完成人）。主持或主要参与科技部重点研发计划、国家青年973、自然科学重点普通基金、上海市科委、上海市经济和信息化委员会项目多项，以及基金资助项目华为、微软、IBM等企业。在SIGMOD、VLDB、ICDE、TKDE等数据库领域国际顶级期刊和会议上发表论文40余篇。担任多个国际学术会议程序委员会委员，包括SIGKDD、ICDE、DASFAA、WAIM等。国际学术期刊VLDBJournal、TKDE、KIS等审稿人。
