20 財金資訊季刊∕No.73∕2013.01

專題報導│金融資訊系統邁向服務不中斷之路

金融資訊系統 邁向服務不中斷之路 葉清維∕財金資訊公司研發部組長

蔡佩珍∕財金資訊公司研發部高級工程師

一、前言

隨著科技的發展，以及使用者對於 IT 服務

的要求越來越高，維持資訊系統之穩定運作，

逐漸被各企業所重視，且資訊系統漸漸朝向提

供 724 小時之服務。但資訊系統難免有計劃

性中斷（Planned Outage），如安裝修補程式、

系統更新或維護資料庫等需求；亦可能發生非

計劃性中斷（Unplanned Outage），如軟體錯

誤、病毒感染、天災或遭受網路入侵攻擊等事

件，如何降低當這些因素發生時對系統之衝

擊，並使系統仍可持續運作，實為企業經營重

要課題之一。

財金資訊公司（以下稱財金公司）為臺灣

金融資訊跨行交易處理樞紐，營運之金融資訊

系統每日處理約數百萬筆的跨行交易，其連線

單位包含臺灣金融機構、國際組織（VISA、

MasterCard、JCB、中國銀聯、NTTD）等，

由於肩負提供金融機構及社會大眾便捷的金流

服務、穩定的營運系統及安全的交易環境之重

任，故除主管機關之要求外，對於強化自我系

統持續運作更是不遺餘力。

財金公司之業務多元，所使用之資訊系統

平台有 IBM 大型主機、開放系統 R6 主機及開

放系統 Windows 主機，本文以財金公司之主要

業務－通匯、ATM 業務所使用之 IBM 大型主

機資訊系統平台為例，探討如何邁向服務不中

斷。

二、業務持續運作等級

IBM 公司在 2007 年出版之「IBM System

Storage Business Continuity: Part 1 Planning

Guide」對於 IT 業務持續運作做出了定義，亦

即在高可用度（High Availability, HA）、持續

運作（Continuous Operations, CO）及災變復

原（Disaster Recovery, DR）三個條件都滿足

後，才能稱為 IT 業務持續運作（如圖 1）。

1. 高可用度（HA）：減少非計劃停機的時間，

包含避免故障發生、具備容錯能力、環境

的獨立性、異常偵測的程式設計、能快速

恢復及重新啟動。

2. 持續運作（CO）：減少計劃性停機時間的

應用系統設計，包含變更或維護時不需停

機的設計、可持續運作之應用程式，以便

使用者於任何時間皆可使用系統。

3. 災變復原（DR）：當災變發生致主中心設

備無法使用時，可於不同的地點、不同的

設備、不同的網路恢復系統運作之能力。

www.fisc.com.tw 21

金融資訊系統邁向服務不中斷之路│專題報導

圖 1 IT 業務持續運作之定義

資料來源：IBM System Storage Business Continuity: Part 1 Planning Guide

其中有關災變復原（DR）的部分，為了滿

足需要正確的描述和量化各種系統災變備援成

功的關鍵因素及能力，美國 SHARE 組織與

IBM 公司於西元 1992 年針對災變備援之技術

能力層級做出第 1 層至第 7 層定義，分別如下：

第 1 層：採用磁帶復原方式且沒有異地備

援中心

第 2 層：採用磁帶復原方式且有異地備援

中心

第 3 層：採用遠距磁帶備援方式

第 4 層：採用即時磁碟抄寫方式

第 5 層：採用軟體之同步方式

第 6 層：採用磁碟或主機之同步方式

第 7 層：採用磁碟或主機之同步方式並且

有自動化復原機制

這 7 個等級提供了簡單的方法定義系統的

「服務等級」、「風險」、「目標服務等級」、

「目標環境」，以及帶入「成本」及「恢復時

間」的概念來說明這些解決方案（如圖 2）。

近年來由於硬體及網路環境的進步，雙中心

（Active-Active）已然有了實現的概念與作

法，故 IBM 公司增加第 8 層雙中心定義。

圖 2 災變備援等級

資料來源：IBM System Storage Business Continuity: Part 1 Planning Guide

因此，企業在進行業務持續運作方法選擇

時，須對以下問題考慮過後，再決定企業之業

務持續運作之等級，才不至於迷失於成本與損

失之間。

22 財金資訊季刊∕No.73∕2013.01

專題報導│金融資訊系統邁向服務不中斷之路

1. 有多少的資料是企業無法遺失的？意即企

業須定義自已的「目標復原點」（Recovery

Point Objective, RPO）。

2. 企業可容忍多少的中斷時間？意即企業須

定義自已的「恢復時間目標」（Recovery

Time Objective, RTO）。

在設計高可用性系統解決方案時，需要考

慮系統中斷服務時所帶來的損失與建置系統所

投入的成本這二者之間的平衡，不同產業所著

重的層面有所不同。對於金融服務業而言，數

分鐘的系統中斷即可能造成極大的金錢與商業

損失，甚至包含無形的損失，如公司的商譽及

客戶的信任；反觀其他行業，服務中斷可能只

是帶來客戶的不便，如擬投資建置高可用性系

統反而花費更高的成本與負擔，所以最重要的

是瞭解：當系統中斷時，其影響範圍及損失至

何種程度是企業所能承受的。

三、打造服務不中斷之系統

早期財金公司每個月系統須進行跨行停機

維護 5～6 小時，造成參加單位及其客戶之不

便，如何縮短資訊系統中斷服務的時間並超越

災變復原第 7 層技術能力，一直是近年來努力

的目標。因此，為達到服務不中斷及業務持續

運作目標，災變備援等級之技術須能達到第 8

層雙中心（Active-Active）架構，亦即在高可

用度（HA）、持續運作（CO）及災變復原（DR）

三個條件都滿足方為可行。

(一) 建置主中心雙主機平行連線系統

（Parallel Sysplex）服務

1. 1997～2000 年前車之鑑

1997 年財金公司即引進當時 IBM 大型主機

最新之雙主機平行連線系統（Parallel Sysplex）

技術；透過耦合設備（Coupling Facility）連接

兩台以上之主機，同時執行既有之應用程式，

以便兩主機能平行處理連線交易，達成工作荷

量均衡化（Workload Balancing）及資料共享

（Data Sharing）之目的，遂進行「跨主機平

行連線系統軟體建置」。但因為雙主機平行連

線技術造成系統額外耗用主機效能（Overhead）

過高，不符合當時需求規格所要求之交易處理

能力，且部分技術尚未臻成熟下，平行備援連

線能力不夠完整，如因原連線 IMS 系統異常導

致斷線，特定之跨行連線種類（如 LU6.1，其

交易量約佔財金公司總交易量之 70%）卻須待

原連線 IMS 系統重新啟動完成後，方能恢復

正常連線等原因，故於 2000 年暫停採用該技

術。

2. 2006 年效能測試階段

隨著技術的進步，自 2006 年開始進行 IBM

大型主機雙主機平行連線系統 POC（Proof Of

Concept）驗證，以確認 IBM 大型主機雙主機

平行連線系統是否適用於財金公司，鑑於該驗

證目標在於平行連線系統之效能可否符合預

期，為達成該目標即需要訂定驗證方法與指

標、建立測試環境、備妥壓力測試工具及測試

機制，然因坊間沒有合適的工具，所以決定自

行開發建立一套更具完整「功能」、「壓力」、

「耐力」的測試工具及機制，並對後來重大系

統轉換作業（含軟、硬體），提供一套完備的

測試方法及工具，降低系統轉換之風險，提供

參加單位於量能測試上之測試經驗及做法上之

參考。

人員訓練亦為本階段之重點項目，除了請

IBM 公司安排一系列不論是硬體、系統軟體、

網路、安控等雙主機平行連線系統相關課程

外，更安排人員到日本及中國參訪，實際考察

www.fisc.com.tw 23

金融資訊系統邁向服務不中斷之路│專題報導

成功的案例是如何做到的，以充實經驗，並增

加同仁對於這個專案成功的信心度，順勢讓不

論是系統、網路、應用程式、安控等相關人員，

對於雙主機平行連線系統之新技術更進一步地

瞭解，此舉對於後來在溝通及人員技術能力等

各方面，都奠定成功的基石。

同時，在開發測試機制方面，也突破了具

備加解密功能，並可透過外部設備經由網路模

擬連線單位交易行為，其中每秒可送出約 300

～800 筆提款∕轉帳∕匯款等交易（約 3.3～

1.25 毫秒∕筆），每秒可接收約 160 筆提款∕

轉帳∕匯款等交易（約 7 毫秒∕筆），這樣對

於效能測試提供了一個更接近真實系統交易之

模擬行為，提高測試結果的可靠性，以及提供

評估未來營運系統之量能之參考價值。

3. 2007 年整體測試及驗證階段

本階段的重點工作為計劃性及非計劃性停

機之持續運作及高可用度驗證。「計劃性停機」

驗證項目包含例行性變更的主要工作：系統硬

體、z/OS 作業系統、IMS 子系統、網路、資料

庫、應用程式、資源控管等；「非計劃性停機」

驗證項目包含：系統硬體元件可用度、z/OS 作

業系統軟體元件可用度、IMS 子系統軟體元件

可用度、TCP/IP 網路元件可用度、應用程式可

用度，意即驗證當單一元件失效（Single Point

of Failure）時之可用度；另外還有批次作業驗

證及效能驗證。

當驗證結果出爐，已可訂出哪些例行性變

更可以採用雙主機系統輪流變更（Rolling

Maintenance）的作法，達到不停機目標。由

驗証結果顯示：在「元件失效」方面，一方面

也確認有哪些是有單點元件失效的可能，哪些

元件在發生問題時，會有什麼影響？影響多

久？需不需要人工介入處理？應用程式做了哪

些有效的修改等各項調校；在「效能」方面，

由於設定之最大交易吞吐量需求為平均每秒

460筆，峰量每秒 690筆，由於初期使用之CPU

處理量能，最大僅能達到每秒 400 筆，且在資

料庫衝撞的比例（Contention Rate）增高，在

增加 2 倍 CPU 處理量能後，平均每秒交易量

約 621 筆，瞬間峰量每秒可逾 700 筆，已達成

系統效能需求標準，這也成為實際建置時，對

於 CPU 投資之參考；在「人員培訓」方面，

均以實機演練為主，使同仁藉此熟悉平行連線

處理系統環境，並藉由實際負責各項驗證之研

討及執行以培養相關技能；在「容量規劃」方

面，在平行處理的環境下，每筆交易相較於單

機環境，CPU 由每筆 1MIPS 增加到 2.5MIPS，

因此備援模式（Degrade Mode）須具備峰時

70% 之容量，而預留安全容量則須增加 10%，

即須達峰時 80%之容量。

在經過各項系統穩定性之驗證後，確認未

來財金公司同地平行連線系統上線後，將可縮

短同地備援主機接替運作時間至 10 分鐘以

內，並可提升系統備援等級、強化業務持續運

作；運用平行連線系統多主機串連之特性及功

能，將可減少例行性系統變更作業之停機項目

及停機時間，提高服務水準，但平行連線系統

建置後，仍須安排計劃性停機，以便進行較特

殊之變更。

4. 2008～2009 年建置階段

由於有了前述二階段的經驗，成員對於

Sysplex 技術已瞭解並十分有心得，所以建置

階段做起來也更駕輕就熟，但是 POC 階段之

目的只是為驗證，並不是在財金公司的實際環

境下執行，如果真要建置，必須要依循財金公

司的各項管理規定，並調整符合高可用度之作

業程序。

24 財金資訊季刊∕No.73∕2013.01

專題報導│金融資訊系統邁向服務不中斷之路

除原有建置及驗證之工作外，在前二個階

段沒有的新購機器設備、複雜及多元的網路環

境管理、監控及自動化復原機制、依財金公司

既有之變更控管機制檢視及調整變更程序、檢

視問題管控流程、操作程序調整、人員熟悉度

訓練、所有連線單位之測試等，都需要另外建

立及安排，所以在這一段時間，財金公司系統、

研發、安控等部門幾乎全體動員投入。

努力的結果終於有了代價，在 2009 年 11

月營運系統上線後，預估 CPU 使用率約為單

機環境之 2 倍，實際結果亦如此，表示先前測

試評估十分正確；在效能部分，原預估大約增

加 1.5 倍之交易反應時間，但結果趨近於原單

機環境，而批次作業原預估無顯著之差異，結

果亦然。

自 2010 年 5 月開始，不論是系統版本提

升、機電設備更換、調整資料庫等，皆採用雙

主機系統輪流變更（Rolling Maintenance）之

作法，以達到服務不中斷。其中除採用非

TCP/IP 連線方式之少數參加單位外，由於可能

在系統輪流變更時會短暫中斷連線，其他所有

採用 TCP/IP 連線方式之參加單位在系統輪流

變更時均無感，後續在 2011 年推行所有參加

單位採用 TCP/IP 連線方式，至此，財金公司

向參加單位公告每月暫停服務之事，已正式走

入歷史。

(二) 異地備援中心對外快速開啟服務

在完成同地之雙主機平行連線系統建置

後，即達成高可用度（HA）及持續運作（CO）

之成果，但關於 IT 業務持續運作（IT Business

Continuity）之災變復原（DR）部分，從 2010

年開始，財金公司考量縮短備援中心接管時

間，將主中心與備援中心間之切換程序調整為

自動化，並可藉此減少人工操作錯誤及簡化程

序，也因此將原本 IT 復原時間由 2 小時縮短至

1 小時內。而在 2011 年為了將主中心切換至備

援中心後返回主中心程序由磁帶改為即時，將

原來 XRC（eXtended Remote Copy）+ RSR

（Remote Site Recovery）機制改為全部

XRC，並搭配 GDPS/XRC 採用自動化切換及

返回，亦縮短返回之時間至 30 分鐘。為再提

升業務持續運作能力，2012 年著手進行「異地

備援中心快速開啟服務」跨行基金可用餘額應

用系統開發（如圖 3），於災變發生造成主中

心服務中斷時，可縮短異地備援中心開啟服務

時間為 10 分鐘內，降低服務中斷所造成之衝

擊。

異地備援中心對外快速開啟服務程序，包

括「平時作業程序」及「災變作業程序」。平

時作業程序含兩個項目，第一項為主中心資料

庫下載並傳送至異地備援中心，其主要下載內

容包含帳務、序號及各業務控制檔，每 10 分

鐘執行一次，執行時間約 45～60 秒，主要目

的為保留 10 分鐘前的參加單位跨行基金可用

餘額；第二項為異地備援中心資料集上載至資

料庫，其主要上載內容為包含帳務、序號及各

業務控制檔，每 10 分鐘執行一次，執行時間

約 3～4 分鐘，主要目的將 10 分鐘前的參加單

位可用餘額上載至備援中心資料庫，讓參加單

位得以進行跨行交易，並且系統可以隨時對外

開啟服務。

災變作業程序含三個項目，第一項為異地

備援中心對外開啟服務，其主要執行內容為關

閉「平時備援中心資料集上載至資料庫」排程，

開啟異地備援中心定時排程作業，確認當下無

執行「平時備援中心資料集上載至資料庫」排

程時，則執行對外開啟服務程序；第二項為異

地營運應用程式作業平台產出資料補全資料，

其主要工作內容為包含帳務資料庫、交易明細

www.fisc.com.tw 25

金融資訊系統邁向服務不中斷之路│專題報導

資料庫、連管及夜間批次作業資料集，主要目

的為產生災變發生時點之帳務補遺資料；第三

項為補全異地營運系統，其主要工作內容為包

含帳務資料庫、交易明細表資料庫、連管及夜

間批次作業資料集，主要目的為將帳務資料庫

補全至異地營運系統，讓該系統可以完成結帳

作業。

圖 3 備援中心快速開啟服務架構圖

四、結語

現今科技進步的速度越來越快，設備成本

亦陸續降低，有可能財金公司當年所面臨的困

境及挑戰，在新技術及新產品推出解決方案後

迎刃而解。 IT 業務持續運作（ IT Business

Continuity）的三個部分：高可用度（HA）、

持續運作（CO）及災變復原（DR），財金公

司一直以來都不遺餘力地持續改善，期望在現

今雙中心運作概念下，陸續提供實行之解決方

案，將業務持續運作的等級推向最高級，即使

災變發生時亦能達到無縫接軌，持續提供高效

能且穩定的服務。惟這一條路尚需仰賴太多的

技術解決方案，尤其是當雙中心之間的距離越

遠時，不論是網路頻寬、資料落差及最重要的

效能衰減，都是極度需要克服的難題。

回顧財金公司金融資訊系統邁向服務不中

斷及業務持續運作之路，公司高層的決心與支

持是非常重要的關鍵因素。打造服務不中斷之

系統及業務持續運作服務，除了需要許多的技

術支援外，投資的成本更是原本單一系統的數

倍。但這些投資帶來了 24 小時不中斷的便民

金流服務，亦達成了財金公司對於企業金流服

務之需求及社會責任。

參考文獻∕資料來源

1. IBM System Storage Business Continuity: Part 1 Planning Guide.

2. Content Manager OnDemand Backup, Recovery, and High Availability.

3. GDPS Family An Introduction to Concepts and Capabilities.