SLI、SLO 和 SLA 有什么区别？错误预算怎么计算、怎么用？

知识点详解：从用户体验，到可靠性决策

测什么，比目标写多少更重要

假设查询返回 HTTP 200，结果却为空或严重过期。只统计没有 5xx，就可能把用户失败算成成功。

先定义好事件：正确完成、满足业务要求、在约定时间内返回。总事件也要说明有效请求和排除范围。

观测位置也重要。服务内部可能看不到网关、网络问题，用户侧更完整但采集更复杂。

SLO 与 SLA 为什么不能混用？

SLO 指导团队工程工作，例如窗口内 99.9% 的请求达标。SLA 是外部约定，可能涉及额度补偿等后果。

内部目标和对外承诺可以相关，不要求相同。没有商业 SLA 也可以有 SLO；有合同写几个九，不代表已建立测量与行动机制，见 Google SRE 服务目标。

预算必须使用同一口径

假设教学场景中，一个窗口一百万次有效请求，目标 99.9%。允许不良事件一千次。

已有六百次不达标，剩余四百次。计算的是请求，不是分钟。流量不均匀，不能直接换成固定宕机时长。

只有按时间片定义目标，才适合算不良时间片。固定月与滚动窗口也不同，预算过期和恢复规则需要明确。

所以分子、分母、窗口和目标一起记录，不能拿某一天失败数减另一个窗口的预算。

图：错误预算，不能混算请求与分钟。

为什么看预算消耗速度？

剩余很多，但短时间消耗极快，也可能马上超标。需要比较不良事件率与允许不良率。

例如允许 0.1%，当前达到 1%，就是以允许速度的十倍消耗。仍需要足够样本与窗口，低流量下单事件会让比例剧变。

多窗口组合有助于分辨突发与长期恶化，不能只看月平均而延迟处理当前事故。

预算怎样影响工程工作？

预算健康，可继续可控发布；过快或用尽，按事先约定优先修可靠性并降低变更风险。

这需要产品、开发、运维共同确认政策，不是事后拿指标争辩，见 Google SRE 实施 SLO。

安全漏洞、数据损坏不应被平均成功率掩盖。预算描述服务目标，不是给严重风险发许可。

图：看消耗速度，决定工程优先级。

面试官继续追问

为什么不统一 100%？

现实链路无法无成本绝对可靠，目标应对应需要与代价。但不能借此忽略可避免问题。

CPU 高，SLO 正常，还要处理吗？

要评估余量与风险。它是内部重要信号，只是不等于当前用户失败。

用尽后停止一切发布？

看约定政策。可靠性修复、安全补丁可能优先发布，不能机械禁止所有变更。

面试速记卡

• SLI：测量真实服务表现。
• SLO：明确口径与窗口内目标。
• SLA：对外约定和后果。
• 错误预算：事件或时间不能混算。
• 工程作用：按消耗调整变更与可靠性工作。