簡介：從精益思想出發(fā)，我們可以看到DevOps的必然發(fā)展方向，那就是向業(yè)務(wù)側(cè)延伸。業(yè)務(wù)是產(chǎn)品開發(fā)和運維的源頭，完整的價值流必須從源頭開始。這不是預(yù)測，而是正在發(fā)生的事實

編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://developer.aliyun.com/topic/devops，下載完整版電子書，了解阿里十年DevOps實踐經(jīng)驗。

本文作者：何勉，阿里云云效資深技術(shù)專家

談到DevOps，就必須從敏捷和精益開發(fā)說起。DevOps在它們基礎(chǔ)上發(fā)展而來，借鑒了其中的方法、理念，并發(fā)展和完善了它們的實踐體系。

敏捷軟件開發(fā)的興起

敏捷軟件開發(fā)的實踐最早出現(xiàn)在上世紀(jì)90年代。當(dāng)時，一批輕量的軟件工程方法和框架相繼誕生，它們共同的特點是，相對傳統(tǒng)軟件工程，都遵循演進和迭代的模型，過程更加輕量靈活。其中Scrum和極限編程（ExtremeProgramming）在實踐上最為成功，影響最大。它們都是迭代和增量的軟件開發(fā)框架，區(qū)別是Scrum只包含管理實踐，而極限編程則同時涵蓋工程和管理實踐。

上世紀(jì)90年代，PC軟件流行和第四代編程語言的出現(xiàn)，面向?qū)ο蠛驮O(shè)計模式運動的興起，讓小型項目的開發(fā)蓬勃發(fā)展。同時，互聯(lián)網(wǎng)應(yīng)用和開源社區(qū)興起，有別于傳統(tǒng)的開發(fā)模式不斷涌現(xiàn)，優(yōu)秀個人在程序開發(fā)中的作用得到凸顯。

這些因素都讓非傳統(tǒng)開發(fā)方法有了實驗的土壤。其結(jié)果是，一方面質(zhì)量問題層出不窮，這部分促使了源自全面質(zhì)量管理體系的CMM/CMMI在這一時間的繁榮和推廣；另一方面也產(chǎn)生了許多不同于傳統(tǒng)方法的有效實踐，讓業(yè)界看到了新的可能。敏捷運動這時已經(jīng)呼之欲出，它既是對傳統(tǒng)的反叛，也是對野蠻生長的規(guī)范。

2001年2月，17位輕量級軟件工程方法的代表人物，齊聚美國猶他州的雪鳥滑雪勝地，其中也包括Scrum和極限編程的幾位發(fā)明人。在兩天的會議之后，發(fā)布了后來產(chǎn)生巨大影響的敏捷宣言(參見 http://agilemanifesto.org/)，敏捷宣言陳述了他們共同認(rèn)可的關(guān)于軟件的開發(fā)方法的理念，同樣重要的是他們找到了敏捷這個詞來總領(lǐng)這些理念。

敏捷概念在2001年出現(xiàn)，可以說適逢其時。當(dāng)時，一方面?zhèn)鹘y(tǒng)方法變得越來越臃腫笨重，卻沒有解決軟件危機；另一方面，人類正在進入互聯(lián)網(wǎng)時代，軟件業(yè)對響應(yīng)變化和創(chuàng)新的要求迅速升級，這是更根本的原因，畢竟需求才是行業(yè)發(fā)展的最好助推劑。

敏捷宣言發(fā)布后，敏捷成為了一場運動，被迅速地推廣和應(yīng)用。但是，早期的敏捷專注的還是研發(fā)交付階段，站在業(yè)務(wù)的角度，它的目標(biāo)是幫助產(chǎn)品和研發(fā)團隊提升敏捷響應(yīng)能力，也就是：“更早地交付價值，更靈活地應(yīng)對變化”。然而，在企業(yè)數(shù)字化轉(zhuǎn)型的背景之下，IT不僅要保證產(chǎn)品的開發(fā)和交付，系統(tǒng)部署和運行同樣重要。DevOps繼承了敏捷開發(fā)的理念，又補上了運維的部分，但DevOps絕不是開發(fā)和運維的簡單疊加，這個我們后面還會說到。

精益產(chǎn)品開發(fā)的出現(xiàn)

精益思想最早源自生產(chǎn)制造領(lǐng)域，根源于豐田在產(chǎn)品制造中管理和工程實踐。1988年《斯隆管理評論》的一篇論文《精益生產(chǎn)系統(tǒng)的勝利》比較了西方的生產(chǎn)方式和豐田生產(chǎn)方式在效率和質(zhì)量上巨大差距，挑戰(zhàn)了規(guī)模生產(chǎn)帶來效益的神話。從此，精益開始進入西方的視野，逐漸成為現(xiàn)代管理學(xué)的重要組成部分。

《精益思想》一書將精益定義為：有效組織人類活動的一個新的思維方法，目標(biāo)是消除浪費，以更多地交付有用的價值。書中進一步總結(jié)了精益的5個原則，同時也是精益的5個實施步驟：

定義價值：站在用戶的視角定義什么是價值，并把它描述為具體產(chǎn)品或服務(wù)；

識別價值流：識別和映射創(chuàng)造價值的流程步驟，消除不增加用戶價值的步驟和活動；

讓價值持續(xù)流動：讓用戶價值在流程步驟中流動起來，使它們持續(xù)、順暢地流向最終用戶；

用戶價值拉動：由用戶價值拉動流動，避免不帶來用戶價值的浪費；

精益求精：不斷重復(fù)1到4步。追求完美的價值和價值流動，消除過程中所有浪費。

在這個抽象層次上，精益思想超越了其誕生的制造業(yè)，深刻影響了各個行業(yè)，如精益政務(wù)、精益醫(yī)院、精益領(lǐng)導(dǎo)力、精益服務(wù)業(yè)、精益供應(yīng)鏈、精益教育等，這其中也包含產(chǎn)品開發(fā)。事實上，主流的敏捷開發(fā)方法都直接受到了精益思想的影響，遵循精益的基本原則。

與此同時，精益產(chǎn)品開發(fā)作為獨立的實踐體系也快速發(fā)展，它聚焦兩個方面的目標(biāo)——價值交付過程和價值本身。

第一，關(guān)注價值交付過程。其中比較有代表性的是“精益看板方法”，它由David Anderson在2006年左右基于自己的實踐發(fā)展而來，并在2010年出版的《看板方法》一書中加以系統(tǒng)總結(jié)。“看板方法”是精益思想在軟件開發(fā)中具體應(yīng)用。它從可視化需求交付端到端的價值流開始，通過系統(tǒng)的實踐提升需求的流動效率，并確保流動的過程質(zhì)量，從而實現(xiàn)端到端的系統(tǒng)改進。

“看板方法”為代表的這一類精益實踐的本質(zhì)改變是：從關(guān)注資源的使用效率，轉(zhuǎn)變?yōu)殛P(guān)注價值的流動效率。這也帶動使用者從過去的局部優(yōu)化轉(zhuǎn)向端到端的全局優(yōu)化。

第二，關(guān)注價值本身。其中比較有代表性的是“精益創(chuàng)業(yè)”。精益創(chuàng)業(yè)的實踐最初由Steve Blank基于自己和其他硅谷的創(chuàng)業(yè)實踐發(fā)展而來，Eric Ries在《精益創(chuàng)業(yè)》一書中對精益創(chuàng)業(yè)的理念和實踐，做了系統(tǒng)的總結(jié)，并讓精益創(chuàng)業(yè)的理念迅速普及。

精益創(chuàng)業(yè)認(rèn)為創(chuàng)業(yè)是一個巨大不確定的過程，其最大的浪費是交付沒用的（不能解決用戶問題，或帶來業(yè)務(wù)成功）的東西。為此它把價值的探索和發(fā)現(xiàn)融入產(chǎn)品交付過程，提出了著名的“開發(fā)-測量-學(xué)習(xí)”循環(huán)。循環(huán)從關(guān)于市場和產(chǎn)品的待檢驗概念開始。接下來，循環(huán)的第一步是開發(fā)用以驗證這一概念的最小可行產(chǎn)品（MVP，Minimal Viable Product）；第二步：基于最小可行產(chǎn)品收集市場、用戶的反饋，并獲得測量數(shù)據(jù)；第三步：用數(shù)據(jù)驗證假設(shè)，證實或證偽它們，并加以調(diào)整，產(chǎn)生經(jīng)實證的認(rèn)知。然后，進入下一循環(huán)，持續(xù)探索商業(yè)模式和產(chǎn)品功能設(shè)計。

精益創(chuàng)業(yè)的影響遠(yuǎn)超初創(chuàng)公司，事實上“精益創(chuàng)業(yè)”一書中把“創(chuàng)業(yè)”定義為在不確定的環(huán)境下，開創(chuàng)新的業(yè)務(wù)和產(chǎn)品。而“不確定性”似乎已成為今天IT領(lǐng)域身處環(huán)境的共性，也因此，MVP、“開發(fā)-測量-學(xué)習(xí)”循環(huán)等理念已成為IT創(chuàng)新領(lǐng)域公認(rèn)的實踐，并且圍繞精益創(chuàng)業(yè)發(fā)展出一套完整的創(chuàng)新實踐體系，如精益數(shù)據(jù)分析、精益客戶開發(fā)、精益交付設(shè)計等。

探索和發(fā)現(xiàn)有效的價值，并讓價值順暢流動。圍繞這兩個目標(biāo)，并遵循精益思想，精益產(chǎn)品開發(fā)已經(jīng)發(fā)展成為系統(tǒng)的實踐。精益思想對DevOps的影響也非常根本，DevOps三原則就完全遵循了精益思想。

DevOps的誕生

最初，敏捷和精益社區(qū)都還只是關(guān)注開發(fā)側(cè)的實踐和行為，運維并沒有成為他們關(guān)注的重點。但是，光有系統(tǒng)開發(fā)是不夠的，開發(fā)完的系統(tǒng)必須即時順利部署，并連續(xù)穩(wěn)定運行才能夠?qū)崿F(xiàn)價值。而傳統(tǒng)上，這部分是由運維負(fù)責(zé)的。

從價值的角度，開發(fā)加運維才構(gòu)成相對完整的IT價值鏈。當(dāng)然更完整的還應(yīng)該包含業(yè)務(wù)，這是后話了，這還不是早期DevOps社區(qū)關(guān)注的重點。DevOps誕生之初，解決的問題還是開發(fā)和運維之間的問題，這是影響IT價值鏈的最突出問題。

在傳統(tǒng)的IT組織下，開發(fā)團隊（Dev）和運維團隊（Ops）之間訴求不同——開發(fā)團隊（尤其是敏捷團隊）追求變化，運維團隊追求穩(wěn)定。雙方往往存在利益的沖突，比如，精益和敏捷的團隊把持續(xù)交付作為目標(biāo)，而運維團隊則為了線上的穩(wěn)定而強調(diào)變更控制。部門墻由此建立起來，這當(dāng)然不利于IT價值的最大化。

2009年，在美國舉行的第二屆Velocity大會上，來自Flickr公司的John Allspaw和Pauk Hammond發(fā)表了一個演講《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在這個演講中，Allspaw和Hammond以角色扮演的方式，生動地表現(xiàn)了開發(fā)與運維之間的各種沖突。演講中出現(xiàn)很多金句，如“It's not my code, it's your machines!”，這深刻反映了Dev和Ops關(guān)系的現(xiàn)狀。接著，他們又展示了如何通過消除開發(fā)團隊（Dev）和運維團隊（Ops）的壁壘，雙方通力合作，借助工具和文化的改變讓軟件的發(fā)布和運維變得持續(xù)和高效。

這次演講是DevOps發(fā)展歷程中的標(biāo)志性事件。它提出了正確的問題——為了更快交付和實現(xiàn)價值，必須彌合開發(fā)和運維之間的鴻溝，并給出了解決方案——為了彌合開發(fā)和運維之間的鴻溝，需要在文化、工具和實踐方面的系列變革。

同一年，比利時獨立IT咨詢師Patrick Debois看到這個演講，受到啟發(fā)，組織了第一屆DevOpsDays，DevOps正式登上舞臺，DevOps的理念開始流行，其相關(guān)的工具和實踐也快速發(fā)展。期間以容器化和自動編排調(diào)度為代表的云原生技術(shù)的出現(xiàn)也極大加速了這一進程。今天，DevOps已成為企業(yè)數(shù)字化的核心能力之一，是對IT交付和運行的基本要求。

其后，在《鳳凰項目》和《DevOps實踐指南》兩本書中，Gene Kim等人總結(jié)了DevOps實施的三步工作法，它們分別是:

流動原則：聚焦IT系統(tǒng)的整體價值流，全局優(yōu)化，保證價值從左（上游）到右（下游）的快速流動。

反饋原則：創(chuàng)建從左到右的反饋循環(huán)，并縮短反饋周期和放大反饋效果。這樣，就可以更快的響應(yīng)和理解內(nèi)外部客戶，并即時獲取改進所需要的知識。

持續(xù)的實驗和學(xué)習(xí)原則：創(chuàng)建承擔(dān)風(fēng)險、持續(xù)實驗并從錯誤中學(xué)習(xí)的文化，在不斷的嘗試中精進能力，并提高系統(tǒng)的韌性。

Kim等人認(rèn)為，這三步工作法是其他一切DevOps流程、實踐的價值和哲學(xué)根基，所有DevOps模式都可以從這三個原則派生而來。

稍作探究，就能夠覺察，DevOps三步工作法是精益原則的翻版。更確切的講，是精益原則在IT開發(fā)和運行上下文中的具體實例。事實上，DevOps的基礎(chǔ)部分，體現(xiàn)了精益原則的影響和應(yīng)用。

總結(jié)

回顧敏捷、精益和DevOps的發(fā)展，我們可以得出如下兩個結(jié)論。

第一，DevOps 是敏捷開發(fā)實踐的自然發(fā)展。敏捷開發(fā)的目標(biāo)是“更早地交付價值，更靈活地應(yīng)對變化”。敏捷運動始于開發(fā)側(cè)，但運維側(cè)如果不做改變，就一定會成為瓶頸，最終敏捷的目標(biāo)還是無法達(dá)成。為了讓敏捷實踐發(fā)揮真正的價值，開發(fā)運維的聯(lián)動就勢在必行了。

第二，DevOps是精益思想應(yīng)用在IT領(lǐng)域的必然結(jié)果。精益產(chǎn)品開發(fā)的目標(biāo)是：“順暢的交付有效價值”，精益思想則要求端到端的系統(tǒng)優(yōu)化和持續(xù)的改進。而開發(fā)和運維是系統(tǒng)的兩個重要組成部分，缺一不可。DevOps三原則，正是精益思想在IT開發(fā)運維領(lǐng)域的具體實例。

最后，從精益思想出發(fā)，我們可以看到DevOps的必然發(fā)展方向，那就是向業(yè)務(wù)側(cè)延伸。業(yè)務(wù)是產(chǎn)品開發(fā)和運維的源頭，完整的價值流必須從源頭開始。這不是預(yù)測，而是正在發(fā)生的事實，大部分DevOps的實施都已經(jīng)將業(yè)務(wù)側(cè)包含在內(nèi)，成為BizDevOps，只不過DevOps的稱謂已經(jīng)深入人心，我們也將延續(xù)DevOps的說法，但缺省情況下，它包含了業(yè)務(wù)在內(nèi)。

DevOps發(fā)展的同時，數(shù)字化轉(zhuǎn)型也成為了企業(yè)界的共識，大部分企業(yè)數(shù)字化框架都把DevOps作為最核心的能力之一，DevOps的影響范圍也不斷擴大，成為力求提升數(shù)字化能力的企業(yè)必然選擇。下一節(jié)我們將在數(shù)字化轉(zhuǎn)型這一背景下，分析DevOps要解決的根本問題。

免費下載《阿里巴巴DevOps實踐指南》

阿里巴巴合伙人和業(yè)界多位大佬力薦、何勉、陳鑫等17位阿里資深技術(shù)專家聯(lián)袂出品、阿里十年DevOps經(jīng)驗沉淀總結(jié)、阿里巴巴DevOps落地實踐一本通。

前往：https://developer.aliyun.com/topic/devops，下載完整版電子書。

原文鏈接：https://developer.aliyun.com/article/785006?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的为什么说DevOps的必然趋势是BizDevOps？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。