运维转大模型：能写脚本的很多，能搞定权限日志的才稀缺-Seo优化-塔城地区网站建设公司

如果你正准备往大模型方向转，《我用运维经验做了次 AI 项目，最先失效的是旧方法》这类问题别只看热度。更重要的是判断自己该补哪块能力，以及怎么证明你真的会。

摘要

上周联调完一个 AIOps Agent，运维同学信心满满地演示告警归因，模型一口气调了三个工具、查了四张表，最后返回结果完美。第二天接入生产环境，直接炸了——权限不够、日志对不上、关键 API 返回 403。

团队盯着报错懵了半小时，才发现 Demo 里用的测试账号和生产账号根本不是一回事。

这件事让我意识到，从运维转大模型，真正卡脖子的不是调 API，而是权限、日志、可观测这三件事。很多同行以为学会了 LangChain 或者能搭出一个能跑的 Agent 就算入门，实际上那只是热身。真正决定项目能不能上线、面试能不能拿 offer 的，是你能不能把 Agent 放进真实环境里跑稳。

---

运维能力的迁移

我做运维十年，最早写 Shell 脚本处理告警，后来用 Ansible 做批量部署，再后来转向 SRE，搞可观测性和容量规划。转大模型的时候，我其实没从头学 Python 或者算法，而是把运维经验平移过去。

迁移的核心是思维转变：以前你写脚本，逻辑是确定性的，输入 A 必然输出 B；现在你写 Agent，逻辑是概率性的，模型会自己规划路径，你只能约束边界。

比如以前告警来了，你写个脚本查 CPU、查磁盘、查进程，逻辑写在代码里；现在告警来了，你让 Agent 自己决定查什么、怎么查、查到异常后怎么办。你的工作从"写逻辑"变成"定义边界"。

这个转变很多人没转过弯。我见过不少转大模型的运维，还在用写脚本的方式写 Prompt，试图让模型一步一步执行，结果模型经常跑偏。实际上，好的 Agent 设计应该是：定义目标、提供工具、设置约束、事后复盘。

---

日志分析

Demo 阶段，日志分析很简单——模型调一个日志查询接口，返回几条记录，你看着没问题就过了。生产环境里，日志量是 Demo 的几百倍，模型要么查不到、要么查错、要么超时。

我们当时的问题是：Agent 调日志接口时没有加时间范围约束，直接查"最近一小时"，结果日志服务返回了空结果，模型误判为"系统正常"，告警被错误归因为网络抖动。

排查路径是这样的：先看 Agent 的工具调用链，发现日志接口确实被调用了；再看接口返回，是空数组；再查模型推理，发现 Prompt 里没有强制要求模型验证返回结果是否合理；最后加了一个后置校验逻辑，要求模型在得出结论前必须确认日志有实际内容。

async def analyze_logs(alert: Alert) -> AnalysisResult: # 第一步：模型决定查询参数 query_params = await agent.decide_query_params(alert) # 第二步：执行查询，带超时和结果校验 logs = await query_logs( service=query_params.service, time_range=query_params.time_range, limit=100, timeout=5.0 ) # 第三步：后置校验，空结果必须触发二次查询或人工介入 if not logs or len(logs) == 0: return AnalysisResult( status="insufficient_data", action="escalate_to_human", reason="日志为空，无法归因" ) # 第四步：模型基于实际日志推理 conclusion = await agent.reason_with_logs(logs, alert) return conclusion

这段代码的关键不是模型推理部分，而是第三步的后置校验。运维经验在这里很有用——你知道什么情况下日志会为空，知道什么时候应该放弃自动分析转人工。这个判断逻辑模型学不会，必须你写进去。

---

告警归因

告警归因是 Agent 最有价值的场景之一，也是最容易翻车的场景。

我们当时遇到的问题是：模型把"数据库连接池耗尽"归因为"应用代码bug"，因为日志里确实有连接超时的报错。但实际上根因是数据库侧的慢查询导致的。

这个错误的根因是：Agent 只看了应用层日志，没看数据库层指标。模型在工具调用时没有主动去查数据库侧的数据，因为 Prompt 里没有明确要求它"跨层归因"。

解决方式是给 Agent 加了一个"归因检查清单"：

ATTRIBUTION_CHECKLIST = [ {"layer": "application", "check": "应用日志是否有异常"}, {"layer": "database", "check": "数据库慢查询和连接池状态"}, {"layer": "network", "check": "网络延迟和丢包率"}, {"layer": "infrastructure", "check": "CPU、内存、磁盘 IO"}, ] async def attribution_workflow(alert: Alert) -> AttributionResult: findings = [] for check in ATTRIBUTION_CHECKLIST: result = await check_layer(alert, check["layer"]) findings.append(result) # 如果当前层已经找到明确根因，可以提前终止 if result.confidence > 0.9: break return AttributionResult(findings=findings)

这里体现的运维思维是：归因不是让模型自由发挥，而是用检查清单约束它的搜索路径。清单由你来设计，基于你对系统架构的理解。模型负责执行和推理，你负责定义边界。

---

自动处置 Agent

自动处置是 Agent 最危险也最有价值的部分。处置对了，MTTR 大幅下降；处置错了，可能引发更大事故。

我们当时设计了一个自动重启服务的 Agent，逻辑是：告警触发→检查服务状态→确认异常→执行重启→验证恢复。Demo 阶段跑得很顺，生产环境却出了问题：模型在"确认异常"这一步判断失误，把一个正常的健康检查超时当成了服务故障，触发了不必要的重启，导致业务中断。

问题的根源在于：模型对"异常"的判断阈值太宽松。Demo 阶段的测试数据都是明确异常，模型没见过边界情况。

解决方案是加了一个双人确认机制，对于高风险操作（重启、扩容、删数据），Agent 必须经过人工审批才能执行：

HIGH_RISK_ACTIONS = {"restart_service", "scale_down", "delete_data"} async def execute_action(action: Action, context: Context) -> ExecutionResult: if action.type in HIGH_RISK_ACTIONS: # 高风险操作必须人工审批 approval = await request_human_approval(action, context) if not approval.approved: return ExecutionResult(status="rejected", reason=approval.reason) # 执行前再次校验上下文 pre_check = await validate_context(context) if not pre_check.passed: return ExecutionResult(status="blocked", reason=pre_check.reason) result = await action.execute() return result

这里的运维经验 again 发挥作用：你知道哪些操作是高风险的，知道审批流程应该怎么设计。模型不懂这些，你必须定义清楚。

---

安全与审批

这是 Demo 到生产最容易被忽视的部分。

我们当时犯的一个错误是：Agent 的 API 调用权限和运维同学的账号权限是同一套，导致模型可以调用一些不该调用的接口。比如一个只读性质的日志分析 Agent，实际却有权执行重启操作。

修复方式是做了权限隔离：Agent 运行在一个独立的 service account 下，权限最小化。只读操作用一个账号，写操作用另一个账号，写操作必须经过审批流程。

# 权限分级配置 PERMISSION_LEVELS = { "readonly": ["query_logs", "get_metrics", "describe_service"], "write": ["restart_service", "scale_up"], "admin": ["delete_data", "modify_config"], } async def check_permission(agent_action: Action, user_context: UserContext) -> bool: required_level = PERMISSION_LEVELS.get(agent_action.type, "readonly") return user_context.permission_level >= required_level

这个设计背后是运维的老习惯：最小权限原则。模型再聪明，也不能给它超出需要的权限。

---