閒聊我心中的運維

運維要被取代？

本文主要面向想了解運維是什麼的讀者，包括想投身運維行業或者非運維崗位的技術從業者。

在知乎我經常受邀請回答很多類似的問題：

”運維到底是幹什麼的？“

”運維工作有沒有意思？“

”運維有沒有前途？“

”運維是不是要被各種技術取代？“

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

「運維是幹什麼的？」

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

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

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

”雲服務普及了，運維工程師就要失業了“

”等 DevOps 或者 SRE 落地了，運維工程師也要失業了“

”容器技術普及了，運維工程師也該失業了“

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

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

一個站點或者App，大致經歷著這樣的誕生過程：
PM 設計出產品原型，交給 Dev 開發實現，QA 測試，最後交付給 Ops 部署到線上執行，最後供使用者使用。
在這幾個簡單步驟中涉及了眾多的人、角色、交付過程等物件，這是一個完整、複雜的系統工程，而任意一個環節的失誤都可能影響最終呈現給使用者的體驗以及效果。

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

無論後面的交付步驟是用 DevOps 還是 SRE 的實現方式，都離不開一個廣義的運維服務的執行環節，所以說 Dev 還是 Dev，Ops 還是 Ops，沒有誰被取代，只是運維服務的執行方式升級為更加軟體工程化的手段，減少人肉操作，DevOps 強調自動化、拉動式來提高團隊交付效率與質量。

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

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

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

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

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

我作為運維產品經理的角色和各種型別的運維開發一起協作過，團隊中有本來就做運維開發的，也有本來做其他業務（電商、平臺）的開發轉來協助運維團隊的，和他們協作一段日子後總體感覺如下：

• 運維開發首先是一個程式設計師，不是運維工程師；
• 一個好的運維開發需要具備 「運維理解」+「開發能力」；
• 對「開發能力」的技術要求低於其他業務形態（如遊戲、電商、搜尋等）；
• 對運維業務的理解難度會低於電商、遊戲等業務形態，即對「運維理解」的要求不高；
• 對運維相關技術棧的掌握程度要求高，如 Linux、git、nginx、zabbix、docker、k8s 等等；

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

對於從業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級以上的技能。

總結

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