结论：SLI 是衡量服务水平的指标（如可用性 = 成功请求数/总请求数、延迟 P99）；SLO 是内部承诺的目标值（如月度可用性 99.9%、P99 < 300ms）；SLA 是对外的合同条款（含违约赔偿），通常比 SLO 宽松留缓冲。错误预算 = 1 - SLO（99.9% 即每月约 43 分钟不可用额度），预算花完就冻结新发布、优先稳定性工作。
展开：实践链条：1）SLI 要选用户可感知的黄金信号——延迟、错误率、可用性，用 Prometheus 的 recording rule 基于 histogram 计算，避免直接拿机器指标当 SLI（CPU 高不等于用户受损）；2）SLO 设定从用户体验反推而非拍脑袋，99.9% 与 99.99% 的成本差是数量级的（多活、变更管控），且下游依赖的 SLO 乘积是上游天花板（串行依赖 3 个 99.9% 服务，你的上限约 99.7%）；3）错误预算驱动决策——预算充足时允许激进发布，消耗过快触发燃烧率告警（burn rate alert：短时间窗口错误率折算的预算消耗速度），这是比"瞬时错误率告警"更科学的告警范式，能同时捕捉缓慢出血和急性事故。易错点：SLO 不是 100%——追求完美等于剥夺迭代空间；SLI 统计窗口（滚动 28 天 vs 自然月）影响预算计算的公平性。
# 5 分钟窗口错误率
sum(rate(http_requests_total{code=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
追问方向：多窗口多燃烧率告警（Google SRE 手册第六章）、SLO 与告警分级的映射（预算快烧完才 page 人）。