運維工程師要失業了?拋開噱頭與調侃,閒聊我心中的運維!
在知乎上,我經常受邀請回答很多類似的問題:運維到底是幹什麼的?運維工作有沒有意思?運維有沒有前途?運維是不是要被各種技術取代?
然而本人上知乎以休閒娛樂為主,一般不回答正兒八經的技術或者專業相關的問題,這次希望能通過本文向各位描述清楚運維到底是幹什麼的,至於有沒有前途、發展以及會不會失業等,請讀者自行判斷。
運維是幹什麼的
「運維」二字可能有幾層意思,分別可以指代運維工程師、運維團隊或者是整個運維服務體系。
我們可以看出,這三層是從狹義到廣義的遞進。相信絕大部分人問的都是運維工程師,只有極少數人能意識到還有運維服務體系這一層含義。
我們經常會聽到一些言論,比如:
雲服務普及了,運維工程師就要失業了。
等 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 級以上的技能。
寫在最後
本文是筆者個人對運維以及其職業發展的一些淺薄理解,總的來說,運維還是一個比較有意思且有良好發展的職業分支,雖然偶爾也要背黑鍋,但也歡迎更多努力、聰明、有才華的同學加入運維行業。
作者:溫崢峰
介紹:百田資訊運維技術專家,DevOps Team Leader,超過 8 年網際網路運維經驗,曾就職於網易遊戲,經受過各類海量規模網際網路業務模式的歷練,專注於運維自動化、DevOps 實踐、運維服務體系建設與 SRE 時代下的運維價值挖掘。
出處:知乎專欄:https://zhuanlan.zhihu.com/hiphone-devops
資源下載
關注公眾號:資料和雲(OraNews)回覆關鍵字獲取
‘2017DTC’,2017 DTC 大會 PPT
‘DBALIFE’,“DBA 的一天”海報
‘DBA04’,DBA 手記4 經典篇章電子書
‘RACV1’, RAC 系列課程視訊及 PPT
‘122ARCH’,Oracle 12.2 體系結構圖
‘2017OOW’,Oracle OpenWorld 資料
‘PRELECTION’,大講堂講師課程資料
相關推薦
運維工程師要失業了?拋開噱頭與調侃,閒聊我心中的運維!
“在知乎上,我經常受邀請回答很多類似的問題:運維到底是幹什麼的?運維工作有沒有意思?運維有沒有前
運維要失業了?機器學習可自動優化你的資料庫管理系統(DBMS)
作者簡介: 達娜·範·阿肯(Dana Van Aken)是卡內基·梅隆大學的計算機學博士生,導師是安德魯·帕夫洛博士。 安迪·帕夫洛(Andy Pavlo)是卡內基·梅隆大學的計算機學系資料庫學助理教授。 傑夫·戈登(Geoff Gordon)是卡內基·梅隆大學的副教授兼機器學習系教育部副主任。 本
運維工程師要熟悉的常見的埠號
通過該工具可以掃描常用的埠和指定的埠是否開放。常用埠號:代理伺服器常用以下埠:(1). HTTP協議代理伺服器常用埠號:80/8080/3128/8081/9080(2). SOCKS代理協議伺服器常用
五毛黨可能要失業了,因為AI水軍來了
價格 網絡 希望 很難 產品 blade 問題 學會 進化 當AI已經開始寫稿、唱歌、翻譯文章、把語音轉錄為文字的時候,我們其實應該清醒的認識到,五毛黨要消亡了。 相信大部分人和小編一樣,現在只要出門吃飯,就會打開大眾點評搜好吃的,看評分,看網友的評論。一般來說
AI合成主播上崗 主播也要失業了嗎?
在剛過去的世界網際網路大會上,全球第一個“AI合成主播”上崗,不僅能播中文,還能播報英文,一天不眠不休可工作24小時。“AI合成主播”的虛擬模樣以真實的新聞主播為原型,看上去和真人沒什麼區別。不少網友感嘆,難道連主播也要失業了嗎? 在智慧語音系統、互動系統等一批人工智慧闖入職場
華為第一款遊戲手機要來了?官方預熱Mate 20X,將主打效能和散熱。
文 | 大號科技 張東東 編輯 | 默然 昨天,華為官方釋出了一張華為Mate 20X的預熱海報,並表示,這款手機同樣會在10月16日的倫敦新品釋出會上與大家見面。 根據官方透露的資訊
微服務領域是不是要變天了?Spring Cloud Alibaba正式入駐Spring Cloud官方孵化器!
引言 微服務這個詞的熱度自它出現以後,就一直是高燒不退,而微服務之所以這麼火,其實和近幾年網際網路的創業氛圍是分不開的。 與傳統行業不同,網際網路企業有一個特點,那就是市場擴張速度非常之快,可能也就是幾天的時間,一家原本名不經傳的網際網路公司就會人盡皆知,一家獨角獸公司也就誕生了。 而伴隨著這些
雲時代,拿什麼保護你,我的“運維安全”
本文整理自 GOPS2017.北京站演講《雲時代網路邊界管理實踐及安全體系建設》,高效運維社群致力於陪伴您共同成長。 翟耐棟 奇虎360網路安全工程師 聚焦於基礎網路層面安全研究,熟悉網路裝置和協議是我們做安全的特長,研究方向包括網路協議、網路基礎設施的漏洞挖掘和安全加固,DDOS攻擊防禦,前瞻
盜QQ號的現在越來越牛B了,我差點被騙!大家要小心了
今天晚上正在上網的我QQ突然彈出郵件訊息 收到一封郵件,點看一看說我的QQ近期被人惡意傳播垃圾資訊,導致我的QQ限制登陸,當時還很納悶我沒有發過什麼垃圾資訊,感覺這是個騙人的,於是看了下發件人寫的是service但是郵件地址是空的,因為QQ官方發郵件時名字是service我
別忘了在使用MES系統之前,還有關鍵一步!
能夠 我們 數據轉換 重要 jpg 機架 方式 中標 發的 如果你是不熟悉工業自動化領域的專業人士,又或者是從IT或其他背景進入到操作技術(OT)領域的相關人士,那麽我相信你不會後悔讀到這篇文章。 我們都想做到智能化生產,想將MES系統,APS系統應用到生產過程中,但是在
TensorFlow 首個優化工具來了:模型壓縮4倍,速度提升3倍!
今天,TensorFlow釋出了一個新的優化工具包:一套可以讓開發者,無論是新手還是高階開發人員,都可以使用來優化機器學習模型以進行部署和執行的技術。 這些技術對於優化任何用於部署的TensorFlow模型都非常有用。特別是對於在記憶體緊張、功耗限制和儲存有限的裝置
未明學院學員報告:做了微博資料分析後,我發現現在最火的明星原來是……
今年,隨著《偶像練習生》、《創造101》、《延禧攻略》等選秀節目或電視劇的爆火,娛樂圈接二連三地湧現出一批炙手可熱的新星。那麼,在娛樂圈如此激烈的競爭中,誰才是目前最火的明星?明星背後又存在怎樣的營銷套路? 為此,未明學院資料分析訓練營的同學利用課上所學,分析了明星微博粉絲資料,同時藉助資料分析
當 AI 醫療成為熱點,噱頭與實幹如何區分?
在全球範圍內,過去至少有 50 萬人因患乳腺癌死亡,他們當中有 90%都是轉移性腫瘤。今年 10 月,Google 公佈了 AI 輔助乳腺癌診斷的最新成果,一款被命名為 LYNA 的監測工具。 LYNA 能夠以 99% 的準確率區分出有轉移性癌症的載玻片和無轉移性癌症的載玻片,將曾經的平均診
寫了 300000 行基礎設施程式碼,我學到了這五條經驗
本文為作者 Yevgeniy Brikman 分享了他在 Gruntwork 工作時建立並維護一個超過 30 萬行基礎設施程式碼的庫(https://gruntwork.io/infrastructure-as-code-library/)時學到的五條經驗。
程式設計師只能做到35歲嗎,年級大了以後會被淘汰嗎,我現在已經30歲了,還能學嗎?
工程師像醫生一樣,屬於年齡越大經驗越豐富,年齡越大越能解決複雜的問題。由於歐美髮展計算機比中國早20年左右,現在歐美50歲以上的程式設計師有很多,這都非常正常。也有很多程式設計師做了轉到產品經理、架構師、CTO技術總監、技術部經理、副總裁等等,這些職位需要有程式設計師的技術功底和豐富的專案管
研究了一下CSDN 私信的排序,我也是醉了
一直感覺CSDN的通知和私信總是看起來怪怪的,主頁提示有私信,開啟卻看不到,有時候向後翻幾頁又能看到。 今天又遇到這種情況了,於是研究了一下,剛開始還是沒找到規律,直到看到“3天前”的訊息排在最後一個“3年前”的訊息之後,突然就明白了,於是翻到最開始,發現“1
受夠了移動端的數字輸入,我用vue寫了個模擬鍵盤
前言 在H5開發過程中,涉及到使用者輸入的表單時,有一個非常常見的場景:輸入數字,在此基礎上往往還會涉及到限定數字範圍等一系列邏輯處理。 這些限定倒還好說,我受不了的是裝置鍵盤,目前常見的處理方式是用type="tel"直接喚起手機號碼的鍵盤,如果想要輸入負號,就只能
【深度相機系列五】腦補了和庫克的對話後,我發現了iPhone X深度相機選擇的祕訣和方法
本文首發於微信公眾號:計算機視覺life 前面的文章分別介紹了三種深度相機的原理:TOF、RGB雙目、結構光。看起來它們都各有利弊,那麼在實際產品研發中如何選擇深度相機呢? 為了讀者能夠有個清晰的思路
堅持寫了一年的部落格,我有哪些收穫
一 、引子 不知不覺,以每月最少一篇、每週一篇到兩篇的頻率開始寫部落格已經差不多堅持了一年,也算是個人一個小小的進步吧,雖然離那些一直在進步的朋友們差距越來越大,但我覺得長期堅持下去至少會比以前的自己更優秀,這就已經是一種進步了。 二、寫部落格的好處、壞處 寫部落格是對每個人來說都有成長的
曹工說JDK原始碼(4)--抄了一小段ConcurrentHashMap的程式碼,我解決了部分場景下的Redis快取雪崩問題
[曹工說JDK原始碼(1)--ConcurrentHashMap,擴容前大家同在一個雜湊桶,為啥擴容後,你去新陣列的高位,我只能去低位?](https://www.cnblogs.com/grey-wolf/p/13057567.html) [曹工說JDK原始碼(2)--ConcurrentHashMap的