在銀行業CIO之間流傳著一個經典的笑話——當你問CIO：「更新老舊的核心系統重要嗎？」他們無一例外地回答：「當然重要！」但當你接著問：「那你打算什麼時候啟動核心系統汰換計畫？」他們多半會笑著說：「等我退休之後。」這個笑話，道盡了汰換銀行核心系統的艱鉅與高風險。
然而，隨著金融市場競爭加劇、監管要求日益嚴格，以及數位金融服務對速度與彈性的需求持續攀升，銀行換核已經刻不容緩。若核心系統仍停留在幾十年前的架構，不僅難以支撐即時支付、數位貨幣、AI 驅動的風控與個人化服務，也會使營運風險增加、維護成本升高，並加劇技術人力的缺口。
細究換核的艱難，若採取「大爆炸式」(Big Bang)汰換，一次性將舊系統全數替換，往往因系統功能龐雜、建置期程過長、專案風險過高及需求變動頻繁，再加上核心系統的特性需要全行大規模人力投入，結果常是專案長期延宕甚至失敗。同時，核心系統承載著帳務、支付、會計與法遵邏輯，一旦有任何疏漏，將對金融穩定造成嚴重衝擊。
因此，我們選擇以「漸進式、模組化」的方式推進，透過微服務與容器化架構，逐步將核心功能解耦、重構。從單一業務場景試點開始，再逐步擴展至跨業務模組，最終建構出「新舊共存、協同運作」的雙核心架構，建立起「大小雙心臟」的重大戰略目標：既能確保穩定與安全，也能加快創新與轉型的步伐。
大心臟指的是IBM zOS主機(Mainframe)，代表了四十餘年來的穩定與可靠，歷經過無數次高併發、高交易量的考驗。小心臟則是以Kubernetes微服務平台為基礎，象徵敏捷、彈性與快速擴展，能承載新業務需求與外部整合。從策略來看，這兩顆心臟不是替代，而是並存協作：大型主機仍負責大多數穩定的帳務核心，而Kubernetes則逐步承擔解耦後的帳務功能，甚至承接新場景與外部串接。大小心臟之間，透過API解耦，互不綁死，互相支撐。這讓我們能同時兼顧「穩定」與「敏捷」，而不是在兩者之間被迫做出取捨。
雙心臟運作架構
圖1、核心微服務應用平台及其與其他系統介接的運行架構
圖1展示了「小心臟」——即核心微服務應用平台的運行架構，以及它如何與本行其他相關系統進行介接。在圖1的左側，我們看到多個與銀行業務息息相關的外部與既有系統：包括端末系統、SWIFT 電文系統、自動化通路（企業網、個人網、行動、語音）、IBM 中心主機、AML（反洗錢）系統，以及各類外部服務（如 LINEBC、推播通知、Mail Server）。這些系統在過去與核心高度耦合，往往以封閉、同步的方式直接串接，造成架構僵化，常常牽一而髮動全身。
而在「小心臟」的設計中，我們以 Ingress Controller 與 API Gateway 作為流量與服務的入口。外部系統的請求經由 Gateway 進入，統一進行路由與控管，確保安全性與一致性。進入平台後，請求會導向不同的服務層：
- Channel Service（通路服務）：負責處理來自不同通路的業務需求，例如端末系統、企網、中心主機或 SWIFT 電文，並將其轉換為內部可識別的標準格式。
- Share Service（共享服務）：涵蓋共用的核心模組，包括認證授權（Auth Management）、交易日誌（AP Journal）、錯誤訊息服務等，為所有業務流程提供支撐。
- Business Service（業務服務）：這是小心臟的核心處理區域，負責依據實際業務需求進行運算與邏輯處理，例如匯入匯款、匯入解款、匯入求償、付款電文解析、對帳、外匯會計、央帳處理，以及 SWIFT 電文管理等。每個服務都具備獨立的資料庫 Schema，強化模組化與自治性。
在這個架構中，我們特別引入防腐層(ACL, Anti-Corruption Layer)服務，它的角色是作為「適配器」，專責處理異質平台的介接。例如中心主機、外部電文、AML 系統，甚至第三方外部服務，都經由防腐層統一轉換與管理。這樣的設計，大幅降低了 Business Service 與外部系統的耦合程度，避免業務邏輯直接依賴外部平台，讓內部微服務可以保持獨立、專注於業務處理。
透過前述規劃，小心臟不僅承擔了解耦後的核心功能，也能與舊核心及外部平台並行運作，達成新舊共存的戰略目標。最重要的是，它建立了一個高度模組化、可彈性擴充的微服務環境，讓銀行在面對新業務需求或外部整合時，不再需要大幅修改核心，而是透過 API 與 ACL 快速完成對接。換句話說，這張圖背後要表達的重點是：小心臟不只是新平台，而是連結大心臟傳統主機、外部通路與創新應用的「橋樑」，它透過 API Gateway、微服務與 ACL 的設計，實現了低耦合、高擴展、可治理的現代化金融核心。
圖2：雙心臟軟體架構
圖2則從軟體架構的角度，展示了「大心臟（IBM 主機）」與「小心臟（微服務平台）」如何分工協作。在右側的大心臟部分，是傳統的 IBM 主機架構。這裡承載著銀行長期以來的業務系統，包括核心的存款、放款、外匯業務系統，甚至許多其他不應在核心系統的各類業務系統，透過應用控制框架運作，底層依靠 CICS、IMSDB、VTAM（VSAM）等主機技術，由 zOS 作業系統支撐。大心臟最大的價值在於經過數十年驗證，能處理龐大的交易量與高併發場景，具備無可取代的穩定性與可靠性，因此至今仍是銀行最核心的交易處理平台。
在左側的小心臟部分，則是新一代的微服務平台。它建立在 VCF（VMware Cloud Foundation） 提供的基礎資源池之上，並以 Tanzu 作為容器化與編排引擎，提供 Kubernetes 平台與自動化管理能力。在此基礎上，再加上本行自行設計開發的微服務應用控制框架層，用來治理與協調微服務的運作。這一層涵蓋了共用系統服務（例如認證、日誌、交易追蹤）、以及 ACL（防腐層），專責處理新舊系統之間的整合與協定轉換，避免微服務被主機的舊有技術耦合。最上層則是業務應用系統，透過多個微服務組合而成，每個服務可獨立部署與演進，避免傳統系統中「一改就牽一髮動全身」的困境。
圖中間的雙向箭頭，象徵新舊核心之間的資料與流程交換。大心臟繼續承擔最穩定、最核心的帳務交易處理；小心臟則負責新開發的功能，或逐步拆解出來的核心模組，並透過 API 與 ACL 進行資料互通。這樣的設計，既能保持兩邊的解耦，又能確保協同運作，實現「穩定」與「敏捷」的並行不悖。
整體而言，這張「雙心臟」架構圖所表達的是：銀行核心不再單靠一個平台，而是透過大心臟 IBM 主機來保障穩定與可靠，再透過小心臟微服務平台來實現敏捷與創新。兩者並存協作，既能確保既有業務不中斷，又能加速數位轉型的落地。
但採用「新舊共存、協同運作」的雙核心架構與戰略目標並非不用付出代價，更非只要喊出口號就能輕鬆落地。首先我們必須正面迎擊的是四大技術難題：
- 跨系統一致性：新舊系統並行時，交易資料與帳務狀態必須在新舊兩個核心系統間保持一致。這涉及即時同步機制、衝突解決策略及完整的驗證框架，否則將帶來帳務錯誤甚至合規風險。
- 同步與非同步優化：部分交易需要毫秒級同步處理（如支付、清算），而其他場景則可採非同步批次以降低耦合。我們必須精準劃分邏輯，並導入事件驅動（Event-Driven）與流式處理（Streaming），兼顧速度與韌性。
- 兩地雙活與金融韌性：新核心不僅要具備傳統的備援與災難復原能力，更應該善用雲端與分散式架構，實現真正的「兩地雙活」。這不只是確保在區域性故障或極端事件下，交易服務能無縫持續；更重要的是，在平時營運中，主備中心能共同分擔交易負載，達到資源最佳化利用，全面提升金融基礎設施的韌性與效率。
- 反向工程挑戰：大量帳務邏輯與資料結構深埋於主機的 VSAM/DLI 與 COBOL 程式中，且經過數十年演進，存在同欄不同義、編碼差異、文件缺失等問題。要將其安全轉換為微服務架構，必須透過工具掃描＋人工複核、跨團隊協作，逐步拆解並重構，才能避免牽一髮而動全身。
跨系統一致性
不論系統多複雜，金融核心交易的正確性是底線。當帳務交易跨越新舊核心與多個微服務時，任何一個環節出錯都可能造成帳務不平衡。為了維持跨系統的一致性，我們導入 SAGA Pattern 搭配事件驅動架構，讓交易可以拆解為可補償的步驟，一旦發生異常，系統能自動觸發補償機制進行復原。如果錯誤發生在微服務之間，SAGA 可以直接執行補償流程；若錯誤來自跨平台與主機回應異常，則透過 SAGA + Batch Listening 進行監測與確認，再依序復原已寫入的資料。透過這樣的設計，不論交易橫跨多少服務或異質系統，都能保持資料正確性。這使得系統不僅能確保一致性與可靠性，也為未來的擴充與調整奠定穩固基礎。
圖3、跨系統交易如何透過 SAGA Pattern 與補償機制來維持帳務的一致性
圖2展示了在新舊核心並行的情境下，跨系統交易如何透過 SAGA Pattern 與補償機制來維持帳務的一致性。在左半部的案例中，交易流程從 MicroService A 開始，負責解析國外銀行電文，接著由 MicroService B 將內容寫入，再傳遞給 COBOL主機寫入帳務資訊。在一切正常的情況下，交易可以順利完成。然而，如果在 COBOL 主機寫入帳務的過程中發生失敗，主機會拋出錯誤訊息。此時系統就會啟動補償機制，由 MicroService B 將剛剛寫入的內容還原。這樣一來，即使最後一環出現問題，也能確保資料不會失衡，維持帳務正確性。
右半部則描述另一種情境：當 COBOL 主機沒有回應時，交易狀態變得不確定。這種情況下，系統會先透過 Batch Listening 的方式，不斷向 COBOL 主機重新查詢，以確認交易結果。如果最終確認 COBOL 主機的交易確實失敗，系統就會再次啟動 SAGA Pattern，讓 MicroService B 依序執行補償，把已經寫入的資料復原。透過這樣的設計，即便跨越異質平台，也能避免因交易結果不明而導致的系統不一致。
整體而言，這張圖所要傳達的核心概念是：在金融核心中，交易正確性是不可妥協的底線。透過 SAGA Pattern 將交易拆分成一連串可補償的步驟，並結合事件驅動架構，自動觸發補償流程，即使交易過程中有失敗或無回應，也能即時修正，避免帳務出錯。而在異質平台的情境下，再輔以 Batch Listening 的監測機制，則進一步確保了跨平台交易的一致性。這樣的架構讓銀行能在複雜的微服務與主機並存環境中，既能維持資料正確性，也為未來系統的擴充和調整奠定穩固基礎。
同步與非同步優化
由於原核心系統龐大且複雜，我們在推動轉型時，採取逐業務系統析離的方式進行重建。然而，帳務交易往往涉及多個系統的連動與串接。在過去的大核心架構中，所有系統都集中於同一平台，彼此高度耦合，交易執行時普遍採取同步機制。也就是說，使用者在執行交易時，必須等待所有相關系統的回應，才能完成一筆交易。
在專案執行過程中，我們檢視了原有的作業流程，發現其中部分程序並不需要強制同步，有些同步機制甚至在微服務架構下，成為大量交易並行處理的瓶頸。於是，我們與業務單位共同重新梳理交易流程，將交易重新劃分為「必須即時回應」的同步處理，以及「可以延遲執行」的非同步處理。
圖4. 以「同步 + 非同步並存」的模式處理國外匯入匯款進電作業
以國外匯入匯款進電作業為例，在傳統架構下，若遇到長假（如農曆新年），大量國際電文同時湧入，整個串接流程就會面臨龐大壓力。為解決此問題，我們利用國際標準電文（如 SWIFT MT103、MT192）的分類特性，將訊息依類型放入不同的 Queue，再由後端服務分批處理，分散負載。同時，對於需要整批處理的交易，作業單位也能先將訊息放入 Queue，再依序處理，避免單點壓力。透過這樣的調整，我們成功將原本「全同步」的架構，轉換為「同步 + 非同步並存」的模式。這不僅解決了高併發下的效能崩潰問題，也讓系統更具彈性與可擴展性。
兩地雙活與金融韌性
在新核心系統設計之初，我們即意識到：既然新核心系統建立在容器化與雲原生的平台之上，就必須充分發揮雲端與容器的可攜性與彈性，進而實現真正的「兩地雙活」。圖 5 所呈現的，正是核心微服務應用平台在規劃階段如何以「雙中心架構」為核心目標，確保金融交易具備高可用性與業務連續性，讓系統能在各種情境下維持穩定與可靠的服務。
圖5、提高金融韌性的新核心系統兩地雙活運作架構
整體架構分為 台北資料中心 與 中壢資料中心 兩個據點，形成雙活部署。分行作業人員使用的端末系統，依據地理區域（台中以北、台中以南）各自連線至最近的核心微服務平台，以降低延遲並提升交易效率。同時，行動銀行、網路銀行及SWIFT系統則可以依照運行需求，透過負載平衡器（AVI LB）進行即時分流，並能根據流量狀況動態調整比例。這樣的設計落實了雙中心的分流機制，不僅能支撐業務成長，也能確保在任一中心發生異常時，系統可自動快速、無縫切換至另一中心繼續運行，維持交易不中斷。
在平台內部，每個據點皆建置 Kubernetes Cluster，並配置本地磁碟（K8s Local Disk）、日誌檔（Log Files）、映像檔倉庫（Harbor Registry）等基礎資源。管理工具如 K8s 管理工作站、ELK 監控平台、VCF 管理工具則分散配置於兩中心，確保管理與監控不因單一據點故障而失效。
在資料儲存層，兩中心各自有獨立的儲存陣列，並透過 VPLEX 技術進行即時同步（VPLEX Sync）。每一筆交易的處理，必須在資料於兩中心完成更新後，才算結束。這代表系統在本地會保有雙份資料，並在異地再保留一份備援副本。這種「同地雙份 + 異地一份」的設計，確保了資料的一致性與完整性，同時也大幅提升了系統的可靠性。
透過這樣的雙活架構，核心微服務平台能夠實現即時分流與無縫切換，確保在任何故障情境下，金融交易仍能不中斷運作。同時，藉由高效能的資料存取與同步機制，系統能夠支撐不斷成長的交易量與業務需求，為銀行業務創新與營運韌性奠定堅實基礎。
逆向工程挑戰
在銀行核心系統的轉型過程中，反向工程是一項無可迴避的挑戰。特別是在既有 IBM 主機環境中，系統經歷了數十年的演進，許多設計來自於早期資源有限的時代，雖然有效支撐了龐大交易量，但同時也埋下了轉換過程的複雜性。這些挑戰主要體現在兩個層面：資料結構的轉換與程式語言的解讀。
首先，資料結構的轉換是一大難關。在主機環境中，資料通常以 VSAM 檔案或 IMS-DLI 資料庫的形式存在，其特徵是固定長度、壓縮存放以及對資源的極端節省。為了達到效能，早期系統設計常出現「同欄不同義」的情況，也就是同一個欄位在不同交易中具有不同意義與型別。例如 COST_RATE 這個欄位，在不同程式中可能對應到不同的長度、精度或語意。這樣的設計雖在當時能有效利用有限資源，但在轉換為現代化微服務架構時卻形成極高風險。再加上主機使用的 EBCDIC 編碼與開放系統普遍採用的 Unicode/UTF-8 並不相容，轉換過程中極易出現亂碼或長度錯誤。這意味著資料不能僅僅「搬移」，而必須經過重新定義與嚴格比對。對此，我們採取的策略是工具掃描配合人工複核，由新舊系統團隊共同解讀欄位語意，並建立統一的轉碼與精度規則，確保在精細拆解的過程中不會引發連鎖錯誤。
圖6. COBOL程式逆向工程
其次，程式語言的解讀同樣困難重重。本行核心帳務系統中，許多 COBOL 程式已有三、四十年的歷史，相關文件並不完整，甚至能完整掌握程式邏輯的人員也已退休。資訊人員對這些程式的熟悉程度往往無法百分之百，這使得我們不得不採取「考古式」的方法，直接從程式碼出發進行反向解讀。這個過程就像拼圖：必須先透過工具解析 COBOL 與 JCL 的流程，再由技術團隊建立初版的程式邏輯，隨後與業務單位反覆討論，將技術語言翻譯成業務能理解的流程。若在驗證過程中出現落差，就需回到程式碼中尋找更多線索，逐步修正，直到業務邏輯被完整還原。最終，這些被確認過的邏輯會整理成「故事（Story）」的形式，成為 API 化與微服務化的設計基礎。雖然這樣的工作既耗時又耗力，但卻是唯一能真正打開「黑盒子」並安全承接既有核心邏輯的方法。
綜上所述，逆向工程的挑戰不僅是技術層面的轉換，更是一場跨世代的知識重構。它要求新舊系統團隊密切協作，兼顧工具自動化與人工驗證，並透過「切片（Thin Slice）」的方法降低風險，逐步完成從主機到微服務的轉換。換言之，這不僅是單純的系統遷移，而是一次從「黑盒子」走向「透明 Schema」、從「巨石程式」走向「模組化微服務」的深層次重建。
前面我們談到，為了實現「新舊共存、協同運作」的雙核心架構與戰略目標，必須正面迎擊四大技術挑戰——跨系統一致性、同步與非同步的優化、兩地雙活與金融韌性，以及反向工程的艱鉅任務。然而，銀行換核並不僅止於技術難題，它更是一場牽動組織結構、流程治理與文化轉型的長期工程。換句話說，光有技術解法並不足夠，真正的難點在於如何讓這些方案能被團隊持續應用、內化為日常習慣，並最終沉澱為組織文化。
從技術破題到團隊學習
因此，從這裡開始，我們將進入第二部分——「從技術破題到團隊學習」。這一部分要談的，是如何從單點解決方案，逐步提升為全方位的落地能力。
我們將聚焦於六個面向：如何克服技術學習曲線（以 OOMKill 為例）、如何把安全前移（DevSecOps Shift-left）、如何升級可觀測性以及早發現風險、如何透過協作與規範降低溝通摩擦、如何建立完整的測試案例以確保品質，以及最後如何設計 API 過渡策略，讓新舊系統能在長期並行的過程中實現平穩過渡。
OOMKill 與 JVM 記憶體管理：從踩坑到組織學習
在銀行核心系統導入雲原生架構的過程中，我們遭遇過最具挑戰性的問題之一是 OOMKill（Out Of Memory Kill）。這是 Kubernetes 或 Linux 系統在偵測到某個容器的記憶體使用量超過限制時，為了保護整體環境而強制終止該容器的機制。當這樣的情況發生時，應用會不斷重啟，造成服務不穩定，使用者體驗也隨之下降。
難題在於，OOMKill 的發生時間往往無法預期，因此錯誤情境常常難以重現並加以確認。其根本原因在於程式在不同情境下的記憶體使用模式差異極大：例如，報表查詢、批次運算或突發流量，都可能在瞬間將記憶體推至臨界點。此外，Java 應用特有的垃圾回收（GC）機制、物件生命週期管理，以及潛在的記憶體洩漏問題，更進一步增加了不確定性。表面上 Pod 或許因 RestartPolicy 而自動重啟，看似恢復正常，然而背後的風險卻依然潛伏，隨時可能再次觸發同樣的問題。
為了真正解決問題，我們展開了三方面的努力。首先，在技術層面上，我們透過 JVM 記憶體分析與 Grafana 監控，精準掌握 Heap（堆區）與 Non-Heap（非堆區）的使用狀況。這裡的區分非常關鍵：Heap 是物件配置的主要空間，而 Non-Heap 則包含 Metaspace、Code Cache、執行緒與垃圾回收預留區。以某次實際分析為例，系統共預留了約 2.8GB 的 Heap 空間，但實際使用僅約 778MB，顯示仍有相當餘裕。透過這類觀測，我們能夠及早發現不合理的資源消耗，並據此調整 Kubernetes 中的 Request 與 Limit 配置。
其次，在組織層面，我們建立了「種子團隊」。這群曾經親身踩過坑的同仁，將處理 OOMKill 的經驗轉化為教材與最佳實務，再傳遞給更多開發與維運人員。如此一來，錯誤不再只是一次性的修正，而是被轉化為集體知識，進而擴散成文化。最後，在持續優化上，我們引入了預警與自動化控制。例如設定當記憶體使用率持續超過 80% 時即發出告警，或定期檢視 OOMKilled 的次數，確保問題能在惡化前被捕捉。這些措施讓團隊能夠更快迴應，避免服務中斷。
綜合來看，這段經歷讓我們意識到，雲原生轉型不是單純把系統搬上 Kubernetes，而是一條完整的路徑，涵蓋基礎設計、部署實作、效能監控與調校、以及組織學習與知識擴散。唯有把事件管理上升為制度化能力，才能真正支撐銀行在高壓環境下的穩定營運。
DevSecOps Shift-left：讓安全成為開發流程的內建特徵
在傳統的軟體開發流程中，安全檢查往往被放在最後一哩路——等到系統快要上線時，才進行一次性的大規模測試與掃描。然而，這種做法不僅成本高昂，更容易造成「救火式」的補救，往往一個漏洞的修復，會牽動大量程式碼的返工。
圖7. 自動化 Pipeline + 安全左移，程式碼一寫就檢查，確保品質與資安
我們在導入雲原生架構與 CI/CD 流程的同時，全面引入了 DevSecOps 的 Shift-left 思維，也就是把「安全」從流程的最後移到最前（如圖7所示）。當開發人員一推送（Push）程式碼，就會自動觸發以下管線：
- 建置與品質檢查：程式碼被自動建置為容器映像檔，同時啟動程式碼品質掃描（如 SonarQube），檢查是否存在不良寫法、潛在 Bug、測試覆蓋率不足或重複程式碼過多等問題。舉例來說，某次掃描結果顯示程式碼覆蓋率達 82.7%，重複率僅 1.0%，同時在安全性、可靠性與可維護性指標上都獲得了最高等級，這讓團隊能放心地將程式推進下一階段（如圖8所示）。
- 容器映像檔掃描：我們進一步針對容器映像檔進行漏洞檢測，檢查其中所使用的套件或依賴是否包含已知的 CVE（Common Vulnerabilities and Exposures）。例如，掃描結果標示出一個 Critical 等級漏洞與一個 High 等級漏洞，代表若不及早處理，未來可能演變成資安事件（如圖8所示）。
- 自動測試與部署：在完成掃描後，系統會自動執行單元測試，並將程式部署到 Dev → SIT → UAT 等不同環境。整個過程透過 Jenkins 與 Pipeline 管理，並在進入 UAT 前設有人為審核（Approve）機制，以兼顧自動化與合規要求。
圖8. 開發階段即掃描程式碼與映像檔，提早發現風險
在這樣的流程設計中，最大的價值在於風險的處理被大幅提前。過去常見的狀況是，系統在接近上線階段才被進行安全檢查，一旦發現漏洞，往往需要大規模返工，既耗時又昂貴。如今透過 Shift-left，程式碼品質與套件漏洞問題能在開發初期就被揭露並修正，讓後續流程不再背負沉重的技術債。這種早期介入的方式，不僅縮短了修復週期，更降低了潛在錯誤在生產環境中擴大的風險。
另一方面，自動化與標準化的引入也使開發流程更加穩健。每一次 Commit 都會觸發相同的建置、掃描與測試程序，開發團隊無需再依賴人工檢查，版本標籤（Tag Release）則讓每個部署都有清晰可追溯的紀錄。這樣的自動化不僅避免了人為疏漏，也讓部署與測試結果更具一致性與可重現性。
最重要的是，這樣的實踐代表了一種文化轉變。安全不再是附加於流程最後的檢查點，而是從一開始就被內建在每一個環節之中。換句話說，安全與品質已經從「部門責任」轉變為「流程特徵」，成為開發人員日常作業自然的一部分。這不僅提升了系統的可靠性，也逐步培養出一種新的組織習慣：任何人、任何一次程式碼提交，都必須帶著安全與品質的意識。
總結來說，DevSecOps Shift-left 並不是單純的工具導入，而是一種文化轉型：安全與品質不再是專屬「資安部門」的責任，而是每一位開發人員、每一次 Commit 就自然具備的流程特徵。這正是我們在核心系統現代化過程中，從「技術破題」走向「文化落地」的重要一步。
可觀測性升級：從監控到營運韌性
在核心系統轉型過程中，單純的監控早已不足以支撐銀行對於穩定性與可靠性的要求。我們需要的不只是「看得到數據」，而是能在問題發生時，即刻追蹤到根源、分派給對的人，並快速完成修復。這正是我們推動「可觀測性升級」的核心理念——從傳統的監控（Monitoring），走向真正的可觀測性（ Observability）。
圖9. ELK Dashboard：幾秒找到關鍵交易 Log，用 traceId 串出完整呼叫鏈，快速定位問題
首先，在交易與事件的排錯效率上，我們導入了 ELK Dashboard。過去當使用者回報交易失敗，往往需要維運人員登入主機，手動翻查龐大的 log 檔案，一個個 grep 才能拼湊出問題的脈絡。現在透過 ELK，只要輸入交易代號或 traceId，便能在幾秒鐘內定位到完整的交易呼叫鏈，包含是哪一個服務處理、對應的 traceId、txid，以及相關的上下文資訊（如圖9）。這讓開發人員與平台團隊能立即判斷問題究竟出在哪一個節點，避免責任模糊，並且為資安稽核或歷史追查提供了清晰的資料來源。換句話說，我們要的不是「找到 log」，而是「快速找到對的 log」，而 ELK 幫我們做到了這一點，讓排錯變得精準且具規模化。
圖10. Grafana：即時觀察叢集資源、Pod 狀態與 API 成功/失敗率
其次，在即時運維監控方面，我們整合了 Grafana 與 Prometheus，打造了一套分層、分級、分流的監控體系。Grafana Dashboard 能清楚呈現整體叢集的資源使用情況，例如記憶體使用率 21%、CPU 使用率 0.38%，讓管理員能快速掌握系統是否有過載或閒置問題（如圖10）。
圖11. Grafana Pod Dashboard：追蹤單一 Pod 資源使用與存活時間，精準定位異常
次外，Pod 的狀態也一目了然，Running 數量、Failed 或 Pending 的異常都會即時顯示，而 CPU 與 RAM 使用曲線則幫助我們觀察波動，判斷是否需要擴容或調整限制（如圖11）。每個微服務的實例數量也能即時呈現，確保系統在高併發下仍能維持高可用性。同時，HTTP 請求的回應分布，讓我們能在第一時間注意到異常，例如 5xx 錯誤是否集中爆發。
圖12. 「Prometheus + Alert Manager：分層告警、精準通知，確保營運不中斷
更進一步，我們為這些監控數據設計了門檻告警機制：當資源或交易異常超過設定值，Prometheus 的告警就會觸發，並透過 Email 或即時通訊工具，精準地通知到對應人員（如圖12）。如果是平台層問題，會直接推送給平台管理團隊；如果是應用層問題，則通知到應用開發人員；重大事件則會在 NOC 中控室大螢幕上即時顯示，確保 24 小時都有人能第一時間採取行動。
圖13. 語意化 TAG：多環境一致性，可追溯、可管理、可追蹤
最後，我們也導入了語意化 TAG 機制，確保多環境部署的一致性與可追溯性。每一個映像檔除了唯一的 Digest（sha256 雜湊值）之外，還會被賦予語意化的標籤，例如「2025H2003-220401150-16.9.20-SNAPSHOT-01」（如圖13）。這個標籤不僅能對應到變更單號，還能追溯所使用的 Base Image 版本與框架版本，確保 DEV、SIT、UAT、PROD 使用的都是同一份映像。這樣的設計，使得問題發生時，我們能精準追查是哪個版本引入風險，同時確保環境一致性。
透過 ELK、Grafana、Prometheus 與語意化 TAG，我們不只是把監控強化，而是把營運韌性制度化，讓系統能夠「快速發現、正確分流、即時修復」。這不僅僅是工具的導入，而是銀行營運模式的質變：從被動反應轉向主動掌握，從黑盒子走向透明化。對金融核心而言，這樣的可觀測性升級，就是保障業務連續性與客戶信任的基礎。
協作與規範：打造大型組織的共同語言
在新核心系統的落地過程中，我們很快就發現，真正的挑戰並不單純在於程式碼本身，而是在於「人與人的協作」。大型組織的複雜度，往往來自跨部門之間如何協同、如何在同一套規範下運作。為了讓新核心能長期穩健發展，我們建立了三個協作與規範的支柱。
圖14. 以 FCBFramework 統一控管第三方套件版本，集中驗證與維護，確保安全與一致性
首先，是 第三方套件的控管。在當前的開發環境裡，第三方套件已經成為不可或缺的一環，但同時也帶來資安風險與維運挑戰。如果讓每個應用系統各自決定要用什麼套件、用哪個版本，那麼漏洞控管與維護成本將會失控。因此，我們設計出一個統一的開發框架（FCBFramework），由框架來統一引用並驗證第三方套件（如圖14所示）。當套件需要更新或替換時，僅需在框架層進行調整，所有應用系統便能同步受惠，不會產生版本不一致或資安風險擴散的問題。這樣的設計，既確保了安全性，也讓維運工作更加高效。
圖15. 核心批次作業透過 Open Control 管理，支援並行、重跑與跳過，提升夜間批次的彈性與韌性
其次，是 批次作業的優化。銀行的夜間批次作業是最敏感、最複雜的部分之一，涉及過帳、申報、報表生成等核心流程。過去，這些作業往往以嚴格的序列方式進行，一旦某個環節出現異常，就可能拖延整體流程。我們導入 Open Control 排程系統，將批次作業設計為可並行、可重跑、可跳過的模式。當發生異常時，系統能根據規劃自動判斷該程序是否可暫時略過，或是否必須立即重跑，甚至與舊核心批次進行同步等待（如圖15）。這大幅提升了批次處理的靈活性與韌性，也確保了新舊核心在夜間批次的協同能夠平順運作。
最後，是 統一規範的制定。我們深知，當團隊龐大、系統複雜時，如果沒有共同的語言與原則，就容易陷入溝通不良、品質不穩的困境。為此，我們制定了 13 大規範文件，涵蓋 API 設計、命名原則、錯誤處理、Log 標準、程式碼品質規範等，包括：
- 本機環境建置說明_應用服務開發
- 本機環境建置說明_Framework 開發
- Framework 使用說明文件
- Java Coding Guideline 文件
- 錯誤控制說明文件
- AP Log 說明文件
- OAS 撰寫說明文件
- 核心 API 設計規範文件
- 通路 API 設計規範文件
- JavaDoc 規範文件
- 程式碼品質規範文件
- Package 命名規範文件
- 入門培訓程式需求文件
這些文件不僅是技術規範，更是團隊之間協作的基礎，確保不同部門、不同開發人員在同一套標準下工作。換句話說，這些規範讓我們能在一個複雜的微服務框架中，維持一致性與可預測性。
透過這三大支柱，我們不只是建立了一個技術平台，更是為組織建立了一套協作文化。從套件控管到批次優化，再到規範統一，我們讓開發、測試、維運都能在同一條軌道上協作，降低摩擦、提升效率。這也是為什麼我們常說：大型組織真正的挑戰，不在於程式碼，而在於如何讓人與人之間「說同一種語言」，並且持續朝著共同的目標前進。
測試案例完整性：從程式驗證到業務共責
在核心帳務系統的轉型專案中，測試案例的完整性是一項不可妥協的關鍵。測試不應僅止於驗證程式碼正確與否，更必須涵蓋人工操作、前端流程與外部系統介接。因為實務上，許多作業仍需仰賴人工判斷、審核，甚至與其他系統交換資料，若未能將這些環節納入測試，將難以確保整體流程的真實可靠。
圖16. 資訊與業務協同的整合測試流程
因此，我們建立了一套完整的測試流程：首先由業務單位挑選具代表性的測試案例，接著由資訊單位與業務單位共同確認，確保涵蓋所有作業情境。環境準備需在三個工作天內完成，隨後進行測試、產出報告，並經雙方共同簽核（如圖16所示）。這樣的安排，讓測試不再是資訊部門的單向工作，而是資訊與業務的共同責任，真正做到跨單位協作。
在此過程中，我們特別強調測試案例的設計需從業務流程出發，而非僅依靠程式碼推導，因為後者往往會忽略手動流程的風險。更進一步，測試結果不僅止於「跑通」程式，而是需與帳務結果、申報資料、防制洗錢檢核等進行比對，確保業務與法遵正確性。每一次測試的結果都會被完整留存，並由資訊與業務人員共同檢視，避免偏差或遺漏。這種完整性測試的價值在於，它讓轉型過程不只是「系統能跑」，而是「流程正確、帳務無誤、結果可被信任」。對金融機構而言，唯有如此，才算是真正的轉型。
API 過渡策略：務實轉型，循序漸進
在核心轉型的過程中，所有人都希望未來的系統能全面採用現代化的 Restful API 串接，這代表標準化、開放性與更高的維運效率。然而，理想與現實之間往往存在一道鴻溝。許多周邊系統，例如語音服務或企業網銀，建置時間已久，依賴的仍是電文傳輸方式，並不具備 API 呼叫能力。如果強行要求全面升級，不僅需要投入龐大的人力與資源成本，還會讓周邊系統的維運團隊背負沉重壓力，進而提高營運風險。
圖17. API 過渡策略：短期 ESB MQ、 中期 Queue 串接、長期全面 Restful API 化
因此，我們設計了一套務實的過渡策略。短期內，仍然讓舊系統透過 MQ（訊息佇列）傳遞電文，再由 ESB 系統進行轉換並呼叫核心 API。中期的調整方向，則是針對已具備能力的個人網銀與行動系統，讓它們直接透過 Queue 串接核心微服務平台。長遠而言，隨著周邊系統逐步升級，最終目標仍是全面 API 化，讓所有系統都能以統一、現代化的方式進行互通（如圖17所示）。
在這樣的設計下，我們特別將防腐層獨立建置，確保不論是從 ESB、Queue，還是 Restful API 進入，服務都能無痛切換而不影響應用平台。換言之，過渡策略的價值不僅在於「解決眼前的難題」，更在於「保留未來的彈性」。
從技術落地到業務價值的映射
在轉型的前半段，我們已經談到自動化、可觀測性、規範建立與測試完整性，這些努力確保了轉型能「跑得起來」，而且能持續規模化。但這一切若僅止於 IT 領域，仍不足以支撐整體價值的落地。真正的挑戰在於：這些技術性突破，能否進一步映射到業務價值，創造出組織真正的競爭優勢？因此，在 Part 3，我們把焦點收束到「從技術到業務價值的映射」。
從技術落地到業務共創：以價值流驅動轉型
首先，我們與業務單位共同投入，針對既有運行了三、四十年的複雜流程進行全面梳理。這些流程過去高度耦合、彼此依賴，為了因應微服務的全新架構，我們必須去蕪存菁，重構出新的業務行為與系統設計藍圖。
在這個過程中，我們強調「平衡」——不是一味追求效率極大化，而是讓創新與穩定並存。業務人員的參與不僅提供了操作經驗，更幫助我們將流程設計與實際使用體驗結合。這讓轉型成果不只是技術的進步，而是能在使用者操作上實際感受到便捷與體驗提升。
圖18. 六大業務流程與 27 條價值序列的共創規劃，並展開為具體測試排程
具體而言，我們與業務單位共創並規劃出六大業務流程，涵蓋二十七條價值序列，這些價值流成為後續系統功能設計、API 開發以及測試案例制定的重要依據。這種「由業務驅動技術」的方式，讓轉型真正回歸本質：不只是改善 IT 效率，而是持續創造可感知的業務價值。
外部限制下的流程優化：以AML為例
在大型金融系統中，外部協作系統往往成為使用者體驗的瓶頸。以防制洗錢（AML）系統為例，過去每一次查詢都需要等待約 90 秒才能得到回應。這段乾等時間不僅拖慢了作業效率，也大幅影響使用者體驗，更讓整體業務流程顯得僵化。
圖19. AML 流程三層優化：離峰自動掃描、尖峰兩段式回覆與查詢結果復用
在新核心微服務應用平台的設計中，我們針對 AML 的掃描流程進行了優化，採取三層式的調整策略。第一，將多數需要即時掃描的請求透過事件（Event）機制移至離峰時段，由系統自動提前完成，讓使用者實際操作時，能省下約 80% 的即時等待時間。第二，在尖峰時段導入兩段式的處理機制：當使用者發出掃描需求時，系統先立即回覆「已接收」，使用者可以繼續其他操作，之後再回傳 AML 結果。這樣的設計有效縮短了約三成的畫面等待時間。第三，針對查詢流程進行優化，避免重複掃描。如果 AML 系統正在處理相同的請求，平台會直接回傳現有結果，而不是重新啟動掃描，進一步減少了 50% 的重複負荷。
透過這些優化措施，不僅顯著改善了使用者體驗，也降低了 AML 系統的壓力，讓外部限制不再是轉型的絆腳石。這一案例說明了在轉型過程中，即便存在外部條件約束，仍能透過創新的流程設計與技術手段，找到兼顧效率與穩定的解法。
國外匯入匯款應用優化：從技術到具體業務價值的落地
轉型不僅止於技術升級，更必須能為業務創造具體價值。以「國外匯入匯款」為例，新核心平台的導入不僅改善了系統效能，還透過自動化與流程重塑，實際節省了龐大的人力成本，並提升了員工的操作體驗與合規性。
圖20. 國外匯入匯款應用優化：四大措施共節省 43.9 人力/年，提升效率、體驗與合規
首先，自動對帳功能取代了以往人工比對的繁瑣作業，僅此一項就能每年節省約 2.6 人力。其次，AML 預掃機制讓大部分的匯入交易能在背景自動完成掃描，避免使用者反覆等待與重查，節省 12 人力。再者，模組化解款功能讓解款案件得以套用自動化規則，降低操作複雜度，每年約可減少 16 人力。最後，透過流程重塑，系統不僅能完整記錄案件生命歷程，更能自動產製報表，讓外匯人員能一站式完成查詢與作業，進一步節省 13.3 人力。
合計下來，這些優化措施每年可節省 43.9 人力。不僅是數字上的減少，更重要的是 AML 掃描變得更快更準，員工體驗明顯改善，合規要求也被內建到系統之中，形成一個可持續進化的自動化營運模式。這些努力凸顯了轉型的真正價值：技術進步必須回饋到業務，才能真正支持銀行持續成長與風險管理。
結論與未來挑戰：從雙心臟到持續進化
回顧這段核心系統轉型的歷程，我們從「單心臟」走向「雙心臟」，不再只能在穩定與敏捷之間二選一，而是建立了能同時兼顧傳統主機的可靠與雲原生微服務的彈性的新架構。這個過程不只是技術升級，更是一場涵蓋流程治理與文化轉型的長期工程。我們從技術破題出發，逐步形成組織可持續學習的能力，並將成果映射到具體的業務價值，讓自動化、可觀測性與規範成為制度化的日常。最終，技術努力轉化為員工體驗的改善、合規性的強化與營運韌性的提升。
然而，這段旅程仍未結束。真正的挑戰在於如何持續進化，並在下一輪迭代中，突破尚未完全解決的瓶頸。這些挑戰不是阻力，而是驅動我們前進的動能：
第一，AI 輔助 COBOL 逆向。
本案中，大量 COBOL 與 JCL 程式邏輯需要透過人工進行逆向與解讀，投入了龐大的人力成本。未來，我們計畫引入 AI 工具來自動分析與萃取業務邏輯，減輕新進人員學習 COBOL 的負擔，加速將巨石程式拆解成可治理的微服務模組。
第二，文件一致化。
專案過程中，不同團隊在撰寫規格文件時仍存在風格差異與錯誤，雖然已經制定規範，但落實度仍有待提升。未來，我們需要更簡化且自動化的規格管理機制，確保文件能真正成為跨團隊協作的共同語言，而不是新的摩擦來源。
第三，跨系統版本控管。
在新舊核心並行的環境中，版本相依性帶來極大挑戰。一旦某個服務或模組升級，可能牽動其他系統的穩定性。如何在多系統、多版本的並存狀態下，建立精準的版本治理與回溯機制，是未來必須正面迎擊的課題。
承接這些挑戰，我們回到轉型的最核心價值：雙心臟架構讓我們同時擁有穩定與敏捷，技術、流程與文化的三重迭代讓我們累積出可複製的 know-how，而這些技術努力最終都必須回饋到業務與客戶價值上。我們不是只在建一套新系統，而是在升級流程、改善體驗、提升韌性。這正是我們的轉型故事，也是我們迎向未來的信念。
普世價值提煉
- 挑戰不在於舊要不要丟，而是如何讓舊與新共存並互補。
- 補償 + 監控的組合，是整合黑盒系統的普遍解法。
- 去同步、去耦合，是雲原生的核心原則。
- 不要把備援當備用，而是設計成日常運作的一部分。
- 轉型第一步不是重建，而是理解現狀。
- 轉型的本質，是把錯誤制度化，避免重複踩坑。
- 安全不是附加的，而是流程內建的特徵。
- 從 Monitoring 到 Observability，是現代平台必經之路。
- 大型組織的複雜度，不在程式碼，而在人與人的協作。
- 沒有完整測試，就沒有真正的數位轉型。
- 真正的轉型，不是一躍而上，而是循序漸進。
- 轉型不是 IT 領導，而是跨部門共創。
- 解耦依賴比硬幹效能更有效。
- 數位轉型的勝利，不是技術，而是文化。
- 挑戰不是障礙，而是下一輪迭代的目標。
- 技術的考題，不是程式跑不跑，而是業務有沒有更好。
- 數位轉型不是目的，而是創造價值的過程。
當數位轉型遇見資訊安全 