以為很熟悉 Linux，萬萬沒想到在生產環境翻車了.....

從事運維工作多年，遇到過各式各樣的問題，資料遺失，網站掛馬，誤刪資料庫文件，駭客攻擊等各類問題。也見過很多小夥伴們，自以為對Linux系統很熟悉，一看到問題，從不心慌，信心滿滿的，但是生產環境翻車（差點被開除）的名場面，數不勝數。 。 。

所以，今天簡單整理一些好的 Linux 操作習慣，分享給各位小夥伴。讓我們安全操作，永不翻車！ ！

線上操作規格

#測試使用

當初學習Linux的使用，從基礎到服務到集群，都是在虛擬機做的，雖然老師告訴我們跟真機沒有什麼差別，可是對真實環境的渴望日漸上升，不過虛擬機的各種快照卻讓我們養成了各種手賤的習慣，以致於拿到伺服器操作權限時候，就迫不及待的想去試試，記得上班第一天，老闆把root密碼交給我，由於只能使用putty，我就想使用xshell，於是悄悄登入伺服器嘗試改為xshell 金鑰登錄，因為沒有測試，也沒有留一個ssh連接，所有重啟sshd伺服器之後，自己就被擋在伺服器之外了，幸好當時我備份了sshd_config文件，後來讓機房人員cp過去就可以了，幸虧這是一家小公司，不然直接就乾了……慶幸當年運氣比較好。

第二個例子是關於檔案同步的，大家都知道rsync同步很快，可是他刪除檔案的速度大大超過了rm -rf,在rsync中有一個指令是，以某目錄為準同步某文件(如果第一個目錄是空的，那麼結果可想而知)，源目錄(有數據的)就會被刪除，當初我就是因為誤操作，以及缺乏測試，就目錄寫反了，關鍵是沒有備份……生產環境資料被刪了，沒備份，大家自己想後果吧，其重要性不言而喻。

Enter前再三確認

關於rm -rf / var 這種錯誤，我相信手快的人，或者網速比較慢的時候，出現的幾率相當大當你發現執行完之後，你的心至少是涼了半截。大家可能會說，我按了這麼多次都沒出錯，不用怕，我只想說當出現一次你就明白了，不要以為那些運維事故都是在別人身上，如果你不注意，下一個就是你。

切忌多人操作

我在的上一家公司，維運管理相當混亂，舉一個最典型的例子吧，離職好幾任的維運都有伺服器root密碼。通常我們維運接到任務，都會進行簡單查看如果無法解決，就請求他人幫忙，可是當問題焦頭爛額的時候，客服主管(懂點linux)，網管，你上司一起調試一個服務器，當你各種百度,各種對照，完了發現，你的伺服器設定文件，跟上你修改不一樣了，然後再改回來，然後再谷歌，興沖衝發現問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數……這個，我就真不知道哪個是問題真正的原因了，當然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測試無效，再去修改發現文件又被修改的時候呢?真的很惱火，切忌多人操作。

先備份後操作

養成一個習慣，要修改資料時，先備份，例如.conf的設定檔。另外，修改設定檔時，建議註解原選項，然後再複製，修改再者說，如果第一個例子中，有資料庫備份，那rsync的誤操作不就沒事了吧所以說丟資料庫非一朝一夕，隨便備份一個就不用那麼慘。

涉及資料

慎用rm -rf

網路上的例子很多，各種rm -rf /，各種刪除主資料庫，各種運維事故…… 一點小失誤就會造成很大的損失。如果真需要刪除，一定要謹慎。

備份操作大於一切

本來上面都有各種關於備份，但是我想把它劃分在資料類再次強調，備份非常之重要哇我記得我的老師說過一句話，涉及到數據何種的謹慎都不為過我就職的公司有做第三方支付網站和網貸平台的第三方支付是每兩個小時完全備份一次，網貸平台是每20分鐘備份一次我不多說了，大家自己斟酌吧

穩定大於一切

其實不只數據，在整個伺服器環境，都是穩定大於一切，不求最快，但求最穩定，求可用性所以未經測試，不要在伺服器使用新的軟體，例如nginx php-fpm，生產環境中php各種掛啊重啟下就好了，或者換apache就好了。

保密大於一切

現在各種艷照門漫天飛，各種路由器後門，所以說，涉及到數據，不保密是不行的。另外，搜尋公眾號Linux就該這樣學後台回覆“Linux”，取得驚喜禮包。

涉及安全性

ssh

更改預設連接埠(當然如果專業要駭你，掃描下就出來了) 禁止root登入使用普通用戶key認證sudo規則ip位址用戶限制使用hostdeny類似的防爆破解軟體(超過幾次嘗試直接拉黑) 篩選/etc/passwd中login的用戶

防火牆

防火牆生產環境一定要開，並且要遵循最小原則，drop所有，然後放行需要的服務連接埠。

精細權限和控製粒度

能使用一般使用者啟動的服務堅決不使用root，把各種服務權限控製到最低，控制細粒度要精細。

入侵偵測與日誌監控

使用第三方軟體，時刻偵測系統關鍵檔案以及各種服務設定檔的變更例如,/etc/passwd,/etc/my.cnf，/ etc/httpd/con/httpd.con等; 使用集中化的日誌監控體系，監控/var/log/secure，/etc/log/message，ftp上傳下載檔案等警報錯誤日誌; 另外針對連接埠掃描，也可以使用一些第三方軟體，發現被掃描就直接拉入host.deny。這些資訊對於系統被入侵後排錯很有幫助。有人說過，一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個很大的話題也是一個很基礎的工作，把基礎做好了，就能相當的提高系統安全性，其他的就是安全高手做的了

日常監控

系統運行監控

好多人踏入運維都是從監控做起，大的公司一般都有專業24小時監控維運。系統運行監控一般包括硬體佔用率常見的有，內存，硬碟，cpu，網卡，os包括登入監控，系統關鍵文件監控定期的監控可以預測出硬體損壞的機率，並且給調優帶來很實用的功能。

服務運行監控

服務監控一般就是各種應用，web，db，lvs等，這一般都是監控一些指標，在系統出現效能瓶頸的時候就能很快發現並解決。

日誌監控

這裡的日誌監控跟安全的日誌監控類似，但這裡一般都是硬件，os，應用程式的報錯和警報資訊監控在系統穩定運行的時候確實沒啥用，但是一旦出現問題，你又沒做監控，就會很被動了。

效能調優

深入了解運行機制

其實以一年多的維運經驗來說，談調優根本就是紙上談兵，但是我只是想簡單總結下，如果有更深入的了解，我會更新。在對軟體進行最佳化之前，例如要深入了解一個軟體的運作機制，例如nginx和apache，大家都說nginx快，那就必須知道nginx為什麼快，利用什麼原理，處理請求比apache，並且要能跟別人用淺顯易懂的話說出來，必要的時候還要能看懂原始碼，否則一切以參數為調優​​物件的文檔都是瞎談。

調優框架以及先後

熟悉了底層運作機制，就要有調優的框架和先後順序，例如資料庫出現瓶頸，好多人直接就去更改資料庫的設定文件，我的建議是，先根據瓶頸去分析，查看日誌，寫出來調優方向，然後再入手，並且資料庫伺服器調優應該是最後一步，最先的應該是硬體和作業系統，現在的資料庫伺服器都是在各種測試之後才會發布的適用於所有作業系統，不應該先從他入手。

牛逼啊！接私活必备的 N 个开源项目！赶快收藏

每次只調一個參數

每次只調一個參數，這個相比大家都了解，調的多了，你就自己就迷糊了。

基準測試

判斷調優是否有用，和測試一個新版本軟體的穩定性和效能等方面，就必須要基準測試了，測試要涉及很多因素測試是否接近業務真實需求這要看測試人的經驗了，相關資料大家可以參考《高性能mysql》第三版相當的好。我的老師曾說過，沒有放之四海皆準的參數，任何參數更改任何調優都必須符合業務場景 所以不要再谷歌什麼什麼調優了，對你的提升和業務環境的改善沒有長久作用。

運維心態

控制心態

很多rm -rf /data都在下班的前幾分鐘，都在煩躁的高峰，那麼你還不打算控制下你的心態麼，有人說了，煩躁也要上班，可是你可以在煩躁的時候盡量避免處理關鍵數據環境越是有壓力，越要冷靜，不然會損失更多。大多人都有rm -rf /data/mysql的經歷，發現刪除之後，那種心情你可以想像一下，可是如果沒有備份，你急又有什麼用，一般這種情況下，你就要冷靜想下最壞打算了，對於mysql來說，刪除了物理文件，一部分錶還會存在內存中，所以斷開業務，但是不要關閉mysql數據庫，這對恢復很有幫助，並使用dd複製硬碟，然後你再進行恢復當然了大多時候你就只能找資料恢復公司了。試想一下，資料被刪了，你各種操作，關閉資料庫，然後修復，不但有可能覆蓋文件，還找不到記憶體中的表了。

對資料負責

生產環境不是兒戲，資料庫也不是兒戲，一定要對資料負責。不備份的後果是非常嚴重的。

追根究底

很多維運人員比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網站老是打不開，經過php程式碼報錯發現是session和whos_online損壞，前任維運是透過repair修復的，我就也這樣修復了，但是過了幾個小時，又出現了反覆三四次之後，我就去谷歌資料庫表莫名損壞原因：一是myisam的bug，二是mysqlbug，三是mysql在寫入過程中被kill，最後發現是內存不夠用，導致OOM kill了mysqld進程並且沒有swap分區，後台監控內存是夠用的，最後升級物理內存解決。

測試和生產環境

在重要操作之前一定要看自己所在的機器，盡量避免多開視窗。