1. 课程导论：为什么需要 Error Budget 驱动的数据库可靠性设计？变更窗口与 SLO/SLI 的关系
1.1 传统变更窗口的困境
在传统数据库运维中，变更窗口（Change Window）是唯一被允许执行 DDL、配置修改、索引重建或版本升级的时间段。这种“定时炸弹”式的操作模式存在三个根本性缺陷：
- 风险集中：所有变更被压缩到凌晨 2:00-4:00 的固定窗口，一旦失败，恢复时间与影响面成倍放大。
- 无量化标准：变更是否“安全”完全依赖 DBA 个人经验，缺乏客观的可靠性度量。
- 业务与运维对立：业务方要求 7×24 可用，运维方需要变更窗口，双方在“什么时候能改”上持续博弈。
核心矛盾：传统变更窗口本质上是“赌窗口内不出错”，而 Error Budget 将可靠性从“感觉”转化为“可计算的预算”。
1.2 从 SLO 到 Error Budget：可靠性的货币化
Service Level Objective（SLO）是数据库服务承诺的可靠性目标，例如“月度可用性 ≥ 99.95%”。Error Budget 则是 SLO 允许的最大不可用时间：
| SLO（月度） | 允许不可用时间（30 天） | Error Budget |
|---|---|---|
| 99.9% | 43.2 分钟 | 43.2 分钟 |
| 99.95% | 21.6 分钟 | 21.6 分钟 |
| 99.99% | 4.32 分钟 | 4.32 分钟 |
Error Budget 的核心思想：只要预算未耗尽，变更就是“免费”的。这从根本上改变了变更窗口的决策逻辑——不再由时钟决定，而是由剩余预算决定。
1.3 SLI、SLO 与变更窗口的三角关系
Service Level Indicator（SLI）是数据库可靠性的具体度量指标，常见的数据库 SLI 包括：
- 可用性 SLI：查询成功率（如 SELECT 错误率 < 0.1%）
- 延迟 SLI：P99 延迟 < 200ms
- 持久性 SLI：已提交事务不丢失率 = 100%
- 吞吐 SLI：每秒事务数（TPS）不低于基线 80%
三者的关系可以概括为：SLI 是测量仪，SLO 是刻度线，Error Budget 是剩余可用空间，变更窗口是消耗预算的操作。
1.4 Error Budget 驱动的变更窗口模型
引入 Error Budget 后，变更窗口不再是固定的“时间段”，而是动态的“预算阈值”。决策流程如下：
- 持续测量 SLI：实时采集数据库可用性、延迟、错误率等指标。
- 计算消耗速率：将 SLI 与 SLO 对比，计算当前周期已消耗的 Error Budget。
- 评估变更风险：对计划中的变更进行风险评分（如高风险 DDL 扣减 5 分钟预算）。
- 预算检查：若“剩余预算 > 变更风险预估”，则允许在任意时间执行变更；否则冻结变更。
- 预算耗尽响应：当 Error Budget 耗尽时，自动触发“变更冻结”与“可靠性恢复行动”。
实践要点：Error Budget 不是“用完就罚”，而是“用完就停”。它让团队在可靠性下降时自动减速，避免雪崩效应。
1.5 为什么数据库需要 Error Budget？
相比无状态微服务，数据库的 Error Budget 设计更具挑战性，原因如下：
| 维度 | 无状态服务 | 数据库（有状态服务） |
|---|---|---|
| 状态影响 | 重启即恢复，无数据残留 | 数据持久性、一致性不可逆 |
| 变更风险 | 灰度发布可快速回滚 | DDL 可能阻塞读写，回滚困难 |
| SLI 敏感度 | 延迟增加影响用户体验 | 延迟增加可能导致连接池耗尽、雪崩 |
| Error Budget 粒度 | 通常按服务维度聚合 | 需按实例、分片、甚至表维度拆分 |
常见误区：不要将数据库 Error Budget 设置得过于宽松（如 99% SLO），否则变更窗口几乎永远开放，失去风险控制意义。建议从 99.95% 起步，根据实际故障频率逐步调整。
1.6 课程核心收益
通过本课程，你将掌握以下能力：
- 设计数据库专属 SLI 指标体系：涵盖可用性、延迟、持久性、一致性等维度。
- 制定合理的 SLO 与 Error Budget：平衡业务需求与运维风险。
- 构建 Error Budget 驱动的变更流水线：实现自动化预算检查、变更审批与冻结。
- 建立可靠性反馈闭环：通过 Error Budget 消耗趋势，持续优化数据库架构与运维策略。