数据驱动的智能运维平台

导语：伴随着各类高新技术的出现，“人工智能”一词越来越多地出现在人们的日常生活中，而运维朋友常听到与自身工作息息相关的便是智能运维了。

但在当前，国内大部分的智能运维并没有完全落地，整个行业处在一个初期的探索阶段。因此，很多运维人或多或少都有这样的疑问：一个传统企业的智能运维之路该如何走？AIOps 的架构设计与组成究竟从哪里落地？今天，小编就为大家带来了日志易产品总监饶琛琳对于智能运维平台建设的演讲分享实录。

本篇分享，主要从运维需求的源头出发，逐步推导出 AIOps 的架构设计与组成，在推导过程中，饶琛琳详细介绍了时序预测、异常检测、模式概要的分析原理与实现方式的具体场景，以及对应的开源项目选择。实录详情如下，还等什么，快来收干货吧！

讲在前面

今天分享的是数据驱动的智能运维平台，可以看到，标题有两个点，第一个是平台，第二个是数据驱动。主要是分享平台本身的主件架构，重点放在一些与数据分析相关的细节，包括对异常检测、时序预测、模块聚类等场景的剖析。

我在参与编写《企业级 AIOps 实施建议》白皮书期间，与腾讯、华为手机的一些朋友在讨论“智能运维”时候，得到了一个比较有趣说法：我们可以把 AIOps 进行分级，像“异常检测”这样的细节点，就认为它是一个原子场景，不用再细分，或者是引用周志华教授的说法，称其为“学件”，这种学件，类似于程序中的 API 或公共库，可以放到四海而皆准；再往上层就是类似于“根因分析”的串联应用，通过多种算法、多个原子场景组建出来的串联组合场景；再往上便是更高级的场景，最终达到终极 AIOps 。今天分享的皆是原子场景的使用方式。

谈谈 AIOps

怎么构建一个 AIOps 平台？我们先要确定目的，然后再谈如何达到目的。

在定义 AIOps 时画了一张图，除了中间有机器学习、BigData、Platform 外，外层的内容就是监管控，这也就是做 AIOps 的目的。只不过是在做监管控时，要使用一些新的方式，以减轻运维的工作量。

与传统运维相比，智能运维可以更灵活、更易用，并且快速探索数据。比如有 1000 台服务器，如果没有一个统一的平台，要发现问题会非常麻烦。

探索和实验平台是什么意思呢？这其实是总结了运维人员的一个工作状态：猜测、试错，如果试错不对，再进行下一次试错，即一个探索发现的过程。如果这个过程执行不够快，就意味着解决故障的速度会慢下来。因此，我认为，这个快慢问题对于运维来说非常重要的一个点。

从实际情况来看，AIOps 平台里应该有哪些东西？我觉得下面的描述很有趣，数据湖，即存储采集数据，还有自动化系统、记录系统、交互系统、监控生态圈。

将这几个系统拆分一下，我们可以发现，监控系统和交互系统在运维的分类中比较混淆。一般来说，监控系统负责的只是把数据抓下来，然后去判断是不是有问题，但是实际上监控系统还要负责一个重要的流程，也就是这个问题和其他问题有没有联系？应该把这个问题发给谁？发送时只能告诉有这么一个问题，还是描述更多信息？这段流程要比数据采集部分更重要。要做好支撑运维目的的平台，就需要将其单独拆分考虑。

这张幻灯看起来好像和 AI 没有太大的关系，只要具备这些系统，就可以承认这是一个 Ops 平台了，但是在这个平台中，AI 是什么？

下图是阿里云 AI 平台的一张截图，类似于这种的机器学习 Web 平台，市面上应该有三四十种，但这种平台对运维来说并没有实际的意义。

我们运维人真正需要的是机器学习在运维工作中的运用。AppDynamics 的 2016 年度总结中提出一些对于 APM 厂商来说可以做出的 AI 场景，可以对这些内容进行拆解，得出运维人的真正需求。

我这里提供一种很好的拆解方式，下图是《 Google SRE book 》书中的一张图，对于运维人员来说，最重要的还是要去解决底层需求，包括监控、事件响应、根因分析、CICD、容量规划、部署，将这张图与上图中 AI 应用场景进行对照，便会得到从技术到需求应用之间的关系。

从对应的关系中可以看出，很多链条是相通的，而最终的目的都是要做好一个监控，即最底层的需求。此外，还有一条链是“根因分析-智能报警-自动化”。也就是上面的链条发现故障，最后一条链发出报警，并明确后续流程。

典型应用场景

时序预测

下面主要聊一下两个大链条里几个最常见、比较好入手的场景。第一个是时序预测，预测这个话题非常大。在与客户交流时，也会被问到一些离谱的预测需求，但真正可落地的需求，还是那些数据量足够大、细，且全面，同时预测的是比较细致情况的需求。

即使是靠谱的未来预测需求，也依然是太大的话题。例如下图，有了时序数据，以红框为点，中间的蓝线是数据实际情况，剩下三条线是用了三种不同的预测算法得到的预测结果，你会发现依然千差万别。

因此，即便有数据，在要求不高的情况下，能不能做依然是一个需要划分的问题。

回到运维领域，下面几张图是大家比较常见到的序列，对于四种常见的序列情况我们可以想到它应该怎么走，这时就可以想办法让机器去想。

对于以上几张图来说，可以用统计学上的办法去做时序预测，也就是指数平滑，从一阶、二阶、三阶持续运算，α、β、γ 会越来越多。

如果有 100 万条这样的线，依次去配 α、β、γ，那工作量将会非常浩大。就这么几个参数、十几条线，可能就要花费两三个月的时间来做，如果说所有的监控指标全这么做，那肯定是不现实的。

在此基础上，就可以考虑用一些减轻人工作量的办法，我们可以用各种不同统计学里的函数确定情况，最后获取一个相对最好的MSE，确定最佳参数，这样工作量就会减轻一些。

对于时序预测的开源选择有很多，除了刚才讲到的 RRDtool 、Holt-Winters 外，还有 Facebook、hawkular 的开源项目。

前面讲的对自动化调参的过程，很多具体的细节来自 Redhat 项目，虽然主项目已经没有更新，但是这个子项目还是推荐大家看一下。

异常检测

第二个场景是异常检测。其实预测本身就是异常检测的一种方式，但异常检测并不只是这种方式。例如下面这两种，虽然是比较离谱的情况，但并不代表在长时间维度下不会出现，这种情况应用任何平滑的方法，对这条线的异常检测都没有任何意义。

再如下面这种线，在不同的障碍阶段差别很大，但用平均值的话，整个这一段中平均值都在一条线上，根本无法判断这条线的任何区别。

此外，异常检测还要考虑一个最基本的同环比，也要考虑同比的鲁棒性。

这里可以介绍一下 datadog 的异常检测，提供 4 种检测方法， Basic 采用的是四分位方法，Agile 用的是 SARIMA 算法，Robust 用的是趋势分解，Adaptive 在我看起来，采用的是 sigma 标准差。

下面是在不同场景下，这四种不同算法对这一条线是否异常的判断，我们可以看到，如果不需要对本身业务的理解，单纯就是一个算法，一切都正常，如第一个想过对比，但在实际工作中却不太可能。

所以当我们真的要去做异常检测时，必须对业务要有一定的了解，明白 metric 这条线背后代表的含义，才能对各种算法进行选择，这个地方没有万能钥匙。

对于异常检测的开源库选择，有些是原子的，有些是组合的。Etsy 的 skyline 是比较高级的场景，里面带有数据存储、异常检测分析、告警等；Twitter、Netflix、Numenta 是纯粹的机器学习算法库，没有任何附加内容；Yahoo 的 egads 库可以算是异常检测的原子场景，比 Twitter 和 Netflix 层级稍高。

模式聚类

第三个要讲的是数据概要-文本聚类。我们知道，前面讲的两类都是监控 metric 情况，但是一些故障单纯看 metric 是无法找出故障的。在排障过程中可以看几条线，包括时间相关性或者时序聚类，也可以做根因分析，但这些还不足够。

我这边可以提供的是另外一条思路，日志易是一款日志分析产品，企业有各种各样的系统，产生各种各样的日志，如果通过ETL的方式把日志收集起来，可能要写上万个表达式，是不可能完成的任务。

我们可以看到下图有四行日志的输出代码，可以看出日志格式和种类是有限的。假如这四行代码打了 1000 万条，其实也就是这四行代码打的而已。如果从人的理解上看，这四行代码就说了两件事：1. 有一个 User 登录了，2. 定义了一个常量。我们要干的是什么？就是把 1000 万行代码反推到四个不同的日志样式。

另外一个细节，在处理自然语言时，逗号还是分号没有任何意义，我们关注的是文本，但日志里面的每一个符号都很关键，是一个独特的聚类聚合方式。如果我们不想上机器学习技术，只想先跨出第一步，就可以利用这个特性，除去文本，留下这堆标点符号。

替换之后，留下的内容也足够反映出一些信息。例如下面这个实例，这个思科的 ASA 日志情况，进行处理后，得到了一些一模一样的标点符号，我们就可以推测应该是同样的内容，这个是最简单的方式，因为比较粗略，所以推测得也不是特别有效。

可以再往前一步，加上一点聚类的东西，先走 TFIDF ，提取一些文本的特征值，再走一个 DBSCAN ，拿每个聚类的样本情况来看。当看到某个样本不太对，就单独把这个样本拿出来，调整参数，将聚类里的日志重新聚类，再观察一下情况。

聚类的思路是相通的，先提取，做聚类，聚类出来有问题，再切分一个小类。但是实际上线使用的话，还是有很多问题需要考虑的。用 DBScan 聚类的运行时间比较长，是一个偏离线运行状态，而且占用的资源也多。

除了这类算法上的问题，还有一个思路上的问题，单纯只是完全的聚类，没有办法合适地判断逻辑代码，也就不足以达到知道它的原始代码是什么样的目的。

这里我们参考一下日本电器美国实验室曾经发表的一篇论文，他们的算法叫 HLAer，原理是不直接上一大堆文本的聚类方式，而是反过来去推导。

我们做的是运维日志，大多数情况下，运维日志有很多东西不需要耗费 CPU 处理。第一个，像 Num、Date、IP、ID 等都是运维 IT 日志里一定会出现的，但在关注模式时不会关注这些。因此，可以在开始就把这些信息替换，节省工作量。

第二个是对齐，对齐也是耗资源的，如何减少对齐的时候强行匹配资源呢？可以开始先走一个距离极其小的聚类，这样每一类中的原始文本差异非常小。此时意味着第二步得到的最底层聚类去做对齐时，在这个类里的对齐耗损就会非常小，可以直接做模式发现。

到第四步的时候，虽然还是聚类，但是消耗的资源已经非常少，因为给出的数据量已经很小，可以快速完成整个速度的迭代。

这是一个事例，首先将两条日志去做分层，再去做一个发现，然后去做一个对齐和一个模式发现。通过这种方式，可以把所有日志一层一层往上推，最终把整个结果全部推导出来。

比如一开始给出的是 15 种，觉得不合适，往下走一层，看 13、14 是怎么样的，还不合适，再往下走一层，看 9、10、11、12 是什么，总有一层是合适的，就可以把前面的 8 条日志得到一个树状结构。

当然，为了方便使用，可以提前中止结构树生成，不一定要推到顶上那个点。一般会在提前、合适的情况下，终止这个数的生成，从机器办法来说，可以记录下每一层剩下多少个这样的模式，找到拐点，这个拐点能够证明再往下已经不方便合并即可，但是这种方式计算量比较大。

因此，目前会选择一个简单但是对肉眼比较合适的方式，即每一行都有分词，如果一行里面分了 20 个，其中，要被替换成新的东西超过了 5%，觉得不太合适看，这个时候就可以停下来了。