昨天你建立了「失敗是資產」的文化理念。今天，你要面對整個組織最不習慣、也是難度最高的一項儀式：召開一場沒有任何人被指責的事故檢討會。
早上十點，會議室裡坐滿了人。然而所有人的眼神都在刻意迴避——看著桌面、盯著筆電、假裝刷著手機。只有一個人孤零零地坐在角落，臉色發白、雙手微微發抖。
他是 David，昨晚親手按下那個生產環境部署按鈕的後端工程師。
你心知肚明，這間會議室裡的所有人，此刻都在等待你做一件事：點名指責他。
昨晚的生產環境事故極為嚴重：一個微小的配置錯誤，導致整個支付服務癱瘓宕機了整整 47 分鐘，給公司帶來預估高達 230 萬美元的營業額損失。CEO Steve 剛才在走廊上特別壓低聲音對你說：「Bill，這次事故性質太惡劣，必須要有人出面負責。」
你深吸一口氣，走進會議室，緩緩說出接下來的話：
「這次會議的唯一目的，不是為了找出是誰犯了錯。我們要共同找出：我們的系統在哪裡設計得不夠好，才會讓這個錯誤如此輕易地發生？」
會議室裡的空氣瞬間凝固了三秒。
你點開投影片：
無指責事後檢討（Blameless Postmortem）。
讓時間倒回去。
週四下午，David 收到了一個緊急 Ticket：「支付服務響應超時太長，客戶反應卡頓」，產品經理催促：「立刻把 timeout 改成 10 秒」。
他迅速查了代碼，將 api_timeout 參數由原先的 30 秒改成了 10 秒。在本地與測試環境運行均順利通過，PR 也得到了 Tech Lead 的核准（Approve）。下午六點，正式部署生產環境。
晚上七點半，系統監控警報突然亮起：支付超時率（Timeout Rate）達到了 23%。當晚值班的 On-call 工程師 Lisa 認為此時剛好是流量高峰，決定「再觀察十分鐘看看」。
然而僅僅十分鐘後，超時率狂飆到了 61%，支付服務全面卡死。
團隊隨後手忙腳亂地花了整整三十分鐘，才驚恐地發現：那個 api_timeout 配置參數，不僅控制了對外的 API 請求，還底層控制了內部資料庫的複雜查詢。 將其改成 10 秒後，所有查詢歷史訂單的大型請求（通常需要 15 到 20 秒）全部被系統判定超時，進而觸發了系統的自動重試機制，瞬間雪崩式地拖垮了整台資料庫。
晚上八點十七分，手動回滾（Rollback）完畢，服務逐步恢復。但無可挽回的損失已經造成。
你站在投影幕前問：
「David，在修改參數前，我們有任何架構文件能查到『這個 timeout 還會影響哪些內部查詢』嗎？」David 搖了搖頭。
「Tech Lead，我們的 PR 審查機制中，有任何檢查清單（Checklist）能提醒你『修改此類 timeout 屬於高風險變更』嗎？」Tech Lead 愣在原地。
「Lisa，當超時率（Timeout Rate）大於 20% 時，我們有標準的 Runbook 指南要求你必須立刻回滾，而不是『憑經驗觀察』嗎？」Lisa 低下頭，小聲說：「沒有。」
你環顧會議室：
🚨 本次事故暴露的五大系統性漏洞：
- 配置參數缺乏相依性與影響範圍文件。
- PR 審查流程流於形式，缺乏高風險變更檢查清單。
- 測試環境資料量過小，根本無法模擬真實生產環境的負載。
- 系統監控警報缺乏標準 Runbook 處置指南，完全依賴值班人員主觀判斷。
- 缺乏自動化回滾（Rollback）機制，修復完全依賴繁瑣的人工操作。
「這五個系統性漏洞，是我們整套研發架構一直以來默許存在的。David 只是昨晚剛好踩到地雷的那個倒楣鬼。」
CTO 有些猶豫地問：「但……發生了這麼大的損失，難道就這樣放過他，不對外做任何懲處交代嗎？」
你平靜地看著他：「如果我們的結論是『David 以後工作要更小心』，那麼下禮拜同樣的事故，一定會換一個名字在別的工程師身上重演。但如果我們的結論是『合力修補好這五個系統性漏洞』，未來就不會再有任何人掉進同一個坑裡。你覺得哪一個才是真正的對公司負責？」
這毫無疑問是組織在進行變革時，最難轉變的文化死角。
| 🔴 選項 A：揪出事故戰犯，公開點名進行嚴厲懲處 | 🔵 選項 B：召開無指責檢討會，專注於系統漏洞的修補 |
|---|---|
| 短期效益：✓ 快速平息眾怒與高層壓力，看似「有人扛起責任了」✓ 展現出雷厲風行的「強硬管理能力」長期代價：✗ 團隊噤若寒蟬，沒人再敢誠實回報潛在的系統漏洞✗ 真相被隱蔽，成員習慣推諉卸責以求自保✗ 系統架構的漏洞依然存在，下次換下一個倒楣鬼踩雷結果：✗ 治標不治本，團隊陷入互相推諉的惡性循環 | 短期代價：✗ 短期內會遭受質疑「難道犯錯的人完全不需要負責？」✗ 必須對抗人性中「想尋求懲罰以示警告」的直覺反應長期效益：✓ 建立「安全說真話」的心理安全感，問題能被提早暴露✓ 從失敗中獲取知識，徹底根治漏洞以防同類事故重演結果：✓ 系統代價轉化為組織資產，整體抗風險能力提升 |
這就是持續學習（Continuous Learning）落地最核心的基石：
無指責事後檢討（Blameless Postmortem）的根本假設是：在事情發生當下，每個人都在他所掌握的上下文資訊中，做出了他認為最合理的決定。要修正的是「讓錯誤極易發生的脆弱系統」，而不是去責怪「被系統引導犯錯的個人」。
你在白板上寫下了五個具體的行動項目（Action Items），分別指派給不同的團隊負責人。在這份改善清單中，沒有任何一項惩罰是針對 David 個人。
你轉身向 David 說：「David，這份配置參數相依性指南，我需要由你配合 Tech Lead 團隊一起建立。因為你親自踩過這個坑，你現在最清楚它的超時邏輯，這個寶貴的經驗對團隊非常重要。」
David 雙眼通紅，難以置信地看著你，隨後用力點了點頭。
會後 CTO 依然有些疑慮：「Bill，你真的確定要開這個先例嗎？」
你拍了拍他的肩膀：「如果我們昨晚懲處了 David，那麼以後其他工程師在修改配置或代碼時，心裡想的就只會是『千萬別被抓到』。他們會開始隱瞞所有不確定的架構細節、選擇性不上報異常。等到下次系統再次崩潰時，我們可能連救火的線索都找不到。但如果我們今天修補了這五個漏洞，系統就會在下一次自動幫大家把危險擋下來，這才是真正對組織負責。」
CTO 沉思了片刻，終於點了點頭。
無指責檢討會最大的阻礙，往往在於人性的記憶偏差與情緒防衛。
在巨大的事故壓力下，人很容易記錯、選擇性遺忘，或是為了自保而美化某些決策細節。一旦會議演變成「你記得什麼」、「我當時以為」的口水戰，真正的系統缺陷就會被永遠掩蓋。
在 2026 年的 AI 時代，AI Agent 可以直接扮演中立且客觀的「事故現場還原者」：
graph TD
A[事故發生] --> B[AI 自動收集資料]
B --> C[Log / 部署記錄]
B --> D[監控數據]
B --> E[Slack / Chat 對話]
B --> F[Git commit / PR]
C --> G[重建時間軸]
D --> G
E --> G
F --> G
G --> H[標出系統缺口]
H --> I[生成 Action Items]
I --> J[追蹤直到關閉]
[AI 自動還原事件真實時間線]
├─ 16:32 ── 建立 Ticket #4728："支付響應過慢，請求調整超時設定"
├─ 16:45 ── 提交 Commit a3f892b：修改 payment_service.yaml 配置檔
├─ 17:18 ── PR #892 由 @tech_lead_sam 審核通過 (審查耗時：僅 2 分鐘)
├─ 18:02 ── 完成生產環境（Production）部署上線
├─ 19:31 ── 系統觸發告警：支付超時率達 23% (Lisa 判定為高峰期流量，決定暫時觀察)
├─ 19:42 ── 系統告警升級：支付超時率飆升至 61% (On-call 工程師緊急聯繫 David 介入)
└─ 20:17 ── 執行回滾（Rollback）部署，生產環境恢復正常
我們來看一個業界常見的轉型縮影：
🏢 資料庫遷移事故無指責檢討成果：
- 問題核心：遷移文件為三個月前撰寫已然過期；測試計畫未涵蓋複雜邊緣時區；測試資料採手動生成，無法反映真實負載；且缺乏回滾預案。
- 改善行動：
- 強制要求所有架構變更文件皆標註「驗證有效日期」。
- 測試案例必須包含邊緣時區極限值測試。
- 測試環境全面導入去敏感化的生產環境真實資料。
- 所有的資料庫變更（Migration）必須預先編寫回滾腳本並進行演練。
- 後續效益：三個月後再次進行大規模遷移，實現 0 故障順暢上線。
但如果當時會議的焦點依然是「究竟是哪位 DBA 貼錯了步驟、哪位工程師沒有仔細對齊」，這四項從根本上加固系統的改善措施就永遠不會誕生。
「當你本能地去問『是誰犯的錯』時，你就已經主動放棄了『為什麼系統會允許錯誤如此輕易發生』這個更重要的改善機會。」
在你們團隊上一次遭遇線上重大事故後的檢討報告中，最終的結論是指向了一個具體員工的名字，還是指向了一組系統性機制的修補？
如果是前者，那麼下一次相同的事故，一定會像幽靈一樣，只是換了一個不同工程師的名字出現在新的事故報告裡。
無指責並非「不需負責」，而是由「整個系統」代替脆弱的個人去承擔責任。
明天，我們將聊聊第三航道的另一個管理難題：當多個團隊都在快速進步，但方向卻開始各奔東西時，你敢不敢當那個打破砂鍋問到底、逼大家撕開假设、對齊目標的人？
Day 23 見。
iThome鐵人賽
看影片追技術