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 网络数据整合;
• etric 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 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/Dap...

Opentracing 的技术规范文档 https://github.com/opentracin...
若是咱们将以上数据类型作成一个矩阵看看，咱们能够获得这样一个表格，比较好的说清楚了相关关系。

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

回到 Garnert 的 AIOps 能力定义， 竟然没有把 Tracing Data

归入到数据整合的范围之中，我的认为不太合理，由于要去作根因分析，若是不知道服务和指标之间的关联关系，实际上是比较难作到故障的根本定位的。

算法部分

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

小结

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

OneAPM 全新推出新一代 AIOps 平台 I2，欢迎您随时联系咱们，即刻开启贵公司的智能运维之旅。点击进入 AIOps 官网了解更多信息。