SLO 设计与错误预算决策

• SLI 四类核心指标（可用性、延迟、吞吐量、质量）的定义与选取
• 错误预算的计算公式（1 - 目标达成率）
• 多窗口燃烧率告警的数学原理与落地

设计 SLO 的第一步是明确"用户真正关心什么"，从用户旅程出发而非从内部指标出发。以最常见的四类 SLI 为例：可用性（availability）用请求成功率衡量，如「成功请求数 / 总请求数」；延迟（latency）用分位数衡量，如 P95 请求延迟 < 500ms；吞吐量（throughput）衡量系统处理能力，如「每秒请求数」；质量（quality）衡量业务质量，如「查询结果正确率」「推荐点击率」。SLI 必须可测量、可采集、具有业务意义。选定 SLI 后，为其设定目标值即 SLO。错误预算 = 1 - SLO 目标，例如 99.9% 可用性对应 0.1% 的错误预算，即每月约 43 分钟（30 天 × 1440 分钟 × 0.1%）。错误预算相当于"允许出错的预算"，是系统可靠性投入的货币化体现。多窗口燃烧率（multi-window multi-burn-rate）告警则通过多个时间窗口（如 1 小时与 5 分钟双窗口、6 小时窗口）观测错误预算消耗速率，当燃烧速率达到阈值（如 14.4 倍）时触发告警，从而在错误预算快速耗尽时及时预警，兼顾"发现快"与"少误报"。

该方法论的核心是「以用户为中心定义指标」，避免工程师只盯着内部指标（如 CPU、内存）而忽略真实用户体验。错误预算把可靠性从"玄学"变成可量化、可交易的资源，多窗口特性则通过长时间窗口过滤瞬时抖动、短窗口保证快速响应，是 Google SRE 手册的标准做法。

• 评审会议的组织与参与方（业务、产品、研发、运营）
• 评审内容（SLI 选取、目标值合理性、预算分配、成本）
• 从"工程师单方面定目标"到"多方契约"的转变

SLO 评审是跨职能对齐的关键环节。流程通常为：① 草案阶段——由 SRE/研发团队基于用户旅程与历史数据起草 SLI 定义、目标值与错误预算草案；② 评审会议——邀请业务负责人、产品经理、研发、测试、运营与客户成功代表参加，逐项评审 SLI 是否真实反映用户体验、目标值是否可达（参考历史分位数）、错误预算是否与业务价值匹配（例如核心交易链路 vs 非核心查询应差异化）；③ 决策与取舍——明确「哪些场景被排除在 SLO 之外」（如重大维护窗口、已知限额）、讨论达到目标所需投入（容量、冗余、成本）与业务回报；④ 签订与发布——将 SLO 以文档形式签订，作为对外的可靠性承诺基线，并同步给监控与告警系统；⑤ 定期复审——按季度/半年重新评审，因业务调整、架构演进或容量变化而修订。评审的核心是「协商」而非「工程部门单方决定」，让业务方清楚知晓 SLO 目标的成本含义，避免定出不可达的激进目标。

对齐的关键是让业务方理解「可靠性是有成本的」——更高的 SLO 意味着更多冗余、更复杂运维与更高成本。评审中应展示错误预算/成本的权衡，让业务方在「目标、成本、预期」中做选择。评审产出物应文档化并进入版本管理，作为后续监控与告警的输入。

• 各工具定位（开源规范、生成器、商业平台、可观测平台）
• SLO 声明式定义与 GitOps 管理
• 从定义到告警/看板的自动化链路

SLO-as-code 把 SLO 以声明式 YAML 定义并纳入版本管理，实现「定义即配置、配置即监控」。OpenSLO 是命名开放的 SLO 规范与 SDK，提供标准化的 SLO 定义格式（SLI、SLO、AlertPolicy），可导出到多种后端，是「语言的共同标准」。Sloth 是开源生成器，从 YAML 生成 Prometheus 录制规则与告警规则，与 Prometheus/Grafana 深度集成，适合直接跑在 Prometheus 上的团队。Nobl9 是商业 SLO 平台，支持多数据源（Prometheus、Datadog、New Relic 等）、跨平台统一 SLO 视图、错误预算面板与燃烧率告警，适合多云异构环境。Grafana SLO 是 Grafana 生态内的开箱即用应用，与 Grafana Alerting、Loki 深度集成，适合已重度使用 Grafana 的团队。落地时，把 SLO 定义存入 Git 仓库，通过 CI 校验（如使用 sloth 校验配置合法性）并生成 Prometheus 规则，再通过 GitOps 或 Terraform 部署到监控系统，实现「代码评审批准的 SLO 变更」。

工具选择取决于现有监控栈与规模：轻量团队用 Sloth/Grafana SLO，多数据源异构场景用 Nobl9，需要规范统一时拥抱 OpenSLO 规范。SLO-as-code 的价值在于可评审、可回滚、可审计，避免 SLO 散落在监控系统 UI 中而无法追溯。

• 分位数含义与统计特性
• 不同分位数的选择场景（P50 中位数、P99 长尾）
• 延迟分布偏斜与长尾问题的识别

延迟分位数描述延迟分布：P50（中位数）代表一半请求的延迟，反映典型体验；P90 代表 90% 请求的延迟，接近多数用户；P95 常用于测试指标；P99 代表 99% 请求的延迟，反映长尾与极限场景。设定时，先定义「有效延迟测量窗口」（如每 5 秒聚合），再选择分位数与目标。选择分位数的原则：追求「大多数用户满意」用 P90/P95；面向交易/交互敏感场景考虑 P99；P50 用于衡量典型性能。解读时会发现：平均延迟往往被极端值拉高，而 P99 与 P50 差距大说明存在长尾（可能有慢查询、锁竞争、GC 停顿、网络抖动）。例如 P50=100ms、P99=1000ms，中位数良好但长尾用户等待 1 秒，说明需要优化长尾根因。SLO 通常写成「P95 延迟 < 500ms」或「P99 延迟 < 1s」，并配合错误预算管理。

分位数比均值更能反映真实体验，且能揭示长尾问题。选择分位数要结合业务（交互式 vs 批量）与成本（P99 更严格更难达成）。解读时把 P50 与 P99 差距当成「长尾诊断信号」，并知道 P99 对异常更敏感、易产生抖动，常配合告警阈值使用。

• 成功口径的定义（HTTP 状态码、业务成败、超时判定）
• 统计窗口（滚动窗口 vs 日历窗口）
• 目标值的确定依据（历史数据与业务容忍度）

请求成功率 SLO 设计分三步：① 定义成功口径——明确哪些请求算「成功被服务」。通常按 HTTP 状态码（2xx 视为成功，5xx 失败），但需排除「客户端错误」（4xx 不算服务失败）、考虑超时（超过 SLI 延迟阈值的请求即使返回 200 也可能视为失败，因为用户已放弃等待）、以及业务口径（如订单提交成功才算成功）。② 选择统计窗口——常用滚动窗口（rolling，基于最近 N 天，如 30 天滚动）或日历窗口（calendar，如自然月）。滚动窗口更平滑、更符合"最近表现"的直觉，日历窗口便于与月度业务对账。③ 确定目标值——参考历史成功率分布，结合业务容忍度（可用性承诺），如「过去 30 天成功率基线 99.95%，目标定为 99.9%」留出余量。目标值应「可达成」而非「拍脑袋」，过高导致预算紧张频繁告警，过低则失去保护意义。

「成功」口径是成败关键——定义不当会误判（把 4xx 计入失败、把超时当成成功）。统计窗口影响错误预算的核算粒度，滚动窗口更常用。目标值应基于历史数据反推，并给业务留出解释空间。

• 按 region 独立定义 SLI/SLO 的原因
• region 维度指标的采集与富集
• 全局 SLO 与 region 级 SLO 的聚合关系

多地域部署下，不同 region 的基础设施、网络质量、用户分布差异大，因此应为每个 region 独立定义 SLI 与 SLO，并独立监控。做法：① 按 region 维度给指标打标签（如 region="us-east"、region="cn-north"），据此计算各 region 的可用性/延迟分位数；② 为重要 region 单独设定 SLO 与错误预算（如核心 region 99.95%，边缘 region 99.9%）；③ 分别配置燃烧率告警，避免某 region 故障被全局指标掩盖；④ 全局 SLO 用「跨 region 加权聚合」或「最差 region 原则」计算，例如按流量权重汇总，或对关键 region 单独考核。同时要处理跨 region 的依赖（如主备切换、数据同步延迟），避免用一个 region 的指标掩盖其他 region。监控上利用 Grafana 的多面板、Prometheus 的 by (region) 分组查询，以及 region 维度的时间线与告警。

独立 region 监控的核心是「避免一个 region 的数据平均掉另一个 region 的故障」。加权聚合反映真实业务，最差 region 则暴露短板。标记 region 标签是数据工程基础，需保证各 region 采集口径一致。

• 多窗口组合（短窗口+长窗口）的原理
• 燃烧率阈值（1x、14.4x、720x 等）含义
• 告警分级（page 与 ticket）与告警内容

多窗口多燃烧率告警的核心是用「短窗口快速发现 + 长窗口过滤误报」的组合。Google 推荐的三层配置：① 快速告警（page，如 1 小时窗口，燃烧率 14.4x）——当错误率快速升高、错误预算将在约 2 天（50 小时）内耗尽时立即通知值班；② 缓慢告警（如 6 小时窗口，燃烧率 6x）——预算在约 5 天内耗尽；③ 慢燃尽（ticket，如 3 天窗口，燃烧率 1x）——长期缓慢消耗预算，无需立即唤醒。燃烧率（burn rate）= 当前错误率 / 目标错误率。例如 99.9% SLO 的目标错误率 0.1%，燃烧率 14.4x 表示错误率达到 1.44%。落地时用 Prometheus 定义多组 record 规则，用 and 组合条件确保「短窗口高阈值 + 长窗口低阈值」同时满足才告警，减少误报。告警必须包含：SLO 名称、燃烧率、消耗的错误预算、预计耗尽时间、相关链接（看板、runbook）。

多窗口本质是「在响应速度与误报率之间取平衡」。燃烧率阈值决定告警灵敏度：1x 表示维持当前错误率会持续消耗预算，14.4x 表示约 2 天（50 小时）耗尽，720x 表示 1 小时耗尽。告警分级让「紧急呼叫」与「低优先级工单」分流，避免所有告警都打断值班。

• 客户分级（tier）的维度（付费、合同、业务关键度）
• 差异化 SLO 目标与错误预算分配
• 差异化告警与沟通策略

差异化 SLO 的核心是「对高价值客户投入更高可靠性」。设计步骤：① 客户分级——按合同金额、付费等级、业务关键度（如金融客户、核心企业客户）将客户分为 Tier1/Tier2/Tier3 或白金/黄金/标准；② 差异化目标——Tier1 客户可用性目标 99.99%、P99 延迟更低，Tier2 99.9%，Tier3 99.5%，错误预算相应更紧；③ 差异化监控——对 Tier1 客户流量单独打标签、单独看板与更灵敏的告警；④ 差异化沟通——Tier1 事故主动通知、专属 SLA 报告、更快的响应时限；⑤ 差异化资源投入——为 Tier1 提供冗余、多活、专属容量。执行时需注意：差异化不能演化成「忽视小客户」，应保证基础可靠性底线；错误预算按客户维度的流量占比计算，避免全局指标掩盖单客户故障。

差异化 SLO 是「业务价值驱动可靠性投入」的体现，把有限的工程资源投向高价值客户。但需平衡：过分级会导致运维复杂度上升，且底层共享基础设施的故障可能同时影响所有 tier，因此 tier 级 SLO 更多反映「承诺与投入」而非「物理隔离」。

• 模型质量指标（准确率、AUC、数据漂移）作为 SLI
• 推理延迟与吞吐的 SLO 化
• 推理失败与回退的判定

ML 在线服务（推荐、搜索、风控）的 SLO 需覆盖「质量、延迟、吞吐」三类。① 模型质量——用离线指标（准确率、AUC、NDCG）与在线指标（点击率、转化率、用户反馈）衡量，SLI 可设为「模型效果稳定，质量分变异系数在阈值内」或「预测正确率（对有 ground truth 的样本）」。② 推理延迟——分位数延迟（P95/P99 推理耗时），含预处理、模型推理、后处理全链路；③ 吞吐——服务每秒能处理的请求数（QPS），在高峰期是否满足容量。此外需定义「推理失败」口径（超时、模型报错、降级）并纳入可用性。落地时把模型版本、特征版本作为标签，便于对比不同版本质量；对数据漂移（输入分布偏移）设置监控，作为「质量预警」的非直接 SLI。ML 服务的 SLO 常写成「P95 推理延迟 < 200ms」「模型质量分周环比下降 < 5%」「可用性 > 99.9%」。

ML 服务的难点在于「质量不易直接度量」，需借助代理指标（点击率、转化率）与离线评估。模型质量与推理延迟存在权衡（更复杂的模型更慢更准），SLO 需在两者间平衡。数据漂移是 ML 特有的可靠风险，应纳入监控。

• 正确性 SLI 的难点（需要 ground truth）
• 数据一致性（副本一致、对账、延迟）的度量
• 计算正确率的抽样校验与代理指标

正确性 SLI 度量难度高，因为「错误」需要参照物（ground truth）。常用方法：① 数据一致性——检测副本间数据是否一致，用「对账（reconciliation）差异率」作为 SLI，如「主从数据差异条数 / 总条数 < 0.01%」；对数据同步链路用「同步延迟」衡量（如分钟级延迟 SLA）。② 计算正确率——对关键计算（计费、统计、风控）用「抽样校验」：抽一定比例样本与权威结果比对，正确率 = 正确样本 / 总样本；对无 ground truth 的场景用「业务校验」或「跨系统交叉验证」作为代理。③ 不可变性/幂等性——验证重复处理结果一致。落地时把「对账跑批」作为定时任务，产出正确率指标流入 Prometheus；对账失败触发告警。SLO 示例：「对账差异率 < 0.01%」「数据同步延迟 < 5 分钟」「抽样校验正确率 > 99.99%」。

正确性 SLI 是「与业务正确性相关的可靠性」，必须建立参照物与校验机制。对账与抽样校验是主要手段，但成本高，需设计采样率与频率。正确性错误往往不体现在延迟/可用性上，容易被忽视，需专门监控。

• 移动端 SLA 的客户端侧指标（启动耗时、崩溃率）
• 关键接口成功率与体验
• 客户端采集与上报的挑战

移动端 SLI 更侧重客户端侧体验，需在客户端埋点采集并上报。核心指标：① 启动耗时——冷启动时间（从点击图标到可交互），SLI 如「P90 冷启动 < 2s」；② 崩溃率——崩溃次数 / 启动次数（或活跃用户数），SLI 如「崩溃率 < 0.5%」；③ 关键接口成功率——业务核心接口（登录、下单）的请求成功率与延迟，SLI 如「登录接口成功率 > 99.9%、P95 < 1s」。选取原则：优先选择「用户可感知、影响留存与转化」的指标，启动体验与稳定性是移动端最重要的两个维度。挑战包括：客户端上报的网络延迟与抽样、不同机型/版本/网络环境的差异、版本灰度期间的指标波动。落地时按版本、机型、网络类型打标签，用「按活跃用户数归一化」的崩溃率，接口成功率按关键接口白名单统计，并设置版本维度对比看板。

移动端 SLO 的独特之处在于「数据来自客户端而非服务端」，涉及采集、上报、清洗的工程链路。启动耗时与崩溃率是移动端体验的核心，接口成功率反映后端依赖。需区分「客户端问题」与「后端问题」归因。

• 成功率与延迟各自反映的维度
• 两者的权衡（延迟高但成功 vs 延迟低但失败）
• 组合使用与告警设计

请求成功率反映「服务是否可用」，延迟分位数反映「服务是否够快」，两者互补但可能冲突：一个系统可能成功率高但延迟很慢（用户在等的痛苦），也可能延迟低但偶发失败。权衡时要结合业务：交互式/实时场景（支付、搜索）延迟更敏感，应优先保证 P95/P99；而批量/异步场景（报表、结算）成功率更关键。落地时两者常组合使用：可用性 SLO（成功率）+ 延迟 SLO（分位数）双指标，如「成功率 > 99.9% 且 P95 < 500ms」。告警上也需分别设计——成功率下降触发「可用性告警」，延迟升高触发「性能告警」，两者都可能是同一根因（如资源耗尽）的不同表现。成本上，P99 延迟目标更严格、更难达成，需权衡。

成功率与延迟是「可用性」与「性能」两个维度，不应二选一。组合使用能全面反映体验，但需注意告警与成本的管理。选择时以「用户感知」为最终依据，交互场景重延迟、非交互场景重成功率。

• 达成率/当前 SLI 值 vs 目标
• 错误预算剩余百分比与消耗曲线
• 燃烧率与告警状态

一个有效的 SLO dashboard 应包含：① 当前 SLI 达成率——每个 SLO 的当前指标值（如当前可用性、P95 延迟）与目标值对比，用仪表盘/进度条展示「是否达标」；② 错误预算剩余——以百分比（如剩余 40%）或时间（剩余 43 分钟）展示，用颜色（绿/黄/红）区分健康度；③ 错误预算消耗曲线——时间轴上的消耗趋势，便于观察是否在加速消耗；④ 燃烧率——当前错误率 / 目标错误率，判断是否接近耗尽；⑤ 告警与事件——当前触发的燃烧率告警、最近事件与复盘；⑥ 时间窗口——明确统计窗口（滚动 30 天）与剩余时间。可视化上，错误预算用「环形或条形进度」直观展示剩余，达成率用「差距 vs 目标」的仪表盘，燃烧率用「趋势图+阈值线」。Grafana 的 SLO 面板、Nobl9 的预算图都是常见实现。

SLO dashboard 的价值是「一眼看到可靠性健康度」，让工程师与业务方都理解。核心是「当前值 vs 目标」的对比与「预算消耗」的直观呈现，避免只看瞬时指标而忽略预算累积效应。

• 记分卡的维度（服务、SLO、达成状态）
• 打分规则与汇总方法
• 面向管理层与团队的汇报

SLO scorecard 是「把多个服务的 SLO 达成情况汇总成一张可评估的表格或看板」。设计：① 维度——行是按服务/团队，列是按 SLO 目标（可用性、延迟、质量），单元格填「达成/未达成/逼近」状态；② 打分规则——为每个 SLO 定义达成判定（预算剩余 > 0 为达成），可给权重（核心服务权重高），汇总成服务级得分（如 0-100）；③ 汇总方法——按服务聚合达成率、按团队聚合，形成「团队可靠性健康度」；④ 汇报——用颜色编码（绿=健康、黄=预警、红=超标）生成周报/月报，面向管理层展示「哪些服务可靠、哪些值得关注」。scorecard 常与 Tech Insights（Backstage）或 SLO 平台（Nobl9）集成，定期自动生成。设计时需避免「目标设得过低全员达标」的形式主义，也应区分「达成但逼近预算」的预警状态。

scorecard 把分散的 SLO 变成可管理的「可靠性仪表盘」，便于向上汇报与向下追责。关键在于「达成判定标准」与「权重」的合理设计，避免失真。它服务于「评估与汇报」，而非替代详细看板。

• 从目标值推导错误率阈值
• 燃烧率告警与预算耗尽预警
• 预警分级与动作

把 99.9% SLO 转化为告警阈值的关键是「从目标推导错误率阈值，再设计燃烧率告警」。99.9% 对应错误率 0.1%（目标错误率）。告警阈值设计为「错误率达到目标错误率的 N 倍（燃烧率）」，例如：燃烧率 1x（错误率 0.1%）持续消耗预算 → 发低优先级工单；燃烧率 14.4x（错误率 1.44%）→ 约 2 天（50 小时）内耗尽预算 → 立即 page；燃烧率 720x（错误率 72%）→ 1 小时内耗尽 → 最高优先级。同时用「多窗口」组合减少误报。错误预算消耗预警机制：当错误预算消耗超过 50%、75%、90% 时逐级预警，或当「预计耗尽时间」进入阈值（如 24 小时内）时预警。预警动作包括：提醒值班、暂停低优发布、触发紧盯。实现上，用 Prometheus 录制规则计算燃烧率与预算消耗，配 Alerting 规则。

核心是「用燃烧率代替裸错误率」，因为裸错误率阈值（如错误率 > 5%）无法体现「对预算的威胁速度」。把 SLO 目标与错误预算消耗率关联，才能实现「预算耗尽前及时预警」。

• 错误预算耗尽与发布冻结的关系
• 冻结范围与判定
• 例外审批流程

错误预算耗尽意味着「可靠性欠账」，此时再发布新版本会放大风险，因此应触发发布冻结。机制设计：① 判定——当错误预算消耗率 ≥ 100%（或超过阈值如 90%）时，冻结高风险的发布（新功能、大版本）；② 冻结范围——并非所有发布都冻结，可保留低风险补丁、紧急修复、只读配置变更；③ 例外审批——确有业务紧急需求时，通过例外审批流程（executive exception）放行：必须有明确理由、风险评估、回滚预案、批准人（如 SRE 负责人 + 业务负责人），并承诺「本次发布消耗的预算由额外补偿」；④ 解冻——错误预算消耗回落到健康水平后自动或手动解冻。落地时，把冻结逻辑接入发布流水线（CI/CD gate），错误预算低时阻断 publish，审批通过后加白名单放行。例外审批要「留痕、限时、可审计」，避免形同虚设。

发布冻结是「错误预算作为可靠性货币」的体现——预算耗尽说明系统已不可靠，不应再冒风险。但完全冻结会阻碍业务，因此需要「例外审批」这个安全阀，既保护可靠性又保留业务灵活性。关键在审批的严格性与可审计性。

• 级联依赖的 SLO 聚合（乘法/最差）
• 从全局 SLO 分解到各服务
• 避免整体平均掩盖单点故障

级联依赖下，端到端 SLO 由各依赖服务 SLO 叠加而成。① 聚合——可用性在串联链路上近似相乘（A 可用性 × B 可用性），故「端到端 99.9% 需要各子服务更高」；延迟在串联链路上近似相加（端到端延迟 ≈ 各服务延迟之和）。② 分解——从全局 SLO 反推各服务目标，如端到端 P99 < 1s，需给每个服务分配延迟预算（如 A 200ms、B 150ms）与可用性余量。③ 避免「和稀泥」——全局 SLO 容易因「平均」掩盖某服务故障（如一个服务 99% 被另一个 99.99% 平均掉）。对策：对关键服务单独考核、用「最差服务」或「关键链路」而非全局平均、对每个服务设独立 SLO 与错误预算、识别「关键路径」只对关键依赖设严格 SLO。落地时用「服务拓扑图」映射依赖，用「sli 聚合 + 最差监控」双管齐下。

级联 SLO 的数学本质是「乘法/加法」，工程本质是「不让一个短板被平均掩盖」。既要全局视角（端到端体验），也要局部视角（单服务独立考核），通过「关键路径 + 单服务独立 SLO」化解和稀泥。

• 可靠性得分的定义
• 从错误预算剩余/消耗率推导
• 得分与决策的关系

可靠性得分把「错误预算消耗」转化为可比较的分数，用于评估服务可靠性健康度。常用计算：score = 1 - (已消耗错误预算比例)，或基于「预算剩余百分比」：预算剩余 100% 得满分较高，剩余 0 分得 0。更精细的版本用「加权历史消耗」或「燃烧率」：综合最近多个窗口的错误预算消耗速率，得到「当前可靠性状况」。例如：score = 100 × (1 - 累计消耗比例)，或按「月度消耗 vs 预算」评分。也可用「达成时长」：统计窗口内「达标的时间占比」。可靠性得分用于：① 横向对比不同服务；② 纵向追踪服务可靠性趋势；③ 作为发布门禁或团队考核（如 score < 60 阻断发布）。设计时需明确统计窗口（滚动 30 天）与算分公式，避免「瞬时高错误率」导致分数失真，可用「多窗口加权」平滑。

可靠性得分是「错误预算的归一化表达」，本质是把「剩余预算」映射为「0-100 分」。关键是定义清晰的算分公式与统计窗口，并明确其用途（对比、门禁、考核）。得分应结合「消耗速度」而非只看瞬时，避免误判。

• 发布引发的错误预算损失量化
• 部署质量与错误预算的关联
• 通过改进 MTTR 减少损失

部署是错误预算的主要消耗来源之一。量化方法：① 用「发布前后错误预算消耗速率对比」衡量发布影响——发布后若燃烧率显著上升，说明发布引入了问题；② 计算「发布窗口内消耗的错误预算量」——如发布后 30 分钟内消耗了预算的 0.05%，即为该次发布造成的损失；③ 用「发布失败率」「发布后 N 分钟内的错误率峰值」作为部署质量指标。改进 MTTR 的路径：发布引发的损失 = 错误率 × 影响时长。要减少损失，既要降低错误率（测试、灰度、金丝雀），也要缩短影响时长（即快速发现 + 快速回滚，降低 MTTR）。因此：加强金丝雀发布、自动化回滚、增强发布期的可观测性与告警，都能减少错误预算损失。落地时把「发布事件」与「错误预算消耗」关联，用「发布后错误预算损失」作为发布质量的考核指标。

核心公式是「损失 = 错误率 × 时长」，量化部署质量即量化这两项。通过灰度降低错误率、通过快速回滚缩短时长，双管齐下降低 MTTR 与错误预算损失。把发布事件与预算消耗关联，能形成「发布质量的量化反馈」。

• 发布门禁的判定条件（预算消耗率、燃烧率）
• 与 CI/CD 流水线集成
• 阻断与放行策略（含例外）

错误预算作为发布门禁，即「预算不足时阻断新发布」。实现：① 判定条件——在发布流水线中加入「SLO 检查」步骤，读取当前错误预算消耗率或燃烧率，若超过阈值（如消耗率 > 90%、或燃烧率 > 14.4x）则阻断发布；② 集成方式——在 CI/CD（GitLab CI、Argo CD、GitHub Actions）中调用 SLO 查询 API（如 Prometheus 查询、Nobl9 API），获取预算状态作为 gate 条件；③ 阻断策略——失败时中止流水线、通知负责人、或自动进入「等待消解」；④ 放行例外——低风险发布（补丁、配置变更）可跳过，或走例外审批。示例：Argo CD 用 Webhook 或 pre-sync hook 查询 SLO，预算耗尽则拒绝同步。设计上需区分「长期消耗速率」与「瞬时」——用「一定窗口内消耗 > 阈值」判定，避免瞬时抖动误阻断。

发布门禁是「错误预算作为可靠性货币」的典型应用，把 SLO 状态与部署流程耦合。关键是「读取真实预算状态 + 合理阈值 + 例外机制」，避免门禁过松形同虚设或过紧阻碍业务。

• AI 特有质量指标（幻觉率、安全率）
• 端到端延迟与吞吐
• 错误预算的归因

AI 系统（LLM 应用）的 SLO 需覆盖质量与性能。① 幻觉率——模型输出与事实不符的比例，用「人工/自动评测抽样」度量，SLI 如「幻觉率 < 5%」；② 安全率——输出不包含违规内容的比例，SLI 如「安全率 > 99.9%」；③ 端到端延迟——从用户请求到生成响应的总延迟，SLI 如「P95 端到端延迟 < 3s」；④ 可用性/吞吐——服务可用率与每秒请求数。纳入错误预算：把质量类指标（幻觉率、安全率）作为「质量 SLO」，性能类（延迟、可用性）作为「性能 SLO」，各自独立错误预算。质量指标采集需「评测回路」（评测集、打分模型、人工标注），成本高，常抽样。幻觉率/安全率超阈值触发「质量告警」并消耗预算。端到端延迟受推理模型、上下文长度影响，需按模型版本、场景差异化设定。

AI 系统 SLO 的难点在于「质量」需要评测体系，且幻觉/安全这类指标不可从可观测性直接获得，需建立评测回路。质量与性能是两类不同 SLO，应分开管理错误预算。端到端延迟包含推理延迟，需与吞吐、成本权衡。

• 错误预算作为可靠性验证工具
• 持续跟踪与趋势分析
• 改进措施的效果验证（A/B 前后对比）

错误预算既是目标也是「可靠性验证工具」。验证方法：① 持续跟踪——记录每个 SLO 在窗口内的达成率与预算消耗曲线，观察趋势；② 改进前基线——在实施改进前记录「错误预算消耗速率/MTTR」作为基线；③ 改进后对比——实施改进（如加缓存、加冗余、优化数据库）后，对比同一窗口的错误预算消耗是否下降、达成率是否提升；④ 归因——用「改进措施生效」的假设验证：若改进针对某类错误（如 5xx 比例），改进后该类错误率下降，则验证有效；⑤ 回归防护——用混沌实验、故障演练验证「改进后系统在故障下仍能守住 SLO」。落地时把「错误预算达成情况」做成周期性报告，并把「改进措施」关联到 SLO 维度，用「预算消耗下降」作为改进的量化证据。验证要控制变量（排除业务量、流量变化影响），可用「同口径对比」。

错误预算把「可靠性改进」变成可度量的工程：改进的有效性可通过「预算消耗下降 / 达成率提升」量化验证。关键是「基线对比 + 控制变量」的科学方法，避免把业务波动误判为改进效果。