智能运维就是由 AI 代替运维人员?

听了有关AI运维之后有很多人感到比较焦虑,我所从事的运维或开发将来会不会被AI给替代掉呢?

现在新技术发展的特别快,各种语言、技术、理念让大家确实感到自顾不暇跟不上趟,但是有一点,在这里我要特别重申一下,AI在目前这个阶段还是一种辅助大家来进行判断和学习、定位处理问题的工具,就像无人驾驶,现在可以做到完全没有人驾驶吗?肯定不行,未来无人驾驶是完全可以替代人的,但它还有很长一段路要走。AI运维就像无人驾驶一样,未来前景很光明,但任重道远。

大部分的智能运维还没有完全落地,我所在的企业也是处在一个探索的阶段。在一个传统的企业它的运维该如何走?从以前的脚本到工具、自动化,再到现在的智能运维,中间这个步骤该怎么走?今天就从下面五个方面给大家分享下:

一、构建一个全面科学的IT运维管理体系

第一个IT部门的整体认可不足。虽然说IT在任何单位现在都是一个比较重要的部门,但是还有很多领导仍然认为它是一个成本中心,不是一个利润中心,认为这个部门是花钱的,而不是像业务部门创造业务价值和创造利润的。

第二个对于运维工作人员负荷比较大,工作模式不被员工认可。在没有自动化运维和平台之前,整个运维团队只有八个人,如果每个人一天处理六到十个故障,基本上没有时间去研究别的东西了。传统运维压力很大,疲于奔命和救火,必须要寻求改变,走向自动化、平台化、智能化。

第三运行的态势相关信息掌握不足。监控是多维度的,不同的业务会有不同的指标,所有加起来有上万个指标,但却没有整体态势变化图、很难成体系,不能实现智能感知和态势预测,整个运维态势就很难保持平稳。

第四依据业务需求调整服务和设置资源的能力不足。在业务故障处理的时候需要很长的过程,中间涉及到很多的相关技术部门,需要和业务方进行交互,仅靠较少的人力几乎做不到。
    ![](http://i2.51cto.com/images/blog/201801/10/0460aaff04210aabddb4772308cc57c6.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

我们希望在现有的业务体系里面,运维部门要实现这样的运维目标?

第一个全面的性能管理。能够提供对现在所有的设备和服务质量进行实时监测,并且提供动态阈值的告警。

第二个统一的资源管理。很多企业业务都上云了,需要有统一的监控平台,可以把所有业务相应资源视图抓取出来,便于我们对整体资源有一个合理的预估和分配,并从整体角度评估各个业务部门对资源的使用情况。

第三个及时的故障告警管理。我们发现有很多产品还不能做到完全及时的告警,告警发生后总是延时才能知晓,需要实时的准确的告警,减少延迟和误报。

第四集中统一展现管理。把很多不同的监控子系统集成起来,这个在现在的企业里面需求是很大的,借助于各种工具,采集数据之后自动合成一个报表统一展现出来,方便管理。

我们关注的核心问题有:

第一我们是一个跨地域的平台,是多数据中心,我们希望有一个IT的综合运维平台,来统一管理。

第二是深入监控并进行集中统一的可视化管理,提高效率。

第三就是有效的预防问题的产生,降低运维成本。另外就是问题出现后,能够快速跟踪定位,降低人力成本。

第四多维的报表为决策提供有力支撑,科学预判趋势。

第五全局业务服务视角和平台化扩展以及大数据分析的融合,满足企业对于业务高效和快速迭代的需求。

第六保护和优化IT资产。以前各个业务都是自己的一套系统,有自己的开发和运维人员以及监控系统,这对企业来说是重复造轮子了。现在上云后,把原有的系统集中整合到云上,通过统一的监控和资源管理最好的保护和优化资产。
    ![](http://i2.51cto.com/images/blog/201801/10/c3383ffc0cef71ce54b306e258498989.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

要做好智能化运维之前,我们经过深入的分析,提了四个要求:

第一个是规范化。规范化就是尽可能的把操作规范下来,比如模板里是什么基础配置和安全基线,有一个规范化的标准。

第二个是可控性。就是能够通过云监控平台发现各个业务存在的瓶颈,包括资源瓶颈和性能瓶颈,对可能产生的问题可控可分析。

第三个是数据化。基于海量数据的决策分析,才能方便作出准确的判断和科学决策。

第四个是主动性。从被动响应变为主动服务,主动发现问题,把问题消灭在萌芽中,在业务发生问题之前及时告知,这个感觉就不一样了。

我们希望构建现代化和智能的运维管理模式,主要是以下5个方面,如下图:

二、全景业务服务管理

在互联网大爆炸时代,国家层面上也在提互联网+、数字化转型、智能化等等。我们的系统能不能快速响应,为业务保驾护航?

面向业务的IT服务管理主要有这几个特点:

1、监控的粒度要细,能通过一个曲线捕捉到异常点。

2、面向业务管理和面向用户管理。这块要区分开来,在企业里用户权限分的是比较细的,什么人可以操作什么样的业务,管理员可以管理哪几类业务都有清晰的定位。

3、数据的全面和扩充性。数据只有全面才能进行科学的决策,很多时候如果看到的日志不全,或者拿到的监控数据不准,在做决策的时候肯定就会比较贸然。比如数据中心某业务链路出现问题,是不是要切换?数据是不是还能保持一致?这个时候在没有确定的数据来支撑你决策之前,你做决策时都会感到比较忐忑,犹豫不前。
    ![](http://i2.51cto.com/images/blog/201801/10/18f2853202a956ebb188843943561d1b.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

建立以业务为导向的综合监控平台,主要目的就是要统一展现、统一管理和统一调度。全链路监测,这个目的就是从访问入口进来后一直到数据出去,每一个过程都要能监控到感知到。

从业务的视角进行IT基础资源的管理与维护,一旦某个资源发生故障或问题,都可以从业务视图中直观地了解到这个资源的故障将影响什么业务影响哪些服务,进而了解到影响哪些用户。

数据库慢了,CPU突然飙升了,这些地方这些资源突然发生变化了之后,影响到哪些业务呢?这时候就需要将监控资源视图和业务关联起来,这样才能准确定位影响了哪些业务。

这个是问题的整体诊断和分析。

任何问题都需要采集相关的日志和数据,才能科学全面的分析问题。

采集层需要把不同数据源的数据采集过来,中间层做一些性能分析,配置管理和预警分析、告警处理。展示层将分析的结果展示出来,也就是各种图表,建立综合的业务指标分析,方便根因定位和解决问题。

三、基于大数据平台的日志分析和多维报表

基于大数据平台,提供日志的采集和聚合处理,通过日志关联分析帮助准确全面定位提升效能和满意度,智能预测和预警,为科学决策提供量化依据。

将采集到的网络监控数据、机房数据、服务器和云环境监控数据以及摄像头报警数据集中起来,数据汇集之后生成PMDB性能管理库,在根据业务应用的特征,建立不同的模型进行相应的算法分析。

根据不同的资源类来定义KPI指标,建模目的就是方便快速分析,为资源管理、告警管理、集中化展现等其他模块提供数据分析模型的支撑。

数据采集有两种类型,一种是被动的,一种是主动的。

采集业务相关指标,可以对数据进行预处理,做一些有效性的标签识别,比如这个信息和指标是不是你关注的,对不友好的日志进行格式化处理。

性能指标的计算,要跟业务进行协同,从业务的角度来定义。设置的

阈值,有些场景是固定的,也有的场景是动态的。固定阈值就相当于资源使用率,肯定有一个上限的。动态阈值像一些性能曲线,CPU的利用率、页面响应、图片加载等这些是可以使用动态阈值的,根据历史数据来计算出这个动态阈值,某一时刻的历史峰值,根据这些合理计算出在那个时刻到底需要多少资源。

根据上面的阈值会有一个报警的事件,任何事件产生都是基于时间的,故障的定位肯定也要基于时间找到相关的日志和发生的事件。

事件诊断一直是运维领域一个很重要的工作,事件和时序的相关性不仅可以为事件诊断提供很好的启发,而且在帮助我们进行根因分析时也能提供很好的线索。某个时间段出现的故障,都会产生一些相关的事件,对它们进行筛选和过滤是能够详细捕捉到故障和定位到根因的。

在事件诊断和处理中,是不是需要引入算法,我觉得是有必要的,如果能提高效率和提高解决问题的能力,一切探索都是值得的。

也有一些运维界的朋友们花了很多时间和精力,去学习和研究算法,我认为不必过于纠结算法, 简单了解一下开源的这些算法,知道这些算法的输入和输出是什么,能解决运维中哪些实际问题,以及组合起来又能解决什么问题,方便我们合理的应用它就可以了,这样会对更快落地智能运维起到事半功倍的效果。

数据的汇聚处理就是把采集到的数据有机的关联起来,压缩、过滤形成标准化的信息。数据导入则可以通过全量的HDFS和增量的Kafka来实现。

基于大数据平台的多维报表,根据自己的需要,按照日、周、月来生成运维报告,发送给管理层的领导,这些数据是他们比较关心的,比较清晰的图示出在这些时段发生了哪些问题,造成了多大面的影响,然后决定相关的资源是否进行扩充,相应的业务部署是否需要调整。

综合展示比较关注的则是性能分析、容量分析和自动化配置。比如今年采购了500TB存储,我用了多少,明年还需要扩容多少,业务增长量会有多少,这个都影响到企业的采购计划。根据业务的实际进行评估,来推算出明年大概需要买多少TB的存储。

四、IT监控管理平台发展

IT监控管理的发展大概有三代,从上世纪九十年代至今,第一代是以网络为中心,在这个时期咱们提供比较多的都是基于网络的监控和故障发现,带宽管理和服务水平协议。

第二代监控就是以监控IT基础设施为中心,看到比较多的就是主机、存储、操作系统、中间件、数据库等各类基础资源的监控。

第三代监控以IT应用为中心,针对比较高度复杂的交易,需要实现面向用户体验和面向应用高可用性的实时监测和故障的智能诊断,运维人员必须高屋建瓴、全面谋划,有能力提供一个全局性、高效健壮、标准规范、自动化的监控解决方案并加以实现。

五、故障管理及自治自愈

这是我们每天收到的告警情况统计,在没有自动化和智能化之前,我和大家一样心态是焦虑和崩溃的。

如何从错综复杂的运维监控数据中得出我们所需要的信息和结果,一句话就是分辨和精炼,提取真正需要关注的信息,从而减少每天的告警信息量。

目标就是简、智、深。

简就是要确保业务和SLA服务级别,出现问题要及时响应、自动分析和优化,把处理的流程精简和高效组合起来,让问题匹配正确的场景,找到正确的人,在第一时间正确处理。

机器学习主要就是突出智,这个需要大量的数据来训练,故障出现的形态是千奇百怪,对故障的历史数据进行场景分类和标注,不断用模式识别和数据来训练机器识别和分析,然后让机器自动准确判断。

当然标注不能完全靠人,也需要通过机器来自动进行关键词标注,而标注的合理性就需要人为进行判断,然后再利用到机器学习上,这样才能真正辅助我们做一些决策。

基于架构、工程师的经验和概率来做到收敛告警事件,基于规范和分工产生告警事件发送到对的人,基于数据和模型来提高事件的处理能力。很多事件有的工程师处理的特别快,反之如果对这个故障不熟悉的人可能花费的时间就很长。这就需要构建一个策略知识库,让其他人来参考和学习,提高同类场景事件处理的能力。

智能运维的终极,实现的目标就是减少对人的依赖,逐步信任机器,实现机器的自判、自断和自决。

技术都是在不断的进步,AI技术将来会解决很多的一些需要花费大量人力和时间才能解决的事情,但是AI不是一个很纯粹的技术,它也需要结合具体的企业场景和业务,通过计算驱动和数据驱动,才能产生一个真正可用的产品。

智能运维技术在企业的落地,不是一蹴而就的,是一个渐进和价值普及的过程。

我们可以看到,智能运维技术已经成为新运维演化的一个开端,可以预见在更高效和更多的平台实践之后,智能运维还将为整个IT领域注入更多新鲜和活力,在未来发展和壮大下去,成为引领潮流的重要性力量!

原文地址:http://blog.51cto.com/xjsunjie/2059289

时间: 2024-11-05 17:34:39

智能运维就是由 AI 代替运维人员?的相关文章

AI在运维中的应用

? 摘 要:随着X86分布式技术应用,服务器数量越来越多,网络拓扑结构越来越复杂,运维越来越辛苦,风险越来越高.智能化运维AIOPS将AI技术应用在运维场景,是DevOps的运维部分,是"开发运维一体化云中心"的重要基础设施之一,其最大的价值在于缩短故障恢复时间,提高IT服务连续性. 本文描述一个运维及在这个场景下对AI的需求,目标是尝试将AI引入运维过程,提高运维效率.缩短故障恢复时间. 关键字:机器学习:DEVOPS.AIOPS.流量预测 随着X86分布式架构应用,服务器规模越来越

【IT运维监控】讨论哪种运维监控工具才是IT运维人员的最爱?

选择运维工具的几大要素:一是看我哪些指标需要监控,二是看我监控到什么 三是看这种运维监控工具能监控到什么程度 有可能,这几个问题IT运维人员自己都没有弄的很明白,那么我们先看一下整个运维行业目前的现状: 目前来说,传统企业的IT运维大部分还是用户在使用过程中发现故障,然后通知运维人员,再邮运维人员确定是什么问题,采用哪种方式可以解决.大部分的运维人员目前还是充当的只是一个救火员的身份,没有起到真正的IT运维监控的作用.运维人员的大部分时间和经历都花在了处理简单而重复的问题上,导致同事及领导的不满

手游公司运维之利用Rundeck自动化运维工具和Shell脚本构建测试环境代码发布平台和生产环境代码发布平台

在做手游运维工作之前,我接触的代码发布都是常规的软件发布,有固定的发布周期.之前工作的那个外企有严格的发布周期,一年中的所有发布计划都是由Release Manager来控制,每次发布之前都需要做一些准备工作,如填写发布表单,上传发布需要的资源文件,联系发布过程中的相关人员,如开发和测试.最后在公司内部开发的发布平台上按照指定的时间点击鼠标对一个集群内的几台主机或全部主机进行代码发布.这个发布平台还是基于rsync服务实现的.虽然每个星期都有各种服务的发布,但是整个发布流程是可以控制的,并且发布

【高招职位精选】大咖公司诚邀运维工程师,一起发现运维之美

在很多人看来,运维是苦逼的,没有美感,然而,你真的了解运维的世界么?运维,其实是一个美妙的世界,只有当你深入了解它,发现运维的内在特性后,才能体会到运维的美感. 1.改变之美 很多时候觉得运维做得好是自我革命,做的不好则被人诟病,因此运维的改变是突破,是重生,是颠覆,是勇气.运维人不断在挑战已有的认知,突破自己,有时候会把自己建立起来流程规范和平台推翻掉,从而适应新的新的需求.2.想象力之美做运维不能没有想象力,没有想象力的运维真的和咸鱼没有区别,而给运维插上想象力翅膀的是研发能力和开放性.想象

2016年新运维:论《普通运维人员就是秋后的蚂蚱》?

2015年第一天,51CTO博主alex曾发表了<普通的运维人员就是秋后的蚂蚱>的博文,为广大的运维界同仁们敲响了警钟.文章主要从资源集中化和高度自动化两个行业大趋势出发,断言普通的运维人员已经走在了被淘汰的路上,IT自动化必将砸掉大多数不思进取的运维人员的饭碗,寿终正寝只是时间问题. 敏捷运营要求BizDevOps一体化 博文中提到的资源集中化,可以理解为云计算.2008年谷歌率先提出了云的概念,它将传统的IT计算能力形成资源池,进行弹性配置并对外提供按需服务,具体表现为服务化和平台化. 我

Linux运维是什么?linux运维的基础知识

如果您对运维行业了解一些,应该会知道,现在的运维早已不是早年的"睡机房",往办公室打眼一看,分不清是运维攻城狮还是开发程序猿,但是,运维这行也是春天到了,今天Linux,明天云计算的,各种新鲜概念层出不穷,那么,Linux运维是什么?云计算运维又是什么? 现在我们谈运维,经常谈的就是海量这个词,当一个企业拥有几百台服务器的时候,可能更关注的是如何满足应用/业务需求,更多时候不必过多的关注架构.容量.扩展性这些,运维部门有时甚至沦为打杂部门.但是当一个企业拥有几万甚至几十万台的服务器这个

运放参数解释及常用运放选型

集成运放的参数较多,其中主要参数分为直流指标和交流指标,外加所有芯片都有极限参数.本文以NE5532为例,分别对各指标作简单解释.下面内容除了图片从NE5532数据手册上截取,其它内容都整理自网络. 极限参数 主要用于确定运放电源供电的设计(提供多少V电压.最大电流不能超过多少),NE5532的极限参数如下: 直流指标 运放主要直流指标有输入失调电压.输入失调电压的温度漂移(简称输入失调电压温漂).输入偏置电流.输入失调电流.输入偏置电流的温度漂移(简称输入失调电流温漂).差模开环直流电压增益.

例看二维数组,指针,二维数组指针

例程: /****************************************************** * * 文件名:例程 * * 文件描述:例看二维数组,指针,二维数组指针 * * 创建人:Jesse * * 版本号: * * 修改记录: * ******************************************************/ #include <stdio.h> #define ROW 3 #define LINE 3 void main(voi

a和&amp;a的区别、二维数组的本质及多维数组

1 a和&a的区别 int a[10] = {1,2};//其他初始化为0 a代表数组首元素的地址,不是整个数组的地址 &a表示整个数组的地址 &a,a代表的数据类型不一样 &a数组类型int[10] a 数组首元素的类型 2 数组指针的用法 int i=0;//循环变量 int a [5] = {3, 4, 5, 6, 2}; //直接定义一个数组指针 int (*p)[5] = &a; for (i=0; i<5; i++) { printf("