编程开发 编辑复核
线上事故复盘与证据链
把日志、时间线和处置记录整理成可验证的事故复盘,区分事实、影响、假设与后续动作。
PROMPT WORKBENCH
复制后替换变量
保留结构,先填真实信息,再把结果交给模型运行。
你是一名可靠性工程复盘主持人。请将给定的日志、告警、变更和沟通记录整理成不甩锅、可复核的事故报告。
先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。
请按以下结构输出:
1. 按时间排序并给每个节点附证据
2. 量化受影响的功能、用户和时间范围
3. 区分直接原因、促成因素与尚未证明的假设
4. 列出已采取的缓解措施及其结果
5. 给出带负责人、优先级和验收条件的行动项
输入变量:
- 事故材料({{incident_materials}}):粘贴脱敏后的日志、告警、变更和沟通记录。
- 服务范围({{service_scope}}):说明服务、地区、版本和受影响时间段。
- 已知影响({{known_impact}}):提供已经确认的错误率、延迟或用户反馈。
约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 先把原始时间戳统一成同一时区,再让模型归纳。
- 没有日志支持的根因只能进入假设清单,不能写成结论。
WHEN IT FITS
适用判断
适合这些情况
- 已经有多种记录但缺少统一时间线。
- 需要让技术、产品和客服共享同一份事实。
- 要把复盘转成可验收的改进任务。
换个做法更好
- 事故仍在持续:先用应急指挥清单,不要边抢修边写长报告。
- 涉及法律取证:交给法务和安全团队保全原始证据。
- 只有一句错误描述:先补充监控和日志。
FAILURE MODES
常见翻车与修正
- 报告把推测写成根因。
要求每个根因结论引用日志或变更证据,并把无法证明的内容单列为假设。
- 行动项没有验收标准。
为每项补充负责人、截止时间、可观察指标和回归验证。
ACCEPTANCE
怎么判断输出合格
- 时间线能回到原始记录。
- 影响范围与根因假设分开。
- 行动项有负责人、期限和验收指标。
- 报告没有凭据、个人信息或未经确认的指责。
SAFETY BOUNDARY
使用边界
- 日志粘贴前移除 token、邮箱、IP 和订单号等敏感字段。
- 事故报告不应暴露可直接利用的漏洞细节,安全事件另走受控渠道。