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

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

Gartner 更是推波助澜，颇为大胆的预测到2022年，将有超过40%的企业会采用 AIOps 平台技术。 睿象科技 从1 8 年 初 开始投入研发力量做 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 后，数据量必将会有爆炸性的增长，达到接近 50T B 每天，甚至突破 100TB 每天，这是对于很多

数据类型多样挑战

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

多样化的分析需求挑战

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

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

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

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

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

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

数据治理挑战

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

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

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

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

• …

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

第三座大山：就是算法

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

人

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

期望

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

适用场景

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

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

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

工程化

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

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

总结

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