親身經歷：遠離培訓機構才能做好運維
原創【編者按】本文作者老曹，在車聯網、互聯網、通訊等行業都有豐富的運維工作經驗，在運維自動化熱潮如火如荼之時，他幽幽的說了這句話：“如果你入職第一個月就被要求設計部署自動化方案，那只能證明這個公司確實沒有運維人才，且這個公司很閑其實不需要運維。”
早在2010年，老曹就開始了puppet運維自動化之旅，但他逐漸了解到運維自動化是一個很雞肋的技能，就像屠龍之術一樣，對大部分人來說學會了很炫的技能，但是無龍可屠。現在的自動化運維都有很大的忽悠成分，大公司請個外來戶搞自動化幾乎不太可能，小公司就那么兩臺機器，做運維自動化更是浪費人力。老曹希望做運維的小伙伴們不要沉迷于自動化培訓的熱潮上，而是把更多精力用在技術浪潮上——只有這樣才能真的提高競爭力，故而寫下了此文，給大家做個參考，純屬個人建議，歡迎拍磚。
運維自動化是2010年開始炒得很熱的一個概念，也讓很多工程師、用人單位瞎激動了很久，我也跟風學過puppet和python，求職雙方也經常在面試時花大量時間談運維自動化。
但冷靜下來想想，所謂自動化，只是讓培訓機構賺錢的噱頭而已。
一句話概括運維自動化
單說“運維自動化”幾個字太抽象容易被主觀塞進去很多概念，上百科搜索到IT運維自動化的介紹又太詳細、大帽子太多。
如果把運維自動化在一句話說清楚，比較官派的說法就是：“運維自動化就是在企業業務越來越復雜、對IT人員要求越來越高……balabalabla……的前提下，靠人工已經無法滿足運維工作的需求，只能靠自動化技術來解決這一問題。”
如果用比較粗糙的說法就是“活多人少的情況下，運維不想靠堆人力去解決繁瑣的問題，只能靠運維自動化來給自己減負。”
運維自動化理論與現實相悖
粗看這些理論挺有道理，但仔細分析根本不是這么回事。首先，我們真的忙了嗎？
我認為運維的工作量并沒有隨著企業需求越來越復雜而變大，就算變大也不是靠自動化能解決的體力活。
運維自動化是給運維用的，請各位運維想想，我們的日常工作，這些年來有太大變化嗎？
初級運維大部分時間在做上線和監控，高級運維在改結構修bug。對于那些重復性的工作，云計算供應商能比你做的更好，云主機、云監控、云RDS、云存儲等等服務都是在給運維減負。
企業業務需求越來越復雜是真的，具體來說是技術進步企業要求越來越刁鉆了。數據庫要求主從實時同步，存儲不能用NFS要用分布式，前端業務要求無縫切換等等。我是不是談偏題了，這些東西跟運維自動化有什么關系？你意識到問題就好，我們這些年新增的業務需求，沒多少是可以靠運維自動化解決的，要解決這些問題，還要靠我們自己的腦子。
運維自動化=shell腳本
其實我們一直在做運維自動化，因為我們會用shell腳本。
我們可以說只要企業需求有變動，我們就要搭服務、搭監控，做這些事情都要寫自動化腳本。當你激動的說到“自動化腳本”的時候，我想問一下，你不會寫shell腳本嗎？
搭完某個服務以后，一個有經驗有責任心的運維，自然會寫好系統優化腳本，復制監控監控模版。如果我們用puppet，用python，最后一樣脫不了指定主機名的工作。
我們完全可以用shell腳本完成各種模擬運維操作的動作，熟練使用shell腳本也是每個運維的必修課，我們有必要為了一個噱頭去學習python嗎？
我曾經看過puppet的官方文檔，他能管理的資源列出來的有“文件”“屬主屬組”“掛載”“軟件包”“服務”“-exec使用本地shell”，在我看來其實也就是“文件”和“-exec”。
在Linux shell腳本里，關于運維有這么多命令“cp、scp、nc、ssh、rsync、svn、chmod、chown、service、/etc/init.d/”，這些命令已經夠用了。
我用puppet的時候，只是用他頻繁監控幾個重要的系統配置文件。上線的工作真正繁瑣在要把realserver從LB上摘下來，且需要用人力去判斷能不能摘。
具體摘設備、傳新備老代碼、重啟java容器、回滾代碼的工作我都寫好腳本了，就這樣還因為麻痹大意而出了幾次高負載或丟步驟的情況。
如果能運維自動化的東西，必然能寫shell腳本搞定，如果用shell腳本搞不定的東西，“運維自動——掛”。
運維自動化≠優化
老生常談，運維應該眼界高一些，不要總是忙著優化手頭的工作，而要想手頭的工作有沒有必要。
有朋友肯定要說我的工作不到家，上線居然還需要人力判斷，我承認這是問題，但這問題在架構不在運維。如果上線不需要人工干預，為什么不直接讓開發執行？甚至更進一步，讓應用服務器定期去svn上檢測有沒有新代碼？在測試環境我們也會用hudson和maven讓開發自己搞，但我肯定做好一個系統鏡像保證他們把系統玩壞了也能快速恢復。
在生產環境里，運維該做的不應該是糾結一步人肉操作該用shell還是python代勞，而是說好好去推動一下，能不能多上幾臺服務器，能不能降低一下耦合度，不要讓我們手動盯著上線工作了。
我現在的公司后臺做的不好，很多業務相關的sql修改都要開發寫好語句給運維執行。如果這個時候我給mysql安裝個phpadmin就是本末倒置，寫個腳本能自動傳sql過去還是本末倒置，我實際該做的是催促公司盡快做出來企業管理后臺可以讓運營和客服人員直接去改業務數據。
我們寫多少牛逼的python腳本，不如做一個穩定到單機房斷電都不會宕機的架構；用好運維自動化很牛逼嗎？是的，就跟用好某種文本編輯器一樣牛逼。
運維自動化背后的利益推動
鼓吹自動化的大師里，很多位其實是運維開發兩條腿都很短的雜魚。
我曾經看到過一個運維自動化的教程，作者很認真的教我們，如何用某種自動化工具調用本地shell，用sed命令將crontab里的ntpdata任務時間給變更了。看到這一段，我被他的執著蠢哭了，所謂的自動化居然是用ntpdate更新系統時間。
我也見過某大師寫的自動化代碼，朋友告訴我他的python水平只值6k——連異常都不處理，我用半瓶醋的水平仔細看了一下他的源碼我真的笑出來了，每隔幾行必然能看到一個os.system(“shell命令”)。
在工作環境里，我用“tar/var/aaa/bbb/ccc/*.jpg”這類通配符匹配出來目標文件，寫了個10行的腳本，將某高手用perl寫了100多行，但其實就是find+tar的腳本給替換掉了。
在處理數據的時候，我也寫python腳本，因為效率遠超shell腳本。但運維自動化一定要用python腳本，更新文件必用puppet，對高手來說這是風格，對新手來說這是跟風。
有心的朋友可以幫忙查一下，從2010年開始，都有哪些培訓機構新增了運維自動化課程或python運維課程，又有哪些人靠這些技術把自己包裝成了大師。
運維自動化的困境
那些高端大氣上檔次的運維自動化教師們，永遠無法回避我這兩個問題：
1、在一個100臺機器下的小公司，搞運維自動化是不是在自己立項冒功？你寫好的運維自動化系統，是不是配合著把文檔寫的很細很好了，會不會系統升級一下就運維自動掛了。
越是小公司，越容易出現單臺機器跑多個業務、不同機器的環境變量完全不同的情況。假設你是個技術新兵，不用自動化只會掛一臺機器，用自動化掛一堆機器；假設你是個技術高手，你知道其中的風險更不會盲目的信任一個腳本。
2、在500臺機器機器以上的大公司，確實很需要運維自動化，否則光是手動畫網絡拓撲圖和加監控就能累死人。
但在這個環境里，最重要最有含金量的是系統架構的設計和演進；運維自動化只是減負的工作而已，哪有聰明人放著金磚不要卻要板磚的？
你覺得有沒有可能這個公司幾十個技術高手天天為上傳個js文件累的要死，就等你一個空降兵來部署自動化系統解救他們的？
做運維自動化，必然是自己公司內部的服務器有大量增加，增加到你覺得手動操作很累的地步，這個時候做運維自動化是水到渠成的。但運維自動化的工作一般是企業內部已有的運維來推動的，這不應該當作招人的理由。
運維自動化也不是簡單的寫一些腳本或部署文件同步工具，它沒有真正成型的方案，因為這是要用機器模擬運維工程師的勞動方式。每個運維團隊的工作風格都不同，生搬硬套外來的自動化方案只會讓我們邯鄲學步舉步維艱。
如果你入職第一個月就被要求設計部署自動化方案，那只能證明這個公司確實沒有運維人才，且這個公司很閑其實不需要運維。
重新審視運維自動化
運維自動化的目的，放低端點，就是解決運維手動操作容易出錯的問題，放高端點是希望運維忽略具體命令而更重視最終成果。
在低端領域，我們可以很自信的說，用shell腳本就是運維自動化；在高端領域，肯定已經搭建好了自動化環境供我們觀摩學習和修改；如果你有幸參與到大規模自動化部署，那是確實是一次很有趣的挑戰；在一個更高的層次上，你會發現諸如系統標準化、應用模塊化、統一認證系統等等更有價值但沒人炒作的技術。。運維自動化不用專門去學習，自動化的“大師”也不用刻意招聘。
最順手的工具就是最好的工具
IT人熱愛某個技術就應該成為某項技術的主人而非信徒；我在文中多次強調shell腳本的可用性是因為shell腳本是每個運維必須掌握的技能。
在本文中我大量引用了對時下最熱門的幾個自動化運維工具的一些批評案例。但這些樣例并不是用來攻擊這些技術本身。事實上我Puppet應用QQ群是我唯一一個沒有退出的Linux技術群，而我明白自己的Python水平看復雜的代碼都費力。只因為這兩個技術被野風吹的最火，我用他們來說明每桿大旗下都少不了盲從的人。
如果你堅信某個技術是特別強悍的并對我的言論怒火中燒，請你想想你能用你的工具做到的事情，在我的環境里能不能提前繞過，就算碰到了我能不能用shell腳本解決掉。我并不反對你推廣你的方案，但我認為“循環調用SSH命令是一個我能接受的、可行的方案”。
我們應該減少盲從，拿起最順手的工具去做一番事業，而不是玩賞最精美的道具卻迷失了目標。
