一些統計的數字…
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 甫一出現就吸引大家目光。
過去的基礎設施的佈建多半混雜著腳本與大量的使用者介面操作，並且透過繁雜的使用手冊來進行維護。當服務越來越多且越複雜時，人工錯誤就越難以避免。這些阻礙會大大降低企業進行變更與反應市場的能力。當事故與災難發生時，此類問題所帶來的影響就變得更為棘手。基礎設施即程式碼就是透過程式化的方式，來降低複雜操作對於操作者的壓力，不僅提高系統的可靠度，也讓管理能夠借用相對成熟的軟體管理方法，來提高管理服務運營資產的掌控力。然而一個根本的問題是私有雲環境的資產複雜(軟硬體資源的多元性)。因此不難理解採用這些自動化工具時，可能面對的是無法自動化或者是沉重的客製整合，而這些問題也會進一步浮現在 CI/CD 的流水線建置上！
流水線的運行資源往往需要更為隨需的配置，以便達到更好的資源運用
比方說需要手動先行配置資源進行專案特有的驗測程序或者是當驗測完畢且服務建置後的資源返還。上述問題都還尚未討論到治理與管理的問題，比方說 「誰能佈建資源?」、「成本花用狀況與監控」等，而另一件更讓人傷腦袋的事情是「人員技能的更新」…
回歸問題的本質
工具、技術採用、正在面對的問題其實都只是一個結果。最根本問題仍然得回到 — 組織目標與人
組織的既有資產是一個既定的事實。私有雲、公有雲、或混合雲的選擇會受到技術穩定度或者是法規需求等因素影響，而有時的選擇甚至是不得已為之的決定。另外，即便是同質資產(比方說虛擬機器)也會因為當時的背景，而導致版本與工具上的不一致，更甚而產生不相容的問題。因此，當新技術襲來與市場持續變化，企業必須正視的問題是
自身的目標與策略應該如何調整?
若企業未能正視這個問題，改變也總是停留在團隊層級。那麼不僅上述的調查發現會降臨在自身組織上，還會進一步導致錯誤發生頻率不減反增、員工滿意度下降、與變革疲勞等等問題。這也正是 DevOps 相關推廣者常常呼籲的面向 — 文化問題。
文化一詞聽起來浪漫，但其實組織文化是由明確的規定或者是潛在的約定作法形塑而成，並且體現於成員的行為上。不管是明確的規定或者是潛在約定作法，這兩者都會受到組織政策的影響，而組織政策就是來自於目標與策略。
因此，基於上述的內容與探討。對於正在積極尋求或正在改變的企業，本團隊有以下建議：
- 重新審視組織的策略，至少是 IT 的策略
- 注重人員的訓練與意識的改變
- 不要只想者抄成功經驗，重要的是當前最優先的事項是什麼? 痛點是什麼?
- 尊重專業做法，但建立有效的指標
- 適度鬆綁決策流程，但留下稽核軌跡
- 審視、激勵與持續改善當前作法
後記
真正需要被解決的困難，總會迎來真正的解決方案。企業面對變動的商業環境，新技術的引入既會帶來市場優勢，也會帶來改變的痛苦。明確的目標設定與持續改善聽起來雖然平淡無奇，但對於永續經營的企業來說，卻是最務實的做法。