第一資本（Capital One）是美國第三大發卡銀行。1994年成立的他們，期盼自己成為一家科技公司，在2012年啟動數字轉型，隔年擁抱敏捷開發、2014年推動IT現代化、2015年投身開源社交媒體、2016年開始上雲，直到2020年關閉最後一個本地數據中心，成為美國金融業全面上雲的先行者。
上雲後的他們，如何確保系統韌性？如何保證每天70億筆的刷卡交易，都能在毫秒內完成欺詐偵測、確認餘額並成功處理？
用公有雲可用區域強化可用性
第一資本信用卡架構副總Kathleen deValk在2023年一場會議中，披露自家的網站可靠性工程（SRE）做法。首先，在人力安排上，第一資本沒有設立一個專門的SRE團隊來維護系統韌性，而是將SRE人力分散在各業務部門一起工作，比如信用卡部，根據事件經驗，改善韌性架構。
第一資本上雲採取了不同的技術架構，最基礎的是公有雲企業AWS標準多可用區域（AZ）架構。這個AZ是指實體地理區域中，相互隔離但以低延遲網路連接的數據中心。由於互相隔離，就算單一AZ故障，也不會影響其他AZ，所以企業常在多個AZ中部署應用程序，來提高可用性，或應對突然暴增的流量。這也是第一資本採用的原因。
他們的多區域基礎架構中，還分為運算層、數據溝通層和永久數據層等3層，每層有各自的服務。比如運算層有Lambda、ECS、Fargate等AWS服務，來執行函數和容器。數據溝通層有Amazon SQS、AWS AppSync等服務，來調度數據處理工作。永久數據層有RDS、DynamoDB、S3等AWS資料庫和存儲服務，來處理數據湖、機器學習（ML）和分析等任務。為確保服務不中斷，第一資本將這3層服務，部署在3個AZ，每個AZ都能執行這3層服務，以便一個故障時，其他AZ可以接手支持。
韌性做法1：多區域故障轉移架構
有了這個基礎，第一資本進一步設置更細緻的韌性機制，其一是多區域故障轉移架構。當負載均衡器偵測到系統故障，能自動將流量轉移到另一個AZ，甚至自動觸發後續功能，例如修復系統、回收執行實例、重新連接資料庫等等。
自建監控儀錶板是這項韌性機制的關鍵，可根據每支應用程序定製的健康指標，來檢測系統健康狀況。這些健康指標，有其相對應的閾值。在系統設計階段，第一資本會通過負載測試、性能測試、擴展測試和邊界測試，來找出可參考的閾值設計。
「但不能止步於此！」Kathleen deValk強調，講求韌性的網站可靠性工程是一個持續學習的過程，所以，第一資本得隨著時間演進不斷優化、微調閾值，才能更快偵測到問題、自動修復。
韌性做法2：AA多區域架構
另一個做法是採用AA多區域架構。有別於多區域故障轉移架構的AP架構、故障切換可能需要幾秒到幾分鐘，AA架構可以近乎即時切換，也更容易水平擴展。也因此，第一資本最常在講求時效的業務場景中，採用AA多區域架構的做法，比如信用卡交易。
在他們的AA架構中，依然用Lambda、ECS和Fargate等服務來執行容器、以S3和DynamoDB處理數據存儲和分析任務。由於信用卡交易涉及多個系統，每個系統的數據複製時間若為1秒，累積起來就很耗時。於是，他們採用DynamoDB的全局表功能，來儘可能縮短時間。
他們還有一項特別的做法：採取120%的過度配置。為什麼要用更高的成本，使用過多的資源，而不是剛剛好就好？
因為，不論何時發生故障，比如節點故障、EC2執行實例故障或AZ脫機，他們都可以通過過度配置，來重新分配工作負載，並分擔工作量，避免影響到顧客服務。「但要記得一件事，在AA架構中過度配置，雲計算成本容易暴增，」Kathleen deValk提醒，何時使用過度配置，還得視第一線業務需求而定。
韌性做法3：區域工作負載分配
不只如此，第一資本還有個區域混合方法，來兼顧韌性和處理速度。試想，人們刷卡的當下，銀行接到交易通知，得要先偵測這筆交易是否為欺詐，通過後再確認賬戶餘額是否足夠。要是不夠，系統可能臨時決定給予額外額度、完成交易。這麼多個事件，都要在幾百毫秒內進行。
因此，系統間的通信速度得快，更需要一致。第一資本發現，要做到這一點，就不能用不同區域的資源，來跳躍處理API調用鏈，因為他們曾測試發現，光用2個區域處理2次API調用，就耗費200毫秒！要是一個調用鏈有10個步驟，累加起來就是很可觀的延遲。
所以，他們規劃用2種技術來分配工作負載，一是採用AWS基於延遲的分配方法，來將負載自動分配到最有效率的區域，另一是在UI觸發API調用鏈後，改由該地的區域來執行，避免中間切換不同區域處理所衍生的延遲。
為做到這一點，第一資本還打造單元架構（Cell-based Architecture），將原本一支支微服務，按端到端流程隔離成一個單元，比如將信用卡驗證微服務、欺詐判斷微服務、授權微服務和處理微服務隔離成一個單元，並限定在同一個AZ執行。只有在故障發生時，才轉移到另一個AZ，來縮短處理延遲。
真實事件的反思：監控系統也要高可用
不過，2021年，第一資本遇到一場讓全公司雞飛狗跳的事件：雲計算DNS網路服務AWS Route 53故障了。第一資本因此發生許多系統錯誤，經過與AWS重重溝通和根本原因分析，從中總結許多寶貴教訓。
第一是監控，「如果看不到正在發生的事，就像盲人一樣，無法做任何反應。」Kathleen deValk點出，他們發現，自家一些監控系統並沒有在多區域執行，因此受Route 53故障影響，這些監控系統故障，看不到系統即時狀況，就算出問題，也難以解決。
第二是無法訪問控制台，導致備用的日誌起不了作用，排除故障也更困難。
第一資本根據這2個教訓，著手改善原本架構。首先是構建關注機制，在日誌系統中，當用戶功能被調用時，插入一個關聯ID，讓這個ID隨著功能處理流程傳遞下去。如此一來，技術團隊就能在故障發生時，找到故障所在之處，還能能更好地分析故障原因、設置更合適的重試和退回方案。
再來，他們也採用真實用戶監控方法，將用戶每個訪問系統的動作，都記錄在日誌。這麼做，第一資本可以看到用戶與系統互動時，系統的即時狀況。綜合這些方法，他們可以打造預測性監控儀錶板，進一步在日誌中尋找事件發生前的預警信號，儘早介入處理。
第一資本通過這些新方法，成功揪出潛在事件，比如偵測到一款應用程序的連接池不斷擴大，於是他們檢查基礎設施、找出問題根源並解決。
這種從事件中吸取教訓、進而回頭改善IT架構設計，正是第一資本追求的「架構 SRE」最佳實踐。
