系統運維秘訣：Git，招聘與軟硬件選擇（實踐篇）
原創【51CTO精選譯文】編者按：本文是SixApart的MySQL DBA，Dormando在2008年總結的一套運維秘訣。編者前日看到Google系統管理員Tom Limoncelli在Everything Sysadmin上推薦這篇文章，并表示這篇文章的內容在今天仍然適用。閱讀之下，發現的確是篇難得的好文章，有大量的經驗分享，總結的十分全面。現在51CTO系統頻道特將本文全文翻譯過來，當作給各位運維讀者們的2011新年禮物。以下為正文。
在運維管理的過程中，我發現了很多有價值的秘訣，本文是這些秘訣的一個總結。雖然這些秘訣可能比較“唯心”，但是我還是把它們總結出來了，相信它們會對你有幫助的。
Dormando的運維秘訣分成以下三大篇：
實踐篇
現在就修復它，而不是以后再修復它
◆如果一個Web服務器處于脫機狀態，不要擔心，因為你應該有10個備用的！
◆在一周中，專門挑出一天來“清理門戶”。更換掉所有存在故障的硬件。在歡度周末之前，確保一切都是完好無損的。
◆如果令人討厭的小問題突然發生了，在早上要做的***件事情就是***性的修復它們。日志塞滿磁盤的情況在上周發生了兩次？明天再說吧！如果總是這樣，這些問題會堆積起來……
◆如果你的構建過程是自動化的，充分利用這個優勢來修復一些你可以馬上修復的問題，或許也可以批量進行修復。
讓每一件事情都自動化
◆人們無法（輕易地）搞亂腳本化的任務。
◆從第二次開始自動化。如果***次你必須手工來做一件事情，那么把你做的事情寫入一個腳本。
◆帶注釋的腳本是***的文檔。與其把如何安裝一些東西的方法詳細地寫到長達20頁文檔中，還不如編寫一個可以自解釋的腳本。
◆腳本可以被放到自動化的構建過程中。如果要更接近這個目標，應該把一些經常做的事情都應該變成“零時間”的任務。
只進行必要的變更
◆只做小規模的，獨立的變更。
◆如果不是必須改變，那么就保持原樣。
◆這也意味著你必須搞清楚什么時候才應該進行變更。找出什么東西是必須要進行變更的，然后對它進行升級，把它拿出來，讓它標準化。
Design for change
◆這里的Design for change（編輯注：技術篇的***條也是Design for change）針對個人的成長。朝快速解決問題大師的方向努力吧。
◆如果快速解決問題比較困難，那么你可以學習一些基礎知識，做出一張清晰的升級路線圖。雖然你的新郵件系統也許并不是你夢想中的、帶有強大反垃圾郵件功能的巨大系統；但是架設兩臺配置干凈的postfix郵件服務器會比你想象中的效果還要好。
◆大家都傾向于把未完成的項目放在那里置之不理。這是你要避免的。
盡快地把更新的內容投入實踐
◆一般來說，運維工作就是要讓代碼更好地運行。并行化，建立起回滾重啟機制。
◆運行內容包括軟件更新，安全補丁，配置變更。
◆使用puppet，cfengine以及你需要的任何工具對配置進行控制。讓它干凈，簡潔，并且容易操作。
◆文件數量越少越好。如果只是為了推出一個新的數據庫就要在20個文件中分別添加一行，那么你的方法一定是錯誤的。創建簡單的模板，不要重復編輯需要手工編輯的數據。
規范化，堅持按照規范來行事
◆OS的規范，httpd的規范，數據庫的規范，打包系統的規范。
◆堅持按照這些規范來行事。對一些方法進行調整和改進，讓它變得更有意義。
◆永遠不要緊抓著主版本不放。如果你的產品功能還沒有***性地凍結，你就必須要按照規范繼續向前推進，把過去的一些事情都拋在腦后。
◆按照規范來做的事情越多，你的工具可以發揮作用的場合就會越多。用于支持其他運維領域的軟件包越多，可以適應的場景也越多。
文檔化
◆把流程文檔化
◆把產品文檔化
◆不要讓文檔出現冗余。如果一個腳本的幫助文檔很長，可以進行引用。好的文檔是一個持續改進的過程，它要一直保持準確。
◆把文檔和代碼，perldoc，pydoc等聯系起來。
◆過期的文檔是有害的。留出一些時間來更新它們。當新的員工遇到問題的時候，和新的員工坐下來一起更新文檔。
◆適當地使用問題跟蹤系統（issue tracking）。為操作歷史保留文檔是十分重要的，以避免為了某個DNS故障的重現去騷擾他人。
使用源代碼控制工具
◆使用git或者mercurial。避免使用SVN。
◆把配置文件、腳本等各種東西都放到源代碼控制工具中管理起來。
◆為代碼遷出提供各種入口。
◆保持遷出的嚴謹性，精準性和可控制性。禁止提交無法進行審核的變更。應該提交的變更應該是不用源代碼控制工具也能容易地進行測試的（在虛擬機環境下，可以直接在一個單獨的測試機器上進行測試）。
招聘
◆區分出固執的人和精明的人
◆不要避免聘請“老前輩”。某個領域的“老前輩”可能已經跟不上技術變革的腳步，以至于你可能不想聘請他們。但是，總是要有幾個“超級巨星”來壓住陣腳的。
◆不要避免聘請新手。我認識的很多人都是從一個真正的新手開始的（包括我自己！實際上，我認為我自己一直是一個新手）。經過這個階段以后，他們會迅速地成長起來。現在正是確立職業生涯的時候。我相信我們中的絕大多數人都是這樣的。當然，不包括那些不學習的人，沒有積極性的人，或者入錯行的人。
避免提供商鎖入，同時和你的提供商保持良好的關系
◆購買專有硬件的主要劣勢是提供商鎖入，你不得不總是使用這個提供商的產品。這可能是一個特殊的SAN，NAS，也可能是特殊用途的隨設備存儲，備份系統等等（51CTO推薦閱讀：別把雞蛋放在一個籃子里）。盡量避免發生這種事情。如果你完全按照上面的設計建議來行事，那么應該可以很快地在不同的平臺上搭建起測試環境。然后，你可以進行硬件評估，自由地進行選擇。
◆如果所有東西都很深奧，都很不明朗，都還沒有經過文檔化，并且直接依賴于專有的負載均衡器……那么***別用，因為用了你就不自由。
◆對你最終選擇的提供商好一點。如果你每一次采購都在價格方面把他們逼到墻角，那么你只能得到一些垃圾硬件了。
◆有時候數據中心有很多潛在的可用資源。盡量把一些免費的遠程協助服務寫到合同里，比如就更換硬盤驅動器，提供商的出貨/RMA條款，以及一些基礎硬件的安裝等方面的細則進行談判。我有一個機架的設備，其安裝上架的過程我們的人完全沒有操心……真的很不錯。
給開源一個機會
◆nginx，mongrel，lighttpd，apache，perlbal，mogilefs，memcached，squid，OpenBGPD，PF，IPTables，LVS，MySQL，Postgres，等等。在你選擇可信、可靠、昂貴的專有安裝程序以前，給開源一個機會。你會發現使用開源軟件意味著可以自己添加插件，擴展，代碼修復補丁，或者你可以把一些自己無法實現的功能外包出去。在我看來，開源軟件是很可靠的，它們通常比巨大負載之下的大型的，昂貴的硬件更可靠。
◆“一分錢一分貨”這種思想是一個徹底的謊言。如果你無法讓開源軟件為你工作，需要協助，你可以找一個提供商。如果你的團隊既睿智又積極主動，這些小伙子們想要搞清楚他們的基礎設施是如何工作的，那么你一定無法抵擋來自于GPL或BSD系統的誘惑。
◆MySQL和Postgres都不錯。如果你要使用它們，可以權衡一下利弊。沒有什么東西會在晚上從你的衣櫥里爬出來“吃”掉你的數據。與經過測試的、穩定的冗余master<->slave MySQL集群實例相比，其實龐大的、處于脫機狀態的Oracle實例更容易把事情搞的一團糟。
◆關于LAMP架構的文章數不勝數。無數知名網站、ISP、甚至企業現在都在使用開源軟件。給開源一個機會。最糟糕的結果也不過是浪費一些時間，而***從你那些心驚膽戰的提供商們那里獲得一些不錯的報價。
【51CTO.com譯稿，轉載請注明原文作譯者和出處。】
原文：http://dormando.livejournal.com/484577.html
【編輯推薦】
