智能运行怎样一败涂地,从应用研讨角度谈

从科研角度谈“如何实现基于机器学习的智能运维”,科研

      清华大学计算机系副教授
裴丹于运维自动化专场发表了题为《基于机器学习的智能运维》的演讲,现场分享了基于机器学习的智能运维目前面临的挑战和解决思路。以下为演讲实录,今天大概内容包括智能运维背景介绍、如何从基于规则上升到基于学习

     
首先会做一个背景的介绍;为什么清华大学的老师做的科研跟运维有那么多关系?智能运维现在已经有一个很清晰的趋势,从基于规则的智能运维自动化逐渐转为基于机器学习了。再介绍几个跟百度的运维部门搜索部门进行合作的案例;最后,还要讲一下挑战与思路。

一、智能运维背景介绍

     
谈一下参加这次大会的感受,昨天各位讲师们的报告,特别是今天早上几位讲师的报告特别精彩,讲到了在生产一线过程中遇到的各种挑战以及大家的实践和经验,我们又加了运维的群,对于像我这样在科研领域做运维相关科研的工作者来说,感觉找到了组织。

     
介绍一下我的经验,特别是跟海峰老师开场的时候,讲的一个概念是相关的。海峰老师提到说我们做运维很苦,正好我大概在去年这个时候,我在百度的运维部门,讲了一下做运维如何做得更高大上一些,我的题目叫做《我的运维之路》。我们先简单看一下,我个人学术上的官方简历。

     
我读了博士,然后在AT&T研究院实习,AT&T研究院前身是贝尔实验室的一部分,这里面大概有200个博士,有C发明者、防火墙之父,当然我其实没有怎么见到过他们,但是办公室是在一起的。之后在里面做了大概6年时间,发了不少论文,得了一些奖,发表了23项运维相关的专利。然后回清华做了不少科研,这是我的官方简历。

     
实际上我在做什么事情?我就是一个运维人员。在一个30万人的大公司里面做运维,当然主要是通过大数据分析的方法。我读博期间跟美国各种运维人员打交道了五年;在实习过程中,喜欢上了分析实际的运维数据;真正在那边工作的时候,基本上就是一个第五级的运维,做的事情是基于大数据技术管理网络和应用的性能,各种网络协议、IPTV、Video等等。

     
回到清华做科研的时候,开设的也是网络性能管理/应用性能管理相关的课程,所有的科研都是跟运维相关的,在国内有一些合作者,包括百度的运维部门、搜索部门以及中石油数据中心等等。我可以认为自己是一个运维人员,很高兴在这里跟大家分享我们之前的一些经验。

     
为什么说运维是可以做得很高大上的事情?这是一个会议叫SIGCOMM,网络里面最顶级的会议,如果计算机网络的事情是像电影一样,这就是奥斯卡,每年大概录用三四十篇论文,录用一篇,就跟中彩票一样。我们看它的Submission,就是这么多,跟我们运维相关的占了40%。

     
再看评委会,我只列出了AT&T研究院里面的前实习人员和前员工的一些同事们,基本上现在都到大学里当教授了。所以说运维苦不苦,是不是可以做得更高大上一些,取决于怎么做。

     
数据分析机器学习,这是很好的路线。再看评委会,我只列出了AT&T研究院里面的前实习人员和前员工的一些同事们,基本上现在都到大学里当教授了。所以说运维苦不苦,是不是可以做得更高大上一些,取决于怎么做。数据分析、机器学习,这是很好的路线。

     
不光是最顶级的会议,我们还有一个专门做运维相关的会议。这个会议,就是这拨人里面,觉得SIGCOMM这个会一年30多篇,实在是收得太少了,我们再开一个会议,全部都是运维相关的,这是一个顶级的会议,是我科研领域一个主要的战场之一。

      铺垫一下,就是说运维是有很多可以钻研的地方,有很多科研问题。

     
简单介绍一下我在清华大学的实验室,叫NetMan。我的网络管理实验室做的科研,基本上都是跟NPMAPM运维相关的。我们跟互联网公司做一些合作,主要做运维相关的自动化工作,跟SmoothAPP相关的运维工作,跟清华校园网WiFi做一些网络性能优化的工作。我们做了一个核心的基于云的运维算法平台,具体这些运维的应用,下面都有一个核心的算法,再下面还有一个大数据分析的平台,就是常用的各种开源工具。

     
前面所讲的是背景部分。我想要表达的一点,工业界、学术界应该在运维领域里面能够密切合作,各取所需。工业界有很多实际问题,有很多的经验,也有实际的数据,学术界老师们有时间有算法有学生,大家一起结合,这样就会产生很好的效果。

     
值得各位运维界同仁们关注的就是学术界的顶级会议,我比较推荐的是上面图中的这些会议,这些会基本上一年三五十篇论文的样子,简单浏览一下,跟大家做得工作是不是相关,浏览一下最新的会议论文集,看看有没有相关的,还是很有帮助的。美国的工业界,像谷歌Facebook都已经在这些会议上发表过一些论文,包括他们在工程上的一些实践。

二、从基于规则到基于学习

      简单介绍一下智能运维大概的历程,基于规则到基于机器学习

     
我简单回顾一下,我们这个趋势,不光是说我们这个领域的趋势,整个人工智能领域发展的趋势。人工智能也是经历了起起伏伏,最近又非常火。基本历程,就是从基于专家库规则到逐渐变成机器学习,再到深度学习。

      我讲一下几年前基于专家库规则到机器学习的经历。

     
我们在做降维分析的时候,需要一个规则集,什么事件导致另外一个事件,再导致额外顶级的事件,最后倒推回来,什么导致了这个事情。我们当时针对骨干网做的各种事件的关联分析,基本上是基于规则的。当时CDN的性能事件,这个事件导致这个事件,单独对它进行分析,如果这个事件发生,可以通过监测到的各种事件一直推到这儿。当时做出来的时候,起到了很好的效果,发表了论文,审稿评价也很高,也有专利,现在还在非常常规地使用,并且用得很好,效果很好。

     
但是这里面有个问题,规则是由运维人员给出来的,为什么能够运行的很好?因为在网络骨干网上面情况不是那么复杂,网络协议一层接一层,事件比较少,所以比较容易把规则弄出来。

     
我们跟百度进行合作的时候,发现不是那么好做。因为在互联网公司里面,大家都在讲微服务,模块特别多,规模很大,百度这边一百多个产品线,上万个微服务模块,上万台机器,每天上万个软件更新,想通过人把这些规则表达出来,运行到你的系统里,根本就不行,我们试了一下,很快就碰壁了。

     
最后怎么办?我们采用了基于机器学习,把这些规则挖出来。我们在做的过程中不断总结,不断遇到新的问题,实现了基于规则的智能运维过渡到基于机器学习。

     
机器学习本身已经有很多年了,有很多成熟的算法。要想把机器学习的应用做成功,要有数据,有标注数据,还要有工具(算法和系统),还要有应用。对于我们运维领域来说,这几点到底是怎么做的?

     
第一点,是数据。互联网的应用天然就有海量日志作为特征数据,想各种办法做优化存储。在运行过程中遇到数据不够用还能按需自主生成,这是很好的。

     
第二点,是过程反馈。在运维日常工作中还会产生各种标注数据,比如说工单系统,发生一次运维事件之后,具体负责诊断的人员会记录下过程,这个过程会被反馈到系统里面,我们可以从里面学到东西,反过来提升运维水平。

     
第三点,就是应用。做出来的系统,我们运维人员就是用户,我们可以设计、部署、使用、并受益于智能运维系统,形成有效闭环。建模、测量、分析、决策、控制,很容易形成一个闭环。我们能够形成闭环,因为我们有这样的优势。

     
总结一下,基于机器学习的智能运维具有得天独厚的基础,互联网应用天然有海量日志作为特征数据,运维日常工作本身就是产生标注数据的来源,拥有大量成熟的机器学习算法和开源系统,可以直接用于改善我们的应用,所以我个人有一个预测,智能运维在今后若干年会有飞速的发展(待续)。

     
蓦然回首,自开号以来,本号已经创作430+篇文章,自媒体的红海时代已经全然来临(死伤无数),随着百家号、今日头条等知名媒体把推广重点放在娱乐八卦、人体艺术和小视频上之后,技术号生存空间变得更小。本号之所以一直坚持创作,其源动力基本来自几万粉丝精神的支持,如果觉得文章对大家有用,请大家不吝动动手指分享给更多读者(源动力)。也不知道什么时候会停笔,但不到万不得已相信会坚持写下去。

     
利用周末时间(一般都是周末),对“Ceph技术架构、生态和特性详细对比分析”进行了第二版刷新,刷新内容包含Ceph架构,故障机制、后端对象存储演进、Ceph跟Glustre
FS和华为分布式OceanStor
9000产品对比分析。感兴趣的读者可通过原文链接查看详情。

>>>推荐阅读

  • 从高性能计算(HPC)技术演变解析方案、生态和行业发展趋势

  • 存储性能瓶颈的背后,这篇文章带来的参考价值

  • 分布式、多活数据中心如何实现DNS域名解析和负载均衡

  • 传统企业存储厮杀过后,昨天的战场留下什么值得回忆

温馨提示:
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号,获取更多精彩内容。

听说点赞和分享的朋友都已走上人生巅峰了

退而求其次

图片 1

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

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

图片 2

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

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

异常检测

基础模块

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图片 3

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

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

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

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

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

故障预测算法

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

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

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

图片 4

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

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

智能熔断

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

图片 5

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

图片 6

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

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

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

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

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

故障定位算法

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

总结与前瞻

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

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

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

图片 7

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

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

图片 8

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

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

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

图片 9

图片 10

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

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

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

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

图片 11

图片 12

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

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

图片 13

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

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

图片 14

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

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

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

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

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

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

庖丁解牛

相关文章

Comment ()
评论是一种美德,说点什么吧,否则我会恨你的。。。