线上事故复盘报告怎么写：Postmortem 提示词（时间线、根因、改进项，无责复盘）
线上故障处理完、要写复盘文档时用：把聊天记录、告警和处理过程整理成结构完整的事故报告，根因追到流程和系统层面，改进项可执行、有负责人和期限，而不是写成检讨书。
通用大模型 对话模型通用
请把下面的材料整理成一份事故复盘报告（Postmortem）。采用无责复盘原则：分析系统、流程和工具为什么允许这个错误发生，不追究个人，不出现「某某粗心」这类表述。 材料： - 事故概述：[一句话描述发生了什么] - 影响范围：[受影响的用户、功能、时长、数据] - 处理过程中的聊天记录、告警记录、操作日志（按原样粘贴即可）： [粘贴材料] - 已知的直接原因：[如某次配置变更] - 团队的严重程度定级标准：[没有就写无] 报告结构： 1. 摘要：3 到 5 句，写清发生了什么、影响多大、怎么恢复的、主要原因。 2. 影响：用数字写，例如受影响请求比例、持续分钟数、涉及订单数；材料里没有的数字标「待补充」，不要估算。 3. 时间线：表格，列为 时间 | 事件 | 信息来源。区分四个关键时间点：问题开始、被发现、开始处理、恢复。计算发现耗时和恢复耗时。 4. 根因分析： - 直接原因（触发因素）； - 用「5 个为什么」继续往下问，至少追到一个流程或系统层面的原因，例如「变更没有经过灰度」「告警阈值设得太宽」； - 有多个促成因素时分别列出。 5. 做得好的地方与运气成分：哪些措施减轻了影响；哪些情况只是碰巧没变得更糟。 6. 改进项：表格，列为 改进项 | 类型（预防 / 发现 / 缓解）| 负责人 | 期限 | 优先级。每条必须具体可验证，例如「给支付回调接口加错误率告警，阈值 1%」，不能写「加强监控」「提高意识」。负责人和期限我没提供的留空。 7. 待确认的问题：材料中矛盾或缺失的信息。 语言要求：客观陈述，时间统一写成 24 小时制并注明时区。
高亮处换成你自己的内容：[一句话描述发生了什么]、[受影响的用户、功能、时长、数据]、[粘贴材料]、[如某次配置变更]、[没有就写无]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[粘贴材料] 不用整理，群聊记录、告警截图里的文字、值班记录直接贴，让 AI 来排时间线。贴之前把用户手机号、内网地址、密钥等敏感信息替换掉。
常见坑：
- 根因只写到「某人改错了配置」就停下，这是最常见的问题。继续问「为什么改错的配置能直接上线」「为什么十几分钟后才发现」，才能得到有价值的改进项。
- 改进项写成「加强代码审查」「提高安全意识」这类口号，复盘会开完就没人跟进。要求每一条都能在一个月后检查「做了没有」。
- AI 会根据上下文「补全」影响数字，所以模板里要求缺失的数字标待补充，审稿时重点核对数字。
追问技巧：初稿出来后追问「站在一个没参与处理的同事角度，哪些地方看不懂或证据不足」；改进项太多时追问「按投入产出排序，选出最该先做的 3 条」。
示例输出
示例，仅供参考（节选）
摘要：10 月 3 日 14:05 至 14:47（北京时间），支付回调接口因配置变更导致验签失败，约 18% 的订单支付成功后状态未更新。回滚配置后恢复，事后补单完成。
| 时间 | 事件 | 来源 |
|---|---|---|
| 14:05 | 发布新版网关配置（问题开始） | 发布记录 |
| 14:21 | 客服反馈「付了钱订单还是待支付」（被发现，耗时 16 分钟） | 客服群 |
| 14:47 | 回滚配置，回调恢复（恢复，耗时 42 分钟） | 操作日志 |
根因：直接原因是新配置漏掉了回调地址的白名单。为什么能上线？配置变更不走灰度、也没有自动化校验。为什么 16 分钟后才发现？回调失败没有告警，只能靠客服反馈。
| 改进项 | 类型 | 负责人 | 期限 | 优先级 |
|---|---|---|---|---|
| 支付回调失败率超过 1% 持续 2 分钟即告警 | 发现 | 高 | ||
| 网关配置变更先在 5% 流量灰度 10 分钟 | 预防 | 高 |
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～