error budget触发自愈剧本门禁 - 第1节
1.1 从 SLA 到 SLO：可靠性承诺的演进
在云原生与微服务架构中，服务可靠性不再是“尽力而为”的模糊承诺，而是需要被精确度量、持续追踪并主动管理的工程指标。传统 SLA（Service Level Agreement，服务等级协议）是面向客户的法律合同条款，而 SLO（Service Level Objective，服务等级目标）则是面向工程团队的内部可靠性靶心。
| 概念 | 定义 | 受众 | 典型粒度 |
|---|---|---|---|
| SLA | 服务提供商与客户之间的正式合同，包含违约赔偿条款 | 法务、商务、客户 | 月/季度 |
| SLO | 服务内部设定的可靠性目标，比 SLA 更严格 | 研发、SRE、运维 | 滚动窗口（28天/30天） |
| SLI | 服务可靠性的具体量化指标，是 SLO 的度量基础 | 技术团队 | 分钟级/请求级 |
工程铁律： 内部 SLO 必须比对外 SLA 更严格。例如 SLA 承诺 99.9%，内部 SLO 应设为 99.95%，预留缓冲空间，避免 SLA 违约风险。
1.2 SLI：可靠性的量化基石
SLI（Service Level Indicator，服务等级指标）是对服务质量的某个维度进行原始测量的数值。常见的 SLI 类型包括：
- 可用性 SLI：成功请求数 / 总请求数 × 100%
- 延迟 SLI：满足阈值（如 p99 ≤ 200ms）的请求占比
- 吞吐量 SLI：每秒成功处理的请求数（RPS）
- 错误率 SLI：返回 HTTP 5xx 或业务错误码的请求占比
- 饱和度 SLI：资源使用率（CPU/内存/连接池）
SLI 定义黄金法则： 每个 SLI 必须明确三个要素——测量窗口（如 1 分钟）、良好条件（如 p99 延迟 < 200ms）、聚合方式（如滑动窗口平均）。缺少任一要素的 SLI 都无法用于 SLO 计算。
1.3 SLO：可靠性的工程靶心
SLO 是对 SLI 设定目标阈值，例如“过去 28 天内，99.9% 的请求延迟低于 200ms”。SLO 的设定需要平衡用户体验与工程成本：
| SLO 等级 | 可用性目标 | 年度最大不可用时间 | 典型适用场景 |
|---|---|---|---|
| 基础 | 99.9%（三个九） | 8.76 小时 | 内部工具、开发环境 |
| 标准 | 99.95%（三个九半） | 4.38 小时 | 核心业务 API、支付系统 |
| 高可用 | 99.99%（四个九） | 52.56 分钟 | 实时交易、在线游戏 |
| 极致 | 99.999%（五个九） | 5.26 分钟 | 电信核心网、金融清算 |
常见误区： 不要为所有服务设置统一的 SLO。不同服务对可靠性的敏感度不同，统一 SLO 会导致成本浪费或保护不足。建议按服务关键度分级设置差异化 SLO。
1.4 Error Budget：可靠性与创新速度的调节阀
Error Budget（错误预算）是 SLO 的衍生概念，定义为 1 − SLO。例如 SLO 为 99.9%，则 Error Budget 为 0.1%。它代表服务在 SLO 窗口内允许发生故障的最大时间或请求比例。
Error Budget 的核心价值在于：
- 量化容错空间：将抽象的“允许故障”转化为可追踪的数值
- 决策依据：Error Budget 充足时，团队可以大胆发布新功能；不足时，应冻结发布并优先修复稳定性
- 消除对立：避免开发团队与 SRE 团队在“能否发布”上无休止争论，用数据说话
# Error Budget 计算示例（基于请求数）
SLO = 99.9%
总请求数（28天滚动窗口） = 10,000,000
允许失败请求数 = 10,000,000 × (1 - 0.999) = 10,000
当前失败请求数 = 6,500
剩余 Error Budget = 10,000 - 6,500 = 3,500（占比 35%）
状态：✅ 充足，可正常发布
实战经验： Error Budget 建议使用滚动窗口（如 28 天或 30 天）而非固定日历月。滚动窗口能平滑处理突发流量和节假日效应，避免月初重置导致的风险盲区。
1.5 三者的核心关系：SLI → SLO → Error Budget
SLI、SLO、Error Budget 构成了可靠性工程的闭环度量体系：
1.6 Error Budget 在可靠性工程中的核心地位
Error Budget 不仅是度量工具，更是 SRE 实践中的决策中枢。它将可靠性从“被动救火”转变为“主动管理”：
| 场景 | 无 Error Budget 时 | 有 Error Budget 时 |
|---|---|---|
| 新功能发布决策 | 靠“感觉”或“领导拍板” | Error Budget 剩余量决定是否允许发布 |
| 故障响应优先级 | 所有故障都紧急，资源分散 | 仅消耗 Error Budget 的故障需要立即响应 |
| 团队协作 | 开发 vs SRE 对立，互相指责 | 共同关注 Error Budget，目标一致 |
| 容量规划 | 凭经验估算，容易过度或不足 | Error Budget 消耗趋势指导扩容决策 |
| 自愈触发 | 人工判断是否执行自愈流程 | Error Budget 阈值自动触发自愈剧本 |
本课程核心： 当 Error Budget 消耗超过预设阈值时，自动触发自愈剧本（Self-Healing Playbook），实现故障的自动发现 → 自动诊断 → 自动恢复 → 自动验证闭环，将 MTTR（平均修复时间）从小时级压缩到分钟级。
1.7 本章小结：可靠性工程的三驾马车
- SLI 是度量——回答“我们测量什么？”
- SLO 是目标——回答“我们想要多可靠？”
- Error Budget 是决策——回答“我们还有多少容错空间？”