这篇不先堆名词。我们把《大模型岗位变了运维工程师该补的还是算法吗》拆成几级台阶看完至少知道下一步该学什么、该练什么。摘要去年这时候朋友圈里全是“大模型重塑运维”的口号大家忙着在本地跑 Demo看着模型回复“已处理告警”觉得离 SRE 2.0 不远了。今年再看那些 Demo 跑得飞起的同学有几个真的敢把 Agent 接进线上集群我面试过十几个想从传统运维转大模型方向的候选人发现一个共性问题代码能力没问题Prompt 写得也溜但一聊到权限控制、日志可观测性和审批流就支支吾吾。 这不是因为他们不懂 AI而是他们的思维还停留在“脚本时代”。运维转大模型最大的坑不是算法而是工程化。今天聊聊怎么跨过这道坎。目录从“脚本执行”到“意图执行”能力迁移的本质日志分析别让模型“瞎看”告警归因从“谁在报错”到“为什么报错”自动处置 Agent权限与审批是生死线可观测性让 Agent 的决策“透明化”总结运维转大模型补什么放什么从“脚本执行”到“意图执行”能力迁移的本质很多人以为运维转 AI 只要学 Python 和 LangChain 就行了这是最大的误解。传统运维的核心是确定性输入 A必然得到 B。你写个 Shell 脚本if error then restart逻辑清晰责任明确。大模型 Agent 的核心是概率性输入 A模型可能得到 B也可能得到 C还可能在中间幻觉出 D。迁移点在哪里1. 故障定位能力你以前看日志靠经验现在靠模型检索。你需要教会模型“什么是异常”而不是让它“猜”。2. 状态机思维运维讲究 SLA 和状态流转Agent 也是一样。一个完整的处置流程检测→分析→审批→执行→验证必须被建模成状态机而不是让模型自由发挥。3. 容错与回滚脚本执行失败可以重试Agent 决策失败可能导致数据误删。你必须设计好“后悔药”。建议先别急着学 RAG 或 Fine-tuning把你们现有的运维 SOP标准作业程序拆解开看看哪些环节可以规则化哪些必须交给模型。日志分析别让模型“瞎看”Demo 里你把日志喂给模型它分析得头头是道。生产环境里日志量是 Demo 的几万倍直接喂进去模型既慢又贵还容易漏关键信息。实战坑点我见过一个团队直接把 Kibana 的原始日志 dump 给 LLM结果Token 费用爆炸响应时间超过 30 秒告警都超时了模型被噪声淹没抓不到重点正确的做法分层处理1. 预处理用正则或轻量级规则过滤掉无关日志如心跳、健康检查。2. 摘要用一个小模型如 Text-Small生成日志摘要只把摘要喂给大模型。3. 结构化将非结构化日志转为 JSON 格式方便模型理解。# 伪代码示例日志预处理管道 def preprocess_logs(raw_logs: List[str]) - List[dict]: structured_logs [] for log in raw_logs: # 1. 过滤噪声 if is_noise(log): continue # 2. 提取关键特征 features extract_features(log) # 3. 生成摘要 summary llm.summarize(log) structured_logs.append({ timestamp: features[ts], level: features[level], service: features[svc], summary: summary }) return structured_logs判断标准如果你的 Agent 处理一条日志需要超过 5 秒或者 Token 消耗超过 1000说明预处理没做好。告警归因从“谁在报错”到“为什么报错”传统监控告诉你“CPU 高了”Agent 要告诉你“因为订单服务 QPS 突增导致连接池耗尽进而影响支付接口”。归因链路的构建1. 拓扑关联利用服务网格或 CMDB建立服务依赖关系图。2. 因果推断不要只靠模型猜要结合时间窗口和依赖关系缩小候选范围。3. 验证假设模型给出归因后必须通过查询指标或日志来验证。建议在简历里不要只写“实现了告警归因”要写出准确率和误报率。比如“通过引入服务拓扑约束将归因准确率从 40% 提升到 85%。”自动处置 Agent权限与审批是生死线这是运维转大模型最核心的价值点也是最危险的地方。权限隔离最小权限原则Agent 执行命令必须像 K8s 的 RBAC 一样严格。只读权限查询日志、指标模型可以自由执行。写权限重启服务、修改配置必须经过审批。高危权限删库、下线节点必须人工确认 双人复核。审批流设计不要相信模型的“自我约束”。在代码层面强制接入审批流。# Agent 动作定义示例 actions: - name: restart_service allowed_roles: [sre_agent] requires_approval: true approval_timeout: 300s post_action_validation: - check_service_health - check_error_rate实战建议在你的项目中展示你如何处理“模型想执行但被系统拒绝”的情况。这比展示“模型成功执行”更能体现工程能力。可观测性让 Agent 的决策“透明化”Demo 跑通后为什么不敢上线因为不可观测。运维工程师最擅长的是监控和告警现在你要给 Agent 也装上“眼睛”。必须追踪的三个维度1. 决策链模型为什么做出这个决定保存它的 Thought Process。2. 执行结果实际发生了什么对比预期和实际。3. 资源消耗Token 用了多少耗时多久日志规范{ trace_id: uuid, agent_action: restart_pod, model_reasoning: Pod OOM, memory 90% for 5min, input_params: {pod: order-svc-1}, output_result: {success: true, latency_ms: 1200}, cost: {tokens: 150, latency: 0.8s} }建议在面试中主动提到“可观测性”和“审计日志”这会让你显得非常专业。总结运维转大模型补什么放什么必补的能力1. Prompt 工程不仅是写提示词而是设计结构化输入输出。2. 权限与安全管理这是运维的天然优势要放大。3. 可观测性建设用老本行技能给新工具保驾护航。4. LLM 基础原理理解 Token、上下文窗口、幻觉来源不要知其然不知其所以然。暂时放一放1. 模型微调除非你有高质量的专属数据否则 RAG Prompt 足够应对 80% 的运维场景。2. 复杂算法不需要懂 Transformer 内部细节理解接口和限制即可。3. 从头造轮子基于 LangChain、LlamaIndex 等框架二次开发别重复造轮子。最后的话运维转大模型不是让你去和算法工程师拼数学而是让你用工程化思维把 AI 能力落地到生产环境。Demo 能跑只是起点能上线、可观测、有权限控制、能回滚才是终点。如果你正在准备面试建议你做一个完整的 AIOps Agent 项目重点展示异常处理和安全审批部分。这比十个 Hello World 式的 Demo 都有用。你的下一个职业增长点不在模型参数里而在你的工程经验里。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。