關(guān)于DevOps你必須知道的11件事

來(lái)源：塔塔 更新時(shí)間：2016-11-17

更多

編輯注：本文來(lái)自技術(shù)出版商IT Revolution，最初以白皮書(shū)的形式發(fā)布為The Top 11 Things You Need to Know about DevOps。經(jīng)本文作者Gene Kim和本文譯者戚一品的授權(quán)與推薦，現(xiàn)將完整譯文分享給InfoQ中文章的讀者們參閱。

關(guān)于作者

Gene Kim在多個(gè)角色上屢獲殊榮：CTO、研究者和作家。他曾是Tripwire的創(chuàng)始人并擔(dān)任了13年的CTO。他寫(xiě)過(guò)兩本書(shū)，其中包括《The Visible Ops Handbook》，目前他正在編寫(xiě)《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》。Gene是 IT運(yùn)維的超級(jí)粉絲，癡迷于改進(jìn)運(yùn)維流程——在不影響當(dāng)前IT生產(chǎn)環(huán)境的情況下，使得開(kāi)發(fā)人員可以向生產(chǎn)交付更多可運(yùn)行的功能，而非只是完成代碼。他與多個(gè)頂級(jí)互聯(lián)網(wǎng)公司合作過(guò)，致力于改進(jìn)他們的發(fā)布流程，提高IT運(yùn)維流程的完整性。2007年，Computer World將Gene列入了“40歲以下的40個(gè)創(chuàng)新IT人士”的名單中，普度大學(xué)還給他頒發(fā)了杰出校友獎(jiǎng)以表彰他在專業(yè)領(lǐng)域的成就和領(lǐng)導(dǎo)力。

目錄

1. 什么是DevOps
2. DevOps與敏捷有什么不同
3. DevOps與ITIL以及ITSM有什么不同
4. DevOps與可視運(yùn)維
5. DevOps的基本原則
6. DevOps模式的應(yīng)用領(lǐng)域
7. DevOps的價(jià)值
8. 信息安全和QA如何融入DevOps的工作流
9. 我最喜歡的DevOps模式一
10. 我最喜歡的DevOps模式二
11. 我最喜歡的DevOps模式三

1. 什么是DevOps

術(shù)語(yǔ)“DevOps”通常指的是新興的專業(yè)化運(yùn)動(dòng)，這種運(yùn)動(dòng)提倡開(kāi)發(fā)和IT運(yùn)維之間的高度協(xié)同，從而在完成高頻率部署的同時(shí)，提高生產(chǎn)環(huán)境的可靠性、穩(wěn)定性、彈性和安全性。

DevOps運(yùn)動(dòng)的起源通常被放在2009年前后，伴隨著許多運(yùn)動(dòng)的相輔相成和相互促進(jìn)——效率研討會(huì)運(yùn)動(dòng)，特別是由John Allspaw和Paul Hammond展示的開(kāi)創(chuàng)性的“一天10次部署”，基礎(chǔ)設(shè)施即代碼”運(yùn)動(dòng)(Mark Burgess 和Luke Kanies)，“敏捷基礎(chǔ)設(shè)施運(yùn)動(dòng)” (Andrew Shafer)，“敏捷系統(tǒng)管理”運(yùn)動(dòng)(Patrick DeBois)，“精益創(chuàng)業(yè)”運(yùn)動(dòng)（Eric Ries），Jez Humble的持續(xù)集成和發(fā)布運(yùn)動(dòng)，以及Amazon的“平臺(tái)即服務(wù)運(yùn)動(dòng)”等這些運(yùn)動(dòng)的相輔相成和相互促進(jìn)而發(fā)展起來(lái)的。

DevOps的合著者John Willis寫(xiě)了一個(gè)非常好的帖子在這里

http://itrevolution.com/the-convergence-of-devops/

2. DevOps與敏捷有哪些不同？

相對(duì)于瀑布開(kāi)發(fā)模式，敏捷開(kāi)發(fā)過(guò)程的一個(gè)基本原則就是以更快的頻率交付最小化可用的軟件。在敏捷的目標(biāo)里，最明顯的是在每個(gè)Sprint的迭代周期末尾，都具備可以交付的功能。

部署的高頻率經(jīng)常會(huì)導(dǎo)致部署堆積在IT運(yùn)維的面前。StreamStep公司的創(chuàng)始人，Clyde Logue總結(jié)過(guò)一句話：“敏捷對(duì)于開(kāi)發(fā)重新獲得商業(yè)的信任是大有益處的，但是它無(wú)意于將IT運(yùn)維拒之門(mén)外，DevOps使得IT組織作為一個(gè)整體重新獲得商業(yè)的信任”。

DevOps和敏捷軟件開(kāi)發(fā)是相輔相成的，因?yàn)樗卣购屯晟屏顺掷m(xù)集成和發(fā)布流程，因此可以確保代碼是生產(chǎn)上可用，并且確實(shí)能給客戶帶來(lái)價(jià)值。

DevOps不僅僅創(chuàng)建了一個(gè)面向IT運(yùn)維的工作流，當(dāng)代碼已經(jīng)開(kāi)發(fā)完成但是卻無(wú)法被部署到生產(chǎn)上時(shí)，這些部署就會(huì)堆積在IT運(yùn)維的面前，客戶也將因而無(wú)法享受到任何價(jià)值，更糟糕的是，部署經(jīng)常導(dǎo)致IT環(huán)境的中斷和服務(wù)不可用。

DevOps具有與生俱來(lái)的文化變革的基因組成，因?yàn)樗镄铝碎_(kāi)發(fā)和IT運(yùn)維之間的工作流和傳統(tǒng)的衡量標(biāo)準(zhǔn)。John Willis和Damon Edwards（兩位都是《DevOps Cookbook》合著者）就這個(gè)話題寫(xiě)過(guò)很多文章：

http://itrevolution.com/devops-culture-part-1/

3. DevOps與ITIL和ITSM有什么不同？

盡管很多人視DevOps為ITIL和ITSM的顛覆，而我則有著不同的看法，在支撐IT運(yùn)維的業(yè)務(wù)流程方面，ITIL和ITSM流程無(wú)疑還是最好的。實(shí)際上，他們描述了需要被IT運(yùn)維支持的功能集合，這些功能集合足以支撐DevOps式的工作流。

敏捷和持續(xù)集成以及持續(xù)發(fā)布是開(kāi)發(fā)的輸出，這些輸出同時(shí)作為IT運(yùn)維的輸入，為了適用跟DevOps相關(guān)的快速部署的節(jié)奏，ITIL流程的很多方面，特別是圍繞著變更、配置和發(fā)布流程方面，需要自動(dòng)化。

DevOps的目標(biāo)不僅只是增加變更的頻率，而且也支持在不中斷和破壞當(dāng)前服務(wù)的基礎(chǔ)上，確保功能部署成功，同時(shí)也可以快速檢測(cè)和修復(fù)缺陷。這引入了服務(wù)設(shè)計(jì)，事故和問(wèn)題管理方面的ITIL新準(zhǔn)則。

4. DevOps和可視運(yùn)維如何搭配

2004年，我與Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》，可視運(yùn)維是一個(gè)說(shuō)明性的指南，該指南使得高性能IT運(yùn)維能順利實(shí)現(xiàn)“從優(yōu)秀到卓越”的轉(zhuǎn)變，關(guān)鍵點(diǎn)之一是如何控制和減少計(jì)劃外的工作。

在開(kāi)發(fā)和IT運(yùn)維之間，DevOps不僅聚焦在創(chuàng)建快速和穩(wěn)定的計(jì)劃工作流，而且DevOps也有一個(gè)更全面的方法來(lái)系統(tǒng)的消除計(jì)劃外工作，定義開(kāi)發(fā)彈性準(zhǔn)則，并負(fù)責(zé)管理和減少技術(shù)債務(wù)。

5. DevOps的基本原則

在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的書(shū)里，我們描述了DevOps的支撐原則——“DevOps三個(gè)基本點(diǎn)”，所有的DevOps模式都可以源自這3個(gè)基本點(diǎn)。

第一個(gè)基本點(diǎn)強(qiáng)調(diào)整個(gè)系統(tǒng)的性能，而非將性能局限于特定的工作領(lǐng)域里，這個(gè)工作領(lǐng)域可以大到一個(gè)部門(mén)（例如開(kāi)發(fā)和IT運(yùn)維）或者小到一個(gè)個(gè)人貢獻(xiàn)者（例如開(kāi)發(fā)者，系統(tǒng)管理員等）。

重點(diǎn)是由IT推動(dòng)的的業(yè)務(wù)價(jià)值流，換句話說(shuō)，它始于需求定義（比如被業(yè)務(wù)或IT部門(mén)定義），進(jìn)行開(kāi)發(fā)構(gòu)建，又交給IT運(yùn)維，最后價(jià)值以一種服務(wù)的形式交付給客戶。

實(shí)踐第一個(gè)基本點(diǎn)的結(jié)果——決不傳遞一個(gè)已知缺陷至下游，決不因小失大，總是致力于改進(jìn)流程，執(zhí)著于深刻理解系統(tǒng)需求（根據(jù)戴明的理論）

第二個(gè)基本點(diǎn)是關(guān)于創(chuàng)建從右至左的反饋回路，幾乎所有的流程改進(jìn)計(jì)劃的目標(biāo)都是縮短和放大反饋回路，以便可以持續(xù)進(jìn)行必要的修正。

應(yīng)用第二個(gè)基本點(diǎn)的結(jié)果——包括理解和回應(yīng)所有內(nèi)部和外部客戶，縮短和放大所有的反饋回路，必要時(shí)，非常容易的嵌入客戶需要的知識(shí)。

第三個(gè)基本點(diǎn)是打造一種文化用來(lái)促進(jìn)兩件事情——持續(xù)不斷的探索精神，勇?lián)L(fēng)險(xiǎn)的精神以及從成功和失敗中來(lái)學(xué)習(xí)的能力，同時(shí)也得謹(jǐn)記：重復(fù)和實(shí)踐是融會(huì)貫通的前提。

這兩件事情對(duì)我們來(lái)說(shuō)同等重要，探索精神和勇?lián)L(fēng)險(xiǎn)的精神可以確保我們持續(xù)改進(jìn)，它甚至意味著我們可能到達(dá)了之前曾未到過(guò)的危險(xiǎn)區(qū)域，因此這也迫使我們?nèi)W(xué)習(xí)，掌握并融會(huì)貫通那些技能，因而使得我們能夠順利離開(kāi)危險(xiǎn)區(qū)。

第三個(gè)基本點(diǎn)的結(jié)果——分配時(shí)間去改進(jìn)每天的例行工作，培養(yǎng)一種獎(jiǎng)勵(lì)冒險(xiǎn)精神的風(fēng)氣，同時(shí)主動(dòng)引入故障到系統(tǒng)中，從而提高彈性。

6．DevOps模式的應(yīng)用領(lǐng)域

在《DevOps Cookbook》里，我們將DevOps模式分成4個(gè)領(lǐng)域，

領(lǐng)域一，將開(kāi)發(fā)延伸至生產(chǎn)中——包括拓展持續(xù)集成和發(fā)布功能至生產(chǎn)，集成QA和信息安全至整個(gè)工作流，確保代碼和環(huán)境可在生產(chǎn)中直接部署，。

領(lǐng)域二，向開(kāi)發(fā)中加入生產(chǎn)反饋——包括建立開(kāi)發(fā)和IT運(yùn)營(yíng)事件的完整時(shí)間表用于幫助事件的解決，使得開(kāi)發(fā)融入無(wú)指責(zé)的生產(chǎn)反思，盡可能使得開(kāi)發(fā)可以自助服務(wù)，同時(shí)創(chuàng)建信息指示器用來(lái)表明本地的決策如何影響全局的目標(biāo)。

領(lǐng)域三，開(kāi)發(fā)嵌入到IT運(yùn)維中——包括開(kāi)發(fā)投入到整個(gè)生產(chǎn)問(wèn)題處理鏈，分配開(kāi)發(fā)資源用于生產(chǎn)問(wèn)題管理，并協(xié)助退回技術(shù)債務(wù)，而且開(kāi)發(fā)為IT運(yùn)維提供交叉培訓(xùn)，增加IT運(yùn)維處理問(wèn)題的能力，從而降低升級(jí)問(wèn)題的數(shù)量。

領(lǐng)域四，將IT運(yùn)維嵌入至開(kāi)發(fā)——包括嵌入和聯(lián)絡(luò)IT運(yùn)維資源至開(kāi)發(fā)，幫助開(kāi)發(fā)創(chuàng)建為IT運(yùn)維(部署，生產(chǎn)代碼的管理等)使用的可重用的用戶故事，定義一些可以被所有項(xiàng)目共用的非功能性需求。

7. DevOps的價(jià)值

我相信企業(yè)在應(yīng)用了DevOps之后可以得到3個(gè)業(yè)務(wù)優(yōu)勢(shì)：產(chǎn)品快速推向市場(chǎng)（比如，縮短開(kāi)發(fā)周期時(shí)間和更高的部署頻率），提高質(zhì)量（比如，提高可用性，提高變更成功率，減少故障，等等）并提高組織的有效性（比如，將時(shí)間花在價(jià)值增加活動(dòng)中，減少浪費(fèi)，同時(shí)交付更多的價(jià)值至客戶手中）。

產(chǎn)品快速推向市場(chǎng)：

2007年，在IT流程協(xié)會(huì)，在評(píng)測(cè)了超過(guò)1500個(gè)IT組織結(jié)構(gòu)之后，我們得出結(jié)論：相比較于一般的組織，高效的IT組織的效率要高出5到7倍。變更要多出14倍，變更故障率只有前者的1/2，第一次修復(fù)率要高出4倍，而且一級(jí)事故時(shí)間要短10倍。 重復(fù)審計(jì)發(fā)現(xiàn)要少4倍，通過(guò)內(nèi)部控制來(lái)檢測(cè)漏洞方面要高出5倍左右，并且8倍于前者的項(xiàng)目到期日表現(xiàn)！

在我們的研究中，觀察到的最高部署頻率大約是每周1000次生產(chǎn)變更，變更成功率為99.5%，我們認(rèn)為這真得很快……

其中一個(gè)高績(jī)效的特點(diǎn)是，最好正在繼續(xù)變得更好。這絕對(duì)是發(fā)生在部署頻率的領(lǐng)域內(nèi)。 在應(yīng)用了DevOps實(shí)踐的組織正表現(xiàn)出更快的快速部署和實(shí)施，而且相比于一般組織要快幾個(gè)數(shù)量級(jí)。

埃森哲最近做了一個(gè)研究：互聯(lián)網(wǎng)公司都在做什么？ 通過(guò)亞馬遜的記錄顯示，他們?cè)诒３帜壳懊恐懿渴?000次的情況下，同時(shí)還能保證99.999%的成功率！

http://www.youtube.com/watch?v=dxk8b9rSKOo

http://www.slideshare.net/slideshow/embed_code/9466635?startSlide=33)

維持高部署率（即，快速的迭代次數(shù)）的能力轉(zhuǎn)化為業(yè)務(wù)價(jià)值的兩種主要方式：

組織如何快速的把一個(gè)想法變成價(jià)值交付到客戶手中(比如，Damon Edwards 和John Willis說(shuō)得“概念到落地”),組織同時(shí)可以做多個(gè)嘗試。

對(duì)我來(lái)說(shuō)，如果我在一個(gè)每9個(gè)月才能部署一次的機(jī)構(gòu)里，而我的競(jìng)爭(zhēng)對(duì)手可以每天部署10次，那么無(wú)疑我將有著明顯的競(jìng)爭(zhēng)劣勢(shì)。

高頻率部署也實(shí)現(xiàn)了快速和持續(xù)不斷的部署。Intuit公司的創(chuàng)始人，Scott Cook一直在組織的各個(gè)層面，不停的倡導(dǎo)“犀利創(chuàng)新文化”，我最喜歡的例子之一就記錄在http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/。

“每一位員工應(yīng)該能夠做到快速，高速的交付……Dan Maurer負(fù)責(zé)我們的消費(fèi)者部門(mén)，包括TurboTax網(wǎng)站。當(dāng)他接手的時(shí)候，我們一年只做幾次部署，但是通過(guò)營(yíng)造一個(gè)犀利的創(chuàng)新文化，在報(bào)稅季節(jié)的3個(gè)月里，他們現(xiàn)在能做165次部署。商業(yè)價(jià)值？ 網(wǎng)站轉(zhuǎn)化率高達(dá)50%。員工價(jià)值？這幫家伙們真得喜愛(ài)它，因?yàn)榭梢詫⑺麄兊南敕ê芸旖桓兜绞袌?chǎng)中”

對(duì)我來(lái)說(shuō)，Scott Cook的故事最令人震驚的是，他們?cè)诜泵Φ膱?bào)稅季節(jié)做所有這些部署！在旺季，大多數(shù)組織都會(huì)凍結(jié)任何變更（例如，從十月到一月，零售商可能經(jīng)常有變更凍結(jié)）。但如果在旺季，若你能提高轉(zhuǎn)換率，而你的競(jìng)爭(zhēng)對(duì)手不能，那么這就是一個(gè)真正的競(jìng)爭(zhēng)優(yōu)勢(shì)。

達(dá)到這個(gè)效果的前提就是，在不影響客戶的基礎(chǔ)上，可以快速的完成并部署很多小的變更。

減少IT浪費(fèi)總量：

Mike Orzen和我很早就談到了IT價(jià)值流中的巨大浪費(fèi)，這些浪費(fèi)是緣起于交付期限延長(zhǎng)，不良的交接，計(jì)劃外工作和返工?；贛ichael Krigsman的一篇文章，在應(yīng)用了DevOps的原則之后，可以挽回很多價(jià)值而非浪費(fèi)。

我們計(jì)算過(guò)，如果能夠減少一半的IT浪費(fèi)量，然后把這些省下來(lái)的錢(qián)重新投資，若能得到5倍的投資回報(bào)，那么每年可以產(chǎn)生30萬(wàn)億美元的價(jià)值。

這就是溜過(guò)我們指尖的巨大的價(jià)值和機(jī)會(huì)。占了全球GDP的4.7%，甚至超越整個(gè)德國(guó)的經(jīng)濟(jì)產(chǎn)出。

我覺(jué)得這真的很重要，尤其是當(dāng)我想到我的三個(gè)孩子將繼承的這個(gè)世界，這些浪費(fèi)對(duì)生產(chǎn)率，生活水平和經(jīng)濟(jì)繁榮的潛在影響正在不斷增加，讓我覺(jué)得不得不改變。

然而，還有一個(gè)更大的成本，在大部分的IT組織結(jié)構(gòu)里，工作是吃力不討好和令人沮喪的，人們覺(jué)得他們自己就像被困在一部不斷重復(fù)的恐怖電影里，無(wú)法改變最終的結(jié)局。管理人員本應(yīng)將IT管理的很好，但是他們放棄了這樣的職責(zé)，直接導(dǎo)致開(kāi)發(fā)，IT運(yùn)維與信息安全之間無(wú)休止的部門(mén)沖突，而審計(jì)師的出現(xiàn)只會(huì)讓事情變得更糟。

長(zhǎng)期來(lái)說(shuō)，必然的結(jié)果就是進(jìn)步遲緩。IT專業(yè)人士的生活往往令人泄氣和沮喪的，通常導(dǎo)致滲透在生活方方面面的無(wú)力感和高壓狀態(tài)。IT專業(yè)人員面臨著壓力相關(guān)的健康問(wèn)題、社交問(wèn)題、宅在家里等問(wèn)題，這樣使得他們不但不健康，同時(shí)生活也很可能難以為繼。

作為人，我們注定就是去貢獻(xiàn)，感覺(jué)就好像我們正在積極發(fā)揮作用，與眾不同。但是，往往當(dāng)IT專業(yè)人員向他們的組織尋求幫助的時(shí)候，他們會(huì)得到回答：“你不明白”，更糟的是，他們甚至?xí)玫健澳悴恢匾边@樣的待遇。

8. 信息安全和QA如何融入DevOps工作流

DevOps的高部署頻率通常會(huì)給QA和信息安全帶來(lái)很大的壓力，考慮這樣一種情形，開(kāi)發(fā)每天部署10次，而信息安全通常需要4個(gè)月的時(shí)間來(lái)評(píng)估應(yīng)用的安全。很顯然，在代碼開(kāi)發(fā)和代碼安全審計(jì)方面的速率一點(diǎn)都不匹配。

2011年Dropbox故障就是一個(gè)著名的例子，其體現(xiàn)了未經(jīng)充分測(cè)試的開(kāi)發(fā)代碼帶來(lái)的風(fēng)險(xiǎn)有多大。因?yàn)檫@次事故，認(rèn)證功能被關(guān)閉了4個(gè)小時(shí)，從而導(dǎo)致未授權(quán)的用戶可以訪問(wèn)所有存儲(chǔ)的數(shù)據(jù)。

當(dāng)然對(duì)QA和信息安全來(lái)說(shuō)，也不全是壞消息， 開(kāi)發(fā)會(huì)通過(guò)持續(xù)集成和好的發(fā)布慣例(持續(xù)測(cè)試的文化)來(lái)維持高頻率部署。換句話說(shuō)，一旦代碼被提交，自動(dòng)測(cè)試便開(kāi)始運(yùn)行，而且一旦發(fā)現(xiàn)問(wèn)題，必須馬上解決，就像開(kāi)發(fā)人員在檢查還沒(méi)編譯的代碼。

通過(guò)集成功能測(cè)試，集成測(cè)試和信息安全測(cè)試到開(kāi)發(fā)的每天例行工作中，問(wèn)題將會(huì)被更快發(fā)現(xiàn)，同時(shí)也會(huì)被更快解決。

同樣，也有著越來(lái)越多的信息安全工具，比如Gauntlet和Security Monkey， 可以幫助我們?cè)陂_(kāi)發(fā)和上線的過(guò)程中測(cè)試安全對(duì)象，達(dá)到信息安全目標(biāo)。

但是也有一個(gè)很重要的問(wèn)題需要考慮，靜態(tài)代碼分析工具通常需要花費(fèi)很長(zhǎng)時(shí)間才能運(yùn)行完，以數(shù)小時(shí)或天記。在這種情況下，信息安全就必須注明特定的有安全隱患的模塊，比如加密，認(rèn)證模塊。只要這些模塊變化，一輪全面的信息安全測(cè)試就運(yùn)行，否則部署就可以繼續(xù)，而不需要全覆蓋信息安全測(cè)試。

需要特別提到的一點(diǎn)是，我們觀察到，相較于標(biāo)準(zhǔn)的功能單元測(cè)試，DevOps工作流依賴于檢測(cè)和恢復(fù)更多一點(diǎn)。換句話說(shuō)，當(dāng)然開(kāi)發(fā)以軟件套件的方式交付的時(shí)候，那么部署變更和補(bǔ)丁就比較困難，同時(shí)QA也嚴(yán)重依賴代碼測(cè)試來(lái)驗(yàn)證功能的正確性。另一方面，當(dāng)軟件以服務(wù)的形式交付，缺陷就可以被很快修復(fù)。而且QA也可以減少測(cè)試依賴，取而代之的更多依賴缺陷的生產(chǎn)監(jiān)控，只要缺陷能被快速的修復(fù)。

代碼故障恢復(fù)可借助于“功能標(biāo)簽”等手段，通過(guò)以配置的形式來(lái)啟用或禁用某些代碼功能，從而達(dá)到避免推出一個(gè)全功能部署，而只部署通過(guò)測(cè)試的功能至生產(chǎn)。

當(dāng)功能不可用或性能出現(xiàn)下降等較壞的情況發(fā)生的時(shí)候，依賴于檢測(cè)和恢復(fù)進(jìn)行QA將會(huì)一種更好的選擇。但是當(dāng)面對(duì)損失保密性或數(shù)據(jù)和系統(tǒng)一致性的時(shí)候，我們就不可以依賴檢測(cè)和恢復(fù)這種方法。取而代之的是，在部署之前，必須進(jìn)行充分的測(cè)試，否則可能導(dǎo)致重大的安全事故。

9. 我最喜歡的DevOps模式一

通常，在軟件開(kāi)發(fā)項(xiàng)目中，開(kāi)發(fā)都會(huì)用完所有計(jì)劃中的時(shí)間用于開(kāi)發(fā)功能。這樣會(huì)導(dǎo)致無(wú)法充分解決IT運(yùn)維的問(wèn)題，于是他們就在定義，創(chuàng)建和測(cè)試數(shù)據(jù)庫(kù)、操作系統(tǒng)、網(wǎng)絡(luò)、虛擬化等代碼依賴的方面直接抄捷徑，以此節(jié)省時(shí)間。

所以這就是開(kāi)發(fā)和IT運(yùn)維以及次優(yōu)結(jié)果之間的永恒的緊張關(guān)系的主要原因。后果很嚴(yán)重，比如不適當(dāng)?shù)亩x和指定環(huán)境、無(wú)法重部署、代碼和環(huán)境的不兼容等等。

在這種模式下，我們會(huì)再開(kāi)發(fā)過(guò)程的早期提出環(huán)境要求，并強(qiáng)制代碼和環(huán)境必須被一起測(cè)試的策略，一旦使用敏捷開(kāi)發(fā)方法，我們可以做到非常簡(jiǎn)潔和優(yōu)雅。

按敏捷的要求，在每個(gè)迭代結(jié)束后，我們就會(huì)發(fā)布能運(yùn)行且可被部署的代碼，通常時(shí)間為兩周。我們將修改敏捷迭代周期策略，不僅僅只交付能運(yùn)行且可被部署的代碼，同時(shí)在每個(gè)迭代周期的早期，還必須準(zhǔn)備好環(huán)境用于部署這些代碼。

由此，我們不再讓IT運(yùn)維負(fù)責(zé)創(chuàng)建生產(chǎn)環(huán)境的規(guī)格要求，取而代之的，建立一個(gè)自動(dòng)化的環(huán)境創(chuàng)建流程，這種機(jī)制不僅僅只創(chuàng)建生產(chǎn)環(huán)境，同時(shí)也包括開(kāi)發(fā)和QA環(huán)境。

通過(guò)使得環(huán)境早期即可用，甚至可能早于軟件項(xiàng)目開(kāi)始之前，開(kāi)發(fā)和QA可以在統(tǒng)一和穩(wěn)定的環(huán)境中運(yùn)行和測(cè)試他們的代碼，從而控制不同環(huán)境之間的差異。

此外，通過(guò)保持不同階段（例如，開(kāi)發(fā)、QA、集成測(cè)試、生產(chǎn)）盡可能小的差異，在生產(chǎn)部署之前，我們就能發(fā)現(xiàn)并修復(fù)代碼和環(huán)境之間的互操作性問(wèn)題。

理想情況下，我們建立的部署機(jī)制是完全自動(dòng)化的?？梢允褂孟馭hell腳本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等很多工具來(lái)完成。

10. 我最喜歡的DevOps模式二：

BrowserMob前CEO，Patrick Lightbody曾經(jīng)說(shuō)過(guò)，“當(dāng)我們?cè)诹璩?點(diǎn)叫醒開(kāi)發(fā)工程師來(lái)解決問(wèn)題時(shí)，缺陷被修復(fù)的比以前更快了，這真是一個(gè)驚人的反饋回路”，

這是我最喜歡的引用之一。

它強(qiáng)調(diào)了問(wèn)題的關(guān)鍵點(diǎn)，開(kāi)發(fā)一般會(huì)在周五的5點(diǎn)提交代碼，然后高高興興的回家，而IT運(yùn)維則要花費(fèi)一整個(gè)周末來(lái)收拾殘局。更糟的是，缺陷和已知錯(cuò)誤在生產(chǎn)上不斷遞歸，迫使IT運(yùn)維不停的救火，而根本原因從不被修復(fù)，造成這種現(xiàn)象的原因就是開(kāi)發(fā)總是關(guān)注開(kāi)發(fā)新功能。

第二種模式的一個(gè)重要要素就是縮短和放大反饋回路，使得開(kāi)發(fā)更貼近客戶體驗(yàn)(包括IT運(yùn)維和最終用戶)

注意這里的對(duì)稱性，模式一討論的盡早讓環(huán)境統(tǒng)一并可用即是將IT運(yùn)維嵌入到開(kāi)中發(fā)，而模式二則為將開(kāi)發(fā)嵌入到IT運(yùn)維中。

我們將開(kāi)發(fā)嵌入進(jìn)IT運(yùn)維的問(wèn)題升級(jí)鏈中，可以將他們放在三級(jí)支持中，甚至使開(kāi)發(fā)對(duì)整個(gè)代碼的部署成功負(fù)責(zé)。要么回滾，要么修復(fù)缺陷，直到服務(wù)恢復(fù)。

我們的目標(biāo)不是讓開(kāi)發(fā)取代IT運(yùn)維，相反，就是想確開(kāi)發(fā)看到他們工作和變更的下游變化，激勵(lì)他們以IT運(yùn)維的視角來(lái)更快的解決問(wèn)題，從而達(dá)到一個(gè)全局的目標(biāo)。

11. 我最喜歡的DevOps模式三：

在開(kāi)發(fā)和IT運(yùn)維之間DevOps價(jià)值流中，另一個(gè)經(jīng)常發(fā)生的問(wèn)題就是不夠規(guī)范。這方面的例子是，每個(gè)部署都帶有其特殊性，因此也使得每次部署后的環(huán)境帶有特殊性，一旦這樣的事情發(fā)生，那么這個(gè)組織里就沒(méi)有針對(duì)流程配置的控制。

在這種模式下，我們定義可重用且可跨多個(gè)項(xiàng)目的部署流程，敏捷方法里有個(gè)很簡(jiǎn)單的解決方案。就是將部署的活動(dòng)變成一個(gè)用戶故事。例如，我們?yōu)镮T運(yùn)維構(gòu)建一個(gè)可重用的用戶故事，叫做“部署到高可用環(huán)境”，這個(gè)用戶故事定義了明確的構(gòu)建環(huán)境的步驟、需要多長(zhǎng)時(shí)間、需要哪些資源等等。

那么這些信息可以被項(xiàng)目經(jīng)理用來(lái)集成部署內(nèi)容到項(xiàng)目計(jì)劃中去。例如，如果我們知道在過(guò)去的3年時(shí)間里，“部署到高可用環(huán)境”用戶故事被部署了15次，每次的平均部署時(shí)間為3天，加或減一天，那么我們對(duì)自己的部署計(jì)劃將會(huì)非常有信心。

此外，我們還可以因部署活動(dòng)被合適的集成到軟件項(xiàng)目中而獲得信心。

我們也得認(rèn)識(shí)到有些特定的軟件項(xiàng)目要求特別的環(huán)境，且其不被IT運(yùn)維官方支持，我們可以允許這些被生產(chǎn)允許的環(huán)境中的例外，但是被IT運(yùn)維部門(mén)外面的人提供支持的。

通過(guò)這種方法，我們即獲得了環(huán)境標(biāo)準(zhǔn)化的好處（比如，減少生產(chǎn)差異，環(huán)境更一致，IT運(yùn)維的支持和維護(hù)能力增加），又能再允許的特殊情況下，提供業(yè)務(wù)需要的靈活性。

---

感謝丁雪豐對(duì)本文的審校。

---

深圳塔塔咨詢服務(wù)有限公司是邁瑞思旗下全資子公司，公司簡(jiǎn)稱塔塔IT，是國(guó)內(nèi)知名的高端IT培訓(xùn)品牌，立足深圳，培訓(xùn)業(yè)務(wù)范圍覆蓋全國(guó)及港澳臺(tái)地區(qū)。公司專注于IT前沿技術(shù)的傳播與應(yīng)用，是一家以IT高端培訓(xùn)、咨詢服務(wù)、技術(shù)支持以及國(guó)際IT認(rèn)證考試為核心業(yè)務(wù)的專業(yè)服務(wù)商。公司與微軟、Redhat、Cisco、Oracle、IBM、Vmware、Citrix、EMC、HP、SAP、華為等全球著名IT廠商及EXIN、ISACA、EPI、PMI、Peoplecert、APMG等國(guó)際知名機(jī)構(gòu)建立長(zhǎng)期合作伙伴關(guān)系，憑借在高端技術(shù)培訓(xùn)領(lǐng)域多年的教學(xué)經(jīng)驗(yàn)和項(xiàng)目經(jīng)驗(yàn)，積累了大量?jī)?yōu)質(zhì)的客戶群體，服務(wù)客戶涉及通信、金融、交通、能源、制造、政府部門(mén)等多個(gè)行業(yè)領(lǐng)域，覆蓋面極廣，累計(jì)培訓(xùn)人數(shù)數(shù)萬(wàn)人，深得用戶信賴和好評(píng)。

課程咨詢熱線：0755-29152000
培訓(xùn)咨詢郵箱：tata@tatait.com

部分榮譽(yù)資質(zhì)：

思科Cisco授權(quán)培訓(xùn)合作伙伴
紅帽培訓(xùn)交付合作伙伴
紅帽官方授權(quán)培訓(xùn)考試中心
RedHat(紅帽學(xué)院)合作伙伴
Oracle WDP 授權(quán)合作伙伴
Oracle官方授權(quán)培訓(xùn)考試中心
IBM培訓(xùn)合作伙伴
H3C大學(xué)培訓(xùn)合作伙伴
阿里云培訓(xùn)合作伙伴
微軟解決方案合作伙伴
ISACA國(guó)際信息審計(jì)協(xié)會(huì)授權(quán)合作伙伴
項(xiàng)目管理協(xié)會(huì)（PMI）注冊(cè)教育培訓(xùn)服務(wù)商（R.E.P.ID: 4412）
PMI官方授權(quán)PMP培訓(xùn)合作伙伴
EXIN EPI數(shù)據(jù)中心認(rèn)證體系授權(quán)培訓(xùn)合作伙伴
PeopleCert授權(quán)ITIL培訓(xùn)考試中心
PeopleCert授權(quán)Prince2考試中心
......