postmortem

事后复盘

目录

1. 目的
2. 适用时机
3. 这是什么？
4. 工作流
5. 常见模式
6. 防护措施
7. 快速参考

目的

开展不追责的事后复盘，将失败转化为学习机会，记录发生了什么、为何发生、影响量化结果、根本原因分析，以及明确责任人的可执行预防措施。

适用时机

在以下情况下使用此技能：

事件背景

• 发生生产环境中断、系统故障或服务降级
• 发生安全漏洞、数据丢失或合规违规
• 产品发布失败、项目错过截止日期或计划成效不佳
• 出现影响客户的错误、质量问题或支持危机
• 发生可能造成严重伤害的未遂事件（主动开展事后复盘）

学习目标

• 需要了解根本原因（而不只是表面症状），以防止问题再次发生
• 希望识别系统性问题，而非个人失误
• 必须为利益相关者或审计人员记录时间线和影响
• 旨在根据失败带来的洞见改进流程、系统或实践
• 正在建设组织学习文化（鼓励透明，而非追责）

时机

• 事件解决后立即开展（趁记忆犹新，在 48 小时内）
• 对反复出现的问题或长期存在的问题进行定期评审
• 每季度评审所有事件，以识别规律
• 事前复盘形式：在重大发布前，设想发布失败并撰写事后复盘

请勿在以下情况下使用：

• 事件仍在进行中（优先解决问题，再进行事后复盘）
• 目的是追究责任或惩罚个人（这与不追责文化背道而驰）
• 问题无关紧要、没有学习价值（事后复盘仅用于重大事件）

这是什么？

事后复盘是对失败进行结构化、不追责的分析，旨在回答以下问题：

• 发生了什么？ 从发现问题到解决问题的事件时间线
• 造成了什么影响？ 量化损失（受影响用户数、收入损失、持续时间）
• 为何会发生？ 使用 5 个为什么、鱼骨图或故障树进行根本原因分析
• 如何防止问题再次发生？ 制定由负责人落实并设定截止日期的可执行事项
• 哪些方面进展顺利？ 事件响应中的积极表现

核心原则：

• 不追责：关注系统和流程，而非个人。人会犯错，系统应具备韧性。
• 可执行：纠正措施必须具体、明确负责人并持续跟踪
• 透明：广泛分享，促进组织学习
• 及时：趁记忆犹新时开展（问题解决后 48 小时内）

快速示例：

事件：数据库中断，停机 2 小时，影响 50K 名用户

时间线：

• 14:05 - 自动部署开始（配置变更）
• 14:07 - 数据库连接池耗尽，错误数量激增
• 14:10 - 警报触发，值班人员收到呼叫
• 14:15 - 工程师开始调查，发现错误配置
• 15:30 - 开始回滚（因运行手册不明确而延迟）
• 16:05 - 服务恢复

影响：服务中断 2 小时，50K 名用户无法访问，预计收入损失 $20K

根本原因（5 个为什么）：

1. 为什么发生中断？部署了错误配置
2. 为什么配置错误？连接池大小设为 10（应为 100）
3. 为什么值不正确？配置模板有误
4. 为什么模板有误？新团队成员不熟悉生产环境的配置值
5. 为什么未能及时发现？没有在暂存环境中测试配置

纠正措施：

• 在部署流水线中添加配置验证（负责人：Alex，截止日期：Mar 15）
• 创建具有类似生产环境负载的暂存环境（负责人：Jordan，截止日期：Mar 30）
• 更新运行手册，补充回滚步骤（负责人：Sam，截止日期：Mar 10）
• 新员工入职清单：检查生产环境配置（负责人：Morgan，截止日期：Mar 5）

进展顺利之处：警报快速触发，团队在 5 分钟内响应，沟通良好

工作流

复制此清单并跟踪进度：

Postmortem Progress:
- [ ] Step 1: Assemble timeline and quantify impact
- [ ] Step 2: Conduct root cause analysis
- [ ] Step 3: Define corrective and preventive actions
- [ ] Step 4: Document and share postmortem
- [ ] Step 5: Track action items to completion

步骤 1：整理时间线并量化影响

收集事实：何时发现、何时开始、关键事件以及何时解决。量化影响：受影响的用户、持续时间、收入 / SLA 影响、客户投诉。对于简单事件，请使用 resources/template.md。对于涉及多个原因或级联故障的复杂事件，请参考 resources/methodology.md，了解高级时间线重建技巧。

步骤 2：开展根本原因分析

连续问 5 次“为什么？”，从症状追溯到根本原因；对于涉及多个促成因素的复杂事件，也可以使用鱼骨图。请参阅根本原因分析技巧了解指导。重点关注系统故障（流程缺陷、缺少防护措施），而非人为错误。

步骤 3：制定纠正和预防措施

针对每个根本原因，确定防止问题再次发生的措施。措施必须具体（不能只写“改进测试”）、明确负责人（指定人员）并设定时限（截止日期）。将措施分为即时修复和长期改进。请参阅纠正措施了解相关框架。

步骤 4：记录并分享事后复盘

使用模板创建事后复盘文档。内容包括时间线、影响、根本原因、措施以及进展顺利之处。广泛分享（面向工程、产品和领导层），以促进学习。在团队会议中进行介绍和讨论。归档到知识库。

步骤 5：跟进待办事项直至完成

指定负责人、设定截止日期，并添加到项目跟踪工具中。在每日站会或每周会议中检查进展。只有所有措施都完成后，才能结束事后复盘。使用 resources/evaluators/rubric_postmortem.json 自评质量。最低标准：平均分 ≥3.5。

常见模式

按事件类型划分

生产环境中断（系统故障、停机）：

• 时间线：发现 → 调查 → 缓解 → 解决
• 影响：受影响的用户、持续时间、SLA 违约、收入损失
• 根本原因：通常是配置错误、部署问题、基础设施限制
• 措施：改进监控、运行手册、回滚流程和容量规划

安全事件（泄露、漏洞）：

• 时间线：泄露发生 → 发现（通常有延迟） → 遏制 → 修复
• 影响：数据暴露、合规风险、声誉受损
• 根本原因：缺少安全控制、访问管理漏洞、未修补的漏洞
• 措施：安全审计、访问权限审查、补丁管理、培训

产品 / 项目失败（发布、截止日期）：

• 时间线：规划 → 执行 → 发布 / 截止日期 → 实际结果与预期对比
• 影响：收入未达预期、用户流失、精力浪费、机会成本
• 根本原因：需求不清、估算不切实际、目标不一致、测试不足
• 措施：改进需求探索、估算、利益相关方协同和验证流程

流程故障（运营、规程）：

• 时间线：流程启动 → 出现故障 → 影响显现
• 影响：延误、质量问题、返工、团队受挫
• 根本原因：流程不清晰、步骤缺失、交接失败、工具缺口
• 措施：记录流程、自动化工作流、改进沟通、开展培训

按根本原因类别分类

人为错误（表面原因，应深入调查）：

• 不要止步于“有人犯了错”
• 追问：为什么会发生这个错误？为什么没有发现？为什么没有防护措施？
• 措施：降低出错概率（检查清单、自动化），提高错误检测能力（测试、审查），减轻错误影响（回滚、冗余）

流程缺口（流程缺失或不明确）：

• 症状：“不知道要做 X”“操作手册中没有”“第一次遇到”
• 措施：记录流程、创建检查清单、正式确立审批关卡、开展入职培训

技术债务（维护工作被推迟）：

• 症状：“已知问题”“系统脆弱”“变通方案失效”
• 措施：优先处理技术债务，分配 20% 的产能，重构，替换旧系统

外部依赖（第三方故障）：

• 症状：“供应商服务中断”“API 调用失败”“合作伙伴出现问题”
• 措施：增加冗余、使用熔断器、优雅降级、监控 SLA、引入多家供应商

系统性问题（组织或文化层面的问题）：

• 症状：“总是很赶”“没有时间测试”“承受交付压力”
• 措施：解决组织层面的根本问题（不切实际的截止期限、资源限制、激励机制不一致）

根本原因分析技术

5 个为什么：

1. 从问题陈述开始
2. 询问“为什么会发生这种情况？”→ 回答
3. 询问“为什么会发生这种情况？”→ 回答
4. 重复 5 次（或直到找到根本原因）
5. 根本原因：可在组织或系统层面修复

示例：数据库中断 → 为什么？配置错误 → 为什么？值不正确 → 为什么？模板错误 → 为什么？新团队成员不熟悉 → 为什么？入职培训中没有配置审查

鱼骨图（石川图）：

• 类别：人员、流程、技术、环境
• 针对每个类别集思广益，列出原因
• 找出最有可能的根本原因，以便进一步调查
• 适用于有多个促成因素的复杂事件

故障树分析：

• 顶层：故障事件（例如“系统宕机”）
• 逻辑门：AND（所有条件都必须满足）与 OR（任一条件满足即可）
• 叶节点：基本原因（例如“配置错误”或“网络故障”）
• 从故障沿路径追溯至根本原因

纠正措施框架

措施类型：

• 即时修复：在几天内部署（热修复、手动流程、变通方案）
• 短期改进：在几周内完成（改进监控、更新操作手册、调整流程）
• 长期投入：在几个月内完成（架构调整、新系统、文化转变）

SMART 措施：

• 具体：“添加配置验证”，而不是“改进部署”
• 可衡量：“将 MTTR 从 2 小时缩短至 30 分钟”，而不是“加快响应”
• 可分配：指定负责人，而不是“团队”
• 现实可行：考虑产能和限制
• 有时限：明确截止期限

优先级排序：

1. 影响大、工作量小：立即处理
2. 影响大、工作量大：安排为战略项目
3. 影响小、工作量小：有空余产能时处理
4. 影响小、工作量大：考虑跳过（成本 > 收益）

预防层级（从最有效到最不有效）：

1. 消除：彻底移除危险（例如停用有风险的功能）
2. 替代：换用更安全的替代方案（例如使用托管服务，而非自行托管）
3. 工程控制：增加防护措施（例如速率限制、熔断器、自动化测试）
4. 管理控制：改进流程（例如操作手册、检查清单、审查）
5. 培训：对人员进行教育（单独使用时效果最差，应与其他措施结合）

防护准则

无责文化：

• ❌ “工程师部署了错误配置，导致服务中断” → ✓ “部署流水线允许错误配置进入生产环境”
• ❌ “PM 没有验证需求” → ✓ “缺少需求验证流程”
• ❌ “设计师犯了错误” → ✓ “设计评审流程未能发现问题”
• 关注：哪个系统／流程出了问题？而不是谁犯了错。

根因分析深度：

• ❌ 停留在表面：“Bug 导致服务中断” → ✓ 深入分析：“由于测试覆盖缺口、没有预发布环境，以及发布压力过大，Bug 被部署上线”
• ❌ 单一原因：“数据库故障” → ✓ 多重原因：“数据库故障 + 没有故障转移 + 告警延迟 + 操作手册不明确”
• 原则：不断追问“为什么？”，直到找到可采取行动的系统性改进措施

可执行性：

• ❌ 含糊：“改进测试”“加强沟通”“更加谨慎” → ✓ 具体：“在 4 月 1 日前添加端到端测试套件，覆盖使用量最高的 10 个用户流程（负责人：Alex）”
• ❌ 没有负责人：“团队应该编写文档” → ✓ 明确负责人：“Sam 在 3 月 15 日前编写事件响应操作手册”
• ❌ 没有截止日期：“以后再迁移” → ✓ 有明确时限：“在第 2 季度末前完成迁移”

量化影响：

• ❌ 定性描述：“许多用户受到影响”“服务中断时间很长” → ✓ 量化描述：“5 万名用户（用户总数的 20%）受影响，服务中断 2 小时，营收损失 2 万美元”
• ❌ 没有指标：“客户体验很差” → ✓ 量化指标：“NPS 从 50 降至 30，收到 100 个支持请求，5 名客户流失（ARR 损失 5 万美元）”

及时性：

• ❌ 等待 2 周 → 记忆淡去，紧迫感消失 → ✓ 在 48 小时内趁记忆犹新时开展复盘
• ❌ 从不跟进 → 行动被遗忘 → ✓ 跟踪行动项，每周检查，完成后关闭

快速参考

资源：

• resources/template.md - 复盘文档结构和章节
• resources/methodology.md - 无责文化、根因分析技巧和纠正行动框架
• resources/evaluators/rubric_postmortem.json - 复盘质量标准

成功标准：

• ✓ 时间线清晰，包含时间戳和关键事件
• ✓ 影响已量化（用户、时长、营收、指标）
• ✓ 已确定根因（系统性原因，而非归咎于个人）
• ✓ 纠正行动符合 SMART 原则（具体、可衡量、已分配、切实可行、有明确时限）
• ✓ 语气无责（关注系统／流程）
• ✓ 在 48 小时内完成记录并共享
• ✓ 行动项持续跟踪直至完成

常见错误：

• ❌ 责怪个人 → 形成恐惧文化，导致今后隐瞒问题
• ❌ 根因分析流于表面 → 无法防止问题再次发生
• ❌ 行动项含糊 → 实际上没有任何改进
• ❌ 缺少跟进 → 行动项始终未完成，同一事件再次发生
• ❌ 延迟复盘 → 细节被遗忘，复盘价值降低
• ❌ 不共享 → 无法促进组织学习
• ❌ 语气带有防御性 → 错失改进机会