系統運維秘訣：變化，監控，擴展（技術篇）(1)

編者按：本文是SixApart的MySQL DBA，Dormando在2008年總結的一套運維秘訣。編者前日看到Google系統管理員Tom Limoncelli在Everything Sysadmin上推薦這篇文章，并表示這篇文章的內容在今天仍然適用。閱讀之下，發現的確是篇難得的好文章，有大量的經驗分享總結�，F在51CTO系統頻道特將本文全文翻譯過來，當作給各位運維讀者們的2011新年禮物。

51CTO推薦專題：系統運維秘訣

完全理解本文內容需要一定的運維經驗。您可能對這些文章也會感興趣：

1. 系統管理員必須了解的六大鐵律
2. 系統管理員都應該知道的系統常識
3. 漫談運維：半神半仙亦民工

以下為正文。

在運維管理的過程中，我發現了很多有價值的秘訣，本文是這些秘訣的一個總結。雖然這些秘訣可能比較“唯心”，但是我還是把它們總結出來了，相信它們會對你有幫助的。

Dormando的運維秘訣分成以下三大篇：

1. 技術篇
2. 交流篇
3. 實踐篇

下面先從技術篇開始。交流篇和實踐篇會陸續整理放出。

技術篇

為變化而設計

◆Google的秘訣是正確的——“為變化而設計”。“變化”就是不得不部署新的軟件，升級現有的軟件，進行擴展，設備損壞，以及人員流動等。

◆每一件事情都是在尋找平衡點。你也許會認為把你的系統和某個操作系統或某個Linux發行版牢牢地綁定在一起是一個好主意，但事實上這跟把它們完全隔離一樣糟。如果實在有必要，你可以進行分層，并使用一點間接性。

◆這并不意味著你的系統必須是平臺無關的。其實我們的目的很簡單：一變二，二變二十，一個系統必須可以應對各種突發事件。也就是說，如果一個系統管理員被公共汽車撞了，你有應對的方案！如果掛載的硬盤出現故障了，你有應對的方案！如果某些人運行了rm -rf /，你也有應對的方案！增量的進行變更。記得安全更新，以及保持內容更新。

使用自動的，可重復的構建過程

◆不要手動構建任何東西。如果你一定需要手動構建，那么就做兩遍，在做第二遍的時候把用到所有的命令都提取出來。

◆下面這一點十分重要：將新硬件上線到生產環境的過程不應該超過15分鐘，而且這個過程必須足夠簡單。否則，當一個服務器出現故障，而沒有人知道如何更換它的時候，你就該倒霉了。

◆下面這一條是普世真理：這個世界上不存在“一次性”的服務器構建。即使你的服務器只需要構建一次，但只要你構建過一次，就一定會有第二次。比如，當它損壞的時候，或者你必須進行一次重大的升級才能讓它在在接下來的兩年時間里更加穩定的時候。

◆測試，檢查新構建好的服務器。這應該是比較容易的，因為你的構建過程都是自動化的，對吧！

◆腳本化的構建，意味著從某個Linux發行版的V3升級到V4應該是很快的。安裝
V4，對腳本進行測試。如果有問題，參考文檔并修復它，直到它可以再次正常工作。這最多應該是一個星期的工作，而不是一個長達一年的浩大工程（因為那時，剛剛完成的V5已經發布了�。�

使用冗余

◆容易重新構建，并不意味著你可以忽視冗余。跳轉盒，郵件服務器，計費網關，等等。如果其中的一半掛掉了卻并不造成客戶的宕機，生活將會變得更加簡單。

◆按照以上方針來做的話，當某個設備在凌晨3點出現故障的時候，你可以“以后再處理那個出現故障的設備！”，把冗余的機器先替換上去。

◆下面這一條是個聊勝于無的解決方案：Rsync。DRBD也許也不是一個完美的解決方案，但是它可以提供令人稱奇的服務。（參考閱讀：DRBD筆記，DRBD實例1，DRBD實例2）

使用備份

◆備份是個嚴肅的話題。使用硬盤，燒錄磁帶。壓縮它們，移動它們，并行地運行。對每一樣東西進行備份！

◆如果你的構建過程是自動的，整個過程都可以被備份。如果到目前為止的幾條你都做到了，那么一個真正的“災難恢復”計劃也許并不是那么遙不可及的。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]