slo-error-budget

SLO 与错误预算技能

为一项服务编写完整、可实施的 SLO 文档，涵盖要衡量的内容、目标设定、错误预算的计算方式，以及预算消耗时的应对措施。

好的 SLO 不是一个要达成的目标，而是关于可靠性对用户意味着什么的一份约定，也是一个在可靠性与交付速度之间做出有原则权衡的框架。

本文在事件响应主干中的位置

这是事件响应主干的调控器：slo-error-budget（框架）→ /debugging-log-analyser → /incident-postmortem → /oncall-runbook。它设定整个流程所依据的 错误预算——这一目标强制机制决定后续复盘的行动项是立即处理（预算已消耗），还是延后 处理（预算充足）。共享术语（SLO、错误预算、事件、行动项）统一定义在 docs/craft/incident-response.md 中。

流程

如果 SLO 只是理想化的目标，而非基于用户需求制定，或者预算没有约束力，那么 SLO 就会失效。第 1 阶段至关重要：按“100% 减一点”选出的目标毫无保障作用。

1. 根据用户需求推导目标，而非从 100% 倒推。 选择能够反映用户实际感受的 SLI（成功率、延迟、新鲜度），并根据用户需求设定目标——也就是可靠性再提高对用户不再重要的临界点。 完成标准： 每个 SLO 目标都能追溯到明确的用户需求，且没有任何目标是 100%，也不是为了好看而选的整数。
2. 用数学计算将目标转化为预算。 将错误预算（在统计周期内，以 100% 减去 SLO）换算成具体额度——请求数、分钟数或事件数，而不是无人有切身感受的百分比。 完成标准： 预算以统计周期内可计数的额度表示，且消耗速率告警会在预算耗尽前触发，而不是耗尽后才触发。
3. 让预算具有约束力——策略才是关键。 明确各预算等级下的变化：充足 → 发布；有风险 → 放慢节奏并补强可靠性；耗尽 → 停止功能开发并修复可靠性。没有策略的预算，只是一张没人遵守的仪表板。 完成标准： 每个预算等级都明确了一项具体且会强制执行的后果——包括一个真正的功能冻结触发条件——并且团队确实会遵守。
4. 将其作为流程调控器交接。 明确说明，该预算用于确定 /incident-postmortem 行动项的优先级：预算已消耗时，行动项应立即处理；预算充足时，则可以等待。 完成标准： 下游流程能够依据此预算判断行动项的紧急程度，而无需重新讨论可靠性目标。

必需输入

如果尚未提供，请询问以下信息：

• 服务名称和简要功能说明
• 主要用户——哪些用户依赖这项服务，以及如何依赖
• 要保障的面向用户的交互——例如 API 调用、页面加载、交易
• 当前可靠性数据——错误率、延迟、正常运行时间（如有，请提供最近 30–90 天的数据）
• 现有值班安排——谁负责响应告警？
• 部署频率——团队多久发布一次？
• 与客户签订的任何现有 SLA——这些会限制 SLO 目标的设定

关键定义

编写 SLO 之前，务必先明确以下定义：

术语	定义
SLI（服务级别指标）	被衡量的指标——例如“在 <500ms 内成功完成的请求百分比”
SLO（服务级别目标）	该指标的目标值——例如“99.5% 的请求”
SLA（服务级别协议）	对客户作出的合同承诺——其标准必须低于 SLO
错误预算	低于 100% 的可用余量——用于计划内和计划外停机的预算
消耗速率	错误预算的消耗速度

---

输出格式

---

SLO 文档：[服务名称]

服务：[名称] | 团队：[团队名称] 负责人：[姓名 / 职务] | 审批人：[姓名] 生效日期：[日期] | 复审日期：[日期 + 3 个月] 版本：[1.0]

---

此 SLO 存在的原因

[用 2–3 句话说明。我们要解决什么可靠性问题？在需要制定此 SLO 之前发生了什么？此 SLO 有助于做出哪些决策？]

---

服务概览

此服务的功能： [一句话] 依赖此服务的对象： [内部团队／外部客户／两者兼有——请说明] 此 SLO 保护的关键用户旅程：

1. [旅程 1——例如“用户完成付款”]
2. [旅程 2]
3. [旅程 3]

---

SLI——衡量指标

为每个用户旅程或可靠性维度定义一个 SLI。最多保留 3–5 个 SLI。

SLI 1：[名称——例如请求成功率]

字段	详情
衡量内容	[例如“返回非 5xx 响应的 API 请求百分比”]
良好事件定义	[例如“HTTP 响应状态为 2xx 或 4xx，且在 500ms 内完成”]
不良事件定义	[例如“HTTP 响应状态为 5xx，或响应耗时超过 500ms”]
测量来源	[例如“应用负载均衡器访问日志／Datadog APM／Prometheus”]
测量周期	滚动 28 天窗口
排除项	[例如“排除健康检查端点／排除计划维护期间的请求”]

SLI 2：[名称——例如延迟]

字段	详情
衡量内容	[例如“/checkout 端点的 P99 响应时间”]
良好事件定义	[例如“P99 请求在 ≤500ms 内完成”]
不良事件定义	[例如“P99 请求耗时超过 500ms”]
测量来源	[来源]
测量周期	滚动 28 天窗口
排除项	[任何排除项]

SLI 3：[名称——例如数据新鲜度／队列深度等]

[相同结构]

---

SLO 目标

SLI	目标	窗口	错误预算
[SLI 1 名称]	[X]%	28 天滚动	[100 - X]% = [Y 分钟／月]
[SLI 2 名称]	[X]%	28 天滚动	[100 - X]% = [Y 分钟／月]
[SLI 3 名称]	[X]%	28 天滚动	[100 - X]% = [Y 分钟／月]

目标的设定方式：

• 历史基线（过去 90 天）：[X]%
• 目标设定为[高于／等于]历史基线，以[提升可靠性／反映当前实际情况，同时将承诺正式化]
• 理由：[用 1–2 句话说明]

为什么目标不是 100%： [简要说明将目标设为 100% 为什么适得其反——这会阻碍功能开发，也无法反映用户的实际情况]

---

错误预算计算

对于 SLI 1（[名称]），目标为 [X]% 时：

Error budget = (100% - SLO target) × measurement window
             = (100% - [X]%) × 28 days × 24 hours × 60 minutes
             = [Y]% × [Z total minutes]
             = [N] minutes of allowed failure per 28-day window

**通俗地说：**在任何滚动 28 天窗口内，发生 [不良事件] 的时间最多可达 [N] 分钟，之后就会违反 SLO。

---

消耗速率告警

消耗速率 = 相对于预算窗口，错误预算的消耗速度。 消耗速率为 1 = 按照恰好会在 28 天内耗尽预算的速度消耗预算。

告警	消耗速率	窗口	严重性	响应
页面告警（严重）	>14×	1 小时	P1	立即呼叫值班人员——预算将在 <2 小时内耗尽
页面告警（高）	>6×	6 小时	P2	呼叫值班人员——预算将在 <5 天内耗尽
工单（警告）	>3×	3 天	P3	创建工单——在下次团队会议上审查
信息	>1×	28 天	信息	仅记录——预算预计将在窗口结束时耗尽

告警实现：[监控工具中的告警配置链接——例如 Datadog、Prometheus/Alertmanager、Grafana]

---

错误预算策略

此策略规定如何处理错误预算——无论预算状况良好还是正在消耗。

预算状况良好（剩余 >50%）时

• 功能开发和部署按正常节奏进行
• 团队可以进行风险较高的实验
• 安排可靠性改进，但无需紧急处理

预算面临风险（剩余 25–50%）时

• 降低部署频率——团队仅发布经过充分测试的变更
• 在当前冲刺中增加一项可靠性改进
• 在团队站会中增加每周错误预算审查

当预算即将耗尽（剩余不足 25%）

• 暂停功能开发，优先改进可靠性
• 未经值班人员明确批准，不得进行新的部署
• 每日审查错误预算消耗速率
• 通知 CSM / 支持团队，以便管理客户预期

当预算耗尽（剩余 0% — SLO 违约）

• 停止所有功能开发
• 立即通知值班工程师和工程经理
• 必须在 5 个工作日内完成事件后审查（PIR）
• 在解决根本原因期间，可暂时放宽 SLO 目标（须经利益相关方批准）

---

仪表板和报告

SLO 仪表板： [Datadog / Grafana / 等仪表板链接]

公开的指标：

• 当前 SLO 合规性（滚动 28 天）
• 剩余错误预算（百分比和分钟数）
• 消耗速率（当前值和趋势）
• 本统计周期内的事件数量和 MTTR

报告频率：

对象	频率	格式
工程团队	每周	Slack 摘要 — #[service]-slo
工程经理	每月	SLO 审查会议
利益相关方 / 客户	每季度	SLO 合规性摘要

---

排除项和边缘情况

计划内维护： 在提前公告的维护时段内不消耗错误预算。必须提前 [X 小时] 通过 [频道] 通知维护安排。

依赖项故障： 如果 SLO 违约是由我们无法控制的上游依赖项导致的，请记录下来——但这仍会计入我们的错误预算（用户无法区分故障是由我们自身还是依赖项导致的）。

不可抗力： [云服务提供商中断、重大基础设施事件的政策]

---

SLO 审查频率

审查	时间	参与者	产出
错误预算审查	每周	团队	预算健康检查 — 消耗过快时进行调整
SLO 目标审查	每季度	团队 + EM	基线发生显著变化时调整目标
年度 SLO 审计	每年	团队 + 利益相关方	审查 SLI — 我们衡量的内容是否正确？

何时更改 SLO 目标：

• 历史基线已显著改善，当前目标已无法反映实际可靠性
• 用户反馈表明，目标与用户的实际体验不一致
• SLO 指标遭到操纵（指标看似健康，但用户并不满意）

---

质量检查

• SLI 面向用户——衡量用户的实际体验，而非内部系统指标
• 对优质事件和不良事件有明确定义——哪些情况计入统计毫无歧义
• 目标基于历史数据，而非理想化的整数
• 错误预算策略具有明确的触发条件和行动——不能只是“团队讨论”
• 消耗速率警报设有不同的时间窗口，以便捕捉快速和缓慢的消耗
• 已记录排除项，避免它们悄然抬高 SLO 数值

反模式

• 不要将 SLO 目标设为 100%——这会阻碍功能开发，也无法反映用户对可靠性的实际体验
• 不要将内部系统指标用作 SLI——SLI 必须反映用户的直接体验，而非内部 CPU 或内存情况
• 不要编写触发条件含糊的错误预算策略——“团队讨论”不是可执行的策略；触发条件必须采用明确的百分比
• 不要基于理想化的整数设定目标——始终应根据历史基线数据推导目标
• 不要只配置一个消耗速率警报时间窗口——单一窗口会漏掉快速消耗和悄然耗尽预算的缓慢消耗