客製軟體事故事後檢討怎麼寫
客製軟體出了事故之後，事後檢討寫下時間線、使用者看得到的影響、當時怎樣把影響停下來、目前查到的原因，以及後續事項由誰在哪一天前完成。維運手冊管的是這一班誰接聽；回滾計畫管的是怎樣退回一次發布；這一頁管的是事故告一段落之後留下的紀錄。
目錄
事後檢討和維運手冊、回滾分開寫
維運手冊回答的是正式環境已經在用的時候，這一班誰接聽、日誌和看板在哪、已知故障先查哪一步、什麼情況改找下一個人、什麼情況改走回滾。回滾計畫回答的是哪一個現象可以啟動退回、誰做決定、這一次是還原資料還是關掉功能開關。事後檢討回答的是另一件事：事故的影響已經停下來，或已經轉成持續處理之後，時間線、使用者看得到的影響、當時採取的做法、目前查到的原因、後續事項由誰負責，寫在哪一份紀錄。三份可以互相指到同一次事故的編號。值班表不改成檢討，回滾的觸發也不抄進原因裡。分別見 客製軟體維運手冊怎麼寫、客製軟體上線回滾怎麼寫。
交接表仍寫誰持有程式庫。變更仍看規格要不要改。見 客製軟體專案交接要準備什麼、客製軟體範圍變更怎麼管。交付仍走 客製軟件、網站與應用程式。檢討封面寫自己的版本、事故編號，以及它存放的路徑。維運手冊若已寫事後檢討放在哪，這一頁就用那個路徑，不另開一個只有當班的人知道的位置。
什麼情況要寫，在事故發生前先定
2026年10月27日閱讀的 Google SRE：Postmortem Culture 由 John Lunney 與 Sue Lueder 撰寫，Gary O'Connor 編輯。該頁沒有刊登日期。該頁把事後檢討定義成一份書面紀錄，寫下事故、它的影響、為了減輕或解決而採取的行動、原因，以及用來降低再次發生的可能或影響的後續行動。該頁寫明，撰寫的目的是把事故記下來、把促成事故的原因弄清楚，並把預防行動放進工作裡。該頁並寫明，什麼情況要寫，應在事故發生前定義，讓每個人都知道何時需要一份檢討；除了這些條件，任何利害相關的人也可以要求為某一件事寫一份。
該頁列出的常見條件，是該頁對 Google 的寫法：使用者看得到的中斷或變慢超過某個限度、任何一種資料遺失、當值的人介入（包括退回發布或改導流量）、處理時間超過某個限度、監控沒有發出應有的呼叫。限度本身該頁沒有印成一個客製專案必須採用的數字。公司自己的條件寫在檢討辦法的封面，註明是誰在哪一天同意的：哪一種使用者看得到的現象要寫、資料遺失要不要寫、當值的人做了回滾或改導要不要寫。封面沒有日期，這一次事故仍可以由利害相關的人要求撰寫，但辦法本身先補上日期，不把該頁的例子填進封面。
時間線按當時的紀錄寫
2026年10月27日閱讀的 Google SRE：示例事後檢討 沒有刊登日期。頁上的範例把日期標成 2015-10-21，服務名稱是一個教學用的搜尋例子。該頁把時間線稱作事故的「分場」，並寫明可以先用事故處理紀錄裡的時間線，再補上其他相關的條目。時間寫明時區。每一條是當時發生的事：呼叫在何時進來、誰宣布這是一次事故、誰做了哪一步、影響在何時停下來、事故在何時結束。條目來自日誌、看板、呼叫紀錄或當時留下的訊息，並寫出處。
範例裡的分鐘數、查詢量和收入說法留在該頁，不抄進這一次客製事故。日誌裡讀不出來的時刻，寫「日誌未載明」，不補一個整數。口頭回憶和日誌不一致時，兩條並列，並寫誰在哪一天對過。時間線不改寫成原因。原因放在下一節。當值同事的名字留在時間線上，因為那是誰做了哪一步。
影響寫使用者看得到的現象
文化那一頁把影響放在檢討必須寫下的項目裡。範例頁的註記寫明，影響是對使用者、收入等方面的效果。客製檢討寫使用者看得到的現象：哪一個功能不能用或變慢、從時間線上的哪一個時刻到哪一個時刻、哪些已經在用的角色受影響。時刻以日誌或看板上讀得到的為準。讀不到時長，這一欄寫「時長未從紀錄讀出」，不估一個數字。
收入、賠償或罰則若公司沒有在這次事故裡核過，這一欄寫「未記錄」。不把範例頁上的收入句子改填成零或改填成一筆金額。可能識別終端使用者個人的資料不放進檢討。文化那一頁寫明，這類資料即使在內部文件裡也不放入。受影響的範圍用角色、功能或筆數來寫，筆數要能指回統計所在的畫面，並寫讀取日期。
把影響停下來的做法，和目前查到的原因分開
文化那一頁把「為了減輕或解決而採取的行動」和「原因」分成兩件事。檢討因此分兩欄。第一欄寫當時怎樣把影響停下來：誰在何時做了哪一步，例如切回上一版、關掉某個開關、把流量改到仍可用的環境、或先停止寫入。若走的是回滾計畫，這欄指到那一版計畫和當次的決定人，不把觸發條件重寫一遍。見 客製軟體上線回滾怎麼寫。第二欄寫目前查到的原因：哪些條件合在一起才發生，已知到哪一步。
範例頁的註記寫明，原因是說明事故在什麼情況下發生，並說用例如「五個為什麼」這類做法來理解促成因素常常有幫助。那是該頁的建議，不是規定客製專案必須用同一種問法。已知的每一步各寫一行，並寫它依據的日誌或變更紀錄。還沒有查完的部分寫「尚未查完」，加上誰在哪一天前繼續查。不補一句聽起來完整、卻沒有出處的原因。文化那一頁把「原因是否夠深」列為覆核時要看的一點。深度不夠時，覆核的結果是補查，不是改寫一句較短的話來結案。
後續事項寫負責人，並寫完成日
文化那一頁寫明，預防行動要放進工作裡，用來降低再次發生的可能或影響。範例頁的後續事項表有事項、類型、負責人和追蹤編號。類型在範例裡包括減輕、預防、流程和其他。該頁註記寫明，一時想到的事項常常過大或成本過高，需要再收斂；也有風險會為了單一個問題過度加強，例如只加一則監控，而較早的測試本來就能攔下。客製檢討沿用「每一項有負責人」。完成日該頁的表沒有印成固定欄，由這一次自己寫：誰在哪一天前做完，做完的結果放在哪裡。
沒有負責人，或沒有完成日，這一項留在未定，不算已經排進工作。負責人不在職或當天不在，欄上預先寫代理人。事項若會改規格，另開變更請求，檢討只指到變更編號。見 客製軟體範圍變更怎麼管。事項若是改維運手冊上的第一步，指到那一條條目和改訂日期，不在檢討裡把手冊重抄一遍。追蹤編號用公司已經在用的工作單或缺陷單，沒有單號就寫存放這項的路徑。
檢討寫事件經過，名字用來對時間線
文化那一頁寫明，事後檢討要找出促成原因，而不把個人或團隊寫成行為不當。一份這樣寫的檢討假定參與的人出於好意，並按當時手上的資訊做了當時該做的事。該頁寫明，若檢討變成指認誰做錯，人們會因為擔心受罰而不把問題說出來。檢討仍寫誰在何時做了哪一步，因為時間線需要這些名字。名字用來對紀錄，不用來寫處分。處分、考績和獎金不放進這一份。
該頁並寫明，把檢討從責怪轉成追問「為什麼當時的資訊不完整或不正確」，預防才寫得下去。人改不了成另一個人，系統和做法可以改，讓人在設計和維護時較容易做對。檢討裡若出現對人的評語，覆核時改回事件和資訊：當時看得到哪一份看板、哪一條手冊、哪一則告警。評語刪掉之後，事件和後續事項仍在。
有人覆核過，這份才算寫完
文化那一頁寫明，沒有人覆核的事後檢討，等於不曾存在。該頁列出覆核時可以看的幾點：關鍵的事故資料有沒有留下、影響有沒有寫全、原因是否夠深、後續事項是否合適且相關修正的優先順序是否恰當、結果有沒有分享給相關的人。客製檢討用這幾點當覆核清單，覆核人寫名字和日期。覆核人不是時間線上唯一的作者；作者也寫名字。兩欄可以是同一人，欄仍分開。
時間線、使用者看得到的影響、把影響停下來的做法、目前查到的原因或「尚未查完」、後續事項的負責人和完成日，有一項空著，狀態停在草稿。草稿可以繼續改。覆核人簽名之後，檢討放進封面寫明的存放處，並把存放路徑寫回這一次事故的編號。分享的範圍寫誰收到、走哪一條已經在用的管道。終端使用者的個人資料不隨這份檢討送出。三件事都在，才把狀態改成已覆核：資料和影響寫齊、原因寫到已知的那一步並有人繼續查未完的部分、每一項後續事項都有負責人和完成日。