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

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

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

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

敏捷軟件開發的興起

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

上世紀90年代，PC軟件流行和第四代編程語言的出現，面向對象和設計模式運動的興起，讓小型項目的開發蓬勃發展。同時，互聯網應用和開源社區興起，有別于傳統的開發模式不斷涌現，優秀個人在程序開發中的作用得到凸顯。

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

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

敏捷概念在2001年出現，可以說適逢其時。當時，一方面傳統方法變得越來越臃腫笨重，卻沒有解決軟件危機；另一方面，人類正在進入互聯網時代，軟件業對響應變化和創新的要求迅速升級，這是更根本的原因，畢竟需求才是行業發展的最好助推劑。

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

精益產品開發的出現

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

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

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

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

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

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

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

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

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

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

“看板方法”為代表的這一類精益實踐的本質改變是：從關注資源的使用效率，轉變為關注價值的流動效率。這也帶動使用者從過去的局部優化轉向端到端的全局優化。

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

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

精益創業的影響遠超初創公司，事實上“精益創業”一書中把“創業”定義為在不確定的環境下，開創新的業務和產品。而“不確定性”似乎已成為今天IT領域身處環境的共性，也因此，MVP、“開發-測量-學習”循環等理念已成為IT創新領域公認的實踐，并且圍繞精益創業發展出一套完整的創新實踐體系，如精益數據分析、精益客戶開發、精益交付設計等。

探索和發現有效的價值，并讓價值順暢流動。圍繞這兩個目標，并遵循精益思想，精益產品開發已經發展成為系統的實踐。精益思想對DevOps的影響也非常根本，DevOps三原則就完全遵循了精益思想。

DevOps的誕生

最初，敏捷和精益社區都還只是關注開發側的實踐和行為，運維并沒有成為他們關注的重點。但是，光有系統開發是不夠的，開發完的系統必須即時順利部署，并連續穩定運行才能夠實現價值。而傳統上，這部分是由運維負責的。

從價值的角度，開發加運維才構成相對完整的IT價值鏈。當然更完整的還應該包含業務，這是后話了，這還不是早期DevOps社區關注的重點。DevOps誕生之初，解決的問題還是開發和運維之間的問題，這是影響IT價值鏈的最突出問題。

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

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

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

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

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

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

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

持續的實驗和學習原則：創建承擔風險、持續實驗并從錯誤中學習的文化，在不斷的嘗試中精進能力，并提高系統的韌性。

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

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

總結

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

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

第二，DevOps是精益思想應用在IT領域的必然結果。精益產品開發的目標是：“順暢的交付有效價值”，精益思想則要求端到端的系統優化和持續的改進。而開發和運維是系統的兩個重要組成部分，缺一不可。DevOps三原則，正是精益思想在IT開發運維領域的具體實例。

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

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

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

阿里巴巴合伙人和業界多位大佬力薦、何勉、陳鑫等17位阿里資深技術專家聯袂出品、阿里十年DevOps經驗沉淀總結、阿里巴巴DevOps落地實踐一本通。

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

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

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的阿里巴巴DevOps实践指南 | 为什么DevOps的必然趋势是BizDevOps？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。