無究責事後檢討#

事故無法完全避免，但每次事故都是一次學習的機會——前提是團隊敢於誠實面對。無究責事後檢討（Blameless Postmortem）的核心信念是：事故的根因是系統與流程的缺陷，而非某個人的失誤。本章談何時該寫、blameless 的信條、流程與如何把它變成團隊文化。事故當下的告警與升級流程見 16 On-Call 與告警設計。

何時該寫 Postmortem#

不是每件事都要寫，但符合以下條件之一時，應該寫：

  • 使用者可感知的服務中斷或降級，超過約定門檻。
  • 任何資料遺失。
  • 需要人工介入才能恢復的事故（例如手動回滾、緊急切換）。
  • 解決時間超過門檻的事故。
  • 監控失效，導致問題是被人發現而非被系統發現。

事先用明確的觸發條件定義「哪些事故必須寫 postmortem」，避免事後爭論「這次要不要寫」。寫不寫不該取決於事故有沒有上頭關注，而取決於它是否符合預設門檻。

Blameless 信條#

無究責的根本主張：人會犯錯，因為系統允許他們犯錯。 與其追問「是誰按錯了按鈕」，不如追問「為什麼系統讓一次按錯就釀成災難」。

  • 假設每個當事人在當下、以其掌握的資訊與動機，都做出了合理的判斷。
  • 把焦點放在系統性因素：缺乏防呆、文件過時、告警缺失、流程模糊、工具危險。
  • 目標是修復「讓錯誤得以發生並擴大的環境」，而不是懲罰犯錯的人。

究責文化會讓人隱瞞錯誤、粉飾細節，反而讓真正的根因永遠藏在暗處——於是同樣的事故換個人再來一次。無究責不是「不負責」，而是把責任從「找戰犯」轉移到「修系統」。

究責 vs 無究責#

維度究責文化（Blameful）無究責文化（Blameless）
根因歸屬某個人的失誤系統與流程的缺陷
提問方式「是誰造成的？」「為什麼系統允許它發生？」
當事人反應隱瞞、推諉、防衛坦誠、主動揭露細節
學習效果細節失真，學不到真因取得完整事實，得以修復根因
長期結果同類事故反覆發生系統逐步加固，事故率下降
心理安全低，人人自危高，敢於承認與分享

事後檢討流程#

flowchart TD
    A[事故發生並恢復] --> B[指定撰寫負責人]
    B --> C[蒐集事實<br/>時間線 / 監控 / 日誌 / 對話記錄]
    C --> D[撰寫初稿<br/>影響 / 時間線 / 根因 / 行動項]
    D --> E[同儕審查<br/>檢查是否客觀、無究責、可行動]
    E --> F[公開分享<br/>全團隊可見]
    F --> G[追蹤行動項至關閉]
    G --> H[歸檔成為組織知識]
  • 蒐集：盡可能還原客觀事實——時間線、監控曲線、日誌、聊天記錄、操作命令。事實先於評斷。
  • 審查：由未直接涉入的同儕審查，確認措辭客觀、不指名究責、且每個行動項都具體可執行。
  • 分享：postmortem 必須公開可見，讓整個組織都能從中學習——藏起來的教訓等於沒有教訓。
  • 追蹤：行動項要有負責人與期限，並追蹤到關閉，否則 postmortem 淪為一份沒人讀的文件。

Postmortem 模板#

title: "結帳服務 P1 中斷"
date: 2026-06-20
status: resolved # draft / in-review / resolved
authors: [oncall-primary]
severity: P1

summary: >
  一行話講清楚發生了什麼、影響了誰、持續多久。

impact:
  duration: "37 分鐘"
  users_affected: "約 12% 結帳請求失敗"
  slo_impact: "消耗約 60% 當月 availability error budget"

timeline: # 以 UTC 記錄，越精確越好
  - "14:02 部署 v2.3.0 上線"
  - "14:05 結帳錯誤率開始上升"
  - "14:11 告警觸發，主值班介入"
  - "14:24 確認為連線池耗盡，開始回滾"
  - "14:39 回滾完成，錯誤率恢復正常"

root_cause: >
  系統性描述：新版本將連線池上限誤設為舊值的 1/10，
  且部署前的負載測試未覆蓋此組態，CI 也無組態校驗。

# 五個為什麼 / 觸發鏈，聚焦系統而非個人
contributing_factors:
  - "連線池組態缺乏校驗與預設安全值"
  - "負載測試未覆蓋此路徑"
  - "Canary 階段未設定連線池相關告警"

what_went_well:
  - "告警在 6 分鐘內觸發"
  - "回滾流程順暢，無資料遺失"

action_items:
  - {
      action: "為連線池組態加入 CI 校驗與下限",
      owner: platform,
      due: 2026-07-04,
      ticket: INFRA-1234,
    }
  - {
      action: "負載測試補上結帳高併發情境",
      owner: checkout,
      due: 2026-07-11,
      ticket: CHK-567,
    }
  - {
      action: "Canary 增加連線池飽和度告警",
      owner: sre,
      due: 2026-06-30,
      ticket: SRE-890,
    }

lessons_learned: >
  組態變更和程式碼變更一樣危險，卻常缺乏同等的測試與守門。

文化導入#

光有模板不夠，無究責是一種需要刻意培養的文化：

  • 由上而下示範：資深成員主動為自己參與的事故寫 postmortem、坦承判斷失誤，讓團隊看到「承認錯誤是安全的」。
  • 公開表揚而非懲罰：表揚誠實揭露問題的人，而非追究犯錯的人；讓「找到一個系統缺陷」成為值得慶祝的事。
  • 災難輪盤（Wheel of Misfortune）：定期舉辦的角色扮演演練——隨機抽出一個過往或假想的事故，讓成員扮演當班者，即時推演如何診斷與應對。這既訓練應變能力，也讓新人在低風險環境中熟悉系統與流程。
  • 把 postmortem 變成資產：建立可檢索的事故庫，讓新事故能參考舊教訓，避免重蹈覆轍。
災難輪盤（Wheel of Misfortune）怎麼跑

一場典型的災難輪盤演練：

  1. 出題：主持人挑一個真實或虛構的故障情境，準備好對應的監控畫面與系統回應。
  2. 抽人：隨機指定一名成員擔任「當班工程師」，其餘人觀摩。
  3. 推演：當班者像真實值班一樣下指令、查監控、做決策；主持人扮演系統，回應其操作的後果。
  4. 覆盤：演練後全體討論——哪裡判斷得好、哪裡有更快的路徑、文件與工具是否夠用。

它的價值不在「考倒誰」，而在於用安全的方式暴露知識落差與流程缺口，讓團隊在真正事故來臨前就練過手。

小結#

  • 事先用明確門檻定義哪些事故必須寫 postmortem，避免事後爭論。
  • Blameless 的核心是「人會犯錯因為系統允許」，把責任從找戰犯轉向修系統。
  • 流程是蒐集事實 ➡️ 同儕審查 ➡️ 公開分享 ➡️ 追蹤行動項至關閉。
  • 無究責是需要刻意培養的文化，靠由上而下示範與災難輪盤等演練落地。
Backward Toil 消除與工程平衡 On-Call 與告警設計 Forward