在知乎上，我經常受邀請回答很多類似的問題：運維到底是干什么的？運維工作有沒有意思？運維有沒有前途？運維是不是要被各種技術取代？

然而本人上知乎以休閑娛樂為主，一般不回答正兒八經的技術或者專業相關的問題，這次希望能通過本文向各位描述清楚運維到底是干什么的，至于有沒有前途、發展以及會不會失業等，請讀者自行判斷。

運維是干什么的

「運維」二字可能有幾層意思，分別可以指代運維工程師、運維團隊或者是整個運維服務體系。

我們可以看出，這三層是從狹義到廣義的遞進。相信絕大部分人問的都是運維工程師，只有極少數人能意識到還有運維服務體系這一層含義。

我們經常會聽到一些言論，比如：

• 云服務普及了，運維工程師就要失業了。
• 等 DevOps 或者 SRE 落地了，運維工程師也要失業了。
• 容器技術普及了，運維工程師也該失業了……

也記不清運維工程師到底被失業了多少遍，但我認為就算運維工程師被取代了，運維服務也不會消亡，它將伴隨并支撐著業務發展的整個生命周期。

為何這樣說？我們還是用業務的誕生過程來分析。

一個站點或者 App，大致經歷著這樣的誕生過程：PM 設計出產品原型，交給 Dev 開發實現、QA 測試，然后交付給 Ops 部署到線上運行，最后供用戶使用。

在這幾個簡單步驟中涉及了眾多的人、角色、交付過程等對象，這是一個完整、復雜的系統工程，而任意一個環節的失誤都可能影響最終呈現給用戶的體驗以及效果。

我們重點考慮從 Dev 把業務產品完成后交付給 Ops 到線上運行的這個階段，Dev 同事主要負責業務產品的功能完整、邏輯正確等業務指標，而 Ops 同事主要負責業務產品的運行質量、穩定性、可用性等系統指標。

無論后面的交付步驟是用 DevOps 還是 SRE 的實現方式，都離不開一個廣義的運維服務的執行環節。

所以說， Dev 還是 Dev，Ops 還是 Ops，沒有誰被取代，只是運維服務的執行方式升級為更加軟件工程化的手段，減少人肉操作，DevOps 強調自動化、拉動式來提高團隊交付效率與質量。

而傳統的運維需要謀求技術轉型，從原來只關注操作系統層面的技術已經不夠了，還要增加對程序代碼的性能調優、持續交付、容器化等軟件基礎架構方面的技能提升，也需要持續關注整個業務、應用、服務的生命周期管理。

簡單來說，就是把過去傳統的黑盒運維的思維方式拋棄，進入白盒運維的時代，我們必須更加深入代碼、深入業務運營，讓整個線上服務運行于更優質高效的狀態。

至于運維是否會被取代，取決于你屬于哪種運維。

運維工程師和運維開發工程師

要建設運維自動化或者實踐 DevOps 離不開運維開發工程師的參與，但要怎樣才能更好地發揮運維開發的作用呢？

我曾作為運維產品經理的角色和各種類型的運維開發一起協作過，團隊中有本來就做運維開發的，也有本來做其他業務（電商、平臺）的開發轉來協助運維團隊的。

和他們協作一段日子后，總體感覺如下：

• 運維開發首先是一個程序員，不是運維工程師。
• 一個好的運維開發需要具備 「運維理解」+「開發能力」。
• 對「開發能力」的技術要求低于其他業務形態（如游戲、電商、搜索等）。
• 對運維業務的理解難度會低于電商、游戲等業務形態，即對「運維理解」的要求不高。
• 對運維相關技術棧的掌握程度要求高，如 Linux、Git、Nginx、Zabbix、Docker、K8S 等。

綜上所述，運維開發是一個深度不算太深的職業分支，而現在之所以對運維開發需求量熱起來了，主要由于老一輩的資深運維普遍研發能力有限，而這是有歷史原因的。

對于從業 8 年以上的資深運維來說，他們剛開始做運維的時候更多的是接觸機房、機架、主機、交換機、防火墻等硬件設備。然后對接業務運維后，一般通過 Shell、Python 等腳本來輔助工作。

等到業界提出 DevOps 的時候，他們往往已經專注于團隊管理、容量規劃、架構調優、運維服務質量等高級范疇，所以基本不太可能抽出大塊的時間來重新學習編碼并開發自動化系統。

所以，當我們有自動化系統的建設需求時，需要更專業的程序員來協助。

但一般的非專職運維開發的程序員做出來的系統對于運維來說往往不太好使，這時候有部分年輕的運維工程師升級了研發技能，轉型運維開發，把好使的運維系統做出來了，贏得了運維團隊的好評，大家都為「運維開發」點贊。

所以，大家將 「好使的運維系統」 和 「運維開發」 等價起來，以為我們只要招來一個運維開發，那么一套完美的運維平臺就能自動誕生出來，這是個很大的誤區。

其實「好使的運維系統」真正等價于「運維理解」+「開發能力」，這兩種能力也是可以分離的，不一定要強加在運維開發工程師一個人的身上。

類似其他業務形態的開發過程，需要產品經理和程序員兩種角色分離，企業也不會說要招聘既會寫代碼、又會出需求的程序員。

所以，當資深運維能把運維自動化的需求細致地文檔化下來，把自動化系統的設計、架構等關鍵環節確立下來，這就是最好的「運維理解」。

這時把這份靠譜、好使、細致的需求文檔交給具備強「開發能力」的程序員，最終就可以得到「好使的運維系統」。

當然，資深運維要獲取產品經理能力也不是那么簡單，而且也需要和運維開發無障礙地探討技術，個人覺得必須具備且不限于以下技能包：

產品規劃、產品設計、面向對象、需求模型、領域模型、設計模型、設計原則、設計模式、產品工具和文檔能力等。

所以，當運維需求被理解、分析得足夠透徹，以及資深運維獲得了「產品經理」能力后，運維開發就是一種普通的開發分支，按需求文檔編碼即可。

再往高級發展的話，運維開發也可以替代資深運維出需求，升級為運維產品經理，以程序員的思維角度來解決運維服務的工程效率和質量問題，我認為這也是類似 Google 所提倡的 SRE 文化。

最后，很多運維可能考慮要不要轉運維開發，當你覺得編碼的樂趣遠遠大于其他運維技能的時候，盡管爭取努力去轉！

把自己當成一個真正的程序員，以程序員的評價標準來要求自己，不要覺得運維能力和編碼能力各自半桶水是好事，正如我前面的那句話：“運維開發首先是一個程序員，不是運維工程師 。”

運維服務體系與技能水平量化

每個運維工程師心中其實都有自己的想法，不妨用思維導圖的形式將其列出來，找出自己感興趣的點，持續深入，打造自己的核心競爭力。

而思維導圖也可以繼續往橫向縱向擴展，形成自己心中完整的一套運維概念。

下面跟大家分享一張思維導圖，展示我個人心中的運維服務體系。當然，這里面還有很多可以展開，但細節就不方便透露了，這屬于個人經驗未必能適用其他運維團隊。

由于運維一般講究廣度而忽略了深度，所以容易導致自身的技術棧廣而不精的情況，那怎么量化自己的技能水平足夠深入呢？

舉一個大家都熟悉的 MySQL 技能作為例子，如果把 MySQL 水平定義成 1~10 級，下面是我對各種級別水平的理解。

為何要量化技能呢？因為人的時間、專注力畢竟有限，如何把精力分配到不同的技能上，需要一定的策略。

正常情況下，大家把精力平均分配到各種具體技能，希望可以做到面面俱到，但不會太深入某項技能，所以技能水平達到的級別落在 1~3 之間。

如路人 A 的技能水平表是這樣的：（當然還有其他技能項，如網絡、安全等等，這里只是簡化了方便討論）。

最低要求

運維是一種需要技能面比較廣的工種，大家普遍都是處于技術面廣但不深的狀態，我把 2 級定義為科普級，意思是達到該級就可以滿足各種日常工作要求。

所以說上面的路人 A，最好盡快爭取把還在1級水平的 Shell 和 MySQL 都提升到 2 級，就可以滿足日常工作要求，這也是我們對運維工程師的最低要求。

進階要求

除了滿足最低要求之外，培養自己的核心競爭力，為日后的發展打下基礎，推薦大家對 1~2 項深入學習，達到 4、5 級甚至更高的水平。

隨著互聯網運維行業的各種 PaaS、IaaS 普及后，自動化程度越來越高，現在已經不像以前那樣需要那么多「操作員」。

也就是說，技能水平偏低的運維急需技能升級或者技能轉型，能支撐你走多遠的不是那些 1、2 級的技能，而是 4、5 級以上的技能。

寫在最后

本文是筆者個人對運維以及其職業發展的一些淺薄理解，總的來說，運維還是一個比較有意思且有良好發展的職業分支，雖然偶爾也要背黑鍋，但也歡迎更多努力、聰明、有才華的同學加入運維行業。