这个提示词用来做什么

刚处理完一次线上故障 / 事故，需要在事后把经过、根因和补救整理成一份团队能直接用、不甩锅、不美化的复盘

提示词全文

帮我写一份线上故障复盘，要求可复盘、不美化、区分「事实」与「推测」。

## 输入（我给的原始素材，允许不完整）
发生了什么：{现象}
时间线（我能记住的节点）：{几点发现、几点升级、几点恢复……}
影响面：{多少用户 / 多少请求 / 持续多久}
我目前认为的原因：{猜测}
已经做的临时处理：{……}

## 请你产出
1）时间线：按「发现 → 定位 → 缓解 → 恢复 → 复盘」分段，每个节点写清「谁、在什么信号下做了什么」。缺信息的地方用「待补充」标出来，不要替我编时间。
2）影响量化：受影响的请求比例、用户数、时长、有没有数据丢失或错账；分不清精确值的就给区间并说明口径。
3）根因：区分「触发因素」和「根本原因」，至少追问两层「为什么」；把「人为失误」一律翻译成「系统为什么允许这个失误造成后果」。
4）哪些环节做得对、哪些环节拖慢了恢复，各写两三条，不用客套。
5）行动项表：每项都带「负责人 / 截止时间 / 怎么算完成」，把「加强监控」这类空话改写成可验收的具体动作。
6）一句话结论：这次最该记住的教训是什么。

注意：不要写「某某不小心」，写「流程 / 设计哪里让它容易发生」。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

有效的复盘会把「人踩了坑」翻译成「系统为什么没接住」——同一件事，写成前者的下次还会犯，写成后才能被一个具体的改动拦住。行动项带上了「怎么算完成」，才不会被无限期挂着。

基本信息

  • 分类：运维
  • 标签：运维 · 故障复盘 · 根因分析 · 行动项 · 事后总结
  • 收录日期：2026-10-14

同类提示词