Try8742
忙不忙主要還是取決於公司，這裡拋開公司不談，說一下運維的3個階段
- 手工運維
- 腳本運維
- 自動化運維
我們以一個例子說一下3個階段。這裡舉一個例子，一個系統升級和簡單故障處理的場景。
首先是手工運維，公司有3臺服務器臺，通過Nginx做的集群和負載均衡，跑的一樣工程代碼。那麼每次服務器升級的時候，就需要人工把每臺服務器都備份了，然後停止每臺服務器的進程，把新的工程傳到服務器上，再每臺服務器啟動項目。這樣是不是很繁瑣，同樣的事情機械化做多次，而且全人工操作也有很大的風險。
在服務器不斷增多的情況下，工作會越來越忙，那麼這個時候就可以引入持續集成的框架，例如Jenkins，它可以很方便的通過我們寫的shell腳本完成上述說的，寫好shell後，只需點擊按鍵，可以一件自動完成從代碼服務器上拉取最新的代碼，然後自動構建為工程，上傳到目標服務器，自動停服備份，發佈新工程啟動。
這樣就需要一次的腳步勞作，減少機械勞動和人為操作的風險，但是還有個問題就是隨著業務的不斷髮展，可能我們需要關注的還有服務器的性能，彈性擴容等，如果我服務器超級多，工作就會越來越重。這個時候就有了新技術例如k8s＋docker＋Jenkins的組合，這裡不太怎麼具體搭建框架，介紹下能實現的效果，引入這一套服務器框架後可以實現，自動備份自動發版，除了上述的，最厲害的是可以實現自動擴容，當你設置一個服務器cpu性能值，例如50%，當我現在有3個服務，每個服務的cpu都到了設定值，k8s框架會根據我們之前設定的一些參數，自動啟動新的服務，並加入集群，如果判斷到某個節點故障了，也會啟動新服務，然後幹掉故障服務。
所以運維工程師忙不忙，除了公司的因數不談，還要看自己是不是善用各種工具技術
TryCatch菌
你好，很高興回答你這個問題。
作為一個運維狗有話說，經歷了手動運維、腳本運維、自動化運維等各個階段，運維工作也由非常忙、很忙、比較忙三個階段，咱們每個階段都說下：
1.手動運維
這個階段一般是新手階段，運維知識儲備不足，思想意識也不夠深，基本是通過手動操作來處理各種問題。兵來將擋，水來土掩。由於手動處理，工作效率不高。因此這個階段隨著各種問題的不斷擠壓，運維工程師將會非常忙，可能真的需要7*24小時工作哦。
2.腳本運維
這個階段隨著運維技能水平的提高、經驗的不斷積累，運維工程師已經可以熟練的運用工具以及相應的腳本開發，實現批量操作。最重要的還是思想意識的提高，能夠主動考慮如何解決問題，這樣驅動著運維不斷的去接觸新工具、新的解決方案。因此運維工程師從非常忙降級到很忙，有了一定的空閒時間去學習新知識。
3.自動化運維
這個階段單純的通過工具或腳本已經不能滿足運維日益增長的技能需求，因此此時通過各種媒體渠道、經驗交流，知道運維過程中不僅僅是處理問題那麼簡單，必須形成一定的制度規範，建立一套監控、故障響應、CI/CD機制，實現不同場景的自動化運維。此時的運維工程師將進入全新的比較忙甚至有足夠的空閒時間，去學習總結，將新的知識點、理念應用到工作中。
最後，運維是一個相對比較複雜的崗位，需要了解的知識面比較廣。當然隨著互聯網技術的不斷更新，運維也需要不斷進行知識的儲備，以便更快速、高效的進行交付工作。
希望我的回答對你有幫助。
我是【木訥大叔愛運維】，歡迎關注，與你分享運維路上的點點滴滴。
木訥大叔愛運維
忙不忙看公司，小公司事情比較雜，相對要忙一點，大公司運維裡面還分很多垂直領域，相對要輕鬆一點。
在互聯網公司，運維崗是個佔比很大的技術崗位，跟開發崗，測試崗並列。一個互聯網產品的生成一般經歷的過程是：產品經理、需求分析、研發部門開發、測試部門測試、運維部門部署發佈以及長期的運行維護。一個產品的生命週期90%以上時間都在運維手中，所以運維的技術含量並不比開發低，甚至入門要高很多。
大公司有硬件運維，系統運維，數據運維，應用運維，安全運維等等，分的細自然要求也高，你要開發很多自動化系統來保證業務x個9的可靠性；小公司這些都是一個人包了，沒有自動化解決方案，很多需要人肉，運維經驗更重要，什麼故障都能很快定位到。
目前運維工程師跟開發工程師的界限越來越模糊，什麼運維開發崗，什麼開發運維崗，都預示著未來不懂開發的運維在運維界很難立足。
