1. SLO 与误差预算基础
在可靠性工程中，SLO（Service Level Objective，服务等级目标）与误差预算（Error Budget）是构建量化运营体系的两大基石。本章从定义出发，逐步拆解 SLI、SLO 与误差预算的内在逻辑，并说明为什么误差预算能改变传统“灭火式”运维模式。
1.1 SLI：衡量可靠性的量化指标
SLI（Service Level Indicator，服务等级指标）是直接反映服务质量的原始测量值。常见的 SLI 类型包括：
| SLI 类别 | 典型指标 | 测量方式 |
|---|---|---|
| 可用性 | 请求成功率、正常运行时间 | 成功请求数 / 总请求数 |
| 延迟 | P50、P95、P99 响应时间 | 从请求发出到收到完整响应的时间分布 |
| 吞吐量 | 每秒请求数（QPS）、带宽 | 单位时间内处理的请求量 |
| 错误率 | 5xx 占比、超时率 | 错误响应数 / 总响应数 |
| 饱和度 | CPU 使用率、内存占用、连接池水位 | 当前使用量 / 容量上限 |
选型建议：SLI 并非越多越好。每个服务应聚焦 2~3 个最能反映用户体验的核心指标，避免指标爆炸导致运维成本失控。
1.2 SLO：设定可靠性的目标边界
SLO（服务等级目标）是对 SLI 设定一个目标阈值，例如“99.9% 的请求在 200ms 内完成”。SLO 将抽象的“可靠性”转化为可衡量、可追踪的数值目标。
SLO 的典型表达格式：
SLI ≤ 阈值 或 SLI ≥ 阈值，在 [时间窗口] 内达到 [目标百分比]示例：
- 延迟 SLO：P99 延迟 ≤ 500ms，在 30 天滚动窗口内达到 99.9%
- 可用性 SLO：请求成功率 ≥ 99.95%，在 28 天滚动窗口内达到 99.9%
- 错误率 SLO：5xx 错误率 ≤ 0.1%，在 7 天滚动窗口内达到 99.5%
常见误区：SLO 不是“承诺”，而是“目标”。100% 的可靠性既不现实也不经济。合理的 SLO 应留出一定的容错空间，用于功能迭代和系统变更。
1.3 误差预算：可靠性的“信用额度”
误差预算（Error Budget） = 100% - SLO。它代表服务在 SLO 窗口内允许“不达标”的最大时间或请求比例。
例如：
- SLO = 99.9% → 误差预算 = 0.1%
- 在 30 天窗口内（共 43200 分钟），允许不可用时间 = 43200 × 0.1% = 43.2 分钟
误差预算的核心作用是将可靠性转化为一种可消耗的资源：
| 误差预算状态 | 含义 | 运营策略 |
|---|---|---|
| 充足（> 50%） | 服务可靠性表现良好，有大量容错空间 | 可进行风险较高的变更、发布新功能 |
| 中等（20% ~ 50%） | 可靠性处于正常波动范围 | 正常发布，但需关注趋势 |
| 紧张（< 20%） | 误差预算即将耗尽，可靠性风险升高 | 暂停非关键变更，优先稳定性投入 |
| 耗尽（0%） | 已违反 SLO，服务可靠性不达标 | 冻结所有变更，启动应急响应 |
关键认知：误差预算不是“失败指标”，而是“决策工具”。它让团队在创新速度与系统稳定性之间做出有数据支撑的权衡。
1.4 为什么需要误差预算？
传统运维模式下，团队往往陷入两个极端：要么追求 100% 可用性而不敢做任何变更，要么为了快速上线而忽视稳定性。误差预算提供了第三条路：
- 量化风险：将抽象的“可靠性风险”转化为具体的数字，让团队知道还剩多少“容错额度”。
- 对齐目标：开发团队与运维团队使用同一套指标沟通，避免“你觉得稳定，我觉得不稳定”的扯皮。
- 加速决策：误差预算充足时，团队可以大胆发布；预算紧张时，自动触发“质量门禁”，暂停高风险操作。
- 持续改进：通过跟踪误差预算消耗趋势，识别系统薄弱环节，指导容量规划和架构优化。
实践案例：某电商平台在“双十一”大促前，通过误差预算监控发现核心交易链路的预算消耗速度异常加快，提前定位到数据库连接池配置问题，避免了促销当天的服务降级。
1.5 SLI → SLO → 误差预算 关系图
下图展示了从原始指标到运营决策的完整链路：
1.6 误差预算消耗模型
下图展示误差预算在时间窗口内的动态消耗过程，以及不同阶段的应对策略：