运维转大模型：从排查路径看工程价值

关注

原创最新推荐文章于 2026-08-26 15:08:34 发布 249 阅读 AI 写同款· GEO 优化 ›

从运维到创造：AI时代IT人的价值升级当AI将运维从“技术工种”升维为“价值创造引擎”，运维人的角色正在经历从“系统保姆”到“业务合伙人”的质变。2025年的数据揭示了一个清晰的事实：那些主动拥抱AI的运维团队，其创造的商业价值是传统团队的3.7倍。在这个价值重构的时代，运维人的终极使命不是维护系统稳定，而是通过技术赋能创造新的商业可能。正如某智算中心运维总监所言：“我们不再等待问题发生，而是创造问题从未存在的未来。”这或许就是AI时代运维人的最高境界——用技术预见未来，以创造重塑价值。阅读详情

聊《我用运维经验做了次 AI 项目，最先失效的是旧方法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

做 SRE 这五年，我最自豪的不是写过多少复杂的 Ansible Playbook，也不是调优了多少个 Kubernetes 集群，而是养成了一种近乎偏执的习惯：不信任任何黑盒，凡事必有日志，操作必留痕迹。

去年年底，团队决定尝试引入 LLM 构建 AIOps Agent，替代部分重复性的告警处理和故障初步排查。作为技术负责人，我原本信心满满，觉得把 Shell 脚本的逻辑翻译成 Python 再套个 LangChain 就行了。结果上线第一周，系统差点崩了。不是因为模型智商不够，而是因为权限失控和日志缺失导致的不可控行为。

这篇文章不谈虚的，只复盘这次从“脚本小子”到“Agent 架构师”的转型过程。如果你也是运维背景，想转做大模型应用开发，希望我的这些坑能帮你省掉几个通宵。

运维思维的迁移：从确定性到概率性

文章插图 1

很多运维兄弟转行 AI，最大的障碍不是学不会 Python 或 PyTorch，而是思维模式的冲突。

在传统运维中，我们追求的是确定性。输入 $A$，经过脚本处理，必然得到输出 $B$。如果没得到 $B$，那就是 Bug，必须修。代码逻辑是严丝合缝的，变量类型是明确的。

但在大模型应用中，我们面对的是概率性。同样的 Prompt，不同的温度设置（Temperature），甚至不同的时间戳，LLM 给出的响应可能截然不同。它不是在执行代码，而是在进行高维空间的向量匹配和语义推理。

我刚开始做 Demo 时，犯了一个典型错误：试图用正则表达式去校验 LLM 的输出结构。结果发现，只要模型稍微“发散”一点，正则就挂了。后来我意识到，对于 LLM 的输出，我们应该像对待 API 接口一样对待它——契约大于实现。我们要定义的是输入输出的 Schema，而不是强行控制模型的每一个字。

日志分析：让沉默的数据开口说话

文章插图 2

在运维时代，Log 是我们的上帝。但在 AIOps 场景下，Log 不仅是查询对象，更是 Agent 的“记忆”和“上下文”。

传统做法 vs Agent 做法

传统做法是写 SQL 或 grep 命令去查日志。Agent 的做法应该是：
1. 结构化日志入库：确保日志格式规范（JSON），并建立向量索引。
2. 语义检索：通过 Embedding 模型将用户的问题转化为向量，在日志库中进行相似度搜索。
3. 上下文组装：将相关的日志片段作为 Context 喂给 LLM。

这里有一个具体的踩坑案例。我们的监控平台存储了海量的 Nginx Access Log。起初，我们直接把这些文本扔进 Vector DB，结果检索出的相关日志全是“200 OK”，对排查问题毫无帮助。

教训：不要把所有日志都向量化。应该先通过规则引擎过滤出 ERROR/WARN 级别的日志，或者提取关键字段（如 statuscode, responsetime, error_message）作为元数据过滤条件，再进行向量检索。


# 伪代码示例：如何构建更有效的日志检索链
def retrieve_logs(query: str, time_range: dict):
    # 1. 先做元数据过滤，缩小范围
    meta_filter = {
        "level": ["ERROR", "CRITICAL"],
        "timestamp": {"$gte": time_range["start"], "$lte": time_range["end"]}
    }

    # 2. 获取候选文档
    candidate_docs = log_store.search_metadata(meta_filter)

    # 3. 对候选文档进行语义排序（重排）
    query_vector = embed_model.encode(query)
    ranked_docs = rerank_model.score(query, candidate_docs)

    return ranked_docs[:5]  # 只取前5条最相关的，节省 Token

优快云资料领取方式

告警归因：从“是什么”到“为什么”

运维告警的核心痛点是告警风暴。一个数据库主节点宕机，可能引发下游 50 个微服务的超时告警。传统规则引擎很难理清这种因果关系，而 LLM 擅长讲故事，也擅长梳理因果。

我设计了一个简单的归因 Agent 流程：
1. 聚合：接收一组相关告警。
2. 提取特征：从告警信息中提取时间、服务名、错误码。
3. LLM 分析：将这些特征拼凑成 Prompt，询问 LLM：“这些告警之间可能存在什么因果关系？”

关键取舍：不要指望 LLM 能直接给出 100% 准确的根因。它的价值在于假设生成。LLM 可能会说“可能是 Redis 缓存击穿导致 DB 压力激增”，这是一个非常合理的假设。运维人员只需要验证这个假设即可，而不是完全依赖 LLM 的结论。

在实际项目中，我们发现 LLM 对于跨服务调用的链路追踪并不敏感。因此，我们引入了 OpenTelemetry 的 Trace ID，将其作为关键上下文传入 Prompt。这样，LLM 就能结合 Trace 链路信息，给出更有依据的推断。

自动处置 Agent：权限是最大的拦路虎

这是我最想强调的部分，也是本次转型中失败教训最多的地方。

危险的想法

最初，我们想让 Agent 自动重启故障容器。想法很简单：检测到 Pod CrashLoopBackOff -> 调用 K8s API 删除 Pod -> Kubelet 重建 Pod。

现实的毒打

第一次测试时，Agent 在一个生产环境的测试集群里“自作主张”地重启了 20 个非核心 Pod，原因是它认为这些 Pod 的内存使用率“看起来有点高”。虽然最终没有造成生产事故，但运维团队的信任度瞬间降至冰点。

核心原则：
1. 读写分离：Agent 可以拥有读取监控、查询日志的权限，但执行变更操作的权限必须严格受限。
2. 审批流嵌入：任何写入操作（Write/Update/Delete）必须经过人工确认环节，除非是极高风险等级的自动化回滚。
3. 沙箱先行：所有自动处置动作先在 Staging 环境演练，通过后才能逐步放开 Production 权限。

我们最终采用的架构是 “Agent 建议 + 人工确认 + 脚本执行” 的模式。Agent 负责分析并生成执行计划（Plan），人类工程师点击“批准”后，再由一个独立的、权限受限的执行器（Executor）去运行脚本。这样既保留了 Agent 的智能分析能力，又锁死了权限风险。

安全与审批：构建可信的 AI 边界

在做 AIOps 时，安全性不仅仅是网络安全，更是业务逻辑安全。

1. Prompt 注入防护：日志内容可能包含恶意构造的字符串，试图诱导 LLM 泄露系统配置。我们必须对输入日志进行清洗，或者使用专门的安全模型对 Prompt 进行前置过滤。
2. 操作审计日志：Agent 做的每一个决策、调用的每一个 API、生成的每一条回复，都必须记录在独立的审计日志中。这部分日志不能被 LLM 访问，只能由管理员查看。这是事后追溯的根本。