線上事故復盤報告怎麼寫：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 條評論
還沒有評論，來搶沙發～