4. 自愈剧本概述
自愈剧本是故障自愈体系的核心执行单元。它是一套可编排、可观测、可回滚的自动化故障处理流程，将运维专家处理特定故障的经验、判断逻辑与操作步骤，固化为机器可执行的“剧本”。当监控系统探测到故障苗头时，自愈剧本被触发，代替人工完成从诊断到恢复的全链路操作，从而将 MTTR 从分钟级甚至小时级压缩到秒级。
4.1 什么是自愈剧本
自愈剧本本质上是一个“故障处理决策树 + 原子操作链”的组合。它定义了：
- 触发条件：什么告警或指标异常会启动剧本。
- 诊断逻辑：如何确认故障根因，排除误报。
- 恢复动作：执行哪些操作来消除故障。
- 验证与回滚：如何确认恢复成功，失败时如何回退。
核心认知： 自愈剧本不是简单的“告警-执行脚本”的线性串联，而是一个包含条件分支、并行动作、超时控制、熔断降级的闭环系统。
4.2 自愈剧本与传统运维脚本的区别
传统运维脚本（Shell、Python 脚本等）与自愈剧本在多个维度存在本质差异。下表从关键维度进行对比：
| 对比维度 | 传统运维脚本 | 自愈剧本 |
|---|---|---|
| 触发方式 | 人工手动执行，或 crontab 定时触发 | 事件驱动，由告警、指标阈值、日志关键字自动触发 |
| 执行逻辑 | 线性顺序执行，if-else 分支有限 | 有向无环图（DAG）编排，支持并行、分支、循环、子剧本调用 |
| 安全控制 | 无内置防护，误操作风险高 | 内置熔断、降级、限频、灰度、人工审批节点 |
| 可观测性 | 依赖脚本内 echo/print，日志分散 | 全链路追踪，每个步骤有输入输出、耗时、状态记录 |
| 回滚能力 | 需手动编写回滚逻辑，常被忽略 | 内置原子回滚步骤，支持自动回滚到上一个稳定状态 |
| 复用性 | 脚本间耦合高，参数化不足 | 剧本可参数化、版本化、跨环境导入导出 |
| 适用场景 | 日常变更、批量操作、数据清洗 | 故障自愈、自动扩缩容、流量切换、混沌工程 |
关键结论： 传统脚本解决的是“怎么做”的问题，而自愈剧本解决的是“什么时候做、做之前先判断什么、做错了怎么恢复”的完整闭环问题。
4.3 自愈剧本的三大核心要素：触发、决策、执行
任何一个完整的自愈剧本，都必须包含三个核心要素：触发（Trigger）、决策（Decision）、执行（Execution）。三者构成一个闭环的故障处理单元。
4.3.1 触发（Trigger）
触发是自愈剧本的“启动器”。它决定了剧本在什么条件下被激活。常见的触发源包括：
- 告警触发：Prometheus Alertmanager、Zabbix 等监控系统发出的告警。
- 指标阈值触发：CPU 使用率 > 90%、错误率 > 1% 等实时指标。
- 日志关键字触发：应用日志中出现 OOM、Connection Refused 等关键字。
- 事件触发：K8s Pod 重启、宿主机宕机、证书即将过期等平台事件。
4.3.2 决策（Decision）
决策是自愈剧本的“大脑”。它负责在触发后判断：是否真的需要执行恢复动作？执行哪个恢复动作？ 决策环节通常包含：
- 误报过滤：通过二次指标确认、上下游依赖检查，排除抖动或误报。
- 根因定位：在多个可能原因中，通过决策树或规则引擎确定最可能的根因。
- 灰度判断：根据故障影响范围、当前变更窗口、业务等级，决定是否执行自愈。
- 熔断检查：检查该剧本在单位时间内的执行次数是否超过限频，防止“自愈风暴”。
4.3.3 执行（Execution）
执行是自愈剧本的“手脚”。它负责将决策结果转化为具体的恢复操作。执行环节必须包含：
- 原子操作：重启进程、切换流量、扩容 Pod、清理缓存、回滚版本等。
- 操作验证：执行后立即检查关键指标是否恢复，确认操作生效。
- 自动回滚：如果验证失败或出现新异常，自动执行回滚步骤，恢复到执行前的状态。
- 结果通知：将执行结果、耗时、变更记录发送到值班群或工单系统。
常见误区： 很多团队在初期只关注“执行”环节，忽略了“决策”中的误报过滤和熔断检查。这会导致自愈剧本在抖动时频繁误操作，反而增加故障风险。一个健壮的自愈剧本，决策环节的代码量往往占整个剧本的 60% 以上。
4.4 自愈剧本的典型工作流
将三大要素串联起来，一个典型的自愈剧本工作流如下：
这个工作流清晰地展示了三大要素如何协同：触发（步骤1）→ 决策（步骤2-4）→ 执行（步骤5-6），并通过反馈闭环形成持续自愈的能力。
4.5 小结
自愈剧本是 MTTR 压降的核心武器。它通过触发、决策、执行三大要素的有机组合，将运维专家的故障处理经验转化为可重复、可观测、可回滚的自动化流程。与传统脚本相比，自愈剧本更强调安全控制、决策逻辑和闭环反馈，是 SRE 团队从“被动救火”走向“主动自愈”的关键基础设施。