敏捷與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 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下，由於傳統的安全治理較為繁瑣，也使企業在導入 DevOps 的過程中，從需求、設計、實作，到後續的監控和改善，較難看見充分的安全實踐，組織亦缺乏在每個流程階段，衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM？ DSOMM 2 的全名為 DevSecOps Maturity Model（DevSecOps 成熟度模型），或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM（Software Assurance Maturity Model，軟體保證成熟度模型），SAMM 針對五個業務功能（治理、設計、實作、驗證、維運）定義了一系列的安全實踐及評量指標，協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型，而 DSOMM 則為更具體的 DevSecOps 實踐。

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