最近，小編在知乎上看到這樣一個問題：
開發都認為運維工程師很Low？
「你以為運維就是管理一下機器，管理一下資料庫？你丟個包上去運維幫你執行下？你的日誌爆滿了運維給你清理一下？運維幫你安裝下中 間件？你以為的運維只是做這些事？」
運維工程師的工作究竟是怎樣的？秉 持著和平交流的學習態度，小編精選了幾位高贊知乎網友的精彩回答，分享給大家學習交流（勿上升、勿引戰） ：
1號知乎網友 ：芬達味橘貓
我是自動化運維，我寫了很多自動化指令碼，我走了之後指令碼沒人維護了，開發不會整，測試不會整，其他運維也不會整，最後原先自動化的業務也都變成手動人員來幹了，又增加人員成本了，公司開技術倒車了。
做運維挺不容易，總被別人說low。機房你得懂吧，網路安全你得懂吧，docker/K8s你得懂吧，公司OA/CRM系統你得懂吧，Linux/Debian/Fedora/Centos/Ubuntu和windows Server你得懂吧，資料庫MySQL/Oracle/SQLServer你得懂吧，Kvm/Openstack/阿裏雲/華為雲你得懂吧，Python也要求會也得懂吧，Java/Vue你也得懂吧，要不遇到個二把刀的開發又被坑得加班了吧，還得懂電腦伺服器硬體Raid之類得，要不壞了東西都沒法修理，所以運維真的不簡單，終於有人提出這個問題了，回答一下也算抒發下不被人重視的感想吧。
2號知乎網友： 技術王
我用十多年的開發經驗告訴你，如果你作為開發覺得運維工程師很Low，你是會吃苦頭的，有些運維水平高的，那可真不是你能評論的。
你以為運維就是管理一下機器，管理一下資料庫？你丟個包上去運維幫你執行下？你的日誌爆滿了運維給你清理一下？運維幫你安裝下中介軟體？你以為的運維只是做這些事？
作為一個開發，我都看到過不少運維的工作超乎了我的想象，這些工作的難度感覺是一點也不比開發簡單，需要的技術水平還是非常高的，現在我就來跟你說說運維的技術能有多高，他們做了哪些高難度的挑戰。
監控能力
這方面我是最有發言權了，穩定性、SRE一直是我現在做的事情，但是全面性的SRE不是只有開發就能完成的，很多東西還是需要依賴於運維來做，這期間我也發現了很多天窗，原來還可以這麽幹？
首先 監控Linux服務 嘛，那肯定是要全方位系統的監控，網路、磁盤、CPU、記憶體等等，這才叫監控，但是對於第一手資訊的獲取，對於我來說確實犯難了，我只有獲取到了這些系統的執行指標，才能做一些效能分析診斷，然後作出一些異常檢測等動作。
然而，運維為我準備了一大堆的數據，我挑選都挑選不過來，監控網路嗎？route、iptables、tcptop、tcplife、tcpconnect、tcpretrancs等等技術，然後他們把這些命令或者工具整理成指令碼，成功的上報到我們這邊的雲端系統，讓我們可以全方位系統的監控整個網路了。
我們要 監控磁盤 呢？他們寫了一大堆指令碼，裏面涉及到各種技術點，什麽biotop、biosnoop、biplatency、mdflush、lsof、pcstat等等工具，可以說是把磁盤的各個方面的數據都搜集上報過來了，我們有時候都嫌多了這些數據，但是他們都統統建設好了，他們的意思是反向推動我們去做一些監控能力，讓他們也能用得上這些能力。
當然， cpu和記憶體方面的監控 他們就更熟悉了，他們能夠把記憶體的數據都給你匯出一份，然後分析記憶體的效能，以及應用程式的堆疊資訊他們也可以透過指令碼上報到雲端，以至於使用者的慢服務都不用自己去發現了，運維的工具就能發現，而且還告訴你，哪個執行緒，哪行程式碼的cpu消耗太多，執行的耗時多長等等。有時候我在想，他們都不是開發，怎麽能定位到這麽精準的地方了？還有，他們對perf這個工具運用一點都不遜色於程式設計師！
對Linux的熟悉程度
如果要說誰最精通Linux，那非運維莫屬了，熟悉到什麽程度呢？舉個栗子吧，他們可以讓Linux開機的流程單步執行，什麽意思，相當於程式設計師在debug自己的程式一樣。
比如有一次，程式設計師配置了環境變量，就是改了/etc/profile檔，然後source了一下，發現根本沒效果，這就是一件非常詭異的事情了，正常Centos 都是可以這樣操作的，為什麽那台機器就偏偏不行呢？由於我們使用的是openstack，所以管理的壓力也就到了運維這裏了。重裝系統，不可能的，這麽多重要的東西安裝上去了，肯定是要運維去解決的。
後來怎麽解決的？運維發現source這個動作在內核中並沒有掛載到對應的勾點上面，導致了執行命令也不會辨識到path，那為什麽沒有掛載到對應勾點上面呢？排查了好久，運維直接單步執行了那個Linux系統，居然用到了Linux kernel的偵錯debug技術。後來尋找到原因是因為有的應用程式不小心把記憶體的勾點給替換掉了，如果是開發，真的很難發現這樣隱晦的問題。
我當時是很納悶的，一個運維，怎麽會偵錯程式碼？ 實際上Linux內核程式碼除了運維，又有誰 會 去偵錯呢，其他的套用開發人員並不需要啊，運維人員也是被逼的。
救火能力
有時候，開發寫了個程式，部署到機器上，不一會就導致連線數耗盡了，磁盤IO出現瓶頸了、或者CPU飆高到100%了，但是這個時候，只是表象，只知道Linux機器的資源耗盡了，運維得先找到資源消耗在哪了，才能進一步分析原因，只有找到確實是套用的問題，才能責令程式設計師整改。
然後，運維做到這一步還不夠，他們還得需要進一步定位是不是資源分配不合理了？不能說java行程占用cpu100%了就直接找到開發人員吧，否則就很不夠專業了，高級的運維會分析為什麽是java的占用率太高了，會不會是其他影響了，確認了確實是java程式的影響，才通知到程式設計師去最佳化，生產問題，瞬息萬變，他們又不熟悉業務，要在這樣的復雜情況下作出正確的決策，這一點我想難度不小吧。
網路安全能力
運維的工作，最重要的是機器的管理，網路架構的建設，什麽樣的機器部署對整個系統有幫助？用什麽樣的方式管理是安全的？這些運維都是需要去做的，管理太復雜了，開發會很反感，管理太簡單了，又擔心安全問題。
而且，怎麽判斷安全不安全？出現不安全的問題的時候有什麽手段處理？常見的安全隱患有哪些？惡意流量、提權、不明流量來源，這些東西都得深入分析，如果機器上被植入了木馬，或者被暴力請求了，主要責任還是在運維的，可想而知運維的壓力有多大，這就是重壓之下逼出最強技術。
好了，這些大概就是我所見到的運維的能力，也是我比較關心但是欠缺的能力，很多排查方式我也是跟著運維學習的，運維的東西其實遠遠不止這一些，這樣說吧，除了不用寫程式碼，其他的事情他們幾乎都要會做，所以，你還會覺得運維Low嗎？
3號知乎網友 ： 匿名使用者
用vmsudo把帳戶降級的時候，他連個l都打不出來。還low……
亂改密碼以為可以調戲運維，是吧？ 單使用者模式直接回收root，就沒脾氣了。 許可權控制就這麽任性。
離職清程式碼顯得自己牛逼是吧。 刪除時指令碼自動同步備份，十分鐘內恢復到你不知道的備用環境，你操作的是vip。 不知道我做了雙節點吧？
不好意思，刪除指令我們alias了，當然你也沒許可權看profile。 n+1 沒了開心不？
自動化監控上線後，一舉一動都會被運維盯著。 等devops上了以後，他們的工作就只有送出程式碼了。 剩下的操作全部被許可權分離成碎片。
要報錯日誌自己看ftp。即時同步給你和領導了。
以上操作都不是我故意做的，都是給坑出來的。
程式碼和研發一起離職了，然後程式定時器幹掉了使用者數據。
密碼和IP一起選擇性忘記了, 然後自己做小動作。
送出了bug然後皮球踢過來，然後關機走人。
清數沒寫where變刪表，然後甩鍋擺爛。
由此衍生出的應對措施：
vmsudo許可權控制降權和密碼有效期控制
自動化運維監控，日誌監控，elasticsearch集群儲存
devops開發運維一體化
sql強審計監控DDL和DML
mac與IP埠繫結，VPN與工號繫結
……
當以上坑一個個踩過來了，你就從桌面運維逐漸變成大牛了， 都 是給逼的。
如果開發的存在，是以極度開放的思維盡可能實作軟體功能。
那麽運維的存在，就是以極度保守的目的，從系統層約束控制風險，並盡可能的全面監控預測未來可能導致的風險的存在，並指定應急方案。
運維就是限制開發許可權過度到破壞業務的防火墻。 這個崗位存在的意義，就是保證業務系統的穩定，以一切技術手段應對各方各面的漏洞和bug， 以及最快時間內滅火恢復業務的能力。
其中最典型的火災就是刪庫跑路。這個梗導致的嚴重後果，合格的系統運維菜鳥，可以在十分鐘內修復。
運維必須從架構，系統，網路，資料庫，甚至軟體功能，業務使用等多個層面了解分析產品的效能並保障其穩定的執行，和客戶體驗。
必要之時控制或禁止研發的各種極端操作：
1x年一個研發大佬奇葩操作
定期清理資料庫需求
後台服務自動用drop
然後重新creat database
至於其他配置和歷史數據……
那不是運維的活嗎？我擔心幹嘛呢？
你不會備份匯入嗎？
從那以後dml許可權與研發無緣了
為什麽開發看運維不爽？
因為研發人員從嚴謹的組織結構上，是被運維人員控制、約束和管理的。沒有運維的授權，一行程式碼都無法部署更新到業務環境。 處處被限制，當然不爽。
他們也不想理解為什麽自己的軟體，運維要浪費伺服器資源部署兩份。
為什麽天天要求自己修什麽漏洞不就是個log4j、fastjson嗎
為什麽不讓自己用容易記的123456配公網admin帳戶而是天天強調復雜度和過期時間
為什麽不準自己用select *
為什麽為什麽天天這個不準那個不準
你很low啊不就是cpu記憶體開銷大嗎？不會花錢買裝置嗎
最後為什麽覺得運維low
那是因為正經運維不會告訴研發，自己做了多少預備應急操作。
你，沒有那個許可權。
這是常識，你如果不懂，也沒必要告訴你。
火災發生以前，消防隊就是一群大男孩。滅火器就是浪費錢的擺設，消防檢查就是浪費時間的事， 他們也沒必要告訴你自己高壓水槍能噴多遠，雲梯有多高，滅火彈能扔多遠。 自己的裝置有多少公斤重，為什麽天天要練爬墻……
抽煙的人覺得他們就是玩水槍打水仗鬧著玩，嚇唬人的，很low。
有些回復，說運維優越感爆棚。 這叫優越感麽？ 這居然叫優越感？ 這是最基本的維護常識。 這叫基本職業態度。
如果運維同行沒有這種職業態度，你是不合格的，你肯定會闖禍。
在一個公司寫了屎山程式碼的研發，可以拍拍屁股走人，然後繼續去下一個企業賺個十萬八萬再寫個屎山。反正不會追著程式碼跨省找你。
而一個搞崩了系統的運維，這個闖禍經歷將成為他的黑歷史，並影響到他未來的就業
因為需要專業運維的好企業，基本都是幾百台伺服器起步的大計畫，難免不會查背景，這就導致運維如果想幹得好，圈子會越來越小，請記住是幹得好，不是混得好，混是會出事的。
運維的屎山，就是P1級事故。
倒黴點是跟著自己一輩子的黑歷史。去哪都受影響，只能轉行。
2018年執行反內外網指令碼，搞崩了雲服務商網路導致全球業務故障30分鐘的運維，，他第一時間和他的崗位一起消失了
同年自作聰明清理垃圾數據幹掉了某地郵政系統資料庫的運維，相關行業的HR已經不搜他的簡歷了。此人據說曾是研發，指令碼程式寫的出神入化，就是分不清日誌和數據。
更早2013年清理垃圾幹崩了某地建設銀行db2資料庫的運維，他被領導抓著去一個個低頭鞠躬分行道歉。然後第一時間結束了電腦行業。
為什麽舉這個例子，因為只要是正規大企業的運維，以上都是反面案例天天講，告誡諸位運維要對自己執行的每一條指令負責。
敏感操作double check 高危操作 triple check
作為最後的系統防火墻，運維同時也是系統最大的破壞者。
由此導致的就是極端保守的工作態度和極端苛刻的容災機制。
所以研發覺得這是優越感？這是現實責任壓力下的常規操作。
很多研發的心理是：三十歲前賺夠錢回家買房， 又或者是： 以後去當領導再也不搞技術。
見多了這種家夥，只要給錢誰都賣， 畢竟他們的職業規劃都是技術只幹30多歲
都不用企業淘汰他。
這種心態，是幹不了運維，更替代不了運維的，更沒資格說他們low的。 如果你們繼續以運維會的研發也會的心態看待運維的工作， 我 看好你們成為下一個反面案例讓全國技術圈都認識你。
4號知乎網友： Gambler
一般的運維工作，好一點的程式設計師都能搞定，甚至這些玩意壓根就是程式設計師的必修課，像一般的弄個系統，裝個k8s，弄一套cicd啥的，都在Java面試題裏的東西，老生常談了。
再有就是純硬體方面的工作，比如說整體網路機房啥的，這算不算在運維的範疇我不知道，但我們之前的運維反正是幹過這些事，這些純硬體方面的工作，可能不一定多難，但程式設計師一般也不會，其實也不是不會，就像你會開你的 帕薩特， 讓你把一輛大型的公交車開起來也不是很難，但是讓你去幹幾天公交司機的工作，你還真不一定幹得了，就算幹得了也是擔驚受怕的，就這麽個道理，但是因為學習成本不高，所以依然在鄙視鏈的底層。
再高端一點的，比如說一些高端的硬體，思科的交換機，或者某些工業路由器，這種東西需要一定的知識和經驗才能偵錯的了，程式設計師搞不定，如果只是付出了很少的學習成本也搞不定，在這一塊上就能體現運維的技術含量的。打個括弧，這一塊算運維的工作嗎？我不太確定，括弧結束。
舉兩個很簡單的例子：一，一家公司幾十或者幾百台員工電腦，要求每台電腦的網路是被平均分配的，或者是動態平均分配的，你可不要以為這玩意簡單，當你真的覺得設定這玩意就跟設定家裏的小米路由器一樣簡單的時候那你基本上是解決不了這個問題的，因為你不會。二，設定讓整個網路的硬體裝置的 syslog 都推播到一個指定ip 的指定埠，然後給他們分類儲存，你看，這你就更懵了吧，很多程式設計師是不是都沒有聽過 syslog 是啥玩意？
再牛一點的，那就是對各種程式熟悉到比自己的家還要熟悉的那種，比如說mysql 在centos 上透過各種方式安裝完之後，他自動建立的目錄都有哪些，都是幹嘛的，設定哪個檔能解決什麽問題，給 MySQL 弄個集群或者 讀者分離怎 麽處理，別看程式設計師面試的時候這些問題背得賊6，真正碰到問題能處理的也沒幾個，因為絕大部份情況不會出現問題，哈哈哈哈哈哈，都是做個測試知道原理就成了，最終幹這個活的還得是運維，從這點上來說，沒有誰高誰低，一個偏理論，一個偏套用，而且理論的點和套用的點也不是同一個點，互補吧算是，MySQL 這都不算啥，還有一些更惡心的軟體，光安裝就給你安裝吐，就不一一列舉了。
再另一種就是網路方面，弄個 vpn 啊，代理個網域名稱啊啥的這都是基本操作，我之前開發微信公眾號，後台介面偵錯需要放到伺服器上測試，因為需要在設定的 ip 白名單下，做過這個的都懂我的意思，那時候是十年前，我還是個 小趴菜， 寫程式碼還不是特別自信，也沒有像現在的那種 ip 代理工具，都是寫一點然後打滿日誌，然後編譯到 tomcat ，是的，那時候用 eclipse 加 tomcat 開發，編譯後從 webapps 下找到改動的那個類的 class 檔然後替換掉伺服器上的這個檔，然後重新開機伺服器上的 tomcat ，是的，那時候tomcat 貌似不會自動載入，或者我記得是載入之後會有各種緩存問題，最保險的就是重新開機，重新開機完了趕緊去另一個控制台看日誌這種，那段時間快給我惡心吐了，後來我跟別人抱怨這種情況被運維大哥聽到了，這大哥直接給我一頓神操作，然後那個ip 就擁有了一個 公網ip ，說明一個情況就是我們那個公司是沒有拉專線的，公網ip 實際上是被伺服器代理過來的，現在想想原理很簡單，但是對於那時候的我來說那就是神一樣的操作，當然了，就算讓現 在的我去搞定這個我也不一定能搞定就是了，是的，我很菜。
最後一種高端操作，這種是完全可以吊打絕大部份程式設計師的，linux 內核，是的，玩內核的，對linux 開源玩的爐火純青，小到自己這個指令碼，大到直接改動內核程式碼，他們都能搞定，我之前見過一大哥就專門幹這個，我linux 方面有一半的知識是他口述教我的，有問題不需要先百度，直接先問他，他會告訴我解決思路，然後告訴我怎麽處理，再告訴我要處理的這幾個點的技術名詞讓我去百度學一下，最後再告訴我坑在哪裏需要多註意，是的，當年我倆工位相鄰，學了不少，在此謝過大哥了。
好了，以上就是我對運維的理解了，有不足之處還望指正。
" 開發都認為運維工程師很Low？ " 歡迎在留言區交流，留下你的觀點 ~
整理丨dbaplus社群
來源丨zhihu.com/question/37627701
*僅為提供參考和學習交流，不代表dbaplus社群立場！ dbaplus社群歡迎廣大技術人員投稿，投稿信箱：[email protected]
直播推薦
針對故障MTTR時長，監控系統進一步的機會點在哪裏？可觀測性系統如何用於快速輔助業務線定位問題根因？釘選5月29日周三晚7點， 去哪兒網 基礎架構部技術TL肖雙 老師帶來的【去哪兒網可觀測性實踐】主題分享。
