本文篇幅较长，分为上，中，下，三个部分进行连载。内容分别为：AIOps 背景/所应具备技术能力分析（上），AIOps 常见的误解（中），挑战及建议（下）。
前言
我大概是 5，6 年前开始接触 ITOA 这个领域的，首次接触后，发现领域有着巨大的潜力，一直寻找在这个领域做点事情的机会。大约三年前在这个领域创业，积极寻求 Product Market Fit。这几年下来，经过与行业内的专家交流，研读报告，阅读论文，客户访谈，亲自动手对相应的运维场景解析，行业产品的试用调研，以及结合着中国运维市场现状，撰写了此文。本人才疏学浅，不学无术，欢迎拍砖。
挑战
挑战1：超越当前技术水平的期望
以下是其中一例，当用户期望超越当前技术水平的一个典型的例子，车毁人亡。
美国加州湾区高速上的一起致命车祸，。一辆价值$79,500的 Tesla Model X，在行驶至山景城段101和85高速交界时，突然撞上隔离带，随后爆炸起火。
对此，遇难华裔司机的遗孀 Sevonne Huang(下文简称Sevonne)首次公开发声透露，丈夫生前曾抱怨过，特斯拉的自动导航仪，好几次让车子开向冲上防撞栏。Sevonne 说，将起诉特斯拉。
自动驾驶的安全性问题，再次把特斯拉推到风口浪尖上。然而事后，虽然特斯拉发声明称，抱歉发生这样的悲剧，但同时也将责任指向了死者，“车辆再三发出警告，提醒司机操控车子，但事发前，司机并没有把手放在方向盘上。自动驾驶仪并不能避免任何事故。”
司机对于特斯拉的 AutoPilot 过度相信，最终导致了悲剧了发生。
虽然目前的智能运维，所造成的结果可能不会那么严重，但是按照Gartner 技术成熟度曲线来看，AIOps 还处于非常初期的阶段(左下角)，超越现阶段的期望，是 AIOps 最大的风险。
中国的企业用户往往有大而全的建设方案，如何从企业的实际情况出发，制定节奏合适的规划，我认为是一个很大的挑战。
挑战2：算法应用场景分散，成熟度不一致，通用性差，产品化，工程化困难，大部分场景距离实际应用有一定的距离
从目前来看，大家期望利用算法解决的场景包括：
-
单指标异常检测;
-
多指标异常检测;
-
日志模式异常检测，根据日志的类型的变化态势，发现正常和异常情况下各类型日志出现的模式；
-
故障根因分析，方法多种多样，有基于传播网络，有基于依赖，有基于概率数学统计等方法;
-
容量预估，对现有业务情况进行分析，预测未来所需要资源使用情况;
-
告警智能压缩，基于根因，减少告警数量;
-
故障预测，目前较为常用的场景为大批量，同批次硬盘的故障预测;
-
基于知识图谱(运维经验)故障定位;
以上的每个智能场景，每个场景所需要用到的算法都不一样，而且成熟度差异较大。
以最为简单，但应用最为广泛，成熟度最高的单指标异常检测来举例，从学术的角度来看，如果你到 Google 里去搜索，你会发现有大约 60000 多条的记录，时间跨度从上世纪 90 年代到几天前的都会有。
从商业化的角度来看，目前从我看到的，比较成熟的也只有 Elastic 公司所收购的 Prelert 的异常检测技术，是产品化的比较好的，普通的用户是容易理解，容易使用的。
这已经是 30 年来，集合了那么多顶尖的智慧，所能达到的产品化程度最高，通用性最强的场景了。其他的场景，成熟度，或者通用性肯定是不如本场景。
例如故障预测，目前比较好的案例是预测硬盘故障，前提是你拥有大量同样型号，相同批次的硬盘，其中某一些硬盘出故障了，从 S.M.A.R.T 信息中，你才能够获得训练集，然后利用模型去预测同一个批次的故障。这种前置条件，通常只会在特定的用户，例如腾讯，百度的数据中心，一次性购置上千块的，才能出现1到15块的故障硬盘 (据统计，硬盘的故障率在0.1%~1.5% 左右)，而且就算有用户根据硬盘的情况，训练好的模型因为每个用户的机房，电压，温度都不一样，很可能没有办法进行复现，因此，此场景通用性极差。
如果要将用于预测硬盘故障的算法，用到某一个 IT 业务系统之上故障上，基本上也是不可能的，因为一个系统，相应的参数，变量，可能影响系统平稳运行因子太多，已经是没有办法套用到预测硬盘故障的算法里头来了。
还有，部分的算法，在实验室中的效果非常好，准确率和召回率都很高，但是，消耗资源巨大，实时性差，没有办法投入真正的生产使用的可能性。
因此，在算法上，我们应该先去落地成熟，ROI 显著的场景。
挑战3：现有运维监控体系没有完善
在无人驾驶技术领域，最核心的一个组件是 LiDar(激光雷达)，一种运用雷达原理，采用光和激光作为主要传感器的汽车视觉系统，LiDAR 传感器赋予了自动驾驶汽车能够看到周边环境的“双眼”。
世界上，几乎所有的汽车厂商( Tesla 除外，Tesla 用的是通过摄像头而实现视觉识别技术，所以我个人高度怀疑特斯拉的事故与此有关)在研发无人驾驶技术的时候，都会给车辆安装上激光雷达。
而类比到运维的场景，如果眼睛不够，数据不足，事情看不清楚，其实是很难做到明确的决策的，具体表现如下：
缺乏足够的数据源： 有的客户，没有日志管理系统，也没有任何业务监控的手段，只有 CPU 内存，硬盘等基础监控，这个时候，其实我个人上是不建议在现阶段做 AIOps 的;
-
监控指标深度，专业华程度不够： 这个问题很多时候反应的数据库监控上，由于数据库专业化程度较高，因此对数据库的很多关键的指标未能识别，导致了关键信息的遗漏，可能会大大影响 AIOps 的落地效果;
-
配置管理不完善： CMDB 缺乏维护， 无法获取系统间关系的描述，拓扑依赖，相关运维监控数据元数据缺乏管理，都会降低落地效果，特别是在故障根因定位中，缺乏关系描述所形成的有向无环图，就很难利用传播关系算法去帮助定位根因。当然，这个可以通过由 APM ，或者 NPM 工具，所生成的应用拓扑去部分弥补;
挑战4：大数据基础复杂，性能及多样性要求高，元数据管理
整个 AIOps 平台最核心数据平台的部分，是要满足以下的需求：
-
高吞吐量，能实时处理海量，不同类型的数据(Metrics , Logging , Tracing);
-
具备强大的流式计算能力;
-
数据在插入后，能被准实时的检索，聚合;
-
数据变化多样，会不停地新增动态列，数据存储模型随时会改变;
-
超高的分析聚合计算性能，需要提供多维列式数据库的分析能力;
-
提供强大的实时搜索分析能力，可以通过关键字对事件信息进行检索;
-
具备一种或多种的数据查询 DSL，便于实现不同的分析场景;
-
具备历史数据和近线数据的分别处理的能力;
-
数据存储能对接到多种的 ML 框架中，作为数据源，训练模型;
-
数据要能实现上卷预聚合，在进行长时间范围聚合的时候，如月报等逻辑时，可以节约计算时间;
-
大的查询进入到平台，平台要有自我保护机制，不会造成故障;
-
良好的元数据管理的能力，包括如果从那么多数据中，按照模型还原相应的指标，以及指标间的关联关系;
-
能够与在线的算法模块进行集成;
以上的描述，都是 AIOps 的数据能力要求，往往需要多个大数据处理，存储组件，才能满足这种苛刻的要求，而且还需要无缝的整合起来，相应的工程技术难度非常大。
挑战5：人才匮乏
目前在国内，无论是算法人才，还是大数据人才，都是比较匮乏的及昂贵的，在人才招募，项目预算制定的时候，要充分考虑相关因素。
从人才的意愿来看，大部分的算法工程师及大数据工程师，更愿意去参与一些离变现比较容易的场景，如推荐系统，视觉识别系统等，如何吸引更多的人才，特别是算法科学家等，让他们感兴趣，加入到 AIOps 的场景中来，也同时获得较好的经济回报，是整个业界需要考虑的地方。
建议
-
企业结合自身的情况，合理控制期望，分阶段进行演进，查漏补缺;
-
建立一个完整的运维数据大数据体系是项目运维的关键，也是为智能化打下良好的基础;
-
以将整合指标数据、日志数据作为切入点，落地逐步整合更多的数据源，产生更大的收益;
-
智能化部分的落地场景优先聚焦在监控的异常检测，以及日志的智能聚类;
-
立足运维，面向业务，将 Operation 的含义演绎为运营，为业务提供商业价值;
总结
AIOps 的确是一个非常革命性的概念框架，它从大数据和 AI 的能力视角，去颠覆或者完善现在的 ITOM 运维体系，给学术界，工业界，最终用户，指明了一个明确，可持续高速发展5-10年的发展方向。可以预计，在未来 5-10 年内，大量关于 AIOps 的新思想，新理论，新技术，将会像寒武纪生命大爆炸时，不断的涌现，创新源源不断，作为业界工作者，作为企业，作为厂商，如何在这次的周期中抓住属于自己的机会，这是一个很值得思考的命题。
AIOps 让运维部门一下成了公司层面拥有数据最多的部门，运维人如何自身进化，从运维到运营，对大部分运维人来说，都是一个巨大的机会及挑战。
虽然 AIOps 的确给我们带来很多的想象空间，但是我们还是要以实际落地，实际帮助企业产生效率为导向，要避免跳入 AI 过热的炒作风，一步一脚印，直面挑战，持续演进，不断吸收世界先进的经验及思想，从而迎接未来这10年的黄金时代。
OneAPM 全新推出新一代 AIOps 平台 I2，欢迎您随时联系我们，即刻开启贵公司的智能运维之旅。点击进入 AIOps 官网了解更多信息。
-
- 来源：http://blog.oneapm.com/apm-tech/816.html
来源：https://www.cnblogs.com/oneapm/p/9223687.html