ITBear旗下自媒体矩阵:

AIOps需要翻越的“三座大山”

   时间:2019-03-11 10:03:22 来源:互联网编辑:星辉 发表评论无障碍通道

最近AIOps火热的就像8月里的盛夏,运维圈子里的每一个人都在讨论着AIOps,仿佛不聊点AIOps的东西,就透着那么out。原来做运维产品的一众厂商也像打了鸡血似的,纷纷推出花样繁多的AIOps产品,仿佛AIOps是什么传说中的灵丹妙药,一试就灵、包治百病一样。

Gartner更是推波助澜,颇为大胆的预测到2022年,将有超过40%的企业会采用AIOps平台技术。睿象科技从18年初开始投入研发力量做AIOps平台,转眼间一年时间过去了,期间遇到了各种未曾预期的挑战,想起来实在是五味杂陈,溢于言表。

不过总算天道酬勤,到现在为止,我们已经成功实施四个商业案例了。淌过这么多坑,对AIOps算是有了些更深入的体会,过节这几天闲暇无事,就和诸位聊聊,也算给大家提个醒吧。

AIOps平台包罗万象,包含异常检测,异常定位,根因分析,容量规划,故障预测,模式识别,告警压缩等等各种“豪华大招”。貌似感觉有了AIOps平台,运维工程师再也不用苦逼哄哄了,然而理想丰满,现实却骨感,要实现我们的理想,甚至说只是部分实现,都是一个极具挑战的系统工程,个人感觉至少要翻越“三座大山“。

第一座大山:数据采集

众所周知,要实现好智能运维,全方位,实时,多维度,全量地对运维数据采集采集,是所有工作的第一步,但是这第一步可不好走。

一个典型的AIOps企业级用户,大多数情况都有比较完整的运维体系,而且经年累月,积累并实施了很多成熟的运维工具,从传统网管,基础架构监控,网络监控,流量监控,工单系统,日志监控,到最流行的APM,从国外的大厂IBM BMC的 Tivoli,OpenView,再到国内的OneAPM,摩卡,天旦,还有开源的Zabbix, Catti ,ELK 等,应有尽有。要在很多软件都已经没有,要将相应的数据导入到AIOps平台中,相应的工作量可想而知。

更要命的是,很多软件,特别是老旧一点的运维产品,是没有公开的数据接口的,某些工具,即使通过各种方法把数据取出来,发现其数据也是不准确,或者是非实时的。

我们在碰到这类问题的时候,就会先帮着企业梳理已有的数据采集工具,能接的全部接上,建立相应的数据模型,如果没有相应的数据维度,则建议企业购买相应的数据采集工具来补足能力。

第二座大山:数据中台

数据中台概念最早是由阿里提出来的,是指以服务为导向,对海量数据进行采集、计算、存储、加工的一系列技术集合;这个概念通常有优先应用于与公司经营决策运行的业务数据,但是随着AIOps的概念的出现,接入海量多种类的IT 数据,所带来的数据存储,计算,加工问题,通常会困扰到运维团队。

在国外,如Gartner的定义中,就没有数据中台的概念,但国外在谈到这块的时候,会用Data lakes 来进行进行陈述,这个IT数据湖对数据处理的要求,有着自己的特点,主要有着以下的挑战:

海量存储和可扩展性的挑战

一般中小金融机构的IT数据中心,在AIOps平台建设的初期,接入的数据量每天就可能达到就在1TB以上,而随着客户对平台价值的理解, 客户将会更多类型的数据,特别是接入例如Wire Data, Tracing Data后,数据量必将会有爆炸性的增长,达到接近50TB每天,甚至突破100TB每天,这是对于很多

数据类型多样挑战

从IT监控运维的角度来说,AIOps 接入的数据包括,时序指标数据,日志数据,网络抓包数据,事务链数据,IT事件数据等等,从底层技术维度来看这些数据,可以把这些数据理解为,时序数据,半结构化数据,DAG图数据,结构化数据,很明显,要对这些这么多样化数据进行存储和分析,只用一种数据存储引擎是不够的,选择合适的数据存储引擎,如何将多个数据引擎进行有机结合,是一个考验。

多样化的分析需求挑战

AIOps监控运维,分析场景众多,维度复杂,在业务监控这块,部分还有很强的关联关系,还要结合一些传统的机器学习算法进行分析,导致了平台起码要支持以下的分析能力:

流计算处理能力:用于对数据进行实时内存计算,在事件窗口内,实现类似于关联,复杂事件处理等计算

多维半结构化数据实时过滤汇聚能力:用于对日志这种半结构化,维度不固定,有大量的数据需要被提取,需要进行实时分析汇聚

时序指标数据处理能力:针对KPI的时序特性,实现高效存储实时汇聚

经典机器能力:支持如线性回归,SVM,决策树等,Kmean 等算法

深度学习能力:LSTM , RNN ,CNN 等深度算法,相关算法需要从大量标注过的历史数据进行训练学习,相关的算法,要能访问到远比实时,近线数据数据量大的多的历史数据,进行相应的训练。

数据治理挑战

可以想象,我们往这个数据湖里头,灌了那么多不同类型的,不同结构的数据后,如果没有合适的治理,这数据湖将肯定会变成一个泥潭,所以需要以下的治理能力。

元数据管理:在商业智能上,这一块相对已经有了不少的实践,但是在IT数据中,业界探索才刚刚开始,我们看到,Elastic公司刚刚开源了一个小项目,叫Elastic Common Schema,用意就是针对IT数据,定义一套通用的Schema,便于关联,以及后继的分析。但是这个东西目前还是比较稚嫩,或者说,在我们很多的场景下。

数据生命周期管理:数据量庞大,需要将过期的数据,迁移合适的历史数据存储上。很多情况下,还需要将部分的历史数据,以粗粒度的形式进行汇聚后,丢弃细粒度原文。有的还需要进行永久保存,例如一些合规要求的交易日志,因此,必然需要有相应的历史数据管理方案

数据流向管理:数据在平台内部, 必然要做相关的流转,关联,处理,需要对相应的数据流向流动,进行管控,保证数据加工的准确性。

可以看到,这个数据中台的能力,是整个AIOps平台的核心,架构,实现的难度非常大, 非常考验架构师的功力。

第三座大山:就是算法

算法的挑战主要来自以下几个方面,分别是人,期望,适用场景,工程化。

这里的人,不单只是算法研究员,而是完整的从产品,算法,研发,运维,测试的有机合作,形成完整的团队,才能从运维场景出发,为算法找到这个相应的落脚点,并通过产品设计,研发编码,运维及测试的配合,才能很好的进行落地。

期望

客户对相应的场景的合理预期,是算法落地的关键。无论是广义的AI,还是AIOps里头的智能算法,都距离大众的期望值有较大的距离,而现在媒体还处于对于AI算法的炒作期阶段,所以这里就会引发出较大落差。在项目初始阶段,需要进行充分,反复的沟通,让双方都能理解到,在目前的阶段,算法的实践还是属于前沿探索行为,在特定的场景下,有一定的效果,而且在落地的过程中,一定有各种的问题,需要一起去探索。

适用场景

离开用户适用场景,去谈AIOps算法,就是耍流程。在刚开始,进行算法研究的时候,我们的算法研究员是独立对算法进行研究的,结果发现,通过新研究的算法,从技术上来说,目标是达到了,但是从业务上来说,这个结果,对于运维人员来说,本身就是显而易见的,就是说在这个场景中,用算法算出的的结果,毫无意义。因此,我们在日后的算法探索,第一步就是与运维人员及客户,把相应的运维场景进行明确。

而在项目真正项目实践过程中,我们在于客户互动的情况下,我们发现,其实在很多时候,客户所想要的智能化,并不一定需要用到多复杂的算法,例如, 我们用了多个很常见算法,甚至不是机器学习的算法, 在客户海量的告警数据下, 对进行了压缩,减少了告警风暴,给客户带来了非常实际的价值。

因此,根据场景找到合适的算法,并进行落地,是算法落地的关键一步。

工程化

我们发现了,很多的算法及模型,在进行实验的时候很不错,但是要进行生产,将算法迁移到生产环境中,就会发现有不少的问题,最普遍的是,计算量巨大,导致计算没有办法做到实时,又或者由于没有考虑到一些制约因素,没有选用对合适的数据读取方法,导致运行缓慢,甚至程序崩溃。

从客观上来说,很多的算法研究员编码及工程化能力不太强,这基本上是一个普遍现场,毕竟术业有专攻;另外以一方面,这也是工程化和产品化的一部分,需要,算法研究员与架构师一起,将算法的实现进行重构, 并进行产品化,工程化。

总结

路慢慢其修远兮,吾将上下而求索。在追求运维智能化的道路上,注定不会平坦,以上就是我们团队在做AIOps产品时经过的“三座大山”,希望能对大家有所帮助,如果大家想要更多的了解有关AIOps的知识,欢迎访问www.AIOps.com。

举报 0 收藏 0 打赏 0评论 0
 
 
更多>同类资讯
全站最新
热门内容
网站首页  |  关于我们  |  联系方式  |  版权声明  |  网站留言  |  RSS订阅  |  违规举报  |  开放转载  |  滚动资讯  |  English Version
关闭
ITBear微信账号

微信扫一扫
加微信拉群
电动汽车群
科技数码群