根据Gartner的最新解读，智能运维（AIOps）是指融合大数据和机器学习能力，通过松耦合和可扩展的方式提取和分析不断增长的IT数据从体量、品种、速度三个维度，为IT运维管理产品提供支持。AIOps围绕质量保障、成本管理、效率提升等基础运维场景，逐步构建智能运维场景。在质量保障方面，保障现网稳定运行细分为异常检测、故障诊断、故障预测、故障自愈等基本场景；在成本管理方面，细分为资源优化、容量规划、性能优化等基础场景；在效率上，分为智能变更、智能问答、智能决策等基础场景。一、网易游戏AIOPS路线图2016年以来，网易游戏在AIOps道路上不断探索，努力实现从人工运维到智能运维的转变。2016年起组建智能监控团队，搭建智能运维平台。目前已实现异常检测、预测、关联分析、下钻分析、日志分析、运维机器人、故障定位、故障预警等功能。此外，还有火焰图分析、硬件预测、CDN文件发布等诸多其他功能，都取得了不错的实用效果。2.异常检测异常检测是研究AIOps的必经之路。后续的很多场景功能都是基于异常检测，这是一个必须要解决的问题。异常检测是指通过AI算法从监控数据中自动、实时、准确发现异常，为后续诊断和“自愈”提供依据。与传统阈值配置成本高、误报多、场景覆盖少等问题相比，异常检测具有配置简单、准确率高、场景覆盖广、自动更新等优点。对于异常检测，其实网上很多文档或者书籍都给出了一些算法或者工具，但是在实际应用的过程中，你会发现效果往往不是很好。原因是这些算法只能有效地针对一些特定的场景，并且需要做大量的优化来适应实际场景。为了在实际场景中更好的实现，我们对算法进行了一些调整和优化，根据业务需求对指标进行划分，以达到更好的检测效果。我们根据指标类型将异常检测分为三种场景——业务黄金指标（如在线游戏人数）、性能指标（如CPU使用率）、文本数据（如日志），并使用不同的检测算法。1、商业黄金指标商业黄金指标的特点是周期性强，曲线波动小，指标量级小，对准确率和召回率要求高。我们知道监督模型具有召回率高和可扩展性高的优点，所以我们考虑使用监督模型来检测业务黄金指标的异常。然而，监督模型需要大量的标记数据，很难为异常检测项目收集足够的异常数据。那么如何解决和平衡两者的关系呢？从样本构建到告警可视化，我们构建了一套完整的检测框架。1）样本构建考虑到样本采集的难度，我们的样本主要来自两个方面——历史KPI数据集和在线用户标注数据。首先抽取一部分KPI数据集，使用Iforest等简单的无监督检测模型检测异常分数，通过不等分层抽样过滤掉疑似异常样本和正常样本，人工标注，分成训练集和测试集设置用户模型训练和测试。功能上线后收集用户标注数据，用于模型优化。用户标注的数据只会在本项目中使用，避免因不同用户的异常认知差异造成的误报。另外需要注意的是，当历史异常数据不足时，可以通过异常生成的方式来生成样本，比如加噪声、设计抖动模式等。2）预处理预处理模块包括三个部分：曲线分类、缺失标准化处理和特征计算。通过LSTM+CNN实现曲线分类，将待检测的KPI分为3类（稳定、不稳定、未检测），分类准确率可达93%+。缺失值处理和max-min归一化采用线性和前值填充方法。特征包括统计特征、拟合特征、分类特征、过滤特征、自定义特征等，构建近500维特征。考虑到无效特征的问题，在建模之前需要进行特征选择。3）算法模型该模型主要采用常用模型，如RF\XGB\GBDT等，然后与LR进行集成检测。4）可视化可视化部分包括三个模块：图形报警、快速注释、异常视图。告警以图文形式发布，并在告警信息中添加快捷标签链接。用户接到报警后，可以快速确认是否有异常，并进行标记。通过有监督模型的方法可以达到准确率和召回率都很高的检测效果，在线检测效果可以达到90%+，可以满足用户的需求。2、性能指标的监督检测模型可以很好的检测业务黄金指标，但不适用于性能指标场景。如上所述，绩效指标量级大、指标类型复杂、周期不确定。如果仍然考虑使用有监督模型，则需要花费大量的标注和训练成本，这对大规模部署非常不友好。因此，我们采用无监督模型来检测性能类型指标。我们按照异常的类型来划分，分为毛刺、漂移、高频、线性趋势四种。分别采用不同的检测模型进行检测。用户可以根据自己的需要选择报警类型。Glitch类型：Glitch异常是最常见的类型，可以通过差分和SR算法来检测，两者都有很好的效果。漂移型：对于漂移问题，首先需要进行STL循环分解，分解循环项、趋势项和残差项。然后使用均值偏移和稳健回归算法进行检测。高频型：高频是毛刺的一种变体。有时你不关心顺时针抖动，但你需要注意连续抖动。因此，使用的检测算法也会进行类型比较，可以采用多步差分的方式进行检测。线性趋势型：线性趋势主要针对监控内存泄漏类型的问题。可以先进行STL分解，在LR回归和MK检测中进行趋势检测。最后，需要一个周期性的抑制步骤来避免周期性的误报。采用无监督检测模型，准确召回率可达80%+，基本满足用户预期。告警以图文告警的形式发出，帮助用户快速确认告警的正确性。3、文本数据业务的快速发展对系统的稳定性提出了更高的要求。每个系统每天都会产生大量的日志：系统存在潜在的异常，却淹没在海量的日志中。Day1w+，如何合并告警。故障发生后，日志告警幅度过大，无法定位。启动新版本时，系统行为会发生变化，但无法感知。这些问题归根结底是日志信息太多，格式繁多，无法很好地归类。智能日志分析基于大数据和AI算法，提供日志实时智能分类、日志指标异常检测等功能。使用模型根据日志文本的相似度进行分类，自动提取对应的日志模板。如下图，可以从两条日志中提取模板。目前业界的日志分类算法已经比较成熟，很多算法都可以取得很好的效果。我们使用drain算法进行第一次分类，然后Spell进行第二次分类，解决第一次分类不同长度的日志被分到不同模板的问题。获取到日志模板后，可以根据日志模板的数量进行异常检测。智能异常检测会比较不同时间段的分类日志数量，利用机器学习模型自动识别与历史趋势不符的突变或日志类型，并发出告警信息：根据历史两日训练模型日志分布，了解正常的日志波动周期。分析日志的整体分布，减少单一类型日志因小抖动造成的误报。自动选择影响分布最大的topN类日志。与指标异常检测不同，日志异常检测可以检测异常代码类型，对程序排查有很大帮助。另外，日志分类对日志管理也有很大的帮助。当一个新的项目/服务上线时，通过查看日志模板，您可以根据需要整理和删除无效的日志。3、故障定位在标准的故障处理流程中，故障定位一般可分为两个阶段：故障止损前：可以快速获取可用于止损决策的信息，并进行相应的止损操作以达到止损目的。恢复服务。故障停损后：进一步找出故障的深层次原因，确定故障根源，将线上环境恢复到正常状态。在游戏场景中，随着游戏和系统架构越来越复杂，运维人员收到的告警信息也越来越多样化。甚至忽略另一个，也不可能在第一时间解决最核心的问题：游戏结构越来越复杂，出现故障后的排查环节比较长。故障发生后，往往会触发多个告警，但这些告警比较分散，没有按照一定的规则进行分类和可视化。因此，在排查过程中需要人工对告警进行梳理和过滤。目前，故障定位依赖于人工经验，难以复用。1、资源资源维度可以区分机器、网络通道、SaaS进行分析，给出异常信息。1）机器对最近20分钟内的所有指标进行异常检测，并计算异常检测分数。根据几个标准，越早出现异常越可能是根本原因，指标异常越严重越可能是根本原因，机器故障越严重越可能是根本原因根本原因。给出topN个异常机器。2）对网络/频道使用Adtributor算法，根据区域和运营商维度进行下钻分析，给出topN个异常维度。3）saas目前我们的SaaS有比较完善的报警系统，可以直接获取异常结果进行汇总。2、通过日志分类和异常检测，可以直接发现代码代码问题，并给出topN异常模板。3、人为操作人为部分主要是变更事件，与变更系统联动，涉及故障前的变更事件，异常提醒。4.历史故障除了分析机器、代码等问题外，定位故障根源的另一个有效方法是关联历史故障。如果本次故障的异常表现与历史故障相似，则很可能是同一原因引起的，因此可以推荐历史故障原因作为本次故障的根本原因。计算当前故障和历史故障的Tanimoto系数，推荐Tanimoto值最大超过阈值的topN个故障及其根本原因。在整个故障定位过程中，当检测到故障时，会从拓扑资源、代码、人为因素、历史故障等角度，通过不同的方式进行根因分析。如果检测到网络游戏用户减少，则启动故障定位流程，检测到A机网络连接异常，并告警网络问题，找出公网故障手动。图片
