AIOps的七种武器:让IT基础设施实现“自动驾驶”-阿里云开发者社区

开发者社区> 开发者学习资源库> 正文

AIOps的七种武器:让IT基础设施实现“自动驾驶”

简介: 2019阿里云上海峰会,由阿里云资深技术专家周琦带来以“基于AlOps的探索和最佳实践”为题的演讲。

2019阿里云上海峰会,由阿里云资深技术专家周琦带来以“基于AlOps的探索和最佳实践”为题的演讲。AIOps意味着智能、安全的管控平台,阿里巴巴经过十年的变革在AIOps上有重大探索,那么AIOps究竟能够为大家带来什么益处呢?接下来本文将对AIOps进行详细的介绍。
视频直播回顾
云原生专场PPT下载

以下为精彩视频内容整理:

AIOps 能带来什么?

image.png

现在无人驾驶技术一直备受关注,无人驾驶技术从L1到L5一共有5个等级代表越来越智能的自动化程度,从目标来看,无人驾驶技术希望在安全驾驶的过程中不断去提升整个通行效率,并且降低整个公路的安全隐患,并降低污染的排放。
与无人驾驶类似,AIOps目标是为IT基础设施平台的运转提升效率,提升系统稳定性并解放人在运维上的投入。近几年来,云原生和容器服务使应用、发布、部署的环节效率能够大大加快,但在整个发布和运营的过程中环境的复杂性、应用部署规模、用户多样性等使得整体风险越来越高。AIOps目标就是通过数值驱动手段,在更快的发布效率同时兼顾更低的风险,减少人力投入,使得IT设施具备既快又安全的“自动驾驶”的能力。

飞天研发史:人与机器斗争史

image.png

飞天操作系统是阿里云的基础设施,要知道研发基础平台是一个非常复杂的事情。可以认为就是一部人和机器的斗争史。在第一个阶段,为了能够在大量机器上进行调试,我们使用了大量的监控工具解决可观测性的问题,这个阶段大约需要2个员工管理大小不等的20个集群。
在集群规模从20个变成400个过程中,工程师会花费大量的时间在如何标准化接入、标准化运营上。所以在这个阶段,主要任务就是如何把整个监控和分析能力标准化,接入自动化,本质上是一个把监控+运维工具标准化,服务化的阶段。
在第三个阶段由于集群规模和业务量的不断增大,我们所面临的问题更加复杂,传统手段往往很难解决一些比较复杂的可观测性问题。因此我们使用了大量数据化、智能化的手段进行尝试,获得了较好的结果,每个员工管理集群的和应用的能力,可以达到1:1000或者更高。
云原生和Docker技术解决了一部分运维和发布的负担,但对于个人承担的责任仍然变得越来越大,我们可以把应用上线的过程分成三个阶段:第一个阶段开发人员需要腾出一半的精力测试系统是否稳定、高效,代码是否有逻辑;第二阶段,在整个上线过程中,除了将产品发布以外,还需要花40%的时间在部署和运营上,让用户能够更好的运用产品;第三阶段为上线后阶段,除了运维和运营支撑外,还需要花时间关注安全问题,例如某个系统有没有人登录,登录之后是否做了一些非法操作等。

研发、运维、运营的挑战

image.png

作为研发(DevOps) 如何能在快节奏下做到以上的点呢?我们可以看一条非常著名的法则:海恩法则(Ohain's law)是德国飞机涡轮机的发明者帕布斯·海恩提出的一个在航空界关于飞行安全的法则,多被用于企业的生产管理,特别是安全管理中。海恩法则指出: 每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。法则强调两点:一是事故的发生是量的积累的结果;二是再好的技术,再完美的规章,在实际操作层面,也无法取代人自身的素质和责任心。
我们关注的是第一点,如何建立一套风险的监控、分析、洞察体系。从安全人员角度来讲,安全人员关注的是在集群上线之后有没有非法登录的现象,安全人员需要采集大量的Logs和规则,用来判断是否防火墙被匿名打开过。对于运营人员来讲,无非是把logs内容变成User Click,然后根据用户的增长进行运营。
因此我们可以把常见工作做一个抽象:对运维、安全、运营而言,无论是从监控场景,还是平时用的基于ELK的Logs场景,还是对安全日志建模场景。要做的往往都是四个步骤:数据采集,根据假设建立一套模型获得初步的结果(Event),根据初步结果获得最后的结论,在步骤三和步骤四的过程中需要进行探索性的Drill Down、Roll Up等操作,不断去Refine自己的假设和模型。

可观察性的挑战

image.png

在建立这样一个体系之前,我们结合AIOps场景特点需要解决三个挑战,具体介绍如下:
 更快的响应:对于一个在线服务而言,从观测数据的采集到行动,期待能够在秒级之内完成,这样才能保障快速解决。
 更多的视角:在安全的角度观察的是有没有漏洞;在研发的角度关心的是有没有错误;在运营人员的角度关心的是流失率和用户点击的路径。所以必须要从更多的视角观察数据。
 深入到细节:对数据进行分析时,应该关注数据的具体详情,例如很多细节的状况都需要在秒级才能发现。

统一的数据模型、通用架构、面向分析类的设计

image.png

从平台的架构来看,我们构建了一套面向观测数据(Telemetry Data)的系统,数据源主要分成Tracing、 Metric、Logging三类,将三个数据采集到同一套架构中,运用一套方法论和平台对数据进行查询、分析、聚类和预测。在这个基础上,可以利用开源或者商业的可视化软件,构建一套所见即所得的可视化架构,帮助用户更好的感知业务的形态和细节。

Sec、Dev、Ops 解决问题思路

image.png

系统构建完成后,我们把问题分析和调查的高频场景做了抽象,并提出了7个高频使用的手段,接下来将会对这7种方法进行详细的介绍。

查找:Grep

image.png

GREP是查询问题最频繁的方法,通过这种方式能够快速的找到问题发生的位置。从业界统计《50 Most Frequently Used Unix Command》看,Grep是使用最多的命令之一(排名第一的是tar、第二就是它)。Grep提供了一种“简单暴力”方式过滤掉无用的信息。从业务的视角来看,无论是pssh + pgm方式,还是对Tracing类数据的应用形态进行剖析,或通过开源ELK工具对访问日志的筛选 + 排查,背后都是查找这种方式。

上下文

image.png

当查找到关键点后,我们需要定位关键点的上下文。这个就像调查一个犯罪现场一样,需要看周围的环境,该环境一般对于程序人员而言就是上下文。比如一个程序执行出现错误时,出现问题的上十行和下十行代码很有可能和这个错误相关,比如之前传入的参数,或错误后的执行逻辑等,这些上下文能够有效的帮助程序员找到上下游的线索。

上下文对于不同的应用含义是不一样的:
• 一个错误,同一个日志文件中的前后数据
• 一行LogAppender中输出,同一个进程顺序输出到日志模块前后顺序
• 一次请求,同一个Session组合
• 一次跨服务请求,同一个TraceId组合

例如一个很常见操作是grep拿到文件后,跳转到对应机器用vim打开文件,上下翻阅查查找这些线索。在这个过程中,有不少程序员贡献过一些vim插件帮助标记(不同颜色标记error、info、level等级别)。纵观整个过程,我们为了拿到前后几行的数据,做了很多不必要的操作。

我们把上下文定义如下:在一个最小区分粒度上能够准确还原出最原始的序列,不受日志存储、采集等环节影响。
• 最小区分粒度:区分上下文的最小空间划分,例如同一个线程、同一个文件等。在定位阶段非常关键,能够使得我们在调查过程中避免很多干扰
• 保序:在最小区分粒度下保证原子有序,及时一秒内有几万次操作,也要保证顺序是严格的
image.png

为了有效的找出问题的上下文,我们设计了一套对应的协议。该协议会在所有的采集器、SDK、Appender中统一实现。该协议的主要思想是,在原始日志产生过程中,设置一个单调递增的ID,这个ID使得服务端在乱序存储的情况下,也能够进行全局的排序。通过全局的排序之后,当命中一条错误的日志时,就能够对整个错误日志的上下游进行关联,进而拿到错误的上下文。为了能够更直观的感受上下文方法,接下来举一个案例(视频)。

image.png

案例如图所示,在图中的7月22日中找到线上出现问题的位置,通过上下文快速的浏览这一行错误的上游和下游分别是什么,进而解决对应的问题。

SQL分析

image.png

寻找问题的第三种方式为SQL分析,在稍复杂一些场景中,我们需要对数据进行统计发现其中规律。在Linux理念中,任何复杂任务都是可以用一组命令的组合来达到(运维大法的一个入门的例子就是对Nginx访问日志进行命令行处理)。
例如线上在多次访问后依旧请求失败,若想知道这些请求是来自于哪些运营商,或者来自哪个省市,就需要对线上数据做完基础的查询后,再通过SQL分析得出想要的结果。
我们在查找后构建了一套SQL92语法的分析系统,能够对满足结果的数据进行实时统计,让我们来看以下这个例子,动态根据线上数据进行分析:
“线上有大量错误发生时,我们需要需要对这些错误各维度去聚合,是一个全局的错误?还是一个用户的错误?如果是用户的错误,是来自于某些省市的运营商?还是来自于用户的某个业务?每个推断后都是一个不断变化的SQL”
image.png

聚类

image.png

寻找问题的第四种方式为聚类,在机器学习中就介绍过“聚类”的概念,即数据不需要许多人工制定的规则就能够自动聚集起来。
在过去,如何从正常的数据中判断出异常很依赖于领域专家能力和经验:以系统Latency作为例子,25ms是个绝对数值,只对特定场景有意义:25ms对于一个包大小为4KB 请求偏大,但对于一个2MB 大小的请求是合适的数值。
如何在缺乏领域专家知识情况下如何发现异常? 这时可以借助统计意义上的大数定律:
大数据定律通俗一点讲,就是样本数量很大的时候,样本均值和真实均值充分接近。例如从数据本身的分布规律来比较哪些是异常的。例如通过聚类我们可以快速将“相似”实例汇聚在一起,定位到“小众”的数据(但不一定是异常)。

对错误类的日志,通过关键字找一个错误可能会搜索到几千条相关信息,但其中只有一两条是问题所在的地方,我们需要用很多grep -v排除掉无用的信息。
对整个线上监控类数据也是类似,假设线上有很多实例,若想看一下负载均衡是否起作用,那么只要将这个实例当前的平均CPU拿出来做排序,看一下哪些机器的CPU使用过高即可。
我们根据线上日志类数据、时序数据(Metric)做了两套原生的聚类算法,例如对日之类数据能够自动识别出变量(例如时间、线程Id、实例信息等),把结构化类的Pattern留下代表一类事件,这样就能够排除数量上的影响,让我们找到背后的关键事件。
image.png

以线上为例再进一步介绍聚类方法,选中sys_log搜索数据的结果有3000多条,通过翻页寻找想要的数据非常困难,但是通过使用聚类方法,就能把同一日志里面符合搜索的数据全部选取出来,包括时间、IP等等。3000多条数据通过聚类筛选后只剩20条左右,接着将这20条信息进行对比,判断哪些是新筛选出来的信息,哪些是以前存在的信息。
image.png

对于线上服务器的流量数据, 我们也能够通过形态进行聚类,以诊断出哪些机器的行为与其他不一致,负载均衡是否起了作用。

异常发现(时序建模)

聚类解决了同一时刻不同实例下的异同点问题,但在很多场景下我们没有别的参照系。在缺乏专家经验情况下,一种简单方法是从历史角度来判别。

例如我们可以用环比和同比函数,和昨天(Yesterday),一周前(Week)和月(Month)进行对比,如果差别大于某一个Threshold(例如10%)可以认为是异常。
image.png

这种方法看似简单直观,但面对复杂一些场景就会产生失效情况,例如“标准日历 vs 零售日历”缺陷:
在零售行业中节假日、周末会比工作日带来60%以上营收。因此每个月进行预测时,往往会随着月的大小周(例如5个周末 vs 4个周末)造成比较大的偏差。
image.png

因此对于非平稳序列数据,通过简单同比环比还不够,我们需要对数据规律进行更复杂的建模。例如可以自动排除数据中的噪声,学习数据的趋势、周期等规模,形成一个根据历史数据自动学习的基线。当前数据和基线有较大偏差时,可以认为就是异常。

根因分析

image.png

通过方式五中的异常发现已经能够找出异常,接下来我们需要能找到问题的根本原因(Root Cause Analysis)。 假设工程师收到一条流量下降的告警,有经验的工程师会有一个猜疑链,究竟是用户的问题还是网站的问题。若是用户的问题,分析是城市的问题还是某个客户端引起的问题;若是网站开发版本的问题,判断究竟是移动端的问题还是网页端的问题。若是移动端问题,那么还需要判断究竟时安卓带来的,还是IOS。
一个简单的思路就是统计意义上的“啤酒和尿布”问题-频繁模式挖掘,我们可以创建一张表,这个表能够把所有失败的请求列出来,同时相关属性。接着做一个简单的统计,就能知道在所有错误的日志里哪个属性占的比例较多,在这个例子里面很明显,问题发生在交换机(ASW=DEV1)。
image.png

模式挖掘方法从统计角度考虑频率的维度,如果数据有时间维度的属性,那我们可以有更多Feature可以提升准确性:根因特征对陡升陡降的变化量影响?根因特征贡献的绝对值与相对值?
一个改进的根因分析算法:
1) 线上流量有突增、将异常数据(突增)标记
2) 根据搜索算法计算突增的影响根元素组合相关性
3) 向用户推荐最有可能的组合(行为和整体的流量突增一致)

image.png

领域建模与本体构建

image.png

以上的方法提供了一批适合发现、定位问题的有力工具,但一旦离开了人,这些好比是空中楼阁,因此我们如何把人对系统的经验和认知,能够固化成一种让计算机理解并推断的方式会非常重要,只有这样才能做到最后一公里的完全自动化。

从计算机历史上看,AI在上个世纪七十年代提出后经历过一次小高潮后,受限于数据量和计算规模在90年代后没有大的突破。因此2000后科学家把提升准确性的工作借助另一个方向:
• 万维网之父"Time Bernus Lee" 提出《Semantic Web》概念,希望能让互联网的内容都有标注,具备一定的语义性,从而使得机器能够去理解人类在互联网上留下的半结构化知识,并做更好的推理
• 2003年一篇著名Paper提出也提出了一个概念:构建一张不断更新,能够具备一定推理能力的网络,网络能够自动去识别可能的问题。

2005年后,各公司开始尝试通过知识图谱(Knowledge Graph)把知识更有效组织起来应用在各领域中辅助AI。以人脑为例,很容易解释Knowledge Graph:
• 一个有经验程序员去调查问题时,会有一定的背景知识。例如有大量请求发生错误时,他可能会从脑海里去查找过去是否有类似的现象。当聚焦点到某一个设备时,他可能会从脑海里去考虑设备对应的网络结构。
• 所谓的历史经验,问题所依赖的环境,环境背后的关联等就Knowledge,通过Graph这种结构能够把零散的Knowledge组成一张体系的图谱在脑海中存储。当有一个新问题来的时候,他可以根据过去的经验,问题背景(例如业务的架构)等作为判断因素,快速去做推理和假设。

与这个过程类似,我们正在围绕CMDB、云产品API、容器拓扑结构、Logging、Metric等数据整合一张知识图谱。当有了这张图谱后,我们就可以有机地把上诉各种算法定位的结果进行整合,无论是故障搜索、线上环境的自动检查等,都可以更权威、准确地完成。

AIOps 算法落地场景

image.png

最后总结一下本文提出的几个方法,通过时序数据的算法能够解决趋势预测的问题;通过异常检测能够分析数据的周期性变化问题;通过聚类方法能够帮助数据进行降维;通过根因推导方法有助于搜索整个建模的问题和故障。

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

开发者免费资源中心,技术电子书、会议PPT、论文资料持续供应中

官方博客
官网链接