失敗的代價就是教育。 — Devin Carraway
在 SRE 規模下，事件是必然。沒有從事件中學習的正式流程，事件會無限重演——複雜度疊加、衝擊放大，最終淹沒系統與運維者。
事後檢討（postmortem）即是這個學習機制的文件化呈現：記下事件、衝擊、緩解、根因與防止再發的後續行動。
Google 的事後檢討哲學#
何時要寫#
在事件發生之前就把觸發條件定義清楚。常見觸發：
- 使用者可見的宕機或退化超過門檻
- 任何形式的資料遺失
- On-Call 工程師手動介入（如回滾、流量切換）
- 解決時間超過門檻
- 監控失效（通常意味著靠人發現故障）
任何利害關係人也可主動要求寫事後檢討。
無究責（Blameless）是核心信條#
真正的無究責事後檢討聚焦於找出造成事件的系統性因素，不指控任何個人或團隊。
假設：所有人在當下都基於手上的資訊做出了善意的選擇。
來源：醫療與航空業——「錯誤可能致命」的領域，把每個錯誤視為強化系統的機會。
- 你不能「修正人」，但可以修正系統與流程，幫助人在複雜系統中做出對的決定
- 一旦充滿究責與羞辱，人們會為了避免懲罰而把問題藏起來——更危險
對照範例#
❌ 究責式：「我們得把那個複雜後端重寫！過去三季每週都壞，再被 page
一次我自己重寫…」
✅ 無究責：「把後端重寫的行動項目可能可以根除這類煩人 page；目前的
維護手冊很長、難以充分培訓——未來的 On-Caller 會感謝我們。」不究責不代表「不檢討」。要明確指出哪裡可以改進、哪些系統需要強化——只是焦點是事件而非個人。
協作與分享知識#
事後檢討文件的工具選擇要點：
- 即時協作：快速蒐集資料與想法
- 開放式留言 / 註解：眾人補完
- email 通知：拉相關人進來
工作流程通常分兩步：
- 內部初審：請資深工程師檢視
- 關鍵事件資料是否完整保存？
- 衝擊評估是否完整？
- 根因是否挖得夠深？
- 行動計畫是否合宜？bug 修復優先級對嗎？
- 是否與相關利害關係人分享了結果？
- 廣泛分享：通常給整個工程團隊或內部 mailing list
未經審查的事後檢討形同沒寫過——團隊應定期辦事後檢討審查會，確保草稿被關閉、想法被捕捉、狀態被定稿。
完成後加入團隊或組織的事件資料庫，便於日後檢索與學習。
導入事後檢討文化#
文化需要持續培育與強化。管理層的積極參與是強力訊號，但理想上文化最終由工程師自發推動。
具體活動：
- 本月最佳事後檢討：月報精選分享
- Google+ 事後檢討小組：分享內外部事後檢討、討論最佳實踐
- 事後檢討讀書會：定期挑一份有趣或有影響力的事後檢討，搭配茶點開放討論——通常是幾個月甚至幾年前的事件
- Wheel of Misfortune：新進 SRE 重演舊事件，由當時的 IC 出席讓體驗逼真
導入時的挑戰與對策：
- 質疑 ROI：先做試行，幾份成功案例做佐證
- 沒人想寫：把「寫好事後檢討」當成被獎勵的行為（社群表彰 + 績效）
- 取得高層支持：Larry Page 本人都會在公司全員大會強調事後檢討的價值
為「做對的事」公開表揚#
一個 SRE 推上線後幾分鐘察覺異狀立刻 rollback，把可能更長的事件壓縮為 4 分鐘——他在事件後立刻拿到兩筆 peer bonus，並在全員大會上獲得創辦人與數千同事的掌聲。
公開表揚這類行為，比任何文件都能傳達「我們真心重視這個」。
收集對事後檢討流程本身的回饋#
Google 定期問團隊：
- 文化是否在支援你的工作？
- 寫事後檢討是否成了過量的瑣事？
- 你的團隊有什麼值得分享給其他團隊的最佳實踐？
- 你希望有什麼工具？
這讓事後檢討流程本身也能持續改進。
結語與持續改進#
投資事後檢討文化的回報：故障變少、使用者體驗變好。
Google 的「Postmortems at Google」工作小組跨產品（YouTube、Fiber、Gmail、Cloud、AdWords、Maps）整合：
- 模板統一
- 從事件工具自動產生事後檢討
- 從事後檢討自動抽取資料以做趨勢分析
未來方向：以機器學習預測弱點、輔助即時事件調查、減少重複事件。