「誰知道現在的流量、頻寬和CPU的使用量嗎？」肯驛國際集團技術長陳志豪在兩年前還只是肯驛IT顧問時，在內部IT會議上問了這個問題，IT部門竟然沒人知道答案，只能概略描述，系統常有延遲狀況，或是經常接到顧客反應網頁沒有回應。IT無法確切掌握系統的運作情報，他指出，不只有肯驛如此，許多企業IT都面臨了同樣問題。而這也成了他後來進入肯驛後必須解決的任務。

但是，肯驛系統運作狀態的情報，不只是肯驛內部IT需要的資訊，更是全臺發卡銀行客服部門都想知道的情報。因為肯驛是全臺最大的VIP服務平臺，負責全臺發卡銀行旗下形形色色的顧客權益服務，例如機場接送、通關禮遇、行李追蹤等，服務顧客每年多達千萬規模。一旦肯驛系統出錯，這些銀行的VIP顧客可能都會跳腳。

也因此，肯驛設置了專屬的客服系統，配置了100多位客服人員，來因應同步執行的30個不同專案的顧客。

肯驛客服人員一接起電話，必須在最短時間內了解客戶身分，分辨客戶來自哪一個銀行的合作專案，但是，隨著，肯驛承攬專案數越來越多，資料庫也越來越龐大，兩年前，甚至因為資料庫反應緩慢，客服電話都快結束了，客服系統還沒回傳客服人員查詢的參考資料。

陳志豪表示，資料庫效能不彰，對客服部門相當困擾，只能依賴資深人員的經驗，透過話術來取得客戶更多必要資訊，但是，客服人員流動率高，且銀行專案經常推陳出新，改變速度又快又多元，新手客服根本無法勝任。後來甚至發生硬碟客服電話錄音資料遺失災情，才讓肯驛下定決定要展開IT大轉型。

為了日後合約糾紛舉證之用，肯驛客服對話都需錄音，且至少保存3年，但是2年前盤點資料時發現，竟有錄音檔沒有成功存檔，IT團隊判斷系統快要不能使用了，肯驛面臨一個抉擇「要擴充本地端的機器，還是乾脆搬上雲端？」陳志豪的部下這樣問他。

而另一方面，肯驛每年承攬的專案持續上升，一年大約有300多個專案，目前累積上千個專案，且專案的服務又相當多元，機房沒有辦法滿足需求，也面臨了容量不足的問題。

為了評估系統是否需要上雲端，陳志豪想要知道現有系統的狀況、流量，不過，肯驛過去採用微軟虛擬化平臺，透過2臺伺服器來部署10幾個VM承載所有服務，雖然有一套功能陽春的Hyper-V平臺監控工具，但沒遇過問題，肯驛MIS也不懂得如何使用。

陳志豪表示，過去系統效能評估工作，多由廠商負責，MIS仰賴微軟或是IBM這類業者來協助配置，而只負責維護系統的MIS，頂多擅長業務面的API介接工作，反而越來越不熟悉系統高可用性、負載均衡、分流等基礎架構的專業知識，他光要部下找出基本CPU使用率的資料都很困難，他認為：「缺乏監控系統效能的指標，就無法有效地管理系統」，因此，他決定，凡是需要效能指標的系統，都得搬上雲端，他就是看上了公有雲提供的詳細環境監控資訊。

肯驛將系統搬上雲端後，也開始發現了過去不少浪費資源的應用，例如有一個過去部署在VM中的資料庫，肯驛IT原本都以為，該資料庫的負載量很大，但是改放上雲端後，才發現負載量竟然不到原本的1%。這更讓陳志豪體會到，許多企業往往投入龐大成本採購I/O資源，因為缺乏了一套衡量系統效能的機制，再加上資料流量異動也很大，企業根本無法用量化數據來評估系統真正需要的資源。

企業既有系統如何無痛上雲端？服務導向架構是關鍵

儘管沒有詳細的效能數據，肯驛也沒有採取一次性全面將系統上雲端的作法，他的作法是將雲端視為另外一個本地端環境，先從系統流程和架構上來將系統分區，不需改變系統邏輯的系統，先上雲端提供服務，如此一來，也可以無痛地淘汰這些系統所用的老舊設備。

肯驛目前的系統架構，分為前中後端，前端是網頁，中間是API引擎，後端則是資料庫，API引擎又分為兩個，一個用來直接串接資料庫，另一個則用於中繼轉換的引擎，來避免外部連線直接存取內部資料庫。

肯驛先將容易搬移的服務上雲端，如儲存和備援，再逐步轉移部分應用系統，等到本地端系統多數上雲端後，再將備援系統和本地端系統的角色互換，最後等到所有系統全數上雲後，再用淘汰本地端的舊設備，來擔任備援機器。

「上雲端的關鍵在於服務導向架構（Service-Oriented Architecture，SOA），」他解釋，採用SOA架構的系統，可以將服務API化，更容易將系統搬上雲端，而其餘未支援SOA的系統，肯驛先用Container技術打包這類系統的完整環境後，再搬上雲端。他補充，肯驛許多系統服務不能中斷，甚至服務的開發者已經離職，更是不能輕易更動系統邏輯。

不過，若遇到同一套系統中，使用到兩種不同的開發語言，例如一部份程式用C語言，而另一部份功能用PHP，陳志豪建議，快速上雲的作法是，直接將既有系統用Container打包後搬上雲端，再來評估考慮是否需要重新設計架構，他認為，多種語言混合的系統架構較為複雜，不值得企業投入人力成本處理。

此外，用Container封裝既有服務，還有另外一個優點，陳志豪解釋，肯驛不少系統經常需要串接代管在GitHub上的開源軟體套件，但有時這些套件因商業化而下架，往往無法在GitHub上快速取得原有的可用版本，所以，肯驛IT團隊後來開發新功能時，都會將程式封裝到Amazon EC2 Container Registry（ECR），再存放到MongoDB資料庫中，如此一來，就能確保應用服務的程式碼不會受到GitHub專案異動的影響。

擁抱微服務架構先從成長型新服務著手，資料庫搬上雲還能節省成本

肯驛將部分系統放上雲端之後，因為有了流量監控的工具，不需要派人巡視機房，省下的人力就可以聚焦於下一步的發展，陳志豪認為，肯驛IT團隊需要升級，才可以走向下一步，當團隊經過一段時間的鑽研後，慢慢地有能力撰寫微服務架構的邏輯，他就開始將核心業務的每個專案，都轉成微服務架構。

肯驛今年推出的新服務稱為「叫車吧」App，就是採用微服務架構，他指出，微服務架構適合從新服務開始著手，舊的專案就要花費較長時間來轉換，需要專案負責人和IT團隊，將舊的服務分成多個部分，再一步一步轉換成新的框架，其中，資料庫的轉移是最費時的工作，他坦言，直到目前為止，肯驛都還在轉移資料庫。

原本肯驛慣用的資料庫是SQL Server，搬上AWS後則改用相容MySQL的雲端資料庫服務Aurora，但兩種資料庫架構差異不小，當時陳志豪也很擔心資料庫轉換後會發生問題，像是資料庫的表格結構（Schema）和資料表（Table）等邏輯設計會出錯。

於是，肯驛IT花了不少時間仔細檢驗每一筆資料，並利用資料庫轉換工具Schema Conversion Tool，來檢視資料庫轉移後可能發生問題的資料，還可以提供這些資料的記錄。一開始先用少量資料測試，像是先轉移1,000筆資料，再一一比對轉換後的結果與原來邏輯是否相同。因為擔心Schema轉換出錯後的處理相當麻煩，在轉換資料庫的過程，陳志豪特別謹慎。

替換資料庫時，內部IT甚至質疑既有資料庫還可用為何要轉移，但他認為，過去為了高可用性，肯驛部署了2套SQL Server，光是一套系統的授權費用就要10幾萬元，上雲端後，初期可以節省不少費用，再加上肯驛IT獨立成新創公司後，目前還無法估計未來業務發展，因此，他認為，不需要先投入太多不必要的成本。

舉例來說，叫車吧系統剛推出時，一天只有幾筆訂單，但是隨著業務量持續成長，資料庫系統的資源需求量才快速增加。依陳志豪觀察，企業服務規模要成長到非常大量且穩定之後，還要能清楚地掌握所有系統的流量資訊，再來改用本地端實體設備才會真正划算。

除此之外，陳志豪也表示，肯驛系統是對外持續提供的服務，不能容許服務中斷，當資料庫轉移到雲端資料庫的過程中，Aurora能夠在不關機的情況下自動更新，在主從式架構下，系統同時有Master和Slave在運作，升級時Aurora會將DNS由Master轉到Slave，原本的Master就會變Slave，更新到新的版本，且目前肯驛在雲上建了3套資料庫，不只是為了備援，還可以分散系統對資料庫的查詢請求。

他補充，更重要的是，Aurora還提供監控的儀表板，可以讓IT人員清楚地看見每一筆資料查詢的狀況，了解系統延遲的原因，這正是肯驛兩年前最大的痛點，缺乏監控機制，遇到系統出狀況卻不知道是哪一個環節出了問題。

容器技術不只能實現微服務架構，還能隔離各服務運作降低風險

Container技術不但能將既有的服務封裝後快速上雲，並將原有的架構重新建構成微服務架構，還能將各個服務相依性降低，讓每個服務獨立運行來降低風險，陳志豪舉例，以前肯驛的服務是Web服務的架構，所以不同的銀行服務都是呼叫同一個Web服務，這樣的作法風險很高，因此，肯驛為了降低風險，將每個銀行的每項服務，都用Container技術獨立分開。

以叫車吧的服務為例，用Container技術後速度變快，隔離機制也變好，在他認為該服務能夠與肯驛其他專案串接時，才發現系統變動性非常高，計價方式和客戶群都不同，需要經常更改模型和規則，即使Container的變動性高，但是他指出，每一次系統變動都有風險。

因此，陳志豪決定將變動性高的部分獨立出來，用另外一個框架，像是漫遊吧的服務，每家銀行訂價邏輯都不一樣，就獨立成另一個框架，以免經常變動影響原有的服務框架。

IT不只解決內部問題，還要開創對外商業模式

「我們現在創造的東西，怎麼變成以後賺錢的工具？」這是他不斷詢問自己的問題，陳志豪曾剛進入一家高科技電腦公司的第一年，就被賦予裁員任務，也因為那次經驗，讓陳志豪在設計架構時，會想的更多更遠，從過去只是完成來自業務端交付的任務，到現在肯驛將他率領IT團隊獨立出來，另外成立了一家新創公司，由陳志豪兼任總經理，他轉而必須開始自己找市場。

「這些問題都可以用更簡單的方式做，」陳志豪表示，要解決企業內部問題、優化系統效能，大可不必將系統搬上雲端，還將傳統架構改為微服務架構，但肯驛集團對陳志豪的期待，IT在解決內部問題的同時，還可以將這套框架變成解決方案，成為對外營銷的產品，他認為，肯驛遇到的每個障礙，跟其他企業是一樣的，以往研發人員都是被動地執行被賦予的任務，他希望IT團隊也可以開拓自己的業務。

陳志豪會從現在趨勢和新技術中，找尋可著手解決方案，從既有產品和市場，發展新產品或是API，借力使力延伸發展出新的商業模式。

CTO小檔案

陳志豪

肯驛國際集團技術長

學歷：臺灣大學電信工程學系碩士

經歷：曾在英華達手機通訊研發部任職長達11年，從工程師一路升到資深經理，之後又進入仁寶電腦，擔任新平臺技術開發處主管4年，在2015年12月則進入肯驛國際，擔任技術長至今，更在去年10月，兼任肯驛集團公司肯驛訊息科技總經理

公司檔案

肯驛國際集團

● 總部：臺中市北區華信街8號2樓

● 成立時間：1999年

● 主要業務：主要負責電信、保險與銀行信用卡、企業 VIP 高端加值服務，提供精緻生活與尊榮禮賓出行平臺化服務

● 網址： www.canlead.com.tw

● 董事長：吳政哲

● 員工數：大約270人

● 年營收：大約20億元

● 技術部門人數：大約20人

● 技術部門分工：數據研發、企業加值、資訊系統維運和UI/UX 設計體驗

● 2008年：成立行銷與電子商務部

● 2015年：成立數據與服務研發部

● 2016年：成立肯驛訊息科技

● 2016年：推出叫車吧平臺

（更正啟事：原公司檔案年營收金額誤植，內容已更正）