靖本

分享與交流知識和資訊是追求進步的第一步

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.

繼續閱讀
DevSecOps 成熟度模型(DSOMM)

DevSecOps 成熟度模型(DSOMM)

前言 隨著企業提升響應市場變化的速度,不管企業的規模為何,抑或屬於哪一種產業,DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下,由於傳統的安全治理較為繁瑣,也使企業在導入 DevOps 的過程中,從需求、設計、實作,到後續的監控和改善,較難看見充分的安全實踐,組織亦缺乏在每個流程階段,衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM? DSOMM 2 的全名為 DevSecOps Maturity Model(DevSecOps 成熟度模型),或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM(Software Assurance Maturity Model,軟體保證成熟度模型),SAMM 針對五個業務功能(治理、設計、實作、驗證、維運)定義了一系列的安全實踐及評量指標,協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型,而 DSOMM 則為更具體的 DevSecOps 實踐。

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

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

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

繼續閱讀