本文介绍我在PyCon2019上海站的议题内容，结尾有PPT下载链接。根据Gartner的报告，AIOps将在未来5-10年落地开花，并集中统一各种Ops平台（Dev、IT、Net、Sec），本议题介绍AIOps的核心作用、相关工程难点（数据采集、数据中台、智能算法、自动化等）与开源方案选择，适当介绍了Python在其中的主要作用，覆盖开源方案有：Kafka、Elastic Stack (Beats， Elasticsearch，Kibana)、K8S、Prometheus、Grafana、Thanos, Tick stack (Telegraf，InfluxDB，Chronograf，Kapacitor)、Ansible、OpenTelemetry、Skywalking、Druid、Clickhouse等。

AIOps并不是蹭热点，而是以实实在在解决IT运维的痛点或提高效率为目标。一直以来IT运维存在以下3个核心指标/目的：

MTTR（Mean Time To Repair）平均修复时间，是一个衡量系统宕机时间的指标，IT运维人员以降低此目标为第一要务，越低越好。

公司每年需要在IT上投入很多钱，包括硬件、软件、服务、人员等，通过IT运维希望将资源效率提高到最高，形成持续的成本优化。另一方面，宕机也会带来业务损失（例如电商一时不能用，客户就无法下单），因此此指标也与MTTR和SL相关，MTTR越长，SL越低，成本也越高。

SLA表示客户与服务商之间服务可用性的承诺，一般以服务可用性用时长为维度，例如99.99%可用，表示一个周期（例如一个月）宕机的总体时间不超过0.01% * 365天 < 4.5分钟。有时也表示API错误率占比。

但是IT运维所面临的挑战也呈现越来越高的趋势，大概分成两类原因：

目标系统越来越复杂，快速定位问题难度越来越高，具体细分为：架构演变复杂化和数据孤岛越来越多。

架构演变复杂化随着云计算的普及，许多公司存在云上、云下业务，甚至多云策略（海外业务用AWS，亚太用阿里云）；SaaS的普及（这点在海外非常普遍），容器化与微服务架构的流行，使得一套系统的部署非常复杂。某一个环节出错，可能落点也都有可能。

数据孤岛越来越多各种数据存储于各个系统之中，在大数据下呈现4V特点（容量Volume、速度Velocity、种类Variety和价值Value），很难集中采集与处理，一旦发生问题，很难有效检查具体数据信息。

祸不单行，修复的IT问题的成本也越来越高，具体细分为三类原因：

业务中断成本信息化越来越发达的今天，一些流行产品动辄上亿PV、千万UV。例如一些电商、服务系统，一旦临时不可用，造成的损失就是客户无法下单、转投竞品处购买，设想一下，双十一当天每秒的交易额可知成本之高，对于金融、公共服务类的系统，则会造成更大的损失也有可能，基本都会成为新闻报道。

缺少持续改进另一方面，普遍存在的现象是运维人员的日常工作大部分时间都在忙于救⽕，自然缺少持续改进的时间和机会，包括工程流程上梳理漏洞，编写引入自动化工具，客户培训等

学习速度跟不上这里特别强调这点，是因为其实人始终是一个非常重要的原因，业务增长的速度往往超乎人的想象（参考风口论），某个业务在一年内提高5倍、10倍甚至100倍都是有可能的，但人的学习成长速度往往很难匹配上。

虽然Ops的概念很宽泛，但一般AIOps表示Artificial Intelligence for IT Operations，可以理解为组合了大数据、机器学习、分析来帮助IT运维实现其目标（例如发现、预测、修复问题）。

而Gartner报告中的一张图可以更具体的解释AIOps对IT运维的改进：

可以看到AIOps平台要求采集各种数据（包括日志、指标、网络数据、API、文本、社会媒体信息等），用于分析、训练API、关联分析等以达到效果。

如前述IT运维挑战所说，完整、实时地采集以上数据是很不容易，且这类数据又被各种角色的人所关心，包括不限于：

因此Gartner认为AIOps会从功能（Feature）演逐渐变成平台并落地，且预测到2022年年，40%企业会使⽤用AIOps。

机器智能主要在如下4个场景下帮助ITOps完成目标：

增强描述性

增强排错

增强预测能力

增强辅助根因分析

总而言之，AIOps的最终目标时促进IT运维的目标达成，逐步释放IT运维人员的效率束缚，理想的未来，甚至被认为是服务Level-0（第一道关）的存在：

以下将AIOps系统拆解，并逐个从数据采集、数据中台、智能算法、自动化等角度分析其工程难点。

简单描述，一个典型的AIOps的系统可以划分为如下层次：

更进一步，借鉴热门AIOps创业公司Moogsoft的一张图：

自上而下的划分，可以看到如下子系统：

没有大数据，AIOps就如巧妇难为无米之炊，实时、有效、完整地数据采集是AIOps的基础前提。

如前面IT运维的挑战类似，数据采集是很困难的，随着技术架构的演变，数据有3V（（大容量、常变化、高速增长））的特点、以各种格式（Log、Tracking、Event；Metrics、IoT data；⽹网络数据）存在于各种来源（ SaaS、多云、容器器、微服务、主机、应⽤用等）中。

各种类型的数据之间也有各自的特点，如下：

可见Tracking数据价值大，但采集难度较大；日志类的价值普遍更高；指标类数据简单，但数据量也可能非常大（IoT场景下）；文本内的价值能力最大，但加工难度最大。

另一方面，数据之间也有一定的重叠（数据量仅供参考）：

某种程度上，在一些产品中，tracking、指标类数据被认为是一种结构化的日志。

没有数据中台，AIOps如空中楼阁，我们看下数据中台具体是什么，又要做什么：

数据中台要能够有效存储和索引各类数据（时序指标数据、⽂文本数据、⽇日志、⽹网络数据、Tracking等）。这里有效指的是，针对前述数据类型的特点，有针对性的提高存储、检索效率（例如时序数据的索引与日志类的索引是有所不同的）。

还需要支持流式（或微批实时）分析处理，例如实时统计PV或异常告警。另一方面，也需要支持多维度的实时关联统计与分析，且支持交互式add-hoc方式。

数据治理的能力也很重要，包括如下两个方面，数据加⼯：支持通⽤数据模型，且支持对多维机器数据、半结构化数据进行灵活的规整或与各种第三⽅数据关联（富化）等。数据⽣命周期管理：随时间流式，更老的数据需要降维、聚集或归档等，需要有这方面的支持。

如前述，机器学习具体在如下几个场景发挥作用：

但算法落地面对一些直接的挑战：

AIOps的最后一块重要系统是外部数据集成与自动化，这也是为什么一些大厂逐步在补齐方面的短板。这部分主要包括工单系统、CMDB（资产管理）的集成；Run Book自动化、告警与应用的编排能力。

这里介绍一些特定场景下特定的平台搭建的开源选择及策略：

这里以容器化架构为例，自下而上可以看到多个层次的开源方案选择。

这里选择上面三类监控方案作为中台进行能力比较，维度参考前述挑战中的方面：

其中Prometheus和Tick方案对于指标类支持很好，而Elastic对于日志类支持更好。但流式分析方面，Prometheus和Elastic方案并无直接支持。而统计关联分析方面，Elastic较强，其他一般。在数据治理方面的支持，三个方面也都差强人意。总体而言，一个结论是：没有银弹。

以下大致介绍下相关方案的特点与优缺点。

Prometheus作为K8S监控标配（继K8S后第2个CNCF项⽬目），其有如下特点：

作为通⽤型指标类可视化⽅案，Grafana已然是Phrometheus的连体婴儿了，其有如下特点：

试图解决Prometheus的几个核心问题而生的方案，其有如下特点：

是目前CNCF蓝图下统⼀Metric、Tracking的新标准（统一了Open Tracing和Open Census），目前还处于开发阶段，其主要是客户端标准。

SkyWalking作为国内流行Tracking方案，已经是Apache孵化项目，其有如下特点：• 性能影响较小(