运维转大模型：把复杂问题拆小验证

IT职业领路人

315人浏览 · 2026-07-09 10:49:34

IT职业领路人 · 2026-07-09 10:49:34 发布

如果你正准备往大模型方向转，《运维转大模型：一次新的项目切入》这类问题别只看热度。更重要的是判断自己该补哪块能力，以及怎么证明你真的会。

摘要

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

最近圈子里有个很明显的趋势：大模型应用正在从“炫技”的 Demo 阶段，迅速向“可观测、可审计、有权限控制”的工程化阶段过渡。对于运维和 SRE 同学来说，这其实是一个巨大的信号。

以前我们觉得运维就是写 Shell、搞 K8s YAML、配 Prometheus 告警。现在呢？AIOps Agent 成了新宠。但很多同行一上来就盯着 LangChain、LlamaIndex 这些框架学，最后做出来的东西要么无法维护，要么在测试环境跑通，一到生产环境就炸。

我的观点很直接：别把大模型当成魔法，把它当成一个“不靠谱但知识渊博的 junior engineer”。你的任务不是教它编程，而是通过工程手段，给它戴上镣铐，让它在你的监控和审批体系下干活。

这次复盘，我不讲怎么搭环境，只讲怎么把一个能跑的 Demo，变成一个能进 CI/CD 的 AIOps 组件。重点聊聊权限、日志和可观测性——这三个才是面试官问你“项目难点”时的得分点。

运维能力的迁移：从“确定性”到“概率性”

文章插图 1

传统运维追求确定性：脚本 A 执行完，状态一定是 B。
大模型 Agent 追求概率性：Prompt 一样，每次回答可能不同。

这种差异导致了一个核心矛盾：如何让不确定的输出，产生确定的副作用？

在运维场景中，Agent 通常扮演“意图识别”和“初步诊断”的角色。比如，收到一条 CPU 飙升的告警，传统做法是查 Top 进程；Agent 的做法是先看日志，再判断是否需要重启服务。

这里有个常见的误区：很多人试图让 Agent 直接执行 kubectl delete pod。这是大忌。
正确的迁移思路是：
1. 读（Read）：Agent 可以随意读取 Prometheus、ELK 数据。这是信息增强，风险极低。
2. 写（Write）：Agent 生成“修复建议”或“执行计划”，由人类或上游系统审批后执行。
3. 控（Control）：所有操作必须经过审批流（Approval Gate）。

我在之前的项目中，故意把 Agent 的权限限制在“只读”和“生成计划”，而不是“直接执行”。这不仅是为了安全，更是为了积累调试数据。如果你让 Agent 直接改配置，一旦它胡言乱语删库了，你连回放都做不到。

日志分析：别只靠 Prompt，要靠结构化数据

文章插图 2

很多初学者问：“怎么让 LLM 分析日志？”
答案是：不要直接把几千行杂乱无章的日志扔给 LLM。既贵又慢，还容易幻觉。

运维同学的优势在于对数据结构敏感。我们应该利用现有的 Log Service 或 ELK，先做一层“预处理”。

比如，针对 Nginx 访问日志，我们不应该让 LLM 去理解 HTTP 状态码的含义，而是先用 Python 脚本提取关键字段：status_code, latency_ms, uri, error_message，然后只把这些聚合后的指标发给 LLM。

下面是一个简单的 Demo，展示如何构建一个“日志意图识别”的 Agent 输入层。注意，这里的 log_summary 是我们预处理后的结果，而不是原始日志。

import json
from typing import List, Dict

class LogPreprocessor:
    """
    预处理日志，只提取 LLM 需要的关键特征
    避免将大量无关文本喂给模型，节省 Token 并减少噪音
    """
    def extract_features(self, raw_logs: List[str]) -> Dict:
        # 模拟从 ELK 查询到的最近 5 条异常日志
        # 在实际生产中，这里应该是 Pandas 处理或 SQL 聚合

        stats = {
            "error_count": len(raw_logs),
            "latest_error_type": None,
            "avg_latency_window": [],
            "affected_services": set()
        }

        for log in raw_logs:
            try:
                # 假设日志是 JSON 格式
                entry = json.loads(log)
                if entry.get("level") == "ERROR":
                    stats["latest_error_type"] = entry.get("msg", "unknown")

                # 提取受影响的 service 名称
                svc = entry.get("service_name")
                if svc:
                    stats["affected_services"].add(svc)

                # 记录延迟区间
                lat = entry.get("latency_ms")
                if lat:
                    stats["avg_latency_window"].append(lat)
            except json.JSONDecodeError:
                continue

        stats["affected_services"] = list(stats["affected_services"])
        return stats

# 示例用法
preprocessor = LogPreprocessor()
raw_logs = [
    '{"service": "auth", "level": "ERROR", "msg": "DB Timeout", "latency_ms": 5000}',
    '{"service": "order", "level": "INFO", "msg": "OK", "latency_ms": 100}'
]
features = preprocessor.extract_features(raw_logs)
print(json.dumps(features, indent=2))

这段代码的价值不在于复杂，而在于隔离。LLM 看到的不再是垃圾文本，而是结构化的“症状”。这样，你在 Prompt 里只需要说：“根据以下症状，推测根因”，准确率会大幅提升。

CSDN资料领取方式

告警归因：Agent 是“分析师”而非“救火队员”

在告警场景下，Agent 的核心价值是降噪和根因定位。

传统的告警风暴里，一个数据库连接池满，可能会引发下游 50 个微服务的超时告警。运维老手一眼就能看出这是源头问题，但新手可能会逐一排查。

我们要做的，是让 Agent 学习这种“拓扑思维”。

我的取舍建议：
1. 不要指望 LLM 实时计算因果图。它的推理速度太慢，且容易出错。
2. 利用向量数据库做语义匹配。将历史工单（Ticket）和故障复盘报告（Post-mortem）存入向量库。当新告警发生时，检索最相似的 3 个历史案例，让 LLM 基于这些案例进行类比推理。

例如，Prompt 可以这样设计：
> “当前告警：API Gateway 响应时间 P99 > 2s。
> 相似历史案例：
> 1. 2023-10-01：Redis 集群脑裂导致缓存穿透。
> 2. 2023-11-15：数据库慢查询锁表。
>
> 请结合当前监控指标（CPU 正常，DB 连接数激增），判断最可能的根因，并给出验证命令。”

这种做法，既利用了 LLM 的自然语言理解能力，又限制了它的发挥范围在“已知历史模式”内，大大降低了幻觉风险。

自动处置 Agent：审批流是底线

到了这一步，很多热情高涨的同学想直接让 Agent 执行 restart service。
停。

在企业级应用中，“可撤销”比“快速恢复”更重要。

我推荐的设计模式是：Propose -> Human-in-the-loop -> Execute。

1. Propose：Agent 分析完告警后，生成一个 ExecutionPlan（执行计划），包括要执行的命令、预期的回滚步骤、影响范围。
2. Review：这个计划发送到 Slack/钉钉/飞书，或者写入 Jira。运维人员点击“Approve”或“Reject”。
3. Execute：只有收到 Approval 信号，后端 Job Runner 才会真正去执行命令。

这里有一个具体的代码片段，展示如何定义这个“安全护栏”：

import enum
from dataclasses import dataclass

class ActionStatus(enum.Enum):
    PENDING = "pending"
    APPROVED = "approved"
    REJECTED = "rejected"
    EXECUTED = "executed"

@dataclass
class RemediationAction:
    action_id: str
    command: str
    rollback_command: str
    risk_level: str  # LOW, MEDIUM, HIGH
    status: ActionStatus = ActionStatus.PENDING

    def execute_if_approved(self):
        if self.status != ActionStatus.APPROVED:
            raise PermissionError(f"Action {self.action_id} has not been approved.")

        # 这里调用实际的 K8s API 或 SSH
        print(f"Executing: {self.command}")
        self.status = ActionStatus.EXECUTED
        return True

你看，把权限控制逻辑显式化，这就是运维工程素养在大模型时代的体现。你不需要懂复杂的 Transformer 原理，但你懂状态机和权限校验。这才是你的核心竞争力。

安全与审批：给 AI 装上监控摄像头

最后，谈谈可观测性。

既然 Agent 会执行操作，我们就必须知道它做了什么、为什么这么做、效果如何。

1. 全链路追踪：每个 Agent 的思考过程（Reasoning Trace）和最终决策，必须记录在案。建议使用 OpenTelemetry，将 LLM 的输入输出作为 Span 记录下来。
2. 权限最小化：Agent 运行的 Service Account 应该只有执行特定命令的权限，而不是 Root 权限。
3. 反馈闭环：如果 Agent 推荐的方案失败了，这个结果必须反馈给向量库，作为负面样本，优化后续的检索策略。

很多团队忽略了第 3 点。他们没有评估机制，不知道 Agent 到底帮了多少忙，还是制造了多少麻烦。没有评估，就没有优化；没有优化，就是纯成本中心。