互聯網+的需要 在信息越來越繁雜的互聯網時代，公司所運行的項目越來越多，項目相關服務繁多，服務之間存在複雜的依賴關係，運維與管理任務越來越繁重，手工交付需要花費很多的人力與時間，且安全性和時效性均無法保證。對於多資源型分佈/分離式部署項目，Udeployer應運而生。 隨著企業對版本上線質量和速度的 ...
互聯網+的需要
在信息越來越繁雜的互聯網時代，公司所運行的項目越來越多，項目相關服務繁多，服務之間存在複雜的依賴關係，運維與管理任務越來越繁重，手工交付需要花費很多的人力與時間，且安全性和時效性均無法保證。對於多資源型分佈/分離式部署項目，Udeployer應運而生。
隨著企業對版本上線質量和速度的要求越來越高，敏捷開發、Devops的接受度越來越高
傳統的交付方式因為項目之間缺少依賴、環境不一致、版本不一致、人為操作失誤等情況使得項目交付過程中問題不斷，而互聯網企業發展節奏快、版本發佈頻率高，上線出故障影響面廣、影響度高，因而企業對於敏捷開發、持續集成、自動發佈都有強烈的需求。
自動化從構建和測試開始
運維自動化的關鍵在於標準化。當你有一個成熟的團隊，有標準化的流程，那麼運維自動化就水到渠成了。而如果你什麼都沒有，那就需要先設定優先順序。
我們的目標當然是將所有的流程標準化，而哪些要放在前面做？做起來比較簡單的，和比較重要的。我認為構建和測試的流程是最基本的第一步。這對於交付產品的公司來說容易一些，對互聯網公司來說更複雜一些，而測試比構建也要複雜一些，但這是基礎。構建和測試的流程標準化做好了，就可以準備做自動化的工作了。
不過我見過的很多公司連Git都還沒有，仍然在用最原始的FTP push來更新代碼。我的觀點是，如果你還沒有用上Git這樣的工具，那根本就不用考慮什麼自動化的問題，因為條件完全不成熟。
所以，我們假設你的團隊能夠很好的使用Git，然後你建立了構建和測試的標準化流程，然後你就可以用工具來實現自動化。這可能是Jenkins這樣的工具，不過Jenkins比較複雜，如果你只是一個很簡單的網站，那麼自己寫一些腳本來實現自動化是更合適的。
到此為止，我們說的還不是自動化運維，而是自動化工具鏈。工具鏈就是開發工具鏈，從IDE，到代碼提交，代碼審查，構建，到測試，仍然屬於開發的範疇。在這之後才是運維的範疇，就是往生產環節部署。
部署
運維自動化最關鍵的部分是運行環境的定義。我們的目標是讓各個階段的代碼完全一樣，即開發者在自己筆記本上寫的代碼，到集成階段的代碼，到線上環境的代碼，都是一致的。為什麼Docker這麼火，就是因為它幫助開發者很簡單的就讓自己的開發環境跟生產環境一致。環境的標準化，意味著目錄、路徑、配置文件、儲存用戶名密碼的方式、訪問許可權、功能變數名稱等種種細節的一致和差異處理的標準化。這涉及到很多方面，也是自動化運維最困難的一部分。
這裡要註意的是，像Puppet這樣的工具並不是魔法。你需要自己為你的環境定義一套描述的方式，工具是無法為你完成這項工作的。無論是Puppet還是Jenkins，都是根據你的定義來管理你的環境。你決定用戶名和密碼如何儲存，你決定配置文件的路徑。開發者很喜歡把各種配置和url之類的參數硬編碼到代碼里，這很快；他們還喜歡東搞西搞的用一些亂七八糟的手段讓軟體通過測試，但是如果要構建一個真正的系統，這些小把戲根本沒用。你必須強迫他們採用標準的方式寫代碼，比如強制他們把用戶名和密碼寫在固定的地方，然後你才能跟Puppet說，配置文件在這裡，測試環境用這個配置，生產環節用那個配置。到這裡就很簡單了。
線上環境問題排查
對於線上環境的問題發現與解決，大部分基礎的問題都能用工具來自動發現並提醒，比如磁碟空間不夠，比如MySQL崩潰，比如訪問網站的時候出現錯誤頁面等等，有很多現成的工具可以抓到它們錯誤的信息。
比較困難的是排查網站為什麼變慢這樣的性能問題。我們經常看到客戶的開發團隊提交新代碼後引入問題。在測試做得不好的時候這很常見，事實上很多東西是很難測試的，尤其是性能；而互聯網公司又尤其沒有測試的文化，互聯網開發人員大多關註特性的實現，而不像傳統企業級開發那樣有很多測試的工具和流程。
理想的情況下，每個人提交代碼前都應該測試。但既然反正也沒人這樣做，那麼用工具來幫忙還是很有用的。比如New Relic這樣的工具就很強大，它可以發現代碼層面的問題。我們有時候也用我們的工具幫客戶做測試，包括負載測試。性能測試是挺困難的一件事，既不容易用起來，也不容易讓別人用起來，一般來說你需要一個專門的團隊才能做性能測試，但互聯網公司基本沒有（除了Google、Facebook這樣的），就算想有也找不到人。所以要善用工具。
Docker的意義
Docker很有意思，很火，很新，當然也很多問題。它目前沒多少大型部署案例，所以人們不斷的發現問題也是很正常的事情。
總體來說，Docker是一個對開發者非常友好的東西：簡單的實現不同機器上的環境標準化，可以輕鬆拿來拿去，而且在不同的雲平臺上都支持。而把Docker用起來對運維而言則是很大的挑戰，我們幫一個客戶做一個規模較大的Docker部署，一個有經驗的DevOps團隊也花費了幾個月的時間。為什麼？
推薦閱讀：
