Post-mortem 不是檢討大會，是讓系統變強的機會
一句話總結：Post-mortem 的目的是找出系統性問題並改善，不是找一個人來背鍋。
結論先講：如果你的 Post-mortem 是在找「誰犯了錯」，那人們就會傾向隱藏問題。真正的根因永遠不會浮出水面，同樣的事故一定會再發生。
Blameless 文化：不是聖母，是實用主義
Blameless Post-mortem 不是因為我們心地善良不想罵人，是因為怪罪個人沒有用。
想想看：如果一個工程師手動操作失誤導致了事故，你可以罵他、記過、甚至開除他。然後呢？下一個新人來了，面對同樣缺乏防護的系統，遲早會犯同樣的錯。
真正的問題不是「這個人犯了錯」，而是「為什麼系統允許一個人為的失誤就能造成嚴重事故？」
核心原則：
- 人會犯錯，系統不該依賴人不犯錯：如果一個手動操作能搞垮 production，問題在系統的防護不夠
- 討論 How 而非 Who：「這件事是怎麼發生的」比「是誰做的」有價值一百倍
- 鼓勵透明：讓所有人覺得安全，願意說出真相，包括自己的失誤
- 錯誤是學習機會：每一次事故都揭露了系統的弱點，這些知識無價
實務做法：Post-mortem 文件裡不寫人名，用角色描述（「on-call 工程師」、「部署者」）。會議由非直接相關的人主持。重點永遠放在行動項目——「我們要改什麼，讓這件事不會再發生？」
5 Whys：追問到你找到真正的根因
5 Whys 是最簡單也最有效的根因分析法。就是不斷問「為什麼」，從表面症狀挖到根本原因。
來看一個真實的例子：
- 為什麼服務中斷？ → 資料庫無法寫入
- 為什麼資料庫無法寫入？ → 磁碟空間滿了
- 為什麼磁碟滿了？ → 慢查詢日誌持續增長沒被清理
- 為什麼日誌沒被清理？ → logrotate 設定在上次遷移時遺漏了
- 為什麼 logrotate 會遺漏？ → 伺服器遷移的 checklist 裡沒有日誌管理的驗證項目
看到了嗎？表面上是「磁碟滿了」，根因其實是「遷移流程不完整」。如果你只處理表面問題——清理日誌、擴展磁碟——下次遷移的時候同樣的事情一定會再發生。
幾個使用原則：
- 從可觀察的事實出發，不是假設
- 答案如果還在技術層面，繼續追問。真正的根因通常是流程或文化層面的
- 不需要嚴格問五次，3-5 層看情況就好
- 每一層的答案都要有證據支持（日誌、指標、操作記錄）
Post-mortem 報告怎麼寫
一份好的 Post-mortem 報告包含：
摘要：2-3 句話交代發生什麼、影響多大、怎麼解決。讀完這段就能決定要不要繼續看細節。
影響：受影響時間、受影響的服務和使用者數量、業務影響（訂單流失、營收損失、有沒有違反 SLA）、有沒有資料遺失。
時間軸：按時間順序列出所有關鍵事件。這是 Post-mortem 的骨架——什麼時間發生了什麼事、做了什麼決定。
根因分析：直接原因 + 根本原因 + 5 Whys。
做得好的地方：不要只檢討缺點。哪些環節運作正常？告警有沒有及時？應對速度如何？這些正面的部分值得被記錄和強化。
需要改善的地方：哪些環節出了問題？
行動項目：每個都要有負責人、優先級、到期日、完成標準。
行動項目：Post-mortem 的靈魂
Post-mortem 最常見的失敗模式是：報告寫得很漂亮，行動項目沒人追蹤，然後同樣的事故再次發生。
我見過太多團隊寫了一份精美的 Post-mortem，列了八項行動項目，然後三個月後回頭看——完成了一項，其他七項不了了之。
怎麼防止？
- 行動項目必須建立在工作追蹤系統（Jira / Linear / GitHub Issues），不是只寫在文件裡
- 指定具體的負責人，不接受「大家一起做」
- 每週團隊會議花五分鐘回顧未完成的行動項目
- 追蹤完成率作為團隊的指標之一
災難復原演練：紙上談兵不算
Runbook 寫了、Post-mortem 做了、行動項目完成了。但你怎麼知道這些東西在真正出事的時候管用？
答案是：定期演練。
三個層級的演練：
桌面演練（每月）：團隊坐在一起，口頭走過一個事故情境。「假設主資料庫掛了，我們的流程是什麼？」不需要動手操作，但會暴露流程上的漏洞。
模擬演練（每季）：在 staging 環境中模擬真實故障。手動關掉一個服務，測試告警有沒有觸發、Runbook 能不能照做、團隊應對速度如何。
混沌工程（持續性）：在 production 環境中注入可控的故障。Chaos Monkey 隨機終止 Pod，看系統的自癒能力。這是最進階的做法，需要有足夠的冗餘和監控才能玩。
演練的幾個坑：
- 事先通知太多人：所有人都知道「今天下午三點演練」，就測不出真實的反應速度了
- 只練簡單的：永遠只模擬「重啟服務」，永遠不會發現複雜場景下的問題
- 練完不追蹤：演練發現了問題但沒修，下次演練又遇到同樣的問題——這比不練還慘，因為你知道問題在但選擇忽略
三個核心指標
整個事故管理流程最終要改善的就是三個數字：
- MTTD（Mean Time To Detect）：故障發生到被偵測的時間。改善方向：更好的監控和告警
- MTTR（Mean Time To Recovery）：偵測到恢復的時間。改善方向：更好的 Runbook、自動化修復
- MTBF（Mean Time Between Failures）：兩次故障之間的間隔。改善方向：落實 Post-mortem 行動項目、預防性維護
系列總結
三篇走完了事故管理的全貌：事故生命週期讓你知道流程、嚴重等級讓你分配資源、On-call 確保有人回應、Runbook 讓你高效修復、Post-mortem 讓你從錯誤中學習、DR Drill 確保一切都真的管用。
目標不是消除所有故障，而是建立一個能優雅地處理故障、並從每次故障中變得更強的系統與團隊。
系列文章：
- 事故管理（一）：事故生命週期與分級
- 事故管理（二）：Runbook
- 你在這裡 → 事故管理（三）：Post-mortem 與災難復原演練
延伸閱讀：
「每一次事故都是系統在告訴你它哪裡不夠強。聽不聽，看你自己。」