提到 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 是 ContinuousIntegration（持續整合），而 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 為什麼 2009 年時不火，現在越來越火的一個主要原因之一。

DevOps 和通訊

作為一名通訊工程師，小棗君再說說 DevOps 和通訊的關係。

最開始接觸 DevOps 的時候，我和很多人一樣，都以為這是一個純IT的概念，和我們通訊沒有什麼關係。

後來，隨著對 DevOps 的深入瞭解，我才發現，這個理念和我們通訊有密切的關係。甚至說，早在十多年我剛入行的時候，其實就已經遇到了 DevOps 所面對的問題。

那時候（2005 年左右）的電信業，產品的穩定性和可靠性是壓到一切的（其實現在也是）。所以，電信業的軟體版本，更新速度非常慢。對朗訊、愛立信這樣的傳統巨頭來說，通常大半年才出一個正式版本。這個版本經過重重把關、精雕細琢，所以非常穩定。

隨著 3G 的興起，全球運營商開始對網路進行更新換代。華為和中興開始趁機切入國際運營商市場，試圖從國際巨頭那邊分一杯羹。

除了價格之外，華為中興最大的殺手鐗是什麼？就是響應速度。

那個時候，運營商客戶對電信裝置軟硬體的需求非常多、非常頻繁。像印度這樣的地方，客戶尤其難纏，每天都會提出新的需求。

當時幾家海外裝置商的響應速度是非常慢的，從不輕易同意接受需求。即使接受，也會答覆半年甚至一年後實現。客戶聽了直接就崩潰了。

而華為和中興則不同，兩家公司的售前市場人員對於客戶需求非常 “大方”，基本上有求必應。（當時售後同事都會罵售前同事，可是仔細想來，不答應的話，根本沒有進入市場的機會。）

當時華為和中興的版本釋出頻率，快到什麼程度呢？最快的時候，三天一個版本。甚至，長期都有大批研發人員駐紮在客戶辦公室，現場改版本，提交 “熱補丁”。

那時候是 2006 年，DevOps 這個概念的影子都還沒有。研發那邊，好像也就是剛剛提出敏捷開發。在沒有理論框架和工具平臺的支援下，純靠人力，實現了版本的飛速迭代。當然，這其中的代價和風險也是很高的。

不僅是開發人員很累很辛苦，專案裡的工服（工程服務）工程師，也就是技術支援工程師，本文裡面的運維工程師，更是苦不堪言。你想啊，以前幾個月升一次級，現在幾天就要升一次級，能不辛苦麼？

但就是這樣的辛苦付出，才硬生生從傳統巨頭嘴裡搶下來市場份額，最終一步一步做大做強。

後來，才慢慢有了敏捷開發的概念，現在更是有了 DevOps，各種工具啊平臺啊都有了，給版本快速迭代提供了很好的條件。

對通訊行業的運維來說，DevOps 是機遇更是挑戰。

就像前面說的容器、虛擬化。5G 核心網採用的 NFV 虛擬化技術，讓網元功能隔離，就大大降低了核心網工程師的操作風險和難度。這是一個積極的變化。但是，DevOps 對運維工程師的能力要求，是大大提高了。。。

通訊軟體是IT軟體的一個重要分支，和 DevOps 有很緊密的關係。建議通訊工程師好好了解一下 DevOps，升級一下自己的知識庫，做好技能儲備。