大版本上線前，所有開發(fā)、測試、運(yùn)維甚至各級技術(shù)領(lǐng)導(dǎo)都如臨大敵、打著十二分的精神熬夜加班，在夜深人靜的時(shí)候，把新代碼偷偷的替換到線上。緊張的幾個(gè)測試回合下來，就已經(jīng)發(fā)現(xiàn)了數(shù)個(gè)嚴(yán)重的問題。原本靜悄悄的辦公室不再保持安靜，頓時(shí)各種聲音四起�！斑@是誰開發(fā)的模塊，快過來看看？”“在測試環(huán)境沒有問題啊，怎么又讓運(yùn)維搞砸了？”“快點(diǎn)快點(diǎn)，看看部署文檔里面的checklist是不是都執(zhí)行了？”……

一個(gè)緊張的夜間大作戰(zhàn)后，天亮了。紅彤彤的太陽照著大地，而參與戰(zhàn)斗的勇士們卻只能瞇著星星松松的睡眼，用一杯速溶豆?jié){和幾個(gè)包子來補(bǔ)充能量。新版本終于上線了，現(xiàn)在只祈禱那脆弱的系統(tǒng)在上帝的保佑下平穩(wěn)的度過一天。

這不是小說，這是一個(gè)我們常見的軟件或者應(yīng)用發(fā)布與部署的場景。

在《持續(xù)交付：發(fā)布可靠軟件的系統(tǒng)方法》一書中，作者列出了幾種持續(xù)交付的反模式，簡單來說有以下幾種：

（1）手工部署軟件。

（2） 開發(fā)完成之后才向類生產(chǎn)環(huán)境部署。

（3） 生產(chǎn)環(huán)境的手工配置管理。

同樣，在這本書中，也給出了實(shí)現(xiàn)持續(xù)交付的方法，那就是構(gòu)建一套部署流水線。關(guān)于如何實(shí)現(xiàn)部署流水線的構(gòu)建，不是本文的主要內(nèi)容，在此不做贅述。

不得不說，這本得到第21屆Jolt大獎(jiǎng)的著作深深影響了一代人對DevOps的理解。甚至有人說，DevOps就是持續(xù)交付。

DevOps不僅僅是持續(xù)交付，持續(xù)交付僅僅是DevOps整個(gè)體系中的一個(gè)組成部分。DevOps是以精益（Lean）作為支撐的，由敏捷管理、持續(xù)交付和輕量級ITSM（IT Service Management，IT服務(wù)管理）為3個(gè)支柱的價(jià)值流體系。DevOps的本質(zhì)是以消除浪費(fèi)為最終目的的精益思想在IT服務(wù)交付方面的實(shí)踐。

該圖引自《EXINWhitepaper：Success with Enterprise DevOps》

以單件流（One PieceFlow）流式供應(yīng)鏈方式構(gòu)建的JIT（Just-In-Time）和自動(dòng)化是精益理論的2個(gè)核心。傳統(tǒng)的以批量方式運(yùn)作的生產(chǎn)模式，往往造成大量的WIP（在制品，即沒有完成價(jià)值交付的半成品）積壓和流轉(zhuǎn)不暢，因此而帶來大量浪費(fèi)。而單件流模式，則以Pull（拉）的方式，以需求拉動(dòng)生產(chǎn)流水線，并盡力減少不必要的步驟從而減少浪費(fèi)，盡可能讓在制品的數(shù)量降低，以達(dá)到價(jià)值的交付。

想想吧，在我們的IT服務(wù)交付鏈中，有多少存在浪費(fèi)的地方？有多少環(huán)節(jié)出現(xiàn)了等待？有多少處在在制品狀態(tài)的項(xiàng)目、軟件、系統(tǒng)過程？

DevOps的首要目標(biāo)就是解決這些浪費(fèi)。

讓開發(fā)和運(yùn)維物理上坐在一個(gè)辦公室工作不是DevOps，讓開發(fā)參與運(yùn)維或者運(yùn)維參與開發(fā)也不是DevOps。DevOps是以精益思想為指導(dǎo)，以實(shí)現(xiàn)價(jià)值交付和杜絕浪費(fèi)為最終目的，通過構(gòu)建協(xié)作的文化、高效的溝通和系統(tǒng)集成（自動(dòng)化）來實(shí)現(xiàn)的IT服務(wù)價(jià)值鏈。

標(biāo)簽： 系統(tǒng)集成 DevOps 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。