小村軟體有限公司
聯絡我們
選單

故障處理不止於復原 ── 給小型開發團隊的 Postmortem（再發防止）實務範本

· · 不具合調查, 日誌設計, Postmortem, 再發防止, 維運, 維護, Windows開發, 技術諮詢, 判斷表

「上個月修好的那個錯誤，又在另一個畫面上出現了」──在維護中的系統上被這樣說時，是否曾經一時語塞、不知該怎麼回答？

故障處理本身──也就是偵測、找出原因所在、修復、發布、道歉──這幾步大多數團隊都做得很確實。問題出在這之後。故障一復原，所有人立刻回到日常業務，故障的記錄就散落在某個人的信箱與聊天記錄裡，逐漸被遺忘。半年後，結構相同的故障在別的地方再次發生，又得把同樣的調查從頭做一遍。「修好、道歉就結束」的故障處理，是一種一再繳同一筆學費的做法。

本部落格先前已經在故障調查的技術面，透過「Windows 當機傾印收集入門」與「例外的捕捉與日誌設計」解說過「如何追溯到原因」的方法。本文要處理的是下一道工序：在查明原因之後，該如何持續進行檢討（Postmortem），才能不讓同樣的故障再次發生。這裡不談大規模 Web 服務，而是聚焦在一個 2～5 人的小型團隊維護業務應用程式、Windows 軟體時，實際能持續下去的做法。

1. 先講結論

  • 復原・原因調查・再發防止是不同的工作。復原是「讓今天的業務恢復正常」，原因調查是「讓自己能夠說明為什麼會發生」，再發防止則是「改變機制」。混在一起做，結果全部都會做得不上不下。
  • 不追究個人責任（blameless）不是出於道德，而是出於實際利益。在追究個人責任的場合，資訊就不會被說出來，也就無法追溯到原因。假設「相關人員都是在自己當時掌握的資訊範圍內做出了正確的行動」，再去找機制上的漏洞──這正是在 SRE 領域確立下來的 blameless postmortem 原則。1
  • 再發防止策略要落實成機制（程式碼・測試・監控・程序），而不是「多加注意」。依賴人的注意力的對策，會隨著負責人更替而消失。第 6 章給出用來判斷對策強度的判斷表。
  • 把原因分成「直接原因」與「促成因素」。能真正修好的，多半是促成因素這一側；「5 Whys 分析」的訣竅在於不要止步於某個人的行為，而要一直挖到機制層面。
  • 不會對所有故障都做完整版 Postmortem。依影響程度 × 再發可能性進行分級（第 7 章），輕微的故障只留下一段記錄即可。把分量控制在能持續下去的範圍內，是這套制度不會被廢棄的最大前提。
  • Postmortem 的份量要控制在 1 小時內能寫完。第 4 章給出最小模板。與其一個月寫出 0 篇像樣的文件，不如每次都留下一份粗略的記錄，後者更有價值。
  • 在委託開發中，客戶端故障報告書要與 Postmortem 區分目的，但內容可以從 Postmortem 轉用而來（第 8 章）。不把追究責任的文件和再發防止的文件混在一起，才能同時守住兩者的品質。

2. 為什麼同樣的故障會反覆發生

會再發的故障，存在的往往不是技術面、而是維運面的固定模式。

故障一復原，就被當成「已經結束」。故障處理屬於緊急插入的工作，一旦復原，所有人都會回到堆積如山的日常業務中。檢討的時間從未被排進任何人的行事曆，「等忙完這陣子再做」永遠不會真的到來。

報告書以「今後會多加注意」收尾。在提交給客戶或主管的報告書的再發防止欄位裡，寫上「會徹底確認」「會進行雙重檢查」之類的話就結束。這些措辭並沒有改變任何機制，於是在注意力鬆懈下來的幾個月後，又掉進同一個坑裡。

把問題歸咎於個人，而不修正結構性問題。如果用「是那個人漏做了測試」來了結這件事，那麼讓測試可以被漏做的結構──發布程序裡沒有測試關卡、在截止日期壓力下省略步驟被默許──就會原封不動地保留下來。下一次，換另一個人做出同樣的省略。

沒有留下記錄，數年後又掉進同一個坑。小型團隊的維護工作之所以「即使沒有記錄也能暫時運作」，正是因為一直由同一個人在處理。但這個人的記憶會在數年間逐漸淡忘，並在離職或換人時徹底消失。「這個錯誤好像以前看過，但想不起來當時是怎麼處理的」──如果有記錄，原本 10 分鐘就能查清楚的事，會因此變成耗費一整天的調查。

這些都不是能力上的問題，而是檢討從未被定義為一項正式業務所帶來的結果。正因如此，事先訂好一套做法（模板與實施標準）才有價值。

3. Postmortem 是什麼 ── 把 SRE 的做法翻譯給小規模維護

Postmortem 是一種檢討做法，把事件的影響、根本原因、應對的時間軸與再發防止行動記錄成文件，這是透過 Google 的 SRE（Site Reliability Engineering，網站可靠性工程）實務而廣泛確立下來的做法。其核心是 blameless（不究責） 原則。「以不究責方式寫成的 Postmortem，會假設所有相關人員都是出於善意、依據當時所掌握的資訊做出了正確的行動」──與其懲罰個人，不如去修正妨礙了正確行動的機制本身。1

這種想法並非 Google 獨有。微軟的架構指引（Azure Well-Architected Framework）同樣把 Postmortem 定義為「由所有相關團隊參與、結構化且不究責的審查」，並建議把根本原因分析（RCA）的結果，以改善應對流程、強化偵測（可觀測性）、改進設計這三種形式回饋到系統中。2

常有人以為「我們又不是大型 Web 服務，跟我們沒關係」，但筆者認為恰恰相反。在沒有客戶現場常駐、由少數人維護桌面應用程式的體制中，Postmortem 反而更能發揮效果。理由有三個。

  1. 由同一個人持續處理，一旦沒有記錄就會完全依賴個人。大型組織裡總會有人記得，但在 2～3 人的團隊中，「記得的那個人」就是唯一的資料庫。Postmortem 會成為這個團隊的外部記憶。
  2. 故障之間的間隔較長。與 Web 服務不同，業務應用程式的重大故障一年只發生幾次。等到上次應對的記憶已經淡去，下一次故障才姍姍來遲，這使得記錄的相對價值更高。
  3. 正因為無法親赴現場，證據與記錄才是命脈。在遠端維護中，「當時到底發生了什麼」的事後重建能力決定了一切，而這與 Postmortem 的時間軸記錄是一脈相承的。

另外，關於該對哪些事件寫 Postmortem 的參考標準，SRE 相關書籍中舉出的實施標準例子包括使用者可見的服務中斷、資料遺失、需要 on-call（緊急待命）介入等情形。1適合小型團隊的標準，會在第 7 章重新整理。

4. 最小 Postmortem 模板

能否持續下去，最重要的條件就是份量。以下提供一份 Markdown 模板，設計上限是初版要能在 1 小時內寫完。建議把它以附日期的檔案形式，放在儲存庫中的 docs/postmortem/ 之類的位置，與程式碼放在同一個地方進行版本管理。

# Postmortem：訂單列表出現跨日期的重複顯示 (2026-07-15)

- 狀態：已完成 / 行動執行中 / 僅登記
- 撰寫人：小村
- 嚴重程度：中（業務得以繼續，但產生了人工核對作業）

## 概要（3 行以內）
月結處理執行期間開啟訂單列表時，前一天的傳票出現了
重複顯示。僅為顯示層面的問題，資料庫上的資料是正常的。

## 影響（誰・什麼・多大程度）
- 影響對象：業務事務人員 3 名
- 影響內容：列表畫面重複顯示。差點造成一起重複出貨的案例 1 件
- 期間：7/15 9:10 左右 〜 11:40（約 2 小時 30 分）

## 時間軸
- 09:10 使用者來電反映「同一張傳票出現 2 行」（偵測到）
- 09:30 以遠端畫面共享方式確認重現條件
- 10:15 暫定應對：請對方在月結處理期間不要開啟列表
- 11:40 發布修正版並確認已復原

## 直接原因
列表查詢用 UNION ALL 的方式，把月結處理複製到暫存表的資料
與正式表合併在一起（沒有互斥控制）。

## 促成因素
- 月結處理與畫面查詢同時執行的情況，不在測試情境之內
- 暫存表的存在沒有寫入設計文件，畫面端改版時未被納入考量
- 沒有偵測重複顯示的機制，發現完全仰賴使用者通報

## 做得好的地方
- 使用者記下了操作紀錄的時間，讓重現條件的定位很快就完成
- 發布機制已自動化，修正版能在當天完成部署

## 再發防止行動（負責人與期限）
- [ ] 為列表查詢加入重複偵測斷言（小村，7/22）
- [ ] 為月結處理與查詢系統的同時執行加入測試（小村，7/29）
- [ ] 檢討廢除暫存表方式、改採快照隔離（小村，8 月底前確定方針）

為了方便直接複製使用，這裡也附上填寫前的空白模板。把它放在儲存庫中的 docs/postmortem/_template.md，故障發生時再以附日期的檔名複製一份使用，會比較方便。

# Postmortem：以一行文字描述現象 (YYYY-MM-DD)

- 狀態：僅登記 / 行動執行中 / 已完成
- 撰寫人：
- 嚴重程度：高 / 中 / 低（做此判斷的理由，一句話說明）

## 概要（3 行以內）

## 影響（誰・什麼・多大程度）
- 影響對象：
- 影響內容：
- 期間：MM/DD HH:MM 〜 HH:MM（約　小時）

## 時間軸
- HH:MM　（偵測到：是誰、透過什麼發現的）
- HH:MM
- HH:MM　（暫定應對）
- HH:MM　（確認復原）

## 直接原因

## 促成因素
- （允許問題混入的條件）
- （被忽略的條件）
- （擴大損害的條件）

## 做得好的地方
-

## 再發防止行動（負責人與期限）
- [ ]　（負責人, MM/DD）
- [ ]　（負責人, MM/DD）

以下列出幾個撰寫時的注意事項。

  • 「概要」控制在 3 行以內。日後來尋找這份文件的，是未來的自己。透過搜尋找到後，能在 3 行內看懂內容，比章節結構是否漂亮更重要。
  • 時間軸只寫附帶時間的事實。解釋（本應該……、應該要……）要分離到原因段落。一旦解釋混進時間軸，事後閱讀時就無法重建當時到底發生了什麼事。
  • 一定要寫「做得好的地方」。這可以防止檢討變成檢討大會，也是把「碰巧順利」的部分（比如剛好留有記錄）升格為正式機制的入口。
  • 行動項一定要附上負責人與期限。沒有負責人與期限的行動不會被執行。Postmortem 的實際效果，取決於它是否被審查、行動是否被追蹤。1

5. 原因分析的實務 ── 區分直接原因與促成因素

模板中把原因欄位分成兩個，是有理由的。

直接原因（direct cause）是直接引發這起故障的技術性事件。例如「漏做 NULL 檢查而拋出例外」「沒有互斥控制的 UNION ALL」。修正的修補程式，改的就是這個部分。

促成因素（contributing factors）是允許直接原因混入、被忽略，或使損害擴大的那些條件。例如「沒有針對那種情況的測試」「沒有寫進設計文件」「偵測完全仰賴使用者」。再發防止策略的主戰場就在這裡，通常會有多個。

分開的理由很單純：即使只修好了直接原因，只要促成因素還在，另一個直接原因就會透過同樣的路徑再次混入。開頭提到的「同樣的錯誤出現在別的畫面上」正是如此。

5.1 5 Whys 分析不能止步於「人的行為」

作為挖掘原因的工具，「5 Whys 分析」相當有效，但如果挖掘的方向不對，它就會變成一個追究戰犯的工具。典型的失敗案例，是止步於「為什麼→因為負責人忘了確認」。不要停在這裡，要再往下多挖一層。

  • 為什麼會忘記確認 → 因為確認這件事既沒有寫進作業程序書，也沒有列入檢查清單，只能靠記憶
  • 為什麼要靠記憶 → 因為發布程序從未被文件化，每次都是臨場組裝出來的

當「人的行為」作為答案出現時，那不是終點，而是通往「追問機制」這個下一個問題的入口。如果接受「人一定會犯錯」這個前提，那麼該深挖的問題就會從「為什麼會犯錯」變成「為什麼這個錯誤會原封不動地進到正式環境」。

5.2 沒有證據，分析就無從開始

原因分析的品質，上限取決於故障發生當時所留下的證據品質。無法重建時間軸的 Postmortem，只會淪為一篇推測性的作文。就 Windows 應用程式的維護而言，至少需要以下三樣東西打底。

如果試著寫 Postmortem 卻發現時間軸補不齊，這件事本身就是「偵測與記錄的機制不足」這項促成因素，也是再發防止行動的候選項目。

6. 再發防止策略的品質 ── 強度判斷表

把再發防止行動列出來之後，要判斷它們的強度。判斷的軸心是「有多依賴人的注意力」。

強度 對策類型 範例 效果的持續性
弱 多加注意・進行宣導 「徹底確認」「提醒信件」「鼓勵雙重檢查」 數週～數個月。會隨負責人更替而消失
中 作業程序書・檢查清單 發布檢查清單、故障應對程序書、審查要點表 只要程序被遵守就能持續。有流於形式的風險
強 機械式地防止・偵測 自動化測試、斷言、由型別・設計形成的約束、CI 關卡、監控警示 只要機制在運作就能持續。不依賴人的狀態

這時候現實的規則是：不是「禁止使用弱對策」，而是「不能只靠弱對策收尾」。宣導作為能當天完成的暫定應對是有意義的，但寫在長久對策欄位裡的，至少要是中等強度，如果可能，最好是強對策。

如果只想得到弱對策，可以用下面的問題重新檢視。

  • 「就算換成一個剛到職的新人處於相同情況，這起故障是否依然不會發生？」──如果答案是否定的，就代表還沒有變成機制。
  • 「能不能讓編譯器、測試或 CI 三者之一偵測出這個錯誤？」──比方說，如果問題是「結束時把例外吞掉了」，那麼強對策不是宣導，而是把「遇到未預期例外時該結束還是繼續的判斷表」中整理的那種方針，實作成程式碼裡的共用例外處理器。
  • 「能不能讓人根本無法犯這個錯？能不能讓人更快發現這個錯？」──如果防止的成本太高，改採偵測（監控、警示、核對批次作業）也是一種夠格的強對策。把故障的教訓回饋為更強的偵測與更好的設計，這種整理方式在微軟的指引中也以同樣的結構被推薦。2

強對策需要花費較多工時，實務上比較可行的做法，是把「這週就能完成的中等對策」與「下個月要做的強對策」都列入行動項目，用期限來管理。

7. 該對哪些故障進行 ── 實施的分級（triage）

如果強制要求對所有故障都寫完整版 Postmortem，3 個月內就會沒人再寫了。要依影響程度 × 再發可能性來決定實施等級。

  容易再發／結構性 不易再發／偶發性
影響大（業務停止・資料損毀・波及客戶） 完整實施：模板全部項目 + 相關人員的審查會（30 分鐘） 完整實施（僅文件。審查會可自行選擇）
影響中（靠因應對策維持了業務） 簡易實施：僅模板中的概要・原因・行動項 在故障管理台帳留一段記錄
影響小（使用者不會察覺・輕微的顯示錯亂） 在故障管理台帳留一段記錄，並每季回顧一次趨勢 在故障管理台帳留一行記錄

運用的重點有三個。

  • 「同類故障再次發生」，不論影響程度為何，都要提升一個等級。因為一旦再次發生，就證明上一次的對策沒有真正變成機制。
  • 即使輕微，也一定要留下記錄。一段話就夠了。只要有「日期・現象・原因・處理」這 4 個項目，數年後的自己就能靠搜尋得救。小型故障的記錄累積多了，還能看出「就這個畫面故障特別多」這類結構性的偏差。
  • 拿不定主意時就傾向於寫，但要壓低份量。與其花時間猶豫要不要做完整版，不如先動手寫簡易版，反而更快結束。

7.1 如何判斷是否「結構性」

表格橫軸的「容易再發／結構性」，如果不先訂好判斷標準就無法使用。實務上，訂出「以下任一項符合就當作結構性處理」這種簡單的判斷基準即可。

  • 在同一畫面・同一模組發生第 2 次。即使時間相隔很久，只要在同一個地方發生了 2 次，就不是偶然。
  • 原因的「型態」與過去的故障相同。漏做 NULL 檢查、缺少互斥控制、日期邊界的處理方式。就算地點不同，只要型態相同，就證明這種型態的漏洞還沒被堵上。
  • 無法寫出重現這起故障的測試／即使寫了也沒有在跑。偵測的網子存在結構性的破洞，所以下次也會直接漏過去。
  • 「只要按照規定的順序操作就不會發生」這類故障。依賴作業程序的問題，只要換了人就會再次發生。
  • 同一段程式碼在其他客戶・其他環境中也在運作。影響範圍不會只限於這一次，所以要把等級提高一階。

反過來，能斷定為「偶發性」的，只有原因僅限於外部因素（特定硬體故障、相依服務的暫時性故障），且沒有在自家的設計・程序中發現漏洞的情況。拿不定主意時就傾向判定為結構性。就算多寫，幾乎不會有什麼壞處。

7.2 審查會（30 分鐘）的進行方式

針對影響大的故障所舉行的審查會，訣竅在於訂好時間、按固定流程進行。

  • 參加者為 3～5 人。應對的當事人、有可能碰到同一段程式碼的其他成員、負責客戶窗口的人。不讓有立場判斷責任的人加入。一旦讓這種人加入，發言就會立刻變得帶有防禦性，促成因素也不會被說出來。必要時分享結果就已足夠。
  • 事先發放初版。不要在現場才開始寫。不過，「所有人都會事先讀完」這個前提往往會落空，所以要在開頭安排一段閱讀時間。
  • 30 分鐘的時間分配。（1）0～5 分：各自靜靜閱讀（2）5～10 分：確認時間軸的事實。補齊認知落差與遺漏的時刻（3）10～20 分：補充促成因素。這裡才是重頭戲（4）20～28 分：判定行動的強度（第 6 章的表格）並確定負責人與期限（5）28～30 分：決定下次確認進度的日期。
  • 要確認的觀點只有兩個。「還有哪裡本來可以發現」與「其他地方是否有同樣的漏洞」。把這兩個問題丟給全體成員，就能問出應對的當事人一個人想不到的促成因素。
  • 主持人由應對的當事人以外的人來擔任。一旦出現以個人姓名為主詞的發言，主持人就把它換成以機制為主詞的說法。「A 忘了確認」→「確認這件事沒有被納入程序」。光是機械式地做這種換句話說，現場的氣氛就會不一樣。
  • 不留下未確定的行動項目。當場無法決定的事項，就改成「在○月○日之前確定方針」這樣的行動項目，附上期限後結束。

7.3 故障管理台帳要放在哪裡

到目前為止出現過好幾次的「故障管理台帳」，並不是要你去買專用工具。該滿足的要件只有三個：數年後仍能全文檢索、每一起故障都能增加一行記錄、團隊全體成員都能寫入。只要滿足這些，形式不拘。

存放位置 適合的情況 注意事項
儲存庫中的 Markdown（在與 docs/postmortem/ 相同位置放一份清單檔） 由開發團隊獨立完成的維護。容易與 Postmortem 本體互相連結 非開發人員（客服・業務）不容易寫
Issue 管理的標籤運用（GitHub Issues、Backlog 等） 已經在使用議題管理工具。想與修正提交、發布連結起來 若沒有事先訂好類似 incident 這樣的標籤，就會被淹沒在一般議題裡
共用磁碟機的 Excel 台帳 非開發人員也要寫入。想依客戶別・系統別產出彙總 要留意同時編輯的衝突，以及檔案不斷增生所造成的個人化管理問題。固定位置、只放一份

欄位只要有「日期／系統・畫面／現象／影響程度／直接原因／處理方式／Postmortem 連結／是否為再發」就足夠了。重要的不是工具，而是即使是輕微的故障也一定會增加一行，以及數年後能用「同樣的現象」搜尋到這兩點。只靠聊天討論串和電子郵件打發過去的狀態，這兩點都無法滿足。

8. 委託開發時的處理方式 ── 與客戶端故障報告書的關係

在委託開發或維護合約中，故障發生後，客戶往往會要求提交一份「故障報告書」。事先把 Postmortem 與報告書的關係整理清楚，可以避免重複作業。

內容有八成可以直接轉用。概要、影響、時間軸、直接原因、再發防止策略，正是客戶端報告書的構成要素本身。如果按照「先寫內部用的 Postmortem，再從中編輯出客戶端版本」這樣的順序，就不會出現只為了報告書而另外撰寫的內容。

不過，要意識到這是兩份目的不同的文件，並把它們區分開來。

觀點 內部 Postmortem 客戶端故障報告書
目的 改變機制以防止再發 履行說明責任、維持信任
讀者 未來的自己・團隊 客戶的負責人・其主管
原因的寫法 坦率地寫到促成因素為止（連公司內部程序上的不足也寫） 準確陳述事實，專業術語轉譯為業務語言
責任・補償 不寫（作為 blameless 範圍之外的內容另外處理） 依合約另行整理（多半是與報告書不同的另一份文件）
再發防止策略 附負責人與期限的行動項 已實施 + 預計實施內容並附上期限

8.1 實際上會怎麼改寫

光講抽象概念不容易理解，這裡直接沿用第 4 章的模板範例，並列出內部記述在改成客戶端版本時會如何變化。

內部 Postmortem 的記述 客戶端報告書的寫法
列表查詢用 UNION ALL 的方式，把月結處理複製到暫存表的資料與正式表合併在一起（沒有互斥控制） 僅限於月結處理執行期間，會出現彙總用的作業資料與確定資料同時顯示在列表中的問題。這是顯示層面的現象，資料庫上的資料並無錯誤
月結處理與畫面查詢同時執行的情況，不在測試情境之內 對於月結處理與畫面操作同時進行的情況，驗證有所不足
暫存表的存在沒有寫入設計文件，畫面端改版時未被納入考量 內部設計資訊的記載有所不足，畫面改版時發生疏漏
沒有偵測重複顯示的機制，發現完全仰賴使用者通報 沒有自動偵測異常的機制，是透過使用者的通知才得知
[ ] 為列表查詢加入重複偵測斷言（小村，7/22） 將加入自動偵測重複資料的機制（預計 7 月 22 日實施）

改寫的原則有三個。

  • 技術用語翻譯成業務語言，但不能稀釋事實。「UNION ALL」「斷言」這類詞彙，要換成客戶的負責人能向自己主管說明的語言。另一方面，像「僅為顯示問題，資料正常」這類能確定影響範圍的資訊，一定要保留。這裡如果模糊帶過，反而會增加詢問件數。
  • 公司內部程序上的不足，也要作為事實寫出來。如果把「設計文件沒有記載」刪掉，再發防止策略的理由就會消失，「為什麼這樣做就能解決」也就傳達不出去。要做的是把措辭寫得更周到，而不是當作沒發生過。
  • 拿掉負責人姓名，保留日期。公司內部的負責人姓名對客戶而言不需要。反過來，預計實施日期要作為承諾保留下來，完成後再回報。

分開的最大理由是，一旦把追究責任・補償的討論與再發防止的討論混在一起，兩者都會被扭曲。在牽涉責任問題的文件中，相關人員難免會寫得比較防禦性。防禦性的文件裡，促成因素會消失，再發防止也會退化成「會多加注意」。反過來，如果把坦率撰寫的內部 Postmortem 原封不動地交給客戶，缺乏脈絡的段落有時會被過度解讀、自行擴散。比較安全的做法，是把「坦率書寫的內部文件」與「準確傳達的外部文件」分開，做成由前者單向產出後者的流程。

另外，一旦在客戶端報告書中寫下了計畫實施的再發防止策略，這就是對客戶的一項承諾。應以與 Postmortem 行動欄位相同的機制管理期限，完成後再回報。這一來一往，反而能把一次故障轉變成累積信任的機會。

9. 總結

  • 故障處理不是復原就結束。要把復原・原因調查・再發防止當作不同的工作，把檢討（Postmortem）納入正式業務流程之中。
  • Postmortem 的原則是 blameless（不究責）。追究個人責任，資訊就不會被說出來，也就無法追溯到原因。分析不要止步於某個人的行為，要一直挖到機制上的漏洞（促成因素）。1
  • 文件只要有能在 1 小時內寫完的最小模板（概要・影響・時間軸・直接原因・促成因素・做得好的地方・附負責人與期限的行動項）就足夠了。作為補齊時間軸的前提，要事先做好當機傾印・日誌・事件記錄的證據保全。
  • 再發防止策略要從「多加注意」（弱）提升到作業程序書（中），如果可能，進一步提升到用測試・斷言・監控・設計變更做到機械式防止（強）。把教訓回饋到偵測與設計中的這種結構，是 SRE 與微軟雙方指引所共有的。12
  • 不對所有故障都完整實施。依影響程度 × 再發可能性進行分級，即使是輕微的故障，也一定要留下一段記錄。
  • 在委託開發中，應先寫內部用的 Postmortem，客戶端故障報告書再從中編輯而來。把責任・補償的文件與再發防止的文件分開，才能同時守住兩者的品質。

相關文章

相關諮詢領域

合同會社小村軟體處理範圍涵蓋難以重現的缺陷調查・原因分析，到建立證據保全（日誌・傾印收集）機制，乃至於包含再發防止在內的維護維運體制整理。從「同樣的故障反覆發生」「故障報告書的再發防止策略已流於形式」這類階段開始諮詢，我們也歡迎。

參考連結

  1. Google，Site Reliability Engineering: Chapter 15 - Postmortem Culture: Learning from Failure。內容涵蓋 blameless postmortem 的原則（假設相關人員都是出於善意、依據當時掌握的資訊做出了正確的行動）、Postmortem 實施標準的範例（使用者可見的服務中斷、資料遺失、on-call 介入等）、審查與行動追蹤的重要性，以及究責文化會導致資訊被隱藏這幾點。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn，Architecture strategies for designing an incident management (IcM) process - Azure Well-Architected Framework。內容涵蓋把 Postmortem 定義為「由所有相關團隊參與、結構化且不究責的審查」、根本原因分析（RCA）是包含促成因素在內的根本原因識別，以及建議把 RCA 的教訓分類回饋到改善應對流程・強化可觀測性（偵測）・改進工作負載設計這三個領域中。 ↩ ↩2 ↩3

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

Postmortem 是什麼？和故障報告書有什麼不同？
Postmortem 是指故障復原後進行的一種結構化檢討文件與活動，是在 SRE（Site Reliability Engineering，網站可靠性工程）領域中確立下來的做法。它以不追究個人責任（blameless）為前提，記錄時間軸、直接原因、促成因素與再發防止行動。客戶端故障報告書是一份履行說明責任的文件──「發生了什麼事、如何處理」，相對地，Postmortem 則是用來決定「今後要如何改變機制，才不會再發生同樣的事」的內部文件。不過由於兩者內容大部分重疊，先寫 Postmortem、再從中編輯出客戶端報告書，會是比較有效率的做法。
再發防止策略總是變成「今後會多加注意」。該怎麼辦？
「多加注意・進行宣導」依賴人的記憶與善意，因此隨著時間過去、負責人更替，效果必定會消失。思考對策時，請重新問自己：「就算換成一個剛到職的新人處於相同情況，這起故障是否依然不會發生？」如果答案是否定的，就代表還沒有變成機制。強力的對策，是像測試、斷言（assertion）、藉由型別或設計形成的約束、監控警示等，即使人不特別注意也能被機械式偵測或防止的東西。若無法馬上採取強力對策，可以先把檢查清單或作業程序書當作過渡階段，並把長久對策記錄成附有期限的行動項目。
在人力有限的委託開發團隊，沒有餘力為每一起故障都寫 Postmortem。
並不需要為所有故障都寫完整版的 Postmortem，勉強這麼做，這套制度本身也撐不下去。應該依影響程度與再發可能性，對是否實施進行分級（triage）：導致業務停止、資料損毀的故障，以及同類故障再次發生時，就完整實施；輕微的故障，只要在故障管理台帳留下一段記錄即可，形成這樣的濃淡區分。重要的是「即使輕微也一定要留下記錄」──數年後同樣的現象再次發生時，過去的記錄能不能被搜尋到，會讓調查所需的時間產生很大差異。
不追究個人責任（blameless）不就是把責任問題含糊帶過嗎？
並非如此。blameless 是一項原則，用來把焦點從「是誰犯了錯」轉移到「為什麼這套機制會讓那個人犯錯」上。如果是操作人員操作失誤，那麼容易讓人出錯的 UI 或作業程序中，就存在促成因素。在懲罰個人的組織裡，下一次故障發生時資訊就會被隱藏，導致無法追溯到原因。另一方面，對客戶的說明責任（發生了什麼事、如何補償）應該以另一份文件、另一套流程來履行，這與 blameless 的檢討並不矛盾。把追究責任的文件與再發防止的文件分開，是實務上的重點。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽