本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

師父在電話裡向林總幹事回報，地下二樓那處照明依前幾天的安排處理後，今晚巡查時沒有再看到原本的閃爍現象。總幹事請他繼續留意，後續紀錄一起整理。

我等他掛上電話，問他這樣是不是就算結案。師父說，目前能確認的是這次看到的狀況，原本有間歇性問題，還需要照安排觀察。

我想到另一件事：「那你的美國產品如果半夜掛了，你是台灣的白天時間也要起床修 bug 嗎？」

出事時，先知道誰受到什麼影響

師父繼續用 AI 客服草稿工具設計了一個事故推演。假設系統突然出現大量失敗通知，幾位客服說無法產生草稿，第一件事是確認影響範圍：哪些功能失效、哪些客戶受到影響、從什麼時間開始，以及原本的工作是否有替代方式。

我問：「你不先看最新一版改了什麼？」

師父說，可以有人查最近變更，但不要一開始就認定一定是它。還可能是外部服務、資料、設定或資源出了問題。先讓團隊掌握現象和影響，再根據證據安排排查。

Google SRE 將事故中的恢復工作，和協調人員、維持溝通的管理工作分開說明，並強調清楚的角色與處理紀錄。Google SRE Workbook：Incident Response

我說：「小公司哪有那麼多人分角色？」

師父回答，一個人可以兼做幾件事，但仍要知道現在誰在改系統、誰對外說明，以及由誰協調。否則三個人各自修改同一個環境，最後連哪個動作造成變化都分不清楚。

先控制影響，修復動作也要能被追蹤

師父把推演往下走。假設確認草稿產生失敗，但客服仍能使用原本的回覆流程，就可以先告知受影響的人，暫時改走原流程。是否停用某項功能、限制重試或暫停新資料進入，要依實際影響判斷。

我問：「回滾不就最快？」

師父說，要先確認能不能安全回到前一個版本。如果同時改過資料結構，或已經產生不能直接撤回的結果，回滾程式不一定能恢復原狀。回復方案應該事先準備，事故當下再依已知狀況選擇。

他補充，每次重要操作都要留下時間、原因和觀察結果。例如先調整流量，再確認失敗是否下降；如果沒有改善，就把這項結果記下。這樣換人接手時，才知道哪些已經試過，也能避免一直重複無效的動作。

我追問：「如果試了一次反而更差，要怎麼說？」

師父回答，就說做了什麼、看到了什麼，重新評估。事故紀錄的用途是幫大家處理問題，不能只留下看起來正確的步驟。事後才知道的答案，也不要寫成自己第一分鐘就已經掌握。

對客戶回報已知狀態，不猜一個修好時間

我問師父：「客戶一直催幾點好，你總得回答吧？」

師父說，可以回覆目前影響、已採取的安排，以及下次更新時間。若還沒有足夠資訊估計修復時間，就直接說明仍在確認，別隨口答應半小時。

他示範一段事故訊息的大意：部分使用者目前無法產生草稿，既有人工回覆流程仍可使用；團隊正在查明原因，下一次狀態更新預計在約定時間提供。這種說法讓客戶知道現在能做什麼，也知道何時會再得到消息。

我說：「聽起來沒有直接承諾，很容易被嫌慢。」

師父回答，承諾一個沒有依據的時間，也不會讓修復比較快。可以提高更新頻率，提供有用的替代安排，但資訊要跟得上實際狀況。

當系統恢復，也需要確認真正的工作流程。監控數字下降，不一定代表所有人都能完成工作；可能還有卡住的批次、失敗的通知或需要補處理的資料。恢復服務和把影響收尾，都應該有人追蹤。

事後把原因和改善接起來

我問：「那處理完就寫一篇事故報告？」

師父說，報告應該留下能改善的內容。什麼先發生、何時知道、哪些處理有用、哪裡讓大家多花時間，以及接下來要改什麼。找出程式原因以外，也可以看偵測、權限、交接和溝通是否有缺口。

如果最後只寫工程師要更小心，卻沒有改變讓錯誤容易發生的條件，下一次仍可能一樣。改善事項要有負責人和確認方式，也要真的排進工作，不能報告寫完就全部消失。

師父說，平常可以像剛才一樣做事故推演，檢查聯絡方式、角色和處理順序。推演時發現沒有人能決定某個動作，就有機會先補上安排。

事故當下先確認影響、控制損害、協調處理並持續回報；恢復之後，再完成根因追查和改善。