我大概是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 的所应该有的能力定义。
ML/SPDR: 机器学习/统计模式发现与识别
UTISI: 非结构化文本索引，搜索以及推断
Topological Analysis: 拓扑分析
Multi-dimensional Database Search and Analysis:多维数据库搜索与分析
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 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》
bigbully.github.io/Dapp
/
Opentracing 的技术规范文档
github.com/opentracing/
如果我们将以上数据类型做成一个矩阵看看，我们可以得到这样一个表格，比较好的说清楚了相关关系。
举例就是，我们的Server Insight 基础监控产品，能采集及处理指标数据，及日志，但是基础监控产品，不会处理Tracing Data，而我们的Application Insight 产品能从JVM 虚拟机中，通过插码，获得应用的响应时间（Metris），Java异常（ Logging ），应用间的调用拓扑关系，以及调用的响应时间（Tracing）。
我司AI 平台应用拓扑截图
回到Garnert 的AIOps 能力定义， 居然没有把 Tracing Data 纳入到数据整合的范围之中，个人认为不太合理，因为要去做根因分析，如果不知道服务和指标之间的关联关系，其实是比较难做到故障的根本定位的。
算法部分
其实可以看到，Gartner 在ITOA 定义的算法部分，如模式发现，机器学习等技术定义，都被比较顺滑的过渡到AIOPS 中来，一个方面可以看出Gartner 在定义ITOA 的时候有足够的前瞻性，另外一个方面可以看到，相关的算法问题，解决及演进的速度，是相对于基础大数据架构相对要慢上不少。
小结
AIOPS 概念与 ITOA 概念相比，在大数据技术部分进行了更细，更有指导性的阐述，所以我认为，AIOps 首先是大数据，然后才是算法。
误解：
AIOps 等于可以减少人力资源的投入
AIOps 不等于无人值守
AIOps 不等于 NoOps
AIOps 不等于可以减少人专家的参与
AIOps 可以降低人力成本
AIOps 在现阶段不等于可以省钱
AI 的确是一个非常性感的词汇，大家认为只要实现了智能化，就能够轻轻松松，不需要人的干预，这当然是一个非常理想的状况，但是，在短时间内，这个不能实现。这个的实现难度，个人认为，与自动无人驾驶，能实现第五等级是同样的难度，也就说，可能起码需要10年左右的时间，甚至可能更长时间。
AIOps平台本质上还是一个工具，在构建后，仍然需要人的参与，而且在目前的探索发展的投入阶段，有大量的工需要去做，需要运维专家，大数据工程师，算法科学家，业务专家，暂时看不到能削减人力成本的可能性，而且相关的投入可能需要多年的时间。
在平台建立后，在持续改进的情况下，仍然需要专家或者分析师，从不同的维度，从不同的业务口径，组合合适的可视化技术，机器学习技术，大数据分析技术，制定分析场景，平台才能够为IT运维，业务分析产生持续的洞察，提供商业价值。
所以，AIOps 不能取代人，在现阶段不可能减少人力投入，但在未来可能能促进部分运维人员转型为通晓业务，掌握运维知识的数据分析师。
算法和智能化是AIOps最重要的事情
算法很重要，但是我个人认为，在此阶段，大部分企业不应该以算法为第一着眼点。
这个应该是比较有争议，或者，或者说大家认知不太一致的部分。以下这张图是Gartnert 在 AIOps还在叫ITOA 时候，给定义的四个阶段：
Data ingestion, indexing, storage and access
Visualization and basic statistical summary
Pattern discovery and anomaly detection
True causal path discovery
Gartner 在报告中强调，掌握后面阶段的前提是拥有前一阶段的能力，如果不拥有充分的前一阶段能力，将会影响ITOA 的落地效果。因此这四个阶段必须一个步一脚印，第三以及第四部时，才显著地引入了机器算法，或者AI的必要。
大家都知道，所谓的机器学习算法，统计算法，深度学习算法这些AI 的分类，其实是高度依赖于数据的。没有多种数据源，数据的采集，数据存储，数据统计，数据可视化，一切都只是空中楼梯。
来源： Gartner Report “Organizations Must Sequentially Implement the Four Phases of ITOA to Maximize Investment ” 2015.2.18
因此，AIOps的平台的建设首先应该是着眼点应该是大数据，然后才是算法，从而实现持续洞察和改进的目标。
一定要上深度学习才叫AIOps
我们可以先看看AI , Machine Learning , Deep Learning 的关系，他们的关系大概如下图。
学术界有不少学者，在探索部分深度学习算法智能运维中的应用，如犹他州大学的《DeepLog: Anomaly Detection and Diagnosis from System Logs through Deep Learning》 中利用 Long Short-Term Memory (LSTM)来实现日志模式的发现，从而实现异常检测。但是，其实智能运维所需要的大部分算法，决策树学习（decision tree learning）、聚类（clustering）、SVM（Support Vector Machine）和贝叶斯网络（Bayesian networks）等等算法，均是属于传统的机器学习范畴的，因此 我们不应该将深度学习与AIOps 挂上必然的联系。
甚至于，我们不用拘泥于概念，从解决问题的角度出发，在特定的场景，利用传统的规则集，设定一些规则，降低了运维人员的工作强度，提高了效率，也能叫智能运维。甚至在Gartner 的报告中，对AIOps 落地的第一步，是统计分析，可视化，而不是任何的机器学习算法。
它适合现阶段所有有规模的用户
这个比较好理解，就目前来看，AIOps 只适合大型的客户，原因如下:
中小型的客户缺乏多种数据源
中小型客户业务需求没有那么复杂
很多算法，其实是为了大规模运维的时候才用的上的，在规模小的时候，难以产生效果
运维自动化是智能运维的前提
我看到过不少的文章，将运维分成了四个阶段，将自动化运维放在智能运维的前一个阶段，把智能，又或者在智能运维这个体系里头，硬是塞了很多自动化运维，批量操作，批量规划的功能在里头，我觉得都是不对的。自动化运维更像是手，智能运维更像是眼镜及大脑，有了更全面数据，更充满的分析后，大脑能更好的指挥手进行操作。
因此，企业应该将自动化运维和智能化运维看成了两个有关联的体系，但是不应该混一谈，造成更多的误解。
挑战
挑战1：超越当前技术水平的期望
以下是其中一例，当用户期望超越当前技术水平的一个典型的例子，车毁人亡。
美国加州湾区高速上的一起致命车祸，。一辆价值$79,500的Tesla Model X，在行驶至山景城段101和85高速交界时，突然撞上隔离带，随后爆炸起火。
对此，遇难华裔司机的遗孀Sevonne Huang（下文简称Sevonne）首次公开发声透露，丈夫生前曾抱怨过，特斯拉的自动导航仪，好几次让车子开向冲上防撞栏。Sevonne说，将起诉特斯拉。
自动驾驶的安全性问题，再次把特斯拉推到风口浪尖上。然而事后，虽然特斯拉发声明称，抱歉发生这样的悲剧，但同时也将责任指向了死者，“车辆再三发出警告，提醒司机操控车子，但事发前，司机并没有把手放在方向盘上。自动驾驶仪并不能避免任何事故。”
司机对于特斯拉的AutoPilot 过度相信，最终导致了悲剧了发生。
虽然目前的智能运维，所造成的结果可能不会那么严重，但是按照Gartner 技术成熟度曲线来看，AIOps 还处于非常初期的阶段（左下角），超越现阶段的期望，是AIOps最大的风险。
中国的企业用户往往有大而全的建设方案，如何从企业的实际情况出发，制定节奏合适的规划，我认为是一个很大的挑战。
挑战2：算法应用场景分散，成熟度不一致，通用性差，产品化，工程化困难，大部分场景距离实际应用有一定的距离
从目前来看，大家期望利用算法解决的场景包括：
