“如果海洋注定要决堤, 就让所有苦水都注入我心中” —— 下一代智能运维AIOps简述_AI.人工智能讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  AI.人工智能讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 66 | 回复: 0   主题: “如果海洋注定要决堤, 就让所有苦水都注入我心中” —— 下一代智能运维AIOps简述        上一篇   下一篇 
huang.wang
高级会员
等级:少将
经验:8230
发帖:58
精华:0
注册:1970-1-1
状态:离线
发送短消息息给huang.wang 加好友    发送短消息息给huang.wang 发消息
发表于: IP:您无权察看 2018-4-27 14:36:12 | [全部帖] [楼主帖] 楼主

1.png

IT运维,从来都不是一项轻松的工作,无论是从工作强度还是工作复杂度来说,运维工程师所需要承受的压力都不小,但与此同时,运维又是各企业发展过程中至关重要的一环,在企业发展和壮大过程中起到了不可替代的作用。对于一个企业来说,运维工作就是企业的守护,可以分析和控制整个企业IT系统的运转情况,保障企业良好运转,其重要性不言而喻。

近年来随着科技的革新与各种工具的不断应用,运维的工作流程越来越趋于自动化、智能化,在提高整体运维效率的同时,运维工程师的工作压力却似乎并没有减轻。2016年开始,历经过大起大落的人工智能以高姿态重新回到人们的视野,其带来的多项技术变革,迅速渗透到各行各业当中,运维自然也是其中之一。AI的应用进一步优化了目前运维的工作方式,提升了运维工作的整体效果,也为未来运维的发展模式指明了前进方向。接下来,我们抛砖引玉、由浅入深地逐步了解下一代AIOps智能运维,及其对于人工量的减少。

 

运维的定义与发展历程


【传统IT运维的定义与现状】

在谈论下一代智能运维AIOps之前,我们先回顾一下运维最基本的定义——通常情况下我们所说的运维,指的就是对产品及其上运行的系统的运营和维护,其核心目标是将交付的应用业务、系统软件和硬件基础设施高效稳健地整合,转换为可持续提供高质量服务的产品或平台,同时最大限度降低保障运行的成本,确保服务运行的安全。

老式的IT运维管理,其基本工作模式主要是手工运维辅以少量工具,由于缺乏高效的运维机制以及运维工具,导致运维工程师的日常工作就是处理各种简单重复的问题;同时由于在部署中未设置预警或者提示系统,只有当问题大规模出现并导致一定后果时,运维工程师才会被通知去解决,这种工作模式下运维工作人员面对的问题往往比较复杂,同时由于故障处理不及时,造成巨大损失大等事故也时有发生。

这些传统式被动、孤立、手工劳作式的IT运维管理模式使得运维工作事倍功半,一方面导致了IT运维质量的低下,另一方面也使得运维效率不高致使工作量频繁且重复。

 2.png

除了难以让团队满意,运维工程师在工作的过程中往往也是身心俱疲、骑虎难下,曾在网络上看过一个运维工程师吐槽的帖子,讲的主要是运维工程师是怎样看待运维工作的,下面是一些点赞数较多的答案——「运维是块砖,哪里需要哪里搬。不出问题你打杂,出了问题你负责」、「先研发之忧而忧,后业务之乐而乐;起早与贪黑齐飞,调休共假期待定,这就是运维」、「运维就像一场永不休止的战争,时而硝烟弥漫,时而安静的可怕;一个人倒下了,后面的人补上来,没有人能看到这场战争结束」、「机器是女朋友,随叫随到,虐我千百遍,还爱的死心塌地」。

从这些反馈可以看出,运维并不是一份轻松的工作,大体可以归纳为——事多、事杂、休假少。提起运维工程师,很多人都会把他们和“消防员”联系起来,而这种形象的出现也和最初运维的方式——“救火式运维”有很大的关系。后来随着运维环境的改变,数据量的增加,以及系统复杂程度以及集成程度的提高,运维工程师的工作量也将越来越大,传统运维工程师开始面临更多的挑战。

首先,运维人员增速跟不上信息系统规模增长速度。信息系统规模增加,使得同一个系统需要更多的运维人员去维护,人员需求量的快速增加也在某种程度导致了运维人力成本的增长,在单个运维工程师身上的投入也变得更多。尽管如此,由于运维工作的特殊性与辛劳程度,很多人对这份哪怕是某种程度高薪的工作也望而却步,运维人员数量涨幅明显低于市场需求。

3.png

图|运维各领域增长示意图

其次,运维的系统架构转变增加运维难度。现有企业的系统架构,正在慢慢从传统的侧重纵向扩展,以小型机、存储为主的IOE架构,逐步演变成侧重横向扩展、分布式部署,以大量的X86服务器为核心,分布式开源系统架构。这一转变也使得了运维的工作量加大,同时难度指数大大提升。

 

4.jpg

与此同时,运维行业面临的最大的挑战,则是由传统的从“人肉运维”逐步像向“技术运维”发展的过渡。在“人肉运维” 时代,运维人员习惯于“眼前的苟且”,运维模式主要为救火式(被动式)运维,追求稳定、安全、可靠,但运维压力大,通过人海战术来完成工作、倚重运维人员的技能与经验对事故作判断与完善。而在新的“技术运维” 时代,运维人员追求的则是“诗和远方”,运维工作主要采取预防式(主动式)运维进行,运维流程追求标准化、自动化、智能化,化运维压力为开发动力;依托运维技能与经验,由机器提供“持续运维”服务。

 

【运维的发展历程】

随着技术的发展与市场要求的提高,运维的工作方式也逐步在改进,由最初的手动运维模式,逐步演变为更专业与更高效的智能运维模式。从发展历程来看,IT运维的演变大致可分为如下三个基本发展阶段:

 5.png

第一阶段是人工运维阶段;这个时期是IT运维的软件工具、流程初始化的时期,使用工具的目标仅仅只是计算机化,运维的主体工作主要依靠人工完成,运维的流程尚属摸索阶段,还没有形成行业共识。

第二阶段是自动化运维阶段;根据技术成熟度的不同,该阶段又可分为Pre-DevOps阶段与DevOps阶段。

在Pre-DevOps阶段,ITIL、DevOps等理念被提出,其中ITIL强调流程管理质量,而DevOps强调打破开发、测试与运维的边界,这个时期也开始了围绕如何落地DevOps工具链的技术研究,业内就IT研发与运维逐步达成了共识。

其次是目前应用最为广泛的DevOps阶段,此阶段DevOps的工具链已经比较成熟,甚至出现了一些高级形式,比如SRE、ChatOps等,其中ChatOps通过对大量运维工具的封装,构建了一个代理,它认识人类定义的特定文本指令,并按照指令处理问题。这个时期的运维从某种程度上来说可以算作真正的自动化运维,此阶段更加强调从运维流程,运维措施等层面实现完全的自动化,甚至在特定情况下可以实现无人干预。

第三阶段,也就是新一代崛起的运维模式,AIOps阶段。自动化运维给传统运维的效率带来了很大提升,但毕竟系统软件是死的,只能预置和死板的按照人类制定的流程去运行工作,不能自主适应,甚至不能处理“相似”的“新”问题。此阶段恰逢AI重新崛起阶段,人工智能的种种特质对运维当前的一些痛点能提供了良好的解决方案,于是AI被运用和结合到IT运维领域;而且运维与AI有天然的结合优势,不像别的领域,需要有数字采样,比如语音和视觉的数字化转换,但运维领域的日志、配置、操作、脚本、程序等等,天然是计算机友好的,或者就是计算机生成的,是最利于AI处理的一个领域之一。这里举两个方面的例子:

一方面是传统运维时效类的问题:

众所周知,运维的本意是提供稳定可靠的服务,而达成这个目标的关键是足够好的时效。时效类的场景还是很多的,例如更短的MTTR(平均故障恢复时间),特别在服务规模很大的情况下,监控数据的获取/集中/分析,问题的跟踪/定位,恢复的执行规划,如果再加上海量数据和状态频繁变化,AIOps时效普遍会远高于有经验的人+工具。此外,人类有“工作时间”和“工作活力”的限制,自动化依然离不开人的决策,但智能化可以自主决策,当然更进一步的,可以自主学习各种处置经验并且不知疲倦没有脑容量的限制。

另一方面是运维人员协作类问题:

人类的生产离不开协作。尽管有了自动化运维平台或工具链,运维很多场景还是需要许多人工协作。一个经典的例子:业务发现了问题提交工单给IT服务台,IT服务台根据经验初步判断可能与哪些系统相关,再通知相关团队,相关团队判断是否是自己的问题,如果是自己的问题则考虑的修复方案,然后修复,再反馈给IT服务台,通知业务,这其实是个典型的ITIL流程。而采用AIOps时,许多的过程可以自动流转,智能走好分支。

 

【人工智能在运维领域的应用】

虽说人工智能在近几年才开始大规模走进人们视线,被大规模加以应用,但事实上,在运维行业的不断演变中,人工智能从来未曾离开,只是起到的作用和扮演的角色一直在改变。

在运维行业经历了初始、专业化、工具化、平台化、云化和智能化过程中,从手动运维阶段基本没有数据,到规模化、结构化数据和智能化、非结构化数据的趋势。人工智能所扮演的角色也由发展初期充当辅助人类的助手角色,以便提升用户体验、优化生产过程和节省成本,到今天的运维的主要角色,成为新一代运维的主导。

 6.png

1、手动运维阶段

运维工作量小,运维人员主要工作就是看监控屏幕,随着对运维要求提高,工作分工此阶段产生,产生了稳定,便捷,可靠,快速的工作原则。人工智能可以做的是:比如基于人的经验,对结构化日志、配置等数据进行挖掘分析,找出数据中的知识,从而优化脚本等工具。

2、规模化阶段

随着 DevOps 概念的推出,工具大量涌现,来协助运维工作能力的大幅提升,带来问题是很少有一家公司可以生产覆盖所有 DevOps 生命周期的工具,而学习多种不同厂商的工具完成任务带来很高的技术门槛。另外,随着一些创业型公司崛起,运维工作量爆发式增长,为了保证业务的连续性 SRE 也在此时期产生,主要目标是使用软件工程技术实现业务大幅增长而运维工作保持了平稳。人工智能可以做的是:例如比较好的进行迭代、收敛与反馈、逼近工作,确保自动化运维的稳定性以及系统的性能最佳。

3、生态化阶段

随着互联网规模的发展,少数大公司承担起基础设施的工作,通过高度集中提升数倍的运维效率(打个比方,在亚马逊购买1美元的基础设施,可以带来与传统数据中心7美元投资相同的计算能力),这种变革让云计算客户专注于业务的发展,并将基础设施运维交给云计算平台。

市场规模继续增长同时,一个公司无法使用一套解决方案覆盖所有细分市场的需求,生态化从而产生;此时大量的数据恰恰为人工智能实用化夯定基础,人工智能可以做的是:比如不同的公司负责一部分问题形成生态圈,在其中结合新的感知能力辅助人类在巨大数据量、变化的规律中做出各项操作决策。

 

AIOps的定义与应用


【AIOps的概念】

在人工智能再次发展的这几年里,新技术不断地涌现,利用数据科学和机器学习来推进日益复杂的企业数字化进程也变成现实,“AIOps”(Algorithmic IT Operations)因此应运而生。根据Gartner公司的预测报告,到2020年,将近 50% 的企业将会在他们的业务和IT运维方面采用AIOps,占比远远高于今天的10%。而2016年,Gartner就已正式将AIOps定义为新的运维类别,源自业界之前所说的 ITOA(IT Operations and Analytics)。Gartner认为,我们已经到达了这样的一个时代,数据科学和算法正在被用于自动化传统的 IT 运维任务和流程,算法被集成到工具里,帮助企业进一步简化运维工作,把人类从耗时又容易出错的流程中解放出来。人们不再需要在遗留的管理系统中定义和管理无穷无尽的规则和过滤器。

为了更好理解AIOps的概念,可以先理解下AI、机器学习、深度学习这样几个概念。如果用一张图,来表示,就是下图:

 7.jpg

简单来说,AI,人工智能是一个广义概念,最早期提出来的时候,人们的愿景是希望AI能够完全具备人类智慧,这属于“强人工智能(General AI)”。不过在实践中,通常是在某个非常具体和特定的领域,机器逐渐一点点赶超人类,比如下国际象棋的深蓝,下围棋的阿尔法狗;这些人工智能的应用,称之为“弱人工智能(Narrow AI)”,这些应用的实现手段,就得益于机器学习算法长足的进步;机器学习算法只是实现AI的其中一种手段,而深度学习又是机器学习领域很精深的一部分。

了解了上面的概念,再回到AIOps上来,拆分为AI + Ops会准确一些,也就是Ops与AI相结合可以做的事情。虽然Gartner的定义是Algorithmic IT,而不是Artificial Intelligence。

 8.png

但关于定义如何到没有必要纠结,因为不管AIOps里这个AI到底是Algorithmic IT还是Artificial Intelligence,最终,我们根本上使用的,还是机器学习算法这个手段。AIOps涉及的技术,从AI的角度,主要还是机器学习算法,以及大数据相关的技术,因为涉及到大量数据的训练和计算,从Ops的角度,主要还是运维自动化、智能化相关的技术。另外AIOps一定是建立在高度完善的运维自动化基础之上的,只有AI没有Ops,是谈不上AIOps。

通俗的讲,AIOps就是对Ops的AI化,即将人工总结运维规律的过程变为自动学习的过程。具体而言,是对我们平时运维工作中长时间积累形成的自动化运维和监控等能力,将其监控、规则、配置、执行等等部分,进行自学习的“去规则化”改造,最终达到终极目标:“有AI调度中枢管理的,质量、成本、效率三者兼顾的无人值守运维,力争所运营系统的综合收益最大化”;或者说,利用大数据、机器学习和其他分析技术,通过预防预测、个性化和动态分析,直接和间接增强IT业务的相关技术能力,实现所维护产品或服务的更高质量、合理成本及高效支撑。

 

【AIOps的组成与主要作用】

功能方面,根据Gartner定义的AIOps平台拥有11项能力,包括历史数据管理(Historical data management)、流数据管理(Streaming data management)、日志数据提取(Log data ingestion)、网络数据提取(Wire data ingestion)、算法数据提取(Metric data ingestion)、文本和NLP文档提取(Document text ingestion)、自动化模型的发现和预测(Automated pattern discovery and prediction)、异常检测(Anomaly detection)、根因分析(Root cause determination)、按需交付(On-premises delivery)和软件服务交付(Software as a service)等。

 9.jpg

为了更好的理解和落地,可以将前9项能力分别纳入数据接入层、大数据管理层、大数据分析层、应用模块层和可视化展现层,这五层逻辑架构中,各层的功能如下:

数据接入层:通过开放的API接口,广泛接入企业IT系统的历史数据、流数据、日志数据、网络数据、算法数据、文本和NLP文档数据,以及APP数据、浏览器数据、业务系统运营指标数据等不同数据源的数据;

大数据管理层:对业务系统和IT支撑系统产生的结构化和非结构化数据进行统一、高效的存储、管理和调度;

大数据分析层:聚合数据建模、大数据分析能力,实现业务和IT数据的关联分析,通过人工智能对业务波动、故障判断、修复操作等依靠人力决策的环节进行持续学习和自动化响应;

应用模块层:针对基础设施、应用和业务系统之间的逻辑拓扑,提供覆盖全部技术栈的基础设施监控、应用性能管理、业务决策分析以及异常检测、根因分析和统一告警服务;

可视化展现层:以可视化大屏或页面的形式实时展现业务系统运行状态、IT资源利用率等智能运维的关键指标,第一时间发现IT对业务的影响,辅助商业决策。

 

【AIOps的技术难点】

目前,单纯从技术上来说,AI在运维领域深度应用前景广阔,不过落实到实际操作中,至少有如下几个问题需要解决好:

 10.png

1、AI“工程化”的复杂性

目前,机器学习是AIOps的重要手段之一,其他还有自然语言处理,高级搜索,知识图谱等,也需要综合应用到这个领域,才能达成实际工程化的落地效果。换言之,把AIOps认为就是算法落地是片面的;不仅如此,为了解决特定场景的问题,还要“借鉴”或“移植”其他领域的技术和方法,如结合知识图谱,建立微智能知识图谱技术等。

2、高质量,高时效的监控数据的获取

算法的运用是以数据为前提的,尽管经典监控架构已经可以覆盖指标(Metrics),日志(Logging),跟踪(Tracing)三大类数据,但由于每种数据都是各自一套系统捕获,归集,存储,使得数据的时效,对齐,品控的标准有时候难以一致;此外数据格式也可能差异很大,在大数据架构下,还要经过清洗,格式转换,面对海量数据时,时效就会进一步下降。

3、多维度数据的关联难度大

经典监控架构由于采集不统一,即便Metrics也可能来自不同的监控系统,例如面向网络监控,面向主机监控,面向应用监控可能就是三套不同的系统,更不用说Logging,Tracing的数据,这就造成了多维度数据的关联难度大;除时效外,可实时关联的数据是系统能够“接近”甚至“达到”专业人员的任务决策能力的另一个关键。

4、机器学习模型的训练难度

智能运维运用机器学习的重要目标之一就是能够识别故障特征。但是运维SLA的目标是保证系统可用性99.9%。这样的矛盾造成故障在实际运行过程中尽管时有发生,但相对于机器学习需要的样本实在是太少。目前行业一般的解决方案是建立一套与生产相同的仿真环境,它是样本收集,也是训练模型的场所,当然即便如此,也有仿真环境的局限性,有些场景也难以模拟。

5、如何实现运维场景的实时感知

运维的时效性也要求系统的感知足够充分,这里不仅仅是监控数据,之所以运维人员比系统有更强的判断力,在于他们掌握了更充分的运维场景的信息,例如他们清楚网络架构,设备之间的关联关系,物理机/虚拟机分布,应用关联关系,应用技术栈,甚至业务用途等,它们是问题定位,根因分析,影响评估的基础,所以这些信息也要能被实时感知起来,而这一块在传统监控中是缺失的。

6、遗留技术栈,混合架构增大复杂性

不管运维行业,还是其他行业,只要不是新企业,都面临大量的遗留系统,它们在技术栈,架构上可能存在很大差异。因此对它们的感知,数据采集需要额外的投入。另一方面,如果遗留系统还在不停的引入新的业务需求,会进一步引入新的复杂性。

 

下一代运维AIOps智能简述


【下一代智能运维AIOps基本特性】

前文讲述了运维的基础知识以及AIOps的相关概念,相信大家对于智能运维已经有了初步的了解,,那么下一代能够投入实际应用的智能运维系统,应该是怎样的呢?

在智能运维的实际落地过程中,不同于纸上谈兵,更需要考虑到落地运用时所需要面临的各种情境,一个能够落地应用的智能运维产品,至少具备如下几个特征:

11.png

(1)无创接入:对CMDB配置管理中的资源对象以无创(CRAWL、SSH、WMI、SNMP、IPMI等)手段对各类IT组件(业务应用、数据库、中间件、存储、主机、网络安全设备)的性能和健康指标进行定时采集、存储和数据处理。

相比较传统方式(Agent),无创接入(CRAWL\SSH)具有资源占用低、使用便捷、数据无压缩等特点。二者比较来看,传统方式更适合网络、平台资源充足稳定的情况下使用,在Agent代理稳定运行时能稳定快捷获取数据;而无创接入简单易用、高效率、零风险,无需第三方配合,适合大多数场景使用。

1.webp.jpg

(2)智能配置管理:智能配置管理主要包括自动采集、自动更新、自动关联等功能,在业务系统运行的各个环节提供便利。

使用过程中,监控告警模块通过定时作业对CMDB配置管理中的资源对象以无创(CRAWL、SSH、WMI、SNMP、IPMI等)手段对各类IT组件(业务应用、数据库、中间件、存储、主机、网络安全设备)的性能和健康指标进行定时采集、存储和数据处理,根据告警规则生成告警事件,触发告警,以短信、邮件方式通知相关人员;就像下面的智能运维产品监控管理界面:

 2.webp.jpg

(3)灵活插件:一个真正实用的系统,应该能够兼顾各方面的功能,但功能太多难免过于冗杂,有些些特色功能只有特定地人群需要,如果全部集成在同一个系统上难免会造成资源浪费同时影响系统运行速度,而功能插件的使用就很好解决了这个问题,更够根据实际需要选用、安装插件,保障系统功能个同时也不会给系统带来负担。

(4)高效调度:通过个角度视察业务,根据需求和资源情况实现自动调度,通过 “业务” 视角纵向健康检查,覆盖整个业务上下游的关键组件和物理设备;通过“IT组件”纬度,横向覆盖各技术方向维护需求;最后据实际需要,快速交付不同深度、频度、广度的健康巡检。自动巡检异常。此外,在部署使用过程中,一站式裸机部署,高效安装与使用。

 13.png

(5)全面监控:具备独立于OS,接通电源就可以实现对服务器的监控;基于IPMI工业标准,稳定可靠;覆盖几乎所有主流IT软硬件设备,实现了对硬件信息(含CPU温度,电压),主机,存储,等底层硬件的监控处理;全操控大型IDC机房千上万硬件设备一键硬件控制;可替代KVM节约投资;可替代现场人工硬件巡检,节约人力。

 

3.webp.jpg


【下一代智能运维AIOps使用场景】

AIOps围绕质量保障、成本管理和效率提升的基本运维场景,逐步构建智能化运维场景。在质量保障方面,保障现网稳定运行细分为异常检测、故障诊断、故障预测、故障自愈等基本场景;在成本管理方面,细分为指标监控,异常检测,资源优化,容量规划,性能优化等基本场景;在效率方面,分为智能预测,智能变更、智能问答,智能决策等基本场景(注:三者之间不是完全独立的,是相互影响的,场景的划分侧重于主影响维度)。

无论是效率提升,质量监控,还是成本优化,都离不开最基础的数据获取,它是整个AIOp的基石。AIOps提高运维生产力的一种方式就是把质量处理流程中的人力部分尽可能的都替换成机器来做。在机器的分析过程中,系统运行过程中的每一个部件都需要数据支持。无论是海量数据采集、还是数据提取方面都离不开大数据技术。

14.jpg

从数据采集的层面来看,运维数据的采集往往是实时的,数据采集端需要具备一定分析能力,综合考虑用户流量、隐私,服务器压力等多个因素,尽可能的降低无效数据的采集,增加有价值信息的上报。

从数据提取的层面来看,运维的数据是多样化的,历史数据,流数据,日志数据、网络数据、算法数据、文本和NLP文档数据,以及APP数据、浏览器数据、业务系统运营指标数据等,从这些海量的数据中提取出正真有价值的指标化数据并可视化是进一步分析决策的前提条件。

而成本优化和效率的提升同样离不开数据的支撑。例如,开始实施成本优化的AIOPS前,需要尽可能多的收集目前的服务器,网络设备,应用服务,数据库等的性能信息,应用日志(Logging)信息,跟踪(Tracing)信息,以便对成本优化的效果进行评估。例如,在搭建智能客服机器人的时候,充足的问题库和相应的答案才能够建立好一个较优的模型。


效率提升方向

运维效率的提升是运维系统的主要目标之一,自动化运维带来的核心价值之一就是效率提升,而智能运维AIOps会推动运维效率提升到一个新的高度。其本质的原因是自动化运维依然是人+自动化工具的模式,人工决策与实施依然是主要驱动力,但人会受到自身生理极限以及认知局限的限制,无法持续地面向大规模、高复杂性的系统提供高质量的运维效率。而AIOps系统通过深度洞察能力为运维提供持续的,高质量的效率运转。

 15.png

质量保障是运维的基本场景之一,随着业务的发展,运维系统也在不断的演进,其规模复杂度、变更频率非常大,技术更新也非常的快,与此同时,软件的规模、调用关系、变更频率也在逐渐增大。在这样背景下,AIOps则可以提供精准的业务质量感知、支撑用户体验优化、全面提升质量保障效率。

1、智能变更

变更是运维中的一种常见场景,DevOps通过串联变更的各个环节形成流水线提升了效率,而AIOps不仅为变更流水线的各个环节引入了“系统决策”,也能更加持续地,精确地提供高效的变更质量管理。智能变更的系统决策来源于运维人员的运维经验和机器的自我学习,然后转化成系统可操作和实施的数据模型。

AIOps的智能变更可以应对以下场景:

(1)频繁变更,高速发布的场景:运维人员会由于生理极限以及认知的局限难以应付这样的场景。例如,每天从1到10次变更时,运维人员通过自动化运维系统尚可应对,如果由10次升级到100次,甚至更多,就难以高效的,准确的应对了。AIOps可以根据每次变更的目标,状态,上下文在变更过程中及时做出系统决策,帮助加速变更过程以及规避变更可能带来的问题。

(2)大规模并行变更:随着微服务架构的普及,实际上服务节点会成倍增长,原有几个或几十个节点,可能变成几千甚至上万的规模。人工驱动工具的模式不但受制于人的精力而被迫“串行化”,也制约了变更过程的监察以及变更结果验证的准确性。AIOps则可以并行驱动更大规模的变更过程,而且变更监察以及结果验证都会被更准确的完成。

2、智能问答

运维的目标是为了支持稳定,可靠的业务运行,而业务与业务之间既可能有相似性,又可能有差异性。但由于知识背景和对业务的认知差异,往往出现以下情况:

 16.jpg

(1)不同的业务人员或开发人员往往会询问运维人员一些相似的问题,运维人员的答案也是非常类似的,但人力被重复消耗。

(2)面对同一个问题,运维人员的回答可能会出现差异(例如表达方式,措辞等),缺乏标准化,可能造成误解。

AIOps智能问答系统通过机器学习,自然语言处理等技术来学习运维人员的回复文本,构建标准问答知识库,从而在遇到类似问题的时候给出标准的,统一的回复。这样,不仅可以有效地节省运维人员的人力成本,还能够使得提问得到更加及时的回复。

3、智能决策

许多运维管理工作都需要各种各样的决策,包括扩容,缩容,制定权重,调度,重启等内容,那么可能面临如下问题:

 17.png

(1)运维人员可以根据自己的业务经验制定相应的决策。但是,不同的业务有着各自的特点,不同的运维人员也有着自己的业务经验。如何将运维人员的这些经验有效地传承是个问题。

(2)人的认知局限性,运维场景的复杂性可能导致最有经验的运维人员遗漏掉某些“不起眼”的“重要细节”,显然,准确的决策还依赖足够充足的细节。

AIOps智能决策一方面可以将运维人员的决策过程数据化,构建决策支持知识库,从而实现经验积累;另一方面,由于系统掌握了从全局到细节的数据,再结合决策支持知识库,可以为更加准确的决策提供最有力的支撑。

4、容量预测

运维工作不仅仅包含对当下的决策和处理,往往还需要根据业务的诉求对未来做出合理的规划,包括扩容的预测,缩容的预测等。由于对未来的规划时常存在不确定性,那么规划过程往往需要大量的数据来支持,还需要大量的推演来确定。而人工预测的方式,一方面需要投入大量人力,另一方面运维人员的能力可能存在差异,使得推演的结果品质不尽一致。

AIOps智能预测借助大数据和机器学习能力,结合运维人员的有效评估经验,甚至业务发展模式以及政策等,对目标场景实现高效的推演过程,最终使预测结果趋近合理范围。这样一来,不但是人力得以节省,关键在于由于预测效率的提升,使得过去难以重复,耗时耗力的人工预测过程,变得可以应需而变,不断修正预测结果,最终使业务诉求获得最佳预测收益。


质量保障方向

 18.png

质量保障是运维的基本场景之一,随着业务的发展,运维系统也在不断的演进,其规模复杂度、变更频率非常大,技术更新也非常的快,与此同时,软件的规模、调用关系、变更频率也在逐渐增大。在这样背景下,需要AIOps提供精准的业务质量感知、支撑用户体验优化、全面提升质量保障效率。

1、异常检测

运维系统中常见的两大类监控数据源是:指标和文本。前者通常是时序数据,即包含指标采集时间和对应指标的值;后者通常是半结构化文本格式,如程序日志(Logging)、跟踪(Tracing)等。随着系统规模的变大、复杂度的提高、监控覆盖的完善,监控数据量越来越大,运维人员无法从海量监控数据中发现质量问题。智能化的异常检测就是要通过AI算法,自动、实时、准确地从监控数据中发现异常,为后续的诊断、自愈提供基础。异常检测的常见任务包括对数据源的异常检测,保证数据质量,以及对指标和文本的异常检测。

 19.png

数据源异常检测:数据源会因为一些不可避免的原因存在一些异常数据,这些异常数据占比虽然很低,但是往往会引起整个指标统计值的波动,使得统计结果偏离真实的用户体验。AIOps则可以自动、实时的动态设置阈值,去除数据源中的异常数据干扰,并能够区分系统真正发生异常时候的故障数据和数据源本身的异常数据,这种判断依赖于一些外部信息。

指标异常检测:包括单指标异常检测及多指标异常检测。先说单指标异常检测,时间序列指标的异常检测是发现问题的核心环节,传统的静态阈值检测为主的方式,阈值太高,漏告警多,质量隐患难以发现,阈值太低,告警太多引发告警风暴,干扰业务运维人员的判断。AIOps通过机器学习算法结合人工标注结果,实现自动学习阈值、自动调参,提高告警的精度和召回率,大幅度降低人工配置成本。再说多指标异常检测,运维过程中有些指标孤立来看可能并没有异常,但是综合多个指标来看,可能就是异常的。有些单指标表现是异常的,但是综合多个指标来看可能又是正常的。AIOps则可以能够综合多个指标综合评判系统指标异常,提高告警的准确性。

文本异常检测:文本日志常是在特点条件下触发生成的,并遵循一定的模板,即半结构化文本。传统的日志检测有两种方式,一是根据日志级别(如Info、Warning、Critical)进行报警,但由于其设定不准确,或不满足实际需要,导致准确性差;二是通过设置规则,匹配日志中特定字符串进行报警,但该方法依赖依赖人工经验,且只能检测已知和确定模式的异常。AIOps则可以通过自然语言处理、聚类、频繁模式挖掘等手段,自动识别日志出现的反常模式;结合人工反馈和标注,不断进行优化、完善。

2、故障诊断

异常检测实现了运维人员对数据的感知,有了数据之后,智能分析可以进一步解放运维人力,提高运维效率,故障诊断是智能分析的核心部分,主要包括基于人工故障库的故障诊断和基于数据挖掘的故障诊断。

20.png 

基于人工故障库的故障诊断:日常运维过程中,运维人员积累了大量的人工经验,运维过程中的大部分故障都是重复的、人工能够识别的异常。重复问题的定位浪费了大量的人力,而且人工确认过程往往是比较滞后的。AIOps把人工专家经验固化下来,对常见问题实现分钟级内自动诊断,运维人员收到的告警信息中,就需要包括故障定位的结果信息。

基于数据挖掘的故障诊断:人工经验可能存在偏差,人工认为的原因可能并不是问题的根因,当有些故障首次发生没有人工经验可以借鉴的时候,故障根因也难以定位。尤其随着微服务的发展,业务的组网变得更加复杂,模块多带来的消息路由多、依赖多,问题的定界定位分析更为困难,人工故障决策效率挑战巨大。对于已知故障,AIOps能够综合故障数据和人工经验自动提取故障特征,生成故障特征库,自动匹配,自动定位故障;对于未知故障,AIOps则可以根据故障特征推演出可能的故障原因,并在人工确认后加入的故障特征库。

3、故障预测

故障的出现一般不是突然的,就比如网络故障来说,往往从丢包开始到网络不可用是有一个演变的过程,依据海恩法则:每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患,开展主动健康度检查,针对重要特性数据进行预测算法学习,提前诊断故障,避免服务受损;常见场景:磁盘故障预测、网络故障预测(根据交换机日志的交换机故障预测),内存泄露预测等等。

4、故障自愈

21.png 

智能分析实现了故障的诊断和预测,智能执行根据智能分析的结果实现故障自愈。传统的故障自愈的决策主要靠人的经验,人的经验能够覆盖的故障范围是有限的,而且人工无法保证7*24随时可以立即决策与处理。AIOps则能够提供完善的自动化平台,在故障智能分析之后,自动决策,实现自愈,常见场景:版本升级回退,DNS自动切换,CDN智能调度,智能流量调度等。

故障自愈是根据故障诊断的结果的输出(问题定位和根因分析),进而进行影响评估,决定“解决故障”或“恢复系统”的过程。影响评估是对故障之后所产生的影响范围(系统应用层面,业务执行层面,成本损失层面等等)输出评估结果,并根据这个评估来决定要采用什么解决手段,甚至生成解决手段的执行计划。


成本管理方向

 22.png

每个公司的经营都离不开成本管理,成本管理包括成本核算,成本分析,成本决策,成本控制。本文不对财务上的成本管理做过多的阐述,主要从AIOps方向上在成本分析和决策中能发挥的作用来举例说明。AIOps通过智能化的资源优化,容量管理,性能优化实现IT成本的态势感知、支撑成本规划与优化、提升成本管理效率。

1、成本优化

在成本优化方向,需要采取高可用的设计,提供更加合理的服务,包括接入层,业务层,存储层等。在接入层需要提供合理的健康检查机制,更加智能的负载均衡算法,限定流量等工作。在业务层不仅需要去除DB的强依赖,使用合理的降级,还要进行合理的压测,监控以及动态的负载均衡。在存储层需要做的事情是容灾等关键工作。这样的话,可以使得内部数据的质量得到大量提升,外部数据的优先接入和动态选择。

对于设备采集的周期控制这个问题来说,过晚的设备采购可能会影响到业务的正常上线或扩展,而过早的采购也可能造成成本的浪费。于是,AIOps则可以建立合理的模型并建立更好的规划,并据此计算更准确的设备采购计划,也能对成本进行更好的控制。

2、资源优化

公司的运营成本优化项目一直是公司成本预算的关键一步。优化问题包括设备的优化,带宽,码率的优化等等。只有进行了合理的资源优化,才能够使得公司的成本得到有效的控制。不同的服务的资源消耗类型是不一样的,包括计算密集型,包括存储密集型等等,而对于同一个服务在不同的时间点资源消耗也是不一样的。

对于一个企业来说,识别不同服务的资源消耗类型,识别每个服务的资源瓶颈,实现不同服务间的资源复用是降低成本的重要环节。根据资源应用的性能指标,可以大致分类成以下类别:

(1)计算密集型:CPU使用率较高,常见于需要大量计算资源的搜索,推荐,数学计算等场景中;

(2)内存密集型:占用的内存使用率较高,如缓存服务;

(3)IO密集型:网络IO繁忙或者磁盘IO操作繁忙,常见于爬虫,消息管道,分布式存储等服务中。

AIOps通过密度管理、特性管理、碎片管理、木桶管理等方法,优化企业不同服务器的配比,发现并优化资源中的短板,提供不同服务的混合部署建议,最终实现智能化降成本方案分析服务。

3、容量规划

对于一个企业来说,容量的需求和业务的发展紧密相关。为了保障产品的正常运营,就需要对容量进行合理的预估。如果容量预留过多,则会造成资源浪费;反之,如果容量预留过少,则容易引发现网故障。而传统的基于业务运维人员人工经验容量预测手段不是十分有效,甚至大多数是“拍脑袋”的结果。不准确的容量预估也使得运维缩容和扩容显得比较被动。

 23.png

通常来说,大型的企业级传统客户和新兴的互联网公司都会有规模庞大的服务器集群,业务规模增加,新业务上线,过保机器替换都会导致有大量新采购的机器需要上线并扩容到集群中,对于一些特殊场景,如电商网站的大促活动,社交类网站的热点新闻事件等,容量规划更是一件必不可少的考验。活动之后资源往往又需要进行回收缩容操作,以节省运行的成本。

以往的容量规划往往是靠人工经验来操作,现今AIOps将根据业务目标的需求,结合服务数据,整合运维人员的业务经验,建立精准容量规划模型,从而精确预测各个业务的容量,让其使用率达到最优。

4、性能优化

性能的调优一直是运维的重要一环。如果性能优化得当,则会减少实际的运算量,减少内存方面的滥用,提升服务器的性能。运维人员在其中并不能保证及时发现所有潜在的性能问题,很多时候也不知道什么的系统配置才是最优的系统配置,什么时候的权重配比才能够达到最佳的效果。AIOps能够根据现网的实际情况,进行智能地调整配置,智能发现性能优化策略,提供智能化的优化服务。

 

【下一代智能运维AIOps 实施及关键技术】

为了实现成本管理、效率提升、质量保障的场景,在AIOps落地实施过程中,至少应包含如下三要素:

(1)数据:大量并且种类繁多的IT基础设施,用于处理历史和实时的数据;

(2)算法:用于计算和分析,以产生IT运维场景所需要的结果;

(3)运维平台:运维平台是算据的来源,也是算法落地的依托,是整个AIOps的基石部分。

24.png

1、AIOps的数据获取

(1)数据采集

数据采集负责将智能运维所需要的数据接入至AIOps平台,所接入的运维数据类型一般包括(但不限于)日志数据,性能指标数据,网络抓包数据,用户行为数据,告警数据,配置管理数据,运维流程类数据等。

(2)数据处理

针对采集数据进行入库前的预处理,数据从非结构化到结构化的解析,数据清洗,格式转换,以及数据(如性能指标)的聚合计算,处理工作体现在几个方面(鉴于本文篇幅有限,这里就不一一列出,而只是提到了相对比较公知的部分):

 25.png

  1)数据字段提取:通过正则解析,KV解析,分隔符解析等解析方式提取字段;

  2)规范化数据格式:对字段值类型重定义和格式转换;

  3)数据字段内容替换:基于业务规则替换数据字段内容,比如必要的数据脱敏过程,同时可实现无效数据、缺失数据的替换处理;

  4)时间规范化:对各类运维数据中的时间字段进行格式统一转换;

  5)预聚合计算:对数值型字段或指标类数据基于滑动时间窗口进行聚合统计计算,比如取1分钟CPU平均值。

(3)数据存储

数据存储是AIOps平台的数据落地的地方,可以根据不同的数据类型以及数据的消费和使用场景,可选择不同的数据存储方式。数据主要可分为如下几类(限于本文篇幅,这里也只是提到相对比较公知的部分):

 26.png

  1)数据需要进行实时全文检索,分词搜索;

  2)时间序列数据(性能指标),主要以时间维度进行查询分析的数据;

  3)关系类数据,以及会聚集在基于关系进行递归查询的数据,这里选择图数据库;

  4)数据的长期存储和离线挖掘以及数据仓库构建,这里选用主流的Hadoop、Spark等大数据平台。

(4)离线和在线计算

离线计算:针对存储的历史数据进行挖掘和批量计算的分析场景,用于大数据量的离线模型训练和计算,如挖掘告警关联关系,趋势预测/容量预测模型计算,错误词频分析等场景。

2、面向AIOps的算法技术

运维场景除了通用的机器学习算法外,还特定制作了一些面向AIOps的算法技术,并且有时交叉支撑,举几个例子:

 27.png

(1)指标趋势预测:通过分析指标历史数据,判断未来一段时间指标趋势及预测值,公知的可以参看Holt-Winters、时序数据分解、ARIMA等算法;主要用于异常检测、容量预测、容量规划等场景。

(2)指标聚类:根据曲线的相似度把多个KPI聚成多个类别,主要用于大规模的指标异常检测;在同一指标类别里采用同样的异常检测算法及参数,大幅降低训练和检测开销。公知的算法可以参看DBSCAN、K-medoids、CLARANS等,但这些公开算法的主要问题是数据量大,曲线模式复杂。

(3)指标与事件关联挖掘:自动挖掘文本数据中的事件与指标之间的关联关系(比如在程序A每次启动的时候CPU利用率就上一个台阶);主要用于构建故障传播关系,从而应用于故障诊断。公知的算法可以参看Pearsoncorrelation、J-measure、Two-sampletest等,但其实它们的问题为事件和KPI种类繁多,KPI测量时间粒度过粗会导致判断相关、先后、单调关系困难。

(4)事件与事件关联挖掘:分析异常事件之间的关联关系,把历史上经常一起发生的事件关联在一起;主要用于构建故障传播关系,从而应用于故障诊断。公知的算法可以参看FP-Growth、Apriori,随机森林等,但它们的前提是异常检测需要准确可靠。

(5)故障传播关系挖掘:融合文本数据与指标数据,基于上述多指标联动关联挖掘、指标与事件关联挖掘、事件与事件关联挖掘等技术、由跟踪(Tracing)推导出的模块调用关系图、辅以服务器与网络拓扑,构建组件之间的故障传播关系;主要应用于故障诊断。

3、AIOps的主要平台

为了构建具有面向业务价值的运维体系,优秀的平台必不可少。在智能运维落地的过程中,数据的来源、算法的实施与落地等,都需要平台作为依托,平台在某种程度上是智能运维的基础与基石。

首先需要一个很好的AI的内核与实现;比如,新一代人工智能的超维模型:

 4.webp.jpg

再者,需要几个很好的支撑;比如,AIOps落地过程中,主要的平台包括CMBD、监控采集与作业实施这三个平台。

(1)CMBD

配置管理(CMDB)模块,也是资源管理模块,默认是预置的资源模型和拓扑关联关系,资源模型可根据业务需求动态调整,如新增模型、新增模型属性、关联关系等。资源模型管理归纳为二类:应用资源管理、基础资源管理。

资源模型管理主要是对资源模型进行一系列管理操作,包括创建模型、编辑模型、删除模型、模型属性添加、模型属性编辑、模型属性删除、显示实例列表、关系管理、生成资源拓扑等,从而适应业务的需求。

(2)监控采集

前文提到了数据的获取,在得到数据之后,技术数据最直接的使用场景,便是对业务质量的监控和告警。

在构建立体化监控的过程中,收集数据并不是最终的目标,挖掘数据的价值才是体现运维价值所在,一般运维对业务质量保障的定义可以分成一下三个纬度:

 5.webp.jpg

监控——覆盖率、状态反馈、指标度量。监控要争取做到无死角全覆盖,业务出现了什么问题都能发现,有了监控的反馈,可以看到实时监控的状态,同时,当指标发生变化的时候也需要看到一些反馈。

告警——时效性、准确性、关联性、触及率。业务越来越复杂,层次越来越多,每一个监控点都会产生数据指标、状态异常,会造成越来越多的告警。有效的告警分级、追踪、关联、收敛、回溯,是质量建设的重要一环。

运营——RCA、事件管理、统计报表与考核。问题再三出现、必须从根源优化。通过事件管理机制保证RCA可以落地,最后通过报表和考核去给运维赋予权利推动相关优化活动的开展,包括架构和代码的优化等等。

监控采集的主要流程包括CMDB选择资源对象、设定采集频率、配置秘钥以及选择脚本功能。如果一个公司用低层次指标来代替高层次的指标的作用,那质量是很难管理好的。高层次的指标,要能够实时反馈业务的真实状况。在海量规模的业务运维场景下,靠人没办法看到单机的层面,必须要看到集群的层面。这就是面向业务的运维思路与传统的运维思路的显著差异。

智能运维的立体化监控体系,实现统一监控告警平台,提供各层级监控能力。有效结合CMDB中运维对象的关联关系,以面向业务的视角,将低层次的指标收敛为高层次的指标,实现技术运营数据的价值挖掘。

3、作业实施

一个完善的AIOps平台应该包括资产配置、智能监控、工具箱、任务调度等基础功能,以应对日常运维工作的需求。

 30.png

但对于一个优秀的智能运维运维平台,除了需要上述基础工作,更多的需要体现其“智能”的部分,包括故障自愈、日志分析、智能诊断等,这要求平台去更主动地去完成运维任务而不是被动工作,在故障发生之前将其感知并修复。为了达到这些要求,平台必须要有实施能力,否则无法体现AIOps的价值。

其中,故障自愈是根据故障诊断的结果的输出(问题定位和根因分析),进而进行影响评估,决定“解决故障”或“恢复系统”的过程。影响评估是对故障之后所产生的影响范围(系统应用层面,业务执行层面,成本损失层面等等)输出评估结果,并根据这个评估来决定要采用什么解决手段,甚至生成解决手段的执行计划。

另外,故障跟踪是能够实时了解故障自愈、修复的情况,一方面可以实时监测运维工作的进度,另一方面当无法完成自愈时能及时采取其它方式进行处理与修复。

而主动预防则需要针对每个系统建立阈值报警体系,通过“基准线”观察每个系统可用性、流畅度、安全性的指标,凡低于或超过阈值,说明系统无法达到最低要求,则对该系统进行报警提示。

 

结语

随着人类社会进入数字化生存,运维将无处不在,未来的市场规模和市场潜力巨大。而人工智能在运维领域使用的终极目标,主要是在运维过程中减少对人的依赖,逐步以机器代替人海,实现自动的、智能的监控、分析、判断、决策和操作等等。

随着技术的不断进步,AI技术将来会解决很多的一些需要花费大量人力和时间才能解决的事情,但是AI不是一个很纯粹的技术,它需要结合具体的企业场景和业务,通过计算驱动和数据驱动,才能产生一个真正恰到好处的使用。因此智能运维技术在企业的落地,同时需要很多细致的、脚踏实地的定制工作。

就目前来看,智能运维技术已经开启了新运维演化的一个时代,可以预见在后续的岁月中,智能运维会持续地为整个IT领域注入更多新鲜和活力,持续地发展和壮大下去,成为引领潮流的重要力量!

 

人们总是高估未来一到两年的变化,低估未来十年的变革。

——比尔·盖茨

 


该贴被huang.wang编辑于2018-4-27 17:03:23


我超级酷,但是如果你回复我的话我可以不酷那么一小会儿。


——来自logo.png


赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论