轻量事故复盘
用途
事故结束后，把零散材料收成轻量复盘：时间线、影响、根因假设、可勾选行动项。
用于学习与改进，不是事中状态通报，也不是法务追责报告。
适用场景
- 适合：故障恢复后的快速复盘会；把值班笔记收成一页复盘。
- 不适合：事中故障通报（用状态短讯类技能）；正式长篇 RCA/审计报告；要求点名追责或编造唯一根因。
边界与差异化
- 参考：
incident-status-update、泛 RCA 模板。 - 本技能差异：事后；根因必须标「假设」；行动项可执行；禁止人身追责措辞。
怎么使用(普通用户)
在 AI 助手里直接说，例如：
- 「用轻量事故复盘整理下面这次超时故障」
- 「事故结束了，帮我写复盘：时间线、影响、行动项」
使用前必问
缺则追问：事故起止时间、影响范围（用户/金额/地区）、已知事实与仍不确定的点、是否已完全恢复。
使用步骤
- 写 3 行内摘要（发生了什么、多久、是否已恢复）。
- 列时间线（仅事实；不确定标「待确认」）。
- 写影响（用户侧/系统侧，能量化则量化）。
- 根因写「假设」并列出支持证据与反证缺口。
- 行动项：负责人角色 + 截止（无则待确认）；禁止空泛「加强重视」。
- 不使用羞辱性/追责性语言。
输出模板
## 轻量复盘 — {事故简称}
### 摘要
...
### 时间线
- HH:MM ...
### 影响
- ...
### 根因假设
- 假设：... — 证据：... — 待核实：...
### 行动项
- [ ] ... — 对接：... — 截止：...
### 待确认
1. ...
示例
输入：
昨晚 21:10 支付回调超时，约 2% 订单延迟入账；21:40 扩容后恢复。
怀疑连接池打满，还没看完整日志。无人员受伤式追责要求。
输出：
## 轻量复盘 — 支付回调超时
### 摘要
支付回调在约 21:10 出现超时，约 2% 订单延迟入账；约 21:40 经扩容后恢复。
### 时间线
- 21:10 观察到支付回调超时（来源：用户描述）
- 21:40 扩容后恢复（来源：用户描述）
- （中间排查步骤待补）
### 影响
- 约 2% 订单延迟入账；是否造成资金差错待确认
### 根因假设
- 假设：连接池打满导致回调处理阻塞 — 证据：目前仅为怀疑 — 待核实：连接池指标与完整日志
### 行动项
- [ ] 导出并审阅事故窗口连接池/线程指标 — 对接：值班后端 — 截止：待确认
- [ ] 补齐时间线中的告警与操作记录 — 对接：值班 — 截止：待确认
- [ ] 评估回调重试与幂等是否覆盖延迟入账 — 对接：支付负责人 — 截止：待确认
### 待确认
1. 准确起止时间与时区？
2. 延迟入账是否已全部补齐？
3. 扩容具体对象（哪类实例/配置）？
常见问题(FAQ)
- 和事中通报有何不同？ 通报面向「现在怎样」；复盘面向「为何与如何改进」。
- 根因不确定怎么办？ 标假设 + 待核实，不写成定论。
- 能写谁的责任吗？ 不写人身追责；只写系统与流程改进项。
已知限制
- 不拉取监控/日志系统。
- 中文交互；不依赖海外 API。
