三层体系是什么
SLI 是可测量的服务质量指标，例如成功率、延迟、吞吐；SLO 是内部追求的可靠性目标值；SLA 是对外承诺、通常带赔付条款。三者的分工是：用 SLI 测量，用 SLO 管理，用 SLA 签约。设计原则是 SLO 严于 SLA，为日常波动留出缓冲。这套方法源自 Google SRE 实践，也已被 ITIL 4 与 ISO/IEC 20000 的服务级别管理实践吸收。
基本信息
| SLI 指标 | 测量什么，须能自动采集且有稳定口径 |
|---|---|
| SLO 内部目标 | 追求值，常见滚动 30 天窗口 |
| SLA 对外承诺 | 合同值，含赔付与免责条款 |
| 设计原则 | SLO 严于 SLA，留出缓冲 |
| 典型 SLI | 可用性、延迟、吞吐、正确率、数据新鲜度 |
| 落地载体 | 监控指标 + 错误预算 + 定期评审例会 |
典型使用场景
- 新服务定目标：先选 2-4 个反映用户体验的 SLI，再定 SLO，最后才谈对客承诺
- 与业务方谈 SLA：用历史 SLI 数据反推可承诺值，避免拍脑袋写 99.99%
- 与发布节奏联动：SLO 结合错误预算，决定是否冻结高风险变更
- 多服务分级：核心交易链路目标高，内部工具目标低，投入与业务影响匹配
- 季度评审：看 SLO 达成率与违反原因，决定调目标还是补架构能力
- 排障优先级：SLO 接近突破时提升该服务告警的处置优先级
三层示例
三层示例
SLI：过去 30 天请求成功率 = 成功请求 / 总请求
SLO：99.95%（内部目标，滚动 30 天窗口）
SLA：99.9%（对外承诺，含赔付条款）
口径必须写死：总请求是否含 4xx、超时是否算失败、重试如何计入
反例：只写“99.9% 可用性”，不说窗口与排除项，月度评审必吵架三层职责对照
| 层次 | 回答什么问题 | 典型数值 | 谁来定 |
|---|---|---|---|
| SLI | 测量什么 | 成功率 99.97% | 研发与可靠性工程师 |
| SLO | 内部追求到什么水平 | 99.95% | 服务负责人与业务方 |
| SLA | 对外承诺多少、违约赔多少 | 99.9% | 业务与法务 |
| 错误预算 | 还剩多少可消耗额度 | 由 SLO 推导 | 服务负责人 |
把所有服务都定成 99.99% 等于没定目标：目标越高投入越成倍，应让目标反映业务损失，而不是反映主观期望。
SLI 要选在用户路径上：核心交易成功率跌到 95% 时，进程活着也没有意义，只测主机存活会严重高估体验。
SLO 的统计窗口与 SLI 口径必须写进文档并版本化，改口径要留记录，否则历史数据不可比、SLA 争议也没有依据。
常见 SLI 候选
- 可用性：成功请求占比，注意 4xx 与超时如何取舍
- 延迟：达到阈值以下的请求占比，比平均值更能反映体验
- 吞吐：单位时间处理量，容量规划的基础
- 正确性：返回结果符合业务预期的比例
- 新鲜度：数据管道与同步的延迟
- 饱和度：资源接近上限的程度，用作预警信号
与错误预算的关系
SLO 一旦确定，可消耗的失败额度就固定下来，此时 SLI 的采集精度直接决定预算消耗是否可信。采集缺失或延迟会让预算统计出现缺口，冻结与放行的决策也就失去依据，因此口径评审要与监控变更一起做。
SLI 不是越多越好：每增加一个指标都要有对应的数据源、告警阈值与处置动作，否则只会增加噪声与值班负担。
目标要随业务阶段调整：新业务追求增长时可适当放松 SLO 换取迭代速度，进入稳定变现期后再收紧，调整记录要留档。