肯驛國際集團技術長陳志豪

「誰知道現在的流量、頻寬和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年:推出叫車吧平臺

(更正啟事:原公司檔案年營收金額誤植,內容已更正)


Advertisement

更多 iThome相關內容