多人排障时，重复调查和口头结论会消耗时间。建立一份共享记录，把观察、假设、动作与结果写在一起。以下是通用工作方法，不描述任何真实组织的事故。
01 / 开场先写可核对的事实
- 现象：用户请求失败、延迟升高或任务积压，说明测量方式。
- 影响：服务、区域、时间窗口和范围，未确认的范围标为待核实。
- 分工：由谁协调、谁执行操作、谁维护记录与更新进展。
- 目标：先恢复哪些能力，下一次检查点是什么时候。
“数据库有问题”是一个待验证假设。可以改写为“某查询的 P95 在指定窗口升高，同时连接池等待增长”，给出证据位置与时间。
02 / 时间线保留每次判断的输入
统一时区，记录观察与动作。下面是虚构格式示例，可按团队实际流程调整。
text
时间（UTC） | 观察 / 假设 | 采取的动作 | 结果 / 后续
09:00 | 入口 5xx 上升 | 核对两个区域的指标 | 仅区域 A 异常
09:05 | 怀疑新版本 | 对比新旧版本日志 | 旧版本暂未出现同类错误
09:10 | 评估回退条件 | 确认数据库兼容性 | 回退前置条件满足时间相关并不自动意味着因果关系。给假设记录支持证据、反证和下一步验证，避免从第一条线索直接跳到根因结论。
03 / 恢复与根因分别验收
恢复验收关注用户功能、错误率、延迟与积压是否回到可接受状态。根因调查需要解释触发条件、传播路径和为什么现有保护没有阻断故障。暂未查明的地方明确写出，不用推测补齐事实。
04 / 把行动项写成可完成的任务
为每个改进项指定负责角色、期限和验证标准。“加强监控”可以具体为“为连接池等待增加监控，在测试环境复现并确认告警能定位服务”。避免只要求个人更小心；优先改进系统约束、回退能力和信息可见性。
公开复盘时，只保留通用机制、示例命令与方法。去掉真实访问凭证、内部地址、客户数据、业务规模和未公开组织细节。日志截图与命令输出同样需要检查。
参考资料
END OF NOTE / 数据与可靠性查看文章源文件 ↗