數位應用驅動IT再造 DevOps流程實踐及時上線

2019-09-09
為了因應外部市場的變化,在下一波數位化世代中贏得競爭力,資訊系統對於企業的意義也發生轉變,不僅用於提高營運效率,更是引領商業模式創新不可或缺的要角。以往軟體工程制定的流程、方法、工具,在業務需求驅動下加速演進,使得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展價值


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!