本文目录一览：
相比传统运维工具，AIOps的优势在哪里
所谓的AIOps，简单理解就是基于自动化运维，将AI和运维很好的结合起来。
AIOps的落地在多方面直击传统运维的痛点，AI算法承担起分析海量运维数据的重任，能够自动、准确地发现和定位问题，从决策层面提高运营效率，为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。
可见，AIOps 在企业中的作用正在进一步放大。但事实上，很多企业对于AIOps 能解决什么问题并不清晰，今天我们就以博睿数据的AIOps 的三大场景和算法说起。
博睿数据的AIOps实践
作为中国领先的智能可观测平台，在AIOps实践方面，多年来博睿数据积极拥抱人工智能、机器学习等新技术变革的浪潮，并基于AI和机器学习技术，自主研发了“数据接入、处理、存储与分析技术”核心技术体系，全面布局智能基线、异常检测、智能告警、关联分析、根因分析等丰富且广泛的智能运维功能，并将AIOps能力融入端到端全栈监控产品线，可为传统企业提供强大的数据处理、存储和分析的软件工具，帮助客户整合各类IT运维监控数据，实现数据的统一存储和关联分析，打破数据孤岛，构建统一的IT运维管理平台，让企业的IT运维更加智能化、自动化。
在此基础上，博睿数据还依托完整的IT运维监控能力，利用大数据和机器学习技术持续构建先进的智能运维监控产品，2021年先后推出了搭载了AI能力的新一代APM产品Server7.0和新版的统一智能运维平台Dataview，不断落地智能异常检测、根因分析、故障预测等场景。基于人工智能的能力实现运维监控场景的信息整合、特征关联和业务洞察，帮助企业确保数字化业务平稳运行，并保障良好的数字化体验。
目前，博睿数据在AIOps 技术方面主要落地了三大场景。即智能基线预测、异常检测及告警收敛。
随着企业业务规模扩大，云原生与微服务的兴起，企业IT架构复杂性呈现指数级增长。而传统的IT运维手段面临故障发生后，查找故障原因困难，故障平均修复时间周期长，已无法满足新的运维要求。因此运用人工智能赋能运维，去取代缓慢易错的人力决策，快速给出运维决策建议，降低问题的影响并提前预警问题就成为了必然。AIOps作为目前运维发展的最高阶目标，未来将会赋能运维带给用户全新的体验。
但需要注意的是，当前智能运维的很多产品和项目在企业侧落地效果并不理想，究其原因可归类为三点：一是数据采集与AI平台割裂，多源数据之间的关联关系缺失导致AI平台缺乏高质量的数据，进而导致模型训练效果不佳；二是数据采集以metric和log为主，导致应用场景较窄且存在数据孤岛问题；三是AI平台能力尚有提升空间。当前落地的场景多以异常检测与智能告警为主，未来需要进一步提升根因分析与故障预测的能力。
因此，未来企业首先要建设一体化监控运维平台，一体化是智能化的基础。基于一体化监控运维平台采集的高质量的可观测数据数据以及数据之间的关联关系，进一步将AIOps的能力落地到一体化监控运维平台中，从而实现问题精准定位与见解能力。
此外，在实际应用中，依据信通院的相关调查，其受访企业中只有不足20%的企业具有智能化监控和运维决策能力，超过70%的企业在应用系统出现故障的10分钟内一筹莫展。
各行业的数字化转型正在改变这一现状，不仅互联网企业，更多传统企业的数字化转型为智能运维开拓了更广阔的市场，智能运维有着巨大的发展空间，这也是博睿数据等行业领先企业发力的大好时机。
提升创新能力，推广智能运维不仅是相关服务商自身发展的要求，也是提升我国企业应用管理和运维水平的使命。
中国企业数字化转型加速，无论是前端的应用服务迭代更新，还是后端IT运维架构的复杂度提升，都在加速培育智能运维的成长。
根因分析法是什么？
根因分析是一项结构化的问题处理法，用以逐步找出问题的根本原因并加以解决， 而不是仅仅关注问题的表征。
所谓根本原因，就是导致我们所关注的问题发生的最基本的原因。因为引起问题的原因通常有很多，物理条件、人为因素、系统行为、或者流程因素等等，通过科学分析，有可能发现不止一个根源性原因。
分析要领：
1、提问为什么会发生当前情况， 并对可能的答案进行记录。
根本原因分析法的目的就是要努力找出问题的作用因素，并对所有的原因进行分析。这种方法通过反复问一个为什么，能够把问题逐渐引向深入，直到你发现根本原因。
2、找到根本原因后，就要评估改变根本原因的最佳方法，从而从根本上解决问题。
这是另一个独立的过程，一般被称之为 改正和预防。当我们在寻找根本原因的时候，必须要记住对每一个已找出的原因也要进行评估，给出改正的办法，因为这样做也将有助于整体改善和提高。
以上内容参考：百度百科-根本原因分析
IT运维平台算法背后的两大“神助攻”
智能运维(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 环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。
Oculus 截图如下：
这部分使用的 计算方式有两种：
欧式距离，就是不同时序数据，在相同时刻做对比。假如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 就是采用了皮尔逊系数的计算，接口文档见：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html
唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个 event 里。所以没法直接从现成的 ES 数据中请求不同的 date_histogram，然后计算，需要自己手动整理一遍，转储回 ES 再计算。
饶琛琳，目前就职日志易，有十年运维工作经验。在微博担任系统架构师期间，负责带领11人的SRE团队。著有《网站运维技术与实践》、《ELKstack权威指南》，合译有《Puppet 3 Cookbook》、《Learning Puppet 4》。在众多技术大会上分享过自动化运维与数据分析相关主题。
