總結兩句話：
1、保障業務長期穩定運行（如網站服務器、遊戲服務器等）。
2、保障數據安全可靠（如用戶名密碼、遊戲數據、博客文章、交易數據等）。
由這兩句話推演運維工程師要學些什麼？
穩定
出一點點差錯，用戶就要投訴了。
1、業務跑在什麼上面？
網站服務器一般是apache,nginx,tomcat等。但是真正跑通流程還需要Mysql數據庫來存儲用戶密碼及其它。很多程序都要php的解析，所以LNMP、LAMP(即nginx、apache、mysql、php)環境部署是必須掌握的技能。
2、業務出了問題怎麼及時知道？
這就需要監控軟件來郵件或短信來通知你，常用的有zabbix,nagios等。報警發郵件，也得一個郵件程序呀，sendmail或postfix。
3、在家裏收到報警，但服務器是內網IP，怎麼也得解決問題吧？
在公司搭建openvpn或pptp或openswan，在家裏通過VPN撥入內網，24小時解決問題…唉，半夜爬起來解決問題也沒工資。
安全
出一點點差錯，領導要找你喝茶了。
1、有時需要手動改數據庫內容？
所以要會基本的Mysql數據庫增刪查改命令。
2、萬一數據庫服務器硬件壞了怎麼辦？
需要有個備庫以備不時之需，所以需要Mysql主從複製。
3、數據庫要還原怎麼辦？
所以需要在crond中定期全備Mysql數據，以便還原使用。如果要還原到指定時間點，還要學會Mysql增量備份與恢復。
4、如果是用戶上傳的圖片或文件服務器壞了怎麼辦？
定時備份可能還不夠，需要使用rsync加inotify來實時備份。以便任一時刻主服務器壞掉，也能保障所有圖片有備份可以用來恢復。
5、小心黑客，要增加服務器安全性？
ssh輕易不能讓外人訪問，那麼就設置只允許公司的IP或跳板機IP訪問，這些都通過iptables來控制。
6、說一下你們公司怎麼發版的（代碼怎麼發佈的）？
筆者回答：我說什麼來着，這個問題又問到了。發佈：jenkins配置好代碼路徑（SVN或GIT），然後拉代碼，打tag。需要編譯就編譯，編譯之後推送到發佈服務器（jenkins裏面可以調腳本），然後從分發服務器往下分發到業務服務器上。
7、如果你們公司的網站訪問很慢，你會如何排查？
其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路:
1)**要url或頁面:**問清楚反應的人哪個服務應用或者頁面調取哪個接口慢，叫他把頁面或相關的URL發給你，
2)chrome瀏覽器分析最直觀的分析就是用瀏覽器按F12 (network->waterfall)，看下是哪一塊的內容過慢（DNS解析、網絡加載、大圖片、還是某個文件內容等），如果有，就對症下藥去解決（圖片慢就優化圖片、網絡慢就查看內網情況等）。
3)觀察後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問接口日誌纔會打出來。
4)排除sql，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。
大性能
1、越來越多的用戶來訪問我們的網站，一臺web服務器抗不住了怎麼辦？
那就需要多臺web服務器來負擔，但多臺服務器之間怎麼進行負載均衡呢，這就需要用到nginx反向代理或(LVS+keepalived或haproxy+heartbeat了–>高可用)。
2、用戶註冊發表的文章與評論太多，一臺數據庫抗不住了怎麼辦？
數據庫壓力分爲讀和寫，如果寫抗不住，需要進行分表分庫到多個服務器上。如果是讀壓力不夠了，可以使用mysql-proxy讀寫分離，
來分擔讀的壓力。更簡單方便的方法，把數據庫裏的內容放到內存上，這就用上memcache或redis了。
3、N多用戶上傳下載文件，磁盤抗不住了怎麼辦？
把多塊磁盤做成raid，或者使用分佈式存儲文件系統如MFS，GlusterFS來提高磁盤的讀寫能力。
4、網站上好多圖片，總有用戶反應網站加載太慢，怎麼辦？
這時可以把網站上的圖片通過squid或varnish緩存到網站前端，儘可能的增加訪問速度，當然，最好是購買商業的CDN加速。
5、運營商是個大難題，他們之間的帶寬好像很小，聯通IP訪問我電信網站怎麼就這麼慢呢？
這時可以使用bind自建一個DNS服務器，把網站的DNS記錄指向自建DNS服務器上，配置好解析規則，以後聯通IP解析到聯通網站上，
電信IP解析到電信網站上，體驗就會好很多啦。
自動化
終極目標：跑死機器，閒死人。
1、公司新買100臺服務器，公司竟然就1個移動光驅，這裝系統得到什麼時候？
使用kickstart或cobbler來網絡遠程自動安裝系統吧。
2、每次裝完機要優化很多內容，什麼文件描述符、端口、軟件安裝啊，手動操作不累死去？
趕緊學會shell，將解放非常多的工作量。
3、系統裝完後登陸要輸入密碼，這麼多臺啊？
使用expect吧，自動讀取提示來輸入密碼，並執行命令。
4、要批量把新代碼發佈到線上服務器，怎麼辦？
使用saltstack或puppet或ansible吧，絕對爽歪歪。
素養
安全
運維人員的權限很大，所以一定要保證帳號/私鑰的安全。
最好使用加密工具存儲。比如truecrypt，1password
基於本地存儲。切勿用網盤，也不建議用lastpass等
ssh私鑰添加密碼
以上任何一點都很重要，否則弄丟了，風險會非常大。
責任心
遇到報警，第一時間處理，而不要等着他人去處理,如果無法處理，應該第一時間讓同事協助幫忙，而不要禁止報警，讓問題掩蓋
細心
1.你的任何一個操作，都可能造成系統的損壞、業務出問題。所以敲命令時一定要細心、再三確認。你敲的再快，也就節省那麼一點時間，出了問題纔是大事。
2.在項目上線前,除了關注功能的測試,還要關注部署、備份、監控、安全以及配置管理,在早期發現的問題越多,越能盡少後期的問題並避免影響用戶體驗
3.建立各個團隊的核心成員定期溝通機制(團隊之間的協作納入績效考覈過程中去)
4.如何從開發的角度去做運維工作( 1)運維去了解代碼的模塊結構,從運維的角度修改代碼,讓產品上線後更方便運維與適應生產環境的特點。2)運維參與到持續的集成測試中,用自己的自動化知識幫助實現自動的集成測試等。)
5.工作量如何體現?
週報
推進/改善
如果代碼有問題，導致系統開銷很大，比如負載，io等。應該第一時間和開發部門確認，要求優化代碼。
進取心/不斷學習
運維的知識範圍很廣，要不斷學習。遇到問題，做好分析記錄，事後還可以在部門內分享交流。
一定要整理分析, 好記性不如爛筆頭!!! 沒有誰能一步登天, 牛人都是從1+1開始學的, 爲什麼有的人會成爲牛人, 定期整理分析是必不可少的. 沒有整理就不能成爲自己的知識.
團隊溝通
在開發過程中,團隊之間的衝突和抱怨是避免不了的,但是產生的影響基本一樣：
1.產品上線的進度延誤，整個團隊很難正常交付新版本。
2.產品上線後問題很多，影響用戶的訪問。
3.團隊的士氣很差。
運維問題：
1.產品開發一點計劃都沒有，突然要上線機器，讓我們措手不及。
2.設備使用不規範,帶寬被跑滿導致網絡出問題.
3. 開發的代碼太不靠譜,一上線就引發用戶投訴,只能回滾到老版本。
開發問題：
1.開發需要了解生產環境是什麼樣,否則不好開發代碼,那麼運維是否可以直接接觸線上的系統?
2.如何處理關於項目上線後出問題,運維直接回滾了.
3.代碼在測試環境或我的機器跑的好好的呀，怎麼一上線就出問題呢.
(測試怎麼測的，那麼多問題發現不了)
4.運維同事幫忙搭一個跟線上一模一樣的測試環境.
測試問題：
1.開發人員不寫規定寫單元測試代碼.
2.爲了實現開發的業務功能,想着能用一個自動的集成測試環境.
3.測試環境跟生產環境不一樣,很多問題不好發現.
4.bug沒修復完,產品急着上線.
解決方案:
借用devops理念來處理團隊協作問題:
1.推出新功能和解決老問題的週期過長
2.不同團隊相互隔離,配合差.(如開發人員收到問題後，第一反應是“在我的機器上工作得好好的呀”)
DevOps更象是一種運動，每家公司都需要根椐自身的特點進行借鑑，推動團隊之間的協作與合作。需要在三個方面努力：
-
人員
一方面對現有人員進行培訓，鼓勵他們瞭解別的團隊的工作、面臨的挑戰等，讓他們用自己的特長去審視和幫助別的團隊，另一方面也想辦法招一些全面的技術人才，在不同團隊之間搭出一些適用的橋來。 -
流程
在研發的前期，讓系統運維同事參與起來，一起搭建測試環境，驗證想法，或者也可以在一些項目團隊中直接配有系統、開發和測試以及產品人員，一起爲產品的上線努力。出現問題的時候，一起想方法找到問題的真正根源，避免相互推託，將解決方案落實在以後的研發過程中。從績效考覈流程上也需要考慮協作因素。 -
工具
說實在的，大家針對DevOps在工具方面其實討論得更多，這裏面跟敏捷有些類似之處。快速的系統部署和自動化產品代碼發佈方面的工具顯得尤爲重要了。
其他
1、搭整套測試環境需要5臺服務器，但公司窮的只有一臺空閒服務器？
學會xen或kvm或docker吧，虛擬出多臺服務器，就能解決資源問題了。特別是docker，強烈推薦，以後某個研發人員讓你部署一套新環境，分分鐘幫他解決。
2、研發人員的代碼控制，權限控制，總要運維人員管呀？
svn或git，這個是肯定要有的。
3.權限相關問題
問題1：你們公司是如何來管理用戶權限的？
答：我們是通過sudo來管理權限的，不論是運維還是開發，一般都不會給root權限，只有核心級開發或者研發總監或以上級別的我們纔可能給相應服務器級別的權限；對核心運維或者運維總監纔會給root權限
問題2:規劃服務器的時候，在服務器上都跑幾個普通用戶？
答：我們的普通用戶是根據項目來的，在不同公司它的項目產品線不一樣。我們公司只有十幾個產品線，我們爲每一個項目建立一個普通用戶，因此不論nginx還是tomcat都是跑在普通用戶下。
問題3：那一些公用服務呢？比如memcached或者redis。
答：這些公共服務也可以跑在普通用戶下，總的來說是這樣的，我對運維的理解是，運維做運維的事情，開發做開發的事情。運維負責網絡系統，只要系統沒有故障，只要網絡沒有故障，只要系統資源還夠用，那麼我們運維的職責就到位了。而我們公司的理念是項目負責制，也就是說每個項目的責任人是開發，我們運維大概佔30%-40%的責任。我們的開發佔60%的責任。當進程上線的時候，這個服務是由普通用戶跑的。它的每個站點目錄都是普通用戶的權限，也就是700的權限普通用戶，這個是最安全的。無論是項目的啓動，停止，以及代碼上線，日誌收集，日誌分析都是通過我們進程跑的普通用戶實現的。我們在管理這個項目的時候，我們可以把開發的用戶加到這個項目組裏面，這樣負責相應項目的開發人員就有對應項目的所有權限。
結尾：
現在我們在回過頭來思考，運維工程師平時幹些啥呢？
1、 隨時解決報警故障。
2、 業務程序更新。
3、 編寫一些腳本，監控或完成其他可自動完成功能。
4、 運維架構完善，部署一些用起來更方便更可靠或性能更好的開源工具以及制定運維流程規範。
5、 打雜，如調交換機，裝系統，部署新環境等。