认识达内从这里开始

智能运维(AIops)是目前IT运维领域最火热的词汇，全称是Algorithmic IT operations platforms，正规翻译是『基于算法的IT运维平台』，直观可见算法是智能运维的核心要素之一。

本文主要谈算法对运维的作用，涉及异常检测和归因分析两方面，围绕运维系统Kale中skyline、Oculus模块、Opprentice系统、Granger causality(格兰杰因果关系)、FastDTW算法等细节展开。

一、异常检测

异常检测，是运维工程师们最先可能接触的地方了。毕竟监控告警是所有运维工作的基础。设定告警阈值是一项耗时耗力的工作，需要运维人员在充分了解业务的前提下才能进行，还得考虑业务是不是平稳发展状态，否则一两周改动一次，运维工程师绝对是要发疯的。

如果能将这部分工作交给算法来解决，无疑是推翻一座大山。这件事情，机器学习当然可以做到。但是不用机器学习，基于数学统计的算法，同样可以，而且效果也不差。

异常检测之Skyline异常检测模块

2013年，Etsy开源了一个内部的运维系统，叫Kale。其中的skyline部分，就是做异常检测的模块，它提供了9种异常检测算法：

first_hour_average、

simple_stddev_from_moving_average、

stddev_from_moving_average、

mean_subtraction_cumulation、

least_squares

histogram_bins、

grubbs、

median_absolute_deviation、

Kolmogorov-Smirnov_test

简要的概括来说，这9种算法分为两类：

从正态分布入手：假设数据服从高斯分布，可以通过标准差来确定绝大多数数据点的区间;或者根据分布的直方图，落在过少直方里的数据就是异常;或者根据箱体图分析来避免造成长尾影响。

从样本校验入手：采用Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor等非参数校验方法。

这些都是统计学上的算法，而不是机器学习的事情。当然，Etsy这个Skyline项目并不是异常检测的全部。

首先，这里只考虑了一个指标自己的状态，从纵向的时序角度做异常检测。而没有考虑业务的复杂性导致的横向异常。其次，提供了这么多种算法，到底一个指标在哪种算法下判断的更准?这又是一个很难判断的事情。

问题一：实现上的抉择。同样的样本校验算法，可以用来对比一个指标的当前和历史情况，也可以用来对比多个指标里哪个跟别的指标不一样。

问题二：Skyline其实自己采用了一种特别朴实和简单的办法来做补充——9个算法每人一票，投票达到阈值就算数。至于这个阈值，一般算6或者7这样，即占到大多数即可。

异常检测之Opprentice系统

作为对比，面对相同的问题，百度SRE的智能运维是怎么处理的。在去年的APMcon上，百度工程师描述Opprentice系统的主要思想时，用了这么一张图：

Opprentice系统的主体流程为：

KPI数据经过各式detector计算得到每个点的诸多feature;

通过专门的交互工具，由运维人员标记KPI数据的异常时间段;

采用随机森林算法做异常分类。

其中detector有14种异常检测算法，如下图：

我们可以看到其中很多算法在Etsy的Skyline里同样存在。不过，为避免给这么多算法调配参数，直接采用的办法是：每个参数的取值范围均等分一下——反正随机森林不要求什么特征工程。如，用holt-winters做为一类detector。holt-winters有α，β，γ三个参数，取值范围都是[0, 1]。那么它就采样为(0.2, 0.4, 0.6, 0.8)，也就是4 ** 3 = 64个可能。那么每个点就此得到64个特征值。

异常检测之

Opprentice系统与Skyline很相似

Opprentice系统整个流程跟skyline的思想相似之处在于先通过不同的统计学上的算法来尝试发现异常，然后通过一个多数同意的方式/算法来确定最终的判定结果。

只不过这里百度采用了一个随机森林的算法，来更靠谱一点的投票。而Etsy呢?在skyline开源几个月后，他们内部又实现了新版本，叫Thyme。利用了小波分解、傅里叶变换、Mann-whitney检测等等技术。

另外，社区在Skyline上同样做了后续更新，Earthgecko利用Tsfresh模块来提取时序数据的特征值，以此做多时序之间的异常检测。我们可以看到，后续发展的两种Skyline，依然都没有使用机器学习，而是进一步深度挖掘和调整时序相关的统计学算法。

开源社区除了Etsy，还有诸多巨头也开源过各式其他的时序异常检测算法库，大多是在2015年开始的。列举如下：

Yahoo!在去年开源的egads库。(Java)

Twitter在去年开源的anomalydetection库。(R)

Netflix在2015年开源的Surus库。(Pig，基于PCA)

其中Twitter这个库还被port到Python社区，有兴趣的读者也可以试试。

二、归因分析

归因分析是运维工作的下一大块内容，就是收到报警以后的排障。对于简单故障，应对方案一般也很简单，采用service restart engineering~但是在大规模IT环境下，通常一个故障会触发或导致大面积的告警发生。如果能从大面积的告警中，找到最紧迫最要紧的那个，肯定能大大的缩短故障恢复时间(MTTR)。

这个故障定位的需求，通常被归类为根因分析(RCA，Root Cause Analysis)。当然，RCA可不止故障定位一个用途，性能优化的过程通常也是RCA的一种。

归因分析之Oculus模块

和异常检测一样，做RCA同样是可以统计学和机器学习方法并行的~我们还是从统计学的角度开始。依然是Etsy的kale系统，其中除了做异常检测的skyline以外，还有另外一部分，叫Oculus。而且在Etsy重构kale 2.0的时候，Oculus被认为是1.0最成功的部分，完整保留下来了。

Oculus的思路，用一句话描述，就是：如果一个监控指标的时间趋势图走势，跟另一个监控指标的趋势图长得比较像，那它们很可能是被同一个根因影响的。那么，如果整体IT环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。

这部分使用的计算方式有两种：

欧式距离，就是不同时序数据，在相同时刻做对比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次类推。

FastDTW，则加了一层偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次类推。当然，算法在这个简单假设背后，是有很多降低计算复杂度的具体实现的，这里就不谈了。

唯一可惜的是Etsy当初实现Oculus是基于ES的0.20版本，后来该版本一直没有更新。现在停留在这么老版本的ES用户应该很少了。除了Oculus，还有很多其他产品，采用不同的统计学原理，达到类似的效果。

归因分析之Granger causality

Granger causality(格兰杰因果关系)是一种算法，简单来说它通过比较“已知上一时刻所有信息，这一时刻X的概率分布情况”和“已知上一时刻除Y以外的所有信息，这一时刻X的概率分布情况”，来判断Y对X是否存在因果关系。

可能有了解过一点机器学习信息的读者会很诧异了：不是说机器只能反应相关性，不能反应因果性的么?需要说明一下，这里的因果，是统计学意义上的因果，不是我们通常哲学意义上的因果。

统计学上的因果定义是：『在宇宙中所有其他事件的发生情况固定不变的条件下，如果一个事件A的发生与不发生对于另一个事件B的发生的概率有影响，并且这两个事件在时间上有先后顺序(A前B后)，那么我们便可以说A是B的原因。』

归因分析之皮尔逊系数

另一个常用的算法是皮尔逊系数。下图是某ITOM软件的实现：

我们可以看到，其主要元素和采用FastDTW算法的Oculus类似：correlation表示相关性的评分、lead/lag表示不同时序数据在时间轴上的偏移量。

皮尔逊系数在R语言里可以特别简单的做到。比如我们拿到同时间段的访问量和服务器CPU使用率：

然后运行如下命令：

acc_count<-scale(acc$acc_count,center=T,scale=T) cpu<-scale(acc$cpuload5,center=T,scale=T) cor.test(acc_count,cpu)

可以看到如下结果输出：

这就说明网站数据访问量和CPU存在弱相关，同时从散点图上看两者为非线性关系。因此访问量上升不一定会真正影响CPU消耗。

其实R语言不太适合嵌入到现有的运维系统中。那这时候使用Elasticsearch的工程师就有福了。ES在大家常用的metric aggregation、bucket aggregation、pipeline aggregation之外，还提供了一种matrix aggregation，目前唯一支持的matrix_stats就是采用了皮尔逊系数的计算，接口文档见：

#/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html

唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个event里。所以没法直接从现成的ES数据中请求不同的date_histogram，然后计算，需要自己手动整理一遍，转储回ES再计算。

免责声明：内容来源于公开网络，若涉及侵权联系尽快删除！