搜尋意圖： 如果你在找「高可用性 是什麼」或「高可用性 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 系統在面對故障、維護和負載波動時，能持續提供服務、維持高正常運行時間的設計屬性。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
系統在面對故障、維護和負載波動時，能持續提供服務、維持高正常運行時間的設計屬性。
高可用性（High Availability, HA）是現代 AI 基礎設施設計的核心目標之一，尤其在大規模語言模型推論服務、即時推薦系統和自動駕駛等對停機時間零容忍的場景中，高可用性是系統能否投入生產的前提條件。
可用性的量化通常以「幾個九」表示：99.9%（三個九）允許每年約 8.7 小時中斷；99.99%（四個九）只允許每年約 52 分鐘中斷；99.999%（五個九）每年中斷時間不超過 5.3 分鐘。AI 推論服務通常以四個九為目標，關鍵業務場景要求五個九。
實現高可用性的核心策略是消除單點故障（Single Point of Failure, SPOF）。在 AI 推論架構中，這意味著：模型服務器部署多個副本（通常至少 3 個），通過負載均衡器分配流量；每個副本跑在不同的實體節點上（Rack-aware Placement），防止機架斷電影響所有副本；使用 Kubernetes 的 Pod Anti-Affinity 規則強制副本分散在不同節點。
健康檢查（Health Check）是高可用性的必要組件。Readiness Probe 確認模型已載入、可接受請求；Liveness Probe 定期發送探測請求，若模型進入死鎖或記憶體洩漏狀態則自動重啟容器。不健康的副本從負載均衡池中移除，流量自動切換到健康副本，使用者幾乎感知不到節點故障。
滾動更新（Rolling Update）策略確保模型版本升級過程中服務不中斷：每次只更新一個副本，等其健康後再更新下一個，始終保持至少 N-1 個副本在線服務。金絲雀部署（Canary Deployment）進一步降低更新風險：先讓 5-10% 流量打到新版本，確認性能指標正常後再逐步擴大比例。
多區域部署（Multi-Region Deployment）是更高層次的高可用性實現，將 AI 服務同時部署在多個地理區域的雲端資料中心，通過 DNS 負載均衡或全球流量管理器（如 AWS Route 53、Cloudflare）在區域間分配流量，即使某個雲端區域完全故障（如颱風斷電），其他區域仍能正常服務。
在 iPAS AI 應用規劃師考試中，高可用性是 AI 系統架構設計章節的重要考點，考生需要理解 SLA（服務層級協議）的可用性目標、主要實現手段（冗餘、故障轉移、健康檢查）以及與容錯性、可擴展性的關係。
從架構設計視角看，高可用性需要從多個層次同時設計：應用層（多副本部署、滾動更新）、資料層（主從複製、自動故障切換）、網路層（多路由、BGP 冗餘）、電力層（UPS、雙電源供應）。任何一個層次的單點故障都可能打破整體高可用保障。
雲端原生時代，容器化（Docker + Kubernetes）大幅降低了高可用架構的實現難度：Kubernetes 的 Deployment Controller 自動維持指定副本數，節點故障時自動在其他節點重新調度 Pod；HorizontalPodAutoscaler（HPA）根據 CPU/記憶體使用率或自訂指標自動伸縮副本數，在流量峰值時自動擴容，低谷時縮容節省資源。
對 AI 推論服務而言，高可用性還要考慮模型預熱（Warm-up）時間：大型模型（如 70B LLM）載入可能需要數分鐘，在新副本就緒前舊副本不能下線。MinReadySeconds 和 readinessProbe 的配置確保新副本真正準備好接受流量後才切換，避免使用者遇到「模型正在載入」的錯誤。 服務網格（Service Mesh，如 Istio）進一步強化了微服務架構的高可用性：通過 Sidecar 代理攔截所有服務間流量，自動重試失敗請求（retry logic）、熔斷（circuit breaker，防止雪崩效應）、超時控制，並提供統一的可觀測性（分散式追蹤、指標收集），讓運維團隊能快速定位高可用性問題的根源。
常見問題
高可用性與容錯性（Fault Tolerance）有什麼區別？
高可用性側重最大化服務正常運行時間，通過冗餘和快速故障切換實現；容錯性側重在部分組件故障時系統仍能正確運行，即使性能可能下降。高可用性是目標（結果），容錯性是實現手段（機制）。一個高可用系統通常具備容錯性，但容錯系統不一定追求極高的可用性百分比。
AI 推論服務如何在不影響可用性的情況下更新模型？
常用策略包括：藍綠部署（Blue-Green）同時維護新舊兩套完整服務，切換時零中斷；滾動更新逐個替換副本，始終保持服務；金絲雀部署先讓少量流量測試新版本。配合 Kubernetes 的 readinessProbe，確保新版本模型完全載入後才接收生產流量，避免使用者接觸到尚未就緒的模型。
衡量 AI 系統可用性時需要注意哪些指標？
除了傳統的 MTBF（平均故障間隔時間）和 MTTR（平均恢復時間），AI 系統還需要監控推論延遲百分位數（P99 延遲）、吞吐量（QPS）和錯誤率。可用性不只是「系統在線」，還要求系統在 SLA 定義的性能標準下正常運作。若推論延遲超過 SLA 閾值（如 > 500ms 視為故障），也計入不可用時間。