1. 课程导论：为什么需要SLO误差预算台账？
1.1 从“可用性神话”到“可靠性工程”的范式转变
传统运维团队往往追求“五个九”（99.999%）的可用性，但这种追求在微服务、分布式架构下逐渐失效：
- 成本失控：每增加一个“9”的可用性，基础设施成本可能翻倍。
- 创新停滞：过度保守的变更策略导致功能交付周期拉长。
- 指标失真：整体可用性99.9%无法反映单个用户请求的失败体验。
Google SRE 体系引入 服务等级目标（SLO） 与 误差预算（Error Budget） 的概念，将可靠性从“指标”转化为“可管理的风险预算”。误差预算 = 1 - SLO，例如 SLO 为 99.9% 时，每月误差预算约为 43 分钟。这 43 分钟是团队可以“消耗”的不可用时间，用于发布、实验或重构。
核心洞察： 误差预算不是失败的记录，而是创新的燃料。它让可靠性从“运维约束”变为“工程决策的量化依据”。
1.2 为什么需要SLO误差预算台账？
在大型组织中，仅定义 SLO 远远不够。多个服务、多个团队、多个季度迭代会产生大量 SLO 数据，如果没有统一的 台账（Ledger） 管理，会出现以下问题：
| 痛点 | 表现 | 后果 |
|---|---|---|
| SLO 碎片化 | 不同团队用不同工具（Grafana、Datadog、自建平台）定义 SLO，口径不统一 | 跨服务依赖分析困难，故障定责扯皮 |
| 误差预算不可追溯 | 只知道当前预算剩余，不知道过去一个月预算消耗在哪些变更或故障上 | 无法复盘改进，重复踩坑 |
| 评审缺乏数据支撑 | 可靠性评审会变成“感觉汇报”，而非“数据驱动” | 决策主观，优化优先级混乱 |
| 迭代优化无闭环 | 调整 SLO 后没有记录变更原因和效果 | SLO 逐渐偏离业务真实需求 |
SLO 误差预算台账 正是为了解决上述问题而设计的结构化记录系统。它不仅是数据的存储，更是可靠性治理的“单一事实源”。
1.3 可靠性评审与台账的关系
可靠性评审（Reliability Review）是 SRE 团队定期（通常每两周或每月）举行的复盘与规划会议。台账在评审中扮演三个关键角色：
- 输入层：台账提供过去周期内每个服务的 SLO 达成率、误差预算消耗速率、主要故障事件列表。
- 决策层：基于台账数据，评审团队决定是否允许高风险变更、是否需要申请额外误差预算、是否调整 SLO 目标。
- 输出层：评审结论（如“暂停发布”、“增加冗余”、“降低 SLO”）被写回台账，形成迭代记录。
1.4 课程目标与受众
课程目标
完成本课程后，学员将能够：
- 设计并搭建一套适用于多服务、多团队的 SLO 误差预算台账结构。
- 驱动可靠性评审，使评审从“汇报会”转变为“数据驱动的决策会”。
- 实施迭代优化流程，通过台账记录-评审-调整的闭环持续提升系统可靠性。
- 量化可靠性投资回报，用误差预算数据向管理层证明可靠性投入的价值。
目标受众
| 角色 | 痛点 | 课程收益 |
|---|---|---|
| SRE / 运维工程师 | 缺乏系统化的 SLO 管理方法，评审效率低 | 掌握台账设计、评审流程、迭代优化技巧 |
| DevOps 教练 | 团队对可靠性指标理解不一致，难以推动改进 | 获得可落地的评审框架和台账模板 |
| 技术管理者 / 架构师 | 无法量化可靠性对业务的影响，预算分配凭感觉 | 学会用误差预算数据做资源投入决策 |
| QA / 测试负责人 | 发布门禁缺乏量化标准，测试范围难以界定 | 理解如何将 SLO 误差预算融入发布流水线 |
课前准备建议： 如果你所在团队尚未定义任何 SLO，建议先阅读 Google SRE 白皮书中关于“服务等级指标（SLI）”和“服务等级目标（SLO）”的基础章节。本课程将在此基础上直接进入台账与评审的实战环节。
1.5 课程内容全景图
本课程共分为 6 个模块，从台账设计到评审落地，再到持续迭代，形成完整知识体系：
本课程不要求学员具备 SRE 实战经验，但建议对以下概念有基本了解：
- 服务等级指标（SLI）与服务等级目标（SLO）的基本定义
- 常见的监控与可观测性工具（如 Prometheus、Grafana、Datadog）
- 基本的 DevOps 与持续交付流程
⚠️ 常见误区提醒： 不要试图在课程初期就追求“完美台账”。台账是迭代出来的，不是设计出来的。本课程将引导你从最小可行台账（MVL）开始，逐步演进。