Wikipedia對(duì)DevOps的定義是：

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

持續(xù)集成思想

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

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

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

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

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

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

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

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

代碼樹(shù)被管理起來(lái)——主干開(kāi)發(fā)

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

代碼和周邊（配置，數(shù)據(jù)，構(gòu)建腳本，單元測(cè)試，測(cè)試用例）統(tǒng)一作為產(chǎn)品被管理起來(lái)——一鍵式產(chǎn)構(gòu)建，測(cè)試，部署，完成產(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 

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

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

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

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

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

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

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

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

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

我們與DevOps的距離

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

Culture：

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

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

Tools：

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

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

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

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

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

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

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

容量測(cè)量（Capacity management）

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

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

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

在實(shí)施持續(xù)集成的過(guò)程中，并行實(shí)施的三個(gè)項(xiàng)目：

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

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

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

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

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