FSI Meetup 2025 Q4 - 擴展韌性 | AWS FSI Meetup 回顧

場次筆記

USAA 是什麼？

USAA 是一家金融服務公司。
提供銀行、保險、財富管理等領域的多元產品。
將客戶服務視為核心產品。
為 1,400 萬名會員提供服務，主要客群為軍職人員及其家屬。
因應會員的獨特需求，著重於可用性與韌性。

USAA 的雲端旅程

於 2019 年開始部署至雲端，最初部署在 US East 1。
接下來幾年，雲端流量與發展動能逐步增加。
截至 2023 年 6 月，已有數十項部署。
採取「絕不浪費任何一次服務中斷」的思維。
發生服務中斷時並未將工作負載遷回自有環境，而是將其視為提升平台成熟度的機會。
透過將應用程式部署至 US West 2，啟用次要區域。
截至 2024 年，已有數百個應用程式部署至 AWS，另有數十個部署至 US West 2。
將 10 月的服務中斷視為另一次學習與成長的機會。

多區域部署策略

決定採用多區域部署策略。
著重三種容錯移轉模式：備份與還原、引導環境，以及暖待命。
備份與還原至關重要，尤其攸關資料可用性。
若資料無法使用，就無法容錯移轉至次要區域。
必須具備將資料傳送至次要區域的流程，即使這需要從快照復原。
高重要性與關鍵應用程式採用引導環境和暖待命。
目標是改善復原時間目標（RTO）與復原點目標（RPO）。
旨在提升韌性，以及軍職會員的客戶體驗。

應用程式韌性的三個階段：架構設計：

評估每個應用程式並識別相依項目。
瞭解讓應用程式具備韌性所需採取的行動。
考量關鍵路徑中的下游相依項目。
著重即時回應與復原需求。
定義必要的復原時間目標（RTO）。
將 RTO 納入架構設計需求。
為使用案例選擇適當的容錯移轉模式（備份與還原、引導環境、暖待命）。

營運準備：

設定部署所需的組態。
制定操作手冊與監控工具。
確保資源可用，以符合 RTO、復原點目標（RPO）指標及服務水準目標（SLO）。

測試與回饋：

進行韌性測試並規劃服務中斷情境。
從服務中斷中學習，並持續收集回饋。
進行事後分析，確保達成 RTO 和 RPO 的 SLO。
透過持續學習與調整來提升平台成熟度。

流程與工具：集中式韌性：

組織並集中管理韌性標準與架構。
確保整個組織採用一套共同標準。

分散式 DevOps 平台：

建置符合應用程式工程師工作方式的 DevOps 平台。
確保所有開發團隊的一致性。
提供提升 DevOps 成熟度所需的工具與支援。

自動化：

尋找將韌性流程自動化的機會。
實作整合至 SDLC 流程中的自助式藍圖。
提供基礎設施即程式碼範本與快速入門指南。
確保應用程式團隊能快速開始開發，並內建韌性需求。

USAA 韌性流程的具體範例客製化 Well-Architected Review：

從 Well-Architected Framework 開始，並將其套用至所有 USAA 應用程式。
由於公司的架構（集中化、DevOps 平台），發現各應用程式具有一致的元素。
在 Well-Architected Review 之上建置客製化評估標準，以提供更有意義的自動化評分。
識別並突顯各應用程式可自行掌控、用來改善韌性的元件。

左移：

「左移」是軟體開發和 IT 服務管理中的一項策略，意指將測試、安全性及品質保證等關鍵活動移至開發或支援生命週期的較早階段。此方法旨在更早發現並修正問題，從而降低成本、提升品質並加快交付速度。
及早驗證 RTO，以減少應用程式建置過程中的反覆修改並提升韌性。
確保在規劃業務使用案例的解決方案時，對韌性的理解至關重要。

CI/CD 管線中的工具整合：

在 CI/CD 管線中使用 GitLab。
整合 AWS Resilience Hub 與 Resource Groups 以取得洞察。
應用程式團隊會在管線執行期間立即收到評估回饋。
在正式環境實作前，提供以證據為基礎的即時韌性報告。
較低階的環境階段也會提供回饋。

金絲雀部署策略：

逐步將一小部分使用者流量移至新版本，以推出新版軟體。
透過管線自動執行金絲雀部署。
對無伺服器和容器型應用程式特別實用。
使用加權路由逐步推出變更並測試韌性。
在向會員推出變更時，可從變更中學習並瞭解應用程式的韌性。

模式程式庫元件快速入門指南：

讓開發人員快速開始，同時確保 USAA 開發實務的一致性。
包含與韌性相關的非功能性需求。

無伺服器模式：

範例包括非同步 API、搭配 event bridge 的編排模式，以及使用 Step Functions 進行協調的即時 API。
提供無伺服器應用程式的快速入門資源。

容器模式：

使用 Helm charts（在 Kubernetes 中定義、安裝及升級應用程式的套件）作為範本，根據特定需求部署容器型應用程式。

封存資料模式：

將非使用中資料從使用中的系統移至成本較低的長期儲存空間，以改善效能並降低成本；使用內部部署、雲端或混合模式等分層儲存，並實作資料分割等策略以有效率地移動資料。
包含將資料從應用程式 VPC 移至資料 VPC 進行封存的模式。
提供自動化快照，以及從封存資料 VPC 或本機快照進行復原的還原模式。
根據應用程式需求，確保區域內或跨區域的資料移動安全且具備韌性。

選擇準則：

用於根據可靠性、效能、延遲與敏感度，識別最適合使用案例的模式。
有助於確保應用程式的一致性，並選擇最佳韌性架構。

範例：存款應用程式的開戶系統概觀：

USAA 用來開立新存款帳戶（支票、儲蓄）的關鍵系統。
新會員加入流程的一部分。
仰賴下游系統的複雜多服務架構。

實作多區域韌性之前：

評估顯示其災難復原、耐久性與可觀測性的表現不佳。
韌性或可用性不足，無法滿足會員需求。

實作暖待命模式之後：

RTO 從 4 小時縮短至 30 分鐘。
RPO 從 1 小時縮短至 5 分鐘。
在 US East 1 服務中斷期間，能於 30 分鐘內完成容錯移轉，確保會員體驗不受影響。
改善復原與資料處理能力，帶來顯著的業務影響。

架構設計：

平台帳戶負責處理網路流量與路由。
應用程式部署在 US East 1 和 US West 2 VPC（暖待命實作）。
使用 DynamoDB global tables 將資料近乎即時複寫至次要區域。

多區域部署的其他考量等冪性：

關注一筆交易能否重複過帳，而不會造成不利影響。
在銀行業中至關重要，因為金錢交易不得重複。
從區域內韌性的角度加以考量。

重試與交易 ID：

必須管理重試，並在 DynamoDB 中維護交易 ID。
對管理 Step Functions 內的狀態不可或缺。

容錯移轉期間的狀態管理：

在 Step Function 執行期間進行容錯移轉時，維持狀態是一項挑戰。
移至次要區域時，不會保留狀態。
必須在設計中因應此項考量，確保容錯移轉期間的韌性。

架構設計（第一階段）：

納入等冪性和狀態管理等考量。
確保容錯移轉程序在設計時就具備韌性。

營運操作手冊（第二階段）：

說明營運韌性的程序與考量事項。
包含重試、交易 ID 及狀態管理的處理方式。

測試與持續回饋（第三階段）：

從測試和真實情境中的錯誤與差異學習。
處理等冪性、效能降低、冷啟動，以及次要區域快取預熱等問題。

建置韌性系統的關鍵：

在設計中充分理解並納入相關考量。
不僅確保單一區域內的韌性，也確保跨多個區域的韌性。
對向 USAA 會員提供具韌性的服務至關重要。

USAA 的韌性架構與成功因素 100% 的新應用程式皆採用韌性架構：

USAA 的所有新應用程式現在都會經過韌性架構。
重新評估已部署至 AWS 的現有應用程式，確保其符合韌性需求。

轉向保守的多區域策略：

根據所學到的最佳實務，將更多應用程式移至多區域架構。
範例：大幅改善開戶系統的 RTO 和 RPO。

改善韌性與架構審查：

隨著學習與回饋增加，韌性審查和架構審查已變得更快速。
對取捨的理解加快了整個流程。
在近期服務中斷期間，韌性相關事件減少了 66%。

組織實現韌性的成功因素文化：

技術人員、IT 團隊與業務合作夥伴共同承擔責任。
瞭解韌性的意義並定義服務水準目標（SLO）。

架構領導力：

由高階主管支持，並將韌性列為主要目標，提供專項經費。
以會員需求作為使命，推動對韌性的投資。

方法：

從單一應用程式的多區域部署開始，小規模起步。
從初期部署中學習，並透過短回饋迴圈擴展規模。
提升平台成熟度，以及韌性實作的一致性。

工具：

投資自動化與自助服務功能。
在 SDLC 中提供藍圖，以及基礎設施即程式碼（IaC）範本。
確保開發人員能實作韌性實務，無須反覆修改或進行繁瑣工作。
這是達成業務目標並提供優質會員服務的關鍵。

本場分享的重點摘要標準化可加速採用：

使用藍圖和範本降低複雜度。
讓開發人員和業務關係人都能更容易理解韌性。

左移：

在專案構想的更早階段納入韌性考量。
與業務合作夥伴建立夥伴關係，使韌性策略與業務需求保持一致。

持續測試：

測試必須持續並反覆進行。
從服務中斷與韌性測試中學習；不要浪費任何學習機會。
透過持續測試與回饋建立信心。

文化與技術必須共同演進：

在整個組織中採取韌性思維。
運用這種思維影響技術開發。
確保文化與技術相輔相成，以維持長期成功。

FSI Meetup 2025 Q4 - 擴展韌性

回顧系列

場次筆記