在進行這篇的扯淡之前，讓我想起了《太平廣記》里的一個《 板橋三娘子》的故事，姓趙的客商窺探到客棧老板娘三娘子在小箱子中取出小孩玩具大小的木頭牛，木頭人，噴口水，木頭人、牛開始犁地耕作，撒一粒蕎麥種子，木頭小人種下，不一會兒，蕎麥長成開花結實，木頭人收割，乃至磨成面粉。然后三娘子把木頭牛、人收入箱中，用得來的面粉做了數張面餅。多么好的一個自動化場景呀。

自動化的目的

自動化管理是網站規模化之后必須要面對的問題。為什么要自動化?肯定不是為了炫技，針對一個發展中的網站來說，自動化的主要目的還是為了節省維護成本，提升運維成熟度能力。另外一個經常被忽略的收益是能讓運維工作更有趣味性一些，不那么無聊，不無聊的有益副作用是減少人為出錯的可能。

自動化針對的范圍大致可以分為安裝自動化、部署自動化、軟件發布自動化、升級自動化、監控自動化等幾個方面。優化自動化? 別，這個稍微”高級”并且不靠譜了一點。

自動化要解決的問題是 N 次循環的過程，如果 N 不具備延續性，那么自動化未必有必要。比如某個過程可能只是短時間內需要臨時進行幾次，是否有必要將其自動化就有待于商榷。如果計劃和開發自動化過程的成本高于非自動化成本就沒必要了。

開發自動化過程

如果看過古龍的小說，他曾經描述過幾個有趣的懶人，懶人造了一些木頭人和機關來幫自己干一些不愿意做的事情。自動化多少就是”懶人”要做的事情，因為懶嘛，所以才會想辦法節省時間和其他成本。一般來說，這個過程的開發者也是使用者，所以沒必要一定要按照所謂的項目過程去走，但是開發者必須能夠產出一份文檔給同團隊的伙伴(如果有的話)。

考慮到多數的網站運維可能都是在 Unix like 環境中的，而 Unix 的哲學思想之一就是”Write programs that do one thing and do it well”，每個過程只做一件事情就很關鍵，”功能單一的自動化模塊”是有必要的，把不同的模塊拼裝起來再去完成更復雜的需求。

Unix 相比 Windows 來說，天生具備可自動化能力。如 Shell/BASH(自動化日常操作)、CronTab(自動化任務調度) 、Expect (自動化交互場景) 、rsync(數據遠程同步)等 啊都是一些需要注意的技術內容。

優化自動化過程

自動化過程一般要有個生命周期，定期升級、優化也是有必要的。面對不同的應用場景應該逐漸改進自動化的可用性。

示例：自動部署 Linux

對于批量的 Linux 安裝，RedHat 提供有 Kickstart Installations 自動安裝解決方案，不過該方案相對比較繁瑣，前不久推出的 Cobbler 是讓人眼前一亮的好工具(參見 hutuworm 的介紹文章)。我一直懷疑 Cobbler 是中國人命名的項目，因為 PXE 發音為”pixie”(皮鞋)，而 Cobbler 的中文意思是”補鞋匠”。

OS 安裝完畢之后的軟件安裝、更新是個麻煩事。在一個 Linux 的環境中，SA 一定不要為軟件相互依賴性浪費太多的時間。什么 YUM、APT、YAST 啊，能用就用上。別太迷信自己編譯軟件所能帶來的優化收益，實際上犯錯的幾率更大。達到某個規模后，本地建立、維護一個軟件資料庫(repositories)也是有必要的。

Linux 軟件安裝進化之路：

手工預編譯-->RPM-->APT 等工具

已經進化到更好的階段了，沒必要還走著老路在原地折騰。

其他參考：Flickr 運維曾經采用 System Image 來自動化 Linux 相關的的運維工作。或許也可以嘗試一下。

在系統配置管理(別混淆到另一個配置管理上去)方面，其實 cfengine 就挺好用的。更多類似工具參考這個比較列表。

標準化，減少后續維護成本是節省人力資源的一大法門。

自動化的一些風險

必須要承認的是，自動化有的時候是容易帶來一些風險的，比如”沖掉”原有配置文件信息，不恰當的自動化腳本給系統帶來額外負載等，在運維過程中需要不斷總結經驗。(又落入俗套)

這方面值得推薦的一本書是《UNIX和Linux自動化管理》，借鑒一下其中的思路和方法。

對了，補充一下前面的《板橋三娘子》的故事發展，三娘子的面餅如果被客人吃下，則會變成驢…… 同樣，自動化有的時候會把人陷進去的，運維人不要變成自動化的奴隸。