运维自动化与 Runbook as Code 实践

值班工程师的时间常常被大量重复劳动吃掉：重启服务、清理磁盘、重跑失败的批处理、手动扩容。这些劳动既不产生持久价值，又随服务规模线性增长。本文讲清楚三件事：怎么识别和量化 toil、怎么把 Runbook 变成可执行代码、怎么在安全边界内做自愈与自动修复，最终把值班时间还给真正的工程工作。

目录

• 1. 什么是 Toil
• 2. 识别与量化 Toil
• 3. Runbook as Code
• 4. 自动化编排框架
• 5. 自愈与自动修复
• 6. 值班减负实践
• 7. 自动化安全边界
• 8. 度量自动化收益
• 9. 案例与最佳实践

1. 什么是 Toil

1.1 Toil 的定义

Toil 是 Google SRE 提出的概念，指运维中那些手工的、重复的、可自动化的、战术性的、不产生持久价值的工作，并且它的量随服务规模线性增长。注意最后一条：如果某项工作随着服务数量增加而线性增加，它几乎一定是 toil。

1.2 Toil 的五个特征

判断一项工作是不是 toil，对照下面五个特征，命中越多越典型。

1.3 Toil 不等于所有运维工作

需要警惕把「所有运维工作都当 toil 消灭」的极端。判断、设计、复盘、改进这类工作恰恰是工程师价值的来源。目标是压缩 toil 占比，而不是取消运维。

2. 识别与量化 Toil

2.1 用时间日志找出来

最可靠的办法是让值班人如实记录一周的时间去向，按半小时粒度标注「做了什么、属于哪类」。数据不用很精确，趋势足够暴露问题。

时间日志示例
  09:30-10:00  手动重启订单服务实例          # 重复、手工
  10:00-10:20  清理日志盘，rm 老日志         # 重复、可自动化
  10:20-11:00  排查告警，确认是误报           # 战术性
  14:00-16:00  重跑失败的对账批处理           # 重复、可自动化
  16:00-17:00  设计重试机制的改进方案         # 非 toil，是工程

2.2 量化到百分比

SRE 的通行建议是把 toil 控制在总工作量的 50% 以内，理想情况更低。把时间日志汇总成一张占比表，toil 占比一目了然。

2.3 按「频次 × 单次耗时」排序

把每类 toil 的月频次乘以单次耗时，得到月度总耗时，从高到低排序，就是自动化投入的优先级。高频短耗时的项目往往比低频长耗时的更值得先做，因为规则更简单。

3. Runbook as Code

3.1 从文档到代码

传统 Runbook 是一份给人看的文档，紧急时刻还得人照着敲命令，既慢又容易出错。Runbook as Code 的核心是把操作步骤写成可执行的代码，纳入版本控制、可评审、可测试、可复用。

3.2 结构化描述

即使暂时不能全自动执行，也应先把 Runbook 结构化，明确每一步的输入、命令、预期结果和失败处理。

# runbook: restart-service.yaml
name: restart-order-service
trigger: order-service-unhealthy
steps:
  - id: drain
    action: remove-from-lb
    target: order-service
    expect: no-active-connections
  - id: restart
    action: rolling-restart
    target: order-service
    max_unavailable: 1
  - id: verify
    action: health-check
    target: order-service
    timeout: 120s
on_failure: rollback-and-page

3.3 可执行的三种形态

• 脚本化：把步骤固化成带参数的脚本，人工触发。
• 流水线化：接入 CI/CD，用流水线执行标准操作。
• 事件驱动：由告警自动触发，无需人工介入。

三者的自动化程度递增，风险也递增，应按操作的风险等级选择形态。

3.4 从文档到代码的渐进路径

不要一次把文档全部重写成自动化工作流。分三步走：先结构化（人能读、机器能解析），再脚本化（可复现执行），最后事件驱动（告警自动触发）。每一步都能独立产生价值。

Runbook 成熟度
  L1 自由文本：人读，易歧义
  L2 结构化  ：步骤、命令、预期结果分明
  L3 可执行  ：脚本化，一键执行
  L4 事件驱动：告警触发，自动执行
  推进原则：每级先覆盖高频故障，再逐步扩展

4. 自动化编排框架

4.1 为什么需要编排

单条命令好自动化，但真实运维操作往往是多步、跨系统、有条件分支的。编排框架负责串起这些步骤、处理失败回滚、记录执行日志。

4.2 工作流的三个要素

一个可靠的运维工作流必须包含：明确的步骤定义、每步的预期结果校验、以及失败时的回滚或人工接管路径。缺少第三步的工作流在出问题时反而制造事故。

4.3 幂等与重入

运维工作流必须能安全重跑。设计时要考虑：中途失败后重跑会不会重复执行已完成步骤？会不会造成资源重复创建？把每一步设计成幂等的，工作流才敢重试。

5. 自愈与自动修复

5.1 自愈的分级

自愈不是「全自动无人值守」，而是按风险分级的自动化响应。

L0 仅告警      ：通知人，人工处理
L1 自动重启    ：进程/实例级别重启，影响面小
L2 自动扩容    ：按负载信号扩缩容，可逆
L3 自动故障转移 ：切流量到健康实例
L4 自动回滚    ：检测到发布引发故障则回滚版本
L5 自动修复数据 ：高风险，通常仍需人工确认

5.2 事件驱动的自愈

自愈通常由监控事件驱动：告警触发后，系统匹配对应的修复动作，执行前做前置校验，执行后做效果验证，验证不通过则升级为人工介入。

5.3 防抖动与熔断

自动修复最怕「修复动作本身引发雪崩」。必须加防抖：同一问题在时间窗内只自动修复一次；连续修复失败则熔断，停止自动动作并立即叫人。

5.4 自愈的效果验证

自动修复执行后不能假定成功，必须验证：服务是否真的恢复、指标是否回到正常区间、是否引入了新的异常。验证不通过则回滚修复动作并升级人工。

6. 值班减负实践

6.1 减少告警噪音

值班疲劳的第一大来源是告警太多。先做告警治理：合并同源告警、抑制级联告警、下线长期误报的规则，让值班人只在真正需要时被打扰。

6.2 让常见故障有按钮

把高频故障处理做成「一键操作」，值班人不需要记命令、不需要翻文档，点一下就能执行经过验证的标准流程。

6.3 值班交接与轮换

建立清晰的值班交接机制：未闭环的问题、可疑的隐患、刚上线的变更都要交接。轮换周期不宜过短，否则每人都在重新熟悉系统。

7. 自动化安全边界

7.1 什么可以自动，什么不可以

原则是：可逆、影响面小、规则明确的操作可以自动；不可逆、影响面大、需要判断的操作必须人工确认。

7.2 最小权限

自动化的执行身份必须遵循最小权限。用于自动重启的账号不应具备删除数据库的权限，避免自动化被滥用或误用时造成不可逆后果。

7.3 审计与可追溯

每一次自动执行都要留下完整审计：谁触发、执行了什么、参数是什么、结果如何。出了问题要能复盘到具体动作，这是自动化能长期安全运行的前提。

7.4 变更审计与回滚预案

自动化执行的每一步都要有回滚预案：如果自动重启后服务仍未恢复怎么办，如果自动扩容后负载仍高怎么办。预案写进工作流，执行失败时按预案升级，而不是原地重试到超时。

8. 度量自动化收益

8.1 三个收益指标

• Toil 占比：自动化后 toil 时间占总工作量的比例是否下降。
• 人工介入率：告警中有多少比例仍需人工处理。
• 平均处理时长：从告警到恢复的平均时间是否缩短。

8.2 用前后对比说话

自动化上线前后各取一个月的同口径数据做对比，避免用「感觉快了」来证明价值。数据也能帮你决定下一个该自动化什么。

8.3 把省下的时间再投入

自动化省下的时间如果不重新投入工程改进，很快会被新的 toil 填满。把节省出的时间显式地划给改进项目，收益才能复利。

9. 案例与最佳实践

9.1 落地 Checklist

□ 用时间日志量化 toil 占比，目标压到 50% 以下
□ 按「频次 × 单次耗时」排序，优先自动化高频项
□ 把 Runbook 结构化并纳入版本控制，可评审可测试
□ 工作流必须含步骤定义、结果校验、失败回滚三段
□ 每一步设计成幂等，保证工作流可安全重跑
□ 自愈按 L0~L5 分级，可逆低风险才自动
□ 加防抖与熔断，修复失败立即叫人
□ 自动执行留完整审计，最小权限运行
□ 用 toil 占比、人工介入率、处理时长度量收益

9.2 常见坑与对策

小结

运维自动化与 Runbook as Code 的路径是：用时间日志识别 toil → 按频次乘耗时排优先级 → 把 Runbook 结构化并可执行化 → 用编排框架串起多步操作 → 按风险分级做自愈 → 在最小权限与审计的安全边界内运行 → 用 toil 占比和人工介入率度量收益。核心原则只有一条：让可逆、规则明确的重复劳动自动完成，把需要判断的工作留给工程师，并把省下的时间重新投入工程改进。