由於技術的發展，我們可以更快、更好地完成每件事，而且資源消耗越來越少。我們可以在每個行業中看到這一點，但毫無疑問，IT 是該領域的領導者——正在開發新的工具和方法，包括 DevOps。這是什麼？
什麼是 DevOps？
雖然這種方法最近比較流行，但它在 IT 界並不新鮮。早在 2009 年根特的一次會議上就曾討論過這個問題，該會議開啟了一系列名為 DevOps Days 的會議。他的主要建議是改善開發和管理團隊之間的溝通和協作。因此這個名字結合了開發和運營（eng. Development & Operations – “開發和運營”）。
DevOps 發生了什麼變化？
在應用這種方法之前，負責項目實施的兩個主要部門有不同的優先事項和目標。開發人員希望盡快完成編程工作並在客戶現場實施軟件。然而，這一政策違背了行政部門的利益，行政部門更願意將代碼更改的次數控制在最低限度。
這種工作模式的結果是什麼？更多的錯誤、更多的交付時間和成本，以及交付產品的質量下降。每個人都失去了：公司、員工和最終用戶。
解決方案是將兩個部門合併為一個團隊，其成員相互分享他們的知識和發現。這就是 DevOps 最初的運作方式，小公司現在正在以這種形式實施它——管理員熟悉生產知識的基礎知識，開發人員在支持領域培養能力。
另一個變化是對流程自動化（測試、分析、實施和監控）和雲基礎設施的興趣增加，這已成為 DevOps 不可或缺的一部分。 IT 界不僅獲得了一種非常實用的方法，而且還獲得了廣泛的新工具和技術。運營模式的改變如此有效，以至於更多的公司正在實施，市場上出現了一個新的職位——DevOps 工程師。
迭代工作模型
我們欠 DevOps 的一個非常重要的修改是用迭代模型替換瀑布工作模型。這是什麼意思，有什麼好處？ “傳統”或級聯繫統將項目實施過程分成不同的階段，一個接一個地進行。重要的是要注意，為了開始項目的下一階段，您必須首先完成前一階段的所有任務。該模型已被證明是有問題的，因為如果在實施的早期階段需要修改，則必須完成所有後續步驟。
還注意到在實施過程中，客戶期望發生了變化，這迫使團隊進行了多次修正。正如你可能猜到的那樣，花費了大量的時間資源，結果，最終的效果遠非完美。
這些缺點在迭代模型中被消除了。最初，這裡只做了粗略的假設，稍後在實施過程中進行檢查和完善。此外，與其等待所有工作完成，不如儘早提交和測試代碼片段。因此，團隊可以快速響應可能的變更需求，最終結果完全符合當前客戶的期望。
DevOps 適合誰？
這種方法的最大受益者是其運營需要對產品基礎架構進行頻繁但不一定是重大更改的組織。
DevOps 有前途嗎？
決定實施 DevOps 的公司對這種方法的看法遠不止自動化和工作文化。他們明白，贏家是比競爭對手工作得更快、更高效、結果更好的供應商。因此，統計數據顯示，例如 77% 的美國企業在實施過程中宣布使用 DevOps 或在不久的將來有這樣的解決方案也就不足為奇了。
