中国领先的IT技术网站
|
|

清华教授解密AIOps:智能运维如何落地?

随着 AI 技术在各个应用领域的落地及实践,IT 运维也将迎来一个智能化运维的新时代。算法的效率提升了 AIOps 的价值,通过持续学习,智能运维将把运维人员从纷繁复杂的告警和噪音中解放出来。

作者:裴丹来源:51CTO技术栈|2017-08-30 11:51

【沙龙】51CTO诚邀您9月23号和多位技术大咖一起聊智能CDN的优化之路,抓紧时间哦!


随着 AI 技术在各个应用领域的落地及实践,IT 运维也将迎来一个智能化运维的新时代。算法的效率提升了 AIOps 的价值,通过持续学习,智能运维将把运维人员从纷繁复杂的告警和噪音中解放出来。

那么,基于算法的 IT 运维与自动化运维的区别是什么?在现阶段,运维中的哪些痛点适合引入人工智能技术?如何加速落地?

8 月 26 日下午 51CTO 在北京举办了第十四期以“Tech Neo”为主题的技术沙龙活动,进一步拓宽运维/开发人员的运维思路、激发创新能力。由清华计算机系副教授,智能运维算法专家裴丹为大家分享主题为“智能运维如何落地”的精彩演讲。

在演讲开始,裴丹教授通过运维背景介绍,普世化智能运维关键技术,意在让所有公司都能用上最好的智能运维技术。裴丹教授认为,解决智能运维普世化的问题在数据、算法、算力、人才四方面。

第二部分是分解定义智能运维中的关键技术,通过分解关键技术来定义科研问题。

裴丹老师指出的科研问题要求分别为:

  • 清晰输入,数据可获得。
  • 清晰输出,输出目标切实可行。
  • 有 high-level 的技术路线图。
  • 有参考文献。
  • 非智能运维领域的学术界能理解、能解决。

裴丹教授还指出,Gartner报告中关于智能运维的问题描述太宽泛。智能运维如何做好?裴丹教授认为,机器学习本身有很多成熟的算法和系统,及其大量的优秀的开源工具。

如果成功的将机器学习应用到运维之中,还需要以下三个方面的支持:

  • 数据。互联网应用本身具有海量的日志。需要做优化存储。 数据不够还需要自主生成。
  • 标注的数据。日常运维工作会产生标注的数据。 比如出了一次事件后,运维工程师会记录下过程, 这个过程会反馈到系统之中, 反过来提升运维水平。
  • 应用。运维工程师是智能运维系统的用户。 用户使用过程发现的问题可以对智能系统的优化起正向反馈作用。

裴丹教授通过与百度运维、搜索部门的合作,分享了智能运维的三个案例,包括异常检测、瓶颈分析以及智能熔断。第一个案例是基于机器学习的 KPI 自动化异常检测。

上图表示运维人员判断 KPI 曲线的异常并标注出来, 系统对标注的特征数据进行学习 。这是典型的监督式学习,需要高效的标注工具来节省运维人员的时间: 如可以拖拽,放大等方式。

最后,裴丹教授在通过构建 KPI 异常检测系统中分享了相关的实践与挑战等相关的解决方案。以下为演讲实录:

智能运维的发展历程

我们大家都知道,在运维发展的过程中,最早出现的是手工运维;在大量的自动化脚本产生后,就有了自动化的运维;后来又出现了 DevOps 和智能运维。

在运维的过程中,涉及到的步骤可以概括为:产生海量的监测日志,进行分析决策,并通过自动化的脚本进行控制。

运维的发展过程,主要是分析决策步骤发生了变化:起初,由人工决策分析;后来,在采集数据的基础上,使用自动化的脚本进行决策分析;最后,用机器学习方法做决策分析。

根据 Gartner Report,智能运维相关的技术产业处于上升期。2016 年,AIOps 的部署率低于 5%,Gartner 预计 2019 年 AIOps 的全球部署率可以达到 25%。所以,AIOps 的前景一片光明。

如果 AIOps 普遍部署之后会是什么样的呢?现在做运维的同学们会变成怎样?

从机器的角度,基础性、重复性的运维工作都交给计算机来做了;同时,机器通过机器学习算法为复杂的问题提供决策的建议,然后向运维专家学习解决复杂问题的思路。

从运维专家的角度,运维专家主要处理运维过程中的难题,同时基于机器建议给出决策和训练机器徒弟。

运维工程师将逐渐转型为大数据工程师,主要负责开发数据采集程序以及自动化执行脚本,负责搭建大数据基础架构,同时高效实现基于机器学习的算法。

机器学习科学家主要负责 AI 的落地应用,智能运维领域相对于其他 AI 应用领域的优势在于,我们不仅有大量的应用数据,而且有实际的应用场景和部署环境。

因此,人工智能在计算机视觉、自然语言理解、语音识别之外,又多了一个落地应用——这是一座尚未开采的金矿。

智能运维科研门槛高-工业界

一般有“前景光明”、“前途光明”这些词的时候,下面跟着的就是“道路曲折”。实际上,智能运维是一个门槛很高的工作。

为什么呢?因为智能运维需要三方面的知识:

  • 我们要熟悉应用的行业,比如互联网、电信或者相对传统的行业,如金融、电力等等。
  • 我们要熟悉运维相关的场景,包括异常检测、故障预测、瓶颈分析、容量预测等。
  • 虽然工业界熟悉运维行业和场景,熟悉生产实践中的挑战,也有数据。但是,工业界并不熟悉整个智能运维中最重要的部分——如何把实际问题转化为算法问题(后面会讲到如何把实践中的难题分解成多个算法并逐个解决)。

同时,工业界也不太熟悉查阅科研文献,特别是跨行业的文献。因此,智能运维是一个需要三方面领域知识结合的高门槛领域。

在智能运维文献里有几十种常见的基础算法。但是,工业界并不熟悉这些算法。所以,我们利用微信公众号介绍这些算法。

下面我将介绍一个例子——通过机器学习方法提升视频流媒体的用户体验和观看时长。

这是一位 CMU 教授的系列文章,这位教授在一个做视频分发的创业公司做了若干工作。

2011 年,他在学术界发表了一篇文章,这一工作比较简单,主要为了提升用户观看流媒体的体验,其中用到了相关分析、线性回归、信息增益等简单算法。

2013 年,该教授基于网络行为数据和性能数据,使用决策树方法预测用户的观看时长。该教授于 2017 年发表了一篇新的文章,将视频质量的实时优化问题转化为一种基础的强化学习问题,并使用上限置信区间算法有效解决了这一问题。

智能运维科研门槛高-学术界

在学术界中,很少有人做智能运维方向。这是因为,对于学术界来说,进入到智能运维这一科研领域具有很强的挑战性。为什么呢?

虽然学术界研究人员的算法能力相对较强,但是他们往往不熟悉行业和运维领域的相关知识。而智能运维处于三个领域的交叉部分。这就导致智能运维的门槛比较高,需要花大量的时间和精力才能进入智能运维领域。

前面讲了如何降低工业界进入智能运维的门槛。同时,我也做了一些工作,以降低学术界进入智能运维领域的门槛。例如,我应邀在《中国计算机学会通讯》上发表文章,向学术界的同行介绍智能运维中的科研问题。

但是,仅仅宣传是远远不够的,我们还要实践。去年,我在第一届 APMCon 会议上做了报告,讲述了当时和百度合作的三个案例,包括异常检测、瓶颈分析以及智能熔断。

这种公开的宣传给我自己带来了很多新的合作。除了与百度的合作,我们清华实验室相继与滴滴、搜狗、阿里巴巴、腾讯签署了正式的合作协议。

这验证我的在去年我在 APMCon 上演讲的观点:工业界可以获得算法层面的深度支持,学术界可以获得现实世界的前沿问题和数据,有利于发表论文和申请国家项目。

工业界-学术界合作

1.0:一对一交流合作

但是,现在这种工业界跟学术界的合作方式,还处于1.0阶段,即一对一的交流。

在这个过程中,我们遇到了诸多挑战:

  • 交流合作效率低,见效慢。比如说我是这个教授,我跟 A 公司讨论一下,再跟 B 公司讨论一下。很多情况下,不同公司遇到的问题都是类似的,比如异常检测。但是,我需要跟每个公司梳理一遍这些问题。

C 公司可能不知道我,就找另外一位教授,他依然需要梳理这些问题。这就大大降低了交流合作的效率。我们知道,科研最难的部分,就是把一个实践中的问题定义好。当定义好问题之后,只要数据准备好,其他问题都可以迎刃而解。

  • 智能运维算法不幸成了特权。因为很少有教授愿意去做这种一对一交流,而愿意或有渠道和学校科研人员沟通交流的公司也不多。

这就导致,在国外,只有少数大公司和教授才能合作。比如,目前只有 Google、 Microsoft、Linkedin、Facebook、雅虎等大公司发表过智能运维有关的论文。

  • 涉及知识产权,不符合开源大趋势。因为一对一的合作需要签署涉及知识产权的协议,不符合开源的大趋势。

2.0:开源开放

一对一交流效率低,那具体应该怎么做呢?我们希望拥抱开源开放的文化,形成工业界与学术界合作的 2.0。

开源开放的大趋势已经对工业界和学术界产生了巨大的影响。大家耳熟能详的 Hadoop、Ecosystem、TensorFlow 等,都是开源开放的产物。

在算法层面,当前有 arXiv 共享算法(论文)平台,和 Github 代码共享;在数据层面,ImageNet 等数据共享平台对机器学习算法的研究起到了巨大的推动作用;在计算能力层面,各大公司都建立了 AI 云;在人才层面,我们也可以看到,学术界和工业界的人才流动比原来顺畅多了。

所以,我们的基本思路是,希望能够建立智能运维的问题库。具体的,我们尝试把运维的常见问题梳理出来,并存储到一个问题库里。

这样的话,对于缺乏智能运维背景知识的科研人员,在问题的输入、输出、数据集齐全的前提下,可以很容易地着手解决问题库中的科研问题。对于做运维实践的工业界的同学们,当遇到实际的问题时,可以查询问题库中的解决方案。

这一思路受到了斯坦福教授李飞飞的影响。她最近在宣传普世化 AI 的思路——让所有人都可以使用 AI。李飞飞教授建立的 ImageNet 上面有 1000 多万张图片的分类标注数据。

在 2012 年 Hinton 教授提出了一种基于 CNN 的图片分类算法,取得比以往最好结果高好几个百分点的结果, 引起了深度学习的复兴。

现在,她同时兼任 Google 机器学习部门的负责人。她在宣传普世化 AI 思路时,提到普世化有四个基本点:计算能力、数据、算法、人才。

这四个基本点跟我们要落地智能运维所遇到的挑战是一样的。 因为我们也需要用到机器学习和 AI 的技术来解决智能运维中的挑战性问题。

除了问题库,学术界还需要数据集。此外,工业界最好能提供云计算资源,让学术界提供的算法在云端跑。数据公开后,学术界可以公布训练好的算法,工业界就可以直接使用这些算法。

在人才方面,工业界可以与学术界合作。同时,那些参与我们的智能运维算法大赛且排名靠前的学生,也可以成为工业界的人才储备。最终,我们希望所有的公司都能用上最好的智能运维算法。

分解定义智能运维中的科研问题

下面分解定义一下智能运维中的科研问题,由于时间关系,我只能概述算法的特性。

为什么我们要定义科研问题呢?对于科研工作者来说,类似 Gartner Report 中列举的智能运维问题太宽泛。

首先,科研问题需要清晰的输入,并且数据是可以获得的;其次,科研问题要有清晰的输出,并且输出的目标要切实可行;再次,科研问题要有高层面的技术路线图,以及参考文献;最后,非智能运维领域的学术界要能理解该科研问题。

这是我们已经梳理出来的一些科研问题,我将用后面的时间来解释一下这些算法。

这些算法分为三种:

  • 第一种算法是相对独立的基础模块,面临的挑战较少,可以直接落地。
  • 第二种算法依赖于其他的算法,我们需要把这些算法分解成一个个切实可行的解决问题。
  • 第三种是把非常难的问题降低要求和难度,“退而求其次”。

基础模块

先讲一下基础模块,基础模块是相对独立并能够落地的。

KPI 瓶颈分析算法

我介绍的第一个基础模块算法是 KPI 瓶颈分析算法。在智能运维领域和 APM 领域,我们收集了很多的数据,数据的形式有 KPI 时间序列、日志等。

假如打开一个页面的响应时间(首屏时间)是我们的 KPI,当首屏时间不理想、不满意时,我们希望能够找出哪些条件的组合导致了首屏时间不理想。这就是我们要解决的 KPI 瓶颈分析的定义。

该问题的输入为一张又宽又长的表,其中包含 KPI 和影响到 KPI 的多维属性。 输出为可能影响 KPI 性能的属性组合。这一科研问题具有广泛的应用场景,包括首屏时间、应用加载时间、软件报错、视频传输用户体验等。

在具体应用时,这一科研问题面临着诸多挑战:搜索的空间巨大;不同属性之间可能存在关联关系,导致用简单的分析方法是不可行的。

KPI 瓶颈分析的常用基础算法有:决策树、聚类树(CLTree)、层次聚类。

故障预测算法

我介绍的第二个基础模块算法,是我们最近跟百度系统部合作的一个案例——交换机故障预测。

在交换机故障之前,我们可以从交换机日志中提取一些预示故障的信号。如果找到这些信号,我们就可以提前两小时预测出交换机故障。

故障预测的应用场景还包括硬盘故障预测、服务器故障预测等,使用到的算法包括隐式马尔科夫模型、支持向量机,随机森林等。

在具体应用时,故障预测面临着一些挑战。训练故障预测模型的数据需要足够多,但往往实践中的故障案例比较少。虽然日志量很大,但日志中的有益信息相对较少。我们已经实现了切实可行的系统,且已经在百度运行。

庖丁解牛

当我们应用层出现问题的时候,我们希望找到问题的原因。这里要解决的问题都描述过了,常用的根因分析算法有基于故障传播链的、有基于概率图模型的。这里我们对基于故障传播链的的思路来庖丁解牛。

假如说我们有这样的故障传播链,同时又对事件有很好的监测和准确的报警,那根因的分析就简单了。因为只需要顺着故障传播链各个报警找,找到最后一个就是根因。

这其中有两个关键的步骤,一个是 KPI 异常检测,另一个是故障传播链,下面会详细介绍这两部分。

异常检测

首先是异常检测,很多算法是基于 KPI 的趋势预测的,还有一些算法是基于机器学习的,机器学习的算法需要有标注。而标注会给运维人员带来很多开销,所以能不能做一些工作减少标注的开销呢?

这其中就包括相似异常的查找,运维人员标一个异常后,能不能自动地把相似的、相关的异常都找出来? 以上是对异常检测问题的简单分解,后面会更详细的说明。

异常检测的问题定义很简单,就是对于这样的随着时间有周期性变化的KPI曲线,当它发生异常的时候能够快速准确的报警。

它的常见算法有:基于窗口,基于预测,基于近似性,基于隐式马尔可夫模型,也有机器学习,集成学习,迁移学习,深度学习,深度生成模型等等。

异常检测所面对的挑战就是 KPI 种类各异,如果基于趋势预测算法,调整算法参数费时费力,同时需要人工标注,人工标注也可能不准确。

我们再分解一下,刚刚提到了异常检测的一种思路是基于 KPI 趋势预测。KPI 趋势预测就是通过时序数据的算法能预测出来 KPI 将来一段时间是什么样的,取什么值,常见的算法有 ARIMA、EWMA、Holt-Winters、时序数据分解、RNN等。

主要挑战包括突发事件的影响、节假日的影响、数据不规则的影响,最重要的就是大家对异常的定义不一样,会有主观的因素,最后导致这些算法很难调。

异常检测的另外一个思路是基于机器学习来做, 但是这种方法通常都需要标注,而标注是需要消耗人力资源的。

并且如果标注不全或不准确,这个机器学习模型的效果就会打折扣。我们把减少异常标注的工作分解一下,在同一条曲线内找相似的异常,跨 KPI 找异常。

KPI 相似异常查找是在 KPI 内找异常,运维人员标注异常,然后算法以标注的异常为模块,在曲线上找出类似的其他的异常,这样就能减少标注开销。

例如图中的红色部分即为标注,输出为其他类似的异常。常用基本算法包括 DTW,MK 最佳配对等。

如果跨 KPI,可以先把一个模块的各种 KPI 提前进行聚类,在同一个类别中的某条曲线上进行标注,那么其他的同类的曲线上的对应位置也为异常。聚类用到的基本算法包括 DBSCAN,K-medoids、CLARANS。

聚类是基于曲线的相似性,如果曲线不相似,但是其内在有关联导致它们经常一起变化,这也能够找出更多的异常,从而可以作为一个减少标注开销的方法。

这个是“KPI 关联分析”科研问题, 其基本算法包括关联分析算法和 Granger 因果性分析算法等。

故障传播链

另一个关键因素是故障传播链的构建,即 A 事件发生会导致 B 事件的发生。如果理清了事件的传播关系,就可以构成故障传播图。

上文提到的 KPI 的关联分析和 KPI 的聚类都可以用上。下面介绍异常事件的关联关系和 KPI 的关联关系挖掘。

上图是故障传播链,当应用层、业务层发生故障的时候,如果有故障传播图,就可以从中找到对应时间范围内的相关事件。

如果有就沿着传播链继续往上找,直至找到根因。我们希望能得到这样的故障传播图,但是很多软件之间的模块关系很复杂,很难描述。

另外,刚才提到的调用关系,即 A 模块调 B 模块,并不代表 A 发生异常就会导致 B 发生异常,而是还有很多其他的因素。 通过机器学习算法挖掘各种关联关系,再辅以模块调用关系链,则构建准确完整的调用关系链就相对比较容易了。

挖掘关联关系包括之前阐述过的 KPI 聚类,KPI 关联分析,下面我们再讲述另外的两个算法。

先看异常事件的关联关系。两个关联事件是不是在历史上经常一起发生,比如说这个时间窗口内发生了这四个不同的事件,如果说经常一起发生,它们就有两两对应关系。现有文献中常见的算法有:FP-Growth、Apriori、随机森林。

另外就是事件和 KPI 的关联关系,比如程序启动的事件,在某个时间点程序 A 启动了,下个时间点程序 B 启动了。在程序 A 每次启动的时候 CPU 利用率就上了一个台阶,而 B 没有。

所以说事件和曲线的关联关系,还包括先后顺序、变化方向。 常用基本算法包括 Pearson 关联分析, J-Measure, Two-sample test 等。

退而求其次

前面我们分解了根因分析问题,但是有时由于数据采集不全等原因,完整的根因分析条件不具备,这就要求我们降低要求,“退而求其次”,解决简单一些但是同样有实际意义的问题。

智能熔断

众所周知,80% 的线上故障都是由产品上线或者变更导致的。也就是说在这种情况下,运维人员自己的操作、上线和变更就是业务出问题的根因,那么对于这种根因我们能不能做一些工作呢?

答案是肯定的,就是智能熔断。当产品上线时,根据现有的数据判断业务层出现的问题是否为该上线操作所导致的。具体实现的时候可以用 CUSUM,奇异谱变换(SST),DID 等算法。

异常报警聚合算法

再换一个角度,现在有各种监控的报警,如果运维人员聚合不准,就无法决定下一步的操作。因为监控的 KPI 太多,导致异常报警冗余。

我们的算法会将各种报警原始数据聚合,比如将 100 个异常报警聚合成 5 个,这样实际处理的时候就会相对容易些。具体的算法包括基于服务、机房、集群等拓扑的层次分析,还有基于挖掘的关系和基于故障传播链的报警聚合。

故障定位算法

最后举一个退而求其次的方案。当业务发生故障时, 故障定位并不是给出完全的根因,而是能够大致区分是哪里的问题,输入是各种各样的性能指标,输出根因所发出的具体位置。

例如去年 SIGCOMM 2016 微软提出的基于数据中心的故障定位,先用实验床把所有可能故障都模拟一下,同时收集各类监控指标。

通过机器学习建立模型,这个模型可以根据实际发生的监控指标的症状, 推断根因的大致位置,以便加速止损。 在相关文献中用到的基础算法包括随机森林,故障指纹构建,逻辑回归,马尔科夫链,狄利克雷过程等方法来进行故障定位。

简单小结一下, 智能运维关键技术落地可以有三种方式。相对独立的算法可以直接落地,依赖其他算法的根因分析可以庖丁解牛,数据条件不成熟的可以退而求其次。

另外从前面列举的那么多的算法例子,大家可以看到的确有很多的算法可以应用到智能运维里面的。

工业界的朋友们可以花一些时间和精力, 简单了解一下这些算法,知道这些算法的输入和输出是什么,能解决运维中哪些实际问题,以及组合起来能解决什么问题,这样会对智能运维更快落地起到事半功倍的效果。

总结与前瞻

智能运维本身前景非常光明,因为它具备丰富的数据和应用场景,将极大提高智能运维领域的生产力,也是 AI 领域尚未充分开采的金库。

智能运维需要工业界和学术界的密切合作,但是目前仍只限于一对一相对低效的合作,少数公司和少数教授的特权不符合我们大的开源开放的趋势。

我们的解决思路就是以科研问题为导向, 从日常工作中找到相关的问题,然后把这些问题分解定义成切实可行的科研问题, 并汇总成智能运维的科研问题库。

同时, 工业界能够提供一些脱敏数据作为评测数据集,这样学术界就可以下载数据,并贡献算法。

我的实验室 NetMan 将会运营一个“智能运维算法竞赛”的网站,汇总智能运维的科研问题库,提供数据下载,并举办智能运维算法大赛。已经有包括美国 eBay 公司在内的多家公司同意为网站提供脱敏的运维数据。

在此非常感谢工业界的各位合作伙伴,也感谢我在清华的团队,NetMan,可以把它认为是在智能运维算法里面的特种兵部队。

最后,与大家共勉:智能运维落地, 前景是光明的,道路肯定是曲折的。在智能运维的领域,我们从去年开始来推动智能运维算法在实践中的落地,我已经行动了一年了,我们还有四年时间。

我相信只要我们有更多的学术界和工业界的朋友参与进来,再加上我们这样的“智能运维算法竞赛”网站的载体,我相信就像 ImageNet 曾经推动深度学习、人工智能的复兴一样,我们一定能推动智能运维算法在实践中更好的落地! 谢谢大家。

51CTO Tech Neo 技术沙龙是 51CTO 在 2016 年开始定期组织的 IT 技术人员线下交流活动,目前仅限北京地区,周期为每月 1 次,每期关注一个话题,范围涉及大数据、云计算、机器学习、物联网等多个技术领域。

【编辑推荐】

  1. 魅族运维进化史:从“远古时代”到“铁器时代”的艰难蜕变
  2. 【免费公开课】赵海兵:运维人员职业规划,如何快速晋升提高收入
  3. 态牛-Tech Neo 6月刊:企业级运维
  4. 从运维角度看中大型网站架构的演变之路
  5. 运维工程师必备的18个网络带宽监控常用命令
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

网络渗透测试——保护网络安全的技术、工具和过程

网络和计算机安全问题已经成为政府、企业必须面对的现实问题。应对安全威胁的途径之一就是采用渗透测试的方法模拟黑客的攻击,找出网络和计...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× 学习达标赢Beats耳机