1. SLO 与自愈基础：SLO 定义、SLI 与错误预算、自愈概念与价值
1.1 服务等级目标（SLO）定义
SLO（Service Level Objective）是服务可靠性工程的核心承诺，它定义了在特定时间窗口内，服务必须达到的可用性或性能阈值。SLO 不是 SLA（Service Level Agreement），而是团队内部或与上下游约定的可靠性目标，通常以“百分比 + 时间窗口”的形式表达。
| 概念 | 定义 | 典型示例 |
|---|---|---|
| SLO | 服务应达到的可靠性目标，内部承诺 | 99.9% 可用性（月度） |
| SLA | 与客户签订的正式服务协议，含惩罚条款 | 99.95% 可用性，否则赔偿 |
| SLI | 实际测量的服务指标，用于评估 SLO | 请求成功率 99.92% |
关键原则：SLO 应比 SLA 更严格（例如 SLA 99.9%，SLO 设为 99.95%），为响应延迟留出缓冲空间，避免直接触发赔偿条款。
1.2 SLI 与错误预算
SLI（Service Level Indicator） 是衡量服务质量的量化指标。常见的 SLI 类型包括：
- 可用性 SLI：成功请求数 / 总请求数（排除预期错误）
- 延迟 SLI：满足延迟阈值的请求百分比（如 p99 < 200ms）
- 吞吐量 SLI：每秒处理请求数（RPS）
- 错误率 SLI：5xx 错误占总请求的比例
错误预算（Error Budget） 是 SLO 的衍生概念，计算公式为：
错误预算 = 1 - SLO（以小数表示）
例如：SLO = 99.9% → 错误预算 = 0.1%（月度时间窗口内允许的不可用时间）
月度错误预算 = 30天 × 24小时 × 60分钟 × 60秒 × 0.001 = 2592 秒 ≈ 43.2 分钟错误预算的消耗速率直接决定是否需要触发自愈流程：
| 错误预算消耗状态 | 消耗比例 | 自愈触发策略 |
|---|---|---|
| 健康区 | < 50% | 仅监控，不触发自愈 |
| 警戒区 | 50% – 80% | 触发预检与轻度自愈（如扩容） |
| 危险区 | > 80% | 触发全自动自愈流程（回滚、切换、限流） |
常见误区：错误预算耗尽不等于服务宕机，而是意味着 SLO 目标已无法达成。此时应优先执行自愈恢复，而非继续发布新功能。
1.3 自愈概念与价值
自愈（Self-Healing） 是指系统在检测到异常或 SLO 偏离时，无需人工介入即可自动执行恢复操作的能力。自愈不是简单的告警通知，而是闭环的自动化决策与执行。
自愈的核心价值体现在三个维度：
- 缩短 MTTR（平均修复时间）：从人工响应（分钟级～小时级）缩短至自动化（秒级～分钟级）
- 降低认知负载：减少 on-call 工程师的疲劳决策，将重复性恢复操作标准化
- 保护错误预算：在错误预算快速消耗时自动介入，避免 SLO 违约
1.4 自愈触发模型与 Runbook 参数化
自愈触发不是简单的“告警 → 执行脚本”，而是基于 SLO 状态的多级决策模型。Runbook 参数化设计正是为了适配这种多场景需求：
- 参数化阈值：错误预算消耗比例、SLI 窗口大小、冷却时间等作为可配置参数
- 参数化动作：根据服务类型（无状态/有状态/批处理）选择不同的自愈动作集
- 参数化回滚：自愈失败后的回退策略，支持逐步降级
课程核心观点：Runbook 参数化是连接 SLO 监控与自愈执行的桥梁。没有参数化的 Runbook 只能处理单一场景，而参数化设计让同一个 Runbook 模板适配不同服务、不同 SLO、不同故障模式。
1.5 自愈成熟度模型
不同团队的自愈能力差异较大，以下成熟度模型可用于评估当前阶段：
| 成熟度等级 | 特征 | MTTR 典型值 | Runbook 形态 |
|---|---|---|---|
| L0：人工 | 完全依赖 on-call 工程师手动排查 | 30 – 120 分钟 | 无 Runbook 或纯文档 |
| L1：辅助 | 有 Runbook 文档，人工按步骤执行 | 15 – 45 分钟 | 静态 Markdown 文档 |
| L2：半自动 | 部分步骤自动化，人工确认后执行 | 5 – 15 分钟 | 参数化脚本 + 审批 |
| L3：全自动 | 基于 SLO 自动触发，无需人工介入 | < 5 分钟 | 参数化 Runbook + 自愈引擎 |
| L4：预测性 | 基于趋势预测提前触发自愈 | < 1 分钟 | ML 模型 + 动态参数调整 |
课程目标：本课程将帮助团队从 L1/L2 跃迁至 L3，通过 Runbook 参数化设计实现 SLO 驱动的全自动自愈。