您的位置:新葡亰496net > 服务器网络 > 新葡亰496net浙大教师解密AIOps,从应用切磋角度谈

新葡亰496net浙大教师解密AIOps,从应用切磋角度谈

发布时间:2019-06-23 00:18编辑:服务器网络浏览(105)

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

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

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

    一、智能运维背景介绍

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

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

          我读了博士,然后在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”或“扫一扫”下面二维码关注公众号,获取更多精彩内容。

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

    中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会,首次举办的APMCon以“驱动应用架构优化与创新”为主题,致力于推动APM在国内的成长与发展。

    基于机器学习的智能运维

    裴  丹1 张圣林2 裴昶华3

    1清华大学  2南开大学   3阿里巴巴公司

    关键词:机器学习 智能运维

    当代社会的生产生活,许多方面都依赖于大型、复杂的软硬件系统, 包括互联网、高性能计算、电信、金融、电力网络、物联网、 医疗网络和设备、航空航天、军用设备及网络等。这些系统的用户都期待有好的体验。 因而,这些复杂系统的部署、运行和维护都需要专业的运维人员,以应对各种突发事件,确保系统安全、可靠地运行。由于各类突发事件会产生海量数据,因此,智能运维从本质上可以认为是一个大数据分析的具体场景。

    图1展示了智能运维涉及的范围。它是人工智能、行业领域知识、运维场景领域知识三者相结合的交叉领域,离不开三者的紧密合作。

    新葡亰496net 1

    图1  智能运维涉及的范围

    智能运维的历史

    手工运维: 早期的运维工作大部分是由运维人员手工完成的,那时,运维人员又被称为系统管理员或网管。他们负责的工作包括监控产品运行状态和性能指标、产品上线、变更服务等。因此,单个运维人员的工作量,运维人员的数量都是随着产品的个数或者产品服务的用户规模呈线性增长的。此时的运维工作消耗大量的人力资源,但大部分运维工作都是低效的重复。这种手工运维的方式必然无法满足互联网产品日新月异的需求和突飞猛进的规模。

    自动化运维: 运维人员逐渐发现,一些常见的重复性的运维工作可以通过自动化的脚本来实现:一部分自动化脚本用以监控分布式系统,产生大量的日志;另外一部分被用于在人工的监督下进行自动化处理。这些脚本能够被重复调用和自动触发,并在一定程度上防止人工的误操作,从而极大地减少人力成本,提高运维的效率。这就诞生了自动化运维。自动化运维可以认为是一种基于行业领域知识和运维场景领域知识的专家系统。

    运维开发一体化:传统的运维体系将运维人员从产品开发人员中抽离出来,成立单独的运维部门。这种模式使得不同公司能够分享自动化运维的工具和想法,互相借鉴,从而极大地推动了运维的发展。然而,这种人为分割的最大问题是产生了两个对立的团队——产品开发人员和运维人员。他们的使命从一开始就截然不同:产品开发人员的目标是尽快地实现系统的新功能并进行部署,从而让用户尽快地使用到新版本和新功能。运维人员则希望尽可能少地产生异常和故障。但是经过统计发现,大部分的异常或故障都是由于配置变更或软件升级导致的。因此,运维人员本能地排斥产品开发团队部署配置变更或软件升级。他们之间的目标冲突降低了系统整体的效率。此外,由于运维人员不了解产品的实现细节,因此他们在发现问题后不能很好地定位故障的根本原因。为了解决这一矛盾,DevOps应运而生。DevOps最核心的概念是开发运维一体化,即不再硬性地区分开发人员和运维人员。开发人员自己在代码中设置监控点,产生监控数据。系统部署和运行过程中发生的异常由开发人员进行定位和分析。这种组织方式的优势非常明显:能够产生更加有效的监控数据,方便后期运维;同时,运维人员也是开发人员,出现问题之后能够快速地找出根因。谷歌的站点可靠性工程(Site Reliability Engineering, SRE)就是DevOps的一种特例。

    智能运维 (AIOps, Artificial Intelligence for IT Operations):自动化运维在手动运维基础上大大提高了运维的效率,DevOps 有效地提升了研发和运维的配合效率。但是,随着整个互联网系统数据规模的急剧膨胀,以及服务类型的复杂多样,“基于人为指定规则”的专家系统逐渐变得力不从心。因为,自动化运维的瓶颈在于人脑:必须由一个长期在一个行业从事运维的专家手动地将重复出现的、有迹可循的现象总结出来,形成规则,才能完成自动化运维。然而,越来越多的场景表明,简单的、基于人为制定规则的方法并不能够解决大规模运维的问题。

    与自动化运维依赖人工生成规则不同,智能运维强调由机器学习算法自动地从海量运维数据(包括事件本身以及运维人员的人工处理日志)中不断地学习,不断地提炼并总结规则。换句话说, 智能运维在自动化运维的基础上增加了一个基于机器学习的大脑,指挥着监测系统采集大脑决策所需的数据,做出分析、决策并指挥自动化脚本去执行大脑的决策,从而达到运维系统的整体目标(见图2)。Gartner Report  预测AIOps 的全球部署率将从2017年的10%增加到2020年的50%。

    新葡亰496net 2

    图2  智能运维与自动化运维的最大区别是有一个基于机器学习的大脑

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

    新葡亰496net 3

    清华大学计算机系副教授 裴丹于运维自动化专场发表了题为《基于机器学习的智能运维》的演讲,现场分享了基于机器学习的智能运维目前面临的挑战和解决思路。

    智能运维现状

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

    新葡亰496net 4

    以下为演讲实录:

    关键场景与技术

    图 3显示了智能运维包含的关键场景和技术 ,涉及大型分布式系统监控、分析、决策等。

    新葡亰496net 5

     图3 智能运维的关键场景和技术

    在针对历史事件的智能运维技术中,瓶颈分析是指发现制约互联网服务性能的硬件或软件瓶颈。热点分析指的是找到对于某项指标(如处理服务请求规模、出错日志)显著大于处于类似属性空间内其他设施的集群、网络设备、服务器等设施。KPI曲线聚类是指对形状类似的曲线进行聚类。KPI曲线关联挖掘针对两条曲线的变化趋势进行关联关系挖掘。KPI曲线与报警之间的关联关系挖掘是针对一条KPI曲线的变化趋势与某种异常之间的关联关系进行挖掘。异常事件关联挖掘是指对异常事件之间进行关联关系挖掘。全链路模块调用链分析能够分析出软件模块之间的调用关系。故障传播关系图构建融合了上述后四种技术,推断出异常事件之间的故障传播关系,并作为故障根因分析的基础,解决微服务时代KPI异常之间的故障传播关系不断变化而无法通过先验知识静态设定的问题。通过以上技术,智能运维系统能够准确地复现并诊断历史事件。

    针对当前事件,KPI异常检测是指通过分析KPI曲线,发现互联网服务的软硬件中的异常行为,如访问延迟增大、网络设备故障、访问用户急剧减少等。异常定位在KPI被检测出异常之后被触发,在多维属性空间中快速定位导致异常的属性组合。快速止损是指对以往常见故障引发的异常报警建立“指纹”系统,用于快速比对新发生故障时的指纹,从而判断故障类型以便快速止损。异常报警聚合指的是根据异常报警的空间和时间特征,对它们进行聚类,并把聚类结果发送给运维人员,从而减少运维人员处理异常报警的工作负担。故障根因分析是指根据故障传播图快速找到当前应用服务KPI异常的根本触发原因。故障根因分析系统找出异常事件可能的根因以及故障传播链后,运维专家可以对根因分析的结果进行确定和标记,从而帮助机器学习方法更好地学习领域知识。这一系统最终达到的效果是当故障发生时,系统自动准确地推荐出故障根因,指导运维人员去修复或者系统自动采取修复措施。

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

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

    我今天分享的题目是《基于机器学习的智能运维》,下面是今天这个报告的大概内容:

    关键技术示例

    新葡亰496net 6

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

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

    KPI瓶颈分析

    为了保证向千万级甚至上亿级用户提供可靠、高效的服务,互联网服务的运维人员通常会使用一些关键性能指标来监测这些应用的服务性能。比如,一个应用服务在单位时间内被访问的次数(Page Views, PV),单位时间交易量,应用性能和可靠性等。KPI瓶颈分析的目标是在KPI不理想时分析系统的瓶颈。一般监控数据中的关键指标有很多属性,这些属性可能影响到关键指标,如图4所示。

    新葡亰496net 7

    图4 KPI及影响因素

    当数据规模较小时,运维人员通过手动过滤和选择,便能够发现影响关键性能指标的属性组合。但是,当某个关键指标有十几个属性,每个属性有几百亿条数据时,如何确定它们的属性是怎样影响关键性能指标的,是一个非常有挑战性的问题。显然,采用人工的方式去总结其中的规律是不可行的。因此,需要借助于机器学习算法来自动地挖掘数据背后的现象,定位系统的瓶颈。

    针对这一问题,学术界已经提出了层次聚类、决策树、聚类树(CLTree)等方法。FOCUS [1]通过对数据预处理,把KPI分为“达标”和“不达标”两类,从而把KPI瓶颈分析问题转化为在多维属性空间中的有监督二分类问题。由于瓶颈分析问题要求结果具备可解释性,因此FOCUS采用了结果解释性较好的决策树算法。该算法较为通用,可以针对符合图4所示的各类数据进行瓶颈分析。

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

    一、智能运维背景介绍

    一、背景介绍

    KPI 异常检测

    KPI异常检测是互联网服务智能运维的一个底层核心技术。大多数上述智能运维的关键技术都依赖于KPI异常检测的结果。

    当 KPI 呈现出异常(如突增、突降、抖动)时,往往意味着与其相关的应用发生了一些潜在的故障,比如网络故障、服务器故障、配置错误、缺陷版本上线、网络过载、服务器过载、外部攻击等。图 5 展示了某搜索引擎一周内的PV数据,其中红圈标注的为异常。

    新葡亰496net 8

    图5  KPI异常示例:某搜索引擎PV曲线的异常

    因此,为了提供高效、可靠的服务,必须实时监测KPI,以便及时发现异常。同时,那些持续时间相对较短的KPI抖动也必须被准确检测出来,以避免未来的经济损失。

    目前,学术界和工业界已经提出了一系列KPI异常检测算法。这些算法可以概括地分成基于窗口的异常检测算法,例如奇异谱变换(singular spectrum transform);基于近似性的异常检测算法;基于预测的异常检测算法,例如Holt-Winters方法、时序分解方法、线性回归方法、支持向量回归等;基于隐式马尔科夫模型的异常检测算法;基于分段的异常检测算法;基于机器学习(集成学习)的异常检测算法[2]等类别。

    故障预测

    现在,主动的异常管理已成为一种提高服务稳定性的有效方法。故障预测是主动异常管理的关键技术。故障预测是指在互联网服务运行时,使用多种模型或方法分析服务当前的状态,并基于历史经验判断近期是否会发生故障。

    图 6 显示了故障预测的定义。在当前时刻,根据一段时间内的测量数据,预测未来某一时间区间是否会发生故障。之所以预测未来某一时间区间的故障,是因为运维人员需要一段时间来应对即将发生的故障,例如切换流量、替换设备等。

    新葡亰496net 9

    图6 故障预测定义

    目前,学术界和工业界已经提出了大量的故障预测方法。大致可分为几个类别:

    • 故障踪迹。其核心思想是从以往故障的发生特征上推断即将发生的故障。发生特征可以是故障的发生频率,也可以是故障的类型。

    • 征兆监测。通过一些故障对系统的“副作用”来捕获它们,例如,异常的内存利用率、CPU使用率、磁盘I/O、系统中异常的功能调用等。

    • 错误记录。错误事件日志往往是离散的分类数据,例如事件ID、组件ID、错误类型等。

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

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

    谈一下参加这次大会的感受,昨天各位讲师们的报告,特别是今天早上几位讲师的报告特别精彩,讲到了在生产一线过程中遇到的各种挑战以及大家的实践和经验,我们又加了运维的群,对于像我这样在科研领域做运维相关科研的工作者来说,感觉找到了组织。介绍一下我的经验,特别是跟海峰老师开场的时候,讲的一个概念是相关的。海峰老师提到说我们做运维很苦,正好我大概在去年这个时候,我在百度的运维部门,讲了一下做运维如何做得更高大上一些,我的题目叫做《我的运维之路》。我们先简单看一下,我个人学术上的官方简历。

    智能运维所用到的机器学习算法

    在智能运维文献中较为常见的算法包括逻辑回归、关联关系挖掘、聚类、决策树、随机森林、支持向量机、蒙特卡洛树搜索、隐式马尔科夫、多示例学习、迁移学习、卷积神经网络等。在处理运维工单和人机界面时,自然语言处理和对话机器人也被广泛应用。

    智能运维系统在演进的过程中,不断采用越来越先进的机器学习算法。

    基于互联网的视频流媒体(如QQ视频、优酷、爱奇艺、Netflix等)已经逐渐渗透到人们的日常生活中。在网络领域顶级会议中也涌现了很多学术界和工业界合作的智能运维案例,如卡内基梅隆大学的系列工作:SIGCOMM’11论文[3]利用不同数据分析及统计分析方法,灵活使用可视化(visualization)、相关分析(correlation)、信息熵增益(information gain)等工具,将杂乱无章的数据转化为直观清晰的信息,从而分析出海量数据背后的视频体验不佳的规律和瓶颈;SIGCOMM’12论文[4]为视频传输设计了一个“大脑”,根据视频客户和网络状况的全局信息,动态地优化视频传输;SIGCOMM’13论文[5]通过决策树模型建立视频流媒体用户参与度的预测模型,指导关键性能指标的优化策略,最终有效地改善了视频流媒体用户的体验质量;NSDI’17论文[6]将视频质量的实时优化问题转化为实时多臂老虎机(multi-armed bandits)问题(一种基础的强化学习方法),并使用上限置信区间算法(upper confidence bound)有效解决了这一问题。这一系列论文,见证了智能运维不断演进之路。

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

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

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

    智能运维未来展望

    多个行业领域都表现出对智能运维的强烈需求。但是,他们主要在各自行业内寻找解决方案。同时,受限于所处行业运维团队的开发能力,他们往往对所处行业内的运维团队提出相对较低的需求——这些需求一般停留在自动化运维的阶段。如果各行业领域能够在深入了解智能运维框架中关键技术的基础上, 制定合适的智能运维目标,并投入适当的资源,一定能够有效地推动智能运维在各自行业的发展。同时,在智能运维通用技术的基础上,各行业领域的科研工作者也可以在解决所处行业智能运维的一些特殊问题的同时,拓宽自身的科研领域。

    在基于机器学习的智能运维框架下,机器将成为运维人员的高效可靠助手。但是,人的作用仍处于主导地位。在智能运维的框架下,运维工程师逐渐转型为大数据工程师,负责搭建大数据基础架构,开发和集成数据采集程序和自动化执行脚本,并高效实现机器学习算法。 同时,在面对所处行业的智能运维需求时,智能运维工程师可以在整个智能运维框架下跨行业地寻找关键技术,从而能够更好地满足本行业的智能运维需求,达到事半功倍的效果。这种从普通工程师到大数据工程师(智能运维工程师)的职业技能转型对运维工程师是非常具有吸引力的。

    智能运维的基石是机器学习和人工智能。 相比人工智能在其他领域的应用,智能运维几乎完美地拥有一个有前景的人工智能垂直应用领域必备的要素: 实际应用场景、大量数据、大量标注。智能运维几乎所有的关键技术都离不开机器学习算法;工业界不断产生海量运维日志;由于运维人员自身就是领域专家,其日常的工作就会产生大量的标注数据。海量的数据和标注降低了研究机器学习算法的门槛,有益于算法研究快速取得进展。因此,智能运维可以说是机器学习领域一个尚未开采的“金矿”, 非常值得机器学习领域科研人员的关注和投入。

    作为人工智能的一个垂直方向,智能运维的理论也将取得长足的进步。除了互联网以外,智能运维在高性能计算、电信、金融、电力网络、物联网、 医疗网络和设备、航空航天、军用设备及网络都有很好的应用。

    参考文献

    [1]Liu D, Zhao Y, Sui K, et al. FOCUS: Shedding Light on the High Search Response Time in the Wild[C]//Proceedings of the 35th Annual IEEE International Conference on Computer Communications. IEEE Press, 2016:1-9.

    [2] Liu D, Zhao Y, Xu H, et al.Opprentice: Towards Practical and Automatic Anomaly Detection Through Machine Learning[C]//Proceedings of the 2015 Internet Measurement Conference.New York: ACM Press, 2015:211-224.

    [3] Dobrian F, Sekar V, Awan A, et al. Understanding the impact of video quality on user engagement[C]//ACM SIGCOMM Computer Communication Review. ACM, 2011, 41(4): 362-373.

    MLA

    [4] Liu X, Dobrian F, Milner H, et al. A case for a coordinated internet video control plane[C]//Proceedings of the ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication. ACM, 2012: 359-370.

    [5] Balachandran A, Sekar V, Akella A, et al. Developing a predictive model of quality of experience for internet video[C]//ACM SIGCOMM Computer Communication Review. ACM, 2013, 43(4): 339-350.

    MLA

    [6] Jiang J, Sun S, Sekar V, et al. Pytheas: Enabling Data-Driven Quality of Experience Optimization Using Group-Based Exploration-Exploitation[C]//NSDI. 2017: 393-406.

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

    新葡亰496net 10

    实际上我在做什么事情?我就是一个运维人员。在一个30万人的大公司里面做运维,当然主要是通过大数据分析的方法。我读博期间跟美国各种运维人员打交道了五年;在实习过程中,喜欢上了分析实际的运维数据;真正在那边工作的时候,基本上就是一个第五级的运维,做的事情是基于大数据技术管理网络和应用的性能,各种网络协议、IPTV、Video等等;回到清华做科研的时候,开设的也是网络性能管理/应用性能管理相关的课程,所有的科研都是跟运维相关的,在国内有一些合作者,包括百度的运维部门、搜索部门以及中石油数据中心等等。我可以认为自己是一个运维人员,很高兴在这里跟大家分享我们之前的一些经验。

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

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

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

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

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

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

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

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

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

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

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

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

    新葡亰496net 11

    新葡亰496net 12

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

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

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

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

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

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

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

    智能运维的发展历程

    新葡亰496net 13

    二、智能运维:从基于规则到基于学习

    新葡亰496net 14

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

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

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

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

    我讲一下几年前基于专家库规则到机器学习的经历。我们在做降维分析的时候,需要一个规则集,什么事件导致另外一个事件,再导致额外顶级的事件,最后倒推回来,什么导致了这个事情。我们当时针对骨干网做的各种事件的关联分析,基本上是基于规则的。当时CDN的性能事件,这个事件导致这个事件,单独对它进行分析,如果这个事件发生,可以通过监测到的各种事件一直推到这儿。当时做出来的时候,起到了很好的效果,发表了论文,审稿评价也很高,也有专利,现在还在非常常规地使用,并且用得很好,效果很好。但是这里面有个问题,规则是由运维人员给出来的,为什么能够运行的很好?因为在网络骨干网上面情况不是那么复杂,网络协议一层接一层,事件比较少,所以比较容易把规则弄出来。

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

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

    我们跟百度进行合作的时候,发现不是那么好做。因为在互联网公司里面,大家都在讲微服务,模块特别多,规模很大,百度这边一百多个产品线,上万个微服务模块,上万台机器,每天上万个软件更新,想通过人把这些规则表达出来,运行到你的系统里,根本就不行。我们试了一下,很快就碰壁了。最后怎么办?我们采用了基于机器学习,把这些规则挖出来。我们在做的过程中不断总结,不断遇到新的问题,实现了基于规则的智能运维过渡到基于机器学习。

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

    新葡亰496net 15

    机器学习本身已经有很多年了,有很多成熟的算法。要想把机器学习的应用做成功,要有数据,有标注数据,还要有工具(算法和系统),还要有应用。

    新葡亰496net 16

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

    对于我们运维领域来说,这几点到底是怎么做的?

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

    新葡亰496net 17

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

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

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

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

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

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

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

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

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

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

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

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

    三、百度案例

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

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

    下面讲一下实际的案例,这边有三个案例:

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

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

    第一个场景,横轴是时间,纵轴是百度的搜索流量,大概是一天几亿条的级别,随着时间的变化,每天早上到中午上升,到下午到晚上下去,我们要在这个曲线里面找到它的异常点,要在这样一个本身就在变化的曲线里面,能够自动化的找到它的坑,并且进行告警。那么多算法,如何挑选算法?如何把阈值自动设出来?这是第一个场景。

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

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

    第二个场景,我们要秒级。对于搜索引擎来说,就是要1秒的指标,这个时候有30%超过1秒,我们的目标是要降到20%及以下,如何找到具体的优化方法把它降下来?我们有很多优化工具,但是不知道到底用哪个,因为数据太复杂了,这是第二个应用场景。

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

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

    第三个场景,自动关联KPI异常与版本上线。上线的过程中,随时都有可能发生问题,发生问题的时候,如何迅速判断出来是你这次上线导致发生的问题?有可能是你上线导致的,也有可能不是,那么多因素,刚才说了几十万台机器,你怎么判断出来?这是百度实际搜索广告的收入,我们看到有一个上线事件,收入在上线之后掉下来了。

    新葡亰496net 18

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

    下面这个是我们一个学生在百度实习的时候做出来的一个方案,基于机器学习的KPI自动化异常检测。

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

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

    横轴是时间,纵轴是流量,要找到异常。我们要迅速识别出来,并且准确识别出来,帮助我们迅速进行诊断和修复,进一步阻止潜在风险。

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

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

    我们学术界,包括其他的领域,包括股票市场,已经研究几十年了,如何根据持续的曲线预测到下一个值是多少?有很多算法。我们的运维人员,就是我们的领域专家,会对自己检测的KPI进行负责,但是我们有海量的数据,这KPI又是千变万化各种各样的,三个曲线就很不一样,如何在这些具体的KPI曲线里取得良好的匹配?这是非常难的一件事情。

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

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

    我们看看为什么是这样的?有一个运维人员负责检测这样的曲线,假如说要试用一下算法,学术界的常规算法,要跟算法开发人员进行一些描述。算法开发人员说,你看我这儿有三个参数,把你的异常按照我的三个参数描述一下,运维人员肯定不干这个事情。开发人员还不了解KPI的专业知识,就想差不多做一做吧,做完了之后说你看看效果怎么样?往往效果差强人意,再来迭代一下,可能几个月就过去了。

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

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

    运维人员难以事先给出准确、量化的异常定义;对于开发人员来说,选择和综合不同的检测器需要很多人力;检测器算法复杂,参数调节不直观,这些都是存在的问题。

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

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

    所以我们方法的主要思想是,做一个机器学习的工具。我们跟着运维人员学,做一个案例学一个,把他的知识学下来,不需要挑具体的检测算法,把这个事情做出来,根据历史的数据以及它的异常学到这个东西。

    新葡亰496net 19

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

    运维人员需要做什么事情?我看着这些KPI的曲线,这段是异常,标注出来,就有了标注数据。本身就是有特征数据的,提供一下,说你这个小徒弟,你要想把它做好,我有一个要求,准确率要超过80%,小徒弟就拼命的跟师傅学。

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

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

    具体做的时候,比如说KPI的具体曲线,假如说这里有一个异常点,我们把能拿到的理论界上,学术界上的各种算法都已经实现了,它还有各种参数,把参数空间扫一遍,大概100多种,用集体的智慧把KPI到底是不是异常,通过跟运维人员去学,把这个学出来。为什么能够工作?就是因为它的基本工作原理,就是我会学历史信息,学到了之后生成一些信号,对于同样的异常会有预测值,红色是检测出来的信号。检测出来的信号略有不同,但是我们觉得集体的智慧,能够最后给出一个非常好的效果,这就是一个基本的思路。

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

    >>>推荐阅读

    如何把它转化成机器学习的问题?我们有特征数据、有标注,想要的就是它是异常还是非异常,就是一个简单的监督机器学习分类的问题。运维人员进行标注,产生各种特征数据,这就是刚才100多种检测器给出的特征数据,然后进行分类,效果还是比较理想的。

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

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

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

    但是,还是有很多实际的挑战,我们简单提一个挑战。第一个挑战,我们运维人员需要标注,我得花多长时间去标注?在实际运维过程中,那些真正的异常并没有那么多,本身数量相对比较少。如果能做出一些比较高效的标记工具,是能够很好的帮助我们的。如果把这个标注工具像做一个互联网产品一样,做得非常好,能够节省标注人员很多的时间。我们做了很多工作,鼠标加键盘,浏览同比、环比的数据,上面有放大缩小,想标注一个数据,拿着鼠标拖一下就OK了。一个月里面的异常数据,最后由运维人员实际进行标注,大概一个月也就花五六分钟的时间,就搞定了。

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

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

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

    还有很多其他的挑战,比如说历史数据中异常种类比较少,类别不均衡问题,还有冗余和无关特征等。

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

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

    下面是一个整体的设计。

    新葡亰496net 20

    新葡亰496net 21

    那么,拿实际运维的数据进行检测的时候效果怎么样呢?

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

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

    这里拿了四组数据,三组是百度的,一组是清华校园网的。一般的操作,分别对这些数据配一组阈值。我们不管这个数据是什么样的,就是用一种算法把它搞定,就拿刚才给出的运维小徒弟这样的算法,把100多种其他的算法都跑了一遍,比较了一下,在四组数据里面,我们算法的准确率不是第一就是第二,而且我们的好处是不用调参数。超过我们这个算法,普通的可能要把100多种试一下,我们这个不用试,直接就出来。

    新葡亰496net 22

    新葡亰496net 23

    为了让运维更高效,可以让告警工作更智能,无需人工选择繁杂的检测器,无需调参,把它做得像一个互联网产品一样好。这是第一个案例,关于智能告警的。理论上学术界有很多漂亮的算法,如何在实际中落地的问题,在这个过程中我们使用的是机器学习的方案。

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

    我们看一下第二个案例,刚才说的秒级。先看一个概念,搜索响应时间:

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

    新葡亰496net浙大教师解密AIOps,从应用切磋角度谈。搜索响应时间,这个就是首屏时间了。对于综合搜索来说,用户在浏览器上输入一个关键字,点一下按纽,直到首屏搜索结果返回来,当然这里面有一些过程。

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

    这个为什么很重要?这就是钱。对于亚马逊来说,如果响应时间增加100毫秒,销量降低1%。对于谷歌来说,每增加100毫秒到400毫秒搜索,用户数就会下降0.2%到0.6%,所以非常重要。

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

    看一下在实际中搜索响应时间是什么样的?

    工业界-学术界合作

    横轴是搜索响应时间,纵轴是CDF。70%的搜索响应时间是低于1秒,是符合要求的。30%的时间是高于1秒的,是不达标的。那怎么办呢?大于1秒的搜索原因到底是什么?如何改进?这里面也是一个机器学习的问题。各种日志非常多,答案就藏在日志里面,问题是如何拿到日志分析出来。我们看一下日志的形式:

    1.0:一对一交流合作

    对于用户每一次搜索,都有他来自于哪个运营商,浏览器内核是什么,返回结果里面图片有多少,返回结果有没有广告,后台负载如何等信息。这次响应,它的响应时间是多少,大于1秒就是不理想,小于1秒就是比较理想,我们有足够多的数据,一天上亿,还有标注,这个标注比较简单了。

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

    我们现在来回答几个问题,在这么多维度的数据里边,如何找出它响应时间比较高的时候,高响应时间容易发生的条件是什么?哪些HSRT条件比较流行?如果找出流行的条件,我们就找到了一些线索,就知道如何去优化。我们能不能在实际优化之前,事先看一下,有可能优化的结果是什么?基本上想做的就是这么一个事情。这里面有些细节我们就跳过,想表达的意思是说对于多维度数据,如果只看单维度的数据,会有各种各样的问题。

    新葡亰496net 24

    在分析多维属性搜索日志的时候也会有很多挑战:

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

    第一,单维度属性分析方法无法揭示不同条件属性的组合带来的影响。

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

    第二,属性之间还存在着潜在的依赖关系,所以单维度分析的结论可能是片面的。

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

    第三,得到的HSRT条件可重叠,每次HSRT被计算多次,不易理解。你如果单维度看,图片数量大于30%,贡献了50%的响应时间,看一下其他的维度,加起来发现120%,这都是单维度看存在的问题。

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

    因为每个维度有各种各样的取值,一旦组合,空间就爆炸了,人是不可能做的,就算是做了可视化的工具,人是不可能一个个试来得出结论,必须靠机器学习的方法,所以我们把这个问题建模成分类问题,利用监督机器学习算法,决策树得到直观分类模型。

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

    下面这个是我们当时设计的一个架构图,每天日志来了之后,输入到机器学习决策树的模型里面,分析出每天高响应时间的条件,跨天进行分析,之后再去做一些准实验,最后得出一些结果。

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

    下面这个是我们第一步完成了之后,得出的一个决策树,生成决策树的过程,基本上拿一些现成的工具,把数据导进去,调一些参数就OK了。

    2.0:开源开放

    我们会看一个月的时间内,每天都获得的数据,我们得出一个月里面,哪些条件比较流行,然后,在此基础上,做一些准实验。不是说分析出来了之后,就真的上线调这些优化条件,比如说得出这样的组合,当图片数量大于10,它的浏览器引擎不是WebKit,里面没有打广告,它会容易响应时间比较高。给了我们一些启示,具体哪个条件导致的?优化哪个维度会产生比较好的结果?这不知道。我如果把每个条件调一下,这个大于10,变成小于10,这个条件的组合,在实际的日志数据里面就是存在的,把这个数据取出来,看一下它的响应延迟到底是高还是低,这就是准实验,诸如此类都做一些,很容易得出一些结论。

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

    我们针对当时的场景,图片数量过多是导致响应时间比较长的主要瓶颈,是当时最重要的瓶颈,具体对这个进行了优化,大家可能就比较熟悉了,部署了base64 encoding来提高“数量多、体积小”的图片传输速度。

    新葡亰496net 25

    这里想强调一点,这个优化方式,大家都知道,但是在没有这样分析的情况下,你并没有把握上线之后,就有效果。假如说你运维部门的KPI指标,超过20%就不达标,如果低于20%就达标了,上线这一个就达标了。各种比较都很清晰,就是这样的一个工具,有很多日志,你做一些基于机器学习的分析,找到目前最重要的瓶颈,把这些瓶颈跟拿到手的各种优化的方式方法,应用一下,就能得到很好的效果,这个效果是很不错的,通用性也比较高。

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

    第三个案例跳过去吧,大概意思是说自动更新会产生很多问题,我简单直接把案例给出来就好了。

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

    最后给出一个案例,这个案例就是说百度上线了一个反点击作弊的版本,上线之后,广告收入就出现了下降,实际上用我们这个系统做了一下,10分钟能够准确检测出问题。而人在具体做的时候,要客户申述、检查KPI、定位问题,要一个半小时,差异还是很大的。

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

    刚才举了几个具体的案例,其实还有其他的很多案例:

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

    异常检测之后的故障定位

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

    故障止损建议

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

    故障根因分析

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

    数据中心交换机故障预测

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

    海量Syslog日志压缩成少量有意义的事件

    新葡亰496net 26

    基于机器学习的系统优化(如TCP运行参数)

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

    我们在学术界来说,我们也不做产品,我们是针对一线生产环境中遇到的各种有挑战性的问题,做一些具体的算法。我们的目标就是做一些智能运维算法的集合,运行在云上面,它会有一些标准的API。标准的API支持任意时序数据,它有一个时间戳,有一个关键指标,这个关键指标针对不同场景会不一样,有销售额、利润、订单数、转化率等等不同属性,经过这样的分析之后,跑到云里面,就能得出一些通用性的结果。

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

    四、挑战与思路

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

    这里我想给大家一些具体的启示,包括我们自己的一些思考。

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

    智能运维到底有哪些可行的目标?我们的步子不能迈得太大,又不能太保守,我们到底想达到什么样的效果?谁拿着枪,谁就处于主导地位。像R2-D2是运维人员的可靠助手,最后还是人来起主导作用。

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

    很重要的就取决于人工智能本身发展到哪个地步,下面是我们清华大学张院士的一个报告。第一个图中人工智能解决了一些问题,知其然,又知其所以然。第二个图是知其然,不知其所以然,这个棋我知道它下的好,但是为什么好,计算机算出来的,我并不知道。人工智能发展到现在的阶段,比较可靠的是这个地步:知其然,而不知其所以然,技术方面,通过机器学习相对成熟,在一定条件下比人好。到后面既不知其然,又不知其所以然,以及连问题都不知道,人工智能还没有到那个地步。我们要自动化那些“知其然而不知其所以然”的运维任务。

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

    2、如何更系统的应用机器学习技术。机器学习纷繁复杂,简单说一下。特征选取的时候,早期可以用一些全部数据 容忍度高的算法,如随机森林,还有特征工程、自动选取(深度学习);不同机器学习算法适用不同的问题;一个比较行之有效的方法,大家做日常运维过程中,可以跟学术界进行具体探讨,针对眼前问题一起探讨一下,可能比较容易找到适合的起点。工业界跟学术界针对具体问题进行密切合作是一个有效的策略。

    新葡亰496net 27

    3、如何从现有ticket数据中提取有价值信息。我们可以把ticketing系统作为智能运维的一部分来设计。

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

    4、如何把智能运维延伸到智能运营?我们有各种各样的数据,数据都在那儿,企业的痛点是,光有海量数据,缺乏真正精准的运营和行动之间有效转化的工具。其实我们思考一下,我们看的那些KPI,如果抽象成时序数据,跟电商的销售数据,跟游戏的KPI指标没有本质的区别。如果抽象成算法层面,可能都有很好的应用场景,具体还会有一些额外的挑战,但是如果在算法层面进行更多投入,可以跳出运维本身到智能运营这块。

    这些算法分为三种:

    总结一下今天的报告。

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

    基于机器学习的智能运维,在今后几年会有飞速的发展,因为它有得天独厚的数据、标注和应用。

    基础模块

    智能运维的终极可行目标,是运维人员高效可靠的助手。

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

    智能运维能够更系统应用机器学习技术,学术界和工业界应能够在一些具体问题上密切合作。

    KPI 瓶颈分析算法

    更系统的数据采集和标注会帮助智能运维更快发展

    新葡亰496net 28

    下一步把智能运维的技术延伸到智能运营里面。

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

    感谢各位同学听我的报告,非常感谢各位合作者,包括百度的搜索和运维部门,谢谢大家!

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

    Q&A

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

    Q1:第一个案例中有标注过程,您做了一个工具加速了标注,我想问一下,因为您后来说你们的准确率已经达到100%了。

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

    裴丹:没有到100%,是说它性能比别的好,取决于不同的情况70%、80%、90%的都有。

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

    Q2:做到80%、90%的标注,标注样本有多少数量级?另外,肯定要持续运行,一共运行了多少个月达到80%多?

    新葡亰496net浙大教师解密AIOps,从应用切磋角度谈。故障预测算法

    裴丹:标注样本一个月大概十几个、几十个。一共大概运行了七、八个月,我们还在做另外一件事情,人工地注入一些异常,根据历史数据学到异常的特征,人工注入,让运维人员能够进行标注。

    新葡亰496net 29

    Q3:人工注入是百度在线注入?可以手工去改吗?

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

    裴丹:历史数据注入,可能在线注入。不能手工改的,是load到标注界面里去的。

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

    Q4:特征提取和特征工程您是分开来说的,特征工程是指一些方法特征?还是什么意思?

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

    裴丹:主要是推动各种统计方法学选哪些特征应该用在机器学习模型里,以及对哪些特征进行转换。

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

    Q5:刚才咱们那些所谓的算法都是已知算法?还是说我们能够在这里面自己学习一些算法?

    庖丁解牛

    裴丹:我们现在正在用卷积神经网络等,通过深度学习的方法,数据来了,我就把它自动学出来了,不用已知的算法。

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

    Q6:刚才咱们那个采样,很多都是指定的关键数据,关键数据的筛选能不能也是智能化的去做?

    新葡亰496net 30

    裴丹:这倒是一个很好的方向,目前还都是运维人员比较关心,并且已经检测了的数据,数据已经采集上来了,我们做监控和异常检测。下一步可以朝您刚才说的方向去做一下尝试,就是说如何动态的、智能的去选取检测哪些KPI,目前还没有做这方面的尝试。

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

    Q7:咱们现在所有的数据都采集上来以后,是挑选了一些影响最大的数据进行处理和分析的吗?

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

    裴丹:刚才说的是,凡是已经进行监控的这些KPI,我们刚才听到几位老师介绍的,基本上可以监控的都监控,我说的进行智能的异常检测是已经监控的KPI里面做更好的工作。

    异常检测

    Q8:是有动作的成分了吗?

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

    裴丹:这个动作的成分是在很早之前发生的,没有数据,我也没法异常检测,数据已经被采集了,前面做了很多大量的基础工作,我们就常规采集了数据进行检测就行了。

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

    新葡亰496net 31

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

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

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

    新葡亰496net 32

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

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

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

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

    新葡亰496net 33

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

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

    新葡亰496net 34

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

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

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

    故障传播链

    新葡亰496net 35

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

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

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

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

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

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

    新葡亰496net 36

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

    新葡亰496net 37

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

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

    退而求其次

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

    智能熔断

    新葡亰496net 38

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

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

    异常报警聚合算法

    新葡亰496net 39

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

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

    故障定位算法

    新葡亰496net 40

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

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

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

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

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

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

    总结与前瞻

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

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

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

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

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

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

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

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

    本文由新葡亰496net发布于服务器网络,转载请注明出处:新葡亰496net浙大教师解密AIOps,从应用切磋角度谈

    关键词: