如要為雲端工作負載建構可靠的基礎架構，第一步是找出工作負載的可靠性需求。Google Cloud 基礎架構可靠性指南的這一部分提供相關指引，協助您定義在 Google Cloud中部署的工作負載可靠性需求。
判斷工作負載專屬需求
應用程式的穩定性需求取決於應用程式提供的服務或執行的程序性質。舉例來說，為銀行提供提款機服務的應用程式可能需要 99.999% 的可用性。支援線上交易平台的網站可能需要 99.999% 的可用性和快速回應時間。每天結尾將銀行交易寫入會計分類帳的批次程序，資料新鮮度目標可能是八小時。
在應用程式中，個別元件或作業可能會有不同的穩定性需求。舉例來說，與讀取要求相比，訂單處理應用程式可能需要更高的可靠性，才能將資料寫入訂單資料庫。
細部分析工作負載的可靠性需求，有助於將支出和心力集中在對業務至關重要的工作負載上。
找出關鍵時期
應用程式的重要性可能會因時而異。這些期間通常是應用程式負載量最高的時候。找出這些期間、規劃足夠的容量，並在尖峰負載條件下測試應用程式。為避免應用程式在尖峰負載期間發生中斷風險，您可以採取適當的作業做法，例如凍結正式版程式碼。
以下是負載會出現季節性尖峰的應用程式範例：
- 通常在排定每月、每季或每年進行的庫存稽核時，財務會計應用程式的庫存模組使用量會較高。
- 電子商務網站在購物旺季或促銷活動期間，負載量會大幅增加。
- 如果資料庫支援大學的學生入學模組，每年特定月份的寫入作業量就會很高。
- 線上報稅服務在報稅季期間的負載量會很高。
- 線上交易平台可能需要 99.999% 的可用性和快速回應時間，但僅限交易時段 (例如週一至週五上午 8 點至下午 5 點)。
考量其他非功能性需求
除了可靠性需求外，企業應用程式可能還有其他重要的非功能性需求，例如安全性、效能、成本和作業效率。評估應用程式的可靠性需求時，請考量這些其他需求帶來的依附元件和取捨。
以下列舉一些非可靠性需求，但可能與可靠性需求有所取捨。
- 成本最佳化：為節省 IT 成本，貴機構可能會對特定雲端資源設定配額。舉例來說，為降低第三方軟體授權的成本，貴機構可能會設定可佈建的運算核心數量配額。儲存資料量和跨區域網路流量也可能設有類似配額。請考量這些成本限制對設計可靠基礎架構的可用選項有何影響。
- 資料落地：為符合法規要求，應用程式可能需要在特定國家/地區儲存及處理資料，即使業務服務全球使用者也一樣。決定應用程式的部署區域和地帶時，請考量這類資料落地限制。
您為滿足其他需求而做出的特定設計決策，有助於提升應用程式的可靠性。例如：
- 部署作業自動化：為了有效率地運作雲端部署作業，您可能會決定使用基礎架構即程式碼 (IaC)，將佈建流程自動化。同樣地，您也可以使用持續整合和持續部署 (CI/CD) 管道，自動化應用程式建構和部署程序。使用 IaC 和 CI/CD 管道不僅能提升作業效率，還能提高工作負載的可靠性。
- 安全控管：您實作的安全控管機制也有助於提升應用程式的可用性。舉例來說，Google Cloud Armor 安全性政策可確保應用程式在阻斷服務 (DoS) 攻擊期間仍可正常運作。
- 內容快取：如要提升內容服務應用程式的效能，您可以啟用快取，做為負載平衡器設定的一部分。這項設計不僅能讓使用者更快存取內容，還能提高可用性。即使原始伺服器當機，使用者也能存取快取內容。
定期重新評估需求
隨著業務發展，應用程式的需求可能會改變。請定期重新評估可靠性需求，並確保這些需求符合貴機構目前的業務目標和優先事項。
假設應用程式為所有使用者提供標準層級的可用性。您可能已在區域內的兩個可用區中部署應用程式，並以區域負載平衡器做為前端。如果貴機構打算推出提供更高可用性的進階服務選項，應用程式的可靠性需求就會隨之改變。為符合新的可用性規定，您可能需要在多個區域部署應用程式，並啟用 Cloud CDN 使用全域負載平衡器。
發生中斷事件後，您也可以再次評估應用程式的可用性需求。服務中斷可能會導致貴商家不同團隊間的期望不一致。舉例來說，某個團隊可能認為每年 45 分鐘的服務中斷 (即 99.99% 的年度可用性) 是可接受的。但另一個團隊可能預期每月停機時間最多為 4.3 分鐘 (即每月可用性為 99.99% )。視您決定如何修改或釐清供應情形規定而定，您應調整架構以符合新規定。