05 软件工程综合实践：做一次能改变规则的复盘

TL;DR：本篇用一个完整案例串起全专栏方法——为一次线上事故做端到端复盘。流程：无责时间线 → 促成条件与系统防线 → PDSA 对照假设 → 判断更新深度 → 产出可审阅的行动项与复查记录。最终产出是一页“复盘决策记录”，让未参与者能复述因果逻辑、判断更新是否到位。判断复盘是否有效，不看文档长度，看行动项是否改变了规则或信息流、复发率是否下降。

概念解释

什么是“能改变规则的复盘”

大多数复盘止于“总结经验教训”——它产出一句话“下次注意”，但不改变任何规则、信息流或结构。能改变规则的复盘至少产出一项可验证的系统层更新（改信息流、激励或结构），使同类问题在框架层面被抑制，而非靠每次提醒。这要求复盘从单环进入双环甚至系统学习（见 单环、双环与系统学习：更新哪一层）。

与决策权衡专栏的衔接

软件工程综合实践：做一次可复盘的技术选型 串起了“决策前”的全流程（门判断→矩阵→Premortem→ADR）。本篇串起“行动后”的全流程（时间线→防线→PDSA→学习深度→行动项）。两篇构成“决策—行动—学习”的完整闭环。

目录

案例与系统边界

某团队订单服务配置发布后发生缓存雪崩，影响持续 40 分钟。朴素做法是开会说“工程师配置错误，已培训”。按本专栏方法，先定边界：复盘范围覆盖从配置发布到恢复的全过程，纳入配置系统、告警、回滚流程和值班权限，而非只看“配置这一个人”。

串起全流程

串联逻辑：时间线（①）→ 促成条件（②）解释行为为何合理 → 系统防线（③）定位缺口 → PDSA（④）判断假设是否错 → 学习深度（⑤）决定改哪层 → 行动项（⑥）产出可追踪更新。如果 ⑤ 只到单环，⑥ 就只有“培训”；如果到系统层，⑥ 会改变信息流和结构。

一页复盘决策记录

这是本专栏的最终交付物，一页纸，可照着执行与审阅：

验收标准：行动项中至少 3 条是系统层（改变信息流/结构），而非只有规则层（“必须做X”）或动作层（“下次注意X”）。系统层行动项让正确行为成为默认，而非靠人记忆。

验收标准

复盘是否有效，看四件事：

1. 事实与解释分离：时间线只有事实，解释标注为“假设”。
2. 系统层更新：至少一条行动项改变信息流或结构，而非只改规则或动作。
3. 行动项可追踪：每条有负责人、复查日期和验证方式。
4. 复发率下降：同类事故在复查期内是否复发——这是复盘效果的真实度量。

满足前三条是复盘“合格”；第四条是复盘“有效”。只满足“写了文档”，仍属走过场。

适用边界

• 不是每次事故都需要完整流程：简单故障用 AAR 四问即可，完整无责复盘留给高影响事故。
• 不是复盘万能：复盘提取的因果假设，关键关系仍需 实验设计：AB 测试、灰度与消融实验 验证。
• 行动项不能代替系统改造：如果复盘发现根因是架构耦合或能力缺失，行动项应指向系统改造而非临时补救。
• 复盘记录不等于客观真理：它让因果逻辑可被审阅，但不保证结论永久正确——下一轮事故可能推翻本轮模型。

关联笔记

• 复盘与学习总览：从行动结果到能力更新（复盘四要素与三层更新）
• 无责复盘：从时间线到系统防线（无责复盘的完整流程）
• PDSA 循环：从预测到研究的知识生成（PDSA 对照假设与实际）
• AAR 与迭代回顾：简洁高效的行动后学习（轻量复盘形式）
• 单环、双环与系统学习：更新哪一层（行动项的杠杆层次）
• 软件工程综合实践：做一次可复盘的技术选型（决策与权衡专栏的综合实践，本篇是其行动后闭环）
• 软件工程综合实践（系统思维专栏的端到端实践）

参考资料

• Postmortem Culture: Learning from Failure — Google SRE
• PDSA Cycle — The W. Edwards Deming Institute
• Double Loop Learning in Organizations — Chris Argyris, HBR
• DORA's software delivery performance metrics
• 《超预测》（原著 Superforecasting）— Philip E. Tetlock & Dan Gardner