1. 课程导论：Error Budget 概念起源、SLO 与 SLI 基础、为什么需要容量规划
1.1 从“四个九”到 Error Budget：可靠性度量的一次范式转换
在传统运维时代，团队往往追求“尽可能高的可用性”，例如“99.99% 可用”（俗称四个九）。这种目标看似明确，却带来了两个致命问题：
- 目标模糊：99.99% 是年度目标还是月度目标？允许的停机时间是多少？
- 创新停滞：为了守住“四个九”，团队不敢发布新功能，因为任何变更都可能引入故障。
Google 在 SRE 实践中提出了 Error Budget（错误预算） 的概念，彻底改变了这一局面。其核心思想是：没有 100% 可靠的系统。既然故障不可避免，不如将“允许的不可用时间”量化成一个预算，让可靠性成为可管理、可消耗的资源。
核心公式：
Error Budget = 1 − SLO
例如：SLO = 99.9% → Error Budget = 0.1% 的时间（月度约 43 分钟）
Error Budget = 1 − SLO
例如：SLO = 99.9% → Error Budget = 0.1% 的时间（月度约 43 分钟）
Error Budget 的引入，使得可靠性不再是“越高越好”，而是“够用就好”。团队可以在预算范围内，大胆地进行发布、实验和迭代，只要不把预算耗尽。
1.2 SLI 与 SLO：构建 Error Budget 的基石
要计算 Error Budget，首先需要定义两个基础概念：SLI（Service Level Indicator，服务等级指标） 和 SLO（Service Level Objective，服务等级目标）。
| 概念 | 定义 | 示例 | 作用 |
|---|---|---|---|
| SLI | 服务质量的实际测量值，通常是一个比率 | 请求成功率 99.95% P99 延迟 200ms |
反映当前真实状态 |
| SLO | 服务质量的目标值，是 SLI 的阈值 | 请求成功率 ≥ 99.9% P99 延迟 ≤ 500ms |
定义“好”与“坏”的边界 |
| Error Budget | SLO 允许的不可用额度 | 1 − 99.9% = 0.1% | 管理风险与创新的预算 |
选择 SLI 的原则： 优先关注用户直接感知的指标。常见的四大黄金信号包括：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
1.3 为什么需要容量规划？—— Error Budget 消耗的视角
容量规划的传统目标是“保证系统不崩溃”。但在 Error Budget 框架下，容量规划有了新的意义：容量不足会直接消耗 Error Budget。
当系统容量不足时，通常表现为：
- 延迟升高：请求排队，P99 延迟突破 SLO 阈值。
- 错误率上升：超时、拒绝服务、连接池耗尽。
- 饱和度告警：CPU、内存、磁盘、网络带宽接近极限。
这些现象都会导致 SLI 下降，进而消耗 Error Budget。如果容量规划不到位，Error Budget 会快速耗尽，导致团队被迫停止发布，陷入“保稳定 vs 促创新”的两难境地。
⚠️ 常见误区： 很多团队将容量规划等同于“采购硬件”或“扩容机器”。实际上，容量规划的核心是 预测 Error Budget 的消耗速率，并在预算耗尽前完成扩容或优化。
1.4 课程核心：Error Budget 消耗模型与 SLO 台账
本课程将围绕一个核心方法展开：Error Budget 消耗模型驱动的容量规划。我们将不再依赖“拍脑袋”的扩容决策，而是通过建立 SLO 台账，实现以下目标：
- 量化容量状态：将容量不足转化为 Error Budget 消耗速率。
- 预测消耗趋势：基于历史数据预测未来预算消耗。
- 制定扩容策略：在预算耗尽前，自动或手动触发扩容动作。
- 优化成本：避免过度扩容，实现容量与成本的平衡。
课程产出： 一套可落地的 SLO 台账模板 和 Error Budget 消耗模型，可直接用于生产环境的容量规划。
在接下来的章节中，我们将从 SLI 的采集与 SLO 的定义开始，逐步深入到 Error Budget 的计算、消耗模型的建立，以及最终的容量规划决策。让我们开始这段从“被动救火”到“主动规划”的旅程。