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

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

運(yùn)維是干什么的

「運(yùn)維」二字可能有幾層意思，分別可以指代運(yùn)維工程師、運(yùn)維團(tuán)隊(duì)或者是整個(gè)運(yùn)維服務(wù)體系。

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

我們經(jīng)常會(huì)聽到一些言論，比如：

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

也記不清運(yùn)維工程師到底被失業(yè)了多少遍，但我認(rèn)為就算運(yùn)維工程師被取代了，運(yùn)維服務(wù)也不會(huì)消亡，它將伴隨并支撐著業(yè)務(wù)發(fā)展的整個(gè)生命周期。

為何這樣說？我們還是用業(yè)務(wù)的誕生過程來分析。

一個(gè)站點(diǎn)或者 App，大致經(jīng)歷著這樣的誕生過程：PM 設(shè)計(jì)出產(chǎn)品原型，交給 Dev 開發(fā)實(shí)現(xiàn)、QA 測(cè)試，然后交付給 Ops 部署到線上運(yùn)行，最后供用戶使用。

在這幾個(gè)簡(jiǎn)單步驟中涉及了眾多的人、角色、交付過程等對(duì)象，這是一個(gè)完整、復(fù)雜的系統(tǒng)工程，而任意一個(gè)環(huán)節(jié)的失誤都可能影響最終呈現(xiàn)給用戶的體驗(yàn)以及效果。

我們重點(diǎn)考慮從 Dev 把業(yè)務(wù)產(chǎn)品完成后交付給 Ops 到線上運(yùn)行的這個(gè)階段，Dev 同事主要負(fù)責(zé)業(yè)務(wù)產(chǎn)品的功能完整、邏輯正確等業(yè)務(wù)指標(biāo)，而 Ops 同事主要負(fù)責(zé)業(yè)務(wù)產(chǎn)品的運(yùn)行質(zhì)量、穩(wěn)定性、可用性等系統(tǒng)指標(biāo)。

無論后面的交付步驟是用 DevOps 還是 SRE 的實(shí)現(xiàn)方式，都離不開一個(gè)廣義的運(yùn)維服務(wù)的執(zhí)行環(huán)節(jié)。

所以說， Dev 還是 Dev，Ops 還是 Ops，沒有誰被取代，只是運(yùn)維服務(wù)的執(zhí)行方式升級(jí)為更加軟件工程化的手段，減少人肉操作，DevOps 強(qiáng)調(diào)自動(dòng)化、拉動(dòng)式來提高團(tuán)隊(duì)交付效率與質(zhì)量。

而傳統(tǒng)的運(yùn)維需要謀求技術(shù)轉(zhuǎn)型，從原來只關(guān)注操作系統(tǒng)層面的技術(shù)已經(jīng)不夠了，還要增加對(duì)程序代碼的性能調(diào)優(yōu)、持續(xù)交付、容器化等軟件基礎(chǔ)架構(gòu)方面的技能提升，也需要持續(xù)關(guān)注整個(gè)業(yè)務(wù)、應(yīng)用、服務(wù)的生命周期管理。

簡(jiǎn)單來說，就是把過去傳統(tǒng)的黑盒運(yùn)維的思維方式拋棄，進(jìn)入白盒運(yùn)維的時(shí)代，我們必須更加深入代碼、深入業(yè)務(wù)運(yùn)營(yíng)，讓整個(gè)線上服務(wù)運(yùn)行于更優(yōu)質(zhì)高效的狀態(tài)。

至于運(yùn)維是否會(huì)被取代，取決于你屬于哪種運(yùn)維。

運(yùn)維工程師和運(yùn)維開發(fā)工程師

要建設(shè)運(yùn)維自動(dòng)化或者實(shí)踐 DevOps 離不開運(yùn)維開發(fā)工程師的參與，但要怎樣才能更好地發(fā)揮運(yùn)維開發(fā)的作用呢？

我曾作為運(yùn)維產(chǎn)品經(jīng)理的角色和各種類型的運(yùn)維開發(fā)一起協(xié)作過，團(tuán)隊(duì)中有本來就做運(yùn)維開發(fā)的，也有本來做其他業(yè)務(wù)（電商、平臺(tái)）的開發(fā)轉(zhuǎn)來協(xié)助運(yùn)維團(tuán)隊(duì)的。

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

• 運(yùn)維開發(fā)首先是一個(gè)程序員，不是運(yùn)維工程師。
• 一個(gè)好的運(yùn)維開發(fā)需要具備 「運(yùn)維理解」+「開發(fā)能力」。
• 對(duì)「開發(fā)能力」的技術(shù)要求低于其他業(yè)務(wù)形態(tài)（如游戲、電商、搜索等）。
• 對(duì)運(yùn)維業(yè)務(wù)的理解難度會(huì)低于電商、游戲等業(yè)務(wù)形態(tài)，即對(duì)「運(yùn)維理解」的要求不高。
• 對(duì)運(yùn)維相關(guān)技術(shù)棧的掌握程度要求高，如 Linux、Git、Nginx、Zabbix、Docker、K8S 等。

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

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

等到業(yè)界提出 DevOps 的時(shí)候，他們往往已經(jīng)專注于團(tuán)隊(duì)管理、容量規(guī)劃、架構(gòu)調(diào)優(yōu)、運(yùn)維服務(wù)質(zhì)量等高級(jí)范疇，所以基本不太可能抽出大塊的時(shí)間來重新學(xué)習(xí)編碼并開發(fā)自動(dòng)化系統(tǒng)。

所以，當(dāng)我們有自動(dòng)化系統(tǒng)的建設(shè)需求時(shí)，需要更專業(yè)的程序員來協(xié)助。

但一般的非專職運(yùn)維開發(fā)的程序員做出來的系統(tǒng)對(duì)于運(yùn)維來說往往不太好使，這時(shí)候有部分年輕的運(yùn)維工程師升級(jí)了研發(fā)技能，轉(zhuǎn)型運(yùn)維開發(fā)，把好使的運(yùn)維系統(tǒng)做出來了，贏得了運(yùn)維團(tuán)隊(duì)的好評(píng)，大家都為「運(yùn)維開發(fā)」點(diǎn)贊。

所以，大家將 「好使的運(yùn)維系統(tǒng)」 和 「運(yùn)維開發(fā)」 等價(jià)起來，以為我們只要招來一個(gè)運(yùn)維開發(fā)，那么一套完美的運(yùn)維平臺(tái)就能自動(dòng)誕生出來，這是個(gè)很大的誤區(qū)。

其實(shí)「好使的運(yùn)維系統(tǒng)」真正等價(jià)于「運(yùn)維理解」+「開發(fā)能力」，這兩種能力也是可以分離的，不一定要強(qiáng)加在運(yùn)維開發(fā)工程師一個(gè)人的身上。

類似其他業(yè)務(wù)形態(tài)的開發(fā)過程，需要產(chǎn)品經(jīng)理和程序員兩種角色分離，企業(yè)也不會(huì)說要招聘既會(huì)寫代碼、又會(huì)出需求的程序員。

所以，當(dāng)資深運(yùn)維能把運(yùn)維自動(dòng)化的需求細(xì)致地文檔化下來，把自動(dòng)化系統(tǒng)的設(shè)計(jì)、架構(gòu)等關(guān)鍵環(huán)節(jié)確立下來，這就是最好的「運(yùn)維理解」。

這時(shí)把這份靠譜、好使、細(xì)致的需求文檔交給具備強(qiáng)「開發(fā)能力」的程序員，最終就可以得到「好使的運(yùn)維系統(tǒng)」。

當(dāng)然，資深運(yùn)維要獲取產(chǎn)品經(jīng)理能力也不是那么簡(jiǎn)單，而且也需要和運(yùn)維開發(fā)無障礙地探討技術(shù)，個(gè)人覺得必須具備且不限于以下技能包：

產(chǎn)品規(guī)劃、產(chǎn)品設(shè)計(jì)、面向?qū)ο?、需求模型、領(lǐng)域模型、設(shè)計(jì)模型、設(shè)計(jì)原則、設(shè)計(jì)模式、產(chǎn)品工具和文檔能力等。

所以，當(dāng)運(yùn)維需求被理解、分析得足夠透徹，以及資深運(yùn)維獲得了「產(chǎn)品經(jīng)理」能力后，運(yùn)維開發(fā)就是一種普通的開發(fā)分支，按需求文檔編碼即可。

再往高級(jí)發(fā)展的話，運(yùn)維開發(fā)也可以替代資深運(yùn)維出需求，升級(jí)為運(yùn)維產(chǎn)品經(jīng)理，以程序員的思維角度來解決運(yùn)維服務(wù)的工程效率和質(zhì)量問題，我認(rèn)為這也是類似 Google 所提倡的 SRE 文化。

最后，很多運(yùn)維可能考慮要不要轉(zhuǎn)運(yùn)維開發(fā)，當(dāng)你覺得編碼的樂趣遠(yuǎn)遠(yuǎn)大于其他運(yùn)維技能的時(shí)候，盡管爭(zhēng)取努力去轉(zhuǎn)！

把自己當(dāng)成一個(gè)真正的程序員，以程序員的評(píng)價(jià)標(biāo)準(zhǔn)來要求自己，不要覺得運(yùn)維能力和編碼能力各自半桶水是好事，正如我前面的那句話：“運(yùn)維開發(fā)首先是一個(gè)程序員，不是運(yùn)維工程師 。”

運(yùn)維服務(wù)體系與技能水平量化

每個(gè)運(yùn)維工程師心中其實(shí)都有自己的想法，不妨用思維導(dǎo)圖的形式將其列出來，找出自己感興趣的點(diǎn)，持續(xù)深入，打造自己的核心競(jìng)爭(zhēng)力。

而思維導(dǎo)圖也可以繼續(xù)往橫向縱向擴(kuò)展，形成自己心中完整的一套運(yùn)維概念。

下面跟大家分享一張思維導(dǎo)圖，展示我個(gè)人心中的運(yùn)維服務(wù)體系。當(dāng)然，這里面還有很多可以展開，但細(xì)節(jié)就不方便透露了，這屬于個(gè)人經(jīng)驗(yàn)未必能適用其他運(yùn)維團(tuán)隊(duì)。

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

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

為何要量化技能呢？因?yàn)槿说臅r(shí)間、專注力畢竟有限，如何把精力分配到不同的技能上，需要一定的策略。

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

如路人 A 的技能水平表是這樣的：（當(dāng)然還有其他技能項(xiàng)，如網(wǎng)絡(luò)、安全等等，這里只是簡(jiǎn)化了方便討論）。

最低要求

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

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

進(jìn)階要求

除了滿足最低要求之外，培養(yǎng)自己的核心競(jìng)爭(zhēng)力，為日后的發(fā)展打下基礎(chǔ)，推薦大家對(duì) 1~2 項(xiàng)深入學(xué)習(xí)，達(dá)到 4、5 級(jí)甚至更高的水平。

隨著互聯(lián)網(wǎng)運(yùn)維行業(yè)的各種 PaaS、IaaS 普及后，自動(dòng)化程度越來越高，現(xiàn)在已經(jīng)不像以前那樣需要那么多「操作員」。

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

寫在最后

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