1. SLO 与误差预算基础
1.1 什么是 SLO（Service Level Objective）
SLO（服务等级目标）是衡量服务可靠性的核心量化指标，它定义了在特定时间窗口内，服务必须达到的可用性或性能水平。在 Kubernetes 集群运维中，SLO 将抽象的“稳定”转化为可度量、可追踪的数字。
| 概念 | 定义 | Kubernetes 场景示例 |
|---|---|---|
| SLI（服务等级指标） | 实际测量的原始指标 | API Server 请求延迟 P99、Pod 就绪率 |
| SLO（服务等级目标） | SLI 的目标阈值 + 时间窗口 | API Server P99 延迟 ≤ 200ms，30 天内 99.9% 达标 |
| SLA（服务等级协议） | 对外的承诺，通常附带惩罚 | 客户合同约定 99.95% 可用性 |
关键区别：SLO 是内部工程目标，SLA 是外部商业承诺。SLO 通常比 SLA 更严格（例如内部 SLO 为 99.99%，对外 SLA 为 99.95%），为故障留出缓冲空间。
1.2 误差预算（Error Budget）概念
误差预算 = 100% - SLO。它表示服务在 SLO 时间窗口内允许发生故障的总时间或总错误量。例如：
- SLO = 99.9% → 误差预算 = 0.1%
- 30 天窗口 → 允许不可用时间 = 30 × 24 × 60 × 0.1% = 43.2 分钟
- 季度窗口（90 天） → 允许不可用时间 = 90 × 24 × 60 × 0.1% = 129.6 分钟
核心思想：误差预算不是“失败配额”，而是“创新预算”。只要误差预算充足，团队可以放心部署新版本、进行集群升级；一旦预算耗尽，必须暂停变更，优先恢复可靠性。
1.3 为什么需要误差预算台账
误差预算台账（Error Budget Ledger）是对误差预算消耗情况的持续记录与可视化。在 Kubernetes 集群环境中，台账解决了三个核心问题：
- 量化决策依据：避免“感觉集群不稳定”的主观判断，用数据决定是否允许变更上线。
- 故障成本可视化：每次 Pod 重启、节点故障、API 超时都会消耗预算，台账让团队看到故障的累积影响。
- 对齐业务与运维：业务方关注功能交付，SRE 关注稳定性，台账提供了双方都能理解的“可靠性货币”。
| 场景 | 无台账时 | 有台账时 |
|---|---|---|
| 版本发布决策 | 依赖个人经验判断“是否稳定” | 查看预算剩余，剩余 > 50% 可发布 |
| 故障复盘 | 仅关注故障本身影响 | 量化该故障消耗了多少预算 |
| 容量规划 | 凭感觉扩容 | 根据预算消耗趋势预测扩容时机 |
| 团队绩效考核 | 用“不出故障”衡量 | 用“预算消耗率”衡量可靠性投入产出 |
常见误区：误差预算台账不是“追责工具”。它的目的是让团队在可靠性与创新速度之间做出有数据支撑的权衡，而不是在故障发生后寻找责任人。
1.4 台账的核心构成要素
一个完整的误差预算台账至少包含以下字段：
- 时间窗口：滚动窗口（如 30 天）或固定窗口（如自然月）
- SLO 目标：例如 99.9%、99.99%
- 总预算：窗口内允许的最大故障时间或错误次数
- 已消耗预算：当前窗口内累计的故障时间或错误次数
- 剩余预算：总预算 - 已消耗预算
- 消耗速率：每日/每小时的平均消耗量，用于预测何时耗尽
- 预算状态：充足（> 50%）、警告（20% - 50%）、危险（< 20%）、耗尽（0%）
1.5 本章小结
- SLO 是可靠性目标，误差预算 是允许的故障空间，台账 是预算的记账本。
- 误差预算 = 100% - SLO，时间窗口越长，预算越大。
- 台账让可靠性决策从“凭感觉”变为“看数据”，是 SRE 实践的基础设施。
- 在 Kubernetes 集群中，台账需要从 API Server、etcd、节点、Pod 等多个维度采集 SLI 并持续计算。