主题
运维文档模板（变更割接 / 故障报告 / 复盘 / 交接 / 架构评审）
本页是可直接复制的运维文档模板。每份模板用代码块包裹，整段复制到你的文档系统里再填。 用法：右侧「本页目录」跳转，或
Ctrl+K搜索；模板里的【】是需要你替换的占位。 配套：日常逐条判定见 Checklist 大全；复盘的"为什么这么做"原理见 事故管理与无指责复盘（本页只给可复制模板，不重讲原理）。
一、变更 / 割接方案
适用：发布、扩容、迁移、配置变更、版本升级等所有生产变更。没有这个模板，就不要在生产动手。
markdown
# 变更/割接方案：【系统名-变更内容】
## 1. 背景与目标
- 变更原因：【为什么要做，解决什么问题】
- 变更目标：【期望达到的结果，最好带可验证指标】
- 变更时间窗口：【YYYY-MM-DD HH:MM ~ HH:MM，避开业务高峰】
- 执行人 / 复核人 / 值班人：【姓名（化名）】
## 2. 影响范围
- 影响系统：【哪些服务/链路会受影响】
- 影响用户：【内部/外部、预估影响面】
- 影响级别：【P0/P1/P2，是否有感知】
- 不影响的部分：【明确列出，避免误判】
## 3. 前置检查（动手前必须全部 ✅）
- [ ] 已备份：【数据库/配置/镜像，备份位置】
- [ ] 已确认回滚方案可执行
- [ ] 已通知相关方（业务/开发/客服）
- [ ] 监控与告警已就位，可观察变更过程
- [ ] 已在测试环境预演通过
- [ ] 业务低峰窗口确认
## 4. 操作步骤（按顺序，每步可验证）
1. 【步骤一：命令/操作 + 预期输出】
2. 【步骤二：……】
3. 【步骤三：……】
## 5. 回滚预案（最重要，先想清楚再动手）
- 触发回滚的条件：【出现什么现象立刻回滚】
- 回滚步骤：
1. 【回滚命令/操作】
2. 【……】
- 回滚预计耗时：【X 分钟】
- 回滚后验证：【确认业务恢复的检查项】
## 6. 变更后验证
- [ ] 功能验证：【核心功能点测试】
- [ ] 指标验证：【可用性/性能/错误率是否符合预期】
- [ ] 观察期：【变更后持续观察 X 分钟/小时】
## 7. 值班安排
- 变更后 X 小时内值班人：【谁盯】
- 应急联络：【升级路径，多久没恢复要上报】
## 8. 变更结论（事后填写）
- 实际结果：【成功/部分成功/回滚】
- 与方案的偏差：【哪步和预期不一样】
- 遗留问题与后续跟进：【……】二、故障报告（Postmortem 面向管理层/周知）
适用：故障发生后，给团队/管理层一份简明、有结论的报告。对事不对人，聚焦事实和改进。
markdown
# 故障报告：【一句话概括故障现象】
## 1. 时间线
- 发生时间：【YYYY-MM-DD HH:MM】
- 发现/告警时间：【HH:MM】
- 恢复时间：【HH:MM】
- 持续时长：【X 分钟】
## 2. 影响
- 影响范围：【哪些用户/业务/功能】
- 影响程度：【预计影响用户数/订单损失/错误率】
- 业务损失评估：【能估则估，不能则写"评估中"】
## 3. 现象与根因
- 表象：【用户看到什么、监控什么指标异常】
- 根因：【直接原因 + 深层原因，分层写清楚】
- 为什么没提前发现：【监控/流程的缺口】
## 4. 处置过程
- 谁在什么时间做了什么关键操作（简列时间线）
- 最终如何恢复
## 5. 整改行动项（Action Items）
| 序号 | 行动项 | 负责人 | 优先级 | 截止时间 |
|---|---|---|---|---|
| 1 | 【例：增加该指标告警】 | 【化名】 | P1 | 【日期】 |
| 2 | 【……】 | | | |
## 6. 经验教训
- 【这次做得好的】
- 【下次要改进的】三、无指责复盘模板（Blameless Postmortem）
适用：P1/P2 故障后的深度复盘会。原则：对系统不对人，找防御纵深漏洞，不找人背锅。 原理和为什么这么做见 事故管理与无指责复盘，本模板只给可直接开会用的结构。
markdown
# 无指责复盘：【故障标题】
> 本复盘遵守"无指责"原则：我们研究系统为什么允许了这次故障，
> 而不是谁犯了错。所有参与者在当时的信息下都做了合理判断。
## 1. 发生了什么（时间线，含所有关键决策点）
- HH:MM 系统状态 / 触发
- HH:MM 告警 / 发现
- HH:MM 某人判断【基于当时信息的合理推断】并采取【动作】
- HH:MM ……
- HH:MM 恢复
## 2. 影响与损失
【范围、时长、业务影响】
## 3. 为什么会发生（按防御纵深分层追问）
- 技术层：【哪个组件/配置/代码引入了问题】
- 监控层：【为什么没更早发现——盲区在哪】
- 流程层：【变更/评审哪里没拦住】
- 组织层：【有没有资源/沟通的系统性问题】
## 4. 为什么没早发现、没早挡住
- 监控盲区：……
- 依赖假设：【我们之前假设了什么，结果假设错了】
## 5. 做得好的地方（也要写）
- 【哪些处置是及时有效的，值得固化】
## 6. 行动项（可验证、有负责人、有截止时间）
| 行动项 | 类别(技术/监控/流程) | 负责人 | 截止 | 完成判定标准 |
|---|---|---|---|---|
| 【例：为该链路加错误率告警】 | 监控 | 【化名】 | 【日期】 | 告警上线并演练触发一次 |
## 7. 是否需要更新文档/预案
- [ ] 更新 Runbook
- [ ] 更新监控
- [ ] 补充自动化/自愈四、交接文档（系统/岗位交接）
适用：人员离职、换班、系统移交。目标：接手人照着这份文档能把系统跑起来。
markdown
# 系统/岗位交接文档：【系统名/岗位名】
## 1. 系统概览
- 这个系统是干什么的：【一句话 + 支撑的业务】
- 架构简图：【贴架构图，关键组件清单】
- 规模：【机器数/QPS/数据量/重要级别】
## 2. 关键信息（接手人最需要的）
- 登录入口、跳板机、密钥/账号位置（注意：不写明文密码）
- 监控大盘地址、关键告警项
- 核心日志位置与排障入口
- 外部依赖：【依赖哪些第三方/其他团队系统】
## 3. 日常运维操作
- 日常巡检：【见 Checklist】
- 常规发布流程：【链接到发布文档/流水线】
- 常见操作手册：【扩缩容、重启、清理等】
## 4. 已知坑与应急预案
- 历史踩过的坑：【……】
- 常见故障与处置：【现象→怎么办】
- 回滚/应急联系人：【升级路径】
## 5. 待办与遗留事项
- 还没做完的优化：【……】
- 已知风险：【……】
## 6. 交接确认
- 交接人 / 接手人 / 日期
- 接手人是否已独立操作过一次关键流程：【是/否】五、架构评审记录（Architecture Review）
适用：新系统设计、重大方案评审。目标：把权衡和取舍记录下来，避免日后"当初为什么这么设计"。
markdown
# 架构评审记录：【方案名】
## 1. 背景与需求
- 要解决的问题：【……】
- 非目标（明确不做什么）：【……】
- 关键约束：【性能/成本/时间/合规】
## 2. 方案与选型
- 选定方案：【架构描述 + 图】
- 关键技术选型及理由：
| 选型 | 备选 | 最终选择 | 理由（含放弃备选的原因） |
|---|---|---|---|
## 3. 评审关注点
- 可用性：【单点在哪、如何冗余】
- 扩展性：【瓶颈在哪、如何水平扩展】
- 数据一致性：【……】
- 安全：【鉴权、密钥、合规】
- 成本：【……】
- 可观测性：【监控/日志/告警如何设计】
## 4. 风险与权衡（重要，记录"为什么接受这个代价"）
- 已知风险：【……】
- 我们接受的权衡：【为了 XX，牺牲了 YY】
## 5. 评审结论
- 通过 / 有条件通过 / 打回
- 必须落地的改进项：【……】
- 评审人 / 日期使用心得（几个提醒）
- 模板是脚手架，不是枷锁。 小变更不必写满全部章节，但"回滚预案"和"影响范围"两栏永远不能省。
- 复盘模板一定要写"做得好的地方"——只写问题会让大家害怕复盘，写了优点才愿意真实暴露问题。
- 行动项必须有**"完成判定标准"**，否则容易变成永远在做的"改进项"。
相关速查
- 逐条的上线/巡检/应急判定：Checklist 大全
- 复盘与事故管理的原理：事故管理与无指责复盘
- SLO 与错误预算（影响范围、可用性评估的依据）：SLO 与错误预算
- 容量与灾备（回滚、影响评估的依据）：容量规划、高可用与灾备
- 把模板里的操作自动化：Python 运维自动化
官方文档
- Google SRE Book（Postmortem 文化）：https://sre.google/sre-book/postmortem-culture/（需科学上网）；国内平替：https://www.cnblogs.com/lhxBlogs/p/17936005.html
- Google 无指责复盘范例：https://sre.google/resources/postmortem-library/（需科学上网，无国内平替）