從事運維一年半，遇到過各式各樣的問題，數(shù)據(jù)丟失，網(wǎng)站掛馬，誤刪數(shù)據(jù)庫文件，黑客攻擊等各類問題，今天想簡單整理一下，分享給各位小伙伴。

[[110944]]

一、線上操作規(guī)范

1.測試使用

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

第二個例子是關(guān)于文件同步的，大家都知道rsync同步很快，可是他刪除文件的速度大大超過了rm -rf,在rsync中有一個命令是，以某目錄為準同步某文件（如果第一個目錄是空的，那么結(jié)果可想而知），源目錄（有數(shù)據(jù)的）就會被刪除，當(dāng)初我就是因為誤操作，以及缺乏測試，就目錄寫反了，關(guān)鍵是沒有備份……生產(chǎn)環(huán)境數(shù)據(jù)被刪了，沒備份，大家自己想后果吧，其重要性不言而喻。

2.Enter前再三確認

關(guān)于rm -rf / var 這種錯誤，我相信手快的人，或者網(wǎng)速比較慢的時候，出現(xiàn)的幾率相當(dāng)大，當(dāng)你發(fā)現(xiàn)執(zhí)行完之后，你的心至少是涼了半截。

大家可能會說，我按了這么多次都沒出過錯，不用怕，我只想說，當(dāng)出現(xiàn)一次你就明白了，不要以為那些運維事故都是在別人身上，如果你不注意，下一個就是你。

3.切忌多人操作

我在的上一家公司，運維管理相當(dāng)混亂，舉一個最典型的例子吧，離職好幾任的運維都有服務(wù)器root密碼。

通常我們運維接到任務(wù)，都會進行簡單查看如果無法解決，就請求他人幫忙，可是當(dāng)問題焦頭爛額的時候，客服主管（懂點linux），網(wǎng)管，你上司一起調(diào)試一個服務(wù)器，當(dāng)你各種百度,各種對照，完了發(fā)現(xiàn)，你的服務(wù)器配置文件，跟上次你修改不一樣了，然后再改回來，然后再谷歌，興沖沖發(fā)現(xiàn)問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數(shù)……這個，我就真不知道哪個是問題真正的原因了，當(dāng)然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測試無效，再去修改發(fā)現(xiàn)文件又被修改的時候呢？真的很惱火，切忌多人操作。

4.先備份后操作

養(yǎng)成一個習(xí)慣，要修改數(shù)據(jù)時，先備份，比如.conf的配置文件，另外，修改配置文件時，建議注釋原選項，然后再復(fù)制，修改。

再者說，如果第一個例子中，有數(shù)據(jù)庫備份，那rsync的誤操作不久沒事了吧。所以說丟數(shù)據(jù)庫非一朝一夕，隨便備份一個就不用那么慘。

二、涉及數(shù)據(jù)

1.慎用rm -rf

網(wǎng)上的例子很多，各種rm -rf /，各種刪除主數(shù)據(jù)庫，各種運維事故……一點小失誤就會造成很大的損失。如果真需要刪除，一定要謹慎。

2.備份大于一切

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

3.穩(wěn)定大于一切

其實不止是數(shù)據(jù)，在整個服務(wù)器環(huán)境，都是穩(wěn)定大于一切，不求最快，但求最穩(wěn)定，求可用性，所以未經(jīng)測試，不要再服務(wù)器使用新的軟件，比如nginx+php-fpm，生產(chǎn)環(huán)境中php各種掛啊，重啟下就好了，或者換apache就好了。

4.保密大于一切

現(xiàn)在各種艷照門漫天飛，各種路由器后門，所以說，涉及到數(shù)據(jù)，不保密是不行的。

三、涉及安全

1. ssh

• 更改默認端口（當(dāng)然如果專業(yè)要黑你，掃描下就出來了）
• 禁止root登錄
• 使用普通用戶+key認證+sudo規(guī)則+ip地址+用戶限制
• 使用hostdeny類似的防爆里破解軟件（超過幾次嘗試直接拉黑）
• 篩選/etc/passwd中l(wèi)ogin的用戶

2. 防火墻

防火墻生產(chǎn)環(huán)境一定要開，并且要遵循最小原則，drop所有，然后放行需要的服務(wù)端口。

3.精細權(quán)限和控制粒度

能使用普通用戶啟動的服務(wù)堅決不使用root，把各種服務(wù)權(quán)限控制到最低，控制粒度要精細。

4.入侵檢測和日志監(jiān)控

• 使用第三方軟件，時刻檢測系統(tǒng)關(guān)鍵文件以及各種服務(wù)配置文件的改動，比如,/etc/passwd,/etc/my.cnf，/etc/httpd/con/httpd.con等；
• 使用集中化的日志監(jiān)控體系，監(jiān)控/var/log/secure，/etc/log/message，ftp上傳下載文件等報警錯誤日志；

另外針對端口掃描，也可以使用一些第三方軟件，發(fā)現(xiàn)被掃描就直接拉入host.deny。這些信息對于系統(tǒng)被入侵后排錯很有幫助。有人說過，一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個很大的話題，也是一個很基礎(chǔ)的工作，把基礎(chǔ)做好了，就能相當(dāng)?shù)奶岣呦到y(tǒng)安全性，其他的就是安全高手做的了。

四、日常監(jiān)控

1.系統(tǒng)運行監(jiān)控

好多人踏入運維都是從監(jiān)控做起，大的公司一般都有專業(yè)24小時監(jiān)控運維。系統(tǒng)運行監(jiān)控一般包括硬件占用率，常見的有，內(nèi)存，硬盤，cpu，網(wǎng)卡，os包括登錄監(jiān)控，系統(tǒng)關(guān)鍵文件監(jiān)控，定期的監(jiān)控可以預(yù)測出硬件損壞的概率，并且給調(diào)優(yōu)帶來很實用的功能。

2.服務(wù)運行監(jiān)控

服務(wù)監(jiān)控一般就是各種應(yīng)用，web，db，lvs等，這一般都是監(jiān)控一些指標(biāo)，在系統(tǒng)出現(xiàn)性能瓶頸的時候就能很快發(fā)現(xiàn)并解決。

3.日志監(jiān)控

這里的日志監(jiān)控跟安全的日志監(jiān)控類似，但這里一般都是硬件，os，應(yīng)用程序的報錯和警報信息，監(jiān)控在系統(tǒng)穩(wěn)定運行的時候確實沒啥用，但是一旦出現(xiàn)問題，你又沒做監(jiān)控，就會很被動了。

五、性能調(diào)優(yōu)

1.深入了解運行機制

其實按一年多的運維經(jīng)驗來說，談?wù){(diào)優(yōu)根本就是紙上談兵，但是我只是想簡單總結(jié)下，如果有更深入的了解，我會更新。

在對軟件進行優(yōu)化之前，比如要深入了解一個軟件的運行機制，比如nginx和apache，大家都說nginx快，那就必須知道nginx為什么快，利用什么原理，處理請求比apache，并且要能跟別人用淺顯易懂的話說出來，必要的時候還要能看懂源代碼，否則一切以參數(shù)為調(diào)優(yōu)對象的文檔都是瞎談。

2.調(diào)優(yōu)框架以及先后

熟悉了底層運行機制，就要有調(diào)優(yōu)的框架和先后順序，比如數(shù)據(jù)庫出現(xiàn)瓶頸，好多人直接就去更改數(shù)據(jù)庫的配置文件，我的建議是，先根據(jù)瓶頸去分析，查看日志，寫出來調(diào)優(yōu)方向，然后再入手，并且數(shù)據(jù)庫服務(wù)器調(diào)優(yōu)應(yīng)該是最后一步，最先的應(yīng)該是硬件和操作系統(tǒng)，現(xiàn)在的數(shù)據(jù)庫服務(wù)器都是在各種測試之后才會發(fā)布的，適用于所有操作系統(tǒng)，不應(yīng)該先從他入手。

3.每次只調(diào)一個參數(shù)

每次只調(diào)一個參數(shù)，這個相比大家都了解，調(diào)的多了，你就自己就迷糊了。

4.基準測試

判斷調(diào)優(yōu)是否有用，和測試一個新版本軟件的穩(wěn)定性和性能等方面，就必須要基準測試了，測試要涉及很多因素，測試是否接近業(yè)務(wù)真實需求這要看測試人的經(jīng)驗了，相關(guān)資料大家可以參考《高性能mysql》第三版，相當(dāng)?shù)暮谩Ｎ业睦蠋熢f過，沒有放之四海皆準的參數(shù)，任何參數(shù)更改任何調(diào)優(yōu)都必須符合業(yè)務(wù)場景，所以不要再谷歌什么什么調(diào)優(yōu)了，對你的提升和業(yè)務(wù)環(huán)境的改善沒有長久作用。

六、運維心態(tài)

1.控制心態(tài)

很多rm -rf /data都在下班的前幾分鐘，都在煩躁的高峰，那么你還不打算控制下你的心態(tài)么，有人說了，煩躁也要上班，可是你可以在煩躁的時候盡量避免處理關(guān)鍵數(shù)據(jù)環(huán)境。越是有壓力，越要冷靜，不然會損失更多。

大多人都有rm -rf /data/mysql的經(jīng)歷，發(fā)現(xiàn)刪除之后，那種心情你可以想象一下，可是如果沒有備份，你急又有什么用，一般這種情況下，你就要冷靜想下最壞打算了，對于mysql來說，刪除了物理文件，一部分表還會存在內(nèi)存中，所以斷開業(yè)務(wù)，但是不要關(guān)閉mysql數(shù)據(jù)庫，這對恢復(fù)很有幫助，并使用dd復(fù)制硬盤，然后你再進行恢復(fù)，當(dāng)然了大多時候你就只能找數(shù)據(jù)恢復(fù)公司了。

試想一下，數(shù)據(jù)被刪了，你各種操作，關(guān)閉數(shù)據(jù)庫，然后修復(fù)，不但有可能覆蓋文件，還找不到內(nèi)存中的表了。

2.對數(shù)據(jù)負責(zé)

生產(chǎn)環(huán)境不是兒戲，數(shù)據(jù)庫也不是兒戲，一定要對數(shù)據(jù)負責(zé)。不備份的后果是非常嚴重的。

3.追根究底

很多運維人員比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網(wǎng)站老是打不開，經(jīng)過php代碼報錯，發(fā)現(xiàn)是session和whos_online損壞，前任運維是通過repair修復(fù)的，我就也這樣修復(fù)了，但是過了幾個小時，又出現(xiàn)了。反復(fù)三四次之后，我就去谷歌數(shù)據(jù)庫表莫名損壞原因：一是myisam的bug，二是mysqlbug，三是mysql在寫入過程中被kill。最后發(fā)現(xiàn)是內(nèi)存不夠用，導(dǎo)致OOM kill了mysqld進程。并且沒有swap分區(qū)，后臺監(jiān)控內(nèi)存是夠用的，最后升級物理內(nèi)存解決。

4.測試和生產(chǎn)環(huán)境

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

以上幾點是我自己工作體會，希望能給部分運維人員帶來一些幫助，如有不足，歡迎指教。