出外露營會遇上哪些風險?意外受傷、旅程突然取消、露營設備因火災意外燒毀、造成他人財物損失。這些,都是露營情境中可能會發生的風險。在國泰產險新推出的電商式投保平臺BeSafe享出門,不僅將這些風險的保障內容,像是人身保障、行程保障、露營設備保障、個人責任保障的保障項目,以客製化、套餐式的方式組合。
如果露營時也帶上自家寵物出門共遊,心愛的寵物卻發生意外而受傷,或是重要財物如手機、證件、現金失竊,甚至自己不小心將車鑰匙遺失,或發生車子在路上臨時拋錨,而需要多付一筆拖吊費用的狀況。消費者還可在平臺上自行加購商品,像是寵物保障、財物保障、汽車保障等。
這樣全新的保險商業模式,只是國泰產險的BeSafe平臺其中一款套餐組合。國泰產險更以出門可能會遇上的風險出發,搭配更多異質的保險險種,針對不同族群,如通勤族、銀髮族,打造不同的保險套餐。
為了要能實現彈性組合、短天期保障的保險創新模式,國泰金控數位數據暨科技發展中心(簡稱數數發中心)與國泰產險IT團隊共同合作,打造了保險中臺新架構。
除了要整合現有國泰產險核心系統,又能在中臺支持碎片化的保險商品快速重組,進而提供數位通路所需的彈性,目的是為了能彈性反應不同保險情境的顧客需求變化。
然而.國泰產險以往的商品邏輯設計方式,並無碎片化、短天期的概念,所以,當要導入一些新型態商品,或是需要異業合作時,通常得花上3個月到半年的時間才能上線。
因此,「如何讓國泰產險的產品更具靈活性,是推出電商式投保平臺的初衷。」國泰產險資訊系統開發部協理陳信良提到。
「打造碎片化車險平臺有兩大主軸,一是需要彈性化的中臺架構,讓產險可以快速發展通路;二是針對產險的核心後臺,進行保險產品碎片化。」國泰金控數數發中心首席架構師張維仁指出。
這是國泰第二次中臺架構大改造的成果。
第一次是設計國泰世華銀行的中臺,採用微服務(Microservices)架構和容器化(Container)技術、Kubernetes(K8s)管理平臺,在傳統銀行資訊架構中,帶進了中臺設計的作法,後來更發展出了數據中臺和業務中臺。
順利完成了銀行技術中臺設計後,國泰將銀行架構改造經驗,變成了一套架構改造範本帶到了金控,進一步套用到產險領域,也就是保險中臺新架構,碎片化車險專案就是第一個業務場景的應用成果。
國泰將銀行架構改造經驗,變成了一套架構改造範本,帶到了金控,進一步套用到產險領域,也就是保險中臺新架構,碎片化車險專案就是第一個業務場景的應用成果。(圖片來源/國泰金控)
碎片化車險導入七大新技術架構
國泰採用了七大新技術架構來打造碎片化保險中臺,包括了微服務、容器化服務、開發維運一體化(DevOps)、雲端運算、事件驅動架構(Event Driven Architecture,EDA)、領域驅動設計(Domain Driven Design,DDD),以及現代化網頁架構(Modernized Web)。
國泰將產險端從以往單體式且複雜的系統,拆分為多個微服務,讓每支服務都可重複使用並彈性組合成新應用。
國泰金控數數發中心企業架構師高華志提到,國泰在BeSafe系統建置了業務中臺,開發約700多支API,可彈性組成所需的軟體服務,以支援日益複雜的客戶服務管道。
在採用容器化服務部分,國泰在BeSafe系統建置了技術中臺,採用K8s為基底的管理平臺,讓系統的擴充更有彈性。並透過技術中臺集中化的系統監控機制,包含微服務日誌集中、微服務效能監控,以及系統效能監控,來強化平臺的穩定性。
陳信良則表示:「在異業合作上,透過API服務,從洽談到服務上線,從原本的6個月,縮短到了1個月。」
能做到比以往更快的速度,其中還有一個關鍵是團隊帶入了敏捷式開發,陳信良提到,當前端在洽談業務時,中臺、後臺核心也平行執行工作。所以,當業務需求一談完,後臺的商品設計,以及需對應到的API程式或中臺服務都可同時到位,就能往下一階段準備測試與驗收。
克服產險內部人員對新技術的疑慮
然而,在這碎片化車險專案,即便有了金控端技術的支持,陳信良坦言,國泰產險在這過程中仍面臨不少挑戰,像是內部人員對於新架構或技術如中臺、微服務等不熟悉,在心態上也對新技術抱有疑慮。「這是國泰產險轉換時,最需要克服的部分。」
為了克服這些障礙,國泰金控在導入新中臺架構的時候,先帶著產險人員實作,透過小成果的驗證,來讓內部人員逐漸接受。
比如,產險IT人員在核心系統改一支程式,從開發、測試到上線,過去可能需要2天時間,透過導入DevOps機制,現在2個小時就可以完成。
「這改變讓大家突然覺得有感,從原本的不相信變成懷疑,進而將小成果的案例分享給其他成員,認為這是一條正確的路,慢慢也有其他IT人員自願參與專案,想要學習新事物。」陳信良坦言。甚至,之後國泰產險內部更透過輪替、教育訓練的方式,讓每個人都可以達到同樣的層次。
在碎片化車險專案,國泰也持續導入DevOps機制,使用了CI/CD Pipeline將程式開發、測試與上線,透過自動化與可視化的方式快速部署,降低人工部署操作錯誤,且在部署時不會造成系統的停機維護。也使用自動化測試進行系統回歸測試,加強整體系統問題掃描機制,並確認系統服務品質(QA)無虞。
此外,國泰團隊採用了Git的程式版本控管,可透過標籤(Tag)的標註方式,鎖定多專案時的特定版次,彈性的合併與上線。以及,透過協同工具如Jira、Trello、Jitsi等,來強化來自金控、產險、協力廠商共50人以上的專案成員,在跨場域與居家辦公的同步協作與溝通。
拔對服務是上天堂,拔錯服務是災難
「拔對服務是上天堂,拔錯服務上中臺是災難。」張維仁認為,微服務中臺不是只有技術中臺,很大的比例是要將業務邏輯放進去。所以,如何正確將服務從傳統核心當中抽離出來,介接到中臺,國泰所採用的方法論就是DDD。
張維仁回憶,在2018年,國泰在第一次銀行新中臺架構建置時,以技術中臺為主,當時還沒有發展出業務中臺的設計,也還沒有碰觸到非用DDD不可的後臺議題。
所以,「國泰真正嘗試、突破,導入DDD的第一個實際專案就是車險,而且範圍不只中臺,還跨到了後臺。」他更強調,傳統大核心如何在新中臺架構,找出最大的相容性,誰也沒有替換掉誰,且能合作順暢的關鍵,就是DDD。
在專案初期,高華志指出,國泰進行DDD工作坊,將領域驅動設計的概念融入系統開發,藉此讓開發人員與規畫人員有共同的領域語言,並能溝通順暢。針對開發700多支微服務,則透過DDD的領域區分,進行權責的劃分,且設計出好維護、好理解且容易被業務調用的程式設計架構。
碎片化保險的第一個挑戰是如何「拆解」後端核心系統的業務,另一挑戰則是考量如何「組合」。國泰產險資訊系統開發部同仁透露,一開始,他們其實面臨了不知道要將哪些服務搬上中臺的狀況,在國泰這次的經驗當中,最後得出了2個面向來拆解。
第一個面向是由上而下,從通路端需求,或是客戶端需求來思考;第二個面向則是由下往上,從產險的資料庫,也就是數據資料中找出可以價值化的服務,或是從現有流程,抽取出可以共用的服務出來。透過這4種方式,拆解出哪些需要微服務化放上中臺的服務。
決定哪些服務要拆出來搬上中臺之後,下一個挑戰是顆粒度,要將服務切得多粗、多細?切太粗會像是一個大單體,切太細的話管理成本負擔會很重。
國泰產險資訊系統開發部同仁認為,這在DDD中,其實沒有一個指引或標準,得要每家公司或團隊各自認定。張維仁則建議:「正確地拆解微服務,設定出微服務的邊界,可以找出一個相對合理的顆粒度尺寸。
國泰將產險商品庫從核心拆解細化,再由中臺組合成保險套餐
若以業務層面來看微服務「拆解」與「組合」。張維仁表示,傳統核心是標準的商品庫、有商品代碼,所以,當要推出一款保險產品時,過去的流程是將商品代碼拉出來,打包成一包送主管機關審核、同意、上架。
現在的碎片化保險,張維仁比喻,像是把一臺車拆成許多部件,得把既有的商品庫從核心端細化搬上中臺,這時,就能由中臺來組合保險套餐。
由於每個商品仍有各自的商品代碼,所以,在中臺成立訂單後,再送到核心系統做保單立案、承保,仍可依照商品代碼對應到同一商品。
「碎片化產險核心這塊做完,就能將彈性化組合這邏輯放在中臺,產生出碎片化車險,快速組裝車險靈活性套餐。」張維仁說。
高華志進一步提到,套餐之所以在中臺組合,是因為保險商品碎片化後,顧客其實看不懂這些單一商品,也不知道如何挑選。所以,必須依照顧客食、衣、住、行、育、樂等生活場景,找出跟這些情境有關的風險,並組合成各式套餐供顧客選擇。
以保險商品來看,陳信良更舉例,國泰產險有一款專賣給餐飲業老闆的綜合保險產品,其中可能包含了商業火災保險、公共意外責任險等,所以得買不只一張保單,才能滿足需求。
以前,要打包多個不同的險種,得修改核心系統程式,開發工作非常的複雜。然而,現在不用每次修改核心,讓顧客也能在同一平臺中,就能自行挑選不同類型保險商品或是套餐組合。
以往,一張保單要算完保費、成本、核保項目、通算規則等,才有辦法對外販售。陳信良表示,整個流程碎片化後,變成好幾支微服務放到中臺,就能等顧客挑選完商品,甚至團隊也將投保的時序拆開,讓顧客有短天期投保的選擇,再透過微服務化後的試算功能計算保費,就連在電商式投保平臺的購物車功能,本身也是一個服務。最後,在中臺成立訂單後,再送到核心系統做保單立案、承保。
國泰提到,為了推出這個BeSafe平臺,他們將商品庫所有關於出門、出遊的險種資訊全部也放到中臺上來組合,才能打破先例,透過組合的方式,可在同一保單上,一次購足部分車險、旅遊險、寵物保險、手機保險等。
雖然在業務組合的複雜性上,確實會增加核心的複雜性,比如以前負責車險的程式,原本只要專心做好車險。現在,因為混合了不同險種,除了車險,還可能要開發部分旅遊、火險的功能。不過,陳信良表示,這些都是透過系統自動化對接並執行,對於後臺作帳、承保的人員來說,作業沒有增加。
從整體上來看,張維仁則強調:「在這碎片化保險專案場景中,中臺與後臺在邏輯上、交易上、合作上要建立機制,讓新中臺能夠包容傳統後臺,並溝通無阻。既可以讓中臺發展通路無止盡的要求,又能讓核心系統,可以回歸基本面的帳務功能,專注於後臺處理的角色。」
由國泰金控數數發中心(照片右半部)與國泰產險IT團隊(左半部)共同合作,打造了保險中臺新架構,將保險商品碎片化,在國泰產險新推出的電商式投保平臺BeSafe,實現彈性組合、短天期保障的保險創新模式。(攝影/洪政偉)
導入多種機制,強化量大交易的穩定與完整
為了強化量大交易的穩定與完整,高華志進一步說明,國泰在中臺導入微服務時,採用了Sprint Boot框架,並加入Spring Cloud OpenFeign框架的熔斷(Circuit Breaker)、重試(Retry)、負載均衡(Load Balancing)等機制。
他進一步解釋,熔斷機制是在瞬間量大時控制用量,以確保服務能持續提供;負載均衡的機制,則是要達到分時多工或是同時多工的方式;重試機制則是在中臺的訂單要轉為後臺的保單時,來確保兩邊的交易能完整一致。
此外,國泰在事件驅動架構上,採用Kafka設計架構,運用在中臺系統與核心系統的資訊串接與任務編排,目的是讓內部間跨系統資訊串接能更加即時與穩定。
而為了要讓中臺與後臺跨系統資訊串接時,也就是中臺成立訂單之後,串接到後臺核心系統時,確保兩邊的訂單筆數一致。高華志提到,他們還自行開發了巡檢機制(Patrolling Mechanism)。當核心系統執行時出現異常的狀況,可以自動化確認問題,通知人工介入處理,判斷是否需要進行重試的動作。
張維仁強調:「得確保中臺所處理的交易量,跟後臺核心正確接收到的交易量是對等的。只要一失焦,整個機制就毀了。」
他透露,國泰其實也曾擔憂,一旦中臺介入之後,會與後臺產生交易斷層,或者是後臺可能因為短時間內處理量過多或者是其他因素,導致交易筆數不正確時,就需要有檢核的機制。甚至,即便跨系統資料串接之間有異常發生時,也要能有平衡機制,即時修復成一致。「這些是中臺串接後臺,一定跑不掉的話題。」他強調。
使用防腐層作為中臺介接後臺的中間層,確保核心不受影響
國泰在這次的碎片化保險專案的設計概念,圍繞在新中臺架構的乘載量或新東西,不要影響到既有核心心臟的功能。所以,一名國泰產險資訊系統開發部同仁表示,盡量避免中臺與後臺的關聯度過高,以免造成同時毀掉的狀況。
因此,在中臺系統與後臺系統對接時,國泰使用了防腐層(Anti Corruption Layer)的設計概念,用這中間層來區隔中臺與後臺。一旦中臺有瞬間爆量的狀況發生,比如舉辦各式行銷活動時,就只會影響到中臺跟中間層,並不會影響到後臺。反之亦然,如果後臺有問題發生,也只會影響中間層,而不會影響到中臺。
國泰解釋,防腐層又分為兩種模式,一種是非同步式,系統允許中間有短暫時間可以執行。例如用佇列,當遇到爆量狀況時,後臺會依照運算資源,依序一筆一筆處理。
另一種是同步式,有些業務需要後臺系統即時確認的,比如需要即時通算保額不能過量的部分,就會在後臺另外建立API伺服器作為防腐層。同樣的,一旦這個API伺服器出問題,也不會影響後臺功能。
陳信良表示,透過同步、非同步機制,可以把中臺、後臺兩邊串連的很穩定,核心系統也不用大量修改,因為前端所有進件以及內勤打單的部分,流程跟以往是一模一樣。「核心系統人員不用因為前端變化,而調整新的流程。」他強調。
有了碎片化車險的第一個成功案例,陳信良指出,產險端只要是交易頻繁或是業務量多,需要大量承載的,包括來自客戶需求的產品,就交由前臺滿足,讓後臺維持穩定運行,這是國泰產險接下來的規畫。
熱門新聞
2024-10-05
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07