今天知乎上有个老问题重新热了起来：「传统的运维工作是否会被 DevOps 和 AIOps 完全取代？」一天之内新增了好几条回答。知乎B 站一条《从夯到拉锐评测 18 个运维岗》的视频，几小时评论区就挤满了真实运维人的自述——有桌面运维说自己仓促入行，「这么一干就是四年」。哔哩哔哩微博上，「传统运维岗位萎缩，运维 + AI 复合型人才供不应求」的说法也在流传。微博
与此同时，你的信息流里大概率还混着另外两种内容：一种是厂商文，宣称「全闭环、30 秒自愈、全程无人介入」；另一种是培训机构，用「AI 不会干掉运维，但会淘汰只会手工重复操作的人」制造焦虑，下一句永远是「来报课」。
这些信息叠在一起，很难不让人心里打鼓。但把这一周知乎、B 站、微博、36 氪的讨论交叉着看完，我的判断是：「取代论」大多是噪音，但如果你当真觉得什么都没变，那也是在骗自己——运维这项工作的技能资产，正在被重新定价。
先看这周真正发生的三件事
第一件，AWS 的 DevOps Agent 今年 4 月正式 GA 之后，8 月中旬又被国内技术社区集中讨论了一轮。微博有意思的是，这位大厂选手的卖点相当克制：故障来了，Agent 做的是只读调查——读日志、校验配置、关联事件时序、输出根因和缓解方案，全程不碰写权限，靠 RBAC 分级和全量审计兜底。针对 DynamoDB 限流、Lambda 并发溢出、API 429 这类高频故障，宣称能把跨天级的救火压缩到 10 分钟内给出结论。知乎注意重点：连 AWS 都停在「调查+建议」，把执行权留给人。
第二件，Spotify 披露的一组数字：约 2900 名工程师，每天约 4500 次部署，73% 的 PR 已经可以直接由 AI 生成。36氪这些数字出自 36 氪报道的 Spotify 与 Claude Code 之父的对话——它说明在交付侧，AI 已经不是玩具，而是流水线的一部分。
第三件，「DevOps」一词的提出者 Patrick Debois 最近的一场演讲被 36 氪完整报道，几个核心判断值得划重点。当 Agent 没按预期完成任务时，「不要再去修改它生成的代码，而要去改进整个系统，而不是只改 Prompt」。36氪组织的护城河是沉淀进 skill、context、harness 里的业务上下文；而那种「发几个 AI 编程工具账号、搞几场培训」就叫转型的公司，结局通常是「一千朵花长成一千根杂草」。
他还提到一个更微妙的变化：开发者正在从「写代码的人」变成「指挥 Agent 的编排者」。不少工程师对这种转变有强烈的身份摩擦——「我们入行是搞技术的，不是来天天调 Prompt、写 SPEC 的」。Debois 承认这种摩擦真实存在，但转折点也在这里：当组织开始围绕 Agent 搭 harness、循环和技能注册中心，一批新的硬核工程问题被打开，之前抱怨「这不是我该干的」的人，反而成了最合适做这些事的人。
三层噪音，建议先摘干净
第一层，厂商的「全闭环」叙事。这波 Agentic AIOps 软文里，「全程无人介入」「30 秒自愈」是标配话术，但通篇找不到第三方验证数据。而工程社区在认真讨论同一个问题——「AI 运维该不该自动执行命令」时，结论保守得多：只读观察可以有条件自动执行，但要满足三个前提——目标明确（到底操作哪台主机）、环境隔离（命令进哪个执行通道）、性质可判定（只读还是写）；会改变系统状态的命令，默认就该停下来审批。知乎下次再看到「无人值守全自动」的宣传，可以先问一句：生产核心系统上，你的 Agent 写操作谁来批？
工程圈的讨论还在往更具体的地方走。最近半年真正把运维 Agent 做进生产环境的技术复盘里，大家首先谈的不是模型多聪明，而是数据怎么打通：「全栈替换」路线（把监控、告警、CMDB 整套换掉）的迁移成本企业很难接受，「对话外挂」路线（在现有工具上套一层聊天界面）又会遇到跨工具推理的上下文断裂。知乎也就是说，AI 运维的落地问题，已经被拆解成数据归属、风险分级、审批策略这些可以逐项核对的工程问题——没人在认真讨论「要不要把人全换掉」。
第二层，培训机构的淘汰论营销。「基础运维内卷、AI 运维缺口大、薪资高出 30%+」——这类说法在微博和短视频里满天飞，但没有一个能追溯到统计口径，它们出现的唯一上下文就是课程广告。微博焦虑是真的，但别让别人用你的焦虑做转化。
第三层，「会不会被取代」本身是个伪问题。知乎那个问题下被顶起来的回答说得很实在：AI 目前是「赋能」而不是直接替代，替代就算发生，也会在真正提效之后。知乎另一篇重审 Google SRE 经典的文章判断更准：SRE 的初衷本来就是消除 Toil（手工重复劳动），AI 只是加速了这个目标的实现。知乎而错误预算、SLO、无责复盘这套框架，反而成了给 AI 组件本身定可靠性标准的地基。
真正在发生的变化：技能资产分三类
与其问「会不会被取代」，不如把手上的技能按资产盘一遍。
贬值资产：救火动作本身。人肉翻日志、盯告警、敲重启、跑命令——这是 Toil，是 AI 最先接管的活，也是本来就该被淘汰的活。如果你的一天 80% 是这些，风险不是「AI 太强」，而是这些动作没有积累性，干十年和干一年差别不大。
平值资产：工具操作。写 YAML、配监控面板、点发布平台，仍然需要，但已经是标配，不再产生溢价。
增值资产有三类。一是故障判断力和执行边界感：哪些命令看似只读实则危险、哪些变更影响面不可控——Debois 管这种持怀疑态度的老运维叫「宝贝」，因为 Agent 恰恰需要把这份挑剔和隐性知识灌进去才能变好。二是把经验沉淀成可复用系统的能力：runbook、skill、context、harness 约束，这是他说的那条护城河。三是给非确定性系统做可靠性设计的系统思维：SLO、错误预算、postmortem——AI 组件的输出每次都不一样，谁来给它定标准和兜底，谁就站在价值链上游。
Debois 还给了一个招人公式：极致用 AI × 扎实工程功底 × 愿意分享协作。注意这三项是相乘关系，任何一项是零，乘出来都是零。36氪
接下来三个月，做三件低成本可验证的事
第一，把最近半年的高频故障列个清单，逐个写成 runbook：触发条件、排查路径、处置动作、验证方式。这不是给公司写的，是给你自己攒的——它将来就是喂给 Agent 的「技能库」，也是你面试聊 AI 运维时拿得出手的证据。
第二，找一条只读型 AI 排查链路真实用一遍（大厂云已经有现成产品），重点观察它在哪里断掉：找不到目标主机？读不到关键日志？关联不上变更？它断掉的地方，就是你短期内贬值不了的地方。
第三，观察一个信号，判断你公司的 AI 运维是来真的还是摆样子：平台团队有没有开始接手 Agent 权限管理、技能注册、context 评估这类脏活？有，说明在落地；如果只是给每人发个 AI 编程账号让大家「自行摸索」，那按 Debois 的说法，这家公司还没准备好——你先冲，容易变成杂草里的那一根。36氪
说到底，这一轮不是「AI 取代运维」，而是运维经验的重新定价：没被沉淀的经验，有没有 AI 都在贬值；被沉淀下来的经验，AI 会是它的放大器。真正要回答的问题从来不是「我会不会被取代」，而是——你的经验，现在是什么形态？
