GitOps交付SLO错误预算监测与复盘 - 第1节
1.1 从服务等级到可靠性度量：SLA、SLI、SLO
在开始 SLO 预算复核之前，必须先厘清三个核心术语：SLA（Service Level Agreement，服务等级协议）、SLI（Service Level Indicator，服务等级指标）和 SLO（Service Level Objective，服务等级目标）。它们是现代站点可靠性工程（SRE）的基石，也是 GitOps 驱动预算复核的输入数据源。
1.1.1 三者的定义与定位
| 术语 | 全称 | 核心定义 | 典型场景 |
|---|---|---|---|
| SLA | Service Level Agreement | 服务提供商与客户之间的法律/合同承诺，包含违约处罚条款。 | 云厂商承诺 99.99% 可用性，未达标则退还月度费用。 |
| SLI | Service Level Indicator | 对服务质量的原始量化测量，通常是比率、延迟或错误计数。 | 请求成功率 99.95%、P99 延迟 200ms。 |
| SLO | Service Level Objective | 团队内部设定的目标阈值，SLI 必须在此范围内才算健康。 | 月度 SLI ≥ 99.95% 为达标，低于 99.9% 触发告警。 |
关键认知：SLA 是商业合同，SLO 是工程目标，SLI 是原始数据。SRE 实践的核心是定义好的 SLO，而不是直接追逐 SLA。SLA 通常比 SLO 宽松（例如 SLA 为 99.9%，内部 SLO 设为 99.95%），为违约风险留出缓冲。
1.1.2 三者关系：从数据到承诺的链路
下图展示了从原始指标到商业承诺的完整链路：
实践要点：在 GitOps 工作流中，SLI 数据通常由 Prometheus / Thanos 等监控系统采集，SLO 配置以 YAML 形式存储在 Git 仓库中，SLA 条款则记录在合同管理系统。SLO 预算复核的本质是：对比当前 SLI 与 SLO 阈值的差距，计算剩余错误预算，并决定是否触发部署门禁或回滚。
1.2 为什么需要 SLO 预算？
SLO 预算（Error Budget，错误预算）是 SRE 中最具工程实践价值的概念。它将抽象的可靠性目标转化为可量化的“容错额度”，让团队在发布速度与系统稳定性之间做出理性决策。
1.2.1 错误预算的定义
错误预算 = 1 − SLO。例如：
- SLO = 99.9% → 错误预算 = 0.1%（月度允许的不可用时间约 43 分钟）
- SLO = 99.99% → 错误预算 = 0.01%（月度允许的不可用时间约 4.3 分钟）
错误预算消耗完之前，团队可以自由发布新功能；一旦预算耗尽，必须暂停发布并优先修复可靠性问题。
1.2.2 错误预算的三大价值
| 价值维度 | 说明 | GitOps 场景示例 |
|---|---|---|
| 消除对立 | 不再有“开发 vs 运维”的零和博弈，双方共享同一个预算池。 | CI/CD 流水线中根据预算剩余自动决定是否允许合并 PR。 |
| 量化风险 | 每次发布前可以评估“这次变更会消耗多少预算”。 | GitOps 控制器在 Apply 前检查预算水位，低于阈值则拒绝同步。 |
| 驱动改进 | 预算快速耗尽说明系统存在根本性缺陷，需要架构优化。 | 预算消耗趋势图作为 Git 仓库中的可观测性 Dashboard 配置。 |
1.2.3 错误预算的生命周期
下图展示了一个典型的月度错误预算消耗与复核流程：
常见误区：错误预算不是“可用时间”，而是“允许失败的时间”。如果系统在月初就因重大故障耗尽预算，团队不应继续发布新功能，而应优先进行根因分析和架构加固。GitOps 的自动化门禁可以强制实施这一策略——当预算低于阈值时，ArgoCD 或 Flux 的同步操作会被自动拒绝。
1.3 SLO 预算与 GitOps 的天然契合
GitOps 的核心原则是“以 Git 仓库作为单一事实来源”，而 SLO 预算的配置、状态和复核结果同样可以（也应该）存储在 Git 中。这种结合带来了以下优势：
- 声明式 SLO 配置：SLO 阈值、预算窗口、告警规则全部以 YAML 形式管理，可审计、可回滚。
- 自动化预算复核：CI/CD 流水线在每次部署前自动计算当前预算消耗，决定是否放行。
- 可追溯的决策记录：每次预算复核的结果（通过/拒绝）都作为 Git 提交记录留存。