提到DevOps這個詞，我相信很多人一定不會陌生。
作爲一個熱門的概念，DevOps近年來頻頻出現在各大技術社區和媒體的文章中，備受行業大咖的追捧，也吸引了很多喫瓜羣衆的圍觀。
那麼，DevOps是什麼呢？
有人說它是一種方法，也有人說它是一種工具，還有人說它是一種思想。更有甚者，說它是一種哲學。
越說越玄乎，感覺都要封神啦！DevOps這玩意真的有那麼誇張嗎？它到底是幹嘛用的？爲什麼行業裏都會對它趨之如騖呢？
今天這篇文章，小棗君就和大家好好聊一聊這個DevOps。
DevOps的起源
這個故事有點長，從頭開始講起吧。
上個世紀40年代，世界上第一臺計算機誕生。從誕生之日起，它就離不開程序（Program）的驅動。而負責編寫程序的人，就被稱爲“程序員”（Programmer）。
程序員是計算機的駕馭者，也是極其稀缺的人才。那個時候，只有高學歷、名校出身的人，纔有資格成爲程序員，操控計算機。
隨着人類科技的不斷髮展，PC和Internet陸續問世，我們進入了全民擁抱信息化的時代。越來越多的企業開始將計算機作爲辦公用的工具，用以提升生產力。而普通個人用戶也開始將計算機作爲娛樂工具，用以改善生活品質。
於是，計算機的程序，開始變成了一門生意。程序，逐步演進爲“軟件（software）”，變成了最賺錢的產品之一。
在軟件產業裏，程序員有了更專業的稱謂，叫做“軟件開發工程師（Software Development Engineer）”，也就是我們常說的“碼農”。
我們知道，一個軟件從零開始到最終交付，大概包括以下幾個階段：規劃、編碼、構建、測試、發佈、部署和維護。
最初，程序比較簡單，工作量不大，程序員一個人可以完成所有階段的工作。
隨着軟件產業的日益發展壯大，軟件的規模也在逐漸變得龐大。軟件的複雜度不斷攀升。一個人已經hold不住了，就開始出現了精細化分工。
碼農的隊伍擴大，工種增加。除了軟件開發工程師之外，又有了軟件測試工程師，軟件運維工程師。
分工之後，傳統的軟件開發流程是這樣的：
軟件開發人員花費數週和數月編寫代碼，然後將代碼交給QA（質量保障）團隊進行測試，然後將最終的發佈版交給運維團隊去佈署。所有的這三個階段，即開發，測試，佈署。
早期所採用的軟件交付模型，稱之爲“瀑布（Waterfall）模型”。
瀑布模型，簡而言之，就是等一個階段所有工作完成之後，再進入下一個階段。
這種模型適合條件比較理想化（用戶需求非常明確、開發時間非常充足）的項目。大家按部就班，輪流執行自己的職責即可。
但是，項目不可能是單向運作的。客戶也是有需求的。產品也是會有問題的，需要改進的。
隨着時間推移，用戶對系統的需求不斷增加，與此同時，用戶給的時間週期卻越來越少。在這個情況下，大家發現，笨重遲緩的瀑布式開發已經不合時宜了。
於是，軟件開發團隊引入了一個新的概念，那就是大名鼎鼎的——“敏捷開發（Agile Development）”。
敏捷開發在2000年左右開始被世人所關注，是一種能應對快速變化需求的軟件開發能力。其實簡單來說，就是把大項目變成小項目，把大時間點變成小時間點，然後這樣：
有兩個詞經常會伴隨着DevOps出現，那就是CI和CD。CI是Continuous Integration（持續集成），而CD對應多個英文，Continuous Delivery（持續交付）或Continuous Deployment（持續部署）。
美其名曰：“持續（Continuous）”，其實就是“加速——反覆——加速——反覆……”，這樣子。
畫個圖大家可能更明白一點：
敏捷開發大幅提高了開發團隊的工作效率，讓版本的更新速度變得更快。
很多人可能會覺得，“更新版本的速度快了，風險不是更大了嗎？”
其實，事實並非如此。
敏捷開發可以幫助更快地發現問題，產品被更快地交付到用戶手中，團隊可以更快地得到用戶的反饋，從而進行更快地響應。而且，DevOps小步快跑的形式帶來的版本變化是比較小的，風險會更小（如下圖所示）。即使出現問題，修復起來也會相對容易一些。
雖然敏捷開發大幅提升了軟件開發的效率和版本更新的速度，但是它的效果僅限於開發環節。研發們發現，運維那邊，依舊是鐵板一塊，成爲了新的瓶頸。
運維工程師，和開發工程師有着完全不同的思維邏輯。運維團隊的座右銘，很簡單，就是“穩定壓倒一切”。運維的核心訴求，就是不出問題。
什麼情況下最容易出問題？發生改變的時候最容易出問題。所以說，運維非常排斥“改變”。
於是乎，矛盾就在兩者之間集中爆發了。
這個時候，我們的DevOps，隆重登場了。
DevOps到底是什麼
DevOps這個詞，其實就是Development和Operations兩個詞的組合。它的英文發音是 /de'vɒps/，類似於“迪沃普斯”。
DevOps的維基百科定義是這樣的：
DevOps是一組過程、方法與系統的統稱，用於促進開發、技術運營和質量保障（QA）部門之間的溝通、協作與整合。
這個定位稍微有點抽象，但是並不難理解。反正它不是某一個特定軟件、工具或平臺的名字。
從目標來看，DevOps就是讓開發人員和運維人員更好地溝通合作，通過自動化流程來使得軟件整體過程更加快捷和可靠。
破牆工具
很多人可能覺得，所謂DevOps，不就是Dev+Ops嘛，把兩個團隊合併，或者將運維劃歸開發，不就完事了嘛，簡單粗暴。
注意，這個觀點是不對的。這也是DevOps這些年一直難以落地的主要原因。
想要將DevOps真正落地，首先第一點，是思維轉變，也就是“洗腦”。不僅是運維的要洗，開發的也要洗。員工要洗，領導更要洗。
DevOps並不僅僅是組織架構變革，更是企業文化和思想觀念的變革。如果不能改變觀念，即使將員工放在一起，也不會產生火花。
除了洗腦之外，就是根據DevOps思想重新梳理全流程的規範和標準。
在DevOps的流程下，運維人員會在項目開發期間就介入到開發過程中，瞭解開發人員使用的系統架構和技術路線，從而制定適當的運維方案。而開發人員也會在運維的初期參與到系統部署中，並提供系統部署的優化建議。
DevOps的實施，促進開發和運維人員的溝通，增進彼此的理（gan）解（qing）。
在思維和流程改變的同時，想要充分落地DevOps，當然離不開軟件和平臺的支持。
目前支持DevOps的軟件實在是太多了。限於篇幅，就不一一介紹了。話說回來，現在DevOps之所以被吹得天花亂墜，也有這些軟件和平臺的功勞，可以趁機賣錢啊。
DevOps生態圈中令人眼花繚亂的工具
上述這些關鍵要素裏面，技術（工具和平臺）是最容易實現的，流程次之，思維轉變反而最困難。
換言之，DevOps考驗的不僅是一家企業的技術，更是管理水平和企業文化。
對比前面所說的瀑布式開發和敏捷開發，我們可以明顯看出，DevOps貫穿了軟件全生命週期，而不僅限於開發階段。
下面這張圖，更明顯地說明了DevOps所處的位置，還有它的價值：
DevOps的發展現狀
DevOps這個詞來源於2009年在比利時根特市舉辦的首屆DevOpsDays大會，爲了在Twitter上更方便的傳播，由DevOpsDays縮寫爲DevOps。
目前，DevOps處於高速增長的階段。尤其是在大企業中，DevOps受到了廣泛的歡迎。
根據2018年的調查發現，74%的受訪者已經接受了DevOps，而前一年這一比例爲66%。
越大的企業，越喜歡DevOps。包括Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Walmart、Sony等公司，都在採用DevOps。
如今，DevOps幾乎已經成爲了軟件工程的代名詞。
DevOps迅猛發展，相關專業人才的薪資待遇也跟着水漲船高。
根據調研，DevOps工程師在美國的平均年薪爲130000美金，在中國平均年薪也在40萬-50萬區間，能力強者年薪百萬也是比比皆是。
數據來自招聘網站
薪資的猛漲，又帶動了IT工程師們學習和認證的熱潮。
DevOps的認證目前最受歡迎的就是EXIN DevOps Master和EXIN DevOps Professional。這些認證的培訓費用不低，但是仍然吸引了很多人踊躍報名。
EXIN DevOps認證體系
DevOps與虛擬化、容器、微服務
這幾年雲計算技術突飛猛進，大家應該對虛擬化、容器、微服務這些概念並不陌生。當我們提到這些概念的時候，也會偶爾提及DevOps。
它們之間有什麼聯繫呢？
其實很簡單。
大家可以設想一下，如果要對一項工作進行精細化分工，我們是對一個大鐵疙瘩進行加工方便？還是拆成一塊一塊進行加工更加方便？
顯然是拆分之後會更加方便。
所謂“微服務”，就是將原來黑盒化的一個整體產品進行拆分（解耦），從一個提供多種服務的整體，拆成各自提供不同服務的多個個體。如下圖所示：
單體式架構（Monolithic）→ 微服務架構（Microservices）
微服務架構下，不同的工程師可以對各自負責的模塊進行處理，例如開發、測試、部署、迭代。
而虛擬化，其實就是一種敏捷的雲計算服務。它從硬件上，將一個系統“劃分”爲多個系統，系統之間相互隔離，爲微服務提供便利。
容器就更徹底了，不是劃分爲不同的操作系統，而是在操作系統上劃分爲不同的“運行環境”（Container），佔用資源更少，部署速度更快。
明白了吧？虛擬化和容器，其實爲DevOps提供了很好的前提條件。開發環境和部署環境都可以更好地隔離了，減小了相互之間的影響。
這也是DevOps爲什麼09年時不火，現在越來越火的一個主要原因之一。
最後的話
天下武功，無堅不摧，唯快不破。
時代發展到現在，客戶的需求瞬息萬變，市場的風向也難以預測。作爲企業，想要生存下去，只有讓自己變得更快。作爲員工，必須讓自己眼光更加長遠，內心更加包容。
近期必讀：
複雜（Complex）問題與繁雜（Complicated）問題，你怎麼選
你需要的不是一顆銀彈，而是一個銀盤——敏捷與DevOps有用嗎？
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言。