最近一年与同行交流，最常听到的一句话是：「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，价值不再来自"我多会操作"，而来自"我多会判断、反思、拒绝、并为后果负责"。
这才是真正的护城河。
相关阅读
备选标题
- AI 时代，SRE 的不可替代性
- 当 AI 接管运维：SRE 工程师还剩什么
- SRE 的下一站：从救火队长到 AI 编排者
- AI 不会取代 SRE：但会淘汰 80% 的运维套路
- 别被 AI 焦虑绑架：SRE 的真正护城河在哪