AI Ops 不仅仅是平台工程：运行 LLM 服务如何颠覆你的 SRE 策略手册

你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。

这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。

新的部署单元：Prompt 加模型，而非代码

在微服务世界中，部署的原子单位是容器镜像。镜像编码了所有行为，通过摘要进行版本控制，更换版本是机械化的。行为变更意味着代码变更，这又意味着经过审查的 PR，以及可测试的 diff。

LLM 服务从三个方面打破了这一模型。

Prompt 是存在于代码之外的行为。 系统提示词（System Prompt）的一个词变动，就可能将结构化 JSON 输出变为散文，削弱安全过滤，或导致模型误解下游 API 的响应。Prompt 的变化频率通常比应用程序代码快——在活跃开发期间，有时一天会变动多次。但它们通常没有得到应用于代码的测试规范：没有 diff 审查，没有集成测试套件，也没有金丝雀验证。结果是，Prompt 变更成了 LLM 应用中生产故障的主要驱动因素，但它们往往绕过了那些本可以捕获等效代码变更的控制措施。

模型更新来自部署流水线之外。 当你的云服务商默默升级你正在调用的模型端点时，你的应用程序代码并没有改变。你的容器没有重新部署，你的 CI 也没有运行。但行为可能已经发生了偏移——输出的冗长度、格式规范、拒绝阈值、推理模式。研究记录显示，即使在零温（Temperature 0）下，同一模型的相同运行在准确率上也有高达 15% 的波动。当供应商轮换模型权重时，你可能直到下游解析失败显现时才会察觉。

配置是第三个行为维度。 Temperature、max tokens、top-p 采样、停止序列、工具选择行为——这些都是影响输出语义而非仅仅是性能的运维调节杆。它们通常设置在环境变量或配置文件中，不经过与应用程序代码相同的变更管理，从而产生了一类标准监控几乎无法察觉的行为变更。

运维层面的启示：部署回滚不再是一个简单的操作。当出现问题时，你需要独立询问：是 Prompt 变了，模型变了，还是配置变了？

SRE 运维手册从未设计过的故障模式

经典的微服务故障是可见的。500 错误会在链路（Trace）中生成一个 span。超时会增加计数。队列堆积、内存攀升、磁盘填满。这些故障产生的信号能够清晰地映射到告警阈值和运维手册步骤。

LLM 故障通常在语义上是沉默的。服务返回 200。Token 使用量看起来正常。延迟在范围内。模型只是产生了一些微妙且自信的错误。

语义故障不产生错误信号。 对 LLM 生成输出的研究发现，超过一半的错误结果在语法上是有效的——代码可以编译，JSON 可以解析，响应遵循模式。系统执行正确，但它解决的是错误的问题。这产生了一类传统告警永远不会触发的故障。检测需要依赖下游故障（这往往比根因滞后数小时），或者需要构建专门的评估监控，对实时流量样本进行输出质量检查。

非确定性使标准金丝雀指标失效。 在传统服务的金丝雀发布中，你会比较基准版本和金丝雀版本之间的错误率、p99 延迟和一些关键业务指标。如果它们在统计上是等效的，你就会发布。这假设了相同的输入产生等效的输出。而根据定义，LLM 的输出是多变的。两个具有相同输入的请求在结构、语气或正确性上可能有所不同。除非你将语义评估作为与错误率并列的一等公民指标，否则传统指标的标准双样本统计检验将无法捕获输出质量的退化。

成本是一类故障，而不仅仅是预算问题。 当 Agent 进入非预期的循环，或者一个边界模糊的检索步骤提取了过多的上下文时，Token 消耗可能会呈指数级增长，而不会触发任何服务级告警。对生产环境 LLM 部署的分析发现，Agent 成本失控是一类正在困扰缺乏预算护栏的团队的活跃故障类别。与 CPU 饱和（会降低性能并产生自我限制）不同，不受限的 Token 使用可能在几分钟内产生五位数的费用，而没有明显的业务影响，直到账单寄达或触发供应商的频率限制。

速率限制级联的行为不同于服务过载。 2026 年初的数据显示，生产环境中 60% 的 LLM 调用错误是由速率限制耗尽引起的，而不是服务故障。LLM API 的速率限制是基于 Token 而非请求的，这意味着来自单个冗长 Prompt 的爆发流量可能比数百个简短请求消耗更多的配额。统计 HTTP 429 错误的传统熔断器响应太慢；有效的速率限制管理需要在所有并发请求中主动跟踪 Token 预算，而不是被动地监控响应代码。

从经典 SRE 中继承了什么

并非所有内容都需要重构。若干 SRE 基本原理可以直接应用，只需在指标层面进行调整。

SLO 方法论可以沿用。 错误预算 (Error budgets)、消耗率 (burn rates) 以及在功能发布前编写 SLO 的实践依然适用。变化的是 SLO 的覆盖面：你不仅要追踪可用性和延迟，还要追踪准确性（通过采样和评估来衡量）、单次请求成本以及幻觉率 (hallucination rate)。自适应 SLO 阈值——即根据任务类型或用户层级调整可接受的质量底线——是消耗率模型的自然延伸。

值班机制和复盘文化可以沿用。 故障所有权、升级路径、无责复盘以及“五个为什么” (five-whys) 流程依然具有价值。复盘模板需要增加新的字段：哪个组件发生了变化（提示词、模型、配置）、是什么让故障在标准监控下隐形，以及什么样的评估 (eval) 或行为信号能更早地发现它。

灰度发布 (Canary deployment) 逻辑可以沿用。 在全量上线前将一小部分流量导向新版本的原则直接适用。但实现方式有所不同：LLM 服务的灰度流量还应运行影子评估 (shadow evaluation)（异步对比输出与基准线），并且在会话内保持一致的用户路由至关重要，因为在对话中途混合使用模型版本会导致上下文不连贯。

运维手册 (Runbook) 的结构可以沿用，但步骤会改变。 运维手册的格式——触发条件、诊断步骤、缓解措施、升级路径——是可以转化的。只是针对上述每个故障类别，其具体内容各不相同。

需要重构的三大 SRE 领域

测试。 确定性系统的回归测试假设相同的输入产生相同的输出；失败是明确无误的。LLM 回归测试则需要评估套件 (eval suites)，用于衡量与参考输出的语义相似度、验证输出格式的正确性、检查对安全策略的遵循情况，并标记提示词或模型版本之间有意义的行为偏移 (behavioral drift)。这些评估套件必须足够快，以便在 CI 中运行，同时也必须足够全面，以捕获那些不会表现为格式错误的回归问题。大多数团队在首次发布 LLM 功能时根本没有这些套件，这意味着前几次故障往往是他们第一次意识到该测试什么。

故障诊断。 当微服务出现异常时，你会调取链路追踪 (traces)，将错误峰值与部署时间戳关联，并二分定位到代码更改。当 LLM 功能出现语义异常时，这些信号都不存在。诊断工作流截然不同：识别输出格式是否改变（解析失败率）、语义偏移是否可检测（与标准输出的向量距离）、故障是否与提示词部署、模型更新或输入分布偏移相关。这需要相关的埋点 (instrumentation)，而大多数团队直到经历第一次“隐形故障”后才会着手搭建。

可观测性埋点。 传统的可观测性服务于单一受众：寻找根因的值班工程师。LLM 的可观测性至少服务于四类受众：值班工程师（服务健康状况）、ML 工程师（模型行为）、产品经理（质量和用户影响）以及财务（成本归因）。这些受众会针对相同的遥测数据提出不同的问题，这意味着单一的仪表盘无法很好地满足所有人的需求。那些将 LLM 可观测性仅仅视为现有 APM 扩展的团队，在遇到第一次真正的质量回归时，通常会发现它力不从心。

你尚未建立的新运维手册类别

运行微服务的团队会为已知的潜在故障维护运维手册。而 LLM 服务则需要针对经典运维中不存在的场景编写手册：

提示词回滚。 当提示词更改导致回归时，回滚意味着恢复到之前的提示词版本，而不是重新部署应用程序代码。这要求提示词必须进行版本控制并与二进制文件解耦，存在一个已知的良好状态供回滚，并且值班人员拥有权限和工具在无需完整部署周期的情况下执行回滚。那些将提示词直接嵌入代码且没有提示词注册表的团队，通常会在故障发生时才发现这一短板。

模型版本固定与升级验证。 如果你调用的是供应商托管的端点，你可能无法控制底层模型的更改时间。针对模型更新的运维手册应包括：如何检测模型版本变化（版本响应头、行为探测）、如何评估新版本在特定用例下是否存在回归，以及在新版本不兼容时如何固定到旧版本或激活降级方案。这类似于依赖版本固定 (dependency pinning)，但此处的“依赖”是一个拥有自己升级计划的云服务。

语义回归排查。 当监控显示质量下降时——例如输出格式成功率下降、与参考输出的语义距离增加、下游解析失败增加——语义回归的排查步骤与服务错误不同。运维手册需要区分：这是提示词更改导致的回归、模型行为变化、输入分布偏移，还是检索质量下降？每种情况都有不同的缓解路径，混淆它们会浪费数小时的时间。

成本失控响应。 当 Token 消耗超出预期范围时，紧急响应措施与 CPU 过载不同。Token 预算限制需要在请求级别强制执行，而不只是在汇总层面进行监控。运维手册应明确：在什么阈值下触发告警、如何在不破坏用户会话的情况下进行限流或丢弃负载、如何识别哪个功能或端点是源头，以及何时从前沿模型切换到更小的降级模型，以便在调查故障期间降低单个 Token 的成本。

建立 AI Ops 体系

在生产环境中运行 LLM 服务最可靠的团队，并不是那些拥有最佳 SRE 实践的团队——而是那些很早就意识到其 SRE 实践需要扩展而非仅仅是应用的团队。在发生显而易见的事故之前，他们就已经建立了基于评估 (eval) 的 CI 门控。在需要在凌晨 2 点回滚 Prompt 之前，他们就已经将其外部化到了带有版本的注册中心。在 Agent 循环失控运行之前，他们就已经设置了成本预算限制。

AI Ops 与传统平台工程之间的差距不仅仅是程度上的，而是本质上的。部署单元不同，失败模式不同，诊断路径不同，回滚语义也不同。这一切并不代表 SRE 原则是错误的——它意味着这些原则是必要的，但并不充分。构建可靠 LLM 服务的组织将 AI Ops 视为一项独立的实践，拥有自己的运行手册 (runbooks)、监控维度和测试准则。而那些将其仅视为现有微服务平台扩展的组织将会付出代价，其事后回顾 (postmortem) 文档将准确记录哪些假设是不成立的。