行業裡有個笑話：越高階的運維越像個隱形人！所以樓主是遇到困惑了，提供自己的能力吧！
說到運維，多半是甲方單位招聘的 ，乙方一般是研發和實施。專案結束後甲方需要運維。從基層職位看，運維和開發（含產品經理）的分工還是挺大的。
本人做軟體開發多年，平時主要考慮功能和非功能的實現，運維負責系統上線後系統的穩定、高效執行。所以在所需技術上也大有不同。
開發重點在各種開發語言、開發框架、持續性整合環境、軟體工程、演算法以及對應的業務等等，對底層的執行環境操心的不太多，尤其上了雲環境之後，越來越少操心負載均衡、高可用這些非功能需求。
運維的重點在於系統執行的各種環境，從機房、網路、儲存、物理機、虛擬機器這些更基礎的架構，到資料庫、中介軟體平臺、雲平臺、大資料平臺，偏重的也不是程式設計，而是對這類平臺的使用和管理。
所以開發重建設、運維當然就是維護。所以運維比開發更不受重視也是可以理解的，很難出彩，不出事就是成績，儘管付出的努力並不少，甚至更多。看過產品運營的人說過一句話“不要管開發做出的是什麼垃圾產品，留住客戶才是運維關心的“
但是在高層考慮中，儘管運維仍然受重視程度比不上開發，但已經不僅僅是考慮要儘快滿足業務需求的問題了。基礎架構越來越有話語權。一方面，確實這個是很耗錢的事情（有錢就有話語權）。開發個系統不是有程式碼就能執行的，養個機房（特別是高階機房），動輒投資也得上億，上千臺伺服器也不是那麼容易管的，每年的折舊、報廢也是錢啊，光電費也夠養幾個高階RD了。另一方面基礎架構，特別雲化之後，更是要制約開發使用的語言和程式架構。還有越來越受重視的安全管理，更是巨大的投資，甚至上升到維穩層面。
但是總體來說，運維工程師是IT的後臺，IT是一般甲方業務的後臺。所以，重要是很重要，但是可能永遠不如RD受重視。當然，小部分運維也很受重視，比如製造業，但畢竟是少數。
所以，it運維工程師選擇就沒有回頭路，努力提供自己能力是王道！
行業裡有個笑話：越高階的運維越像個隱形人！所以樓主是遇到困惑了，提供自己的能力吧！
說到運維，多半是甲方單位招聘的 ，乙方一般是研發和實施。專案結束後甲方需要運維。從基層職位看，運維和開發（含產品經理）的分工還是挺大的。
本人做軟體開發多年，平時主要考慮功能和非功能的實現，運維負責系統上線後系統的穩定、高效執行。所以在所需技術上也大有不同。
開發重點在各種開發語言、開發框架、持續性整合環境、軟體工程、演算法以及對應的業務等等，對底層的執行環境操心的不太多，尤其上了雲環境之後，越來越少操心負載均衡、高可用這些非功能需求。
運維的重點在於系統執行的各種環境，從機房、網路、儲存、物理機、虛擬機器這些更基礎的架構，到資料庫、中介軟體平臺、雲平臺、大資料平臺，偏重的也不是程式設計，而是對這類平臺的使用和管理。
所以開發重建設、運維當然就是維護。所以運維比開發更不受重視也是可以理解的，很難出彩，不出事就是成績，儘管付出的努力並不少，甚至更多。看過產品運營的人說過一句話“不要管開發做出的是什麼垃圾產品，留住客戶才是運維關心的“
但是在高層考慮中，儘管運維仍然受重視程度比不上開發，但已經不僅僅是考慮要儘快滿足業務需求的問題了。基礎架構越來越有話語權。一方面，確實這個是很耗錢的事情（有錢就有話語權）。開發個系統不是有程式碼就能執行的，養個機房（特別是高階機房），動輒投資也得上億，上千臺伺服器也不是那麼容易管的，每年的折舊、報廢也是錢啊，光電費也夠養幾個高階RD了。另一方面基礎架構，特別雲化之後，更是要制約開發使用的語言和程式架構。還有越來越受重視的安全管理，更是巨大的投資，甚至上升到維穩層面。
但是總體來說，運維工程師是IT的後臺，IT是一般甲方業務的後臺。所以，重要是很重要，但是可能永遠不如RD受重視。當然，小部分運維也很受重視，比如製造業，但畢竟是少數。
所以，it運維工程師選擇就沒有回頭路，努力提供自己能力是王道！