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

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

[[82228]] 

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

以下為采訪實錄：

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

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

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

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

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

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

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

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

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

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

另外一個就是說，在生產(chǎn)環(huán)境下面會考慮到可用性、考慮到安全、考慮到運維的要求。它會把這樣的約束條件灌輸給團隊，團隊在設(shè)計系統(tǒng)的時候就考量這一塊的約束情況，這樣的時候?qū)嵤┚蜁靡恍?/p>

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

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

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

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

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

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

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

#p#

記者：在前些時間，IBM的一個技術(shù)峰會上面，我看到了很多人都在在討論著一個DevOps的主題，他們認為DevOps已經(jīng)成為幫助企業(yè)實現(xiàn)移動和云計算轉(zhuǎn)型的關(guān)鍵。你是怎么認為的？

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

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

記者：其實我知道目前大部分的互聯(lián)網(wǎng)行業(yè)企業(yè)都能夠適用DevOps這個方法論，或者說有開發(fā)部門、運維部門這樣的一些企業(yè)。那么DevOps在傳統(tǒng)的企業(yè)它能用上嗎？

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

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

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

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

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

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

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

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

從這幾點出發(fā)，或者到另外一個社區(qū)里面，DevOps工具也是越來越成熟，像我們以前做日志管理、做事件管理的工具，現(xiàn)在慢慢都由開源的成熟工具出來。其實從另外一方面也是加強了DevOps的能力，所以從雙方幾個大勢來看，我認為DevOps未來會在傳統(tǒng)企業(yè)、互聯(lián)網(wǎng)企業(yè)里面占據(jù)更多的比重。