4. SLO 目标设定：基于历史数据与业务需求设定合理的 SLO 目标
SLO（Service Level Objective）是服务等级目标，它定义了系统在特定时间窗口内应达到的可靠性水平。设定合理的 SLO 是构建告警自愈闭环的基石——没有明确的目标，燃烧率与错误预算便无从谈起，告警阈值也将失去依据。
4.1 SLO 设定的核心输入：历史数据与业务需求
SLO 的设定并非凭空臆断，而是需要平衡两个维度的输入：
| 输入维度 | 数据来源 | 作用 |
|---|---|---|
| 历史数据 | APM 平台、监控系统、日志系统 | 提供过去 3-6 个月的实际可用性、延迟、错误率基线，避免设定无法达成的目标 |
| 业务需求 | 产品经理、业务方、SLA 合同 | 定义用户可接受的最低体验，决定 SLO 的严格程度 |
实践建议： 在首次设定 SLO 时，优先以历史数据的 P99 或 P95 性能指标作为起点，再根据业务容忍度进行微调。例如，若过去 3 个月 API 延迟 P99 为 800ms，则 SLO 可设定为 1s，而非 200ms。
4.2 燃烧率（Burn Rate）与错误预算（Error Budget）
燃烧率与错误预算是 SLO 告警自愈的核心量化工具：
- 错误预算 = 1 - SLO（以百分比计）。例如，99.9% SLO 对应 0.1% 的错误预算。在 30 天窗口内，允许的总错误时间为 30d × 24h × 60min × 0.1% = 43.2 分钟。
- 燃烧率 = 实际错误率 / 错误预算消耗速率。燃烧率 > 1 表示错误预算正在加速消耗，需要触发告警。
下表展示了不同 SLO 等级对应的错误预算与典型燃烧率阈值：
| SLO 目标 | 错误预算（30 天） | 慢燃烧率（告警） | 快燃烧率（紧急） |
|---|---|---|---|
| 99.9% | 43.2 分钟 | 2x（1 小时内消耗 2% 预算） | 10x（10 分钟内消耗 10% 预算） |
| 99.99% | 4.32 分钟 | 2x | 10x |
| 99.999% | 25.9 秒 | 2x | 10x |
4.3 基于历史数据的 SLO 设定流程
以下流程可帮助团队从历史数据中推导出合理的 SLO 目标：
- 收集基线数据：从监控系统导出过去 90 天的可用性、延迟（P50/P95/P99）、错误率。
- 计算实际表现：统计实际达到的可用性百分比。例如，过去 90 天实际可用性为 99.85%。
- 设定初始 SLO：在历史基线基础上增加 0.05%~0.1% 的余量。若实际为 99.85%，则 SLO 可设为 99.75%。
- 定义燃烧率窗口：根据业务影响速度，设定 1 小时、6 小时、24 小时三个燃烧率告警窗口。
- 计算错误预算：基于 SLO 与窗口长度，计算每日/每周/每月的错误预算消耗上限。
关键公式：
错误预算 = 1 - SLO
燃烧率 = (实际错误率 × 窗口时长) / (错误预算 × 窗口时长)
当燃烧率 > 1 时，触发告警；当燃烧率 > 10 时，触发紧急自愈流程。
错误预算 = 1 - SLO
燃烧率 = (实际错误率 × 窗口时长) / (错误预算 × 窗口时长)
当燃烧率 > 1 时，触发告警；当燃烧率 > 10 时，触发紧急自愈流程。
4.4 SLO 燃烧率告警与自愈联动架构
下图展示了 SLO 燃烧率如何与告警及自愈 Runbook 形成闭环：
4.5 多窗口燃烧率告警策略
单一燃烧率窗口容易产生误报或漏报。推荐使用多窗口策略，覆盖不同时间尺度的异常：
| 窗口长度 | 燃烧率阈值 | 告警级别 | 典型响应 |
|---|---|---|---|
| 1 小时 | ≥ 10x | P0（紧急） | 立即触发自愈 Runbook，通知值班 SRE |
| 6 小时 | ≥ 3x | P1（高） | 触发告警，启动自动化诊断流程 |
| 24 小时 | ≥ 1.5x | P2（中） | 记录事件，生成分析报告，人工介入评估 |
常见陷阱： 不要仅依赖单一窗口的燃烧率。例如，1 小时内 10x 燃烧率可能由突发流量导致，而 24 小时 1.5x 燃烧率可能暗示慢性退化。多窗口组合可区分“急性故障”与“慢性劣化”，避免自愈 Runbook 被误触发。
4.6 错误预算消耗与自愈触发条件
错误预算的消耗速率直接决定自愈流程的启动时机。以下是一个基于错误预算剩余百分比的自愈触发矩阵：
- 绿色区（剩余 > 80%）：系统健康，无需干预。
- 黄色区（剩余 50%~80%）：触发低优先级告警，启动被动监控增强。
- 橙色区（剩余 20%~50%）：触发中优先级告警，启动自动化诊断 Runbook。
- 红色区（剩余 < 20%）：触发高优先级告警，立即执行自愈 Runbook（如自动扩容、流量切换、降级）。
下图展示了错误预算消耗与自愈动作的对应关系：
4.7 设定 SLO 的常见模式与避坑指南
| 模式 | 适用场景 | 风险 |
|---|---|---|
| 单一 SLO（如 99.9%） | 简单服务、内部工具 | 无法区分不同用户群体的体验差异 |
| 分层 SLO（核心/非核心） | 多模块微服务架构 | 核心 SLO 过严导致频繁告警 |
| 基于用户旅程的 SLO | 电商、支付等关键业务 | 数据采集成本高，依赖全链路追踪 |
| 动态 SLO（随季节调整） | 电商大促、节假日 | 需要自动化调整机制，否则易出错 |
最佳实践： 在 Runbook 中为每个 SLO 目标绑定明确的燃烧率告警规则与自愈动作。例如，当 1 小时燃烧率 ≥ 10x 时，自动执行“扩容 + 流量切换”Runbook；当 24 小时燃烧率 ≥ 1.5x 时，自动创建 Jira 工单并通知 SRE 团队。确保每个 SLO 都有对应的“自愈兜底”策略。