簡介：從精益思想出發，我們可以看到DevOps的必然發展方向，那就是向業務側延伸。業務是產品開發和運維的源頭，完整的價值流必須從源頭開始。這不是預測，而是正在發生的事實。
編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，前往：https://developer.aliyun.com/...，下載完整版電子書，瞭解阿里十年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要解決的根本問題。
阿里巴巴合夥人和業界多位大佬力薦、何勉、陳鑫等17位阿里資深技術專家聯袂出品、阿里十年DevOps經驗沉澱總結、阿里巴巴DevOps落地實踐一本通。
前往：https://developer.aliyun.com/...，下載完整版電子書。
歡迎大家使用雲效，雲原生時代新DevOps平臺，透過雲原生新技術和研發新模式，大幅提升研發效率。現雲效公共雲基礎版不限人數0元使用。