Linux 運維一天的工作時間是如何度過的？

12-31

我是名計算機專業應屆畢業生，對linux方面很感興趣，也想以linux運維來開始自己的IT職業生涯，目前掌握了一些linux方面的基礎，想對linux運維這份工作有更多的了解。我想知道linux運維典型的一天是如何度過的，都做了哪些事情，有哪些任務?還請大家不吝賜教！謝謝！

對於這個問題，我有相當的感觸。在我面試了一些運維職位的同學以後，我覺得在中國，很大一部分運維的同學，都是每天過著我以下要提到的，我最不喜歡的最典型的一天。

我最不喜歡的一天：

早上一來到，剛坐下，被一個同事跑過來說一個需求打斷一下。一位同事 im 上也提了一個需求。一位同事郵件上也提了一個需求。一位同事電話你也提了一個需求。好，默默地把這些需求記在 todo list 上。

剛坐下，臨時被拉去開一次會，同事說要怎樣怎樣協助他。

剛回來，發現 10 分鐘後有一個面試。

面試回來，發現 10 分鐘後有一個計劃中的會議。

會議回來，產品功能測試完畢，要協助上線操作。

上線過程沒有標準化，生產環境出錯，緊急回滾。

抓來這次上線相關人員，討論為何會出現這樣的事故，日後如何規避。

回來後，再次準備上線，這次上線過程全程跟進。

終於正常上線完成了。

噢，不。只是功能上線完成，原來還有一個很大的性能問題。繼續救火。

調整參數，性能調優，伺服器負載終於下去了。

看一下時間，已經差不多是下班的時間了。

對著一直在增長的 todo list ，一臉的茫然。

以上，略誇張，但是各種千奇百怪的中斷，確實很可怕，各類中斷還有上下文切換的。很多人就這樣埋沒在中斷中了。

個人認為一個運維最應該的一天工作時間安排：

20% ，處理緊急重要的事情。

80% ，開展重要不緊急的事情的工作。

緊急重要很容易理解，其實就是救火類工作。

重要不緊急的工作，才是最能體現運維的價值的工作。

監控系統，這個是一個大話題。除了被動地監控各類服務的正常與否，還有主動開發各類協助系統分析的系統，並對整個系統的未來有規劃性。

性能調優，我最喜歡的一個方面。發現性能瓶頸，解決性能問題，都很喜歡。

開發工具型系統。提高自己，和團隊內所有人的工作效率的一些工具。尤其是可以快速解決那些中斷的工具。

學習。這個是最重要的。運維涉及的知識面非常廣，不斷學習才能順利快速解決以上各類問題，不斷嘗試不斷經歷才有足夠的經驗遇神殺神，遇佛殺佛。

一天一天，做好重要不緊急的工作，才能令到運維工作更有效率，整個系統更穩定，未來的發展更具有預見性。

以前看過的一篇文章，非原創，《互聯網運維裝腔指南》

當時是在cnbeta上看到的，原創我也不知道，侵權請私信我要求刪除。

感謝運維iBer的投遞

模仿花總寫了篇互聯網運維裝腔指南，供各位參考。

1、全球化的認證有助於提升逼格，什麼OCM、CCIE、RHCA、CISSP等等能考都考，再不濟，也要有一張系統架構設計師或者網路規劃設計師的信產部認證。每過一個認證，逼格提升一檔。如果再有能一個211工程的MSC，那就再好不過了。

2、TCP/IP協議、Linux內核深入研究、ORACLE大全等等之類的超過1千頁大本頭的書能有效提升B格，一定要放手邊。不懂不要緊，別人能看見就行了。真有人跟你談這些，也別擔心裝B失敗，談網路就從TCP的實現談起，談Linux就從內存的管理談起，談資料庫就從各資料庫SQL語句的源碼實現談起。如果有人跟你談MS的東西也不要緊，就說自己之前有多年的微軟的工作經歷，外包的也算。反正也不會有查。有人非要跟你談硬體，最次也要從CPU的指令集的實現談起吧。

3、大眾化的東西要少用。能用ATS，就別用squid；能用postgresql，就別用MySQL；堅信什麼nginx、lighty這種webserver要比apache好一萬倍，而且apache能實現的功能，這些都能實現，不行就自己寫模塊、寫擴展。實在要用apache，也別用高版本，抱死1.3的系統。有人要是問起，就說這是基於1.3的版是自己深度二次開發版本。實在要找不到的話也不要緊，沒事在sf、oschina上看看什麼下載量少的項目，背背項目簡介啥的。不得不說，這兩個網站太貼心，分類都給你做好了。總之，小眾的東西能很有效的提升iBer的戰鬥力。

4、寫腳本的話，別用grep、sort 、uniq、管道這類命令。iBer會選擇使用純粹的awk、sed的實現，長度不要緊，閱讀性、性能也不是問題。功能實現了，別人都還不懂這就是關鍵。如果真有人來請教，也要裝出一副很簡單的表情。切記不要搖頭尾巴晃。就算是你是從《sed和awk》這種書上抄你自己也不一定能看懂的代碼。

5、雖然會shell，但也要少用shell。初級iBer，系統管理會首選perl、python、php這類3p的工具，而且要對shell這種語言有一種不屑。把什麼性能、移植性、面向對象要常掛嘴邊。,如果再能寫二行什麼erlang、ruby、lua這類語言做系統管理，絕對是iBer的裝B神器，也是中級iBer的標準。高級IBer會有Haskell這類函數式語言進行系統管理，這絕對是裝B的B2轟炸機呀。當然，資深iBer會返璞歸真，使用面向對象進行shell編程。對，你沒看錯，是使用OO進行shell編程。

6、iBer對談到Redhat、ubuntu這類大眾發行版本時，會回復一個字「切！」LFS、Gentoo這類系統絕對是iBer們首選。不為什麼，就為在無窮盡的編譯中找到屬於iBer的快感。如果非裝大眾發行版，iBer也會從開機畫面、登陸提示等等地方打自己上深刻的烙印。iBer的寂寞豈是一般人能懂的。

7、iBer對什麼checkpoint，juniper等表示不屑。必須天天把iptabes的鏈和表都掛在嘴邊，尤其是mangle表。原則上對商用產品的一律不屑一顧，什麼f5，radware一律自己開發實現。至於意外的將自己關在外面的事情一定要嚴格遵守各自公司的保密協議。

8、iBer的操作終端呢，像SecureCRT、xshell這種絕對是不用的，一定要用最原始的，什麼黑屏綠字只是初級iBer的水平，中高級iBer的都是Alpha半透明終端，桌面背景在設置個全球internet流量趨勢圖。讓你根本就不知道他天天對著屏幕在敲什麼東西。有事沒事編譯一些大型軟體，看著翻滾的屏幕做思考狀。

9、名片的title一定要是系統架構師，沒有名片也不要緊，什麼QQ簽名、人人狀態、微博簡介上，有人看的地方一定要寫上。這些都是提升B格的好地方。

10、初級iBer談流量、PV、自動化；中級iBer談流程、談規範，什麼ITIL、ITSM要常掛嘴邊；高級iBer談架構、談模式；資深iBer談合同、談成本。

11、混圈子對iBer來非常有必要的。什麼XX沙龍、XX架構師大會、XX優化大會之類必要是常客，露個B臉就行。基本原則就是跟搞系統談網路，跟搞網路的談資料庫，跟搞資料庫的談安全……對方不懂什麼就談什麼對就了

12、骨灰級iBer早就超出三界外，不在五行中，他們註定有著傳奇的色彩。他們正忙於對iBer們進行職業發展規劃。iBer助理、iBer、高級iBer、資深iBer、iBer總監直至CBO。如果發展了到了CBO，那麼你一定是一位驚天地、泣鬼神的一代B神，一統江湖的教主，供萬千iBer敬仰。darling，我很看好你喲！

三年過去了，一點變化都沒有

======================

遊戲運維:

早晨起床揉揉惺忪的雙眼, 一邊刷牙, 腦子一邊在回想凌晨四點被客服叫醒處理的故障, 心中咒罵著那該死的硬碟. 嗯...... 黑眼圈又深了.

背上電腦包去擠地鐵, 拿出手機看看起點小說, 順便瞄幾眼報警簡訊, "No route to host"? 流量又超了啊....

到公司, 口胡.... 9:08分了, 到公司看看監控頁面, 屁股還沒坐熱就去給同事修電腦了. 看看開服計劃, 準備把腳本整理整理的時候廣告部門說西北地區廣告載入又慢了, 運營的來說海外的大戶玩家又上不去了(FUCK GFW!!!) , 採購部門來問固定資產的資料, 開發部門說這幾張表給導一下到內網. 嗯...... 還好今天沒有定時任務失敗的情況,感謝上蒼.

下午昏昏沉沉手工跑腳本開服,心想老子有一天都要用puppet自動開 (實踐證明用fabric吧)! 聯運哭哭鬧鬧說自己的伺服器比較卡, 用監控圖表打敗他們 XD. OA又卡了, 重啟了之. 看看伺服器精簡計劃嗯... 無甚新意. 刷刷微博,虛擬化雲計算高性能集群演算法架構架構架構, 架構你妹啦神仙道這樣的index lb直接生成,戰鬥統一用erlang算的才有架構好么,破網頁遊戲一個服歸一個服的個個跟私服一樣合服累死人的有個屁架構啊! 收藏幾個鏈接騙自己說有一天會看的,然後默默叉掉chrome.

你們問老大哪去了? 廢話么當然是開會啦.

搜索引擎維護：

正常的一天，8點半起床，9點半到公司開始一天的工作

上午：

)看看昨天的超時報表，看看那個系統超時比較多。

)從監控圖中查查超時比較集中的機器，看看機器的基礎監控，硬體有沒有故障，有沒有人誤操作，有沒有人在沒有通知的情況下訪問引擎等，查到原因，和開發商議解決方案和deadline，回復郵件。

)處理各種報警，半開發和QA解決測試環境問題。

)刷刷微博

下午：

)預約的上線，開始上【僅限於離線部分，在線部分凌晨上】，不出問題的話一般半小時以內

)寫一寫重要而不緊急的監控

)想一下今天遇到的問題，baidu，google，問題，弄明白之後記錄下來

晚上9點前：

)寫代碼的好時機，此時是你無人打擾寫自己認為有意思且總要的東西的時候

)如果有想學習的東西，學習之

)刷刷微博

晚上10點到2點：

)如果趕上上線的話，一般是凌晨開始，1點多冒煙之後沒問題就結束了。如果有bug，回滾之一般在1點也能結束

救火：突發性故障不可避免的會產生

中斷：產品、程序、QC誰都能找你，事情可能也是千奇百怪，無法一一道來

求知：你需要懂的內容可不少，包括為了「對付」上面的中斷

開發：各種協助運維的系統

補漏：已經BUG，可預見性的問題、缺陷

規劃：高預見性，大局觀

IT人喜歡自嘲，稱自己是「IT民工」、「碼農」等，無論對挖苦自己多麼地「樂此不疲」，但其實他們骨子裡流淌的都是對這個行業的驕傲。可是，擁有這樣一份驕傲的工作為什麼還要自嘲呢？除了有可能是「滿足虛榮心」之外，最主要的原因就是「工作真的沒含量」。

研發工程師一般稱為RD，即ResearchDesign，通常RD需要「使用」多種開發語言以完成不同工作。一般來說，公司業務迭代都很快，項目催得急， RD為了快速完成項目，不得不捨棄深入學習某一技術的想法。這就暴露了一個問題，多數RD只達到了「會用」的階段，很難「掌握」，比如會用一個框架就行了，會用一個庫函數就行了，為了快速完成任務，不求甚解。因此，很多RD自稱碼農是有道理的，他們的工作就像流量線一樣。如果你問RD：「在這麼多種語言中切換自如，你好厲害啊」，他們一般會說：「沒啥含量，照著例子寫唄…」，當然有可能是他們在謙虛。

運維工程師一般稱為OP，即OPeration。從名字上就能看出運維工程上主要工作是「操作」。儘管如此，運維還是需要寫代碼的，但是寫代碼的工作畢竟不是OP工作的全部（甚至只是小部分），很多情況下，OP和RD一樣也是照著例子改代碼。相對RD同學，咱們OP在代碼方面是業餘的，何況，很多RD同學也只是到了「會用」的程度。

現在流行「全棧工程師」，也就是掌握多種技能，能夠獨擋多面，獨立完成一個產品的技術大牛。但人的精力是有限的，掌握的越寬就意味著掌握的越淺，儘管在業務上「以一敵十」，但還是不能「一勞永逸」，需要與時俱進、不斷學習新技術。沒有絕對「一勞永逸」的方法，但有相對「一勞永逸」的途徑，萬變不離其宗就是這個道理。

在高手的眼裡，技術是沒有區別的，只是外在形式有所不同。正如天下武功出少林，各類武功都是以少林武功為「基類」擴展的，因此少林高僧能一眼看出各種武功的共性，因此稱天下武功是一家。像峨眉、武當等不同派系的武功，在高手眼裡都是一樣的內功+外力的組合運用，只是外在形勢不同而已，而一般人只會看到不同的外在，因此在他們眼裡，天下有很多種不同的武功。

在運維剛剛興起的時候，OP能做的工作，大部分RD都做不了，那時候的OP還是蠻有存在感的。比如他們除了配置、優化伺服器外，還要承擔一部分的安全、資料庫維護、機房建設等工作，還要配置路由器、交換機做網路規劃，甚至掐水晶頭做網線。這些活兒很少有RD能做下來。

幾年下來，基礎維護越來越細緻規範，開始有專職的DBA負責資料庫，SA負責系統，NA負責網路。OP剩下的工作就是裝軟體，部署環境等業務維護，我們成了名副其實的「保姆」。也許我這麼說傷害了您，但您想想，RD為什麼讓我們裝軟體？他們自己不會裝嗎？原因很簡單，在RD的認知中，OP就是干這個的，就像地上髒了，咱們首先想到的是找保潔阿姨。說白了，RD會讓總監或CTO給他們裝軟體嗎？換句話說，RD會讓比他技術更牛的人給他打下手嗎？這裡面的道理不言自明。如果想讓RD高看OP，OP必須要在RD的價值觀中征服RD，這樣OP才能翻身，RD的價值觀是技術為王，打鐵還需自身硬，OP要提升技術內功。無論是從架構還是設計部署方面，OP的使命始終是維護業務穩定，這才是體現OP價值的體現，我們應該是業務的主人而不是保姆，這才叫掌控業務。

不過話說回來了，有些OP還是很厲害的，他們會指導RD如何改代碼，但這畢竟是少數，他們要麼曾經是RD，要麼是開發運維。

說了這麼久，我就是不想成為保姆，我想成為業務的主人，那麼我們就需要改變自己的角色。正如修車技術最好的，永遠不是維修人員，肯定是車的設計師。您想，他都會造車，那麼對車具有絕對控制力，對每個細節都了解的人肯定會修車。掌握了最底層的技術才會增加內功，學會了更難的技能，那些表面上的技術學起來才能更輕鬆，因為你能看到這些淺表技術背後的本質。就像動畫片《七龍珠》，悟天是先變成了超級賽亞人後再學舞空術的，這樣反而更容易學會。

都說谷歌的OP是最有技術含量的，他們是全棧式運維，因此RD也要聽取OP的意見。我相信BAT中這樣的OP也不少，但從我國大環境來看，運維行業還是較國外落後，我們的運維還有一段路要走，我希望我國的互聯網公司在技術方面也是運維主導。

技術人員需要的是一種快速解決問題的能力，這背後需要紮實的知識，猶如冰山在水面上雖然只露出一點點，但如果沒有水下的巨大部分做支撐，那一點點我們都看不到。

在計算領域中有幾塊「硬骨頭」，操作系統是其中一個，它是所有應用軟體的根基。儘管我們大部分的工作都是寫應用軟體，可是如果我們也能夠創造一個操作系統，那麼操作系統對我們來說便不是黑盒。了解了內核為軟體提供服務的機理後，我們在開發應用軟體、執行命令時便成竹在胸，這正是我推薦《操作系統真象還原》的原因，這是一本「一步步編寫操作系統」的書，它的使命是讓操作系統的學習不再盲人摸象，徹底揭開操作系統的面紗。這本書我脫產寫了19個月，詳細闡述了一個最基本的操作系統從原理到實現的過程，捨棄了大量的內核管理策略等「無關」的代碼，直接復現內核的本質，因此，最終完成的操作系統，代碼量僅為6023行，大大降低了學習難度。

也許有人會說，學操作系統編寫是很耗時的，我們把大量的精力放在了這方面，而且這方面並不能讓我們有實際的產出，值得嗎？

有句話叫磨刀不誤砍柴工，我們暫時的後退是為了助跑，可以跳得更遠。我舉個例子，李連杰功夫那麼厲害，他會太極、洪拳、套路等等，但他會小學生的廣播體操嗎？我看未必，不過值得肯定的是，由於李連杰有了紮實的功夫底子，廣播體操也顯得更容易，對他來說，分分鐘就能學會。

操作系統只是計算機工程的一個方面，只要我們多付出努力就能夠掌握，當然把操作系統寫好還是不容易的，這涉及到管理方面的策略，但不管好不好，能寫出來就是很不錯的，因為從0到1是有著本質的不同。然而技術的頂端永遠是演算法、數學，這不是一蹴而就的，要想在這方面有所建樹，除了天份佔據著主要因素外，也需要我們長期的積累。

做為一個OP，我希望給這個行業爭口氣，提高這個行業的形象還需要我們自身的努力。

文章來自：《操作系統真象還原》作者鄭鋼

你想更深入了解學習Linux知識體系，你可以看一下我們花費了一個多月整理了上百小時的幾百個知識點體系內容：

【超全整理】《Linux雲計算從入門到精通》系列實戰筆記全放送

看情況. 有些地方的運維每天下棋打麻將扎金花. 有些地方的就忙到死, 晚上睡覺了還會收到報警器的報警... 完全沒法比..

1，等待監控系統報警

2，核心系統巡檢，備份系統備份任務完成情況巡檢

3，等待用戶報障

4，例行任務計劃攥寫，例行任務執行，比如新開用戶，存儲擴容等；

5，項目性的工作，比如新購存儲，新的監控系統，新的操作系統，應用系統驗證

6，學習新知識，看技術文檔或者公司的各種通知

7，和不同供應商（工程師），內部人員開會

我的日常大概如上；

重啟服務

改配置

告訴開發人員不能這麼干

告訴開發人員應該這麼干

告訴運營人員上傳文件不要太大

告訴小夥伴這裡有坑，小心不要掉進去

看到小夥伴掉到坑裡，會幫他們跳出來。

看到新東西就興奮。

while(1)

{

早上一般9點起床吧，折騰一下9點半到公司，一般吃著路邊買的餅，一邊看看kindle上訂閱的新聞，技術章。上午就自己搞搞興趣的東西，寫一些改進目前工作的腳本。接受一下開發測試的諮詢，幫他們搞一下研發環境的問題。下午事情比較集中，一邊開會一邊處理一些線上的問題，基本自己都是同時起三個以上的線上，自己的大腦不是超線程的，但是一般確實得同時搞N件事情。

到了下班時間事情還有一堆，晚上繼續搞搞，每天都想早點下班，每當你準備走的時候郵件,IM，電話又來一堆。。。

回到家，上上網，看看文檔，看看OS,TCP/IP等等基礎的名著陶冶一下情操，搞到12點，睡覺

}

受邀簡單講講：

1. 處理報警，查看報警的原因，和開發一起解決，並且盡量找出避免再次發生的方法，例如添加一些定時清理腳本

2. 處理髮布，基本都是自動化，但是總有發布不成功或者需要回滾的時候，這時候就需要手工介入，找到原因，並跟開發一起討論最後是否撤銷還是重上

3. 日常一起能夠自動化的工作盡量找到自動化的方法

4. 會啟動一些和運維相關的項目，所以有時候也兼職項目開發

5. 學習，看看新聞，學習資料等等。

在公交上看各種crontab執行結果的簡訊。掃了眼沒問題開始看技術文檔。

到公司處理nagios報警和客服提交的問題。其間接下各種研發和產品的需求，不合理的駁回去（你總會遇到一些經常異想天開的產品。。。）。

研發說客服那個問題需要倒庫到內網查。

DBA給發份文檔說今天有幾種新加的日誌需要入庫，裡面是表結構和關鍵字，最近新開的服日誌量太大，一起研究怎麼優化下。

處理各種需求。

繼續寫昨天未寫完的工具。寫完後扔給值班，告訴怎麼用。

學習。

看錶，發現已經下班了。

淡定。。。繼續學習，琢磨應該要寫一個新的工具。。。

幹了幾年運維，說說感受

早上起來打開nagios，看到一串的報警，比如日誌空間不足80%，某個備份沒成功，某個計劃任務執行失敗，某個資料庫的索引建立失敗，等等等等....手動全部解決大約11點。看看昨天值班的日誌，各種上線，各種下線，各種修修補補，nginx主配置里增加了14行，8個配置文件；DNS配置增加N行；兩塊硬碟要換，一台存儲機頭要換，已經下線在機房等DELL過來換。給IDC的同事打電話確認這些亂事....

開發和測試說某個項目的性能要提升到20W/小時(其實這個項目每日獨立ip沒超過200)，編輯說讓我們給他們轉換幾萬個文章的UID，給三個部門的header寫郵件「不給項目加伺服器、把轉uid的任務交給dba」，然後被vp交去辦公室說--要儘力配合其它部門，不能推來推去.......回去給值班的同事寫郵件說把某個項目加2台伺服器，怕被罵只能自己轉uid....這就一天結束了。

來公司一上午發獃下午繼續發獃。新手不知道幹啥

上班，看日報，看新聞，看新聞，吃中飯，睡覺，看日報，看新聞，打遊戲，打遊戲，下班，看新聞看新聞，8點下班回家

要看階段的，這裡分享下個人在一線運維崗位上「非突髮狀態」中比較經典的一天

09：30-10：30 黃金時間

項目群say hello報告就位後，查看郵件+rtx+QQ+各種日報+業務版本線狀態，分析「前一天」制定的todo_list中的變數

10：30-11：30 最優先解決的問題

短時間內需要有結果的問題，除前一天工作的繼續外，也有可能是昨晚core的進程debug，緊急版本更新，沒收斂的告警，項目組突發需求，必須要回的郵件，必須要找的協調人，方案討論。。。。

11：30-12：00 糾結時間

吃飯，馬上go？或者繼續扯會淡

12：00-14：00

吃飯+遊戲+睡覺

14：00-16：00 「大段」的幸福時光

todo_list執行+刷新，有可能是大段的編碼時間，也有可能是大段拿來發獃想「這個問題如何解決「的時間，有可能是業務優化（程序性能、功能調優，現網待解決問題，監控發布等工具的完善等等），預算、個人kpi，業務上蛛絲馬跡的刨根究底。。。如果不幸分配給了「會議」的話，這一天可以休矣，考慮12點能不能回家。。。。

16：00-18：00 出活

腳本、工具階段性的調試驗收，需求驗證，當天各種跟進事項的狀態

18：00-未知第二個黃金時間

當天todo_list正式開工的時間。。。加油吧，少年！

~~~~~~~~~~~以上工作安排的前提是不可預料的電話+msg轟炸不至於讓你生活不能自理。。。

ps：突髮狀態是指運維處於需要」緊急響應「的狀態，只處理當前事物，比如現網運營事故，版本問題的測試調試等等

9點後到公司(9點上班，習慣性遲到一點)

打開公司網站首頁

打開zabbix screens（各web伺服器流量圖，流量匯總圖）

吃早餐

偶爾看看python，總是學了放下並不知道用來幹嘛

鋤禾日當午，

不如運維苦。

對著破電腦，

一調一下午。

理想中的時間劃分：20%時間事務性工作，60%時間建設性工作，20%時間思考規劃整理

------20170511-------

3、4年過去了，很高興大部分時間都花在學習和改造現有系統上了，救火的情況也有，但是真心不會多。

這3、4年最大的變化就是跟各種雲的介面打交道越來越多了，甚至已經成為最重要的一部分。

過很長一段時間再回來補。

百業待興階段

1. 跟程序交接布署，問清楚環境、運行參數

2. 梳理

3. 搭建支撐體系

4. 自動化

5. 執行做好的自動化布署

6. 看有沒有毛病加以改善，循環4-6.

經濟起飛階段

1. 依照流程開新伺服器，搭建、遷移、例行維護等

2. 撰寫自動回報腳本、監控主機

3. 與團隊研究批量布署的方法，並計畫投入測試環境、生產環境的日程

4. 開會，研究流程，知識總結

5. 救火

6. 待命, 4,5,6循環不息

養老階段

1. 培養運維團隊

2. 接手項目管理

3. 接手其他主管代辦事項

4. 研究自己的程序興趣

5. 考慮轉行