在全球IT領域擁有最多專利技術的IBM，近年來積極輔助本土企業實踐數位化營運模式，基於IBM Cloud Garage方法論，為企業建立正確的DevOps文化、釐清營運業務遭受的挑戰，並且解決持續整合、持續交付的Pipeline過程中無效率的環節，幫助企業把既有應用系統現代化，甚至是邁向數位化轉型。
IBM雲端副總經理張瑞源指出，實際上IBM自家提供的軟體，不論是主從式架構或多層次架構，為了因應DevOps時代到來，經過多年研發幾乎已經全數容器化，實踐Agile、Scrum的精神，以快速因應市場需求，尤其是雲端服務，才可藉此跟進市場變化的速度。
「如今的IBM已經可引領數位化應用進入第二篇章，讓無所不在的人工智慧，協助客戶轉型為認知型企業。」張瑞源強調。只是台灣人務實的文化，面對新興技術大多會抱持觀望的態度，即使願意嘗試也僅止於試驗階段。直到近幾年面臨市場快速變遷，營運業務遭遇到前所未有的挑戰才著手實踐，開始把原本內部進行測試的專案逐步商業化，腳步較快的企業甚至正式組織DevOps團隊，基於Agile或Scrum方法論，來發展新型態的應用服務。
打造最小可行性產品測試市場反應
基於現代化工具與開發思維，確實得以因應市場變化快速地提出新服務。張瑞源觀察，尤其是銀行業者，正積極地把傳統核心應用系統轉變為現代化，並且利用雲端原生與DevOps工作流程來發展新業務。
他進一步說明，啟動轉型的第一階段是引進現代化的管理模式，首先必須先接受雲端服務，也願意把應用系統部署於雲端平台。心態較保守的本土企業如今對於公有雲或私有雲的應用模式接受度增高，只是傳統應用系統轉換為現代化的過程中，往往不知如何從業務層面到IT層面，乃至於整體維運，皆得以實踐。「IBM提出的Garage方法論，如今已成為企業雲端化的代表品牌，讓企業依據最佳導入實例建置應用場域，由IBM專家團隊來指導驗證，創造商業可運行的模式，再逐漸轉變成為標準化。」
探討多年的數位轉型，不論是工業4.0、物聯網等新型態應用，可藉由Garage方法論整合營運部門與IT部門，讓業務的決策更貼近市場需求，從中找出MVP（最小可行性的產品）。經由持續不斷循環的方法，探索企業核心價值的需求，再進行開發，並且測試市場反應，確認可行性。
「就如同漏斗，把利害關係人發散的想法逐層聚焦，最後產生MVP，所採用的技術手段，即是運用容器環境建立地端與雲端的共通性，進而落實到企業內部與對外的營運服務，之後進入維運階段，接收外部顧客與內部使用者的回饋，再加以改進，逐步實踐數位化商業模式。」張瑞源說。
吸取轉型成功經驗重拾市場競爭力
IBM之所以提出Garage方法論，主要是著眼於雲端原生的應用趨勢，勢必將扭轉既有產業的商業模式。IBM Garage團隊必須把企業端的想法先予以聚焦，運用現代科技技術的手段具體化落實產生最小可行性的產品，之後由IT領域專家接手，例如教導開發者採用現代工具來達到可視化，分析產品發布於市場後的反應，以便及時調整加快回應速度。
張瑞源指出，過去開發團隊鑽研於Agile、Scrum方法來增進敏捷性，讓軟體、系統皆得以具備彈性擴充的能力，問題是這種溝通模式主要是工程師層面，只有技術專家能夠理解。然而，如今企業面臨的轉型，實際上是進行組織再造，必須得打破職務與部門的藩籬，統整高階管理層、業務單位一線員工、IT部門，共同確立共識並討論可發展的方向，之後再交給開發人員來落實想法。
只是以往的瀑布式開發模式，完成需求單填寫後，進入開發階段，少說要一年半載才得以完工，現代商業市場變化速度之快，類似的競爭服務項目，可能兩個月時間就已經在市場上出現，如此一來，勢必得最大程度縮短開發生命週期，促使企業不得不有所改變。
Garage方法論提出新的設計思維，圍繞三個階段實施來協助企業因應。初期是共同創造未來，讓利害關係人參與且取得共識，並且在過程中設置多個查核點來確認需求。其次是共同執行，來自不同功能性的部門成員，組成專業小組來共同落實發展MVP。第三階段是進入維運期，必須依照應用程式場景、基礎架構場景，共同執行維運工作。
前述的三個階段是指導原則，至於達到目的的手段相當多，其中企業文化可說扮演相當重要的角色，須藉由高階管理層的加入來共同推動。近幾年許多企業的高階管理層普遍面臨到外部競爭對手壓境導致獲利逐漸下滑，自然也寄望能藉由開創新商業型態重拾競爭力。國際間企業轉型成功的案例，正可成為本土產業的借鏡。
人、流程、工具全面轉型
在企業進展到實作MVP階段時，可以由內部團隊執行，或交給IBM輔助。另一方面，亦可借助最佳參考範例，以及實作的方法，把運行時日已久的舊式系統，例如銀行業的核心金融系統，逐階段轉換為雲端原生方式開發，IBM顧問團隊可共同加入DevOps團隊，依據IBM在國際間蒐集整理的知識與經驗，協助企業把既有的工作流程轉換到新型態應用環境中執行。
「現代備受注目的DevOps、雲端原生開發、多雲平台部署等新興模式，實際上皆無法擁有一套通則可依循。目前來看台灣以金融業較有機會先在IT演化過程中歸納出實作法。」張瑞源說。過去多年來關注DevOps議題主要為新創公司，在本土環境中逐漸發酵後，如今也開始影響到所有產業，若得以有實戰經驗豐富的廠商協助，可讓企業更有信心開展轉型之路。
畢竟DevOps牽涉到人、流程、工具，並非僅為IT部門而已。人的部分實際上就是企業文化；流程則是依據企業文化所建立的工作程序，不論是人工或自動化作業，一旦方法過時，就必須得採用新模式；至於工具，則是建構穩定、安全的底層環境，讓應用服務得以於此平台之上呈現價值，如此的技術工具才算合適。
就Kubernetes在IT領域興起的態勢來看，原本應用系統的架構是前端呈現層、中介軟體層、後端資料庫系統所組成，如今全數可被打包封裝在獨立的映像檔，原本單台應用伺服器變成許多小積木堆棧而成，勢必得讓整個開發流程增添透通性，促進團隊彼此得以協同合作，降低無效率的重複查驗程式碼。當程式碼簽入／簽出版本控管系統，執行Build完成之後進入自動化測試，團隊成員皆得以掌握每一步執行動作，直到產品生命週期結束。
搭建開源工具鏈強化團隊協同合作
現代企業積極發展的雲端原生應用，特點在於擁抱開源社群技術，基於全球技術菁英參與貢獻，使得近年來企業或組織也改變非商業版不用的態度，開始採納開源工具來輔助DevOps，並且接受工具鏈的動態改變。
就DevOps運用開源工具鏈所建立的Pipeline來看，流程大致可分為Build、Ship、Run，持續整合、持續交付主要是落在Build、Ship階段，當Docker環境要拉回映像檔時，必須得有查核安全漏洞的機制，以降低潛在資安風險。整個Pipeline流程可選用IBM中介軟體、開源工具，甚至是自行開發的實作法，完全不會有廠商綁定的問題。只是選項過多，對企業而言同樣困擾，因此現階段仍舊得由專業廠商輔助搭建最佳組合模式。
到了開發階段，隨著成員熟悉的Node.js、Java等程式語言不同，採用的工具也有差異。張瑞源說明，在程式碼簽入到IBM Microclimate開發環境的版本控管系統後，可直接透過Apache Maven建構工具執行，或是交由Jenkins來測試與封裝映像檔，進而部署到容器環境，即便是異質開發語言，也可以透過開源套件或自行撰寫的Script相互整合運行。在部署之前，亦會要求持續整合階段必須實作自動化檢查程式碼功能與壓力測試。至於監看日誌、資源狀態、告警等服務，這方面則是Kubernetes可以協助之處。
IBM雲端副總經理張瑞源指出，面臨轉型需求卻不知從何著手的企業，可借助IBM提出的Garage方法論，先依據最佳導入實例建置應用場域，由IBM專家團隊來指導驗證，創造商業可運行的模式，再逐漸轉變成為標準化。
張瑞源強調，現階段企業採用雲端服務主要會遭遇到的挑戰，在於內部許多執行不同工作負載的系統遷移問題，欠缺外部眾多異質技術的公有雲服務供應商評估標準，以及雲端原生與傳統應用系統之間的知識落差。他建議，欲著手遷移時，必須讓既有系統做到只要Build一次，即可部署到多種雲端平台，並且建立可視化能力，以便於執行治理與安全性，保護分散式工作負載。針對知識方面的落差，則可透過實作驗證找到最佳方法，如此才得以在效率低落的環節中利用合適工具來改善。
CSMO專家維運確保營運服務水準
至於DevOps團隊的技能，若把應用系統區分為商業功能與非商業功能，開發人員比較偏重在商業功能的角色，依照用戶端需求制定發展走向，所以通常是Dev方需要負責。至於人才市場中新興的SRE（網站可靠性工程師），則比較偏向非商業功能的職責範疇，只是IBM並未正式採用SRE的用語，而是稱為CSMO（Cloud Service Management and Operation），統整了DevOps、ITIL應用服務管理，以及SRE，評估的準則就如同雲端平台強調的服務水準協議（SLA），例如目標是「五個9」，從整體架構的設計來達到目的。
針對意外事件、系統異動等緊急狀況，究竟是由一線或二線工程師負責，IBM設計出RACI（Responsible、Accountable、Consulted、Informed）矩陣，定義出在維運團隊中各自的職掌、對工作當責的人、團隊中可詢問的角色，以及報告工作狀況的對象。「現階段台灣可能尚未出現類似的職務，畢竟我們Cloud Lab是國際級團隊，已經有設立SME（Subject-matter Expert）的角色，由領域專家專門執行CSMO，進而基於過去完成雲端服務導入建置專案經驗，來輔導更多的企業。」張瑞源說。
【專題報導】：IT跨界合作 DevOps展價值