📚 课程目录第4章自愈流程概述

4. 自愈流程概述

自愈流程是 Error Budget 超限后触发 Runbook 自动执行的核心环节。它并非简单的自动化脚本，而是一套具备感知、决策、执行与验证能力的闭环机制。本节将明确自愈的定义、与自动化的本质区别，并拆解其核心要素。

4.1 自愈的定义

自愈（Self-Healing）是指系统在检测到异常或故障后，无需人工干预，自动执行预定义的恢复策略，使服务恢复到正常状态的能力。在 SRE 语境下，自愈流程通常由 Error Budget 消耗速率或剩余阈值触发，是保障服务等级目标（SLO）的最后一道防线。

关键特征： 闭环、无人工介入、可观测驱动、策略可编程。

4.2 自愈与自动化的区别

自动化是自愈的基础，但自愈在决策能力和反馈机制上要求更高。下表从多个维度对比两者的差异：

维度	自动化	自愈
触发方式	定时、事件、手动	可观测指标异常 + 策略匹配
决策能力	固定逻辑（if-then）	多条件判断、回滚、降级、熔断
反馈闭环	执行即结束	执行 → 验证 → 恢复 → 通知
失败处理	报错或重试	回滚、告警升级、人工介入
目标	减少重复操作	维持 SLO、降低 MTTR

实践建议： 优先将高频、低风险的故障场景自动化；当自动化覆盖率达到 80% 以上时，再逐步引入自愈策略。

4.3 自愈流程的核心要素

一个完整的自愈流程包含以下五个核心要素，它们共同构成闭环：

感知（Perception）：通过指标、日志、链路追踪等可观测数据，实时检测异常。常见信号包括：Error Budget 消耗速率、错误率、延迟 P99、饱和度。
决策（Decision）：根据预定义的策略引擎（如规则引擎、策略表、ML 模型），判断当前异常是否触发自愈动作，以及选择何种恢复策略。
执行（Execution）：调用 Runbook 中的原子操作，如重启实例、扩缩容、切换流量、回滚版本、降级功能等。
验证（Verification）：执行后再次检查关键指标，确认恢复是否成功。若失败，则进入回滚或升级流程。
记录与通知（Recording & Notification）：将自愈过程、结果、耗时记录到事件平台，并通知相关团队。

避坑提示： 自愈流程必须设置最大执行次数和冷却时间，防止“自愈风暴”——即系统反复触发自愈导致资源耗尽或状态混乱。

4.4 自愈流程闭环架构

下图展示了自愈流程的闭环架构，从感知到通知形成完整链路：

4.5 自愈流程的触发条件与策略分级

并非所有异常都适合自愈。根据 Error Budget 消耗速率和严重程度，可将自愈策略分为三个等级：

等级	触发条件	典型动作	风险
L1 轻量自愈	Error Budget 消耗速率 > 阈值 120%	重启实例、清理缓存、重试队列	低
L2 标准自愈	Error Budget 剩余 < 30% 且持续消耗	扩缩容、切换 AZ、回滚版本	中
L3 紧急自愈	Error Budget 剩余 < 10% 或 SLO 即将违反	熔断、降级、全局流量切换	高

设计原则： L1 自愈可全自动执行；L2 建议加入“人工确认窗口”（如 60 秒内无人取消则自动执行）；L3 必须触发告警升级，由值班 SRE 确认后执行。

4.6 自愈流程的 Runbook 模板结构

一个标准自愈 Runbook 应包含以下字段，确保可重复执行和审计：

# 自愈 Runbook 模板
---
name: "error_budget_exhaustion_self_heal"
version: "1.2.0"
trigger:
  metric: "error_budget_remaining_ratio"
  condition: "< 0.3"
  duration: "5m"
steps:
  - id: "step_1_perception"
    action: "query_metrics"
    params:
      metrics: ["error_rate", "p99_latency", "saturation"]
  - id: "step_2_decision"
    action: "evaluate_strategy"
    params:
      strategy_table: "config/self_heal_strategies.yaml"
  - id: "step_3_execution"
    action: "run_playbook"
    params:
      playbook: "{{ strategy.playbook }}"
  - id: "step_4_verification"
    action: "verify_recovery"
    params:
      check_interval: "30s"
      max_retries: 3
  - id: "step_5_notification"
    action: "send_alert"
    params:
      channel: "pagerduty"
      severity: "critical"
rollback:
  action: "rollback_last_step"
  timeout: "120s"
cool_down: "300s"
max_executions: 3

  关键字段说明： cool_down 防止自愈风暴；max_executions 限制单次故障的自愈次数；rollback 定义失败后的回滚动作。

通过以上定义与结构，自愈流程不再是简单的自动化脚本，而是一套具备感知、决策、执行、验证、回滚能力的闭环系统，能够有效降低 MTTR，保障 Error Budget 不超支。