AIOps 需要翻越的「三座大山」

标签: aiops 需要 三座大山 | 发表时间:2019-03-11 11:35 | 作者:
出处:http://blog.oneapm.com/

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

aiops.png

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. AIO ps.com


相关 [aiops 需要 三座大山] 推荐:

AIOps 需要翻越的「三座大山」

- - OneAPM 博客
最近 AIOps 火热的就像8月里的盛夏,运维圈子里的每一个人都在讨论着 AIOps,仿佛不聊点AIOps的东西,就透着那么out. 原来做运维产品的一众厂商也像打了鸡血似的,纷纷推出花样繁多的AIOps产品,仿佛AIOps是什么传说中的灵丹妙药,一试就灵、包治百病一样. Gartner 更是推波助澜,颇为大胆的预测到2022年,将有超过40%的企业会采用 AIOps 平台技术.

AIOps 核心技术和算法要点

- - IT瘾-dev
AIOps已经逐渐兴起,AI算法已较为成熟,使之与运维结合到了一起,下面列出AIOps相关技术和算法要点,有空了再展开写,懂大数据和机器学习的基本都知道各个组件及算法的作用. elasticsearch(支持时序). clickhouse(支持时序). -------------推荐阅读------------.

微软亚研院的AIOps底层算法: KPI快速聚类

- - 运维派
智能运维中存在海量时序数据(KPI)需要监控、检测异常、关联, 而AIOps的一个底层算法就是把大规模时序数据快速准确地聚类成有限的若干类别,从而大大降低后续数据分析与挖掘工作的开销.  其应用场景包括自动适配异常检测算法、辅助标注、辅助构建故障传播链等.  本文介绍的案例是由微软亚洲研究院发表在数据库领域顶级会议VLDB 2015的文章《 Yading: Fast Clustering of Large-Scale Time Series Data》.

运营商员工三座大山:指标高加班多心理抑郁

- 晋安渔夫 - cnBeta.COM
“收入高、工作轻松、住豪宅、开好车……”如果有人说他是一名电信运营商的员工,人们一般会给 他打上这些标签;如果这个人告诉你,他一年只休息10天;收入不过是社会平均中等水平,还经常被扣掉三分之一;如今家庭矛盾重重,妻子吵着要和他离婚……你会信吗. 常被公众诟病“垄断”的三大电信运营商,市场竞争之惨烈、员工生存之压力,远超人们想象.

Google 需要性爱

- cantrip - 酷壳 - CoolShell.cn
看到一篇趣文Google Needs Sex,翻译过来. Brad DeLong 给我们写了 两篇关于“Google遇到的麻烦”的文章(墙),这两篇文章基本上是说, 制造网络欺诈和网络垃圾信息的人会尽其一切努力来和搜索引擎进行博弈,这样一来,其会让搜索到的结果对我们越来越没有帮助(译注:百度的竞价排名成为了制造网络欺诈和网络垃圾信息甚至洗脑的温床).

都需要过程

- Terence - 左岸读书_blog
我一直相信,这个世界所有的事情都建立在一定的规则之上,最根本的规则. 其上一切规则都要依次规则,一旦上层规则违背了底层的规则,则必然会出现问题. 而那些根本的规则,其实在最初我们就已经知道,只是无法意识到. 记得有一句好象是说:最初,看山是山,看水是水;然后,看山不是山,看水不是水;最后才发现,山仍然山,水仍然是水.

谁需要瓢虫保镖?

- bill - 科学松鼠会
如果你觉得上面的图是瓢虫在抱蛋或抱蛹~那么你弄错了. 在瓢虫身体下面的其实是瓢虫茧蜂​​(Dinocampus coccinellae)的蛹. 瓢虫茧蜂会下蛋在瓢虫身上(它们尤其热爱七星瓢虫),然后瓢虫茧蜂会开始在瓢虫里面成长,但是不会杀死瓢虫. 直到他们要化蛹的时候,他们才会由瓢虫的腹部钻出来,并在瓢虫(仍然活着)的六足之间吐丝结蛹.

你不需要iPhone 4S

- 鹏 - 译言-每日精品译文推荐
  人已沦为他们制造的工具的工具.  你们中很多人都看过新推出的iPhone 4S的视频和评论;的确,它看起来很酷. 的确,它光鲜诱人,拥有高级摄像头、个人助理、更好的屏幕等配置. 但是,和昨天或5年前一样,你今天并不需要它. 昨天,没有新的iPhone,你过得很好. 没有新的iPhone,你们中的很多人都很快乐和满足,甚至可以专注于工作和享受生活.

减肥需要加营养

- - 范志红_原创营养信息
若说一年中最有减肥压力的时候,那肯定要数5月了. 风和日暖,衣装轻薄,本是曼妙身材曲线毕露的时刻. 然而,这时候的穿衣也最为烦恼——女性看看原来的纤腰上增加了两道游泳圈,男性看看胸前腹部凸起的三片高原,郁闷之余,又会开始新的减肥历程. 一位朋友咬牙切齿地告诉我,美丽的连衣裙穿不进了,5月份开始要对自己狠一点,天天称量体重,严格节食减肥,什么有营养的东西都不吃.

写作不需要天才,但需要找对方法

- - 白板报
如果写的是鸿篇巨制,例如长篇小说,史诗巨构,或者是诗歌,那天赋显然是需要的. 如果写的只是散文、随笔、应用文、小品文、短篇小说、中篇小说,或者是电影剧本,甚至电视连续剧,那么可以通过努力和训练,达到合格以上的水平,而并不需要太多的天才. 自古以来,写作这件事被搞得很精致,也很神秘,有些过度精致,神秘得有点近乎巫术了.