隨著開發效率的提高，運維的自動化已經成為很多技術團隊越來越重視的問題，否則部署的速度容易成為業務創新的瓶頸。在這個背景下，定位于給互聯網公司做運維服務的云絡科技公司接觸了越來越多的客戶，對國內互聯網公司的運維水平有相當多的了解。他們看到的現狀是怎樣的?技術團隊要實現運維自動化應該從哪里開始?像Docker這樣的技術如何影響開發者與運維工程師?在本次采訪中，云絡科技CEO Steve Mushero談論了這些話題。

[[127894]]

嘉賓簡介

Steve Mushero從硅谷來到中國，在全球范圍內的廣泛行業及從業企業中擁有超過25年的技術管理經驗，其中包括IT運營、軟件開發、物流、制造以及機械等領域。他曾在土豆網(中國)、Intermind、New Vine Logistics以及Advanced Management Systems等企業擔任過CTO，擁有***架構師工作經驗，并以顧問身份為世界衛生組織、格萊珉銀行基金會以及多家全球財富五***企業的全球化項目提供指導。

自動化從構建和測試開始

運維自動化的關鍵在于標準化。當你有一個成熟的團隊，有標準化的流程，那么運維自動化就水到渠成了。而如果你什么都沒有，那就需要先設定優先級。

我們的目標當然是將所有的流程標準化，而哪些要放在前面做?做起來比較簡單的，和比較重要的。我認為構建和測試的流程是最基本的***步。這對于交付產品的公司來說容易一些，對互聯網公司來說更復雜一些，而測試比構建也要復雜一些，但這是基礎。構建和測試的流程標準化做好了，就可以準備做自動化的工作了。

不過我見過的很多公司連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團隊也花費了幾個月的時間。為什么?

Docker容器就跟VM差不多，從運維的角度，會希望像管理VM那樣管理Docker容器，但是Docker容器很難troubleshooting，因為默認來說它沒有SSH，你要怎么登陸到一個容器里去查看里面發生了什么問題?Troubleshooting，這是一個***的問題。

默認來說，Docker容器也無法運行cron任務或者batch任務，意味著你沒法兒讓它自動做備份之類的工作，而這是最基本的運維任務，這是另一個必須解決的問題，否則你根本無法構建一個自動化管理的云環境，而要解決這個問題，你需要搞一些手段，比如改造它的架構，但是你一折騰，又引入了很多新的問題要解決。

Docker有很好的網絡機制，但是也很復雜，所以我們bypass了所有的Docker網絡，而這也引入了一些問題。Docker容器也沒有好的重啟方法，因為你很難看到哪個是哪個，需要做一些好的命名映射的管理系統。總之，要在大型部署中把Docker玩好，你需要各個方面的專家，還需要時間。

我并不懷疑Docker是趨勢，它的概念非常好，會極大的改善開發者的世界。如果你的系統比較簡單，不是很大，那么用Docker是完全沒問題的。而且它的文檔很好，這也是很贊的地方。我相信它會***未來。它只是還需要時間來完善。而這也不奇怪：想想KVM，其實KVM做的事情很簡單，就關注系統層和CPU、內存、存儲、網絡的交互，并不難理解，但即使是目標如此簡單的項目也多年處于問題層出不窮的狀態，人們不斷的圍繞它開發工具，改進它，才到了今天的可用狀態。Docker則復雜的多，有很多層：它是一個環境管理系統，它是個打包系統，它是個文件系統，它包含一套網絡機制，它是一個repo系統，它是個代碼系統，等等。基本上，Docker想要把所有的東西都扔到一個小盒子里，五臟俱全。當你用Docker提交代碼時，你做的事情跟以前是完全不同的。在以前我們只是把代碼提交上去，而在Docker中我們把整臺計算機(虛擬機)提交上去。想象一下，這就好像是交換電腦一樣，開發者把整臺電腦交給運維，電腦里面的環境和代碼都有了，是不變的;而運維需要把所有的電源網線什么的都插回去，需要處理很多變化的東西，比如變更的IP、用戶名、文件系統等等。這是全新的方式。