運維有前（錢）途麼？

這是個理論且枯燥的話題，但很多人又不得不面對。

今天我以自己在小公司、百度、阿里的工作經歷，結合同學在騰訊、小米等公司的狀況，來說下運維技術在未來網際網路的前景。

通過這篇文章，你會了解到小公司和大公司的運維狀況對比，並能瞭解到各自的發展狀況，但很多問題並不會細節化，因為寫不下。

首先說下結論：我認為運維是非常有前（錢）途的，也是技術性越來越強的職業。
身邊bat的同學，工作3年左右跳槽的，基本沒有月薪少於20k的，多一點到40k左右，一般也都是技術負責人甚至直接帶團隊。

但是，運維累是一定的，做網際網路的沒有不累的，問題是累的同時，能不能學習或實踐到更好的技術，來支撐你將來拿更多的錢，才是核心。

為何普遍感覺運維沒有技術含量？

我自己在大公司和小公司都呆過，我認為主要是初級運維太多，而他們做的事很多根本不能稱之為運維，總結如下幾點：

1、運維自身缺少對目標充分的規劃和實施拆分，導致很多工作無技術性。

運維是一定會做基礎性工作的，例如部署服務、上線，甚至搬機器、重灌系統等等。但運維肯定不能只做這些，因此在剩餘時間如何做有利於運維技術提升的事，就尤為重要。

舉個簡單例子：當你和研發一起做一些事的時候，你在裡面的定位是什麼，怎麼體現你的價值和技術能力？如果沒有，基本就是在幫別人做貢獻。

2、運維自身負責的點非常多，無法精通，無核心競爭力。

大的範疇包括：硬體、網路、作業系統、資料庫、儲存、開源軟體；職責上要負責：各種功能的部署和除錯，例如ldap、samba、nagios等；再細的分工還包括：壓力測試、效能優化、核心引數調優、系統問題追查等。

很多運維因為要做太多不同層面的事，導致很多事都僅僅只是完成任務，缺乏深入的研究，當然可能也缺少深入研究的場景。

3、運維自身的總結、呈現不夠，技術能力提升不足。

其實和第一點關聯比較多，因為本身沒有對目標充分的規劃，再加上總結呈現也不夠，對技術的提升就比較有限了。

舉個真例項子，我認識一個人做運維7年多，期間在幾家公司做過不少事且時間都不短，正常來說會有相當的積累。前段時間因為要幫他內部推薦到bat時review了他的簡歷，有幾個感受：簡歷通篇都是描述性詞彙，無資料支撐；專案工作都是敘事型描述，充斥著服務搭建、解決問題的字樣，沒有技術點；僅有的技術工作都是一筆帶過，沒有方案選型和技術能力體現，無法體現技術水準；

我自己面試過很多人，老實說這樣的簡歷遠遠達不到及格分。當應聘公司拿到這樣簡歷時，如何能快速瞭解到你就是公司需要的人？

4、運維在技術部門毫無話語權，技術上得不到應有重視。

在研發和測試的眼裡，運維可能就是搬機器、重灌系統、部署服務、掌握root許可權這樣毫無技術含量的職位，但也不得不承認，在很多公司，運維實際上就是這樣。

實際上，不管是哪個職業，只要你做的不好，都沒有前途。比如研發一般比較有前途吧，但很多研發人員做了差不多十年，最後還轉型做其他職業了；我身邊運維做到等級很高，跳槽出去到中小型公司就是運維總監的人比比皆是。

▼那麼在BAT從事運維的同學們都在做什麼？我從幾個層面簡單描述：

運維職能方面：

首先，BAT在運維上的分工更細，一般系統、資料庫、應用運維這些都是完全分開的，因此在職能上可能更加專注，當然涉及的面肯定會窄。

工作職能上，運維主要在可用性、效率提升、成本控制這3個主要方面發力，並和公司、研發的目標密切關聯，運維所做的絕大部分工作都是從這3個目標中拆出來的。

技術提升上，主要是以專案的形式，利用對服務的瞭解和技術方案，來解決共性問題。

▼技術工作方面：

以服務可用性為例，絕不僅僅只是處理報警，操作時小心些，寫幾個自動化工具這麼簡單，它包括了：

技術方案：預案執行是否足夠清晰明確、速度足夠快；監控是否能及時發現問題，避免客戶投訴；服務出現任何問題，是否都有及時的方案止損和解決（例如機房異常的問題）；業務出現問題，是否有方案能夠快速定位和恢復；

非技術方案：流程的控制（任何對線上的操作是否有記錄、隨時回滾、方便review），資訊的披露（資訊是否公開透明）。

▼做事方法方面：

資料說話。今年的可用性目標是保持服務基本穩定？還是保持服務可用性99.99%？還是保持99.99%基礎上0運維事故，同時mttr小於20分鐘？

嚴格按照既定計劃安排工作、review、總結。有明確的工作實施拆分細則麼，精確到什麼時間維度，季度？月？周？日？多久review一次？

合縱連橫，結合外部資源以更高的視角去解決問題，而不是停留在一個點上。下面有類似例子。

結合這些方面，可能BAT的運維同學才能夠實現技術的快速提升，這是我所看到的。

▼最後說下運維的努力方向：

想要運維有前途，需要幾個要素：

1、需要一個能夠施展運維發展的平臺，至少是一個有發展並有一定機器規模的業務。這裡並不是必須要bat，而是選擇一個適合你的。

2、瞭解和熟悉業務。

很多人不喜歡去處理問題，然後只想著做高大上的東西，這樣的結果我不說你也明白，就是不接地氣，做出來的東西沒人用，等等。

所以我認為運維架構師必須是一個瞭解和熟悉業務的人，而且非常熟悉。我身邊也遇到過這樣的人，等級很高，平時也不處理什麼問題，但關鍵時刻（比如出了問題），他就是能迅速找到關鍵點並解決之，並且某些細節比你還要了解，讓你不得不佩服。運維是必須要做這樣的人！

3、對運維技術和業務架構的發現和思考。

即使你每天重複在做上線、處理故障和問題、響應需求、開發和維護指令碼，這些都沒關係，重點是你是否有從所做的問題上看到業務和運維上的痛點，並利用已有的技術方案，處理和解決掉！

4、綜合考慮問題，並以全域性化視角去解決共性問題。

問題是很多的，也並不是說解決掉很多個問題就是牛人，問題的關鍵在於怎麼解決問題的同時能體現你的全域性視角和技術能力。

舉個最簡單例子，有臺機器磁碟快滿了，這肯定是個特別小的問題了，運維同學應該經常遇到，怎麼處理呢？

如果你只是排查了磁碟佔用，然後刪除了資料或者調整了刪除磁碟的指令碼，那是最差的一檔；排查了磁碟佔用，確認是單機有問題還是批量機器都有問題，為什麼在這個點報，確認清楚並能解決之，這就高了一檔；排查了磁碟佔用，徹底發現了磁碟增長的原因，但是發現磁碟增長不可控，現有的資料刪除方式不能避免報警.那麼有辦法在保證重要資料保留正常的情況下讓磁碟不報警麼？然後以技術方案解決之，這就更高了一檔。。。。。。這樣的例子還有很多。

你會發現，運維，實際上就是利用你對系統、網路、硬體、規範、服務方面的熟悉程度，結合專業知識，用技術方案解決研發、測試解決不了或者不能單獨解決的一系列共性問題，並能形成工具、平臺、框架，最終能給運維部甚至公司創造價值，這就是個牛逼的運維。

在這個過程中所做的，不管是部署nginx、研究透了nginx的rewrite規則、寫了牛逼的工具等等、把iptables用的滾瓜爛熟，這並沒有卵用，這都只是為最終結果服務，而已。

最後，關於運維同學應該怎麼提升自己的能力，我下次單獨寫一篇文章，分析下bat這類公司對運維技術的要求，以及運維在技術上的進階路線。