DevOps這個詞流傳甚廣，對它的理解也因人而異。Jez Humble將其定義為一種系統的操作方式，所操作的系統具有快速變更的特徵，例如I.E.，CI/CD，快速反饋環等。還有人將它定義成操作人員，他們使用開發人員的樣式來更加快速的執行和部署應用。但在很大程度上的事實卻是：存在一種偽共識，認為DevOps與開啟組織敏捷性有關係。卻沒有提及敏捷對不同的組織會意味著不同的東西。從組織的角度來看，我認為DevOps沒有規範的實現方法。如果這麼說有點難以理解的話，讓我進一步展開。因為語言對不同的人有不同的含義，所以我要在這裡做些說明，概述一下我所說的“不同的實現”是什麼意思，但不提供我個人的觀點。一個組織通常有以下幾個關鍵點：團隊管理的基礎設施 VS 集中式管理基礎設施團隊有自己的基礎設施嗎？還是有人在中間專門提供執行？如果是前者，開發團隊是否必須學習運維？意味著開發人員是否要對自己的基礎設施負責？他們是否需要隨時保持響應？他們是否可以以任何想要的方式執行他們的應用？而如果是後者，那麼是否意味著有一個專職的操作團隊？意味著開發人員是否只需關註自己的應用？那非工作時間的應用支援怎麼辦呢？換個角度，如果不清楚問題的根源是應用程式還是基礎設施時，怎麼辦呢？選擇一種技術時，存在組織預設和指引嗎？您的組織是否偏好某一組特定的技術？如果組織沒有任何預設意見，是否意味著團隊可以執行任何想要的東西？如果是這樣，是否有一種機制確保任何人都知道每個人在做什麼？當外部團隊從安全性或可用性的角度影響了某個服務時，如何看待責任問題？如果組織有某些預設意見，如何判斷一個團隊是否可以偏離？如果一個團隊決定偏離，決策人員是否有足夠的背景關係資訊（業務和技術）來做出決策？我們又如何確定以上的資訊？如果組織有特定的要求，這是否意味著有業務單元會在更新、更好的技術選擇上進行創新？如果是，他們可獲得足夠的支援嗎？相反，其他團隊的交付速度是否會成為瓶頸？以上選項資訊，我們會根據我們認可的價值和對事物的評價選擇其中的某個選項。
知識星球
朋友會在“發現-看一看”看到你“在看”的內容