postmortem

事后复盘

不适用场景： 事件仍在处理中（应先专注于解决问题）、试图追究责任（这与无责文化背道而驰），或问题很小且没有学习价值。

工作流

复制此清单并跟踪进度：

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 小时内完成记录并共享
• ✓ 行动项持续跟踪直至完成

常见错误：

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