為了因應外部市場的變化，在下一波數位化世代中贏得競爭力，資訊系統對於企業的意義也發生轉變，不僅用於提高營運效率，更是引領商業模式創新不可或缺的要角。以往軟體工程制定的流程、方法、工具，在業務需求驅動下加速演進，使得DevOps躍升為當代顯學，打破以往開發與維運壁壘分明的隔閡，促進團隊之間的協同合作，讓建構、測試、發布軟體的流程，更加地頻繁與可靠，以貼近業務需求。
軟體開發流程從早期瀑布式，演進到Agile、Scrum方法論，乃至於如今炙手可熱的DevOps，核心精神皆在於加快價值的呈現。歐哲顧問技術長胡士亮說明，DevOps剛開始出現時，是由國際級大廠內部實作驗證，實現了每天平均可發布多達10次的版本更新，這在傳統開發流程中根本難以想像。事實上，許多軟體專案失敗的原因，正是因為從開發系統到實際上線提供價值的時間過長所導致。過去軟體公司的版本更迭週期大約是2到5年，問題是，2年前規畫的開發專案項目，在上線運行後卻發現市場需求已經轉變，促使開發專案的總時程必須得切分為多個發布階段，並且隨著市場變化調整規畫。
要達到這個目的時，若仍舊採用傳統方法，先經過完整的分析，才著手進入設計、開發、測試、上線，不可能短時間內完成，此時就會在不同階段中出現可協助縮短時程的工具。多年前探討的Scrum方法論，只是在分析、設計、開發階段進行加速，把瀑布式的開發週期，從以年為單位拆分成以週為單位，透過工作流程的拆解來實現。DevOps則是為了更進一步縮短流程，徹底解決軟體開發週期過於冗長的問題，讓軟體得以快速地上線產生價值。
歐哲顧問技術長胡士亮認為，開發者可創造營收，維運者則是可降低維運成本，長期來看對公司的貢獻度反而更高，只是得學習運用資源展現價值。
「概念上類似於新創公司的快速失敗（Fail-fast）理念，」胡士亮說明，意思是為了驗證想法的可行性，必須得快速地上線測試，例如藍綠部署、金絲雀部署等策略，亦整合到DevOps的管線（Pipeline）之中，以小規模的部署，再逐漸擴大，來加快實踐的速度，又不至於因為發生錯誤影響整體運行。
應用運行環境演進到容器化
回顧過去十年來IT技術的創新，Ayla Networks的DevOps架構師蘇培欣觀察，最實用的莫過於虛擬化（Hypervisor），把硬體資源予以統合後進行配置，提高利用率，降低過多的閒置資源。此後開始出現雲端運算應用模式，讓需求者得以簡單地方式取得，與此同時，大數據議題開始受到各產業關注，後續衍生出採用機器學習演算模型運行分析，以建立智慧來輔助有規則可循的人力操作。
Ayla Networks DevOps架構師蘇培欣指出，對於已工作多年的IT人員來說，學習開源陣營的技術堆疊沒有捷徑，必須得逐步累積，儘管技術更迭速度快，網路上大多找得到資源，一旦熟悉後即可降低學習曲線。
羽昇國際資深技術顧問陳鳴豪以Computing演變來說明，從硬體伺服器演進到虛擬伺服器，已從過去需數個月的採購與建置時間，大幅縮短到數分鐘內完成部署。近兩年雲端平台開始邁向容器環境，則是以秒為單位，擺脫作業系統的包袱，即可讓應用程式運行。對於DevOps團隊而言，應用系統架構於容器環境更可滿足持續整合、持續部署的速度，同時也減少作業系統的維運負擔。正在發展中的還有無伺服器（Serverless）技術，甚至可達到毫秒內完成部署與擴充。
相較於多數IT人員熟悉的Hypervisor技術，容器化的差異是基於NameSpace進行切割，且不再如同虛擬主機必須佔用固定的實體資源，能使堆疊數量大幅增加，啟用資源的速度又比虛擬環境更快，可以做到重複資料刪除（Dedup）功能。蘇培欣指出，多年前Docker剛開始出現時就有人做過實驗，在樹莓派的主機板上搭配ARM處理器，即可啟用超過2,000個容器。「主要因素在於Docker核心具有Thin Provisioning機制。基於NameSpace進行切割後，當第一個服務執行緒啟動運行，所有映像檔案都已經到位，後續再創建經由Snapshot即可，速度自然會加快。」
儘管現階段主流的公有雲平台為了提升安全性，底層仍舊是虛擬化環境為主。但是為了提高資源配置的彈性，以及提供更多新興技術，眾家服務供應商同時也提供容器技術，讓企業用戶得以運用虛擬化、容器化，來重新組合應用服務，打造現代技術的堆疊。當然如此一來，也讓IT人員變得更加辛苦，要學習的知識變得較以往更多。
K8S逐步強化自動化維運能力
在容器化環境中慣用的工具，蘇培欣引述RightScale 2019年度雲端調查報告指出，前兩名即為Docker與Kubernetes（K8S），現階段不論是公有雲服務供應商或自建部署解決方案，幾乎全數基於Docker搭配K8S所建構。「其實從Google搜尋引擎的趨勢圖也可看出K8S近年來的成長狀況，若IT人員排斥投入研究，恐怕不久後會發現跟不上世代演進。」
此外，在搜尋K8S時會一併出現的詞彙，首先是Docker Swarm叢集平台，儘管K8S幾乎已經統一了Docker叢集架構的資源配置與調度，目前仍有許多人沿用Swarm；其次則是Apache Mesos，知名的案例即為Twitter，藉此管理數萬台機器所建構的叢集環境；OpenShift、OpenStack自建的方案同樣擁有相當多的擁護者，只是OpenStack難度過高，除非企業內部組織具備龐大研發能量，否則恐怕很難駕馭。至於OpenShift，多年前的核心技術早已改版為K8S。
K8S之所以能夠在幾年內異軍突起，蘇培欣觀察，除了K8S源自於Google內部的開發專案以外，其設計定義的框架保留了許多彈性讓第三方廠商得以發揮，亦是成功吸引眾多IT廠商整合發展的重要因素。「K8S可說把近十年來所有IT技術予以融合，包含軟體定義網路與儲存、權限控管等機制，透過描述檔案即可運用。當然還有來自Google內部所採用的框架背書，以K8S為基礎控管全球伺服器，因此受到開放社群高度認同。實際上，Google會釋出K8S並非全然為了分享，背後的商業邏輯，在於藉此吸引全球用戶，建立可跨越異質雲端平台彈性遷移的特性，尤其是企業端，只要公有雲平台上有支援K8S，皆可遷移部署，不用再被既有的公有雲平台所綁定。」
對於IT人員而言，導入新平台的關鍵在於方便日後維運。K8S已經發展到具備一定的成熟度，日前再提出的Operator開發框架，不管是維運、告警通知等機制，都可藉此框架實作，幫助維運工作逐步轉換為自動化。
如今的K8S已可提供企業應用環境所需的功能性，即便應用服務原本部署在公有雲平台，可能因為安全性、資料保護等議題，欲遷移回到地端以完整掌控安全性，也有自建部署方案可實作。Google日前在Next年度大會中宣布推出的Anthos方案，只要網路、儲存等裝置架構通過驗證，地端也可建置雲端平台。企業端常見部署的Openshift平台，核心框架為K8S，亦可簡單地完成整合。
蘇培欣以實際帶領DevOps團隊導入K8S的經驗為例，由於Ayla Networks研發設計的物聯網平台，同時可提供自建部署與雲端服務，讓場域中所有連網裝置得以接取，為數以百萬計的連網裝置提供服務。對於需要提供大量即時連線、儲存龐大資料的平台而言，K8S的配置模式攸關運行穩定度。「當時的挑戰是把公司最大的客戶流量遷移到虛擬私有雲，必須得建置龐大的容器叢集環境，事前經過壓力測試可同時啟用250個節點，每個節點皆為16核心的運算能力，在此架構下才有能力承載。畢竟K8S為開放原始碼，要能夠承載大流量，勢必得經過調校。本來在改造之前，我們的物聯網平台幾乎是一開啟就停擺，如今具備的承載量則是屢次嘗試錯誤後的成果。自此後，部署時間已可從過去的一個月以上，縮短到最多兩天完成上線。」
善用資源跟進技術發揮Ops真價值
應用運行環境進入到容器世代後，技術堆疊主要來自開源陣營，對於已工作多年的IT人員來說，面對這麼多技術，且開源陣營演進速度又相當快，究竟該如何跟進？蘇培欣認為，這件事沒有捷徑，必須得逐步累積，而且網路上資源很多，雖然改變速度很快，在網路上大多找得到資源，只要緊跟相關新技術，一旦熟悉後即可降低學習曲線。當然，若可以投入到DevOps團隊，相信短時間內就得會有所精進。
胡士亮從實際輔導客戶轉型的經驗觀察，實際上在整個資訊部門中最重要的職務大多為開發者，IT通常是最不被重視的角色。過去在探討的DevOps工作流程，亦是開發者獲得最多的光環，維運相對較少。不論是DevOps、ChatOps、AIOps，或是擁抱雲端服務後撤除資料中心的NoOps，看起來Ops都像是可有可無的角色，但事實上並非如此，如今對於Ops的定位已大不相同。
企業之所以要組織DevOps團隊，主因在於開發者必須加速系統上線的頻率，前提是在開發流程不被壓縮的狀況下達到目標，此時就必須得靠工具技術、工作流程來輔助，才有能力實現加速。也就是DevOps流程中必備的持續整合（CI）與持續交付（CD），來幫助開發者解決問題。「過去的軟體開發方法，整合與交付並非同一個人完成，以微軟來說，區分為軟體開發工程師（SDE）與軟體測試開發工程師（SDET），後者是專門做測試。最後上線，則是交給系統工程師執行，主要想法是開發者不接觸線上系統，不同團隊各自執行專案任務，藉此相互勾稽。轉換成持續整合與持續交付流程後，則不再需要人力介入，較可確保安全性與合規性。」胡士亮說。
開發者之所以受重視，主要在於可創造營收，然而維運者則是可降低維運成本，長期來看對公司的貢獻度更優於開發者。胡士亮強調，「我反而認為OpsDev較DevOps更有價值。」只是台灣的Ops技能普遍未跟上時代變遷，並非Ops不夠認真，而是傳統維運人員普遍不受重視，並未被賦予過多的期待。
多數企業把維運定義過於狹隘，甚至認為雲端世代下根本不需要維運人員，實際上，只要有應用系統的企業或組織，即便是以最新Serverless技術開發所整合的應用，上線運行後皆需要交由維運人員控管，只是維運的型態持續在改變。胡士亮強調，身為現代的維運者或DevOps團隊成員，必須懂得掌握應用程式的執行階段行為（Runtime Behavior），「Dev角色就像是賽車的設計師與車廠，負責打造車子，把車子發揮最大效益的則是賽車手，也就是Ops，甚至可回饋有用的數據給車廠，藉此調整設計提升運行效率。只要善用現代工具之力，亦可彰顯維運本就具備的價值。」
【專題報導】：IT跨界合作 DevOps展價值