AIOps 平台的误解，挑战及建议， AIOps背景及所应具备技术能力分析（上）

本文出自睿象科技产品总监陈自欣。篇幅较长，分为上，中，下，三个部分进行连载。内容分别为：AIOps 背景及所应具备技术能力分析（上），AIOps 常见的误解（中），挑战及建议（下）。

前言

我大概是 5，6 年前开始接触 ITOA 这个领域的，首次接触后，发现领域有着巨大的潜力，一直寻找在这个领域做点事情的机会。大约三年前在这个领域创业，积极寻求 Product Market Fit。这几年下来，经过与行业内的专家交流，研读报告，阅读论文，客户访谈，亲自动手对相应的运维场景解析，行业产品的试用调研，以及结合着中国运维市场现状，撰写了此文。本人才疏学浅，不学无术，欢迎拍砖。

背景

概念的进化：ITOA -> AIOps -> AIOps

让我们回到2013年，著名的 Buzz word (时髦用语) 制造商 Gartner 在一份报告中提及了 ITOA，当时的定义是，IT 运营分析(IT Operations Analytics)， 通过技术与服务手段，采集、存储、展现海量的 IT 运维数据，并进行有效的推理与归纳得出分析结论。

而随着时间推移，在2016年，Gartner 将 ITOA 概念升级为了 AIOps，原本的含义基于算法的 IT 运维(Algorithmic IT Operations)，即，平台利用大数据，现代的机器学习技术和其他高级分析技术，通过主动，个性化和动态的洞察力直接或间接地，持续地增强 IT 操作(监控，自动化和服务台)功能。 AIOps 平台可以同时使用多个数据源，多种数据收集方法，实时分析技术，深层分析技术以及展示技术。

随着 AI 在多个领域越来越火爆，Gartner 终于按捺不住了，在它的2017年年中一份报告中，顺应民意将 AIOps 的含义定义为了，Artificial Intelligence for IT Operations， 也就是现在大家都在说的智能运维。

在短短的不到 1 年时间中，伴随着AI的热炒，以及在各个领域的落地，运维界的同仁基本上把 AIOps 看成是未来解决运维问题的必然方向。

个人认为，在企业内部构建 AIOps，通过融合 IT 数据，真正打破数据烟囱，对监控，自动化，服务台进行支持，使得 IT 能够更好的支撑业务，利用大数据技术以及机器学习技术，回答以前很多单从业务口径，或者单从 IT 口径无法回答的问题。如，联通，电信，移动，电信的用户，哪种用户转化率较高。AIOps 以创造商业价值为导向，对 IT 运营以及业务运营产生持续洞察，为 DevOps 提供持续反馈，加快企业在竞争日趋激烈市场环境中，数字化转型的步伐。

因此，Gartner 预测到2022年，大型企业中的的40%将会部署 AIOps 平台。

具体关于 AIOps 的概念，价值，Gartner 很多都已经说的很清楚，不是本文的重点，本文是根据我的理解，尝试从现实的角度，去谈 AIOps 在落地过程中容易产生的误解，挑战以及一些建议。

AIOps 所应具备技术能力分析

个人认为，AIOps，本质上是 ITOA 的升级版，让我们来看一下 Garnter 在 2015 年对 ITOA 的所应该有的能力定义。

1. ML/SPDR: 机器学习/统计模式发现与识别;

2. UTISI: 非结构化文本索引，搜索以及推断;

3. Topological Analysis: 拓扑分析;

4. Multi-dimensional Database Search and Analysis:多维数据库搜索与分析;

5. Complex Operations Event Processing: 复杂运维事件处理;

然后， 我们对比一下，Gartner 对 AIOps 的能力定义

• Historical data management 历史数据管理;

• Streaming data management 流数据管理;

• Log data ingestion 日志数据整合;

• Wire data ingestion 网络数据整合;

• Metric data ingestion 指标数据整合;

• Document text ingestion 文本数据整合;

• Automated pattern discovery and prediction 自动化模式发现和预测;

• Anomaly detection 异常检测;

• Root cause determination 根因分析;

• On-premises delivery 提供私有化部署;

• Software as a service 提供 SaaS 服务;

除去最后两个的交付方式，对比下来，我认为 AIOps 比起原来的 ITOA 有以下的进化：

强调历史数据的管理：

允许采集，索引和持续存储日志数据，网络数据，指标以及文档数据，数据大部分是非结构化或者半结构化的，而且数据量累积速度很快，格式多样，非常符合大数据的特征。总所周知，在新一轮以 CNN , RNN 算法为代表的算法中，都需要大量有标准的数据来进行训练，因此， 对历史数据的管理，成了智能运维的第一重点。

强调实时的流数据管理：

以 Kafka Streams，Flink，Storm，Spark Streaming 为代表的流计算处理技术，已经成为了各大数据平台的必备组件，而面对 IT 数据中海量的实时流式数据，某些场景里头，在数据进行持久化前，进行实时分析，查询，集合，处理，降低数据库(SQL or Nosql)的负载，成为了非常合理且常规的选择，因此 AIOps 平台中，含有数据流，非常合理。

强调多种数据源的整合:

我认为，这个是 AIOps 平台最大的价值点，因为 Gartner 第一次将多种数据源整合的能力，带入了 ITOM 管理的领域，我们搞运维监控那么多年，终于第一次可以以大数据的视角，数据驱动的视角，去思考运维监控这个传统。

Gartner 这里提及到了四种数据，Log Data, Wire Data, Metirc data，Document text。 这样的分类，我是个人持有保留意见，感觉很奇怪，特别是 Document text 的那块，需要用到 NLP，主要是用于打通 ITSM 产品，分析 ITSM 工单。我对这个场景存在必要性，以及实现的 ROI 表示怀疑。具体原因我可能稍后会写一篇文章，进行更详细的解释。

我认为，如果从宏观的类型来划分，应该这样划分 (下含部分我司产品介绍)

机器数据(Machine Data)：是 IT 系统自己产生的数据，包括客户端、服务器、网络设备、安全设备、应用程序、传感器产生的日志，及 SNMP、WMI，监控脚本等时间序列事件数据(含CPU 内存变化的程度)，这些数据都带有时间戳。这里要强调， Machine Data 不等于 Log Data ，因为指标数据包含。在通常的业界实践中，这些数据通常通过运行在主机上的一个 Agent 程序，如 LogStash， File beat，Zabbix agent 等获得，如果我们的 LogInsight，Server Insight 产品，就是面向此类型数据。

网络数据(Wire Data)：系统之间2~7层网络通信协议的数据，可通过网络端口镜像流量，进行深度包检测 DPI(Deep Packet Inspection)、包头取样 Netflow 等技术分析。一个10Gbps端口一天产生的数据可达100TB，包含的信息非常多，但一些性能、安全、业务分析的数据未必通过网络传输，一些事件的发生也未被触发网络通信，从而无法获得。我司的 Network Insight 主要面向的是这些数据，提供关键应用的 7 x 24 小时全方位视图。

代理数据(Agent Data)：是在 .NET、PHP、Java 字节码里插入代理程序，从字节码里统计函数调用、堆栈使用等信息，从而进行代码级别的监控。我司的 Application Insight 主要是解决这个问题而诞生，能获得真正用户体验数据以及应用性能指标。

探针数据(Probe Data)：也就是所谓的拨测，是模拟用户请求，对系统进行检测获得的数据，如 ICMP ping、HTTP GET 等，能够从不同地点模拟客户端发起，进行包括网络和服务器的端到端全路径检测，及时发现问题。 我司的 Cloud Automation Test，Cloud Performance Test 主要是产出这些数据的，CT 的产品能从遍布全球的拨测点，对网站的可用性进行全天候的分布式监控。其中我们的 CPT 给你带来从数百到数百万完全弹性的压力测试能力，获得应用在高压力的情况下的性能表现情况。

因为 IT 监控技术发展实在是太庞杂，以上的划分不一定对，但是应该没有显著的遗漏。

但如果从微观技术的角度来看，不考虑数据的来源，只考虑数据本身的属性特点，我们可以这样划分：

指标数据( Metrics Data )

描述具体某个对象某个时间点这个就不用多说了， CPU 百分比等等，指标数据等等

日志数据 ( Logging Data )

描述某个对象的是离散的事情，例如有个应用出错，抛出了 NullPointerExcepction，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。

调用链数据( Tracing Data )

Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用 Tracing 这个词。 Tracing 的特点就是，它在单次请求的范围内，处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。 例如：一次调用远程服务的 RPC 执行过程;一次实际的 SQL 查询语句;一次 HTTP 请求的业务性 ID。 通过对 Tracing 信息进行还原，我们可以得到调用链 Call Chain 调用链，或者是 Call Tree 调用数。

官方 OpenTracing 中的 Call Tree 例子。

在实践的过程中，很多的日志，都会有流水号，Trace ID， span ID， ChildOf, FollowsFrom 等相关的信息，如果通过技术手段，将其串联在一起，也可以将这些日志视为 Tracing 。

Tracing 信息越来越被重视，因为在一个分布式环境中，进行故障定位，Tracing Data 是必不可少的。

由于 Tracing 相对于 Logging 以及 Metircs 相对比较复杂一点，想深入了解的话，可以参考 ：

《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 http://bigbully.github.io/Dapper-translation/

Opentracing 的技术规范文档 https://github.com/opentracing/specification 如果我们将以上数据类型做成一个矩阵看看，我们可以得到这样一个表格，比较好的说清楚了相关关系。

举例就是，基础监控产品，能采集及处理指标数据，及日志，但是基础监控产品，不会处理 Tracing Data，APM产品能从 JVM 虚拟机中，通过插码，获得应用的响应时间(Metris)，Java异常( Logging )，应用间的调用拓扑关系，以及调用的响应时间(Tracing)。

回到 Garnert 的 AIOps 能力定义， 居然没有把 Tracing Data 纳入到数据整合的范围之中，个人认为不太合理，因为要去做根因分析，如果不知道服务和指标之间的关联关系，其实是比较难做到故障的根本定位的。

算法部分

其实可以看到，Gartner 在 ITOA 定义的算法部分，如模式发现，机器学习等技术定义，都被比较顺滑的过渡到 AIOPS 中来，一个方面可以看出 Gartner 在定义 ITOA 的时候有足够的前瞻性，另外一个方面可以看到，相关的算法问题，解决及演进的速度，是相对于基础大数据架构相对要慢上不少。

小结

AIOPS 概念与 ITOA 概念相比，在大数据技术部分进行了更细，更有指导性的阐述，所以我认为，AIOps 首先是大数据，然后才是算法。