AI 100 講
← M09 MLOps 與部署 M09 MLOps 與部署

M09.09｜AI 系統的可靠性工程：讓 AI 服務穩如磐石

準確率 99% 但掛掉 10% 的時間 — 可靠性才是 AI 上線的真正門檻

L2-系統部署-系統穩定性維運 L2-AI技術應用-系統架構設計
🇺🇸 DOL AI Literacy 🔎 評估 AI 產出 📶 解決先備條件
可靠性工程 SLA SLO 故障容錯 降級策略 負載均衡 高可用性 服務可用性 熔斷器
📋

本講學習重點

SLA、SLO、SLI 三者的關係和差別是什麼？
AI 系統的可靠性為何比傳統軟體更難保證？
什麼是熔斷器模式？它解決了什麼問題？
降級策略在 AI 系統中有哪些常見的實作方式？
藍綠部署和滾動部署各有什麼優缺點？

SLI（指標）→ SLO（目標，內部）→ SLA（協議，對外承諾），違反 SLA 通常有財務懲罰

99.9% 可用性 = 每年 8.76 小時停機；99.99% = 每年 52 分鐘；99.999% = 每年 5.26 分鐘

AI 系統特有的可靠性挑戰：模型退化（準確率下滑但服務仍在跑）、GPU 記憶體洩漏、依賴外部資料源的不穩定性

熔斷器：正常（Closed）→ 錯誤率超閾值時斷開（Open）→ 一段時間後半開（Half-Open）→ 恢復正常

降級策略：AI 推論失敗時，fallback 到規則引擎、快取結果、預設回應，而非直接回傳錯誤

負載均衡：在多個推論服務實例之間分配流量；自動擴縮容（Auto-scaling）根據負載增減實例數

錯誤預算（Error Budget）：SLO 允許的失敗比例，用完後應暫停高風險部署，優先提升可靠性

📌 AI 系統的可靠性工程超越了傳統軟體可靠性的範疇——除了服務可用性（不當機），還需要確保模型品質可靠性（不輸出嚴重錯誤的結果）。SLA/SLO/SLI 框架提供了量化可靠性目標的語言；熔斷器、重試、超時、降級是常見的容錯設計模式；負載均衡和自動擴縮容確保系統在流量高峰下不崩潰；藍綠部署和金絲雀部署降低了上線風險。最重要的是：在 AI 系統設計初期就把可靠性納入需求，而非事後補救。
AI 系統的可靠性工程：讓 AI 服務穩如磐石

🎙️ Podcast（中文）

0:00 / 0:00

一句話搞懂

AI 系統的可靠性工程就是確保你的 AI 服務不只「在理想情況下能正常運作」，而是在流量暴增、網路不穩、硬體故障、模型輸出異常等各種真實世界的混亂中，仍然能給用戶一個可接受的體驗——有時候「給出一個次優的結果」比「報錯 500 Internal Server Error」對用戶的傷害小得多，而這種「優雅地失敗（Graceful Degradation）」的能力，是生產級 AI 系統必須刻意設計的。

白話解說

AI 系統和傳統軟體的可靠性差別

傳統軟體的可靠性工程通常關注一個核心問題：「服務是不是在跑？（Is it up or down?）」。一個網頁伺服器要麼能回應 HTTP 請求，要麼不能——這個狀態很清楚。

AI 系統的可靠性工程要複雜得多，因為它需要同時關注兩個維度：

第一維度：服務可用性（Operational Reliability）：AI 推論服務有沒有在跑？延遲有沒有超標？這和傳統軟體沒什麼本質差別，都是標準的 DevOps 問題。

第二維度：模型品質可靠性（Model Quality Reliability）：這是 AI 系統獨有的可靠性問題。服務在線上跑得好好的，但模型可能因為資料漂移、概念漂移、訓練-服務偏差等原因，正在輸出越來越不準確的結果——服務沒有「掛掉」，但它在「悄悄做錯誤決策」。一個在線上一直在跑但輸出全是亂預測的詐欺偵測模型，對業務的傷害可能比一次 2 小時的服務中斷更大。

因此，AI 系統的可靠性工程必須同時涵蓋：確保服務不中斷（傳統 SRE 問題），以及確保模型輸出品質不退化（MLOps 特有問題）。

SLA、SLO、SLI：量化可靠性的語言

要管理可靠性，首先需要一套可以量化和溝通的語言框架。Google SRE（Site Reliability Engineering）團隊提出的 SLA/SLO/SLI 三層架構，已成為業界標準：

SLI（Service Level Indicator，服務等級指標）：可以測量的、反映服務健康狀態的具體指標數值。例如：過去 30 天的可用性為 99.87%；過去 7 天的 P99 延遲為 287ms；過去 24 小時的推論成功率為 99.94%。SLI 是「實際測量到的數字」。

SLO（Service Level Objective，服務等級目標）：內部設定的 SLI 目標值。例如：可用性 SLO = 99.9%；P99 延遲 SLO = 500ms；推論成功率 SLO = 99.5%。SLO 是「我們自己承諾要達到的目標」，是工程團隊努力的方向。

SLA（Service Level Agreement，服務等級協議）：對外部客戶承諾的可靠性保證，並附帶違反協議的後果（通常是補償或退費）。例如：「保證月可用性 99.9%，若未達到每降低 0.1% 退還 10% 的月費」。SLA 是「我們對客戶的法律承諾」，通常比 SLO 寬鬆（為工程團隊留出緩衝空間）。

錯誤預算（Error Budget）：SLO 中隱含的允許失敗比例。如果可用性 SLO = 99.9%，那麼錯誤預算就是 0.1%——每月允許最多 43.2 分鐘的停機時間。錯誤預算是一個重要的工程管理工具：當錯誤預算還充足時，工程團隊可以積極推進新功能上線（有一定風險也可以接受）；當錯誤預算快用完時，應該暫停高風險部署，優先修復可靠性問題，否則可能違反 SLA。

從「九」看可用性目標

可用性目標通常用「幾個九」來表示，每多一個「九」意味著對停機容忍度更嚴苛：

可用性 年度停機時間 月度停機時間 適用場景
99%（兩個九） 87.6 小時 7.3 小時 非關鍵業務工具
99.9%（三個九） 8.76 小時 43.8 分鐘 大多數商業 SaaS
99.95% 4.38 小時 21.9 分鐘 電商平台、金融 App
99.99%（四個九） 52.6 分鐘 4.38 分鐘 支付系統、醫療系統
99.999%（五個九） 5.26 分鐘 26.3 秒 航空管制、核電廠控制

從三個九提升到四個九，不是難一倍，而是需要一個完全不同量級的工程投入——需要多區域部署、自動故障轉移（Failover）、混沌工程（Chaos Engineering）測試等複雜機制。追求不必要的高可用性，會導致過度工程和資源浪費；低估了可靠性需求，則會讓用戶受苦。選擇「剛好夠」的可用性目標，是架構決策中的重要判斷。

熔斷器模式：防止故障蔓延

在分散式系統中，一個服務的故障可能像骨牌效應一樣，蔓延到依賴它的所有服務，最終導致整個系統崩潰。熔斷器模式（Circuit Breaker Pattern） 是阻止這種故障蔓延的重要設計模式。

名稱來自電路熔斷器：當電路過載時，熔斷器自動斷開，保護後面的設備不被燒毀。在軟體中，熔斷器位於服務調用的路徑上，有三個狀態：

Closed（正常）：所有請求正常通過，同時持續統計錯誤率。

Open（斷開）：當錯誤率超過閾值（如 5 秒內有 50% 的請求失敗），熔斷器斷開，所有後續請求不再發送給故障的服務，而是直接返回錯誤（或啟動降級邏輯）。這防止了「持續向一個無法回應的服務發送請求，佔用資源和增加其負擔」的問題。

Half-Open（半開）：斷開一段時間後（如 30 秒），熔斷器進入半開狀態，允許少量的探測請求通過。如果探測請求成功，熔斷器恢復到 Closed 狀態；如果仍失敗，繼續保持 Open 狀態並等待下一輪探測。

在 AI 系統中，熔斷器特別重要：如果 GPU 推論服務因為 OOM（記憶體溢出）開始大量超時，沒有熔斷器的上游服務會因為等待超時而阻塞，積累的連接最終拖垮整個系統。有了熔斷器，上游服務能快速失敗（Fast Fail）並啟動降級邏輯，系統其他部分不受影響。

降級策略：優雅地失敗

當 AI 推論服務不可用時，最差的用戶體驗是直接報錯「503 Service Unavailable」。降級策略（Graceful Degradation） 的設計哲學是：服務品質降低了，但至少還能提供「某種程度上」有用的回應，而非完全崩潰。

AI 系統常見的降級策略：

快取回應（Cache Fallback）：把近期的推論結果快取，當推論服務無法回應時，返回快取的結果。適合結果不需要完全即時的場景（如商品推薦：用昨天的個人化推薦，比完全沒有推薦體驗好得多）。快取結果需要設置合理的 TTL（Time To Live），避免過期資料被長時間使用。

規則引擎後備（Rule-Based Fallback）：AI 推論失敗時，切換到人工定義的規則引擎。例如：信用評分模型不可用時，切換到「年收入 > 50 萬、工作年資 > 3 年、無逾期紀錄 → 核准」這類簡單規則。準確率比 AI 模型低，但至少業務不停擺。

降質推論（Simplified Model Fallback）：維護一個「輕量備援模型」（如邏輯回歸或決策樹），當主要的深度學習模型不可用時，切換到備援模型。輕量模型的準確率較低，但資源需求極少，可靠性更高。

預設回應（Safe Default）：在沒有任何更好選項時，返回一個「安全的預設值」。例如詐欺偵測系統推論失敗時，預設把交易標記為「需要人工審核」（而非直接放行）；醫療影像分析不可用時，預設建議「請諮詢醫師」而非給出診斷。

負載均衡與自動擴縮容

單一推論服務實例無法處理大流量，也缺乏容錯能力（一個實例故障，服務就中斷）。負載均衡（Load Balancing） 和 自動擴縮容（Auto-scaling） 是解決這兩個問題的標準方案：

負載均衡：在多個推論服務實例之間分配流量，讓每個實例的負載均衡。常見算法：輪詢（Round Robin，依序分配）、最少連接（Least Connections，優先分配給目前連接數最少的實例）、一致性雜湊（Consistent Hashing，確保同一個用戶的請求始終路由到同一個實例，適合有狀態的推論）。

自動擴縮容：當流量增加時，自動啟動新的推論服務實例（Scale Out）；當流量下降時，自動縮減實例數量（Scale In），避免資源浪費。AI 推論服務的擴縮容要特別注意：GPU 實例的啟動時間比 CPU 實例長（通常 1–3 分鐘，因為需要載入模型），所以擴縮容策略需要「提前預測」流量高峰，而非「到了才擴」。根據時間規律（如每天中午 12 點前預先擴容）的預測性擴縮容，是 AI 推論服務的常見最佳實踐。

應用場景

場景 可用性目標 主要可靠性挑戰 降級策略
電商推薦系統 99.9% 流量高峰（大促）、模型推論延遲 快取推薦結果，fallback 到熱銷排行榜
即時詐欺偵測 99.99% 延遲敏感（需在支付完成前決策） 降級到規則引擎，疑問案例轉人工
醫療診斷輔助系統 99.9%（工作時間） 模型品質可靠性（不可輸出極端錯誤） 不可用時強制提示「請咨詢醫師」
自動駕駛感知 99.999% 極低延遲、多模型協同故障 安全模式（降速靠邊，等待人工接管）
對話式 AI 客服 99.5% GPU 推論延遲、模型輸出不當內容 切換到 FAQ 靜態回答，排隊等待人工
廣告即時競價 AI 99.95% 毫秒級延遲要求、高並發 超時時用歷史出價均值作為預設出價
倉儲機器人路徑規劃 99.9% 計算複雜度高、環境感知延遲 降速並切換到保守的固定路徑規劃

常見誤區

誤區 1：「SLA 設 99.9% 就好，反正出了問題補用戶就行」

把 SLA 視為純財務問題（違反了就補償），忽略了可靠性對品牌信任和用戶留存的長期影響。研究顯示，用戶在遭遇一次嚴重服務中斷後，40% 的人會考慮更換競爭對手的服務；在金融、醫療等高度信任的場景，一次重大故障可能讓用戶失去信心，不論補償多少都難以挽回。更重要的是，可靠性工程的成本不是線性的——從 99% 提升到 99.9% 的成本，遠低於因 99% 可用性帶來的用戶流失損失。

此外，AI 系統的「故障」有一種特別危險的形式：靜默失敗（Silent Failure）。服務沒有報錯，但模型正在輸出嚴重偏差的結果，這種情況既不觸發 SLA 的可用性指標，也不會有用戶投訴（因為用戶可能不知道「正確答案」是什麼）。例如推薦系統開始只推薦高利潤商品而不再是用戶感興趣的商品；信用評分模型系統性地對特定族群過度評分。這種靜默失敗的損害往往比服務中斷更大且更難察覺，這就是為何 AI 系統的 SLO 必須包含模型品質指標（如預測分佈的 PSI < 0.2）而不只是可用性數字。

誤區 2：「加了重試就夠了，失敗了讓客戶端自動重試就好」

重試（Retry）是容錯設計的基礎工具，但如果使用不當，重試本身可能成為造成系統崩潰的原因。想像以下場景：服務因為流量過大開始響應緩慢，客戶端發現超時後進行重試，但重試又進一步增加了服務的負擔，導致更多超時，觸發更多重試……這個正反饋循環被稱為重試風暴（Retry Storm），可以在幾秒內把一個本來只是響應慢的服務徹底壓垮。

正確的重試設計需要以下幾個要素同時到位：指數退避（Exponential Backoff）——第一次重試等 1 秒，第二次等 2 秒，第三次等 4 秒，避免重試請求密集地打在服務上；抖動（Jitter）——在等待時間上加入隨機抖動（如等待時間 = 2^n + random(0, 1) 秒），防止所有客戶端同步重試；最大重試次數——設定上限（如最多重試 3 次），不能無限重試；與熔斷器結合——當熔斷器斷開時，客戶端不應再重試（因為服務已確定不可用），而應直接走降級路徑。此外，「幂等性（Idempotency）」也必須考慮——重試只應用於幂等的操作（讀取、查詢），對於有副作用的操作（支付、下單），重試前必須先確認前一次操作是否已成功，避免重複執行。

誤區 3：「高可用性和快速迭代是互相矛盾的，要穩定就要犧牲速度」

這個誤解源於把「高可用性」和「保守、緩慢的部署節奏」混為一談。事實上，恰恰相反：好的可靠性工程實踐，讓你可以更快地、更安心地部署新版本。

傳統上「部署慢、測試多」的做法，是在可靠性工程工具不完善時的應對方式——因為沒有好的方式即時觀察部署後的系統狀態，只能用「部署前充分測試」來降低風險，但這限制了迭代速度。現代的可靠性工程實踐（金絲雀部署 + 自動回滾 + 完善監控）讓你能夠「快速部署，快速發現問題，快速回滾」——金絲雀部署讓只有 1% 的流量受到新版本的影響，自動化監控能在 5 分鐘內偵測到業務指標的異常，自動回滾讓問題在影響大多數用戶之前就被修復。Google 和 Netflix 每天部署幾十甚至幾百次新版本，同時維持 99.99% 以上的可用性，靠的正是完善的自動化可靠性工程工具，而非「放慢速度」。

小練習

練習 1：設計 SLO 和錯誤預算

你是一家台灣電商平台的 SRE 工程師，負責為 AI 推薦系統制定 SLO。平台有以下基本情況：

  • 每日活躍用戶（DAU）：50 萬
  • 高峰時間：每晚 8–10 點 PM，高峰 QPS 約為平均 QPS 的 5 倍
  • 雙 11 當天：流量是平時的 20 倍
  • 競爭對手保證：momo 和蝦皮都宣稱「99.9% 可用性」

請設計以下 SLO：

  1. 可用性 SLO（百分比）：你會設定多少？理由是什麼？
  2. 推論延遲 SLO（P50、P99）：考慮到高峰和一般時段的差異，你如何設定？
  3. 模型品質 SLO：除了可用性和延遲，你還需要哪些模型品質的 SLO？請提出至少 2 個。
  4. 計算月度錯誤預算：依據你設定的可用性 SLO，每月允許多少分鐘的停機時間？

練習 2：設計降級策略

你的電商推薦系統發生了一次完整的 GPU 叢集故障（所有 GPU 推論實例同時宕機），故障持續時間預計需要 45 分鐘才能恢復。此時正值週六晚上 9 點（高峰期），每分鐘有約 12,000 個用戶同時在線，推薦系統完全不可用。

請設計一個完整的降級應對方案，說明：

  1. 立即措施（0–5 分鐘）：在推論服務不可用的情況下，用戶看到的是什麼？
  2. 短期緩解（5–45 分鐘）：如何在不需要 GPU 的情況下，提供「次優但可接受」的推薦體驗？
  3. 對業務影響的評估：這 45 分鐘的降級期間，大約對轉換率和用戶體驗有多大影響？
  4. 事後預防：如何修改架構設計，避免下次 GPU 故障時需要完全降級？
查看答案 **練習 1：電商推薦系統 SLO 設計** **可用性 SLO：99.95%** 選擇理由： - 99.9% 是競爭對手的基準線，選擇 99.95% 能在可靠性上建立差異化競爭優勢 - 99.95% 對應每月約 21.9 分鐘的停機預算，工程上可實現（需要多區域部署 + 自動 Failover） - 電商推薦系統的故障會直接影響轉換率和營收，每分鐘停機的業務損失可以計算：50 萬 DAU / 24 小時 = 約 20,833 人/小時，高峰期可達 5 倍即約 104,000 人/小時線上，假設轉換率 3%、平均訂單金額 500 元，每分鐘停機損失約 104,000 / 60 × 3% × 500 ≈ 2.6 萬元 - 選擇 99.99% 過於激進（需要極複雜的工程，且成本遠高於業務收益） **推論延遲 SLO**： - 一般時段：P50 ≤ 80ms，P99 ≤ 300ms - 高峰時段（晚上 8–10 點）：P50 ≤ 150ms，P99 ≤ 600ms（因流量是平時 5 倍，允許更寬鬆的目標） - 雙 11 特別預案：P50 ≤ 300ms，P99 ≤ 1,000ms（提前規劃額外擴容，但設定更寬鬆的 SLO 以應對 20 倍流量） - 說明：P99 目標設定為用戶能感知延遲的閾值（人類對 1 秒以內的等待通常可接受，超過 3 秒開始明顯不耐煩） **模型品質 SLO（至少 2 個）**： 1. **推薦多樣性指標**：推薦列表的品類多樣性（每 10 個推薦中，至少涵蓋 3 個不同品類）月度達標率 ≥ 99%。防止模型退化成「只推某一類商品」的過度收斂問題。 2. **點擊率健康度指標**：推薦列表的整體點擊率（CTR）7 日滑動平均，不得低於過去 30 天均值的 80%。若 CTR 持續下滑，說明推薦品質退化，需要觸發重訓練或人工調查。 3. （額外建議）**預測分佈穩定性**：每個關鍵特徵的 PSI 每日計算，須 < 0.2。超過 0.2 時觸發告警並評估是否需要重訓練，確保模型的輸入分佈沒有嚴重漂移。 **月度錯誤預算計算（99.95% 可用性）**： - 月度分鐘數：30 天 × 24 小時 × 60 分鐘 = 43,200 分鐘 - 允許停機比例：1 - 99.95% = 0.05% - 月度錯誤預算：43,200 × 0.05% = **21.6 分鐘** 意義：工程團隊每月只有約 21.6 分鐘的「停機額度」，必須管理好這個預算——計劃性維護、部署風險、意外故障都要從這個預算中扣除。 --- **練習 2：GPU 叢集故障降級應對方案** **立即措施（0–5 分鐘）**： 推論服務完全不可用的前 5 分鐘，用戶看到的應該是**快取的個人化推薦結果**（如果存在快取）或**熱銷排行榜**（始終可用，不依賴 GPU）。 具體做法：在負載均衡器層，當推論服務的健康檢查失敗時，自動切換到降級端點（Fallback Endpoint）： - 若用戶有歷史行為，返回最近 24 小時快取的個人化推薦結果（Redis 快取，TTL = 24 小時） - 若用戶是新用戶或快取已過期，返回當前類別的熱銷排行前 20（從資料庫即時查詢，不需要 GPU） 前端 UI 不顯示任何錯誤訊息，用戶看到的是「正常的推薦列表」（雖然是過期的或非個人化的），這比顯示「推薦系統暫時無法使用」的空白頁面體驗好得多。 **短期緩解（5–45 分鐘）**： 在沒有 GPU 的情況下，可以使用以下不依賴深度學習推論的「輕量化推薦策略」： 1. **協同過濾的近似計算版本**（CPU 可運行）：預先計算好的「購買了 A 的人也購買了 B」的商品關聯矩陣（存在 Redis），根據用戶的瀏覽/購買歷史，即時查詢關聯商品。這不需要 GPU，延遲 < 50ms。 2. **分類排行榜個人化版本**：根據用戶的偏好品類（存在用戶 Profile 資料庫），返回各品類的熱銷排行。例如用戶歷史顯示偏好「3C 電子」和「運動用品」，則推薦這兩個類別的熱銷前 10。 3. **提升快取 TTL**：在故障期間，把快取的個人化推薦結果 TTL 從 24 小時延長到 72 小時，讓更多用戶能享用快取結果，減少 fallback 到熱銷排行的比例。 **業務影響評估**： - 使用快取個人化推薦的用戶（假設 70% 有近 24 小時快取）：點擊率約下降 10–15%（因為推薦已過期，不是最新的個人化結果），轉換率約下降 5–8% - 使用輕量化 CPU 推薦的用戶（20%）：點擊率約下降 20–30%，轉換率約下降 15–20% - 使用純熱銷排行的用戶（10% 新用戶）：點擊率約下降 30–40%，轉換率約下降 25–30% 整體估計：45 分鐘故障期間，整體轉換率約下降 10–15%，按照每分鐘損失 2.6 萬元的估計，45 分鐘約損失 117 萬元（相比完全停擺的損失會小很多）。 **事後預防（架構改進）**： 1. **多可用區 GPU 部署**：在至少 2 個不同的可用區（AZ）部署 GPU 推論叢集，配置負載均衡在可用區之間自動 Failover。這樣單一 AZ 的 GPU 故障不再導致完全不可用，另一個 AZ 的實例自動承接所有流量（可用性不變，但效能下降至正常的 50%，通常可接受）。 2. **CPU 備援推論池**：常態維護一組 CPU 推論實例（使用輕量化量化模型，如 INT8 的 MobileNet 推薦模型），在 GPU 不可用時自動切換。CPU 推論的效能（準確率和速度）比 GPU 差，但服務不中斷。成本相對低（CPU 實例遠比 GPU 便宜），但需要維護兩套推論路徑。 3. **增強快取策略**：將推薦快取的 TTL 從 24 小時提升到 48 小時，並增加快取的覆蓋率（每次用戶請求都更新快取，而非只在快取過期時更新）。這樣在 GPU 故障時，更多用戶能享用相對新鮮的快取個人化結果。 4. **建立故障演練（Chaos Engineering）常規**：每季在非高峰時段主動模擬 GPU 叢集故障，驗證降級路徑是否正常工作、自動 Failover 是否如預期切換、業務指標的下滑幅度是否在可接受範圍內。這樣在真正的故障發生時，降級流程已被充分驗證，不會臨時慌亂。

關鍵字自我檢核

✅ 可靠性工程 ✅ Reliability Engineering ✅ SLA ✅ Service Level Agreement ✅ SLO ✅ Service Level Objective ✅ SLI ✅ Service Level Indicator ✅ 故障容錯 ✅ Fault Tolerance ✅ 降級策略 ✅ Graceful Degradation ✅ 負載均衡 ✅ Load Balancing ✅ 熔斷器模式 ✅ Circuit Breaker Pattern ✅ 重試策略 ✅ Retry Strategy ✅ 超時設定 ✅ Timeout ✅ 藍綠部署 ✅ Blue-Green Deployment ✅ 備援機制 ✅ Fallback Mechanism ✅ 可用性 ✅ Availability ✅ MTTR ✅ Mean Time To Recovery ✅ MTBF ✅ Mean Time Between Failures