4、误差预算台账设计原则：台账的四大核心字段与版本控制
误差预算台账是SRE团队从“被动救火”转向“数据驱动决策”的核心载体。一份设计良好的台账，必须同时满足可观测性（一眼看清当前风险）和可审计性（追溯历史变更与决策依据）。本章聚焦台账的四大核心字段定义、字段间的计算关系，以及版本控制与审计的工程落地方法。
4.1 台账的四大核心字段
任何误差预算台账都必须包含以下四个字段，缺一不可。它们共同构成了“定义→测量→消耗→剩余”的闭环。
| 字段名称 | 英文缩写 | 定义与作用 | 示例值 |
|---|---|---|---|
| 服务等级指标 | SLI | 衡量服务质量的具体指标，通常是“好事件/总事件”的比率。它是台账的测量源头。 | 请求成功率：99.95% |
| 服务等级目标 | SLO | SLI的目标阈值，定义了“什么是可接受的服务质量”。它是台账的基准线。 | 99.9%（滚动30天窗口） |
| 预算消耗 | Budget Burn | 在SLO窗口内，实际SLI低于SLO的累计“不合格时间”或“不合格事件数”。它是台账的风险计数器。 | 0.05%（过去7天累计） |
| 剩余预算 | Remaining Budget | SLO窗口内剩余的、可容忍的故障额度。计算公式：剩余预算 = SLO窗口总预算 - 预算消耗。它是台账的决策触发器。 |
0.05%（剩余50%） |
工程落地要点： 四个字段必须使用同一时间窗口（如滚动30天）。如果SLI使用1分钟粒度，SLO使用30天窗口，预算消耗必须按分钟累计到30天窗口内，避免“口径不一致”导致台账失真。
4.2 四大字段的关联关系与计算逻辑
四个字段不是孤立的，它们通过以下公式形成动态关联：
# 核心计算公式
SLO窗口总预算 = 1 - SLO目标值
预算消耗 = 窗口内所有SLI < SLO的偏差累计
剩余预算 = SLO窗口总预算 - 预算消耗
# 示例：SLO = 99.9%，窗口总预算 = 0.1%
# 若过去30天累计消耗了0.04%的预算
# 剩余预算 = 0.1% - 0.04% = 0.06%（剩余60%）下图展示了四个字段在台账中的流转关系与决策链路：
关键认知： 剩余预算不是“剩余时间”，而是“剩余故障额度”。当剩余预算趋近于0时，意味着服务已经接近违反SLO，必须立即采取降速、回滚或扩容等干预措施。
4.3 台账的版本控制与审计
误差预算台账是SRE团队的“服务健康档案”，必须像代码一样进行版本管理。任何对SLI定义、SLO阈值、窗口周期的修改，都必须留下审计痕迹。
4.3.1 版本控制的三大场景
- SLI定义变更： 例如从“请求成功率”改为“有效请求成功率”（排除爬虫）。变更后，历史预算消耗需要重新计算或标记为“旧版口径”。
- SLO阈值调整： 例如从99.9%提升到99.95%。调整后，剩余预算会瞬间“缩水”，需要记录变更原因与审批人。
- 窗口周期修改： 例如从固定30天改为滚动28天。窗口变化会导致预算消耗的累计速度发生变化，必须审计。
4.3.2 审计日志的核心字段
| 字段 | 说明 | 示例 |
|---|---|---|
| 变更ID | 全局唯一标识 | CHG-20240521-001 |
| 变更时间 | 精确到毫秒的时间戳 | 2024-05-21T14:30:00.000Z |
| 变更人 | 执行变更的工程师或系统 | zhangsan@company.com |
| 变更类型 | SLI/SLO/窗口/计算逻辑 | SLO阈值调整 |
| 变更前值 | 变更前的完整配置快照 | SLO: 99.9% |
| 变更后值 | 变更后的完整配置快照 | SLO: 99.95% |
| 审批人 | 变更审批链 | liwei@company.com (Tech Lead) |
| 变更原因 | Jira/工单链接或文字说明 | PROJ-1234: 提升核心API可用性目标 |
4.3.3 版本控制工程实践
推荐使用Git + YAML作为台账的版本控制基础设施。每个SLO条目对应一个YAML文件，变更通过Pull Request提交，CI流水线自动校验格式并生成审计日志。
# 示例：slo-payment-service.yaml
version: "2.0"
metadata:
service: payment-service
owner: team-payment
last_modified: 2024-05-21T14:30:00Z
spec:
sli:
metric: "http_requests_total{status=~\"2xx|3xx\"} / http_requests_total"
measurement_window: "1m"
slo:
target: 0.9995
window: "rolling_30d"
burn_rate_alerts:
- level: warning
threshold: 0.2 # 剩余预算 < 20%
- level: critical
threshold: 0.1 # 剩余预算 < 10%
budget:
total: 0.0005
consumed: 0.0002
remaining: 0.0003
last_updated: 2024-05-21T14:30:00Z
避坑指南： 不要将“预算消耗”和“剩余预算”直接写入YAML文件作为静态值。它们应该由监控系统实时计算并写入数据库，YAML只保存SLI/SLO定义和版本历史。否则，每次PR都会导致预算数据冲突。
4.4 台账版本控制与审计的架构
下图展示了台账版本控制与审计的工程架构，从变更触发到审计归档的完整链路：
工程落地建议： 审计数据库建议使用不可变日志存储（如EventStore或Kafka + 对象存储），确保历史记录无法被篡改。每次变更都生成一个完整的配置快照，方便回溯任意时间点的台账状态。
4.5 本章小结
- 四大核心字段（SLI、SLO、预算消耗、剩余预算）构成了误差预算台账的骨架，缺一不可。
- 计算关系必须基于同一时间窗口，剩余预算 = 总预算 - 累计消耗，是决策的核心依据。
- 版本控制通过Git + YAML实现，每次变更必须记录变更ID、时间、人、前后值、审批人和原因。
- 审计架构采用“变更触发 → Git仓库 → CI校验 → 审计数据库”的链路，确保台账的完整性和可追溯性。