9.1 SLI、SLO 与错误预算：把可靠性变成决策

生产平台运行在 K8s 集群上，Prometheus 收集 metrics，Jaeger 记录请求链路。监控工具很多仍不等于可靠性目标明确；若团队说不清哪些用户事件算成功，就无法判断一次发布究竟消耗了多少可靠性余量。

SRE 用可衡量的用户体验目标管理可靠性。SLO 不是对系统“永不失败”的愿望，而是在一个窗口的有效样本内允许多少不满足目标的事件，并据此决定发布和可靠性投入。

用好事件占有效事件的比例定义 SLI

本课使用事件型 SLI；也有按时间窗口或其他用户结果定义的指标。

SLI = good events / valid events

先定义 valid，即哪些事件属于测量范围；再定义 good，即状态、延迟和结果满足哪些条件。明确无效输入和测试流量可以按政策排除，但过载限流、服务变慢导致的客户端取消、认证基础设施故障，不能为了报表好看就一律从分母里删掉。

例如搜索可用性：

valid = 真实用户发起且符合接口约定的搜索请求，含服务端超时与限流
good  = 在 800 ms 内返回契约允许的搜索结果，数据新鲜度落后不超过 5 分钟

正常的“没有匹配项”可以是成功结果；异常空结果、错误缓存和业务失败不能仅凭 HTTP 200 算成功。没有有效样本或采集数据缺失时，应显示“无样本/未知”，不能把 0/0 填成 100%。

SLO 有范围、窗口和目标

过去滚动 30 天，99.9% 的有效结算请求在 2 秒内成功完成。

必须写清服务、用户/区域范围、事件来源、排除项、时间窗口和目标。内部组件指标可以帮助诊断，但 SLO 优先贴近用户边界。

不同用户过程可有不同 SLO；不要把全站所有请求混成一个平均值，让低价值高流量掩盖关键路径。

错误预算

目标 99.9% 意味着窗口内允许 0.1% valid events 不满足 good 条件：

error budget = valid events × (1 - SLO target)

例如当前窗口有 1,000,000 个有效事件，预算为 1000 个坏事件；已出现 350 个，剩余 650 个。滚动窗口前移后，进入与移出的好坏事件都会改变这些数值，这不是每月只减不增的一张固定额度表。

错误预算承认边际可靠性有成本。预算健康时可以承担有控制的发布风险；快速消耗时暂停高风险变更并优先恢复可靠性。

政策应预先约定触发条件和例外审批，不能事故后临时拿预算替责任开脱。

Burn rate 衡量消耗速度

burn rate = observed bad-event ratio / allowed bad-event ratio

对 99.9% 目标，允许坏事件比例是 0.1%；观察窗口内坏事件为 1%，burn rate 就是 10。若流量近似稳定且这个比例持续，满额 30 天预算约 3 天就会用完。流量变化、已消耗额度和旧事件移出窗口都会改变实际剩余时间，不能把它当作精确倒计时。

多窗口告警通常要求同一档位的长窗口和短窗口都超出门槛：长窗口确认影响持续，短窗口确认现在仍在发生。不同档位再覆盖快速大故障与缓慢消耗，减少瞬时噪声与慢性漏报。

Page 应对应需要立即人工行动的用户风险；ticket 对应可在工作时间处理的问题；dashboard 用于探索。不能对每个资源阈值都叫醒值班人员。

SLO 不是 SLA

SLA 是与客户约定的服务承诺，可能包含未达标时的补偿等后果；SLO 是用于工程决策的目标，也可以对外公开；SLI 是实际测量。采用相同测量口径时，团队通常把 SLO 设得比 SLA 更严格，留出响应余量。

SLO 的质量检查

• 指标是否从用户边界测得？
• good/valid 是否能用事件精确定义？
• 窗口是否匹配业务周期？
• 低流量服务是否需要合成请求或时间型 SLI？
• 数据管线故障会不会看起来“没有坏事件”？
• 目标是否由用户需求和成本推导，而不是整数偏好？
• 错误预算政策是否真正影响发布决策？

下一课处理预算真的被快速消耗时，值班和事件响应如何运作。

参考资料

• Google SRE Workbook, Implementing SLOs
• Google SRE Workbook, Alerting on SLOs