📚 课程目录第2章预算编制基础

2. SLO 与预算基础：SLO 定义、SLI 与 SLA 的关系、错误预算概念、预算消耗机制

2.1 核心概念速览

在开始复核 RBAC 系统的 SLO 预算之前，必须统一对以下四个基础术语的理解。它们构成了整个可靠性工程的度量基石。

术语	英文全称	一句话定义	面向对象
SLI	Service Level Indicator	服务质量的原始度量指标（如：请求延迟 P99、错误率）	技术团队
SLO	Service Level Objective	SLI 的目标阈值（如：P99 延迟 ≤ 200ms，99.9% 的请求）	技术团队 + 产品
SLA	Service Level Agreement	对客户的法律承诺（如：月度可用性 ≥ 99.9%，否则赔偿）	法务 + 客户
错误预算	Error Budget	SLO 允许的最大不可用额度（1 - SLO）	SRE 团队

关键原则：SLA 必须比 SLO 更宽松（SLA ≤ SLO）。内部 SLO 是防守线，外部 SLA 是底线。错误预算则是 SRE 团队进行风险决策的“货币”。

2.2 SLI 与 SLA 的关系：从度量到承诺

SLI 是原始数据，SLO 是内部目标，SLA 是外部契约。三者构成一个从技术到商业的传递链。

2.3 错误预算概念

错误预算 = 1 - SLO。它量化了服务在 SLO 范围内允许“犯错”的总时间或总请求量。

计算示例：若 SLO 为 99.9%（月度），则月度错误预算 = 30 天 × 24 小时 × 60 分钟 × (1 - 0.999) ≈ 43.2 分钟。这 43.2 分钟是团队可以用于发布、升级、实验的“风险额度”。

错误预算的三大核心作用：

风险量化：将不可靠性转化为可管理的数字，避免主观判断。
发布决策：预算充足 → 可以加速发布；预算耗尽 → 冻结变更，专注稳定性。
团队对齐：让开发、运维、产品在同一个数字框架下讨论风险。

2.4 预算消耗机制

错误预算的消耗不是线性的，而是基于 SLI 的实际表现。以下是一个典型的消耗与恢复模型。

2.5 预算消耗的数学表达

对于 RBAC 系统，我们通常使用滑动窗口计算错误预算消耗。以下是一个基于请求量的简化模型：

# 错误预算消耗计算（伪代码）
slo_target = 0.999  # 99.9%
window_seconds = 30 * 24 * 3600  # 30天滑动窗口
total_requests = get_total_requests(window_seconds)
bad_requests = get_bad_requests(window_seconds)  # 违反 SLI 的请求

# 当前可用性
current_availability = 1 - (bad_requests / total_requests)

# 错误预算剩余
error_budget_remaining = 1 - (bad_requests / (total_requests * (1 - slo_target)))

# 消耗百分比
consumption_percent = (1 - error_budget_remaining) * 100

print(f"当前可用性: {current_availability:.4%}")
print(f"错误预算剩余: {error_budget_remaining:.2%}")
print(f"已消耗预算: {consumption_percent:.1f}%")

2.6 预算消耗的典型场景

场景	消耗速率	典型原因	SRE 响应
正常运营	缓慢线性消耗	偶发延迟抖动、少量超时	无需干预
部分故障	快速消耗	数据库慢查询、网络分区	启动应急响应
完全故障	瞬间耗尽	服务宕机、权限系统崩溃	立即回滚 / 切换
预算恢复	负消耗（恢复）	故障修复后，窗口滑动移出坏记录	复盘 + 改进

RBAC 系统特别提醒：权限变更、策略同步、令牌验证等关键路径的 SLI 必须单独监控。一次错误的权限下发可能导致大量 403/401 错误，瞬间消耗错误预算，且难以通过常规健康检查发现。

2.7 预算消耗的决策阈值

在实际 SRE 运营中，我们通常设置三个预算水位线来触发不同级别的响应：

绿色区（预算 > 50%）：正常运营，允许常规发布和变更。
黄色区（20% ≤ 预算 ≤ 50%）：谨慎模式，变更需要审批，禁止高风险操作。
红色区（预算 < 20%）：冻结模式，仅允许紧急修复，全员聚焦稳定性。