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

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