运维转大模型：脚本经验够用，权限和日志把我打回原形

关注

原创最新推荐文章于 2026-10-04 16:27:12 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

2026年Linux运维/SRE学习路线：从零基础到云原生与AIOps实战如果你在2026年还在用2018年的方法学Linux运维，那你可能已经落后了整整一个技术代际。这不是危言耸听。过去几年，运维领域经历了从“手工救火”到“平台工程”，再到如今“AI驱动”的深刻变革。传统的“命令大全”式学习路径，面对云原生、可观测性、SRE工程实践和AIOps的复合要求，显得越来越力不从心。很多想转行或提升的工程师，投入大量时间学了一堆命令和脚本，却发现面试时被问的都是“如何设计一个高可用的告警收敛策略”或“如何用IaC管理千台服务器”，瞬间被打回原形。问题的核心在于：学习资源的时效性与阅读详情

聊《运维转大模型实战，第一道门槛可能不是算法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

从传统自动化脚本到 AIOps Agent，技术栈的转变不只是换个框架。很多运维兄弟一开始自信满满，觉得 Ansible、Terraform 的经验能直接平移，结果项目刚进生产环境就崩在权限管理和日志可观测上。这篇文章复盘我带团队做 AIOps Agent 的全过程，不聊概念，只讲踩过的坑、排过的错，以及最后真正能用起来的方案。适合想从运维转向 AI 自动化的工程师参考。

---

运维能力的迁移

文章插图 1

先说结论：运维的核心能力是在不确定性中建立确定性。这个能力在大模型时代反而更值钱了，只是表达形式变了。

以前你写 Shell 脚本处理故障，现在你用 Agent 来处理。底层逻辑没变——识别状态、判断路径、执行动作、验证结果。变的只是工具。

我最早做运维自动化时，用的是 Ansible Playbook。每个任务都有明确的前置条件、执行步骤和回滚方案。转到 Agent 项目时，我发现 LangChain 里的"ReAct 循环"和 Playbook 的执行逻辑惊人地相似：Thought → Action → Observation → Thought → Action → ... 直到得到最终答案。

但问题出在边界条件。

Ansible 执行失败会直接报错退出，Agent 遇到异常可能继续"一本正经地胡说八道"。我第一次做日志分析 Agent 时，模型在找不到关键词时会自动编造一个"相关日志"，直接把运维同学带进了沟里。这不是算法问题，是工程化问题。

所以我的建议是：别急着学 Prompt Engineering，先把运维里那些"兜底逻辑"的思维模式保留下来。Agent 的输出必须可验证，这一点比任何技巧都重要。

---

日志分析：从 grep 到语义检索

文章插图 2

真实案例

我们有一个订单系统的日志，每天大约 2GB，分散在 5 台 Kubernetes Pod 里。原来的流程是告警触发后，值班同学手动 kubectl logs grep 关键字，平均定位时间 15 分钟。

接入 RAG 后的 Agent 输入是一个自然语言问题："昨天下午订单支付超时率上升，可能的原因是什么？"

步骤拆解：

1. 模型解析问题，提取关键实体：时间范围（昨天下午）、指标（支付超时率）
2. 调用日志检索工具，生成 Kubernetes Log Query
3. 获取日志片段，进行语义摘要
4. 输出结构化分析报告

实际测试中，Agent 在 90% 的场景下能在 30 秒内给出有效分析，平均定位时间从 15 分钟降到 2 分钟。但剩下的 10% 翻车得很离谱。

排查过程

有一次 Agent 报告"发现数据库连接池满的日志"，我让值班同学去核实，结果日志里没有相关内容。排查链路如下：

现象：模型输出了不存在的错误日志。

验证动作 1：检查原始日志查询的返回结果。发现 Agent 确实执行了正确的查询，但返回的日志片段被截断了，上下文丢失。

验证动作 2：检查 Prompt 中的约束条件。发现"如果日志中没有明确信息，请基于已有信息推断"这句话导致了模型的幻觉。

验证动作 3：修改约束，改为"如果日志中没有明确信息，请在报告中明确说明'无直接证据'"。再次测试，幻觉消失，但可用性也下降了——有时候模型确实需要做一些合理推断。

排除结果：这不是模型能力问题，是约束设计问题。需要在"避免幻觉"和"保持有用性"之间找到平衡点。

代码解释

以下是我们最终使用的日志查询工具的伪代码，解释一下关键逻辑：

async def query_logs(query: str, time_range: dict) -> List[str]:
    """
    输入:
        query: 用户自然语言问题
        time_range: 时间范围 {"start": "2026-09-01T14:00:00Z", "end": "2026-09-01T16:00:00Z"}

    核心逻辑:
        1. 用 embedding 模型将自然语言转为向量
        2. 在日志向量库中做相似度检索
        3. 对 Top-K 结果进行关键词过滤，确保语义相关且包含关键实体

    输出:
        结构化日志列表，每条包含 pod_name, timestamp, log_content
    """

    # 步骤 1: 语义检索
    query_vector = await embed_text(query)
    raw_results = await vector_db.search(
        vector=query_vector,
        top_k=50,
        filter={"time_range": time_range}
    )

    # 步骤 2: 关键词过滤
    entities = await extract_entities(query)  # 提取时间、服务名、错误类型等
    filtered = []
    for doc in raw_results:
        if any(e in doc["log_content"] for e in entities):
            filtered.append(doc)

    # 步骤 3: 结果限制
    return filtered[:10]  # 最多返回 10 条，防止上下文溢出

关键点：步骤 2 的关键词过滤是防幻觉的第一道防线。纯语义检索会返回"看起来相关"但实际不相关的日志，加上实体过滤后准确率从 72% 提升到 94%。

---

优快云资料领取方式

告警归因：模型会幻觉，但你不能

告警归因是 Agent 最容易出彩也最容易翻车的场景。

我们的监控体系有 Zabbix、Prometheus、SkyWalking 三个数据源，告警每天超过 200 条。以前靠值班同学经验判断关联关系，现在想让 Agent 做初步归因。

第一次上线的直接后果：

Agent 把三条完全无关的告警关联在了一起——数据库慢查询、磁盘 IO 高、网关超时。理由是"它们发生在同一时间段"。值班同学信了，排查了半小时，最后发现磁盘 IO 高是因为备份任务，和数据库没关系。

复盘后的改进：

1. 加因果推断层：不只看时间相关性，还要验证"如果 A 恢复，B 是否随之恢复"
2. 置信度阈值：模型输出归因结果时必须带上置信度，低于 80% 的自动标记为"人工复核"
3. 人工反馈闭环：值班同学的确认或修正会存入训练集，用于后续微调

失败原因

这里区分三类常见失败：

业务错误：模型理解错了告警语义。比如把"连接池满"理解为"连接数多"，而不是"请求阻塞"。解决方案：在 Prompt 中加入领域术语表。
配置错误：RAG 的检索范围设置错误，导致漏掉了关键日志。解决方案：建立检索范围的白名单机制。
环境错误：向量数据库查询超时，返回了空结果，模型被迫"脑补"。解决方案：设置超时熔断，空结果直接返回"无法获取数据"而不是继续推理。

---

自动处置 Agent：工具调用比想象中复杂

这是最核心的部分，也是大多数团队卡住的地方。

工具调用的陷阱

很多人以为 Agent 的工具调用就是"模型决定调用哪个工具、传什么参数"。实际生产环境中，你需要解决三个问题：

1. 工具权限隔离：Agent 能不能直接执行 kubectl delete pod？肯定不能。
2. 调用顺序依赖：先查询再处置，还是先保存状态再执行？
3. 回滚机制：执行失败了怎么恢复？

我们的方案是用 LangGraph 构建有状态的工作流，每个节点都是独立的可观测单元。

代码解释

from langgraph.graph import StateGraph, START, END

class IncidentState(TypedDict):
    alert_id: str
    root_cause: str
    action_taken: str
    rollback_needed: bool
    approval_status: str  # pending / approved / rejected

# 定义工作流节点
workflow = StateGraph(IncidentState)

# 节点 1: 根因分析（只读）
workflow.add_node("analyze", analyze_root_cause)

# 节点 2: 制定处置方案（只读）
workflow.add_node("plan", create_action_plan)

# 节点 3: 审批检查（权限控制点）
workflow.add_node("approve", check_approval)

# 节点 4: 执行处置（可写操作）
workflow.add_node("execute", execute_action)

# 节点 5: 验证结果
workflow.add_node("verify", verify_result)

# 定义边
workflow.add_edge(START, "analyze")
workflow.add_edge("analyze", "plan")
workflow.add_edge("plan", "approve")

# 条件边：审批通过才执行
workflow.add_conditional_edges(
    "approve",
    lambda state: state["approval_status"],
    {
        "approved": "execute",
        "rejected": END,
        "pending": "execute"  # 低风险操作可自动通过
    }
)

workflow.add_edge("execute", "verify")
workflow.add_edge("verify", END)

这段代码的关键设计：审批节点是强制插入的权限控制点。模型不能绕过它直接执行写操作。这是 Demo 和生产环境最大的区别——Demo 里你可以让模型"自动执行所有操作"，但生产环境必须有人工或规则在中间拦截。

---

安全与审批：Demo 能跑不代表能上线

这部分是我踩坑最深的地方。

权限设计的三个层次

1. 读取权限：Agent 可以访问哪些日志、监控数据？按服务名做隔离，每个 Agent 只能访问自己负责的域。
2. 执行权限：Agent 可以执行哪些操作？把操作按风险分级，P0（如重启核心服务）必须人工审批，P3（如查询指标）可以自动执行。
3. 审计权限：所有操作必须有日志，包括"模型决定做什么"和"最终执行了什么"。