2. 自愈场景概述

自愈（Self-Healing）是指系统在检测到故障或异常状态后，无需人工干预，自动执行预定义的恢复动作，使服务或资源回归正常水平的能力。在SRE实践中，自愈不是消灭故障，而是缩短故障持续时间，将MTTR（平均修复时间）从小时级压缩到分钟级甚至秒级。

2.1 自愈的定义与核心要素

一个完整的自愈能力包含三个核心要素：

2.2 常见自愈场景

生产环境中，以下四类场景占据了自愈需求的80%以上。每个场景都有其独特的检测指标和恢复动作模式。

2.2.1 服务宕机（Service Down）

进程崩溃、端口无响应、健康检查失败。这是最紧急的自愈场景，通常需要在秒级完成恢复。

• 检测方式：TCP端口探测、HTTP状态码检查、进程PID检查
• 典型恢复动作：重启进程、重新加载配置、切换流量到健康实例
• 常见陷阱：频繁重启导致"崩溃-重启"死循环，需配合熔断机制

2.2.2 磁盘空间满（Disk Full）

日志文件、临时数据、数据库WAL日志等持续增长，导致磁盘使用率超过阈值（通常为85%或90%）。

• 检测方式：磁盘使用率监控、inode耗尽检测
• 典型恢复动作：清理过期日志、压缩归档、扩容磁盘、删除临时文件
• 常见陷阱：只清理不治理，需要配合日志轮转策略

2.2.3 CPU使用率高（CPU High）

突发的计算密集型任务、代码死循环、异常流量导致CPU持续超过阈值（如80%）。

• 检测方式：CPU使用率指标、load average、top/htop进程分析
• 典型恢复动作：终止异常进程、限流降级、扩容实例、调整线程池大小
• 常见陷阱：误杀系统关键进程，需建立进程白名单

2.2.4 内存泄漏（Memory Leak）

应用程序持续分配内存但未释放，导致内存使用率持续上升，最终触发OOM Killer。

• 检测方式：内存使用率趋势、GC频率监控、堆内存分析
• 典型恢复动作：重启进程、触发GC、dump堆内存后重启、扩容内存
• 常见陷阱：重启治标不治本，需配合版本回滚或热修复

2.3 自愈闭环流程

任何自愈场景都必须遵循一个完整的闭环流程，缺一不可。下图展示了自愈闭环的五个阶段：

2.4 闭环各阶段详解

每个阶段都有明确的输入、输出和关键检查点：

2.5 自愈场景与Runbook模板化的关系

不同自愈场景的恢复动作差异很大，但它们的流程结构高度相似。这正是Runbook模板化的基础：

• 相同点：所有场景都遵循"检测→告警→决策→执行→验证"的闭环结构
• 不同点：检测指标、阈值、恢复命令、验证方式等参数不同
• 模板化策略：将闭环流程固化为模板骨架，将场景差异抽象为参数变量

例如，服务宕机和磁盘满两个场景，在模板层面共享相同的"重启/清理→验证→回滚"三段式结构，只是具体的执行命令和验证指标不同。后续章节将详细讲解如何设计这种参数化模板。