1. <em id="vzzs9"></em>
      <tbody id="vzzs9"></tbody>

    2. <span id="vzzs9"></span>
      <progress id="vzzs9"></progress>
      首頁 運維干貨經驗之談:Linux 運維工程師的 6 類好習慣和 23 個教訓

      經驗之談:Linux 運維工程師的 6 類好習慣和 23 個教訓

      運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
      領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥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的誤操作不久沒事了吧。所以說丟數據庫非一朝一夕,隨便備份一個就不用那么慘。
      二、涉及數據
      5、慎用rm -rf
      網上的例子很多,各種rm -rf /,各種刪除主數據庫,各種運維事故……
      一點小失誤就會造成很大的損失。如果真需要刪除,一定要謹慎。
      6、備份大于一切
      本來上面都有各種關于備份,但是我想把它劃分在數據類再次強調,備份非常之重要哇。
      我記得我的老師說過一句話,涉及到數據何種的謹慎都不為過。我就職的公司有做第三方支付網站和網貸平臺的,第三方支付是每兩個小時完全備份一次,網貸平臺是每20分鐘備份一次。
      我不多說了,大家自己斟酌吧。
      7、穩定大于一切
      其實不止是數據,在整個服務器環境,都是穩定大于一切,不求最快,但求最穩定,求可用性,所以未經測試,不要在服務器使用新的軟件,比如Nginx+PHP-FPM,生產環境中PHP各種掛啊。
      重啟下就好了,或者換apache就好了。
      8、保密大于一切
      現在各種艷照門漫天飛,各種路由器后門,所以說,涉及到數據,不保密是不行的。
      三、涉及安全
      9、SSH

      • 更改默認端口(當然如果專業要黑你,掃描下就出來了)
      • 禁止root登錄
      • 使用普通用戶+key認證+sudo規則+IP地址+用戶限制
      • 使用hostdeny類似的防爆里破解軟件(超過幾次嘗試直接拉黑)

      篩選/etc/passwd中login的用戶。
      10、防火墻
      防火墻生產環境一定要開,并且要遵循最小原則,drop所有,然后放行需要的服務端口。
      11、精細權限和控制粒度
      能使用普通用戶啟動的服務堅決不使用root,把各種服務權限控制到最低,控制粒度要精細。
      12、入侵檢測和日志監控
      使用第三方軟件,時刻檢測系統關鍵文件以及各種服務配置文件的改動,比如:/etc/passwd,/etc/my.cnf,/etc/httpd/con/httpd.con等。
      使用集中化的日志監控體系,監控/var/log/secure,/etc/log/message,ftp上傳下載文件等報警錯誤日志。
      另外針對端口掃描,也可以使用一些第三方軟件,發現被掃描就直接拉入host.deny。這些信息對于系統被入侵后排錯很有幫助。
      有人說過,一個公司在安全投入的成本跟他被安全攻擊損失的成本成正比,安全是一個很大的話題,也是一個很基礎的工作,把基礎做好了,就能相當的提高系統安全性,其他的就是安全高手做的了。
      四、日常監控
      13、系統運行監控
      好多人踏入運維都是從監控做起,大的公司一般都有專業24小時監控運維。系統運行監控一般包括硬件占用率,常見的有,內存,硬盤,CPU,網卡,OS包括登錄監控,系統關鍵文件監控。
      定期的監控可以預測出硬件損壞的概率,并且給調優帶來很實用的功能。
      14、服務運行監控
      服務監控一般就是各種應用,Web,DB,LVS等,這一般都是監控一些指標。在系統出現性能瓶頸的時候就能很快發現并解決。
      15、日志監控
      這里的日志監控跟安全的日志監控類似,但這里一般都是硬件,OS,應用程序的報錯和警報信息。
      監控在系統穩定運行的時候確實沒啥用,但是一旦出現問題,你又沒做監控,就會很被動了。
      五、性能調優
      16、深入了解運行機制
      其實按一年多的運維經驗來說,談調優根本就是紙上談兵,但是我只是想簡單總結下,如果有更深入的了解,我會更新。在對軟件進行優化之前,比如要深入了解一個軟件的運行機制,比如Nginx和Apache,大家都說Nginx快,那就必須知道Nginx為什么快,利用什么原理,處理請求比Apache,并且要能跟別人用淺顯易懂的話說出來,必要的時候還要能看懂源代碼,否則一切以參數為調優對象的文檔都是瞎談。
      17、調優框架以及先后
      熟悉了底層運行機制,就要有調優的框架和先后順序,比如數據庫出現瓶頸,好多人直接就去更改數據庫的配置文件,我的建議是,先根據瓶頸去分析,查看日志,寫出來調優方向,然后再入手,并且數據庫服務器調優應該是最后一步,最先的應該是硬件和操作系統,現在的數據庫服務器都是在各種測試之后才會發布的
      適用于所有操作系統,不應該先從他入手。
      18、每次只調一個參數
      每次只調一個參數,這個相比大家都了解,調的多了,你就自己就迷糊了。
      19、基準測試
      判斷調優是否有用,和測試一個新版本軟件的穩定性和性能等方面,就必須要基準測試了,測試要涉及很多因素。
      測試是否接近業務真實需求這要看測試人的經驗了,相關資料大家可以參考《高性能MySQL》第三版相當的好。
      我的老師曾說過,沒有放之四海皆準的參數,任何參數更改任何調優都必須符合業務場景,所以不要再谷歌什么什么調優了,對你的提升和業務環境的改善沒有長久作用。
      六、運維心態
      20、控制心態
      很多rm -rf /data都在下班的前幾分鐘,都在煩躁的高峰,那么你還不打算控制下你的心態么?
      有人說了,煩躁也要上班,可是你可以在煩躁的時候盡量避免處理關鍵數據環境,越是有壓力,越要冷靜,不然會損失更多。
      大多人都有rm -rf /data/mysql的經歷,發現刪除之后,那種心情你可以想象一下,可是如果沒有備份,你急又有什么用,一般這種情況下,你就要冷靜想下最壞打算了,對于MySQL來說,刪除了物理文件,一部分表還會存在內存中,所以斷開業務,但是不要關閉MySQL數據庫,這對恢復很有幫助,并使用dd復制硬盤,然后你再進行恢復。
      當然了大多時候你就只能找數據恢復公司了。
      試想一下,數據被刪了,你各種操作,關閉數據庫,然后修復,不但有可能覆蓋文件,還找不到內存中的表了。
      21、對數據負責
      生產環境不是兒戲,數據庫也不是兒戲,一定要對數據負責。不備份的后果是非常嚴重的。
      22、追根究底
      很多運維人員比較忙,遇到問題解決就不會再管了,記得去年一個客戶的網站老是打不開,經過PHP代碼報錯,發現是session和whos_online損壞,前任運維是通過repair修復的,我就也這樣修復了,但是過了幾個小時,又出現了。反復三四次之后,我就去谷歌數據庫表莫名損壞原因:一是myisam的bug,二是mysqlbug,三是MySQL在寫入過程中被kill,最后發現是內存不夠用,導致OOM kill了mysqld進程,并且沒有swap分區,后臺監控內存是夠用的,最后升級物理內存解決。
      23、測試和生產環境
      在重要操作之前一定要看自己所在的機器,盡量避免多開窗口。

      鏈接:DevOps技術棧

      (版權歸原作者所有,侵刪)

      本文鏈接:http://www.abandonstatusquo.com/41883.html

      網友評論comments

      發表評論

      您的電子郵箱地址不會被公開。

      暫無評論

      Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
      掃二維碼
      掃二維碼
      返回頂部
      久久久久亚洲国内精品|亚洲一区二区在线观看综合无码|欧洲一区无码精品色|97伊人久久超碰|一级a爱片国产亚洲精品