---
url: /sre/planning/sre-ai-era.md
description: >
  当 AIOps 平台能自动识别异常、大模型能写出自愈脚本、ChatOps 能自动答疑——SRE 的护城河在哪？本文给出一个耐用的回答：AI 替代的是 SRE
  的"动作"，不是 SRE 的"判断"。真正的价值是在不确定下做权衡、为后果负责，并设计"该不该自动化"的护栏。
---

最近一年与同行交流，最常听到的一句话是：「AI 都这么能干了，还要 SRE 干什么？」这背后是一个真问题：当 AIOps 平台能自动识别异常模式、当大模型能根据日志写出自愈脚本、当 ChatOps 能在群里自动答疑——SRE 这个岗位的护城河到底在哪里？

我想给出一个不那么时髦、但更耐用的回答：**AI 替代的是 SRE 的"动作"，不是 SRE 的"判断"。**

## 一、AI 已经接管了哪些动作

先把账算清楚：过去三年，AI/AIOps 在 SRE 领域已经稳稳拿下了这些阵地。

* **智能告警聚合**：把几十条相关告警聚合成一次事件根因，附带严重度评估。
* **日志模式识别**：从海量日志中识别异常模式，省去人工翻日志。
* **阈值自适应**：基于历史数据自动调节监控阈值，降低误报与漏报。
* **Runbook 自动生成**：根据故障描述自动起草恢复脚本。
* **故障知识库问答**：把散落的复盘文档变成可对话的内部 ChatOps。
* **剧本式自愈**：在隔离环境里执行预设的自愈流程，把值班员从凌晨三点捞起来。

如果把"动作"定义为可被规则化、流程化、脚本化的工作，AI 已经吃掉了其中一大块。这没有什么好回避的。

但是——这是我想展开的部分——这些"动作"从来不是 SRE 真正的价值所在。

## 二、SRE 真正的价值：在不确定下做权衡

把 SRE 工作的全貌摊开看，AI 真正擅长的是**确定性问题**——有清晰规则、有充足样本、可以反复回放验证的任务。但 SRE 工作的另一半，恰恰是**不确定下的权衡**：

* **稳定性 vs 迭代速度**：上线频率要提到一天 30 次，混沌工程要不要做？告警阈值要收紧还是放松？
* **成本 vs 体验**：一个慢查询每月多花 8 万，但只影响 0.01% 用户，重不重要？
* **自动化收益 vs 维护成本**：把 6 个手工巡检写成脚本省了 2 小时/周，但要付出一位工程师 3 周的开发与持续维护，划不划算？
* **告警敏感度 vs 告警疲劳**：阈值降到 95% 时每月多 200 条告警，是降低漏报还是制造疲劳？
* **跨团队利益冲突**：业务要弹性扩缩容、财务要降本、研发要稳定，谁说了算？

这一类问题，AI 现阶段只能给"候选答案"，没法给"最终答案"。因为每一个决策背后都有**责任主体**——SRE 工程师（或 SRE 团队）才是那个在事故复盘报告上签字的人。

换个角度说：AI 给出的是"菜谱"，SRE 决定的是"今晚到底吃不吃外卖"。前者是知识，后者是判断。

## 三、被低估的能力：识别"不该自动化"

很多团队把 AI/SRE 数字化做歪，不是因为 AI 不够强，而是因为他们把"自动化"等同于"价值"。

我见过一些典型反模式：

* 把凌晨 3 点的 20 条告警全部接入自动化工单系统，工程师第二天上班时面对 200 条待办，反而把真正紧急的淹没了。
* 用 AI 自动跑巡检脚本，但**没有人在回路**做风险评估，结果巡检脚本越跑越多，真正的高风险项反而被稀释。
* 一键"自愈"按钮上线后，根因不再被追溯，监控系统沦为"重启一下就好"的工具。

SRE 的不可替代价值之一，是能识别\*\*"哪些事情不该自动化"、"什么时候该停手"、"这个剧本是否值得做"\*\*。AI 越强，这种"踩刹车"的判断就越重要——因为工具越强，滥用造成的损失就越大。

这也是为什么我说：**会"问 AI"比会"操作"更值钱。** 当 AI 给出 3 个修复方案时，谁来选？当 AI 信心 60% 时该不该执行？当 AI 推荐重启容器时，有没有考虑过这是某次内存泄漏的早期信号？

## 四、SRE 的新画像：AI 编排者、风险治理者、质量守门人

如果一定要给"AI 时代的 SRE"画一张新画像，我会画三个角色：

### 1. AI 编排者（AI Orchestrator）

不是"用 AI 工具的 SRE"，而是"用 AI 把杠杆放大的 SRE"。具体能力包括：

* 把 AI 嵌入值班流程，而不是把 AI 当玩具玩；
* 设计"人在回路"的关键决策点；
* 评估每个 AI 介入环节的**失败成本**；
* 在 AI 误判时及时回退与修正。

### 2. 风险治理者（Risk Steward）

AI 越强，治理责任越重：

* 为 AI 自动执行的剧本设置**风险等级与审批阈值**；
* 定期审计 AI 决策日志，发现系统性偏差；
* 在 AI 与业务之间建立**对齐机制**——AI 的优化目标与 SRE 的优化目标并不天然一致。

### 3. 质量守门人（Quality Gatekeeper）

SRE 是最后一道防线：

* 防止"AI 自愈"变成"AI 掩盖问题"；
* 防止"AI 智能告警"变成"AI 让告警更难懂"；
* 在系统发生异常时，确保**故障的真实信号**依然能被传递到该知道的人手中。

## 五、能力迁移：从"执行者"到"判断者"

那么 SRE 的能力模型该怎么迁移？我自己的体感有三条主线：

### 主线一：从"修机器"到"问问题"

过去 SRE 的典型能力是：日志在哪里、Prometheus 怎么查、Kubernetes 怎么排障。现在这些都可以问 AI 助手、问内部 ChatOps、问文档知识库。

但更重要的是：

* 这个问题**是不是该问**？——判断问题本身的优先级。
* AI 给的答案**该不该采信**？——批判性评估 AI 输出。
* 答案与现场不符时**哪里出错**？——追溯根因。

### 主线二：从"写脚本"到"设计护栏"

自动化脚本的"写"越来越被 AI 接管，但"设计"不能被接管：

* 这条自动化**是否值得做**？——评估投入产出比。
* 自动化的**失败模式**有哪些？——设计兜底与回滚。
* 自动化的**副作用**是什么？——避免引入新的隐性故障。

### 主线三：从"应急响应"到"风险前置"

SRE 的工作重心会从"救火"前移到"防火"：

* 把事后复盘的事故模式转化为前置防控；
* 用 AI 模拟故障做混沌工程的剧本；
* 在架构评审阶段就介入，把可靠性从"事后修"变成"前置设计"。

## 六、不是 SRE 被 AI 取代，而是不会用 AI 的 SRE 被会用 AI 的 SRE 取代

我想用一个稍微刺耳的句子收尾：

**AI 不会取代 SRE，但"拒绝 AI 的 SRE"一定会被"驾驭 AI 的 SRE"取代。**

这不是一句鸡汤话，而是一个工程现实：当一个会用 AI 的 SRE 能在 1 小时内完成过去需要一周的故障复盘报告；当一个会用 AI 的 SRE 能同时看护 3 倍的系统规模；当一个会用 AI 的 SRE 能把"凌晨 3 点的告警"变成"上午 10 点的策略调整"——那些还在坚持"我手动跑命令更稳"的同行，在职业市场上会越来越贵——**贵在性价比，而不是贵在稀缺**。

AI 时代的 SRE，价值不再来自"我多会操作"，而来自"我多会判断、反思、拒绝、并为后果负责"。

这才是真正的护城河。

***

**相关阅读**

* [自动生成 Skill 的价值：复用、治理、降方差](./skill-value.md)
* [系统可用性健康感知三剑客：监控、拨测与巡检](../practice/monitoring-health.md)
* [监控 vs 可观测性 2023](../observability/what-is-observability.md)

***

**备选标题**

* AI 时代，SRE 的不可替代性
* 当 AI 接管运维：SRE 工程师还剩什么
* SRE 的下一站：从救火队长到 AI 编排者
* AI 不会取代 SRE：但会淘汰 80% 的运维套路
* 别被 AI 焦虑绑架：SRE 的真正护城河在哪