📚 课程目录第1章 SLI基础概念

1. SLI 基础概念：定义、核心价值与原则

SLI（Service Level Indicator，服务等级指标）是衡量软件服务某一维度表现的可量化度量值。在 CI/CD 流水线语境下，SLI 将抽象的“流水线质量”转化为具体的数字，是后续 SLO 制定、错误预算计算和性能调优的基石。

SLI 是对服务某个特性（如可用性、延迟、吞吐量、错误率）的直接观测值。它回答“服务现在表现如何”的问题。例如：

关键区分：SLI 是原始测量值，SLO（Service Level Objective）是基于 SLI 设定的目标阈值。例如“P95 延迟 < 5 分钟”是 SLO，而“最近 1 小时 P95 延迟 = 3.2 分钟”是 SLI。

将 SLI 引入 CI/CD 流水线，能够实现从“凭感觉优化”到“数据驱动决策”的转变。其核心价值体现在以下四个维度：

价值维度	具体说明	流水线场景示例
可观测性	量化流水线各阶段健康状况，暴露瓶颈	构建阶段 P95 耗时从 8 分钟升至 15 分钟，触发告警
客观决策	用数据替代直觉，指导资源投入优先级	测试阶段失败率 12%，决定优先修复 flaky test 而非优化部署速度
故障定位	通过 SLI 趋势变化快速缩小根因范围	部署成功率 SLI 骤降，关联到新引入的镜像扫描步骤
持续改进	建立基线，衡量调优措施的实际效果	缓存优化后，构建 SLI 中位数从 6 分钟降至 4 分钟

定义有效的 CI/CD 流水线 SLI 需要遵循以下四项原则，避免指标泛滥或无法落地：

用户视角原则：SLI 应反映流水线使用者（开发人员、QA、SRE）的真实体验。例如“代码提交后多久能收到构建结果通知”比“构建服务器 CPU 使用率”更贴近用户价值。
可测量原则：指标必须能够被精确、一致地采集，且采集成本可控。避免定义“代码质量满意度”这类主观或无法自动采集的指标。
可行动原则：SLI 恶化时，团队应有明确的行动路径。如果“流水线总耗时”上升，团队能通过拆分阶段、增加并发或优化依赖来干预。
最小化原则：从少量关键指标开始（通常 3-5 个），避免指标爆炸。优先覆盖流水线的“黄金信号”：延迟、错误率、吞吐量。

  实践建议：在定义 SLI 时，先回答“如果这个指标变差，我们是否会立即采取行动？”如果答案是否定的，该指标很可能不适合作为 SLI。

以下表格列举了流水线各阶段常用的 SLI，以及对应的采集方式和典型目标：

流水线阶段	SLI 名称	定义口径	采集方式
代码提交	提交触发延迟	从 git push 到 webhook 被流水线接收的 P50 时间	Git 事件时间戳 vs 流水线入口日志
构建	构建成功率	成功完成的构建数 / 总触发构建数 × 100%	构建系统 API / 日志
单元测试	测试执行时间	所有测试用例从开始到结束的 P95 耗时	测试框架报告 + 时间戳
集成测试	环境就绪时间	从请求测试环境到环境状态为 Ready 的 P90 时间	环境管理平台事件日志
部署	部署回滚率	触发回滚的部署次数 / 总部署次数 × 100%	部署系统状态变更记录
全流水线	端到端交付时间	从代码合并到生产环境部署完成的 P95 时长	多系统时间戳关联

常见误区：不要将基础设施指标（如 CPU、内存）直接作为流水线 SLI。基础设施指标是“手段”，流水线 SLI 应关注“结果”。例如“构建服务器 CPU 使用率 90%”不是 SLI，“构建 P95 延迟 12 分钟”才是 SLI。

SLI 不是孤立存在的，它与 SLO、错误预算共同构成服务等级管理体系。三者关系如下：

SLI（指标）：实际观测到的数值，如“过去 7 天部署成功率为 99.2%”。
SLO（目标）：基于 SLI 设定的期望阈值，如“部署成功率 ≥ 99.5%”。
错误预算（Error Budget）：SLO 允许的容错空间，计算公式为 1 - SLO。例如 SLO 为 99.5%，则错误预算为 0.5%。当 SLI 消耗的错误预算接近上限时，团队应暂停新功能发布，优先提升可靠性。

  流水线场景示例：设定“构建成功率 SLO = 99.9%”，则每月错误预算为 0.1%（约 43 分钟）。如果某周构建失败率上升导致消耗了 30% 的错误预算，团队应立即排查失败根因，避免月底突破 SLO。