运维转大模型：用一次交付过程做复盘

原创于 2026-08-02 13:26:46 发布 · 263 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

聊《同样转大模型，运维背景的优势和短板分别是什么？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周需求评审，产品经理抛出一个需求：“做个能自动处理告警的 Agent。”我差点脱口而出：先聊聊权限和日志。

这不是刁难，是血泪教训。去年我们团队花三个月搭了一套告警归因 Agent，Demo 演示效果惊艳——日志一扔，根因秒出，还能自动重启服务。结果上线第一周，Agent 把生产库的测试表删了，因为它的“自动处置”权限配置错了，而日志里只有一行 INFO: action completed。

运维转大模型，最大的优势不是会写 Prompt，而是知道什么不能交给模型。今天这篇复盘，不聊多炫的架构，只讲我们从 Demo 到生产踩过的坑，以及一套让 Agent 能真正接手的验收清单。

运维能力的迁移：脚本思维 vs Agent 思维

文章插图 1

很多运维同学转型时，习惯用“自动化脚本”的思路做 Agent。脚本是确定性的：输入 A 必然得到 B。但 Agent 面对的是大模型的不确定性，同样的日志，今天归因到数据库，明天可能归因到网络。

我的取舍标准很简单：凡是能写脚本解决的，绝不交给 Agent。比如重启某个无状态服务，脚本 3 行搞定，准确率 100%，为什么要让 Agent 去“理解”再执行？

真正适合 Agent 的场景，是需要跨系统关联、语义理解、动态决策的任务。比如：

10 个告警同时触发，判断是否同一个根因
日志格式不统一，需要自然语言描述问题
处置方案需要参考历史工单、变更公告、监控指标

转型的第一步，先把你现有的自动化脚本列出来，用这张表筛一遍：

| 任务类型 | 推荐方案 | 理由 |
|---------|---------|------|
| 确定性操作（重启、扩容） | 保留脚本 | 可预测、可回滚、无需 LLM |
| 日志解析（结构化字段） | 正则/解析器 | 稳定、成本低 |
| 异常模式识别 | Agent + 规则兜底 | 需语义理解，但结果需验证 |
| 根因推断（跨系统） | Agent 主导 | 需要关联分析能力 |

我们团队踩过的坑：把“查询数据库连接数”这种简单任务也塞给 Agent，结果它偶尔返回错误格式，导致下游解析失败。后来改为：Agent 只负责生成查询语句，执行和结果校验仍由脚本完成。

日志分析：从 grep 到 LLM，边界在哪里

文章插图 2

以前分析日志，我们依赖 grep + awk + 自定义脚本。现在 LLM 能直接理解非结构化日志，但代价是不确定性。

我的实战建议：永远不要信任 LLM 的单次输出。我们现在的流程是：
1. LLM 生成初步分析
2. 用规则引擎校验关键字段（比如时间戳格式、错误码范围）
3. 对低置信度结果，回退到传统解析


# 示例：带校验的日志分析
def analyze_log(llm_response: dict, raw_log: str) -> dict:
    # 基础校验：必须包含 error_code 和 timestamp
    if not all(k in llm_response for k in ["error_code", "timestamp"]):
        return fallback_to_regex(raw_log)  # 回退到正则解析

    # 置信度低于阈值时，标记为人工审核
    if llm_response.get("confidence", 1.0) < 0.8:
        llm_response["review_required"] = True

    return llm_response

另一个关键点是日志脱敏。运维日志里经常有 IP、用户 ID、接口参数，直接扔给公有云 LLM 有风险。我们做法是：先在本地用规则替换敏感字段，再发送。这部分代码必须审计，不能依赖模型“自动脱敏”。

CSDN资料领取方式

告警归因：关联分析 vs 单点判断

告警归因是 Agent 最能发挥价值的场景之一。以前我们用规则：如果 A 告警 5 分钟内出现 B 告警，则关联。但规则维护成本高，且无法处理复杂场景。

Agent 的优势在于能理解“语义关联”。比如日志里有 connection pool exhausted 和 response timeout，脚本可能认为无关，但 Agent 能推断出前者导致后者。

但这里有个陷阱：模型会过度关联。有一次，Agent 把“磁盘使用率高”和“支付接口慢”关联起来，因为日志里都出现过 slow 关键词。实际上两者毫无关系。

我们的解决方式是引入因果约束：

时间窗口限制（比如 30 分钟内）
系统依赖关系预定义（数据库告警不会归因到前端）
历史归因结果作为负样本反馈

验收标准很简单：让 Agent 处理过去一个月的告警记录，人工抽检 10% 的归因结果，准确率必须＞90%，否则不上线。

自动处置 Agent：权限是生死线

Demo 里 Agent 能自动重启服务、清理日志、扩容实例，看着很爽。但生产环境，权限配置错误就是事故。

我们总结了一套权限分级：

P0（禁止）：删除数据、修改配置、跨机房操作
P1（需审批）：重启服务、扩容、清空缓存
P2（可自动）：查询状态、收集日志、发送通知

Agent 只能执行 P2，P1 必须经过人工审批。审批流程不是走个形式，而是双人确认：一个运维同学审核，另一个 SRE 复核。

技术实现上，我们用了策略引擎（OPA）做权限校验。Agent 每次调用工具前，都会先请求策略服务，返回 allow/deny/review。这段逻辑必须独立于 Agent 本身，不能由模型决定。


# OPA 策略示例
allow(action, resource) {
  input.user.role == "agent"
  input.action == "query"
  input.resource.type == "log"
}

allow(action, resource) {
  input.user.role == "agent"
  input.action == "restart"
  input.resource.type == "service"
  input.resource.name == "cache-service"
  input.context.approved == true  # 需要审批上下文
}