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