從事運維一年半，遇到過各式各樣的問題，數據丟失，網站掛馬，誤刪數據庫文件，******等各類問題，今天想簡單整理一下，主要有以下幾點：
一，線上操作規範
1.測試使用
當初學習linux的使用，從基礎到服務到集羣，都是在虛擬機做的，雖然老師告訴我們跟真機沒有什麼差別，可是對真實環境的渴望日漸上升，不過虛擬機的各種快照卻讓我們養成了各種手賤的習慣，以致於拿到服務器操作權限時候，就迫不及待的想去試試，記得上班第一天，老大把root密碼交給我，由於只能使用putty，我就想使用xshell，於是悄悄登錄服務器嘗試改爲xshell+密鑰登錄，因爲沒有測試，也沒有留一個ssh連接，所有重啓sshd服務器之後，自己就被擋在服務器之外了，幸好當時我備份了sshd_config文件，後來讓機房人員cp過去就可以了，幸虧這是一家小公司，不然直接就被幹了。。。慶幸當年運氣比較好。
第二個例子是關於文件同步的，大家都知道rsync同步很快，可是他刪除文件的速度大大超過了rm -rf,在rsync中有一個命令是，以某目錄爲準同步某文件（如果第一個目錄是空的，那麼結果可想而知），源目錄（有數據的）就會被刪除，當初我就是因爲誤操作，以及缺乏測試，就目錄寫反了，關鍵是沒有備份。。生產環境數據被刪了，沒備份，大家自己想後果吧，我不想再回憶了。
測試的重要性我就不再多說了，大家自己體會吧。
2.Enter前再三確認
關於rm -rf / var 這種錯誤，我相信手快的人，或者網速比較慢的時候，出現的機率相當大，當你發現執行完之後，你的心至少是涼了半截。
大家可能會說，我按了這麼多次都沒出過錯，不用怕，我只想說，呵呵，出現一次就夠了。。。你就明白了，不要以爲那些運維事故都是在別人身上，如果你不注意，下一個就是你。
3.切忌多人操作
我在的上一家公司，運維管理相當混亂，舉一個最典型的例子吧，離職好幾任的運維都有服務器root密碼，呵呵。
通常我們運維接到任務，都會進行簡單查看如果無法解決，就請求他人幫忙，可是當問題焦頭爛額的時候，客服主管（懂點linux），網管，你上司一起調試一個服務器，當你各種百度,各種對照，完了發現，你的服務器配置文件，跟上次你修改不一樣了，然後再改回來，然後再谷歌，興沖沖發現問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數。。。這個，我就真不知道哪個是問題真正的原因了，當然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測試無效，再去修改發現文件又被修改的時候呢，，，，多人同時修改很蛋疼哇。。。
4.先備份後操作
養成一個習慣，要修改數據時，先備份，比如.conf的配置文件，另外，修改配置文件時，建議註釋原選項，然後再複製，修改。
再者說，如果第一個例子中，有數據庫備份，那rsync的誤操作不久沒事了吧。所以說丟數據庫非一朝一夕哇。。。隨便備份一個就不用那麼慘哇。。。
二，涉及數據
1.慎用rm -rf
網上的例子很多，各種rm -rf / 哇，各種刪除主數據庫哇，各種運維事故，，，你這1s的疏忽，造成的損失可是相當重大的，大家可以百度，下廚房事件（http://www.infoq.com/cn/news/2013/07/xiachufang-626-disaster-recovery）
呵呵，如果真需要刪除就看看在看看再看看再說吧
2.備份大於一切
本來上面都有各種關於備份，但是我想把它劃分在數據類再次強調，備份非常之重要哇，我記得我的老師說過一句話，涉及到數據何種的謹慎都不爲過。我就職的公司有做第三方支付網站和網貸平臺的，第三方支付是每兩個小時完全備份一次，網貸平臺是每20分鐘備份一次。我不多說了，大家自己斟酌吧。
3.穩定大於一切
其實不止是數據，在整個服務器環境，都是穩定大於一切，不求最快，但求最穩定，求可用性，所以未經測試，不要再服務器使用新的軟件，比如nginx+php-fpm，生產環境中php各種掛啊，重啓下就好了，或者換apache就好了。說多了都是淚啊。
4.保密大於一切
現在各種***門漫天飛，各種路由器後門，所以說，涉及到數據，不保密能行麼，除非你想成爲下一個陳冠希，，，哇咔咔。。。
三，涉及安全
1，ssh
更改默認端口（當然如果專業要黑你，掃描下就出來了）
禁止root登錄
使用普通用戶+key認證+sudo規則+ip地址+用戶限制
使用hostdeny類似的防爆裏破解軟件（超過幾次嘗試直接拉黑）
篩選/etc/passwd中login的用戶，
2. 防火牆
防火牆生產環境一定要開，並且要遵循最小原則，drop所有，然後放行需要的服務端口。
3.精細權限和控制粒度
能使用普通用戶啓動的服務堅決不使用root，把各種服務權限控制到最低，控制粒度要精細，
4.***檢測和日誌監控
使用第三方軟件，時刻檢測系統關鍵文件以及各種服務配置文件的改動，比如,/etc/passwd,/etc/my.cnf，/etc/httpd/con/httpd.con等，
使用集中化的日誌監控體系，監控/var/log/secure，/etc/log/message，ftp上傳下載文件等報警錯誤日誌。
另外針對端口掃描，也可以使用一些第三方軟件，發現被掃描就直接拉入host.deny
這些信息對於系統被***後排錯很有幫助，切忌
有人說過，一個公司在安全投入的成本跟他被安全***損失的成本成正比，，，，
安全是一個很大的話題，也是一個和基礎的工作，把基礎做好了，就能相當的提高系統安全性，其他的就是安全高手做的了。。。
四，日常監控
1.系統運行監控
好多人踏入運維都是從監控做起，大的公司一般都有專業24小時監控運維，其重要性我就不多說了，
系統運行監控一般包括硬件佔用率，常見的有，內存，硬盤，cpu，網卡，os包括登錄監控，系統關鍵文件監控，定期的監控可以預測出硬件損壞的概率，並且給調優帶來很實用的功能
2.服務運行監控
服務監控一般就是各種應用，web，db，lvs等，這一般都是監控一些指標，在系統出現性能瓶頸的時候就能很快發現並解決
3.日誌監控
這裏的日誌監控跟安全的日誌監控類似，但這裏一般都是硬件，os，應用程序的報錯和警報信息，
監控在系統穩定運行的時候確實沒啥用，但是一旦出現問題，你又沒做監控，你就只能呵呵了。。。
五，性能調優
1.深入瞭解運行機制
其實按一年多的運維經驗來說，談調優根本就是紙上談兵，但是我只是想簡單總結下，如果有更深入的瞭解，我會更新，
在對軟件進行優化之前，比如要深入瞭解一個軟件的運行機制，比如nginx和apache，大家都說nginx快，那就必須知道nginx爲什麼快，利用什麼原理，處理請求比apache，並且要能跟別人用淺顯易懂的話說出來，必要的時候還要能看懂源代碼，否則一切以參數爲調優對象的文檔都是瞎談
2.調優框架以及先後
熟悉了底層運行機制，就要有調優的框架和先後順序，比如數據庫出現瓶頸，好多人直接就去更改數據庫的配置文件，我的建議是，先根據瓶頸去分析，查看日誌，寫出來調優方向，然後再入手，並且數據庫服務器調優應該是最後一步，最先的應該是硬件和操作系統，現在的數據庫服務器都是在各種測試之後纔會發佈的，適用於所有操作系統，不應該先從他入手。
3.每次只調一個參數
每次只調一個參數，這個相比大家都瞭解，調的多了，你就自己就迷糊了。
4.基準測試
判斷調優是否有用，和測試一個新版本軟件的穩定性和性能等方面，就必須要基準測試了，測試要涉及很多因素，測試是否接近業務真實需求這要看測試人的經驗了，相關資料大家可以參考《高性能mysql》第三版，相當的好。
我記得我的老師曾說過，沒有放之四海皆準的參數，任何參數更改任何調優都必須符合業務場景，所以不要再谷歌什麼什麼調優了，對你的提升和業務環境的改善沒有長久作用。
六，運維心態
1，控制心態
很多rm -rf /data都在下班的前幾分鐘，都在煩躁的高峯，那麼你還不打算控制下你的心態麼，有人說了，煩躁也要上班，可是你可以在煩躁的時候儘量避免處理關鍵數據環境哇。。。越是有壓力，越要冷靜，不然會損失更多。。。
大多人都有rm -rf /data/mysql的經歷，發現刪除之後，那種心情你可以想象一下，可是如果沒有備份，你急又有什麼用，一般這種情況下，你就要冷靜想下最壞打算了，對於mysql來說，刪除了物理文件，一部分表還會存在內存中，所以斷開業務，但是不要關閉mysql數據庫，這對恢復很有幫助，並使用dd複製硬盤，然後你再進行恢復，當然了大多時候你就只能找數據恢復公司了，，，
試想一下，數據被刪了，你各種操作，關閉數據庫，然後修復，，，不但有可能覆蓋文件，還找不到內存中的表了，，，結果，我就呵呵了。。。
2，對數據負責
再次強調一邊，生產環境不是兒戲，數據庫也不是兒戲，隨手備份一下會死啊。。。不備份纔會死的。。。
3，追根究底
好多運維比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網站老是打不開，經過php代碼報錯，發現是session和whos_online損壞，前任運維是通過repair修復的，我就也這樣修復了，但是過了幾個小時，又出現了，。。反覆三四次之後，我就去谷歌數據庫表莫名損壞原因，1，是myisam的bug，2，是mysqlbug，3，mysql在寫入過程中被kill。最後發現是內存不夠用，導致OOM kill了mysqld進程。。。並且沒有swap分區，後臺監控內存是夠用的，最後升級物理內存解決。。。
4，測試和生產環境
在重要操作之前一定要看自己所在的機器，儘量避免多開窗口，稍不注意就呵呵了。。。
總結，以上幾點是我自己工作體會，大家看了就看了，如有不足，歡迎指教。呵呵。
線上操作規範 測試使用 Enter前再三確認 忌多人同時操作 先看再備份後改 涉及數據 慎用rm -rf 備份大於一切 穩定大於一切 保密大於一切 涉及安全 ssh 防火牆 精細權限控制粒度 ***檢測和日誌監控 日常監控 系統運行狀況 服務運行狀況 日誌監控（安全） 性能調優 深入瞭解運行機制 調優框架以及先後 每次只調一個參數 基準測試 運維心態 控制心態 對數據負責 追根究底 測試和生產環境