获课地址：789it.top/17359/

一、先搞清楚一个问题：AIOps 和 SRE 到底是什么关系

很多人一上来就混淆这两个概念，导致学习方向跑偏。

SRE（Site Reliability Engineering） 是一套方法论：用软件工程的方式做运维。核心是：SLI/SLO/Error Budget、故障响应、容量规划、变更管理、可观测性……它回答的是“我们应该怎么做运维”。

AIOps（Artificial Intelligence for IT Operations） 是一套技术手段：用 AI/ML 算法来分析运维数据（指标、日志、链路追踪），实现异常检测、根因分析、故障预测、智能告警……它回答的是“怎么用算法来辅助甚至替代人做运维决策”。

它们的关系是：SRE 是骨架，AIOps 是血肉。 没有 SRE 的方法论，AIOps 就是一盘散沙的算法；没有 AIOps 的自动化，SRE 就只能停留在“写文档、定流程”的管理层面。

所以在学习路线上，你要两条腿走路：

一条腿：SRE 的核心方法论（不学这个，你连“要自动化什么”都不知道）

一条腿：AIOps 的核心技术（不学这个，你的自动化还停留在“写 if-else 脚本”的原始阶段）

下面我会按学习的优先级，拆解出 5 个核心模块，告诉你每个模块“重点学什么”“学到什么程度算够”“怎么学最快”。

二、模块一：可观测性——AIOps 的“数据源头”（优先级：最高）

没有数据，AI 就是无米之炊。可观测性是整个 AIOps 体系的基石。

很多人把“可观测性”等同于“监控”，这是个致命误解。监控回答的是“系统出了什么问题”（CPU 高了、内存满了）；可观测性回答的是“系统为什么出这个问题”。

可观测性有三个支柱，你需要系统掌握：

2.1 指标（Metrics）

这是你最熟悉的。但传统做法是“拍脑袋选指标”：CPU、内存、磁盘、网络……然后画几个大盘。

AIOps 视角下的指标设计完全不同：

USE 方法：每个资源的 Utilization、Saturation、Errors

RED 方法：每个服务的 Rate、Errors、Duration

Google 的四个黄金信号：延迟、流量、错误、饱和度

学习重点：不是学怎么用 Prometheus，而是学“应该采集哪些指标”。指标设计得好不好，直接决定了后续异常检测和根因分析的上限。建议花时间研究 Netflix、Google 等公司的 SRE 公开文档，看他们怎么设计指标体系。

2.2 日志（Logs）

日志的传统用法是：出问题了，grep ERROR，然后人肉阅读。这在微服务环境下已经彻底失效了——一次故障可能涉及十几个服务，几万行日志，你看不过来的。

AIOps 下的日志处理，你需要掌握的是：

日志的“结构化”：不要把日志打成一行字符串，要用 JSON 格式，字段清晰

日志的“分级与采样”：全量采集成本太高，需要设计哪些日志必须存、哪些可以采样、哪些可以丢弃

日志的“模板化”：把变量替换成占位符，把“User 12345 logged in”和“User 67890 logged in”归为同一类模板，这是后续异常检测的基础

学习重点：实践“日志模板提取”的方法。你可以用现成的工具（如 logreduce 或自己写简单脚本）去分析一批日志，看能不能把成千上万条原始日志归成十几个模板。这个能力比学某个日志平台更重要。

2.3 链路追踪（Tracing）

这是云原生时代最关键的观测手段。一个请求穿过网关→服务 A→服务 B→数据库→缓存→消息队列→服务 C……如果没有链路追踪，你根本不知道慢在哪里。

学习重点：理解 Trace、Span、Parent-Child 关系的概念，知道怎么在代码里埋点传递 trace_id。技术上可以用 OpenTelemetry 这套标准——它已经成为事实上的行业标准，学一次，所有厂商通用。

学习路径建议：不要同时学三个支柱。先攻 Metrics（你最熟悉，容易上手），再学 Tracing（最核心，最体现云原生特色），最后学 Logs（有了前两个的基础，日志的定位会更清晰）。每个支柱花 1-2 周实践，5-6 周打牢基础。

三、模块二：异常检测——让系统“自己发现不对劲”（优先级：次高）

传统监控的告警规则是人工配置的：“CPU > 80% 持续 5 分钟就告警”。

问题是什么？你配得过来吗？几百个微服务，每个服务几十个指标，你配到猴年马月？而且静态阈值根本适应不了动态负载——半夜业务低峰，CPU 30% 可能已经异常了；白天大促，CPU 80% 可能完全正常。

AIOps 的答案：让算法自动学习指标的“正常模式”，然后识别偏离。

你需要掌握的核心内容：

3.1 时间序列异常检测

运维数据里，90% 都是时间序列（CPU、内存、QPS、延迟……）。你需要理解几种经典方法：

统计方法：3-sigma（正态分布假设）、移动平均、指数平滑——简单，可解释性强，但对复杂模式无效

季节分解：把时间序列拆成趋势项、周期项、残差项——非常适合有规律的业务（如“工作日高、周末低”）

机器学习方法：孤立森林、One-Class SVM——不需要标签数据，适合探索性检测

深度学习方法：LSTM、Transformer 做时序预测——精度高，但需要大量数据和调参

学习重点：不要一开始就上深度学习。从统计学方法入手，因为它们的数学门槛低、可解释性强、计算开销小，足够覆盖 80% 的场景。等你踩过“统计方法不够用”的坑，再学 ML 方法，会有“原来如此”的感觉。

3.2 日志异常检测

日志异常的模式和指标不同。指标是数值，日志是文本。

核心思路是：把日志模板化成“事件类型”，然后看“不应该同时出现的事件同时出现了”或者“事件的出现顺序乱了”。

学习重点：理解“日志模板提取 + 序列挖掘”这条技术路径。不需要自己实现算法，但要知道现有的开源方案（如 Loglizer、DeepLog）大概是怎么做的，以及它们的局限性。

学习建议：异常检测是一个“容易入门、很难精通”的领域。不要追求“学完所有算法”，那会把你淹死。相反，你应该：

先手算几个简单指标的标准差，理解“什么是异常”

用现成工具（如 Prometheus 的 stddev 函数）跑通一个检测案例

然后深入学一个你最需要的算法（比如季节性分解）

把精力花在“怎么评估检测效果”上——误报率和漏报率哪个对你更重要？怎么调整阈值？

四、模块三：根因分析——从“知道坏了”到“知道哪里坏了”（优先级：中高）

异常检测告诉你“现在有问题”。但你真正需要的是：哪里出的问题？

在微服务架构里，这是最难的问题。一个“接口慢”的 symptom，可能的原因有几十个：下游服务慢了、数据库连接池满了、GC 频繁、网络丢包、CPU 节流、甚至 DNS 解析超时……

AIOps 的根因分析，不是“一个算法”，而是一套“推理系统”。核心思想是利用系统的拓扑结构。

4.1 依赖关系图

你需要知道服务之间的调用关系。A 调 B，B 调 C，C 调 D。当 D 出问题时，A、B、C 都会表现出异常。算法需要从“所有服务都异常”里推断出“D 是源头”。

学习重点：理解“基于时间序列因果推断”的基本逻辑——哪个指标的异常发生得最早、哪个节点的异常能解释其他节点的异常。不需要自己实现格兰杰因果检验，但要知道它的存在和适用场景。

4.2 多维下钻

一个指标聚合起来是“平均延迟变高了”。但可能是某个特定机房、某类用户、某个实例、某个时间窗口的问题。

多维下钻的思路是：自动在所有可能的维度上“切分”，找到那个最能解释异常的维度组合。

学习重点：理解“决策树”思想在根因分析中的应用——信息增益、基尼系数这些概念不需要深究，但要明白“系统怎么自动找到最可疑的那个维度”。

4.3 知识图谱

最先进的根因分析方法，是把历史故障的处理经验变成知识图谱。当新的异常模式出现时，系统自动匹配历史上相似的故障，给出候选根因和处理方案。

学习重点：这不是初学者需要深入的方向。作为学习课程，你只需要知道“有这个方向”就可以了，等到实践中遇到瓶颈再去研究。

学习建议：根因分析是 AIOps 里最难啃的骨头。前期不要试图自己实现一个根因分析系统，那超出了个人学习的合理范围。你的目标应该是：

能看懂现有根因分析工具（如阿里云 ARMS、SkyWalking 的拓扑分析）的输出

知道它是基于什么原理得出的结论

能人工验证它的结论是否正确

等到你有了实际业务场景和足够的数据积累，再考虑定制化的根因分析方案。

五、模块四：故障预测与容量规划——从“被动救火”到“主动防火”（优先级：中）

这是 SRE 工作的最高境界：在故障发生之前就阻止它。

5.1 故障预测

不是“算命的”，而是基于历史数据预测“这个磁盘大概会在 7 天后写满”“这个服务的 QPS 会在下周大促期间超过容量上限”。

核心技术就是时间序列预测——你已经在模块二里接触过了。区别在于：异常检测看的是“当前是否异常”，故障预测看的是“未来什么时候会达到阈值”。

学习重点：把你在模块二里学的预测方法（移动平均、指数平滑、Prophet 等）应用到“未来值预测”上。重点不是精度，而是不确定性量化——你应该输出“有 95% 的概率在未来 5-8 天内磁盘写满”，而不是“第 7 天磁盘写满”。

5.2 容量规划

容量规划的本质是：业务量在增长，你的资源够不够？什么时候需要扩容？扩多少？

AIOps 的容量规划是 “需求预测 + 资源建模”：

需求预测：用时间序列预测业务量（QPS、日活、订单量）

资源建模：每个 Pod 能扛多少 QPS？数据库的连接池上限是多少？

计算出资源缺口，给出扩容建议

学习重点：理解“线性模型”在容量规划中的应用——虽然简单，但可解释性强，业务也容易接受。先把线性模型用熟，再考虑更复杂的非线性模型。

学习路径建议：故障预测和容量规划，本质上是同一个能力（预测）在两个场景的应用。建议一口气学完预测方法，然后分别应用到两个场景里。这样效率最高。