事故复盘、失败方案与组织学习
事故复盘用事实还原影响、时间线和促成条件，再把结论转化为有负责人、优先级和验证方式的改进行动。
1. 先定义需要复盘的事件
团队应在事故前确定触发条件，例如：
- 用户可见中断或性能退化超过阈值；
- 数据丢失、错误写入或安全事件；
- 需要人工回滚、切流或紧急修复；
- 恢复时间超过目标；
- 监控未发现、但用户已经报告的问题；
- 险些造成严重影响的 near miss。
统一标准避免复盘取决于负责人意愿。任何相关方仍可以为异常复杂或有普遍学习价值的事件提出复盘。
事故指挥与复盘写作是两个阶段。恢复期间优先控制影响并保存证据，不在高压现场寻找责任人或完整根因。
2. 用时间线建立共同事实
时间线记录事件发生、检测、判断、操作、状态变化和恢复，来源包括监控、日志、变更记录、聊天和工单。
每个时间点写清：
- 当时观察到了什么；
- 操作者掌握哪些信息；
- 做了什么决定；
- 系统产生什么结果。
区分事件时间和发现时间。数据库在 10:00 开始丢数据、团队在 10:20 才发现，这二十分钟本身就是检测缺口。
无法确认的内容标为未知，不为填满时间线而猜测。后续证据可以更新事实，但要保留来源。
3. 影响使用用户和业务口径
“服务异常 30 分钟”缺少影响范围。复盘应量化：
- 受影响用户、请求或租户数量；
- 错误、延迟和不可用持续时间；
- 数据丢失、重复或陈旧范围；
- 收入、履约、合规和客服影响；
- 是否触发 SLA 或消耗错误预算。
技术指标与业务结果要互相校验。整体错误率只有 1%，可能意味着一个地区或一个大客户完全不可用。
4. 分析促成条件
复杂事故通常由多个条件共同形成：设计假设、代码缺陷、容量、配置、发布、监控、文档、权限和组织交接都可能参与。
“某人执行了错误命令”只描述触发动作。还需要继续问：
- 为什么命令允许作用于全部目标；
- 为什么没有 dry-run、审批或范围限制；
- 为什么监控无法提前发现；
- 为什么恢复步骤依赖个人记忆；
- 当时的时间压力和信息怎样影响判断。
复盘采用无责语言，假设参与者基于当时信息做了合理判断。无责不取消责任：系统 owner 仍要负责改进，故意违规和人事问题由独立流程处理。
5. 同时记录有效与失效的防线
一场事故会经过预防、检测、缓解和恢复多层防线。复盘分别说明：
- 哪些防线按设计工作；
- 哪些防线存在但没有触发；
- 哪些环节完全缺少保护；
- 哪些偶然条件减小了影响。
“运气好”也要记录。例如故障发生在低峰期，说明高峰期影响可能更大，容量和响应计划需要按更坏场景验证。
同时保留有效行动，避免修复一项问题时移除原本有价值的保护。
6. 行动项覆盖不同阶段
行动项可以分为：
- 预防：消除触发条件或缩小可操作范围；
- 检测：增加用户 SLI、数据差异和变更告警；
- 缓解：限流、隔舱、降级和自动回滚；
- 恢复：改进备份、runbook、权限和工具；
- 学习：更新设计规范、培训和演练场景。
每项都需要明确动作、负责人、优先级、截止时间、追踪项和可验证结束状态。“加强监控”“提高意识”无法验收。
高优先级行动进入正式产品或工程计划，不能只留在复盘文档。复测或演练确认措施有效后再关闭。
7. 失败方案也值得复盘
没有造成生产事故的技术方案，也可能消耗大量时间并暴露决策问题。失败方案复盘关注：
- 原始目标和约束；
- 当时有哪些假设和证据；
- 哪个信号证明方向不再成立；
- 为什么没有更早停止；
- 哪些资产、工具或结论可以复用；
- 下次决策需要增加什么验证或退出条件。
不要用结果倒推当时的人必然判断错误。关键是检查信息收集、实验设计、阶段目标和停止机制。
及时停止一项低价值方案是一项正确决策。将失败隐藏到“需求变化”中，会让其他团队重复相同成本。
8. 从单次事故发现系统问题
统一模板和标签可以聚合多次复盘，识别重复主题，例如变更造成的故障、权限缺口、同一依赖频繁超时或行动项长期未完成。
跨团队分享时保护用户隐私和敏感安全信息，同时保留足够的技术细节。相似服务可以把事故场景加入故障演练、架构检查和上线清单。
如果同类事故重复出现，先检查旧行动项是否完成和有效，再决定更大范围重构。继续新增告警，却不关闭已知根因，只会增加值班负担。
9. 复盘完成需要闭环
复盘至少经过作者、事件参与者和相关系统负责人评审。完成标准包括：
- 影响和时间线有证据；
- 促成条件足够深入；
- 行动项有所有者与验收；
- 重要结论已向受影响团队分享；
- 高风险措施已进入排期；
- 后续复测或演练已经安排。
文档发布只是中间步骤。行动项关闭率、重复事故和错误预算改善，才反映复盘是否产生了组织学习。
10. 面试题
10.1 怎样复盘一次由发布引起的线上事故
出现公司：字节跳动
考察重点
- 用户影响、证据时间线和促成条件。
- 无责分析与明确责任的关系。
- 可执行行动项、复测和跨团队学习。
相关内容：第 1 节“先定义需要复盘的事件”至第 9 节“复盘完成需要闭环”。
参考回答
恢复服务后，我会先保存监控、日志、变更和沟通证据，按事件时间与发现时间建立时间线，并用受影响用户、业务结果、数据和错误预算量化影响。分析时从触发动作继续追到设计、发布、权限、监控、文档和组织交接等促成条件，采用无责语言，同时让系统 owner 对改进行动负责。
行动项覆盖预防、检测、缓解和恢复，每项都有负责人、优先级、期限和可验证结果；高风险项进入正式排期，并通过测试或演练复核。复盘经参与者和相关团队评审后广泛分享，再聚合历史事故查找重复模式。文档发布不算完成，行动项关闭和同类事故减少才算形成闭环。