📚 课程目录第3章 SLI与SLO概念辨析

3. SLI与SLO概念辨析：SLI、SLO、SLA的关系及DORA指标映射

在可观测性与DevOps度量体系中，SLI（Service Level Indicator，服务等级指标）、SLO（Service Level Objective，服务等级目标）与SLA（Service Level Agreement，服务等级协议）构成了服务质量管理的基础三角。理解三者之间的层级关系，是将DORA指标从“原始数据”转化为“可管理目标”的前提。

3.1 核心概念定义

术语	定义	典型示例	责任方
SLI	对服务某个维度质量的实际测量值，是原始数据	请求延迟P99 = 250ms	技术团队定义并采集
SLO	为SLI设定的目标阈值，是内部承诺	P99延迟 ≤ 300ms，99.9%的时间	技术团队与产品共同设定
SLA	与客户签订的法律约束性协议，含惩罚条款	P99延迟 ≤ 500ms，99.95%的时间，否则赔偿	法务、商务、SRE共同签署

  关键认知：SLO 通常比 SLA 更严格（内部目标高于外部承诺），SLI 是 SLO 的量化基础，SLA 是 SLO 的法律化延伸。

3.2 三者的层级关系

下图展示了从原始指标到法律协议的完整链路：

3.3 DORA指标如何映射为SLI

DORA的四个核心指标本质上是软件交付与运维性能的原始测量值，天然符合SLI的定义。在Kubernetes集群环境中，每个DORA指标都可以转化为可观测的SLI口径：

DORA指标	SLI定义（Kubernetes环境）	数据来源	典型口径
部署频率	单位时间内成功部署到生产环境的次数	ArgoCD / Flux / Jenkins事件	次/天或次/周
变更前置时间	从代码提交到生产部署完成的时间间隔	Git提交时间戳 + 部署完成时间戳	分钟/小时/天
变更失败率	导致服务降级或回滚的部署占比	部署事件 + 告警/回滚事件	百分比（%）
故障恢复时间	从服务降级告警到完全恢复的时间	告警时间 + Pod Ready / 健康检查恢复	分钟

实践建议：在Kubernetes中，建议将每个DORA指标拆分为“原始SLI”和“聚合SLI”两层。原始SLI记录每次事件的具体值，聚合SLI按时间窗口（如周、月）计算百分位数或平均值，用于SLO的合规性评估。

3.4 从DORA SLI到SLO的转化示例

以“变更失败率”为例，展示从原始SLI到SLO的完整链路：

原始SLI：每次部署后15分钟内，是否触发P1告警或执行回滚（布尔值）
聚合SLI：过去28天内，变更失败率 = 失败部署次数 / 总部署次数 × 100%
SLO设定：变更失败率 ≤ 15%（精英/高绩效团队标准）
SLA映射：变更失败率 ≤ 25%，否则触发服务信用扣减

3.5 常见误区与避坑指南

⚠️ 常见误区：

将SLA当作SLO使用：SLA是法律底线，SLO是工程目标。直接使用SLA作为SLO会导致“刚好达标”的侥幸心理，缺乏安全缓冲。
SLI定义过于粗糙：例如“部署频率”仅统计次数而不区分部署类型（金丝雀/滚动/蓝绿），导致数据失真。
忽略SLI的聚合口径：同一DORA指标在不同时间窗口（天/周/月）下的SLI值差异巨大，需明确声明聚合方式。
SLO与业务目标脱节：例如将“变更前置时间”SLO设为1小时，但业务实际需要30分钟，导致SLO失去指导意义。

3.6 在Kubernetes中定义DORA SLI的最佳实践

实践维度	推荐做法	避免做法
SLI粒度	按服务/命名空间/集群分层定义	全局单一SLI掩盖局部问题
数据源	Kubernetes API Events + Prometheus Metrics + GitOps工具日志	仅依赖单一数据源导致盲区
SLO设定	基于历史数据P90-P99百分位，预留20%缓冲	拍脑袋设定或直接复制行业基准
SLA映射	SLO × 1.5 ~ 2.0 作为SLA阈值	SLO与SLA相同或过于接近
可视化	Grafana仪表盘展示SLI趋势 + SLO燃烧速率	仅展示原始指标，无SLO合规性视图

  核心结论：DORA指标是SLI的天然候选，但需要经过口径标准化和聚合窗口定义才能转化为可用的SLO。在Kubernetes环境中，利用Event-driven架构和Prometheus的Recording Rules，可以实现DORA SLI的自动化采集与SLO合规性持续评估。