Linux 運維工程師的六類好習慣

安全劍客發表於2019-01-14
當初學習 Linux 的使用,從基礎到服務到叢集,都是在虛擬機器做的,雖然老師告訴我們跟真機沒有什麼差別,可是對真實環境的渴望日漸上升,不過虛擬機器的各種快照卻讓我們養成了各種手賤的習慣,以致於拿到伺服器操作許可權時候,就迫不及待的想去試試。

Linux 運維工程師的六類好習慣Linux 運維工程師的六類好習慣

一、線上操作規範
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 /,各種刪除主資料庫,各種運維事故……

一點小失誤就會造成很大的損失。如果真需要刪除,一定要謹慎。

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修復的,我就也這樣修復了,但是過了幾個小時,又出現了。反覆三四次之後,我就去谷歌資料庫表莫名損壞原因:一是myisam的bug,二是mysqlbug,三是mysql在寫入過程中被kill,最後發現是記憶體不夠用,導致OOM kill了mysqld程式,並且沒有swap分割槽,後臺監控記憶體是夠用的,最後升級實體記憶體解決。

4.測試和生產環境

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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31559985/viewspace-2554519/,如需轉載,請註明出處,否則將追究法律責任。

相關文章