一、線上操作規范

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；
•  MySQL Bug；
•  MySQL 在寫入過程中被 kill。

最后發現是內存不夠用，導致 OOM kill 了 mysqld 進程，并且沒有 swap 分區，后臺監控內存是夠用的，最終通過升級物理內存解決了。

4. 測試和生產環境

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