本文件屬於Google Cloud Well-Architected Framework：金融服務 (FS) 觀點，概略說明在 Google Cloud建構、部署及操作穩健 FS 工作負載的原則和建議。這些建議可協助您設定觀測能力、自動化和擴充性等基本要素。本文中的建議符合 Well-Architected Framework 的卓越營運支柱。
由於 Google Cloud 中的 FS 工作負載具有高度管制和敏感性，因此卓越的營運能力至關重要。卓越營運可確保雲端解決方案能因應不斷變化的需求，並滿足您對價值、效能、安全性和可靠性的要求。如果這些領域發生問題，可能會導致重大財務損失、監管處罰和聲譽損害。
卓越營運可為 FS 工作負載帶來下列好處：
- 維持信任和信譽：金融機構高度仰賴客戶的信任。營運中斷或安全漏洞會嚴重破壞這種信任，並導致客戶流失。卓越營運有助於盡可能降低這些風險。
符合嚴格的法規遵循要求：金融服務必須遵守眾多複雜的法規，例如：
必須具備完善的作業程序、監控和事件管理機制，才能證明符合法規，避免受罰。
確保業務持續運作和復原能力：金融市場和服務通常會持續運作。因此，高可用性和有效的災難復原至關重要。卓越營運原則可指引您設計及實作具韌性的系統。可靠性支柱提供這方面的更多指引。
保護機密資料：金融機構會處理大量高度機密的客戶和財務資料。為防止資料侵害並維護隱私，必須採取強大的作業控管措施、安全監控和快速事件應變。安全性支柱提供這方面的更多指引。
最佳化重要應用程式的效能：許多金融應用程式 (例如交易平台和即時分析) 都需要高效能和低延遲。為滿足這些效能需求，您需要高度最佳化的運算、網路和儲存空間設計。效能最佳化支柱提供這個領域的更多指引。
有效管理成本：除了安全性和可靠性，金融機構也重視成本效益。卓越營運包括最佳化資源使用率和管理雲端支出的做法。成本最佳化支柱提供這方面的更多指引。
本文中的優質營運建議對應至下列核心原則：
定義服務水準協議，以及相應的服務等級目標和服務水準指標
在許多金融服務機構中，應用程式的可用性通常會根據復原時間目標 (RTO) 和復原點目標 (RPO) 指標進行分類。對於為外部客戶提供服務的業務關鍵應用程式，可能也會定義服務水準協議 (SLA)。
SLA 需要一個指標架構，從使用者滿意度的角度呈現系統行為。網站可靠性工程 (SRE) 做法可協助您達到所需的系統可靠性。建立指標架構時，必須定義及監控關鍵數值指標，從使用者的角度瞭解系統健康狀態。舉例來說，延遲時間和錯誤率等指標可量化服務的效能。這些指標稱為服務水準指標 (SLI)。開發有效的 SLI 至關重要，因為這類指標能提供客觀評估可靠性所需的原始資料。
如要定義有意義的 SLA、SLI 和 SLO，請參考下列建議：
- 為每項重要服務制定及定義 SLI。設定目標值，定義可接受的效能等級。
- 制定並定義與 SLI 對應的服務水準目標 (SLO)。舉例來說，SLO 可能會規定 99.9% 的要求延遲時間必須低於 200 毫秒。
- 找出服務不符合服務等級目標時，必須採取的內部補救措施。舉例來說，為了提高平台的韌性，您可能需要將開發資源集中用於修正問題。
- 驗證每項服務的服務水準協議 (SLA) 規定，並將 SLA 視為與服務使用者簽訂的正式合約。
服務水準範例
下表提供付款平台的 SLI、SLO 和 SLA 範例：
| 業務指標 | SLI | SLO | 服務水準協議 |
|---|---|---|---|
| 付款交易成功 | 量化指標，代表所有已啟動的付款交易中，成功處理並確認的百分比。 範例：(成功交易次數 ÷ 有效交易總數) × 100，以 5 分鐘為滾動時間範圍計算。 |
內部目標，在特定期間內維持高比例的成功付款交易。 範例：在 30 天的滾動週期內，維持 99.98% 的付款交易成功率，不含無效要求和預定維護。 |
合約保證付款交易處理的成功率和速度。 範例：服務供應商保證，客戶發起的付款交易中，有 99.0% 會在一秒內成功處理並確認。 |
| 付款處理延遲時間 | 從客戶發起付款交易到最終確認，處理付款交易所需的平均時間。 範例：交易確認的平均回覆時間 (以毫秒為單位)，以 5 分鐘為滾動週期測量。 |
付款交易處理速度的內部目標。 範例：確保 99.5% 的付款交易在 30 天滾動期間內，於 400 毫秒內處理完畢。 |
合約承諾在指定時間範圍內解決重大付款處理問題。 範例：針對重大付款處理問題 (定義為影響超過 1% 交易的中斷情形)，服務供應商承諾在問題回報或偵測到後的兩小時內解決。 |
| 平台適用情形 | 核心付款處理 API 和使用者介面可供客戶操作及存取的時間百分比。 範例：(總運作時間 - 停機時間) ÷ 總運作時間 × 100，以分鐘為單位。 |
核心付款平台正常運作時間的內部目標。 範例：每個月的平台可用性達到 99.995% (不含排定的維護期間)。 |
對客戶做出的正式、具法律約束力的承諾，保證付款平台的最短正常運作時間，並說明未達標準的後果。 範例：平台每個月至少維持 99.9% 的可用性，不含排定的維護期間。如果可用性低於最低水準，每下降 0.1%，客戶將獲得每月服務費 5% 的服務抵免額。 |
使用 SLI 資料監控系統是否在定義的 SLO 範圍內，並確保符合 SLA。工程師和開發人員可以使用一組定義明確的 SLI，在下列層級監控 FS 應用程式：
- 直接在部署應用程式的服務中，例如 Google Kubernetes Engine 或 Cloud Run。
- 使用基礎架構元件 (例如負載平衡器) 提供的記錄。
OpenTelemetry 提供開放原始碼標準和一組技術，可擷取所有類型的遙測資料，包括指標、追蹤記錄和記錄。Google Cloud Managed Service for Prometheus 提供全代管、高擴充性的指標後端，以及大規模的 Prometheus 作業。
如要進一步瞭解 SLI、SLO 和錯誤預算，請參閱 SRE 手冊。
如要開發有效的快訊和監控資訊主頁和機制，請搭配使用 Google Cloud Observability 工具和 Cloud Monitoring。如要瞭解安全性專屬的監控和偵測功能，請參閱安全性支柱。
定義及測試事件管理程序
定義明確且定期測試的事件管理程序，可直接提升 Google Cloud中 FS 工作負載的價值、效能、安全性和可靠性。這些程序可協助金融機構符合嚴格的法規要求、保護機密資料、維持業務連續性，並贏得客戶信任。
定期測試事件管理程序可帶來下列好處：
- 在尖峰負載下維持效能：定期進行效能和負載測試，有助於金融機構確保雲端式應用程式和基礎架構能處理尖峰交易量、市場波動和其他高需求情境，且效能不會降低。這項功能對於維持流暢的使用者體驗，以及滿足金融市場的需求至關重要。
- 找出潛在瓶頸和限制：壓力測試會將系統推向極限，讓金融機構在潛在瓶頸和效能限制影響重要營運之前，找出這些問題。這種主動做法可讓金融機構調整基礎架構和應用程式，達到最佳效能和擴充性。
- 驗證可靠性和韌性：定期測試 (包括混沌工程或模擬故障) 有助於驗證金融系統的可靠性和韌性。這項測試可確保系統能從故障中順利復原，並維持高可用性，這對業務持續運作至關重要。
- 進行有效的容量規劃：效能測試可提供不同負載條件下資源使用率的寶貴資料，這對準確的容量規劃至關重要。金融機構可運用這項資料，主動預測未來的容量需求，並避免因資源限制而發生效能問題。
- 成功部署新功能和程式碼變更：將自動化測試整合至 CI/CD 管道，有助於確保變更和新部署項目在發布至正式環境前，都經過徹底驗證。這個方法能大幅降低錯誤和迴歸風險，避免作業中斷。
- 符合系統穩定性的法規要求：金融法規通常要求機構採取完善的測試做法，確保重要系統穩定可靠。定期測試有助於證明符合這些要求。
如要定義及測試事件管理程序，請參考下列建議。
制定明確的事件應變程序
一套完善的事件應變程序應包含下列元素：
- 定義事件指揮官、調查人員、通訊人員和技術專家的角色和責任，確保應變措施有效且協調一致。
- 定義通訊協定和提報路徑，確保在事件期間能及時有效地分享資訊。
- 在執行手冊或應對手冊中記錄的程序，概述溝通、分類、調查和解決的步驟。
- 定期培訓和準備，讓團隊具備有效應對的知識和技能。
定期執行效能和負載測試
定期進行效能和負載測試，有助於確保雲端式應用程式和基礎架構能處理尖峰負載，並維持最佳效能。負載測試會模擬實際的流量模式。壓力測試會將系統推向極限，找出潛在瓶頸和效能限制。您可以使用 Cloud Load Balancing 等產品和負載測試服務，模擬實際流量。您可以根據測試結果調整雲端基礎架構和應用程式，以達到最佳效能和擴充性。例如，您可以調整資源分配或應用程式設定。
在 CI/CD 管道中自動執行測試
將自動化測試納入 CI/CD 管道，有助於在部署前驗證變更，確保雲端應用程式的品質和可靠性。這種做法可大幅降低錯誤和迴歸的風險，並協助您建構更穩定、更強大的軟體系統。您可以在 CI/CD 管道中納入不同類型的測試，包括單元測試、整合測試和端對端測試。使用 Cloud Build 和 Cloud Deploy 等產品，建立及管理 CI/CD 管道。
持續改良和創新
對雲端中的金融服務工作負載而言，遷移至雲端只是第一步。持續強化和創新至關重要，原因如下：
- 加速創新：運用 AI 等新技術提升服務品質。
- 降低成本：消除低效率問題，並充分運用資源。
- 提高靈活性：快速因應市場和法規變化。
- 提升決策品質：使用 BigQuery 和 Looker 等資料分析產品，做出明智決策。
為確保持續改善和創新，請參考下列建議。
定期回顧
回顧對於持續改善事件應變程序，以及根據定期效能和負載測試結果最佳化測試策略至關重要。為確保回顧會議有效，請採取下列做法：
- 讓團隊有機會反思經驗、找出成效良好的部分，並找出待改進之處。
- 在專案里程碑、重大事件或重要測試週期後，舉行回顧會議。團隊可以從成功和失敗中學習，持續改善流程和做法。
- 採用開始-停止-繼續模型等結構化方法，確保回顧會議能發揮成效，並產生可行的步驟。
- 透過回顧會議，找出可進一步強化變更管理自動化的領域，以提高可靠性並降低風險。
培養學習文化
學習文化有助於在Google Cloud中安全探索新技術，例如運用 AI 和機器學習功能，強化詐欺偵測和個人化財務建議等服務。如要推廣學習文化，請採取下列做法：
- 鼓勵團隊實驗、分享知識及持續學習。
- 建立不究責的文化，將失敗視為成長和改進的機會。
- 營造心理安全感，讓團隊敢於冒險並考慮創新解決方案。團隊能從成功和失敗中學習，進而打造出更具韌性和適應力的組織。
- 培養一種文化，促進分享從事件管理流程和測試演練中獲得的知識。
掌握最新雲端技術
持續學習對於瞭解及實施新的安全措施、運用進階資料分析取得更深入的洞察，以及採用與金融服務相關的創新解決方案至關重要。
- 隨時掌握最新進展、功能和最佳做法，充分發揮 Google Cloud 服務的潛力。
- 推出新的 Google Cloud 功能和服務時，請找出機會進一步自動化程序、強化安全性，以及提升應用程式的效能和擴充性。
- 參加相關會議、網路研討會和訓練課程，拓展知識並瞭解新功能。
- 鼓勵團隊成員取得Google Cloud 認證，確保組織具備在雲端環境中取得成功所需的技能。