最近 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.
来源: https://juejin.im/post/5c85bea26fb9a049f06b1468