编程开发 编辑复核

线上事故复盘与证据链

把日志、时间线和处置记录整理成可验证的事故复盘,区分事实、影响、假设与后续动作。

场景:线上故障、数据异常和服务中断复盘输出:事故时间线 + 影响评估 + 根因假设 + 行动项更新于 2026-08-14

复制后替换变量

保留结构,先填真实信息,再把结果交给模型运行。

你是一名可靠性工程复盘主持人。请将给定的日志、告警、变更和沟通记录整理成不甩锅、可复核的事故报告。

先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。

请按以下结构输出:
1. 按时间排序并给每个节点附证据
2. 量化受影响的功能、用户和时间范围
3. 区分直接原因、促成因素与尚未证明的假设
4. 列出已采取的缓解措施及其结果
5. 给出带负责人、优先级和验收条件的行动项

输入变量:
- 事故材料({{incident_materials}}):粘贴脱敏后的日志、告警、变更和沟通记录。
- 服务范围({{service_scope}}):说明服务、地区、版本和受影响时间段。
- 已知影响({{known_impact}}):提供已经确认的错误率、延迟或用户反馈。

约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。

使用说明

  1. 先把原始时间戳统一成同一时区,再让模型归纳。
  2. 没有日志支持的根因只能进入假设清单,不能写成结论。

适用判断

适合这些情况

  • 已经有多种记录但缺少统一时间线。
  • 需要让技术、产品和客服共享同一份事实。
  • 要把复盘转成可验收的改进任务。

换个做法更好

  • 事故仍在持续:先用应急指挥清单,不要边抢修边写长报告。
  • 涉及法律取证:交给法务和安全团队保全原始证据。
  • 只有一句错误描述:先补充监控和日志。

常见翻车与修正

  • 报告把推测写成根因。

    要求每个根因结论引用日志或变更证据,并把无法证明的内容单列为假设。

  • 行动项没有验收标准。

    为每项补充负责人、截止时间、可观察指标和回归验证。

怎么判断输出合格

  1. 时间线能回到原始记录。
  2. 影响范围与根因假设分开。
  3. 行动项有负责人、期限和验收指标。
  4. 报告没有凭据、个人信息或未经确认的指责。

使用边界

  • 日志粘贴前移除 token、邮箱、IP 和订单号等敏感字段。
  • 事故报告不应暴露可直接利用的漏洞细节,安全事件另走受控渠道。