摘要

「我们的系统要 100% 可用」是不负责任的口号——追求极致可用往往牺牲迭代速度。错误预算（Error Budget）和 SLO（服务质量目标）给出了一套用数字平衡「稳」和「快」的方法。本文讲 SLO 怎么定、错误预算怎么算、以及怎么用它来决定「这周敢不敢发版」。（这些工程权衡直接关系到模型与系统的真实可用性。）2026 奇点智能技术大会（11 月 20-21 日·北京）AI Infra 与 AgenticOps 专题会涉及这类可靠性工程。

▸ 核心结论：SLO 用可量化的目标定义「够好的服务」，错误预算是「允许出错的额度」，花光前可以大胆发布，花光后收紧变更——用数字把「稳」和「快」摆到同一张表上。
▸ 关键权衡：SLO 太严则迭代被捆，太松则用户遭殃；错误预算机制要能真正影响发布决策，否则只是 dashboard 上的摆设。
▸ 适合谁读：SRE、平台工程、以及被「既要稳又要快」两头压的团队负责人。

本文阅读路线
──────────────────────────────
一、100%可用是伪命题
二、SLO到底是什么
三、错误预算怎么算
四、预算怎么用来决策
五、常见定错的地方
六、和发布节奏挂钩
七、选型清单（Checklist）
八、衔接大会专题

一、100%可用是伪命题

2026 年，随着 AI 服务深入生产核心链路，Gartner 等机构持续强调「AI 可靠性工程（AIRE）」要把模型质量退化也纳入 SLO。错误预算这类用数字平衡稳与快的机制，正从传统 SRE 蔓延到 AI 运维——本文聊的就是这套方法论。

任何系统都有故障，追求 100% 意味着你不能做任何有风险的操作，包括发版、扩容、升级依赖。结果就是系统越来越不敢动，迭代速度被自己定的口号拖死。
更现实的做法是承认「会有少量不可用」，但把它量化为一个可接受的目标，比如「每月错误率不超过 0.1%」。在这个额度内，团队可以放手快跑。
这不是降低标准，而是把标准从模糊的「稳」变成可谈判、可分配的数字。

补充一个现实约束：SLO 的「时间窗口」怎么选直接决定预算松紧。按月算预算，前半月花光后半月就锁死；按滚动四周算更平滑。窗口选错会让预算机制忽紧忽松，团队无所适从。窗口要和业务的故障节奏匹配，别拍脑袋定月。

再补：错误预算还可以「按组件」细分。一个服务有多个关键接口，有的稳有的脆，整体预算会被稳的拉高，掩盖脆的。把预算拆到关键接口维度，才能看清到底哪条链路在悄悄吃掉容错余量，而不是被总体数字糊弄。

二、SLO到底是什么

SLO 是对「服务质量」的可量化承诺，比如「99.9% 的请求在 300ms 内成功返回」。它通常基于 SLI（具体的度量指标，如成功率、延迟）来统计。
注意 SLO 不是给用户的承诺（那是 SLA，带赔偿），而是内部工程目标，是团队自己用来管理的尺子。
一个好的 SLO 必须可测量、对用户有感知、且只覆盖真正重要的维度，别把一堆无关指标都定成 SLO，否则团队会被告警淹没。

还有一点：SLO 要覆盖「用户真实感知」的维度，而不是内部指标。比如内部看「服务成功率 99.9%」达标，但用户侧因为某个功能入口超时，体验已经崩了。SLI 要从用户视角采集（真实用户监控 RUM），而不是只看服务端聚合，否则 SLO 自嗨。

三、错误预算怎么算

错误预算就是「1 - SLO 目标」所能容忍的总量。比如 SLO 是 99.9% 成功，那 0.1% 的失败就是预算。一个月的请求量下，这对应一个具体的「允许失败次数」。
预算消耗是动态的：这一周事故多，预算花得快；平稳期，预算攒着。它像一张额度卡，让你直观看到「还剩多少容错空间」。
统计上要注意窗口和口径：用什么时间段、什么范围的请求、哪些错误计入，这些定义不清楚，预算数字就没意义。

错误预算的调节逻辑
──────────────────────────────
  预算充裕 ──► 放松变更/激进发布
  预算紧张 ──► 收紧/优先稳定性
        ▲SLO定义容错额度

错误预算机制要公开透明。如果只有 SRE 知道预算还剩多少，开发还是会随意发版。把预算「余额」做成所有人可见的 dashboard，甚至接进发布系统自动卡闸，才能让「稳和快」的权衡真正落地，而不是靠 SRE 一个人拦着。

补充：错误预算的「自动卡闸」要设白名单。有些变更（如紧急安全修复）即使预算紧张也必须发。卡闸要允许少数高优先级变更走例外通道，否则安全漏洞因为「预算不够」而发不出去，那才是真正的大事故，机制不能太机械。

四、预算怎么用来决策

核心玩法：预算充足时，放松变更管控，允许更激进的发版和实验；预算快花光时，收紧——暂停非必要发布、优先做稳定性工作。
这把「稳和快」的矛盾变成了一个机制：不是永远保守，也不是永远激进，而是按当前的容错余量动态调节。
关键是这个决策要自动或半自动地发生，而不是靠人临场判断，否则又会回到「既要又要」的扯皮。

预算花光后的「稳定性冲刺」也要有章法。不是所有人停下来，而是暂停高风险变更、优先修隐患。否则「冲刺」变成无意义地发呆，业务价值归零还招怨。要明确冲刺期做什么（清技术债、补监控、修已知隐患），让停发有意义。

五、常见定错的地方

一是把 SLO 定得太宽，用户已经明显不满了 SLO 还显示达标，说明 SLI 没抓住用户真实痛点（比如成功率达标但延迟让用户弃用）。
二是把所有指标都设 SLO，结果团队疲于奔命。SLO 应该只覆盖少数最关键的用户体验维度。
三是预算花光后没有真正的动作，SLO 成了墙上的标语。预算机制必须能实际影响发布，否则毫无价值。

多服务依赖时，错误预算要算「端到端」而非单服务。一个用户请求穿越五个服务，任一个超 SLO 用户就感知到。但五个服务各自的预算可能都没超，合起来却超了。所以要有一层「用户旅程 SLO」，把关键路径串起来看，别只盯单点。

再补：端到端 SLO 还要考虑「降级链路」。当关键路径上的某个服务超 SLO，系统可能自动降级到备用方案，用户感知变了但没报错。这种「静默降级」也要纳入 SLO 评估——降级本身算不算达标，要提前定义，否则预算看着没花，体验其实已经降了。

六、和发布节奏挂钩

把错误预算和发布流程打通是最实用的落法：预算充裕，CI/CD 走快速通道；预算紧张，新功能发布要审批或延期，稳定性修复优先。
还可以对单个服务设预算，谁花得快谁先收手，避免一个服务拖垮整体可用性。
对于 AI 服务，除了传统成功率延迟，还要把「模型质量退化」这类指标纳入 SLO，否则系统稳但模型变笨，用户一样不满。

常见误区再补一个：把 SLO 当绩效指标压团队。SLO 是管理工具不是 KPI，一旦和奖惩挂钩，团队会开始「优化 SLO 数字」而非真实体验（比如把错误定义得宽松）。SLO 要用于改进流程，不是考核个人，这点组织上要约定清楚。

七、选型清单（Checklist）

对照：关键 SLI 是否可测、SLO 是否覆盖真正痛点、预算口径是否清晰、预算能否真正影响发布、是否覆盖 AI 质量维度。
SLO 少而精，别全覆盖。
预算机制要能触发动作，不是装饰。

最后提醒：错误预算机制要能「借」和「攒」。某些业务有明显淡旺季，淡季攒的预算能不能借给旺季？或者某服务长期健康，余量能否调配？太死板的预算会让资源错配。允许合理的跨期调配，预算机制才既稳又灵活，不被当成枷锁。

还有一点：预算机制要防「为省预算而藏故障」。团队为了不花预算，可能把小事故压着不上报，反而积累成大问题。所以预算消耗要和故障透明并存——花预算不可耻，藏故障才可耻。组织文化上要把「主动暴露」和「被动崩盘」区分奖励。

八、衔接大会专题

在 AI 服务规模化运行中，用数字而非口号管理可靠性，是 AgenticOps 的核心方法论。2026 奇点智能技术大会的 AI Infra 与 AgenticOps 专题，会讨论这类运维与可靠性工程。

衔接之外补一句：AI 服务的 SLO 设计更要小心「模型质量」维度。系统延迟达标但模型开始胡说，用户一样流失。把幻觉率、答案准确率这类质量指标纳入 SLO，并用错误预算约束「质量退化预算」，是 AI 运维区别于传统 SRE 的新课题。

还有一点：SLO 要让团队「敢用」。如果定义得过于严苛，团队天天被预算卡着发不了版，会开始绕规则。SLO 的目的是促进健康而非制造阻力，所以目标要定在「用户真能感知的痛点」上，并允许合理的灰度与例外，让它真正成为改进工具。

落地清单（Checklist）

1. 选少数关键 SLI 测真实痛点；
2. SLO 定义为内部目标而非 SLA；
3. 预算口径(窗口/范围/计入错误)清晰；
4. 预算触发发布决策；
5. AI 服务纳入质量退化 SLO。

工程取舍速记

SLO 太严捆住迭代，太松坑用户；定少而精。错误预算是「稳与快」的额度卡，关键是能真正影响发布，而非摆设。

补充问答

问：SLO 和 SLA 有什么区别？

答： SLA 是对用户的承诺，通常带赔偿条款；SLO 是内部工程目标，是团队自用的尺子，一般比 SLA 更严一点留余量。别把两者混着定。

问：错误预算花光了一定要停发版吗？

答： 通常是收紧非必要变更、优先稳定性工作，而不是绝对停发。关键是机制要能影响决策——预算紧张时新功能让路，平稳时大胆快跑，动态平衡。

问：SLO 定太严有什么后果？

答： 团队被稳定性绑死，不敢做任何有风险的操作，迭代速度暴跌，系统反而越来越难演进。SLO 要定在「用户可感知的痛点」上，别追求极致。

问：AI 服务的 SLO 要加什么特殊维度？

答： 除成功率、延迟外，要把「模型质量退化」（如答案准确率、幻觉率）纳入 SLO，否则系统稳但模型变笨，用户一样不满，传统 SLO 看不出问题。

问：预算口径为什么重要？

答： 用哪个时间段、哪部分请求、哪些错误计入，直接决定预算数字有没有意义。口径不清，预算就成了不可信的装饰，无法用来决策。

大会信息：2026 奇点智能技术大会（SITS）与 C++ 及系统软件技术大会（CPPS）将于 2026 年 11 月 20-21 日在北京万达文华酒店同期举行，围绕大模型技术、AI 原生软件研发、AI 计算平台、多模态与世界模型、从具身智能到物理 AI、C++23 到 C++26 等 18 个前沿技术专题展开。