编程开发 编辑复核
线上事故复盘与改进项
用时间线、影响、检测、响应和根因证据复盘事故，避免追责式叙事和把单一相关性写成根因。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名可靠性复盘负责人。请基于日志、监控和人员访谈复盘事故，关注系统条件和可预防的改进，不把责任归因替代事实分析。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 定义影响用户、影响窗口、检测和恢复时间
2. 按时间线记录信号、决策、动作和证据
3. 区分直接触发、促成条件、检测缺口和恢复阻力
4. 列出负责人、优先级、验收指标、截止时间和复盘日期
输入变量：
- 事故描述（{{incident}}）：提供用户可观察现象和影响范围。
- 时间线证据（{{timeline}}）：提供日志、监控、发布和响应时间。
- 响应记录（{{response}}）：提供采取的措施和未采取的措施。
- 已有改进项（{{followups}}）：说明已登记的修复和负责人。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先冻结事实和时间线，再讨论原因。
- 改进项必须可验收，下一次复盘时检查是否真的降低风险。
WHEN IT FITS
适用判断
适合这些情况
- 事故已经处理完，服务恢复稳定，可以回头分析。
- 有时间线记录和相关日志，能还原事发经过。
- 希望产出的是可落地的改进项，而不是责任认定。
换个做法更好
- 事故还在处理中：先恢复服务。
- 你要做的是产品发布的复盘：用《发布活动复盘》。
- 组织氛围会把复盘变成追责：那样拿到的信息不可靠，先解决这个问题。
FAILURE MODES
常见翻车与修正
- 根因写成「某某人操作失误」。
人为失误通常是系统缺少防护的表现。要求追问「什么机制允许这个操作造成这个后果」，把根因落到流程或系统。
- 时间线里的时间点是模型补的，和实际记录对不上。
要求所有时间点来自你提供的记录，缺失的标「时间未知」而不是估算。
- 改进项写成「加强监控」这类无法验收的动作。
要求每条改进指定具体动作、负责人、完成时间和验收标准，做不到这四项的改成待细化。
ACCEPTANCE
怎么判断输出合格
- 根因落在系统或流程层面，不是归咎个人。
- 时间线全部来自实际记录，没有估算的时间点。
- 改进项有负责人、时间和验收标准。
- 区分了直接原因、根本原因和放大影响的因素。
SAFETY BOUNDARY
使用边界
- 复盘材料含故障细节和系统弱点，对外披露前要做脱敏和范围确认。
- 根因分析要基于日志和时间线证据，模型补出的因果链在没有数据支撑时不能写入结论。