🎯 什麼情境該想到我
分工：《DevOps 手冊》怎麼把事後檢討擴散到整個組織 → 廣泛公開事後檢討。這張補一份可以直接用的模板、寫法上的具體規則，以及好的行動項長什麼樣子。
當事故發生後，你想「真正學到教訓、避免重演」，而不是找戰犯讓大家更不敢說真話時。
⚙️ 怎麼用
- 前提假設：每個人在當下都是基於已知資訊做出合理判斷——問題出在系統與流程，不是壞人。
- 重建時間線：事實導向地還原「發生了什麼、何時、當事人當下看到什麼」。
- 追系統性成因，不追個人責任：問「什麼樣的系統/流程讓這個錯誤變得可能且不易發現」。
- 產出可執行的改善項：加護欄、補監控、改流程，並追蹤落實。
- 公開分享：把教訓擴散到整個組織，把學習制度化。
★ 事後檢討文件的模板
# 事後檢討：<一句話描述，例：9/12 訂單 API 錯誤率 30%，持續 42 分鐘>
## 摘要（三句話）
發生了什麼、影響多大、怎麼恢復的。
## 影響
- 時間：09:14–09:56（42 分鐘）
- 範圍：約 30% 的下單請求失敗；估計影響 1,200 位使用者
- 錯誤預算：消耗本月 18%
## 時間線（全部用同一個時區）
| 時間 | 事件 | 資訊來源 |
|---|---|---|
| 09:02 | 部署 v2.41.0（含連線池設定變更） | 部署紀錄 |
| 09:14 | 錯誤率開始上升 | 監控圖表 |
| 09:21 | 告警觸發，值班人員收到通知 | 告警系統 |
| 09:30 | 值班人員懷疑資料庫，檢查慢查詢（沒有發現） | 事後訪談 |
| 09:48 | 注意到部署時間與錯誤開始時間吻合，決定回滾 | 聊天紀錄 |
| 09:56 | 回滾完成，錯誤率恢復正常 | 監控圖表 |
## 促成因素（不是「根本原因」，通常有好幾個）
1. 連線池上限從 50 改成 5（設定檔的單位誤解）
2. 設定變更沒有在預備環境以正式環境的流量測試
3. 儀表板沒有顯示「最近的部署」，讓值班人員花了 18 分鐘才聯想到部署
## 做得好的地方
- 告警在 7 分鐘內觸發
- 回滾程序順利，8 分鐘完成
## 行動項
| 行動 | 類型 | 負責人 | 期限 | 追蹤單 |
|---|---|---|---|---|
| 連線池設定加上合理範圍的驗證（< 10 時拒絕啟動） | 預防 | @alice | 9/20 | #812 |
| 儀表板加上部署標記 | 偵測 | @bob | 9/19 | #813 |
| 部署後 10 分鐘內錯誤率上升時自動回滾 | 緩解 | @carol | 10/1 | #814 |★ 寫法規則：讓文件保持「無指責」
| 避免 | 改成 | 為什麼 |
|---|---|---|
| 「Alice 應該要檢查……」 | 「設定變更的流程沒有要求……」 | 「應該」是事後諸葛；當下的人不知道事後才知道的事 |
| 「人為疏失」 | 描述當時的決策與依據的資訊 | 「人為疏失」是調查的起點，不是結論 |
| 「根本原因是……」（單一） | 「促成因素」（多個） | 複雜系統的事故幾乎都有多個因素同時成立 |
| 「他沒注意到……」 | 「儀表板沒有顯示……」 | 把問題從人身上移到系統上，才能改善 |
核心提問從「誰做錯了」換成「當時看到的資訊，為什麼讓這個決定顯得合理？」——這個問題的答案，才指向可以改善的系統缺陷。
★ 好的行動項：預防、偵測、緩解三種都要有
| 類型 | 目的 | 例子 |
|---|---|---|
| 預防 | 讓這類錯誤無法發生 | 設定驗證、型別檢查、權限限制 |
| 偵測 | 發生時更快發現 | 告警、儀表板、部署標記 |
| 緩解 | 發生時影響更小、恢復更快 | 自動回滾、功能開關、限流 |
好的行動項要具體、有負責人、有期限、有追蹤單。「加強注意」「提升意識」「多做測試」都不是行動項——它們無法被驗證是否完成。
★ 「5 個為什麼」的限制
「問 5 次為什麼」容易把分析導向一條線性的因果鏈，最後停在某個人的決定上。複雜系統的事故更像是好幾個條件同時成立（上面例子的三個促成因素，少了任何一個都可能不會發生或更快被發現）。用「還有什麼因素讓這件事發生或惡化」取代「為什麼」，比較不會漏掉。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
-
一旦開始究責，人就會隱藏資訊、事故根因永遠查不清——心理安全是前提（見 工具-心理安全感）。
-
無指責不等於沒有責任：它針對的是誠實的錯誤。故意違規、刻意繞過安全機制屬於另一種處理。區分的目的是讓人敢說出真實經過，而不是讓所有行為都免責。
-
沒有追蹤的行動項等於沒寫：在下次事後檢討前，回頭檢查上次的行動項完成了多少。
🔗 相關工具
- 工具-遙測與監控 —— 檢討的原料，沒有時間軸與指標就只能靠記憶推測事故經過
- 工具-區分修復與掩蓋症狀 —— 檢討的品質關卡，行動項是真修根因還是只是加了個 retry
- 工具-三步工作法 —— 上位框架，事後檢討落在第二步「回饋」與第三步「持續學習」的交界