You are here

「路途並不遙遠」但是會「走的十分辛苦」

近一年來廠商大談SERVER CONSOLIDATION,我也曾陪幾個所謂的專家(其實更像SALESMAN)去拜訪認識的CIO,談到的大都是諸多管理,資源有效等強調ROI優點,但是甚少談到銀行應該怎麼著手(從何開始,如何作?主要考慮點?)等技術上的建議.當年(2004)T銀行嘗試在主機上執行LINUX,我就問拿來做甚麼系統?主要技術人員告訴我,他們想做分行系統整合我就建議應找核心系統經驗者參與.數月前F銀行計劃以SOA作為新核心系統架構進行CST(Core System Transformation)我就告訴他們,要在OPEN架構上進行CST先要求支援廠商組織等同原主機系統服務支援體制再來談,當時我並未進一步說明,也是僅以追求QoS(Quality of Service-Transaction, Realibility, Management, Security)帶過,我是想有些事情等發生問題時大家自然會重視,早說客戶可能會認為你在嚇他們.然而最近確實有C銀行遭遇到分行SERVER集中化以後發生的問題,而這個問題嚴重性等同核心系統出問題,也許這時才瞭解到原來設計集中化SERVER就是設計另一個用途的核心系統,再認知到原來核心系統並不是所謂的存放匯系統而已,還包括許多東西-QoS,對大部份開發應用系統的人而言也許是名詞上深淺度不同體會而已,然而對設計核心系統的人就不僅是體會而已,而是必須深入思考及實踐的習題.負責C銀行分行系統的廠商也許以為SERVER就是SERVER,反正原先的AP FRAMEWORK-J2EE本來就是跨平台(H/W,OS),集中化就是把原先BRANCH SERVER上的軟體搬到另一個較大的CENTER SERVER而已,然而它似乎忽略了這種原先就可靠性並不如核心系統的分行系統,集中化後反而不如過去水準(消化不良).這種情況也就是筆者所言-名詞上路途似乎並不遙遠,但實施上會走的十分辛苦.有這種錯覺也非支援C銀行這個廠商一個,可以說這是普遍現象.然而一下子要這些搞OPEN的人達到主機QoS等級事實上也需要時間磨練,畢竟主機QoS也累積將近30年經驗.筆者以為還是先針對QoS中的Reliability這個主題著手,因為筆者認為這是QoS中最重要的項目,至於有關Reliability的細節項目,筆者想留在「研究與報告-技術」中詳談,

Comments

C銀行最大的問題不在branch搬到central上面,該廠商的設計本來就是central的,以前是把central搬到branch上。
問題是因為C銀行有舊式的認證系統,無法在central上面正常實作,而這是沒有真正作之前不能知道的事情。去除這點其實central是沒有問題的。
...可是別忘了C1銀行也把主機換了,雖然C2銀行還是在主機上執行,那是因為sales賣得好,但是世界上別的銀行大多數沒有讓該系統於主機執行。

F I N's picture

從閣下行文判斷大概是IISI公司,C銀行的分行系統應該是貴公司的傑作?何不好好利用本站大方的站出來把經驗講出來讓關心的人理解? 所謂"廠商的設計本來就是central"需要更明確的技術說明(最好在研究與報告-通路與端末發表一篇專文),才能讓社員們理解,否則豈不等於沒說?最後你提到"...可是別忘了C1銀行也把主機換了,雖然C2銀行還是在主機上執行,那是因為sales賣得好,但是世界上別的銀行大多數沒有讓該系統於主機執行"似乎與這篇主題沒甚麼關連,是否可以請你進一步說明,讓我了解你的意思.

是IISI,閣下能那麼清楚的人應該是與IBM有極深關係的人。
回答問題1,看表格可以知道系統,有那麼好的關係看一下表格應該就可以知道該系統是集中式的,看H銀行(IBM別的BP的分行方案)的表格,就知道那不是集中式。
問題2,FNS光在台灣就沒有全部是主機的方案,就我知道BANCS現在也不是主推主機的,更別說別家的retail banking方案,最近日本幾個案子都不是用主機。

F I N's picture

筆者認為集中化以後應該重視有關Disk(DR&HA),Trsaction(2PC,UOW,Workload),Recovery(Log & Trace),Scalbility(Throughput & response)等High Availability考慮點,結果你是談應用系統設計層次的表格(Branch Table),我看有點雞同鴨講.另外無論用甚麼server(z,p,x),集中化的設計都要考慮上述的問題,那是確保QoS(Quality of Service)的絕對必要條件,這個問題解決了以後,才是應用系統的設計問題.舉個例子也許可以讓你理解,未集中化以前系統每日START/STOP都有一日的CYCLE,每日的交易量/瞬間的交易量也比較可控制(系統面設計與應用面設計),所以比較不會突發狀況,整體系統運轉相對就比較穩定.但是當集中化以後,系統就很有可能被要求不停機(分行作業時間帶不同),所以一個永不停頓系統的HOUSEKEEPING工作從系統面與應用面就要依賴良好設計經驗才可能調整的比較理想.至於瞬間的巨量,雖然系統都有提供WORKLOAD BALANCE對策,但是同樣的從系統面與應用面就要依賴良好設計經驗才可能調整的比較理想.筆者寫這篇文章的主要用意在此,並提醒要進行如此計劃的銀行同業注意,把過去在核心系統經驗應用在諸如此類的系統.而這個系統將大多會建置在開放系統架構下.通篇內容只是建議設計這種等同核心系統架構的人,不妨多參考以前攪主機人的經驗.以本社註冊社員迄今將近400人,其中一半屬銀行客戶,大家交換意見彼此切搓,具名發表意見只是禮貌,如果你認為侵犯隱私權,不屑註冊,也不強求,就請做個旁觀者吧. 

Arthur's picture

看起來大概是語意上的誤會
原文並非說主機好、open 不好;也不是說分行系統該分散、不該集中
本意依在下細細體會,應是期勉新架構別忽略了舊架構之所以長久存在的理由
兼取兩者之長,則用者幸甚

倒是這位匿名兄臺(或大姐)提及的認證系統問題,相信大夥兒都有極大的興趣
大家說說看,是也不是?

分行分散式處理沒甚麼不對,以前服務於U公司(9600時代, ATM交易不多), 南部'一等行'臨櫃單筆交易,一般平均在3秒內回應到位(不含傳票列印), 現在數據為何? 分行是否都改為'矮櫃'了? Unix Kernel Scheduler是否仍舊Time-Sharing? 分行系統規格中是否加入Tuxedo/Weblogic/WAS or CICS? Unix+RDB+AP Server+P-Code(Java),目前'實驗性'是否仍有點高? H/W要多大, 以有100家分行(平均5個端末櫃檯)的行庫為例,共要幾部Unix Boxes? TCO如何? 用UNIX跑Batch是否比OLTP/SOA更適合?

henry's picture

分行系統往往會被認為是個系統的週邊,其實它對業務的運轉是相當重要的,而至於是要採集中式或分散式,其實没有一定論,要看使用者的環境及管理者的認知而定,而採集中 sever 方式的系統,其實在技術上更要考慮較多的因素,諸如交易流量的控制/系統non-stop 的控制等,在處理的方式上應該是與主機的 OLTP 較相似;採分散式則所考慮的只是單一分行點的問題,交易量的考量可能没有集中式的迫切,而對這些的因素的考慮,其實就在於各銀行系統在架構時,依現實環境去決定,對採何種方式確定後,再依實際的問題去解決,所以我想較合理的用法,就是往運用面去決定,而至於系統面,我認為是各有優缺及考量的。

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
情非得已,網路蟑螂橫行,必須確認您是友善的訪客,麻煩之處,尚請見諒
Fill in the blank.