G 觀點

DevOps 實踐現況與回顧

DevOps 實踐現況與回顧

一些統計的數字… CloudBolt2 針對公司員工數大於 1000 人的組織進行了 DevOps 的現況調查,並且釋出了相關的統計數據3。DevOps 近幾年打得火熱,尤其在疫情期間對企業的自動化、流程改善、團隊運作起到了相當大的幫助。整份報告著重在自動化的調查,數字的確發人省思。以下為摘要: 只有 4% 企業認為自己在 CI/CD 的使用與實踐達到專家級別; 只有 5% 企業有能力單日數次發佈服務變更,然而 85% 企業發佈服務變更需要數天、數周或者更久; 只有 11% 企業認為自己的 CI/CD 流水線環境是可靠且受控; 有 88% 的企業表示正在考慮或已經使用 Terraform 作為基礎設施的發佈工具,然而卻只有 5% 的企業對於使用後感到滿意。 關於 Terraform 與 Infrastructure as Code Infrastructure as Code (基礎設施即程式碼) 的概念已經有 25 個年頭,而 2015 年 Terraform 甫一出現就吸引大家目光。

繼續閱讀
敏捷於疫情下對組織的助益

敏捷於疫情下對組織的助益

敏捷在疫情中,為企業帶來了什麼實質的影響? 從麥肯錫2的兩項調查統計來看 在客戶滿意度、員工參與度、與營運績效來看,在同一企業內,敏捷程度較高的部門表現顯然優於敏捷程度較低的部門。 基於亞洲與歐洲電信運營商的組織應變速度來看,敏捷成熟度最高的組織較成熟度最低的組織有著近兩倍的差異。 不可諱言地在疫情前,轉變對於組織來說,並不必然是極為迫切的事情。因為市場變化雖然強勁,但壓迫力卻並非立即性地逼得企業喘不過氣來。疫情來臨時,交付管道的失效、聯繫方式的失效、工作空間的失效等等問題,讓供需兩方彼此交互增強對於變動的需求。敏捷基本上是想找尋一個系統性的方式來解決最終結果的不確定性。畢竟,商業環境唯一不變的真理就是改變。 從疫情中過渡到後疫情 對於組織來說,什麼才是所謂「系統性」的方式? 這就得同時從團隊層級與企業層級兩個不同層級來探討,畢竟敏捷並不是組織內某個單位的事情,而所謂的文化改變,也不可能忽略組織的營運與治理。但不管哪一個層級,以敏捷的角度來看有兩件事是重要的: 1. 貼近於現實的可調適能力; 2. 可視性。 透過看板、電子協作工具,以及基於上述工具的指標儀板,組織才能在霧濛濛的不確定性市場中具備視覺能力。有了這些視覺能力,組織才能夠以更為全面的視角,客觀地衡量現況,進而調整自己的步伐。具備了這項基礎的能力後,才能讓調整步伐的能力有效展現。這就會回到了「如何實際地讓自己具有貼近於現實的可調適能力」這件事上。具體作法不外乎是 企業層級能夠盡快響應市場變化,調整方針與重要項目;團隊層級能夠基於這些改變的方針與實際場景的差異,具體地進行微調,來達成目標。 為了能夠做到這些事情,企業必須要思考的不會是如何帶入別人成功的套路,而是要去反思當前的營運模式、流程與治理方法。 企業作為一個法人,正如同自然人一般。面對外部刺激的反應,可以從大腦下達指令,然後產生相關反應,也可以在一些「特定條件」下,「授權」各部位直接採取行動。不管是從大腦下達,抑或是特定條件下的授權行為,為了能夠更有效率且無誤地發生效果。需要的不只是應急措施,更重要的是能夠重複的「成功規則」。因此,在得益於敏捷的實務作法,而在此次疫情中獲益的組織,在疫情之後,應該要去思考的是: 1. 疫情中採取了哪些應該持續下去的改變,還有哪些問題並未被解決; 2. 匯整經驗,融入日常營運,並且強化與擴大這些經驗的成熟度與覆蓋度。 後記 敏捷不僅是一種方法,也是一種能力。面對疫情所帶來的紛亂,提升企業的敏捷能力,便是提升企業韌性的最好策略。 1. Photo by Elena Mozhvilo on Unsplash 2.

繼續閱讀
DevOps 工程師 - 實踐價值的道路

DevOps 工程師 - 實踐價值的道路

在過去帶領 DevOps 團隊的經驗裡,有時會遇到團隊成員對於身為 DevOps 工程師的價值有所疑惑或迷思: 🤔 我們好像只是在做各種工具的整合…是不是要像開發人員一樣寫程式,這樣才比較厲害!? 🤔 是不是要像開發團隊一樣面對市場客戶的需求,這樣才能產生價值的交付? 🤔 是不是打造完工具鏈,DevOps 團隊就不需要存在了? 本文同步刊登於 DZone - Addressing Concerns About Being a DevOps Engineer 認真做好每一樣事物,這才是工程 在工程的世界裡,每個領域絕對都有它專業價值的存在,只是使用的技術、工具及面對的客群不同。雖然各種 IaC 或 XaC 的工具,不像廣為人知的 Java、TypeScript、Python 等程式語言,但在撰寫的過程中,仍然需要基於邏輯地去考量彈性度、模組化等,以及如何透過測試維持品質。有時更因為它是基礎設施或與合規相關,所以相顯之下它所衝擊的範圍也較為龐大,而需更加謹慎。且在五花八門的工具世界裡,選擇一個適合您組織文化、流程、團隊技術線的解決方案,也是個大哉問,不落入貨物崇拜尤為重要。因此,只要保持好奇心、積極的態度,把事情做對,不論背後所採用的技術為何,這就是工程的美妙。

繼續閱讀
全面轉向 CentOS Stream,憤怒了嗎?

全面轉向 CentOS Stream,憤怒了嗎?

去年底公佈 CentOS Stream 來替代 CentOS1,也就是說原先的 CentOS 的發佈版本終於迎來它的終焉之時。 簡言之,CentOS 原先作為 RHEL 釋出後的開源版本,如今將重新定位在 Fedora 與 RHEL 釋出之間,成為 RHEL 釋出前的版本,也因為這樣的位置重置,讓原先 CentOS 的用戶立馬就吵翻了天。 不開心! 為何? 先不論是否背叛了開源社群,或者是因為誰而促使這樣的狀況發生。造成這樣的不適感,筆者認為最大的原因有二: 已如理所當然的長期免費資源,如今不再這樣可口。 除 CentOS 6 與 CentOS 7 仍按照原先生命週期外,CentOS 8 並不會按照原先預期的約定,直接改止於 2021 年底。這讓已經投入 CentOS 8 轉換且以此展開產品發展計劃的個人或企業,直接面對這突如其來的變化,反應可想而知不會太好。 關於第二點,雖說按目前軟體發展的模式,尤其紅帽這類大型公司,在持續測試整合上的能力已經相當成熟,不管是相容性與主次版本的相關測試案例,應該都能提供對應的保障,但是一聽到是先於企業版本的發展版本時,誰又願意進一步嘗試或者是相信呢?CentOS Stream 並非突然在 2020 拔地而出,而是在 2019 年時便已經問世,開源使用者固然有關注的義務,然而突如其然的轉換聲明,使用者溝通上顯然不足。不過說到此處,基於第一點,說實在很難找到兩全的方法。或許紅帽能為一些先於RHEL釋出的新功能,提供一些開關,讓使用者對於過新的變化至少有個簡便濾除能力。

繼續閱讀