把 API 當機視為「事故」，而非「新聞」：一份 72 小時應變清單

2026 年 7 月中旬，主要入口的 AI 推論路由停擺了 72 小時。這不是公關危機，也沒有外部媒體報導，內部使用者只看到頁面回傳 502 錯誤。但從那天起，我們將「API 當機」從玄學變成了檢查清單（checklist）：動作、負責人、時間戳記，缺一不可。

第一步：確認是誰在哭

當機發生後 5 分鐘內，第一份工作不是寫公關稿，而是處理三件事：

- 確認受影響範圍：哪條路由（API 節點、推論閘道、快取層、CDN）報錯？日誌關鍵字是什麼？

- 檢查降級機制是否觸發：有沒有自動切換到 fallback 模型或本地快取？

- 通知內外部的利害關係人：用站內訊息通知技術團隊、編輯團隊，以及當前正在排隊請求的業務單位。

這一步只消耗 5 分鐘，但能避免「整條產線莫名降級」的持續性浪費。

第二步：拉起戰情室（事後查核，非猜測）

當機 15 分鐘還沒有恢復跡象時，指定唯一的決策者。這個決策者不是「技術負責人」，而是「知道該怎麼評估成本的人」——通常是不負責本次故障的資深工程師，因為他不會陷入「自救幻覺」，反而能看清全局。

決策者只負責三件事：

- 是否延長降級方案（例如切換到備用路由）？

- 是否啟動應急內容發布（如覆蓋頁、狀態頁）？

- 是否通知客戶預計恢復時間？

其他所有人關閉工單系統，只回覆「等待指令」。這不是軍事化管理，而是防止反覆切換導致問題複雜化。

第三步：給讀者一個臺階下

如果你的產品面向全球用戶，502 錯誤頁面必須支援多語系。

我要求團隊維護至少三個版本的臨時頁面：

- zh-CN: 「我們正在恢復服務，預計 XX 分鐘。」

- zh-TW: 「我們正在恢復服務，預計 XX 分鐘。」

- en: "Service temporarily unavailable. Estimated recovery in XX minutes."

並且，每 30 分鐘更新一次時間。這不是心理安慰，而是向讀者傳遞「我們仍在監控」的信号。

第四步：事後檢討——不追責，只追流程

當機結束後 24 小時內，召開一次「檢討會議」。會議只討論三個問題：

1. 時間軸是否完整？（從當機開始、發現、降級、恢復、通知，每個節點是否有記錄？）

2. 哪一步慢了？（例如：呼叫路由、人工決策、客戶通知，哪個環節超過正常閾值？）

3. 哪個預案沒生效？（例如：自動切換失敗、監控未覆蓋、文件未更新）

不點名、不扣績效。如果檢討後不更新文件和檢查點，等於什麼都沒學到。

第五步：把檢查清單變成「肌肉記憶」

最後，把這份 72 小時清單拆解成 72 小時以內的**單項動作**，存放在每個團隊的共享文件中。每次演練後更新。半年後回顧，你會發現：團隊對當機的反應從「慌了」變成「按清單走」。

---

*不是要你祈禱 API 永不當機，而是希望它當機時，你有一張能救場的地图。*