我們都知道現在中國互聯網的發展速度是非常迅猛的，可以說在世界上也達到了相當的規模和比例。那么在軟件行業進入互聯網時代后，在整個市場用戶對軟件產品以及服務的要求也跟著提高，這不僅需要開發和運維人員快速實現，而且要快速部署發布上線，并且必須保證業務可靠、高效運行。那么如何去滿足這些要求，加強IT組織需要強有力的流程呢？

在2013年阿里巴巴集團主辦的ADC•阿里技術嘉年華這一場專屬于<互聯網工程師>的“技術盛宴”，倡導<干貨分享>的大會上，51CTO記者有幸采訪到了ThoughtWorks的首席咨詢師 金明老師， 在針對以上的問題和DevOps與敏捷之間的一脈相承關系在實際項目操作中的典型問題以及DevOps人員角色部署等典型問題展開討論，以及給出解決對策。

[[82228]] 

金明，ThoughtWorks首席咨詢師，擁有多年企業應用與互聯網應用開發經驗， 熱衷折騰新技術，是敏捷和精益的堅定追隨者。目前主要關注于持續交付、DevOps、敏捷實施、組織轉型以及虛擬化和云計算，同時積極參與開源軟件以及國內外軟件開發者的大會與社區活動。

以下為采訪實錄：

記者：敏捷的出現打破了用戶、開發和測試之間的隔閡，實現了團隊的協作。DevOps的出現和敏捷之間有著什么樣的關系？

金明：我覺得這個是一脈相承的，我們傳統意義上來講，傳統模型帶來的是開發及測試的部門壁壘。隨著我們通過像敏捷，像Scrum這樣的敏捷方法，在加強開發團隊和測試團隊之間的溝通協作之后，其實我們不可避免地會面臨到開發部門和我們的運維，以及發布運營這樣的一個瓶頸。它會取代我們之前開發團隊里面所遇到的障礙和瓶頸，我們新的要解決這樣的問題。所以DevOps我認為，它從時間上來看，大概是零七年左右在國外開始流行。從它的思想和實踐上來看，也是隨著敏捷的實踐項目繼續集成、自動化部署這樣的一些實踐成熟。它慢慢地流行起來。

記者：他們之間人員的部署情況，開發人員跟運維人員之間，人員角色和職責這塊相關事情如何去部署？

金明：傳統的意義上講，我們開發團隊，開發完了之后往往是打包扔給發布部門，或者說是運維部門，隨著我們對于發布的要求越來越高。我們其實是要求，就是說生產環境的運維部門和發布團隊，跟開發部門坐到一起，雙方角色互補，開發人員去學習運維的知識和工具。運維去提供我生產環境部署的約束和要求，雙方融合形成一個比較一體化的DevOps這樣的團隊。

記者：目前在云計算上也提供了一些相關的部署，這樣是不是能夠很方便地推進DevOps？

金明：是，因為傳統的，我們之前是說，在虛擬化和云計算出來之前，往往我們的部署和生產運維，而且都是在實體機上面，實體機上面的成本基數很高的。在虛擬化技術出來之后，我一個普通的運維人員，輸入命令就可以得到幾臺這樣的虛擬機。當這樣的工具出來之后，我可以再輸入命令就會拿到一個完全一樣的環境出來。所以我們來講，隨著虛擬化和云計算技術，以及周邊的管理，像自動化創建工具這樣的成熟后，DevOps就傳統的運維技能會變得越來越大眾化，可以被我們開發人員所接受、所擁抱，再用到環境里面去。

記者：很多開發者都認為，迭代項目管理方法Scrum是敏捷開發的代名詞，DevOps您認為用什么來做它的代名詞比較合適？

金明：我覺得目前不足以說，就是還不足以說出現像Scrum的這樣的一個方法論里面比較典型的方法，我就說方法。因為DevOps還是以工程實踐為主，管理實踐這塊，像Scrum成體系的還比較少。目前各大工具是正在慢慢演化的過程里面，我們看到的剛才講虛擬機配置和我們來講部署，各自有各自的工具來做。目前還沒有看到說，從底向下，整個打通的DevOps的方法論。

記者：開發人員和運維人員認識的方法，以及各自所處的角色，都存在根本性的差別。如何通過DevOps來解決他們之間的一些開發部署的問題。

金明：那我就舉個例子，像我們之前在國外的項目上面，之前他們開發和運維是分開的兩個部門，項目之間通過一個發布包，做出一個FTP這樣的去溝通。其他團隊把包放在FTP上面，然后運維從FTP上取下包去部署。這個導致的問題就是，很多生產環境下面的環境配置，這樣的一些軟件要求，跟開發的時候不一樣。我們現在做事的方式是，就是說從發布團隊和運維團隊里面，它會變成一個池子，里面每個成員會變成具有DevOps能力的成員。DevOps成員是作為團隊的一分子參與到開發團隊的日常工作里面去，它的幾個主要工作職責會包括，第一，它會幫助團隊把他們團隊對環境的配置、對環境的要求，用一些工具把它變成代碼，變成自動化的。

另外一個就是說，在生產環境下面會考慮到可用性、考慮到安全、考慮到運維的要求。它會把這樣的約束條件灌輸給團隊，團隊在設計系統的時候就考量這一塊的約束情況，這樣的時候實施就會更好一些。

記者：很多人都認為DevOps是一個非常強大的方法論，它可以在眾多不同層面上產生共鳴。您認為開發人員和運維人員應該如何去落實DevOps？需要具備哪些條件？

金明：在我們公司的話，DevOps也會變成是一種角色，就像我們開發測試一樣變成一個角色。很早的話跟團隊一起來工作，然后考慮我們像環境自動化、配置自動化，以及我們部署自動化這樣的事情，很早會作為團隊的一份子參與到這里面去。

就相當說，假如說一個傳統的團隊，我希望往DevOps這塊去轉型的時候，可能要一些這樣的先決條件。在整個過程可能要有些這樣的挑戰和問題要克服。的確是說，開發和運維其實是兩種不同的技能，開發的頭腦里面就是我趕緊把代碼寫完，扔給運維就好了。運維的頭腦就想著，我這塊要是出了問題，那我就可能睡不著覺，每天晚上接到電話起來維護。

其實來講，兩邊對對方存在一些這樣的誤解，很大的原因就是，大家對于各自工作是不了解的，他不知道運維需要做什么事情，我只看到運維可能有這樣的一些報表，有這樣的投影，投在那里說系統實際是怎么樣，有沒有出現問題。運維看到開發團隊在那邊寫代碼，也不知道在做什么事情。要想在團隊里面實施這樣的運維，DevOps的話，其實我們覺得它從文化和技術，或者是技能兩方面都要提供相應的輔導。從文化層面上面來講，就要鼓勵我們的運維和開發人員坐在一起，互相地分享。因為團隊的目標還是一致的，我把系統更快的部署到環境上去，讓它能夠穩定安全地運行。從文化上面來講，首先要讓大家理解這樣的一個，大家是共同的目標，不是說勢如水火。

其次的話，要營造出雙方相互協作的一個情況、一個場景。就是文化上面，然后從場景和技巧上面來講，除了雙方對于各自技能的掌握和培訓之外，我們發現還是有一些前提條件是比較滿足的，比如說我們來講企業集成。我們需要自動化測試，只要我們能夠在團隊內部把企業集成和自動化測試先做到一定程度的話，比如說我們可以有信心地拍胸脯說，我們這個軟件沒有太大的問題。在這樣的情況下面，我們再引入DevOps做這個，從軟件交付的角度來講，會是比較好的一種方式。否則的話團隊整天在修復缺陷，這時候我們的運維和開發坐在一起可能沒有太多的意義，這是第一。

第二就是說，如果我們不是這么全局來看，我們是從局部優化來看，我們可以看到運維團隊在系統配置、系統創建這一塊的技能。它也是非常必要的，因為我們發現開發團隊，不管是開發還是測試，它其實有一個很嚴重的問題，他們要想做調試、做測試的時候，環境是不夠的?？赡苓@個環境做完一套測試之后，環境就被污染了、數據被污染、我的應用包被污染。在追求環境的準備和提供方面，其實我們的運維是可以進來，或者是我們的DevOps團隊是可以形成的，然后去做一些相對來講沒有那么廣的事情，還是跟在這一塊上面。而這個前提條件就可能是我們這樣的一個架構也好、技術也好，能夠比較好的支持我們DevOps去做基礎設施代碼的工作。

跳出這兩種方式，兩種場景下來看，如果在一個組織里面想去推DevOps的話，其實上層的支持是必不可少的。上層要有這樣的決心和魄力，我們來挑個項目，我們從點擊項目開始，我們試著哪一個運維團隊的成員跟開發團隊坐在一起。然后看看如何在雙方的磨合過程里面，能夠取得一個比較平衡、比較優秀的結果。其實也看到這樣的情況，有一些組織，尤其是互聯網組織，他們的CIO就會喜歡拉一個團隊。從運維里面拉一兩個人出來，那就專門做環境自動化，就設計代碼這個工作，去幫助他的開發團隊里面，去準備測試環境的，一鍵式搭建，一鍵式配置的事情。

#p#

記者：在前些時間，IBM的一個技術峰會上面，我看到了很多人都在在討論著一個DevOps的主題，他們認為DevOps已經成為幫助企業實現移動和云計算轉型的關鍵。你是怎么認為的？

金明：這是一個非常大的概念和論斷，從大層面來講，我是基本贊同這樣的一個論斷的，為什么呢？隨著移動應用和云計算的興起，其實給我們開發帶來兩個大的變化。一個是開發這邊的復雜信息降低了，我們傳統意義上的互聯網，比如做個網站，你前后端代碼可能是幾十萬行、幾百萬行代碼，出現移動互聯網的應用可能就是很少的一些代碼，輕量的這樣一個應用。

從這樣的角度來看，在傳統意義上，如果說去對我的應用做測試，去做集成，它所暴露出來的問題就不是整個移動應用去運維業務上面的大問題。相反我如何能夠快速的開發出來，然后發布出去，然后積極反饋、修改，再快速發布出去。這個變成我們移動應用能否在互聯網業務上面取得門傳票的這樣一個很關鍵的點。從另外方面來看，從云計算來看，它虛擬化技術又給我們帶來背后的，基礎設施這一塊的輕量化。技術和應用輕量化，加虛擬化和背后基礎設施的輕量化。這就迫使我們在如何融合雙方的節點上面，來提出更好、更先進的工具和技術，DevOps就來幫助我們解決這個問題。

記者：其實我知道目前大部分的互聯網行業企業都能夠適用DevOps這個方法論，或者說有開發部門、運維部門這樣的一些企業。那么DevOps在傳統的企業它能用上嗎？

金明：這個問題，我想這樣來看，DevOps類似于我們敏捷方法，它其實也是跟思想原則和具體的實現，DevOps它的本身的這樣一個思想和價值觀就是說，讓我們的開發和我們的運維也好，或者說我們的實施也好，讓他們能夠更好地，雙方能夠消除各自領域的浪費。從原則上來講，就會有一些像基礎設施代碼、配置自動化等等這樣的一些原則。

我想對DevOps來講，不管是傳統行業，還是互聯網行業，或者是移動應用行業。其實它的原則和思想都是適用的，是通的。但是在具體上可能會有些差別。舉個例子，應該是愛立信，愛立信之間有這樣的網絡設備，網絡設備整個的需要開發，上到板子上面，部署到機房里面去測試。之前的話會出現一個問題，它在實驗室的板子上面燒的程序是可以工作，大概到生產上的板子，實際上的板子，它也是不能工作的。于是他們針對這個問題，也是做了DevOps相關的這樣一些活動，把生產環節和實施上面的，這樣的一些問題和要求，提早地告訴給開發團隊。讓開發團隊在他們的實驗室里面，就按照生產環境準備相應的板子和規格。在開發的時候，就按照跟生產環境幾乎一致的板子來驗證他們實際是否是一樣的，這也是DevOps良好的一個使用場景。

如果存在多套不同的環境也好，或者是碰到不同階段，比如說我們開發調試構建，跟我們今后的運維，或者說實施，這樣的階段其實他們都會這樣的優化和改進的空間，雙方的一個融合，就是DevOps這樣的一個空間和土壤。

記者：之前我也了解過，在ThoughtWorks公司里面的一些項目也用到了DevOps持續交付。在這個過程當中，你們公司在實施的過程當中，你們遇到一些什么樣的問題？

金明：這其實是一個現在很多人會關心的問題。就是說DevOps雖然給我們承諾，或者是許諾這么良好的一個愿景，在具體過程會有些什么問題？在我們做的時候也是遇到一些相對的問題？現在我講講最主要的幾個大的問題。

在我們傳統的像軟件架構的設計和它對于這樣的配置，環境配置、像數據這樣的一些管理的工作，并沒有達到一個比較成熟和穩定的地步。導致的問題是什么？比如說我們曾經遇到這樣的一個項目，這樣的一個系統。這個系統包括十幾個這樣的不同系統組成，不同的系統使用的技術又不一樣。有些系統，甚至是沒有人能知道他上面的配置信息什么樣子，因為這個已經太早了，用了比較早的語言來寫的。所以這塊信息的丟失，其實對于我們DevOps來講，就會導致走很多的彎路，很多這樣的一個嘗試。但是其實正是因為DevOps，反而才能解決我們之前像這樣配置信息丟失，架構不合理，分成和我們的模塊不合理，這樣的情況。所以這也算是DevOps給我們帶來反向的一個優勢，讓我們很好地審視我們之前的交流設計、我們的發布、我們的環境配置是否是經過仔細考量和設計過的。

記者：你能闡述一下你對DevOps前景的發展是怎么樣的？

金明：我覺得會是一個比較廣闊的空間，因為這塊是涉及到三個大背景的考量，第一個大背景是市場的不確定性，導致IT對于業務的響應，要求是越來越快。第二個是像現在公有云的技術，對于我們企業內部基礎設施，乃至私有數據中心的要求。第三個就是我本身應用系統越來越簡化的大背景。在這幾個背景下面來看，其實我們就發現，我們的企業里面，不管是什么企業，企業里面這樣的運維團隊和開發團隊會面臨到交付周期越來越短，對于基礎設施這塊響應的能力越來越高。我的系統越來越簡化，越來越傾向的這樣一個背景。

從這幾點出發，或者到另外一個社區里面，DevOps工具也是越來越成熟，像我們以前做日志管理、做事件管理的工具，現在慢慢都由開源的成熟工具出來。其實從另外一方面也是加強了DevOps的能力，所以從雙方幾個大勢來看，我認為DevOps未來會在傳統企業、互聯網企業里面占據更多的比重。