聊《运维转大模型实践笔记 》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要本文概述文章目标、核心观点和实践价值。摘要从 Shell 脚本到 AIOps Agent不只是工具链的升级更是思维范式的重构。本文复盘了将传统自动化平台迁移至 LLM 驱动的 Agent 架构的真实过程重点讨论了在日志归因、决策边界和安全审批上的取舍以及为何“不确定性”是运维工程师最需要适应的新常态。目录运维能力的迁移从确定性到概率性日志分析告别正则地狱告警归因让 LLM 当“初级 SRE”自动处置 Agent最危险的环节安全与审批给 AI 装上刹车总结给转型者的建议---运维能力的迁移从确定性到概率性很多刚接触大模型的运维兄弟第一反应是“这玩意儿能替代我的 Ansible 吗”答案是在标准化操作层面不能在复杂故障诊断层面它能做得比你好但代价是你必须接受“它偶尔会胡说八道”。我所在的团队最近在推进 AIOps 2.0 升级。旧系统是基于规则引擎Rule-based的比如“CPU 90% 且 Load 5重启 Tomcat”。这套逻辑严密但维护成本极高一旦业务逻辑变更就要改脚本。新架构的核心变化在于引入了 LLM 作为“大脑”配合 ReActReasoning Acting框架。我们不再直接写死“如果 A 则 B”而是让 Agent 读取日志、理解上下文然后决定调用哪个 Tool。这里有一个巨大的认知陷阱运维习惯追求 100% 的可复现性而 LLM 本质是概率模型。如果你试图用 Prompt Engineering 去硬磕一个 100% 准确率的自动化脚本你会疯掉。正确的思路是LLM 负责“意图识别”和“初步判断”确定性任务仍由传统脚本兜底。日志分析告别正则地狱以前处理非结构化日志我最头疼的是写 Regex。每次上线新服务日志格式稍微一变监控大盘就报警失效。这次我们将 Prometheus Loki 的查询结果喂给 LLM。关键在于 Context 的构建。import openai def analyze_log_pattern(log_lines: list[str], service_name: str) - str: 让 LLM 从混乱的日志中提取潜在的模式或异常根因 prompt f 你是一个资深 SRE 专家。以下是 {service_name} 最近 10 条 ERROR 级别的日志 {chr(10).join(log_lines)} 请执行以下操作 1. 识别是否有重复出现的错误模式。 2. 如果是已知错误如连接超时简述原因。 3. 如果是未知错误给出可能的排查方向如检查数据库配置、网络策略。 注意只输出分析结论不要生成修复命令除非错误明确指向配置缺失。 response openai.ChatCompletion.create( modelgpt-4o-mini, # 实际生产建议使用更便宜的小模型如 Qwen2.5-7B-Instruct messages[{role: user, content: prompt}], temperature0.1 # 分析类任务温度越低越好 ) return response.choices[0].message.content踩坑经历刚开始我们把整个集群的全量日志都丢进去结果 Token 爆炸且延迟高达几十秒。后来我们做了两层过滤先在本地用向量检索Vector Search召回 Top-K 相关日志再传给 LLM 做语义分析。这不仅省了钱还让响应时间降到了 3 秒以内。告警归因让 LLM 当“初级 SRE”告警风暴是运维的噩梦。以前我们靠关联规则Correlation Rules去合并告警规则越写越多最后自己都看不懂。现在我们让 LLM 充当“第一道防线”。当一组告警触发时Agent 会自动询问“这几个服务之间有没有依赖关系最近的变更是什么”它可以通过调用 Knowledge Graph 接口或读取 Git Commit Log 来获取背景信息然后生成一份Incident Summary。取舍点我们并没有完全信任 LLM 的归因结果。对于 P0 级故障LLM 的输出仅作为参考必须经过人工确认Human-in-the-loop。但对于 P3/P4 级别的噪音告警如果 LLM 判定为“已知噪声”且置信度高于 0.9我们可以直接静默处理。这个阈值是我们花了两周调优出来的太高漏报多太低无效处理多。自动处置 Agent最危险的环节这是整个转型中最敏感的部分。能不能让 Agent 直接执行kubectl delete pod或者iptables -F我的观点是绝对不行至少现阶段不行。我曾见过一个 DemoAgent 根据日志判断“磁盘空间不足”于是它调用了清理脚本。但它没意识到那个脚本同时也清了 Redis 的 RDB 文件导致缓存雪崩。我们目前的架构是Read-Only Agent。Agent 只能执行只读命令如df -h,top,git log。当它发现需要写入或修改配置时它会生成一个Plan推送到 Slack 或钉钉群请求人类工程师审批。只有当某个动作被标记为Safe-Action例如重启一个无状态的非核心服务且经过了两次不同的 Agent 独立判断一致时我们才允许自动执行。这种“保守主义”在运维领域不是缺陷而是美德。安全与审批给 AI 装上刹车既然涉及权限RBAC基于角色的访问控制就必须适配 LLM。我们设计了一个中间层Orchestrator它不直接拥有 K8s 或 DB 的写权限。所有的 Write 操作必须经过Policy Engine的检查。rules: - action: restart_service conditions: - service_tier: non-critical - approval_required: false - max_concurrent_restarts: 5 - action: delete_pod conditions: - always_approval_required: true - approver_role: [sre_lead, dev_owner]此外所有 Agent 的操作日志都会审计存储。如果发现 Agent 频繁尝试访问未授权的 API我们的 WAF 会自动锁定该 Service Account。总结给转型者的建议从运维转向大模型应用开发技术栈的变化是其次最重要的是心态的转变。1.不要试图用 LLM 解决所有问题它能理解自然语言但不擅长精确计算和状态管理。把 LLM 当作一个“懂语法的实习生”把核心逻辑留在代码和脚本里。2.重视 Prompt 的版本管理Prompt 不再是静态文本它是你的业务逻辑代码。使用类似 Git 的方式管理 Prompt 迭代记录每次变更对准确率的影响。3.接受不确定性你的第一个 Agent 版本一定会出错。建立完善的 Monitoring 和 Alerting 机制来监控 Agent 的行为而不是只监控服务器。这条路不好走但当你看到 Agent 帮你从几千条日志中在一分钟内定位到那行关键的 Trace ID 时你会发现之前的正则和脚本维护工作真的可以放下了。目录总结资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。