Wikipedia對DevOps的定義是：

DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個集合。 它是人們?yōu)榱思皶r生產(chǎn)軟件產(chǎn)品或服務(wù)，以滿足某個業(yè)務(wù)目標(biāo)，對開發(fā)與運(yùn)維之間相互依存關(guān)系的一種新的理解。 ...... DevOps并不僅僅關(guān)注軟件部署，它是部門間溝通協(xié)作的一組流程和方法。

持續(xù)集成思想

怎樣才能達(dá)到這樣一種狀態(tài)呢，我們先放一下，看看持續(xù)集成（Continuous Integration）體現(xiàn)出來的一些思想。

縱覽全局（打破職責(zé)界限）

rd，qa，op，如果僅僅按照這樣的角色標(biāo)簽去處理事情，那就和圣經(jīng)里的巴別塔一樣，大家不說同一種語言怎么能勁往一處使呢。

我們把目標(biāo)放得更遠(yuǎn)一些，不再為了趕代碼而將質(zhì)量保障交給qa和op，不是為了增加測出bug的數(shù)量而和rd爭論，不是為了減少變更而是積極的適應(yīng)變更，我們共同的目標(biāo)是實現(xiàn)商業(yè)目的，確保軟件質(zhì)量（也包括變更質(zhì)量和運(yùn)行質(zhì)量）也是其中的一部分。頻繁的變更不是質(zhì)量的殺手，而應(yīng)該在軟件開發(fā)整個流程多個環(huán)節(jié)進(jìn)行質(zhì)量的保障，并頻繁的運(yùn)行這些保障。

這種方法就打破了目前的rd->qa->op流水線的流程，而是將三者緊密的結(jié)合在一起。從實踐的結(jié)果來看，rd每次提交代碼都會觸發(fā)一系列的自動化步驟，包括編譯，單元測試，代碼覆蓋率，功能測試，部署測試，性能/容量測試（注：后兩者受限與時間要求，實際實施不會每次提交代碼都觸發(fā)）。Rd，qa，op都在過程中做質(zhì)量保障。

是努力減少變化還是在變化發(fā)生時做好準(zhǔn)備。一定是后者，因為當(dāng)一件事情頻繁發(fā)生時，問題才會大量的暴露。解決暴露出來的問題才能促進(jìn)業(yè)務(wù)更好的發(fā)展，也是對團(tuán)隊能力的提升。

拿一個的實際例子，部署測試（Deploy check）和性能/容量測試（capacity test），我們比QA有更多的資源和條件，那么我們就應(yīng)該主動承擔(dān)起這份工作，然后將其加入到整條質(zhì)量保障線的必要環(huán)節(jié)上。

渾然一體（而非七零八落）

代碼樹被管理起來——主干開發(fā)

主干開發(fā)的好處是每個rd都知曉整體的變更，所有的feature作為一個整體發(fā)布，對OP的現(xiàn)實意義就是上線變得更有規(guī)律，非計劃的、臨時的上線***消失。

代碼和周邊（配置，數(shù)據(jù)，構(gòu)建腳本，單元測試，測試用例）統(tǒng)一作為產(chǎn)品被管理起來——一鍵式產(chǎn)構(gòu)建，測試，部署，完成產(chǎn)品的最終發(fā)布。

SVN結(jié)構(gòu)樣例

module 
|--product 
|----code 
|----bin 
|----scm_product.conf（描述程序地址） 
|----module_control 
|----conf 
|----data 
|----data_description（描述數(shù)據(jù)存放地址） 
|----ci-script  
|----test_case  
|----build_script  
|----test_script  
|----deploy_script  
|--development  
|--test 

好處易見，生成一個完整的產(chǎn)品的所有原料都被管理起來，上線僅需要一個版本號，不會出現(xiàn)上線時冗長的步驟，做版本diff，部署環(huán)境diff，測試case diff都非常簡單。而且，環(huán)境的備份也變得簡單和純粹了。

研發(fā)（開發(fā)，測試，發(fā)布，部署）全過程被管理起來。所有角色在一個界面下工作，使用共同的平臺，統(tǒng)一的源碼管理，共享。

 大家都在一個平臺上工作，所有的任務(wù)都在這個平臺下，各角色間對互相的工作有更深入的了解，并且，工作狀態(tài)也可以共享。

少就是多，簡潔就是美（用簡單的方法解決問題）
持續(xù)集成的解決方案是簡潔的。產(chǎn)品由SVN去管理，構(gòu)建過程由CI server負(fù)責(zé)，而構(gòu)建過程包含了編譯，測試，發(fā)布，部署過程

沒有封閉的系統(tǒng)，沒有蹩腳的流程，配合開放的系統(tǒng)（Code Review/wiki）所有的信息被自然的整合在一起。而一切都是以提高變更速度，提高產(chǎn)品質(zhì)量為目標(biāo)。

當(dāng)解決方案讓你覺得不自然（或有很多內(nèi)容無法囊括，或需要人為干預(yù)）的時候，那這個方案就不是一個***的方案，必定在某一些方面受到了限制，這些限制有可能是歷史造成的。要勇于質(zhì)疑，擴(kuò)展角度，提升高度。去掉角色的限制，站在產(chǎn)品的角度去思考，對于整體的優(yōu)化的解決方案就產(chǎn)生了。

以終為始（一直以發(fā)布級的質(zhì)量要求產(chǎn)品）

寫代碼都是為了要發(fā)布的，也就是需要上線使用的，那在開始編碼就以產(chǎn)品的質(zhì)量要求代碼，要求check in的代碼就是能夠完成編譯的，具備一定功能并且可以部署的產(chǎn)品。

將質(zhì)量內(nèi)建于產(chǎn)品中。每次代碼的提交都會經(jīng)歷單元，功能，部署，性能/容量測試。在上線前我們就能夠知道是否能成功部署，線上的服務(wù)器是否能撐住。這樣的產(chǎn)品在上線時我們就不會有那么大的壓力了，OP也不需要擔(dān)心回滾的風(fēng)險了，即使回滾，那么回滾也是one step。小菜一碟。

我們與DevOps的距離

那么我們離DevOps有多遠(yuǎn)呢。從各個公司放出來的技術(shù)資料（flickr最全面），最經(jīng)典的是flickr的10+ deploys per day，他們的***實踐有以下幾點，而起穿針引線作用的是持續(xù)集成（技術(shù)上）和思考方式（文化上）。

Culture：

1.respect 
2.trust 
3.healthy attitude about failure 
4.avoiding blame 

從文化上，我們需要一種氛圍，不僅僅把自己看作rd，qa，op這樣的角色，哪里有質(zhì)量缺口，我們就要把它補(bǔ)起來；哪里有不通暢的地方，我們就要把它疏通。RD了解op的部署方式，能夠獲取OP提供的監(jiān)控指標(biāo)；OP也了解RD的開發(fā)方法，開發(fā)流程，所面對的問題。放開自己的眼界，從更高的視角看待和解決問題。

Tools：

1.Automated infrastructure（自動化，系統(tǒng)之間可集成）
2.shared version control（SVN共享源碼） 
3.one step build and deploy（持續(xù)構(gòu)建和部署） 
4.feature flags（公司內(nèi)部稱為single branch，主干開發(fā)） 
5.Shared metrics 
6.IRC and IM robots（信息整合）

技術(shù)上的這些要點被3（持續(xù)集成/部署）一線貫穿。

4點（主干開發(fā)）是持續(xù)集成的前提 

1點（自動化），2點（代碼及周邊集中管理）是實施持續(xù)集成的必要條件

5點是1的一部分（圖表是由自動化系統(tǒng)產(chǎn)生的）

可見，技術(shù)上的核心是持續(xù)集成/部署

5所提到的有較高的技術(shù)要求。要求我們將業(yè)務(wù)/運(yùn)維上的指標(biāo)變得可測量，直至可預(yù)測。這里面的兩個核心技術(shù)內(nèi)容就是：

容量測量（Capacity management）

容量的變化體現(xiàn)在用戶行為（流量）系統(tǒng)變更（軟件性能）和資源（服務(wù)器數(shù)量，冗余度計劃）等幾個因素的變化上，將容量和這些變化掛鉤，在每一個因素變化下重新得到系統(tǒng)的容量，從而在變更中控制容量不足造成的風(fēng)險。有一個要點，我們需要的是系統(tǒng)的容量而不是單個模塊的性能。

質(zhì)量反饋（Quality feedback）

變更會導(dǎo)致質(zhì)量變化，而質(zhì)量變化體現(xiàn)在各種指標(biāo)上，而測量這些指標(biāo)（包括應(yīng)用指標(biāo)：平響，處理效率等和系統(tǒng)指標(biāo)：負(fù)載，網(wǎng)絡(luò)流量），發(fā)現(xiàn)指標(biāo)之間的規(guī)律，將指標(biāo)share給整個團(tuán)隊，從而有效的達(dá)成質(zhì)量的反饋，控制變更（包括內(nèi)部變更和外部條件的變化）造成的質(zhì)量下降的風(fēng)險。本質(zhì)上說，容量測量也是質(zhì)量反饋的一部分。

在實施持續(xù)集成的過程中，并行實施的三個項目：

• 持續(xù)部署/一鍵式部署（continuous deployment/one step deploy），
• 容量測試/管理（Capacity Test/Management） 
• 質(zhì)量反饋（Quality feedback） 

分別對應(yīng)于上面三個要點，共同支撐系統(tǒng)的高速迭代，減少系統(tǒng)頻繁變更引發(fā)的風(fēng)險。

借助于持續(xù)集成，我們在實踐中向DevOps邁進(jìn)了一大步，離業(yè)界的***實踐已不遠(yuǎn)。dev和ops說著同一種語言，共同為業(yè)務(wù)發(fā)展和質(zhì)量保障做出貢獻(xiàn)。

敏捷/精益開發(fā)方法可以提高應(yīng)變業(yè)務(wù)變化的能力，并內(nèi)建質(zhì)量。DevOps把開發(fā)和運(yùn)維的溝壑抹平。那么我們的development和ITIL就能夠結(jié)合到一起了。

我們曾經(jīng)愿景將服務(wù)器放到機(jī)架上，一鍵就能完成服務(wù)上線，我們已經(jīng)有了一個好的開始，這個目標(biāo)就會實現(xiàn)。