SLI、SLO 与错误预算
本节目标
从用户期望出发定义可计算的SLI、有窗口的SLO和可指导发布/可靠性取舍的错误预算。
三个概念
- SLI（Service Level Indicator）：服务行为的可量化指标，例如“合格请求在2秒内返回可用答案的比例”。
- SLO（Service Level Objective）：对某SLI在指定窗口内的目标，例如“28天内99%”。这些数值只是语法示例，不是本教程的通用目标。
- SLA（Service Level Agreement）：与用户/客户之间带明确后果的约定，不能与内部SLO混用。
对于基于事件的SLI，最小公式是：
公式简单，困难在“好”与“合格”的语义。用户取消、上游输入非法、安全策略正确拒绝、本系统超时各应如何计数，必须在SLI规范中写清。
从用户任务反推SLI
先问“用户认为任务何时成功”，再选可计算的代理信号。一个Agent应用可能需要多个互补SLI：
| 用户期望 | 可能SLI | 不足 |
|---|---|---|
| 能访问 | 合格请求得到非5xx/非超时结果的比例 | 200不代表答案正确 |
| 等待可接受 | 有效请求的首字可见和完成延迟分布 | 流式首字快可能总耗时仍长 |
| 任务有用 | 已有真值样本的任务成功率/人工接管率 | 标签延迟且可能有选择偏差 |
| 不做危险操作 | 经审计的越权或高损失事件率 | 未检测不等于未发生 |
对重要切片单独计算，防止高流量低风险任务掩盖少量高风险任务。切片不宜无界增加：应与用户损失、发布决策和可行行动对应。
窗口与错误预算
如果SLO目标是，那么窗口内允许的坏事件比例是。它不是“可以故意伤害用户的配额”，而是衡量当前可靠性余量、决定是否需暂停高风险发布的管理工具。
常见窗口：
- 滚动窗口：每个时刻查过去N天，对用户近期经验敏感，计算与解释较复杂；
- 日历窗口：按月/周归零，容易结算，窗口边界可导致相同故障被不同看待。
要将窗口起止、时区、数据延迟和重算规则写入规范。尤其不能用“最后一条到达的事件时间”悄悄移动观察终点：Collector 可以新鲜地导出旧数据，业务事件时龄与导出时龄都应可见。
燃烧率与告警直觉
错误预算燃烧率比较当前坏事件速度与“若匀速用完预算”的速度。高燃烧率表示按当前趋势会很快消耗预算。实战告警可组合短窗口（快速感知）和长窗口（排除短暂噪声），但阈值必须根据本项目SLO、流量和值班响应能力设计，不从教程照抄。
若目标为、观测到的坏事件比例为，教学中可写成：
1x表示按当前窗口允许的预算匀速消耗；5x表示坏事件比例是允许值的5倍。短窗口能较快发现突发故障，长窗口能确认持续影响；两者同时越过阈值再PAGE，是一种常见的降噪思路。Google SRE Workbook给出了基于SLO的多窗口、多燃烧率方法，但其中数值不是通用模板，本库项目使用的是明确标注的本地教学阈值。
燃烧率是当前消耗速度，不是“剩余错误预算比例”。后者必须知道完整SLO合规窗口中已允许和已经消耗的预算、人口与排除规则；单个5分钟或60分钟事故窗口无法诚实计算它。仪表盘和发布策略应把这两种量分开命名、分开取数。
一份可审查的SLI规范
name: interactive_answer_within_budget # 用稳定名称引用该 SLI，避免仪表盘和策略各自命名。
population: production中通过认证且输入契约有效的交互请求 # 精确定义分母，不能把无效输入或未认证流量混入。
good_event: 在用户截止时限前返回非技术错误结果 # 定义分子；业务成功仍需由独立质量 SLI 补充。
exclusions: 用户主动取消（必须能区分） # 只有数据可靠地区分取消原因时才能排除。
source: edge request events # 声明计算所用的原始事件来源，支持审计与回放。
window: rolling 28d # 固定滚动观察窗口，避免跨口径直接比较。
dimensions: [release, task_type] # 保留发布和任务切片，避免总平均掩盖局部退化。
owner: reliability-team # 指定负责口径、告警和改进动作的团队。这是结构示例，不是特定监控产品配置。“用户主动取消”只能在数据可靠区分时排除，否则系统超时被误标为用户取消会虚高SLI。
常见错误
- 从现有Metric反推用户期望：可测的CPU不一定是用户在意的行为。
- 用100%作默认目标：成本、创新和依赖边界常使其不现实；高风险安全事件则应另设零容忍控制，不与普通可用性预算混在一起。
- 将无标签样本当质量成功：只能说不知道，需同时报告标签覆盖率。
- 更改SLI口径后直接续接历史曲线：口径版本不同时数值不可直接比较。
练习与自测
为“自动分类工单，高风险工单转人工”设计可用性、延迟和任务质量SLI。每个都要写总事件、好事件、排除条件、窗口、数据源和切片。回答：
- 为什么HTTP 200可用于技术可用性，却不能代替任务质量？
- 为什么只报已标注样本的成功率还不够？
- 错误预算快耗尽时，哪些发布可继续，哪些应暂停？这一策略应由谁审批？
小结与下一步
SLI将用户期望转成计数契约，SLO和错误预算将其转成行动边界。AI应用还需把技术信号与质量、安全和成本并列，见 质量、安全与成本信号。
参考资料
- Google SRE: Service Level Objectives（访问于2026-07-21）
- Google SRE Workbook: Implementing SLOs（访问于2026-07-21）
- Google SRE Workbook: Alerting on SLOs（访问于2026-07-21；阈值应按本地SLO重新设计）
- OpenTelemetry Observability primer（访问于2026-07-21）