關(guān)于DevOps你必須知道的11件事
來源:塔塔 更新時間:2016-11-17
編輯注:本文來自技術(shù)出版商IT Revolution,最初以白皮書的形式發(fā)布為The Top 11 Things You Need to Know about DevOps。經(jīng)本文作者Gene Kim和本文譯者戚一品的授權(quán)與推薦,現(xiàn)將完整譯文分享給InfoQ中文章的讀者們參閱。
關(guān)于作者
Gene Kim在多個角色上屢獲殊榮:CTO、研究者和作家。他曾是Tripwire的創(chuàng)始人并擔(dān)任了13年的CTO。他寫過兩本書,其中包括《The Visible Ops Handbook》,目前他正在編寫《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》。Gene是 IT運(yùn)維的超級粉絲,癡迷于改進(jìn)運(yùn)維流程——在不影響當(dāng)前IT生產(chǎn)環(huán)境的情況下,使得開發(fā)人員可以向生產(chǎn)交付更多可運(yùn)行的功能,而非只是完成代碼。他與多個頂級互聯(lián)網(wǎng)公司合作過,致力于改進(jìn)他們的發(fā)布流程,提高IT運(yùn)維流程的完整性。2007年,Computer World將Gene列入了“40歲以下的40個創(chuàng)新IT人士”的名單中,普度大學(xué)還給他頒發(fā)了杰出校友獎以表彰他在專業(yè)領(lǐng)域的成就和領(lǐng)導(dǎo)力。
目錄
-
什么是DevOps
-
DevOps與敏捷有什么不同
-
DevOps與ITIL以及ITSM有什么不同
-
DevOps與可視運(yùn)維
-
DevOps的基本原則
-
DevOps模式的應(yīng)用領(lǐng)域
-
DevOps的價值
-
信息安全和QA如何融入DevOps的工作流
-
我最喜歡的DevOps模式一
-
我最喜歡的DevOps模式二
-
我最喜歡的DevOps模式三
1. 什么是DevOps
術(shù)語“DevOps”通常指的是新興的專業(yè)化運(yùn)動,這種運(yùn)動提倡開發(fā)和IT運(yùn)維之間的高度協(xié)同,從而在完成高頻率部署的同時,提高生產(chǎn)環(huán)境的可靠性、穩(wěn)定性、彈性和安全性。
DevOps運(yùn)動的起源通常被放在2009年前后,伴隨著許多運(yùn)動的相輔相成和相互促進(jìn)——效率研討會運(yùn)動,特別是由John Allspaw和Paul Hammond展示的開創(chuàng)性的“一天10次部署”,基礎(chǔ)設(shè)施即代碼”運(yùn)動(Mark Burgess 和Luke Kanies),“敏捷基礎(chǔ)設(shè)施運(yùn)動” (Andrew Shafer),“敏捷系統(tǒng)管理”運(yùn)動(Patrick DeBois),“精益創(chuàng)業(yè)”運(yùn)動(Eric Ries),Jez Humble的持續(xù)集成和發(fā)布運(yùn)動,以及Amazon的“平臺即服務(wù)運(yùn)動”等這些運(yùn)動的相輔相成和相互促進(jìn)而發(fā)展起來的。
DevOps的合著者John Willis寫了一個非常好的帖子在這里
http://itrevolution.com/the-convergence-of-devops/
2. DevOps與敏捷有哪些不同?
相對于瀑布開發(fā)模式,敏捷開發(fā)過程的一個基本原則就是以更快的頻率交付最小化可用的軟件。在敏捷的目標(biāo)里,最明顯的是在每個Sprint的迭代周期末尾,都具備可以交付的功能。
部署的高頻率經(jīng)常會導(dǎo)致部署堆積在IT運(yùn)維的面前。StreamStep公司的創(chuàng)始人,Clyde Logue總結(jié)過一句話:“敏捷對于開發(fā)重新獲得商業(yè)的信任是大有益處的,但是它無意于將IT運(yùn)維拒之門外,DevOps使得IT組織作為一個整體重新獲得商業(yè)的信任”。
DevOps和敏捷軟件開發(fā)是相輔相成的,因?yàn)樗卣购屯晟屏顺掷m(xù)集成和發(fā)布流程,因此可以確保代碼是生產(chǎn)上可用,并且確實(shí)能給客戶帶來價值。
DevOps不僅僅創(chuàng)建了一個面向IT運(yùn)維的工作流,當(dāng)代碼已經(jīng)開發(fā)完成但是卻無法被部署到生產(chǎn)上時,這些部署就會堆積在IT運(yùn)維的面前,客戶也將因而無法享受到任何價值,更糟糕的是,部署經(jīng)常導(dǎo)致IT環(huán)境的中斷和服務(wù)不可用。
DevOps具有與生俱來的文化變革的基因組成,因?yàn)樗镄铝碎_發(fā)和IT運(yùn)維之間的工作流和傳統(tǒng)的衡量標(biāo)準(zhǔn)。John Willis和Damon Edwards(兩位都是《DevOps Cookbook》合著者)就這個話題寫過很多文章:
http://itrevolution.com/devops-culture-part-1/
3. DevOps與ITIL和ITSM有什么不同?
盡管很多人視DevOps為ITIL和ITSM的顛覆,而我則有著不同的看法,在支撐IT運(yùn)維的業(yè)務(wù)流程方面,ITIL和ITSM流程無疑還是最好的。實(shí)際上,他們描述了需要被IT運(yùn)維支持的功能集合,這些功能集合足以支撐DevOps式的工作流。
敏捷和持續(xù)集成以及持續(xù)發(fā)布是開發(fā)的輸出,這些輸出同時作為IT運(yùn)維的輸入,為了適用跟DevOps相關(guān)的快速部署的節(jié)奏,ITIL流程的很多方面,特別是圍繞著變更、配置和發(fā)布流程方面,需要自動化。
DevOps的目標(biāo)不僅只是增加變更的頻率,而且也支持在不中斷和破壞當(dāng)前服務(wù)的基礎(chǔ)上,確保功能部署成功,同時也可以快速檢測和修復(fù)缺陷。這引入了服務(wù)設(shè)計(jì),事故和問題管理方面的ITIL新準(zhǔn)則。
4. DevOps和可視運(yùn)維如何搭配
2004年,我與Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》,可視運(yùn)維是一個說明性的指南,該指南使得高性能IT運(yùn)維能順利實(shí)現(xiàn)“從優(yōu)秀到卓越”的轉(zhuǎn)變,關(guān)鍵點(diǎn)之一是如何控制和減少計(jì)劃外的工作。
在開發(fā)和IT運(yùn)維之間,DevOps不僅聚焦在創(chuàng)建快速和穩(wěn)定的計(jì)劃工作流,而且DevOps也有一個更全面的方法來系統(tǒng)的消除計(jì)劃外工作,定義開發(fā)彈性準(zhǔn)則,并負(fù)責(zé)管理和減少技術(shù)債務(wù)。
5. DevOps的基本原則
在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的書里,我們描述了DevOps的支撐原則——“DevOps三個基本點(diǎn)”,所有的DevOps模式都可以源自這3個基本點(diǎn)。
第一個基本點(diǎn)強(qiáng)調(diào)整個系統(tǒng)的性能,而非將性能局限于特定的工作領(lǐng)域里,這個工作領(lǐng)域可以大到一個部門(例如開發(fā)和IT運(yùn)維)或者小到一個個人貢獻(xiàn)者(例如開發(fā)者,系統(tǒng)管理員等)。
重點(diǎn)是由IT推動的的業(yè)務(wù)價值流,換句話說,它始于需求定義(比如被業(yè)務(wù)或IT部門定義),進(jìn)行開發(fā)構(gòu)建,又交給IT運(yùn)維,最后價值以一種服務(wù)的形式交付給客戶。
實(shí)踐第一個基本點(diǎn)的結(jié)果——決不傳遞一個已知缺陷至下游,決不因小失大,總是致力于改進(jìn)流程,執(zhí)著于深刻理解系統(tǒng)需求(根據(jù)戴明的理論)
第二個基本點(diǎn)是關(guān)于創(chuàng)建從右至左的反饋回路,幾乎所有的流程改進(jìn)計(jì)劃的目標(biāo)都是縮短和放大反饋回路,以便可以持續(xù)進(jìn)行必要的修正。
應(yīng)用第二個基本點(diǎn)的結(jié)果——包括理解和回應(yīng)所有內(nèi)部和外部客戶,縮短和放大所有的反饋回路,必要時,非常容易的嵌入客戶需要的知識。
第三個基本點(diǎn)是打造一種文化用來促進(jìn)兩件事情——持續(xù)不斷的探索精神,勇?lián)L(fēng)險的精神以及從成功和失敗中來學(xué)習(xí)的能力,同時也得謹(jǐn)記:重復(fù)和實(shí)踐是融會貫通的前提。
這兩件事情對我們來說同等重要,探索精神和勇?lián)L(fēng)險的精神可以確保我們持續(xù)改進(jìn),它甚至意味著我們可能到達(dá)了之前曾未到過的危險區(qū)域,因此這也迫使我們?nèi)W(xué)習(xí),掌握并融會貫通那些技能,因而使得我們能夠順利離開危險區(qū)。
第三個基本點(diǎn)的結(jié)果——分配時間去改進(jìn)每天的例行工作,培養(yǎng)一種獎勵冒險精神的風(fēng)氣,同時主動引入故障到系統(tǒng)中,從而提高彈性。
6.DevOps模式的應(yīng)用領(lǐng)域
在《DevOps Cookbook》里,我們將DevOps模式分成4個領(lǐng)域,
領(lǐng)域一,將開發(fā)延伸至生產(chǎn)中——包括拓展持續(xù)集成和發(fā)布功能至生產(chǎn),集成QA和信息安全至整個工作流,確保代碼和環(huán)境可在生產(chǎn)中直接部署,。
領(lǐng)域二,向開發(fā)中加入生產(chǎn)反饋——包括建立開發(fā)和IT運(yùn)營事件的完整時間表用于幫助事件的解決,使得開發(fā)融入無指責(zé)的生產(chǎn)反思,盡可能使得開發(fā)可以自助服務(wù),同時創(chuàng)建信息指示器用來表明本地的決策如何影響全局的目標(biāo)。
領(lǐng)域三,開發(fā)嵌入到IT運(yùn)維中——包括開發(fā)投入到整個生產(chǎn)問題處理鏈,分配開發(fā)資源用于生產(chǎn)問題管理,并協(xié)助退回技術(shù)債務(wù),而且開發(fā)為IT運(yùn)維提供交叉培訓(xùn),增加IT運(yùn)維處理問題的能力,從而降低升級問題的數(shù)量。
領(lǐng)域四,將IT運(yùn)維嵌入至開發(fā)——包括嵌入和聯(lián)絡(luò)IT運(yùn)維資源至開發(fā),幫助開發(fā)創(chuàng)建為IT運(yùn)維(部署,生產(chǎn)代碼的管理等)使用的可重用的用戶故事,定義一些可以被所有項(xiàng)目共用的非功能性需求。
7. DevOps的價值
我相信企業(yè)在應(yīng)用了DevOps之后可以得到3個業(yè)務(wù)優(yōu)勢:產(chǎn)品快速推向市場(比如,縮短開發(fā)周期時間和更高的部署頻率),提高質(zhì)量(比如,提高可用性,提高變更成功率,減少故障,等等)并提高組織的有效性(比如,將時間花在價值增加活動中,減少浪費(fèi),同時交付更多的價值至客戶手中)。
產(chǎn)品快速推向市場:
2007年,在IT流程協(xié)會,在評測了超過1500個IT組織結(jié)構(gòu)之后,我們得出結(jié)論:相比較于一般的組織,高效的IT組織的效率要高出5到7倍。變更要多出14倍,變更故障率只有前者的1/2,第一次修復(fù)率要高出4倍,而且一級事故時間要短10倍。 重復(fù)審計(jì)發(fā)現(xiàn)要少4倍,通過內(nèi)部控制來檢測漏洞方面要高出5倍左右,并且8倍于前者的項(xiàng)目到期日表現(xiàn)!
在我們的研究中,觀察到的最高部署頻率大約是每周1000次生產(chǎn)變更,變更成功率為99.5%,我們認(rèn)為這真得很快……
其中一個高績效的特點(diǎn)是,最好正在繼續(xù)變得更好。這絕對是發(fā)生在部署頻率的領(lǐng)域內(nèi)。 在應(yīng)用了DevOps實(shí)踐的組織正表現(xiàn)出更快的快速部署和實(shí)施,而且相比于一般組織要快幾個數(shù)量級。
埃森哲最近做了一個研究:互聯(lián)網(wǎng)公司都在做什么? 通過亞馬遜的記錄顯示,他們在保持目前每周部署1000次的情況下,同時還能保證99.999%的成功率!
http://www.youtube.com/watch?v=dxk8b9rSKOo
http://www.slideshare.net/slideshow/embed_code/9466635?startSlide=33)
維持高部署率(即,快速的迭代次數(shù))的能力轉(zhuǎn)化為業(yè)務(wù)價值的兩種主要方式:
組織如何快速的把一個想法變成價值交付到客戶手中(比如,Damon Edwards 和John Willis說得“概念到落地”),組織同時可以做多個嘗試。
對我來說,如果我在一個每9個月才能部署一次的機(jī)構(gòu)里,而我的競爭對手可以每天部署10次,那么無疑我將有著明顯的競爭劣勢。
高頻率部署也實(shí)現(xiàn)了快速和持續(xù)不斷的部署。Intuit公司的創(chuàng)始人,Scott Cook一直在組織的各個層面,不停的倡導(dǎo)“犀利創(chuàng)新文化”,我最喜歡的例子之一就記錄在http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/。
“每一位員工應(yīng)該能夠做到快速,高速的交付……Dan Maurer負(fù)責(zé)我們的消費(fèi)者部門,包括TurboTax網(wǎng)站。當(dāng)他接手的時候,我們一年只做幾次部署,但是通過營造一個犀利的創(chuàng)新文化,在報(bào)稅季節(jié)的3個月里,他們現(xiàn)在能做165次部署。商業(yè)價值? 網(wǎng)站轉(zhuǎn)化率高達(dá)50%。員工價值?這幫家伙們真得喜愛它,因?yàn)榭梢詫⑺麄兊南敕ê芸旖桓兜绞袌鲋小?
對我來說,Scott Cook的故事最令人震驚的是,他們在繁忙的報(bào)稅季節(jié)做所有這些部署!在旺季,大多數(shù)組織都會凍結(jié)任何變更(例如,從十月到一月,零售商可能經(jīng)常有變更凍結(jié))。但如果在旺季,若你能提高轉(zhuǎn)換率,而你的競爭對手不能,那么這就是一個真正的競爭優(yōu)勢。
達(dá)到這個效果的前提就是,在不影響客戶的基礎(chǔ)上,可以快速的完成并部署很多小的變更。
減少IT浪費(fèi)總量:
Mike Orzen和我很早就談到了IT價值流中的巨大浪費(fèi),這些浪費(fèi)是緣起于交付期限延長,不良的交接,計(jì)劃外工作和返工?;贛ichael Krigsman的一篇文章,在應(yīng)用了DevOps的原則之后,可以挽回很多價值而非浪費(fèi)。
我們計(jì)算過,如果能夠減少一半的IT浪費(fèi)量,然后把這些省下來的錢重新投資,若能得到5倍的投資回報(bào),那么每年可以產(chǎn)生30萬億美元的價值。
這就是溜過我們指尖的巨大的價值和機(jī)會。占了全球GDP的4.7%,甚至超越整個德國的經(jīng)濟(jì)產(chǎn)出。
我覺得這真的很重要,尤其是當(dāng)我想到我的三個孩子將繼承的這個世界,這些浪費(fèi)對生產(chǎn)率,生活水平和經(jīng)濟(jì)繁榮的潛在影響正在不斷增加,讓我覺得不得不改變。
然而,還有一個更大的成本,在大部分的IT組織結(jié)構(gòu)里,工作是吃力不討好和令人沮喪的,人們覺得他們自己就像被困在一部不斷重復(fù)的恐怖電影里,無法改變最終的結(jié)局。管理人員本應(yīng)將IT管理的很好,但是他們放棄了這樣的職責(zé),直接導(dǎo)致開發(fā),IT運(yùn)維與信息安全之間無休止的部門沖突,而審計(jì)師的出現(xiàn)只會讓事情變得更糟。
長期來說,必然的結(jié)果就是進(jìn)步遲緩。IT專業(yè)人士的生活往往令人泄氣和沮喪的,通常導(dǎo)致滲透在生活方方面面的無力感和高壓狀態(tài)。IT專業(yè)人員面臨著壓力相關(guān)的健康問題、社交問題、宅在家里等問題,這樣使得他們不但不健康,同時生活也很可能難以為繼。
作為人,我們注定就是去貢獻(xiàn),感覺就好像我們正在積極發(fā)揮作用,與眾不同。但是,往往當(dāng)IT專業(yè)人員向他們的組織尋求幫助的時候,他們會得到回答:“你不明白”,更糟的是,他們甚至?xí)玫健澳悴恢匾边@樣的待遇。
8. 信息安全和QA如何融入DevOps工作流
DevOps的高部署頻率通常會給QA和信息安全帶來很大的壓力,考慮這樣一種情形,開發(fā)每天部署10次,而信息安全通常需要4個月的時間來評估應(yīng)用的安全。很顯然,在代碼開發(fā)和代碼安全審計(jì)方面的速率一點(diǎn)都不匹配。
2011年Dropbox故障就是一個著名的例子,其體現(xiàn)了未經(jīng)充分測試的開發(fā)代碼帶來的風(fēng)險有多大。因?yàn)檫@次事故,認(rèn)證功能被關(guān)閉了4個小時,從而導(dǎo)致未授權(quán)的用戶可以訪問所有存儲的數(shù)據(jù)。
當(dāng)然對QA和信息安全來說,也不全是壞消息, 開發(fā)會通過持續(xù)集成和好的發(fā)布慣例(持續(xù)測試的文化)來維持高頻率部署。換句話說,一旦代碼被提交,自動測試便開始運(yùn)行,而且一旦發(fā)現(xiàn)問題,必須馬上解決,就像開發(fā)人員在檢查還沒編譯的代碼。
通過集成功能測試,集成測試和信息安全測試到開發(fā)的每天例行工作中,問題將會被更快發(fā)現(xiàn),同時也會被更快解決。
同樣,也有著越來越多的信息安全工具,比如Gauntlet和Security Monkey, 可以幫助我們在開發(fā)和上線的過程中測試安全對象,達(dá)到信息安全目標(biāo)。
但是也有一個很重要的問題需要考慮,靜態(tài)代碼分析工具通常需要花費(fèi)很長時間才能運(yùn)行完,以數(shù)小時或天記。在這種情況下,信息安全就必須注明特定的有安全隱患的模塊,比如加密,認(rèn)證模塊。只要這些模塊變化,一輪全面的信息安全測試就運(yùn)行,否則部署就可以繼續(xù),而不需要全覆蓋信息安全測試。
需要特別提到的一點(diǎn)是,我們觀察到,相較于標(biāo)準(zhǔn)的功能單元測試,DevOps工作流依賴于檢測和恢復(fù)更多一點(diǎn)。換句話說,當(dāng)然開發(fā)以軟件套件的方式交付的時候,那么部署變更和補(bǔ)丁就比較困難,同時QA也嚴(yán)重依賴代碼測試來驗(yàn)證功能的正確性。另一方面,當(dāng)軟件以服務(wù)的形式交付,缺陷就可以被很快修復(fù)。而且QA也可以減少測試依賴,取而代之的更多依賴缺陷的生產(chǎn)監(jiān)控,只要缺陷能被快速的修復(fù)。
代碼故障恢復(fù)可借助于“功能標(biāo)簽”等手段,通過以配置的形式來啟用或禁用某些代碼功能,從而達(dá)到避免推出一個全功能部署,而只部署通過測試的功能至生產(chǎn)。
當(dāng)功能不可用或性能出現(xiàn)下降等較壞的情況發(fā)生的時候,依賴于檢測和恢復(fù)進(jìn)行QA將會一種更好的選擇。但是當(dāng)面對損失保密性或數(shù)據(jù)和系統(tǒng)一致性的時候,我們就不可以依賴檢測和恢復(fù)這種方法。取而代之的是,在部署之前,必須進(jìn)行充分的測試,否則可能導(dǎo)致重大的安全事故。
9. 我最喜歡的DevOps模式一
通常,在軟件開發(fā)項(xiàng)目中,開發(fā)都會用完所有計(jì)劃中的時間用于開發(fā)功能。這樣會導(dǎo)致無法充分解決IT運(yùn)維的問題,于是他們就在定義,創(chuàng)建和測試數(shù)據(jù)庫、操作系統(tǒng)、網(wǎng)絡(luò)、虛擬化等代碼依賴的方面直接抄捷徑,以此節(jié)省時間。
所以這就是開發(fā)和IT運(yùn)維以及次優(yōu)結(jié)果之間的永恒的緊張關(guān)系的主要原因。后果很嚴(yán)重,比如不適當(dāng)?shù)亩x和指定環(huán)境、無法重部署、代碼和環(huán)境的不兼容等等。
在這種模式下,我們會再開發(fā)過程的早期提出環(huán)境要求,并強(qiáng)制代碼和環(huán)境必須被一起測試的策略,一旦使用敏捷開發(fā)方法,我們可以做到非常簡潔和優(yōu)雅。
按敏捷的要求,在每個迭代結(jié)束后,我們就會發(fā)布能運(yùn)行且可被部署的代碼,通常時間為兩周。我們將修改敏捷迭代周期策略,不僅僅只交付能運(yùn)行且可被部署的代碼,同時在每個迭代周期的早期,還必須準(zhǔn)備好環(huán)境用于部署這些代碼。
由此,我們不再讓IT運(yùn)維負(fù)責(zé)創(chuàng)建生產(chǎn)環(huán)境的規(guī)格要求,取而代之的,建立一個自動化的環(huán)境創(chuàng)建流程,這種機(jī)制不僅僅只創(chuàng)建生產(chǎn)環(huán)境,同時也包括開發(fā)和QA環(huán)境。
通過使得環(huán)境早期即可用,甚至可能早于軟件項(xiàng)目開始之前,開發(fā)和QA可以在統(tǒng)一和穩(wěn)定的環(huán)境中運(yùn)行和測試他們的代碼,從而控制不同環(huán)境之間的差異。
此外,通過保持不同階段(例如,開發(fā)、QA、集成測試、生產(chǎn))盡可能小的差異,在生產(chǎn)部署之前,我們就能發(fā)現(xiàn)并修復(fù)代碼和環(huán)境之間的互操作性問題。
理想情況下,我們建立的部署機(jī)制是完全自動化的??梢允褂孟馭hell腳本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等很多工具來完成。
10. 我最喜歡的DevOps模式二:
BrowserMob前CEO,Patrick Lightbody曾經(jīng)說過,“當(dāng)我們在凌晨2點(diǎn)叫醒開發(fā)工程師來解決問題時,缺陷被修復(fù)的比以前更快了,這真是一個驚人的反饋回路”,
這是我最喜歡的引用之一。
它強(qiáng)調(diào)了問題的關(guān)鍵點(diǎn),開發(fā)一般會在周五的5點(diǎn)提交代碼,然后高高興興的回家,而IT運(yùn)維則要花費(fèi)一整個周末來收拾殘局。更糟的是,缺陷和已知錯誤在生產(chǎn)上不斷遞歸,迫使IT運(yùn)維不停的救火,而根本原因從不被修復(fù),造成這種現(xiàn)象的原因就是開發(fā)總是關(guān)注開發(fā)新功能。
第二種模式的一個重要要素就是縮短和放大反饋回路,使得開發(fā)更貼近客戶體驗(yàn)(包括IT運(yùn)維和最終用戶)
注意這里的對稱性,模式一討論的盡早讓環(huán)境統(tǒng)一并可用即是將IT運(yùn)維嵌入到開中發(fā),而模式二則為將開發(fā)嵌入到IT運(yùn)維中。
我們將開發(fā)嵌入進(jìn)IT運(yùn)維的問題升級鏈中,可以將他們放在三級支持中,甚至使開發(fā)對整個代碼的部署成功負(fù)責(zé)。要么回滾,要么修復(fù)缺陷,直到服務(wù)恢復(fù)。
我們的目標(biāo)不是讓開發(fā)取代IT運(yùn)維,相反,就是想確開發(fā)看到他們工作和變更的下游變化,激勵他們以IT運(yùn)維的視角來更快的解決問題,從而達(dá)到一個全局的目標(biāo)。
11. 我最喜歡的DevOps模式三:
在開發(fā)和IT運(yùn)維之間DevOps價值流中,另一個經(jīng)常發(fā)生的問題就是不夠規(guī)范。這方面的例子是,每個部署都帶有其特殊性,因此也使得每次部署后的環(huán)境帶有特殊性,一旦這樣的事情發(fā)生,那么這個組織里就沒有針對流程配置的控制。
在這種模式下,我們定義可重用且可跨多個項(xiàng)目的部署流程,敏捷方法里有個很簡單的解決方案。就是將部署的活動變成一個用戶故事。例如,我們?yōu)镮T運(yùn)維構(gòu)建一個可重用的用戶故事,叫做“部署到高可用環(huán)境”,這個用戶故事定義了明確的構(gòu)建環(huán)境的步驟、需要多長時間、需要哪些資源等等。
那么這些信息可以被項(xiàng)目經(jīng)理用來集成部署內(nèi)容到項(xiàng)目計(jì)劃中去。例如,如果我們知道在過去的3年時間里,“部署到高可用環(huán)境”用戶故事被部署了15次,每次的平均部署時間為3天,加或減一天,那么我們對自己的部署計(jì)劃將會非常有信心。
此外,我們還可以因部署活動被合適的集成到軟件項(xiàng)目中而獲得信心。
我們也得認(rèn)識到有些特定的軟件項(xiàng)目要求特別的環(huán)境,且其不被IT運(yùn)維官方支持,我們可以允許這些被生產(chǎn)允許的環(huán)境中的例外,但是被IT運(yùn)維部門外面的人提供支持的。
通過這種方法,我們即獲得了環(huán)境標(biāo)準(zhǔn)化的好處(比如,減少生產(chǎn)差異,環(huán)境更一致,IT運(yùn)維的支持和維護(hù)能力增加),又能再允許的特殊情況下,提供業(yè)務(wù)需要的靈活性。
感謝丁雪豐對本文的審校。
深圳塔塔咨詢服務(wù)有限公司是邁瑞思旗下全資子公司,公司簡稱塔塔IT,是國內(nèi)知名的高端IT培訓(xùn)品牌,立足深圳,培訓(xùn)業(yè)務(wù)范圍覆蓋全國及港澳臺地區(qū)。公司專注于IT前沿技術(shù)的傳播與應(yīng)用,是一家以IT高端培訓(xùn)、咨詢服務(wù)、技術(shù)支持以及國際IT認(rèn)證考試為核心業(yè)務(wù)的專業(yè)服務(wù)商。公司與微軟、Redhat、Cisco、Oracle、IBM、Vmware、Citrix、EMC、HP、SAP、華為等全球著名IT廠商及EXIN、ISACA、EPI、PMI、Peoplecert、APMG等國際知名機(jī)構(gòu)建立長期合作伙伴關(guān)系,憑借在高端技術(shù)培訓(xùn)領(lǐng)域多年的教學(xué)經(jīng)驗(yàn)和項(xiàng)目經(jīng)驗(yàn),積累了大量優(yōu)質(zhì)的客戶群體,服務(wù)客戶涉及通信、金融、交通、能源、制造、政府部門等多個行業(yè)領(lǐng)域,覆蓋面極廣,累計(jì)培訓(xùn)人數(shù)數(shù)萬人,深得用戶信賴和好評。
課程咨詢熱線: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國際信息審計(jì)協(xié)會授權(quán)合作伙伴
項(xiàng)目管理協(xié)會(PMI)注冊教育培訓(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考試中心
......