3.6　DevOps

3.6.1　DevOps的誕生

我們從背景說起。

近年來，軟件發布的形式發生了巨大的變化：過去常常是刻一張光盤，用戶自己來安裝軟件。而現在越來越多的是提供在線服務，用戶通過網頁瀏覽器、移動端應用等來連接和使用在線服務。這樣的在線服務，背后常常是一個運行在多臺甚至海量服務器上的復雜的分布式系統。這就意味著如果想要發布軟件，就需要做與運維相關的一堆事情。

于是就會成立相應的Ops（運維/技術運營）團隊，與Dev（開發）團隊相互配合。要上線了，Dev團隊把一包東西從“墻”的這邊扔到“墻”的那邊，Ops團隊接著把它部署上線。由于Dev團隊的根本目標是開發出新特性并把它們發布上線，而Ops則特別關注線上運行的穩定性，不希望有任何風吹草動，所以這兩個目標不同的團隊配合起來就特別擰巴。

那怎么辦呢？打破隔閡，加強協作，協作好了就是DevOps。回望從瀑布模式到敏捷模式的轉變，其實質是在很大程度上打破了Dev和QA（Quality Assurance，質量保證，這里指測試）之間的“墻”，讓協作更順暢。而DevOps進一步打破了開發、測試與運維之間的“墻”，讓Dev、QA、Ops甚至Sec（Security，安全）等更多角色、更多工作協作得更順暢。這需要從組織結構方面想辦法，從文化方面想辦法，從工具和流程角度想辦法，等等。這么一整套解決辦法，就是DevOps。

3.6.2　DevOps三步工作法

DevOps三步工作法[10]是DevOps的重要方法論。

“第1步，實現開發到運維的工作快速地從左向右流動。為了最大限度地優化工作流，需要將工作可視化，減小每批次大小和等待間隔，通過內建質量杜絕向下游傳遞缺陷，并持續地優化全局目標。

第2步，在從右向左的每個階段中，應用持續、快速的工作反饋機制。該方法通過放大反饋環來防止問題復發，并能縮短問題檢測周期，實現快速修復。通過這種方式，我們能從源頭控制質量，并在流程中嵌入相關知識。這樣不僅能創造出更安全的工作系統，還可以在災難性事故發生前就檢測到并且加以解決。

第3步，建立具有創意和高可信度的企業文化，支持動態的、嚴格的、科學的實驗。通過主動承擔風險，不但能從成功中學習，還能從失敗中學習。通過持續地縮短和放大反饋環，不僅能創造出更安全的工作系統，還能承擔更多的風險，并通過進行實驗幫助自己比競爭對手改進得更快，從而在市場競爭中戰勝他們。”

3.6.3　DevOps落地實踐

2009年，一場名為“10 + Deploys Per Day: Dev and Ops Cooperation at Flickr”的演講[11]被認為是DevOps萌發的標志。這場演講在DevOps的落地實踐方面，主要涉及自動化基礎設施、共享的版本控制、一鍵完成構建和部署、特性開關、共享度量統計、即時通信機器人這六種技術手段，以及尊重、信任、對失敗的正確態度、避免指責這四個文化方面的要素。再后來，不斷有新的方法和實踐被添加到這個工具箱中。而工具箱的名字，就叫DevOps。

想當年敏捷興起時，敏捷的概念和范圍不斷擴大。2010年，Ivar Jacobson在一篇博文中說，“過去你問我支不支持敏捷，我會說哪些支持，哪些不支持，并給出我的理由。但現在你再問，我就只能回答支持。因為，如今敏捷的意思已經演變成‘軟件開發中一切好的東西’。”

DevOps也一樣，它在吸納越來越多的東西。比如把安全涵蓋進來，甚至為此有了一個新名詞——DevSecOps。如今，在DevOps協作框架下，安全防護是整個IT團隊的共同責任，需要貫穿于整個軟件生命周期的每一個環節。

現在DevOps越來越變成軟件設計、開發、集成、測試、發布、運維、安全中一切好的東西的集合。那好的東西從哪里來呢？好的東西很多都是從軟件工程來的，從敏捷和精益來的，從持續集成、持續交付來的，從容器化、微服務、云原生來的。DevOps逐漸變成了一個標簽和代稱，實質上是在講，如今軟件設計、開發、交付、運維該怎么組織。