运维文档

概述 凌晨三点被告警叫醒，面对一个不熟悉的服务，你能多快恢复？如果你需要翻聊天记录、问同事、翻代码才能弄清楚怎么处理，那说明你的团队缺一样东西——Runbook。 Runbook 是 SRE 体系中最基础但也最容易被忽视的工程实践。它是连接"告警"和"行动"的桥梁——告警告诉你"出问题了"，Runbook 告诉你"该怎么办"。一个好的 Runbook 能让任何有基础技术能力的工程师在 On-Call 时有效响应告警，而不依赖特定人员的"脑内知识"。 从 Runbook 的作用、结构设计、自动化、版本管理、质量评审到实战模板，详细梳理如何编写和维护高质量的 Runbook。 关于 Runbook 的好的实践，可参考 Google SRE Workbook - Operational Overload 和 PagerDuty - Runbook Guide。 一、Runbook 的作用与价值 什么是 Runbook Runbook 是一份标准化的操作手册，描述了如何诊断和处理特定的运维场景。它的核心特征是： 任何有基础技术能力的工程师，按照 Runbook 的步骤操作，都能正确处理对应的告警或运维任务——而不需要依赖特定人员的主观经验。 没有 Runbook 的代价 没有 Runbook 的故障响应： 告警触发 → On-Call 工程师看到 "Redis 内存使用率 90%" → 不知道该怎么办 → 打电话问张三（张三写过这个服务） → 张三不在线 → 打电话问李四 → 李四说 "可能是某个 key 太大了，你看看" → 工程师花 20 分钟找大 key → 最终处理了，但用了 40 分钟 有 Runbook 的故障响应： 告警触发 → On-Call 工程师看到 "Redis 内存使用率 90%" → 告警中附带 Runbook 链接 → 打开 Runbook，按步骤操作 → Step 1: 执行 redis-cli --bigkeys 扫描大 key → Step 2: 发现 user_session:xxx 占用 500MB → Step 3: 执行 DEL user_session:xxx → 10 分钟恢复 Runbook 的价值 维度 价值 降低 MTTR 按步骤操作比从零排查快得多 降低 On-Call 压力 有文档可依，不需要"什么都知道" 知识沉淀 把个人经验转化为组织知识 新人友好 新人 On-Call 不再需要"跟班学习"数周 驱动自动化 Runbook 中的步骤是自动化的候选对象 Runbook 与其他文档的区别 文档类型 目的 读者 场景 Runbook 处理特定告警/故障的操作步骤 On-Call 工程师 告警触发时 Architecture Doc 描述系统架构和设计决策 所有工程师 理解系统设计 API Doc 描述 API 接口规范 开发者 对接 API Postmortem 分析故障根因和改进项 团队 故障复盘 Playbook 更广泛的工作流程指南 团队 执行复杂任务 二、Runbook 的结构设计 标准结构 一个好的 Runbook 应该包含以下部分：...