三年Linux運維工做總結教訓

Linux運維必定要知道的六類好習慣和23個教訓，避免入坑！

從事運維三年半，遇到過各式各樣的問題，數據丟失，網站掛馬，誤刪數據庫文件，黑客攻擊等各種問題。

今天簡單整理一下，分享給各位小夥伴。

 

1、線上操做規範

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的誤操做不久沒事了吧

因此說丟數據庫非一朝一夕，隨便備份一個就不用那麼慘。

 

2、涉及數據

1.慎用rm -rf

網上的例子不少，各類rm -rf /，各類刪除主數據庫，各類運維事故……

一點小失誤就會形成很大的損失。若是真須要刪除，必定要謹慎。

2.備份大於一切

原本上面都有各類關於備份，可是我想把它劃分在數據類再次強調，備份很是之重要哇

我記得個人老師說過一句話，涉及到數據何種的謹慎都不爲過

我就任的公司有作第三方支付網站和網貸平臺的

第三方支付是每兩個小時徹底備份一次，網貸平臺是每20分鐘備份一次

我很少說了，你們本身斟酌吧

3.穩定大於一切

其實不止是數據，在整個服務器環境，都是穩定大於一切，不求最快，但求最穩定，求可用性

因此未經測試，不要再服務器使用新的軟件，好比nginx+php-fpm，生產環境中php各類掛啊

重啓下就行了，或者換apache就行了。

4.保密大於一切

如今各類豔照門漫天飛，各類路由器後門，因此說，涉及到數據，不保密是不行的。

 

3、涉及安全

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。這些信息對於系統被入侵後排錯頗有幫助。有人說過，一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個很大的話題

也是一個很基礎的工做，把基礎作好了，就能至關的提升系統安全性，其餘的就是安全高手作的了

 

4、平常監控

1.系統運行監控

好多人踏入運維都是從監控作起，大的公司通常都有專業24小時監控運維。系統運行監控通常包括硬件佔用率

常見的有，內存，硬盤，cpu，網卡，os包括登陸監控，系統關鍵文件監控

按期的監控能夠預測出硬件損壞的機率，而且給調優帶來很實用的功能

2.服務運行監控

服務監控通常就是各類應用，web，db，lvs等，這通常都是監控一些指標

在系統出現性能瓶頸的時候就能很快發現並解決。

3.日誌監控

這裏的日誌監控跟安全的日誌監控相似，但這裏通常都是硬件，os，應用程序的報錯和警報信息

監控在系統穩定運行的時候確實沒啥用，可是一旦出現問題，你又沒作監控，就會很被動了

 

5、性能調優

1.深刻了解運行機制

其實按一年多的運維經驗來講，談調優根本就是紙上談兵，可是我只是想簡單總結下，若是有更深刻的瞭解，我會更新。在對軟件進行優化以前，好比要深刻了解一個軟件的運行機制，好比nginx和apache，你們都說nginx快，那就必須知道nginx爲何快，利用什麼原理，處理請求比apache，而且要能跟別人用淺顯易懂的話說出來，必要的時候還要能看懂源代碼，不然一切以參數爲調優對象的文檔都是瞎談。

2.調優框架以及前後

熟悉了底層運行機制，就要有調優的框架和前後順序，好比數據庫出現瓶頸，好多人直接就去更改數據庫的配置文件，個人建議是，先根據瓶頸去分析，查看日誌，寫出來調優方向，而後再入手，而且數據庫服務器調優應該是最後一步，最早的應該是硬件和操做系統，如今的數據庫服務器都是在各類測試以後纔會發佈的

適用於全部操做系統，不該該先從他入手。

3.每次只調一個參數

每次只調一個參數，這個相比你們都瞭解，調的多了，你就本身就迷糊了。

4.基準測試

判斷調優是否有用，和測試一個新版本軟件的穩定性和性能等方面，就必需要基準測試了，測試要涉及不少因素

測試是否接近業務真實需求這要看測試人的經驗了，相關資料你們能夠參考《高性能mysql》第三版至關的好

個人老師曾說過，沒有放之四海皆準的參數，任何參數更改任何調優都必須符合業務場景

因此不要再谷歌什麼什麼調優了，對你的提高和業務環境的改善沒有長久做用

 

6、運維心態

1.控制心態

不少rm -rf /data都在下班的前幾分鐘，都在煩躁的高峯，那麼你還不打算控制下你的心態麼

有人說了，煩躁也要上班，但是你能夠在煩躁的時候儘可能避免處理關鍵數據環境

越是有壓力，越要冷靜，否則會損失更多。

大多人都有rm -rf /data/mysql的經歷，發現刪除以後，那種心情你能夠想象一下，但是若是沒有備份，你急又有什麼用，通常這種狀況下，你就要冷靜想下最壞打算了，對於mysql來講，刪除了物理文件，一部分表還會存在內存中，因此斷開業務，可是不要關閉mysql數據庫，這對恢復頗有幫助，並使用dd複製硬盤，而後你再進行恢復

固然了大多時候你就只能找數據恢復公司了。

試想一下，數據被刪了，你各類操做，關閉數據庫，而後修復，不但有可能覆蓋文件，還找不到內存中的表了。

2.對數據負責

生產環境不是兒戲，數據庫也不是兒戲，必定要對數據負責。不備份的後果是很是嚴重的。

3.追根究底

不少運維人員比較忙，遇到問題解決就不會再管了，記得去年一個客戶的網站總是打不開，通過php代碼報錯

發現是session和whos_online損壞，前任運維是經過repair修復的，我就也這樣修復了，可是過了幾個小時，又出現了

反覆三四次以後，我就去谷歌數據庫表莫名損壞緣由：一是myisam的bug，二是mysqlbug，三是mysql在寫入過程當中

被kill，最後發現是內存不夠用，致使OOM kill了mysqld進程

而且沒有swap分區，後臺監控內存是夠用的，最後升級物理內存解決。

4.測試和生產環境

在重要操做以前必定要看本身所在的機器，儘可能避免多開窗口。