AI 学习笔记（二十）：LLM SLO、Error Budget 与值班治理最小实践

发表于 更新于 分类于 阅读次数： Changyan： 本文字数： 4.4k 阅读时长 ≈ 4 分钟
把监控、事故响应和发布闸门再往前推进一步，用 SLO、error budget 和 on-call runbook 定义“什么算稳定、什么时候该收紧发布、谁来接住事故”。

上一篇我们把发布闸门、灰度和回滚的最小闭环串起来了。
但生产稳定性并不只取决于“这次发版有没有出事”，还取决于下面三件事是否清楚：

  1. 什么才算“稳定”
  2. 稳定性被消耗到什么程度时必须收紧变更
  3. 半夜真的出问题时，谁来接住、按什么剧本处理

这篇继续生产运维实践主线，聚焦三个经常被一起提起、却很少一起落地的概念：
SLO、error budget 和 on-call 值班治理。

先说结论：

  1. 没有 SLO，告警和发布就没有统一尺度
  2. 没有 error budget，团队会长期靠感觉做放量与冻结
  3. 没有 on-call runbook，再好的监控也可能接不住真实事故

1. 为什么这三件事必须一起落

很多团队已经有监控、事故响应和发布流程，但线上还是反复“有惊无险”。
根因通常不是工具不够多，而是三层判断彼此脱节：

  1. 监控层
    指标很多，但没人能回答“到底有没有越线”
  2. 变更层
    灰度和发布在继续，但不知道稳定性预算是不是已经快耗尽
  3. 响应层
    事故来了能拉群，却没有固定值班角色和标准动作

SLO 负责回答“什么叫稳定”；
error budget 负责回答“还剩多少试错空间”；
on-call 负责回答“系统偏离稳定时，谁按什么顺序把它拉回来”。

这三个环节连起来，发布闸门、事故响应和日常治理才会形成闭环。

2. 先统一最小概念，不要一开始就做复杂

在 LLM 场景里，我建议先只记住 3 个定义：

  1. SLI
    你真正拿来度量体验的信号，比如成功率、结构化输出通过率、人工接管率
  2. SLO
    你承诺的目标区间，比如 28 天内核心请求成功率不低于 99.5%
  3. Error Budget
    允许你“没达到 SLO”的那部分余量，它决定你还能不能继续激进变更

最容易犯的错是把所有指标都设成 SLO。
实际上，只有满足下面两个条件的指标才适合进入 SLO：

  1. 它和用户体验或业务风险直接相关
  2. 你能稳定采集、稳定复算、稳定回放

像 token 使用量、provider 内部 trace、某段 prompt 命中次数 这些指标很重要，但更适合作为诊断或成本治理指标，而不是直接变成稳定性承诺。

3. LLM 的 SLO 不该只盯可用性

如果你只把 HTTP 200 当作成功，LLM 系统会出现一种很典型的“假稳定”：
接口没挂，但答案已经变差、结构已经漂、工具已经误调用。

更实用的做法是把 SLO 分成 3 层：

3.1 服务可用性 SLO

面向传统稳定性问题：

  1. 核心路由成功率
  2. P95 / P99 延迟
  3. provider fallback 成功率

3.2 结果质量 SLO

面向 LLM 特有问题：

  1. 结构化输出成功率
  2. 关键任务通过率
  3. 引用/检索命中正确率
  4. 人工抽检质量分

3.3 副作用与人工接管 SLO

面向 agent / 工具场景：

  1. 高风险工具误调用率
  2. 错误写操作事件数
  3. 人工接管率
  4. 只读降级触发次数

最小实践里，不要求你三层都做得非常精细。
但至少要避免只看“服务活着没有”，而忽略“结果是否还能被信任”。

4. 一个可直接照抄的最小 SLO 示例

如果你现在刚开始给 LLM 应用定 SLO，可以先从下面这组最小目标起步：

  1. 28 天窗口内，核心问答/执行路由成功率 >= 99.5%
  2. 28 天窗口内，结构化输出成功率 >= 97%
  3. 28 天窗口内，高风险工具错误写操作 = 0
  4. 28 天窗口内，人工接管率 <= 8%

把它写成结构化配置会更容易接到告警、发布和复盘链路里：

1
2
3
4
5
6
7
8
9
10
slo:
  window_days: 28
  service_success_rate:
    target: 0.995
  structured_output_success_rate:
    target: 0.97
  risky_write_incidents:
    target: 0
  human_handoff_rate:
    target: 0.08

这里有两个落地提醒：

  1. 99.5% 在 28 天窗口下，大约对应 202 分钟不可用预算
  2. 质量型 SLO 不一定换算成“分钟”，很多时候更适合按“失败请求配额”计算

也就是说，error budget 不一定只有一种形态。
服务型目标适合按时间预算看，质量型和副作用型目标更适合按请求预算或事故次数看。

5. Error Budget 最有价值的地方，是把“该不该继续发版”变成规则

很多团队明明知道最近不稳，但因为没有预算机制，还是会继续上新模型、新 prompt、新工具链。
结果是线上本来已经在飘，变更还在加速。

更稳的做法是把 error budget 直接接到发布策略：

  1. 预算剩余 >= 50%
    正常发布，但保留 Canary 和自动回滚
  2. 预算剩余 20% ~ 50%
    只允许低风险变更，强制小流量灰度
  3. 预算剩余 < 20%
    冻结高风险发布，只允许修复类变更
  4. 预算耗尽
    进入恢复优先模式，停止新功能放量，先处理稳定性债务

下面是一段可直接放进 Node.js 服务层或发布器里的最小判断逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
export function decideReleaseGuard(report) {
  const {
    serviceBudgetLeftRatio,
    qualityBudgetLeftRatio,
    riskyWriteIncidents,
  } = report;

  if (riskyWriteIncidents > 0) {
    return { mode: "freeze", reason: "risky-write-incident" };
  }

  const minBudgetLeft = Math.min(serviceBudgetLeftRatio, qualityBudgetLeftRatio);

  if (minBudgetLeft <= 0) {
    return { mode: "freeze", reason: "budget-exhausted" };
  }

  if (minBudgetLeft < 0.2) {
    return { mode: "fix-only", reason: "budget-critical" };
  }

  if (minBudgetLeft < 0.5) {
    return { mode: "canary-only", reason: "budget-low" };
  }

  return { mode: "normal", reason: "budget-healthy" };
}

这段代码的重点不是“写法高级”，而是把“收紧发布”从口头共识变成系统规则。

6. 值班治理不要一上来学大厂全套，先把最小角色和剧本定住

值班体系最怕两种极端：

  1. 完全没有值班，事故来了靠谁在线谁处理
  2. 一次性引入很重的值班流程，最后没人愿意真正维护

更适合多数团队的最小版是 3 个角色：

  1. Primary On-call
    第一响应人，负责确认告警、执行 runbook、发出第一轮状态同步
  2. Secondary On-call
    Primary 处理不过来时接手，或协助定位 provider / 检索 / 工具链问题
  3. Incident Commander
    不一定 24 小时轮值，但 P1/P2 事故时必须明确谁统一决策和同步

同时固定 4 类值班资产：

  1. 告警分级
    只有真正影响用户或副作用风险高的信号才 page 人
  2. 路由开关
    provider fallback、只读模式、禁用高风险工具、缩上下文
  3. Runbook
    每种高频故障对应固定止血动作
  4. 升级路径
    多久没人响应就自动升级到 Secondary / 负责人

如果这 4 件事都没有，再多告警平台也只是把噪音更快地送到人脸上。

7. 一个够用的 On-call Runbook 模板

每个核心链路的 runbook，最少要写清楚下面 5 件事：

  1. 触发条件
    什么指标越线时进入值班处理
  2. 影响判断
    哪些路由、租户、模型、工具受影响
  3. 止血顺序
    先切什么，再关什么，最后怎么验证
  4. 升级条件
    多久没恢复，或出现哪些副作用时必须拉更多人
  5. 恢复验收
    哪些指标回到什么区间才算恢复

比如针对“structured output 失败率飙升”的最小 runbook：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
runbook:
  incident: structured-output-drift
  trigger:
    schema_success_rate_lt: 0.94
  actions:
    - disable_new_prompt_version
    - route_to_safe_model
    - shrink_output_schema
    - require_human_review_for_write_actions
  escalate_if:
    duration_minutes_gt: 15
    risky_write_incident_gt: 0
  recover_when:
    schema_success_rate_gte: 0.97
    error_rate_lte: 0.03

关键不是把文档写长，而是让值班同学能在 5 分钟内照着执行。

8. 一周内可落地的推进顺序

如果你现在还没有这套治理，我建议按下面顺序推进：

  1. Day 1
    选 2~4 个最关键 SLI，先定义 28 天 SLO
  2. Day 2
    给每个 SLO 算出对应预算，并接入日报或仪表盘
  3. Day 3
    把预算剩余量接进发布闸门，支持 normal / canary-only / fix-only / freeze
  4. Day 4
    给核心链路写 2~3 份 runbook，覆盖 provider 故障、schema 漂移、检索异常
  5. Day 5
    固定 Primary / Secondary 值班角色和升级路径，并做一次演练

做到这里，系统就从“能监控”升级成“知道什么时候该收紧、谁来接住、按什么方式恢复”。

总结

SLO、error budget 和 on-call 不是三套独立制度，而是一条完整的稳定性治理链路：

  1. SLO 定义稳定目标
  2. Error budget 约束变更节奏
  3. On-call runbook 保证越线时有人能接住

如果你这周只能先做一件事，我最推荐的是：
先把核心链路的 SLO 和 budget 剩余量接到发布闸门里。

因为只要“预算不足就自动收紧发布”这件事成立，很多线上波动会在扩大之前被拦下来。

参考资料

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-slo-error-budget-on-call-minimal-practice/