Last reviewed 2026-10-27 UTC
Google Cloud Well-Architected Framework 可靠性支柱中的這項原則，可協助您為 Google Cloud中的工作負載，定義技術上可行的可靠性目標。
這項原則與可靠性的範圍重點領域相關。
原則總覽
設計系統時，應以使用者滿意度為準，確保系統可靠性達到所需水準。這可能不符合直覺，但 100% 可靠性的目標通常不是最有效的策略。提高可靠性可能會大幅增加成本，包括財務投資和創新方面的潛在限制。如果使用者對目前的服務水準感到滿意，那麼進一步提升滿意度的努力可能只會帶來低投資報酬率。因此，您可以將資源用在其他地方。
您必須判斷使用者滿意的可靠性程度，並找出漸進式改善的成本開始超過效益的時間點。確定足夠的可靠性等級後，您就能策略性地分配資源，並專注於能為使用者帶來更高價值的功能和改善項目。
建議
如要設定合理的可靠性目標，請參考下列子節的建議。
接受部分失敗並優先處理元件
請以高可用性為目標，例如 99.99% 的運作時間，但不要將目標設為 100% 運作時間。承認某些失敗是不可避免的。
100% 正常運作時間與 99.99% 目標之間的差距，就是容許失敗的範圍。這個差距通常稱為「錯誤預算」。錯誤預算可協助您承擔風險和創新，這是任何企業保持競爭力的根本。
優先確保系統中最重要元件的可靠性。接受較不重要的元件可以有較高的故障容忍度。
兼顧可靠性和成本
如要判斷系統的最佳可靠性等級，請進行徹底的成本效益分析。
請考量系統需求、故障後果，以及貴組織對特定應用程式的風險承受度等因素。請務必考量災難復原指標，例如復原時間目標 (RTO) 和復原點目標 (RPO)。在預算和其他限制條件內，決定可接受的可靠性等級。
尋找提高效率和降低成本的方法，同時不影響重要的可靠性功能。