3. SLA 基础概念：SLA / SLO / SLI 的定义与发布工程关键指标
在发布工程中，SLA（服务等级协议）是保障发布频率与系统稳定性的核心契约。要真正落地 SLA，必须先理解其底层三要素：SLI（服务等级指标）、SLO（服务等级目标）和SLA（服务等级协议）。这三者构成了从测量到承诺的完整链路。
3.1 SLA / SLO / SLI 定义与关系
| 术语 | 定义 | 发布工程示例 |
|---|---|---|
| SLI | 实际测量的服务性能指标，是原始数据 | 部署时长、回滚耗时、错误率 |
| SLO | 团队内部设定的目标阈值，是承诺的边界 | 部署时长 ≤ 15 分钟（月度 99.9%） |
| SLA | 对外部客户或上下游的正式协议，含惩罚条款 | 月度可用性 ≥ 99.95%，否则赔付 |
核心原则：SLO 必须比 SLA 更严格（通常 SLO 比 SLA 严格 1~2 个数量级），为 SLA 留出安全缓冲。例如 SLA 要求 99.9% 可用性，SLO 应设为 99.95%。
下图展示了 SLI → SLO → SLA 的逐层收敛关系：
3.2 发布工程中的关键 SLA 指标
发布工程 SLA 不能只关注系统可用性，必须覆盖发布全生命周期的可观测性与可靠性。以下三个指标是发布自助门户最核心的 SLA 维度：
3.2.1 可用性（Availability）
- 定义：发布系统或目标服务在约定时间窗口内正常响应请求的时间占比。
- 计算公式：
可用性 = (总时间 - 不可用时间) / 总时间 × 100% - 发布工程关注点：发布期间是否导致服务降级、蓝绿切换时的流量中断窗口、金丝雀发布时的错误率阈值。
3.2.2 部署时长（Deployment Duration）
- 定义：从触发部署到所有实例完成更新并健康运行的总耗时。
- 计算公式：
部署时长 = 部署完成时间戳 - 部署触发时间戳 - 发布工程关注点：流水线各阶段耗时（构建、镜像推送、滚动更新、健康检查）、回滚触发后的恢复时长。
3.2.3 回滚成功率（Rollback Success Rate）
- 定义：在指定时间窗口内，回滚操作成功恢复到上一稳定版本的比例。
- 计算公式：
回滚成功率 = 成功回滚次数 / 总回滚尝试次数 × 100% - 发布工程关注点：回滚脚本的健壮性、数据库迁移的回滚兼容性、配置版本一致性。
实践建议：在自助门户中，将这三个指标作为默认仪表盘的首屏卡片，并设置 SLO 告警线。例如：可用性 SLO = 99.95%，部署时长 SLO = 15 分钟，回滚成功率 SLO = 99.9%。
3.3 发布工程 SLA 指标对比矩阵
| 指标 | 测量单位 | 典型 SLO | 影响发布频率的因素 |
|---|---|---|---|
| 可用性 | 百分比（%） | ≥ 99.95% | 发布窗口限制、蓝绿切换耗时、健康检查延迟 |
| 部署时长 | 分钟（min） | ≤ 15 min | 构建速度、镜像大小、实例数、滚动更新策略 |
| 回滚成功率 | 百分比（%） | ≥ 99.9% | 回滚脚本覆盖率、数据库迁移兼容性、配置版本管理 |
3.4 SLA 指标在发布自助门户中的落地流程
下图展示了从 SLI 采集到 SLA 报告的全链路：
常见误区：不要将 SLA 仅视为运维指标。发布工程 SLA 必须与开发团队的部署频率、回滚能力、测试覆盖率联动。如果 SLA 只由 SRE 团队背责，而开发团队不参与 SLO 设定，发布频率调优将无法落地。
3.5 发布工程 SLA 设定最佳实践
- 从 SLI 开始：先确保可测量，再设定目标。没有 Prometheus 或等效监控，不要空谈 SLO。
- SLO 要留余量：内部 SLO 比外部 SLA 严格 1~2 个数量级，避免 SLA 违约。
- 指标要可行动：每个 SLA 指标必须对应一个可执行的调优动作（如：部署时长超标 → 自动增加并行度或优化镜像层）。
- 定期复盘：每季度审查 SLA 达成率，调整 SLO 阈值以适应业务增长或架构变更。