聊《大模型岗位变了运维工程师该补的还是算法吗》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。最近半年我和不少从传统运维、SRE 转型做 AI 自动化的朋友聊过天。大家最焦虑的不是“怎么调大模型 API”而是“为什么我在本地 Demo 里跑通的神仙 Agent一放到生产环境就乱飞”其实答案很残酷大厂面试或者实际招聘中现在考察的早已不是你会不会写 LangChain 或 LlamaIndex而是你有没有处理过权限隔离、操作审计、可观测性这些脏活累活。很多团队效率没提升甚至因为 Agent 误删库、越权查询导致事故频发根本原因就在于我们太迷恋“自动化脚本”的思维而忽略了 AIOps Agent 作为一个“智能体”必须具备的工程化边界。今天这篇复盘不讲虚的概念直接结合我最近带队搭建的一个“告警自动归因与处置平台”的案例聊聊运维转大模型开发时最容易踩的三个坑以及怎么把 Agent 真正做成生产可用的服务。目录运维能力的迁移从“确定性”到“概率性”的阵痛日志分析不只是 RAG更是结构化提取告警归因用思维链CoT替代暴力搜索自动处置 Agent必须加上“审批人”安全与审批构建可观测的信任链条总结运维能力的迁移从“确定性”到“概率性”的阵痛做传统运维的兄弟都知道Shell 脚本和 Ansible playbook 是确定性的。输入 A必然得到 B。只要逻辑写对就不会出错。但引入大模型后一切变成了概率性问题。LLM 可能会幻觉可能会理解错上下文更可怕的是它可能会“自作聪明”地执行危险操作。我见过一个典型反例某团队为了省事直接把运维人员的 K8s 权限授予给 Agent。结果 Agent 在一次日志分析中因为上下文丢失误判某个 Pod 状态异常直接执行了kubectl delete pod。虽然集群有副本保护没挂但这种“裸奔”式的自动化在生产环境是绝对不允许的。所以运维转大模型第一要务不是学算法而是建立“信任但验证”的工程思维。我们要做的不是让 Agent 代替人去思考而是让 Agent 成为人的增强接口且这个接口必须被严格约束。日志分析不只是 RAG更是结构化提取很多初学者做 Log Analysis习惯直接扔一段日志给 LLM 让它总结。这在 Demo 里没问题但在生产里全是坑。日志是非结构化数据直接喂给 LLM 不仅 Token 消耗巨大而且容易丢失关键的时间序列信息。我们的做法是先通过向量检索Vector Search召回相关日志片段再利用 LLM 进行结构化字段提取最后结合监控指标Metrics做交叉验证。比如当 CPU 飙高时Agent 不会只看日志而是会先查 Prometheus发现是某个 Java 线程死锁然后去 ELK 拉取对应时间段的 Thread Dump 日志再请求 LLM 分析堆栈信息。这里的关键在于工具调用的上下文管理。我们需要在 Agent 的记忆模块中明确记录“当前正在分析哪个服务、哪个实例、哪段时间”防止 LLM 跨实例误读。告警归因用思维链CoT替代暴力搜索告警风暴是运维的噩梦。传统规则引擎很难处理复杂的根因分析。LLM 的优势在于推理但前提是我们要引导它使用正确的推理路径。在项目中我们设计了一个基于 ReActReasoning Acting模式的归因 Agent。它不会直接给出结论而是按照以下逻辑执行1. 观察接收告警信号如数据库连接池耗尽。2. 思考可能的原因有哪些慢查询、连接泄漏、DB 宕机。3. 行动调用相应的工具验证假设。* 如果是慢查询调用 DB 监控工具查看 Top SQL。* 如果是连接泄漏调用应用日志分析工具查看活跃会话。4. 观察评估工具返回的结果。5. 循环或结论直到找到根因或确认需要人工介入。这种结构化的思维链比让 LLM 一次性回答要可靠得多。它能让我们清晰地看到 Agent 每一步的判断依据这也是后续做审计日志的基础。自动处置 Agent必须加上“审批人”这是最敏感的部分。读日志、发邮件提醒这些操作风险可控可以全自动。但涉及修改配置、重启服务、清理数据必须引入人类审批Human-in-the-loop。我们实现了一个“预执行沙箱”机制。Agent 计划好处置方案后先生成一份详细的Action Plan包括执行什么命令影响哪些资源回滚方案是什么预计耗时这份计划会被发送到钉钉/飞书群 值班人员确认。只有收到明确的CONFIRMED指令后真正的执行引擎才会启动。下面是一个简单的 Python 伪代码示例展示如何构建一个带有权限校验的工具调用器import json from typing import Dict, Any class SafeToolExecutor: 安全的工具执行器 核心原则所有写操作必须经过白名单校验和人工审批 def __init__(self, approval_required_tools: list): self.approval_required set(approval_required_tools) def execute(self, tool_name: str, params: Dict[str, Any], user_token: str) - str: # 1. 权限检查用户是否有权限调用此工具 if not self._check_permission(user_token, tool_name): return fError: User {user_token} does not have permission to use {tool_name} # 2. 高危操作拦截是否需要人工审批 if tool_name in self.approval_required: # 在实际工程中这里会异步发送通知并等待回调 # 为了演示假设这里直接返回需要审批的状态 return fPENDING_APPROVAL: Action {tool_name} requires human confirmation. Params: {json.dumps(params)} # 3. 执行操作 try: result self._run_tool(tool_name, params) # 4. 记录日志用于后续审计和调试 self._audit_log(tool_name, params, result, user_token) return json.dumps({status: success, result: result}) except Exception as e: self._audit_log(tool_name, params, None, user_token, errorstr(e)) return fError: {str(e)} def _check_permission(self, token: str, tool: str) - bool: # 简化版实际应从 RBAC 系统获取 return True def _run_tool(self, name: str, params: dict) - Any: # 对接实际的运维工具 SDK pass def _audit_log(self, tool, params, result, user, errorNone): # 写入不可篡改的审计日志存储 pass注意看_check_permission和approval_required这两个逻辑。没有这两层保护Agent 就是个定时炸弹。安全与审批构建可观测的信任链条最后谈谈怎么证明你的 Agent 是靠谱的。很多面试官或技术负责人会问“你怎么保证 Agent 没干坏事”你的回答不能是“我有单元测试”而应该是“我有完整的审计链路。”每一个 Agent 的行动都必须留下不可篡改的记录1. Input用户问了什么当时的系统上下文是什么2. ReasoningAgent 内部的思维链步骤脱敏后是什么3. Action调用了哪个工具传了什么参数4. Output工具返回了什么Agent 最终给用户回了什么这些数据要实时同步到 Grafana 或专门的审计面板。当故障发生时我们可以回溯 Agent 的每一秒决策过程。这不仅是追责更是优化 Agent Prompt 和工具链的依据。总结运维转大模型技术栈的跨度确实大但底层的工程素养是通用的。不要因为看到了 LLM 的潜力就忽视了基础设施的稳固性。对于想转型的同行我的建议是1. 先搞定权限和日志在写任何 Agent 代码前先设计好 RBAC 和审计方案。2. 从小场景切入先从只读的日志分析、智能问答做起再逐步扩展到受控的自动处置。3. 保持敬畏永远不要相信 LLM 的绝对准确性把它当作一个偶尔会犯错的实习生你需要做的是给足指引Prompt、管好手脚Tool Use和盯好结果Review。大模型时代真正的护城河不是模型本身而是将模型嵌入现有 IT 架构、确保其安全可控的那套工程体系。这才是运维工程师转型最大的优势所在。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
七日实战：从内存分配到GC调优)
