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