這份文件屬於Google Cloud Well-Architected Framework：金融服務 (FS) 觀點，概略說明在 Google Cloud中最佳化 FS 工作負載效能的原則和建議。本文中的建議符合 Well-Architected Framework 的效能最佳化支柱。
金融服務業長久以來都致力於提升效能。這項技術協助金融服務機構克服技術挑戰，且幾乎總是能促成或加速新商業模式的建立。舉例來說，ATM (1967 年推出) 自動化現金提領流程，協助銀行降低核心業務成本。繞過 OS 核心和將應用程式執行緒固定至運算核心等技術，有助於確保交易應用程式的確定性和低延遲。延遲時間縮短後，金融市場的流動性更高、更穩定，價差也更小。
雲端技術為效能最佳化帶來新契機。此外，這項技術也挑戰了部分過去公認的最佳化模式。具體來說，在雲端中，下列權衡取捨更透明且可控：
- 推出速度與成本。
- 系統層級的端對端效能與節點層級的效能。
- 人才可用性與技術相關決策的靈活度。
舉例來說，在雲端中，根據特定技能需求調整硬體和 IT 資源是輕而易舉的事。如要支援 GPU 程式設計，您可以建立以 GPU 為基礎的 VM。您可以擴充雲端容量，因應需求激增的情況，不必過度佈建資源。這項功能可確保工作負載能處理尖峰負載，例如非農就業人口資料公布日，以及交易量明顯高於歷來水準時。您不必花費心力在個別伺服器層級編寫高度最佳化的程式碼 (例如以 C 語言編寫的高度微調程式碼)，或為傳統高效能運算 (HPC) 環境編寫程式碼，而是可以使用架構完善、以 Kubernetes 為基礎的分散式系統，以最佳方式水平擴展。
本文件中的效能最佳化建議對應至下列核心原則：
根據主要業務指標調整技術成效指標
您可以透過多種方式，將成效最佳化對應至業務價值成果。舉例來說，在買方研究部門，業務目標可能是最佳化每小時研究產出，或優先處理過往成效良好團隊的實驗，例如夏普比率較高的團隊。在賣方方面，您可以使用數據分析追蹤客戶興趣，並據此優先處理支援最有趣研究的 AI 模型。
將成效目標與業務主要成效指標 (KPI) 連結，對於資助成效改善也相當重要。與日常業務 (BAU) 或銀行營運作業相比，業務創新和轉型計畫 (有時稱為銀行轉型工作) 的預算不同，且資源存取權限可能也不同。例如， Google Cloud 協助 G-SIFI 的風險管理和技術團隊與前台量化分析師合作，開發出可在幾分鐘內 (而非數小時或數天) 執行風險分析計算 (例如 XVA) 的解決方案。這項解決方案協助該組織符合相關法規遵循要求。此外，交易員也能與客戶進行更高品質的對話，進而提供更小的價差、更穩定的流動性，以及更具成本效益的避險。
將成效指標與業務指標對齊時，請考慮下列建議：
- 將每項技術計畫與相關的業務目標和關鍵成果 (OKR) 連結，例如提高收益或利潤、降低成本，以及更有效率或更全面地降低風險。
- 著重於最佳化系統層級的效能。不要侷限於傳統的「改變銀行」與「經營銀行」區分，以及「前台」與「後台」的孤島。
優先考量安全性，不因未經證實的風險而犧牲效能
金融服務機構的安全性和法規遵循標準必須明確且高標準。維持高標準是避免流失客戶，以及防止組織品牌受到不可回復損害的關鍵。通常，最高價值來自生成式 AI 等技術創新，以及 Spanner 等獨特的代管服務。請勿因對營運風險或法規遵循情形不足的誤解，而自動捨棄這類技術選項。
Google Cloud 與 G-SIFI 密切合作，確保在機構服務客戶的管轄區內，能使用 AI 反洗錢 (AML) 做法。舉例來說，HSBC大幅提升金融犯罪 (Fincrime) 單位的績效，並取得以下成果：
- 已確認可疑活動的偵測量約提升 2 至 4 倍。
- 減少超過 60% 的誤判情形，並將調查時間集中在有參考價值的高風險快訊，降低營運成本。
- 可稽核且可理解的輸出內容，以便遵守法規遵循。
請參考下列建議：
- 確認您打算使用的產品，有助於滿足營運所在管轄區的安全性、韌性和法規遵循要求。為達成這個目標，請與 Google Cloud帳戶團隊、風險團隊和產品團隊合作。
- 運用 AI 可解釋性，建立更強大的模型，並向客戶提供透明資訊。
如果可解釋性不足，請將價值流中的決策步驟分開，並僅使用 AI 自動化非決策步驟。在某些情況下，可解釋 AI 可能不夠充分，或基於法規考量 (例如 GDPR 第 22 條)，程序可能需要人工介入。在這種情況下，請在單一控制窗格中，呈現真人服務專員決策所需的所有資訊，但自動執行資料收集、擷取、操控和摘要工作。
重新思考架構，因應新商機和需求
運用雲端式功能強化現有架構，可帶來極大價值。如要取得更具變革性的成果，您需要定期採用雲端優先方法，重新思考架構。
建議您參考下列最佳化建議，定期重新思考工作負載的架構，進一步提升效能。
使用雲端式替代方案，取代地端部署 HPC 系統和排程器
如要充分運用更高的彈性、更完善的資安態勢，以及廣泛的監控和管理功能，您可以在雲端執行 HPC 工作負載，或將地端部署工作負載高載至雲端。不過，對於某些數值建模用途，例如模擬投資策略或 XVA 建模，結合 Kubernetes 與 Kueue 可能會是更強大的解決方案。
切換至圖表式程式設計，進行模擬
在 Dataflow 等圖形執行系統中，蒙地卡羅模擬的效能可能更佳。舉例來說，HSBC使用 Dataflow 執行風險計算，速度比先前的方法快 16 倍。
執行雲端式交易所和交易平台
與 Google Cloud 客戶的對話顯示，80/20 帕雷托法則適用於市場和交易應用程式的效能需求。
- 超過 80% 的交易應用程式不需要極低延遲。不過，雲端的彈性、安全性和彈性功能可帶來顯著效益。舉例來說，外匯多交易商平台 BidFX 使用雲端快速推出新產品，並在不增加資源的情況下大幅提高可用性和足跡。
- 其餘應用程式 (不到 20%) 則需要低延遲 (不到一毫秒)、確定性和公平性，才能傳送訊息。傳統上，這些系統會在僵化且昂貴的主機代管機房中運作。不過，這類應用程式也越來越常在雲端重新平台化，無論是在邊緣或做為雲端優先應用程式。
採用與時俱進的技術，滿足目前和未來的業務需求
過去，許多金融服務機構會建構專有技術，以取得競爭優勢。舉例來說，在 2000 年代初期，成功的投資銀行和交易公司都有自己的基礎技術實作，例如發布/訂閱系統和訊息代理程式。隨著開放原始碼技術和雲端的演進，這類技術已成為商品，無法提供額外的業務價值。
請參考下列建議，確保技術與時俱進。
採用資料即服務 (DaaS) 做法，加快上市速度並提高成本透明度
金融服務機構通常會透過自然成長和併購 (M&A) 的方式發展。因此，組織必須整合不同的技術。此外，他們也需要管理重複的資源，例如資料供應商、資料授權和整合點。 Google Cloud 提供機會，在合併後整合中創造差異化價值。
舉例來說，您可以使用 BigQuery 共用等服務，建構可立即分析的資料即服務 (DaaS) 平台。平台可提供市場資料和替代來源的輸入內容。這種做法可避免建構多餘的資料管道，讓您專注於更有價值的工作。此外，合併或收購的公司可以快速有效地合理化合併後的資料授權和基礎架構需求。合併後的企業可以專注於新的業務商機，而不必花費心力調整及合併舊版資料資產和作業。
建立抽象層，隔離現有系統並因應新興商業模式
銀行的競爭優勢越來越不取決於核心銀行系統，而是客戶體驗層。不過，傳統銀行系統通常使用以 Cobol 等語言開發的單體式應用程式，並整合至整個銀行價值鏈。這種整合方式使得價值鏈的各層難以分離，因此幾乎不可能升級和翻新這類系統。
解決這項挑戰的方法之一，是使用隔離層 (例如 API 管理系統) 或暫存層 (例如 Spanner)，複製記錄簿，並透過進階數據分析和 AI 促進服務現代化。舉例來說，德意志銀行使用 Spanner 隔離舊有的核心銀行資產，並展開創新之旅。