2. SLI 基础概念：什么是 SLI、SLO、SLI 与 SLO 的关系、为什么需要统一的 SLI 口径
2.1 核心定义：SLI 与 SLO
在开始构建跨团队流水线质量体系之前，必须统一对 SLI 和 SLO 这两个基础概念的理解。它们是整个可观测性与可靠性工程的基石。
| 术语 | 全称 | 核心定义 | 通俗理解 |
|---|---|---|---|
| SLI | Service Level Indicator （服务等级指标） |
对服务某个特定维度的量化测量值，通常是随时间变化的数值或比率。 | “我们测量了什么？”—— 例如：流水线成功率、构建时长 P95、部署频率。 |
| SLO | Service Level Objective （服务等级目标） |
为 SLI 设定的目标阈值或范围，代表服务可接受的表现水平。 | “我们希望达到什么水平？”—— 例如：流水线成功率 ≥ 99.5%。 |
关键区分： SLI 是“事实”（实际测量值），SLO 是“期望”（目标值）。没有 SLI 的 SLO 是空谈，没有 SLO 的 SLI 是无效数据。
2.2 SLI 与 SLO 的关系：从测量到目标
SLI 与 SLO 构成一个闭环的可靠性管理模型。SLO 基于 SLI 的历史数据与业务需求设定，而 SLI 的持续观测又用于评估 SLO 的达成情况。
2.3 为什么需要统一的 SLI 口径
在跨团队协作中，如果没有统一的 SLI 口径，每个团队对“成功率”、“延迟”、“可用性”的定义可能完全不同，导致数据无法横向对比，告警混乱，甚至引发团队间的信任危机。
典型混乱场景： A 团队将“流水线成功率”定义为“代码编译通过率”，B 团队定义为“包含集成测试通过率”，C 团队定义为“部署到生产环境且无回滚的比率”。三个团队汇报的“成功率”都是 99%，但实际质量水平完全不同。
统一口径的三大核心价值
- 可对比性： 所有团队使用相同的测量方法与计算逻辑，确保跨团队数据可以横向比较，识别出真正的瓶颈团队。
- 可归因性： 当 SLO 未达成时，统一的 SLI 口径能快速定位是哪个环节、哪个团队的数据出现了问题，避免互相推诿。
- 可自动化： 统一的 SLI 定义可以直接编码为可复用的监控与告警规则，减少人工解释与配置成本。
2.4 统一口径的落地要素
要实现统一的 SLI 口径，需要在组织层面和技术层面达成一致。以下是必须明确的四个要素：
| 要素 | 说明 | 示例（流水线成功率） |
|---|---|---|
| 测量对象 | 明确 SLI 作用于哪个实体或过程 | 每条 CI/CD 流水线的单次执行 |
| 测量方法 | 如何采集原始数据，使用什么工具 | 从 Jenkins/GitLab CI API 获取构建状态 |
| 计算逻辑 | 具体的数学公式或聚合方式 | 成功执行次数 / 总执行次数 × 100% |
| 时间窗口 | 数据聚合的时间范围 | 滚动 7 天 / 滚动 30 天 |
实践建议： 在跨团队启动 SLI 口径统一工作时，建议先由 SRE 团队输出一份《SLI 口径定义模板》，包含上述四个要素的填写规范。各团队基于模板填写自己的 SLI 定义，再由 SRE 团队进行评审与对齐。这个过程通常需要 2-3 轮迭代才能达成一致。