技術分享
AI 事故應變 Runbook：分級、應變步驟與復盤
AI 系統上線後難免遇上幻覺、API 逾時或成本暴衝，但多數團隊沒準備好事故發生時的應變流程。本文提供一套 SRE 式的 AI 事故應變 Runbook，涵蓋 SEV 分級、應變步驟與角色分工，並用真實案例與無咎化復盤機制，讓事故不再重演。
可靠性是設計出來的，不是出事才救
AI 系統比傳統軟體更脆弱，因為它把最不穩定的一環——外部 LLM 與第三方 API——放進了主要路徑。這不是杞人憂天：即使是 OpenAI 這樣的頭部供應商，服務可用度也不是永遠達標，2025 年 6 月就發生過一次影響全球用戶、長達數小時的重大中斷。限流（rate limit）錯誤更是生產環境中常見的失敗來源之一，隨著 AI 工作流大量呼叫外部 API，這類錯誤只會更頻繁出現。把這些狀況攤開會發現，依賴故障不是罕見異常，而是每個月都要遇上的常態，真正決定可靠度的，是設計階段有沒有先想好「失敗當下該怎麼撐住」。
先把停機換算成錢，才知道可靠性該投多少
可靠性投資最常見的錯誤，是無限追求 100% 不中斷。務實的做法是先算停機成本：Gartner 長期引用的基準是平均每分鐘約 5,600 美元、約每小時 33.6 萬美元；ITIC 2024 年調查更指出，九成以上的中大型企業一小時停機損失超過 30 萬美元，其中約四成落在 100 萬到 500 萬美元之間。有了這個數字，再回推需要多高的可用度——關鍵認知是：可用度每多一個 9，成本通常是跳級成長，而非線性增加。
| 可用度 | 每年容許停機 | 適合流程 |
|---|---|---|
| 99% | 約 3.65 天 | 內部工具、非即時的批次任務 |
| 99.9% | 約 8.8 小時 | 一般對外服務、內部核心系統 |
| 99.99% | 約 52 分鐘 | 交易、即時客服等關鍵流程 |
把每小時停機成本乘上目標可用度，就得到一個能拿去簽核預算的數字。一條每小時停機損失數十萬元的交易流程，從 99% 拉到 99.9% 等於一年少停約三天，多投架構就划算；一個內部報表工具硬套 99.99% 只是浪費。沒有這個數字，可靠性投資不是做太少、就是做過頭。
三個核心模式：熔斷、降級、重試
把可靠性設計進系統，靠的不是更貴的伺服器，而是三個歷經大規模驗證的失敗處理模式。它們最早由 Netflix 的 Hystrix 函式庫推廣，如今 Hystrix 已進入維護停更、新專案多改用 Resilience4j，但模式本身仍是業界標準。
| 模式 | 解決什麼 | 要注意的代價 |
|---|---|---|
| 重試（retry） | 短暫抖動、偶發逾時 | 要用指數退避加抖動，並搭配去重，否則放大流量、重複扣款 |
| 熔斷（circuit breaker） | 依賴持續失敗 | 熔斷期間該功能暫停，需定期試探恢復 |
| 降級（fallback） | 主路徑整個不可用 | 備援品質較低，必須事先定義可接受的簡化版本 |
重試處理「再試一次多半就好」的暫時性故障，重點是指數退避加上隨機抖動（full jitter），公式約為 sleep = random(0, min(上限, 基數×2^次數))，上限抓 32–60 秒、次數控制在 3–5 次以內，避免所有請求同時重試造成驚群效應把依賴壓垮；4xx 錯誤中通常只有 429（限流）值得重試，且若回應帶了 Retry-After 就照它等。牽涉付款、寫入的動作還要加上等冪金鑰（idempotency key，Stripe、PayPal 都以此為標準）確保重試不會重複生效。熔斷則相反：某依賴連續失敗時直接快速失敗，暫停呼叫再定期試探。降級是最後防線：主路徑真的掛了，就退到快取的舊結果、較簡單的模型或人工處理。
把三個模式串成一條請求的防護鏈
這三者不是三選一，而是在同一條請求路徑上依序疊起來。以呼叫 LLM 為例，2026 年生產級的合理順序是：
- 逾時（timeout）：先設每次呼叫的等待上限，避免卡住的請求拖住資源。
- 重試（retry）：逾時或暫時性錯誤時，以指數退避重試一到兩次，吸收偶發抖動。
- 熔斷（circuit breaker）：短時間內失敗超過門檻，就打開熔斷、停止呼叫，把後續請求直接導向下一層。
- 降級（fallback）：熔斷開啟或重試用盡後，切換到備援模型或快取結果，確保使用者永遠拿得到回應。
這條鏈的價值，在於任何一層擋不住的失敗都會被下一層接住。對多代理（multi-agent）系統尤其關鍵：若每一步成功率 85%，十步串起來的端到端成功率只剩約 19.7%，錯誤會沿著鏈路複利式放大。因此除了防護鏈，還要把「步數愈少愈好、每一步都設關卡」一起做，才擋得住這種級聯失敗。
降級鏈的成本陷阱
降級聽起來只有好處，實務上卻藏著一個反直覺的坑：如果備援模型比主模型更貴，故障期間流量全灌到備援，等於在業務已經受損的當下又把成本推高。2026 年的多模型路由（multi-model routing）實務因此強調——降級鏈要按成本調整後的品質排序，例如主模型 → 跨供應商的同級模型 → 同供應商較便宜的模型 → 自建開源模型，讓最壞情況的花費有上限。同時降級必須是明確、可測試的行為：靜默切換到不合適的模型，往往比直接回報失敗更糟。
落地順序：從最痛的那條路徑開始
不必一次替所有功能都套上完整防護。務實順序是：先找出停機成本最高、又最依賴外部服務的一兩條關鍵路徑，補齊逾時與重試，再對最不穩的依賴加上熔斷與降級，最後才擴展其餘流程。每加一層都要用故障注入（fault injection）實際模擬——手動關掉某個依賴、觀察系統是不是優雅降級而非整個卡死，而不是等真正出事那天才發現防護沒生效。可靠性不是一次到位的專案，而是隨依賴與流量變化持續調整的長期投資。
恩梯科技：把可靠性長在系統裡
可靠性工程的難處，不在於知道熔斷、降級、重試這些名詞，而在於準確判斷哪條路徑值得投資、每一層的門檻與退場行為該怎麼設，以及如何在降級時控制住成本——這需要同時懂業務損失與系統實作。恩梯科技的 AI 系統顧問與客製開發服務，會先幫你把關鍵流程的停機成本盤清楚，再對應到合適的可靠性設計，讓系統從一開始就具備撐過依賴故障的能力，而不是等上線出事、業務受損之後才回頭補救。
參考資料
- Tom's Guide，《ChatGPT / OpenAI down outage — live updates, June 10, 2025》，2025。來源連結
- Atlassian，《Calculating the cost of downtime》（引用 Gartner 停機成本基準）。來源連結
- ITIC，《ITIC 2024 Hourly Cost of Downtime Report》，2024。來源連結
- Netflix，《Hystrix》GitHub 專案說明（維護模式聲明）。來源連結
- Stripe，《Designing robust and predictable APIs with idempotency》。來源連結
