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.AIOps.com。