? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?《持續(xù)交付》譯者《持續(xù)交付 2.0》作者

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 騰訊高級管理顧問

講師介紹

大家都叫我“喬幫主”？這個綽號是我 2010年以領(lǐng)域?qū)＜疑矸菁尤氚俣萈MO時得到的。

當(dāng)時百度并沒有工程生產(chǎn)力部門，而是負責(zé)軟件過程度量的 SQA。在加入之后，該部門的職責(zé)已經(jīng)改為：“通過引入先進軟件研發(fā)模式，并在百度各產(chǎn)品線進行推廣，從而提升生產(chǎn)效率“。

現(xiàn)在，DevOps 運動興起，持續(xù)交付研發(fā)理念已被廣泛接受。

而在當(dāng)時，我們戲稱自己是“丐幫”，因為持續(xù)集成和持續(xù)交付這種軟件交付方式在當(dāng)時還很難被人接受，所以只能向不同團隊“兜售（祈求）”我們的持續(xù)交付研發(fā)方式，也不一定被人“理睬”。

而我一身正氣，是不是和《天龍八部》中的喬幫主有點兒像，哈哈哈。

在過去的10年里，我為不同類型的企業(yè)提供組織轉(zhuǎn)型和研發(fā)效率方面的咨詢工作，今天這個題目是我對過去這么多年的總結(jié)。

更多的實踐原則與方法在我的新書《持續(xù)交付 2.0》。本會場可以看到一些預(yù)覽版，當(dāng)然只有為數(shù)不多的幾本，因為還沒有正式印刷出版。這一版算是“限量版”啦，哈哈哈。

那么在過去的這些年里面，我遇到了什么？我在這個行業(yè)里做過很多角色，從普通工程師到架構(gòu)師，從項目經(jīng)理到部門負責(zé)人。

從小作坊式的軟件生產(chǎn)，到大規(guī)模的瀑布軟件開發(fā)方法。感覺做軟件總是這么累，反反復(fù)復(fù)總是不流暢。

直到2002年發(fā)現(xiàn)了《解析極限編程》，覺得其中的開發(fā)方法有些不可思議，但覺得應(yīng)該能有一些效果。

后來有機會在自己的團隊中使用其中一些實踐，當(dāng)然根據(jù)自己的判斷進行了所謂的定制（現(xiàn)在看來是不恰當(dāng)?shù)淖龇?#xff09;，得到一些收益，但并沒有想象的那么大。

直到 2007 年加入思特沃克公司（ThoughtWorks）以后，尤其是與Jez Humble（他是 DevOps 領(lǐng)域的世界級領(lǐng)軍人物）一起負責(zé)一款軟件產(chǎn)品開發(fā)以后，才真正體會到這種軟件開發(fā)模式的魅力。持續(xù)交付這種開發(fā)方式的確可以讓軟件交付變得非常快。

然而，當(dāng)時IT行業(yè)的絕大多數(shù)組織并不相信這一點，所以我就開始了我的布道之旅。

我在過去十年里也遇到過困難，走過一些彎路，今天就為大家分享其中的幾個“陷阱”。提醒大家一點，這條路不太好走。

1. DevOps 運動誕生的必然與發(fā)展

---

在不同的時期，軟件交付面臨不同的困難，而行業(yè)中各種新名詞的出現(xiàn)，總是想解決軟件生命周期中的某個具體問題。

上個世紀60年代未出現(xiàn)第一次“軟件危機”，所以我們從建筑行業(yè)借用了“工程”的概念，并產(chǎn)生了“軟件工程”學(xué)科，并隨之出現(xiàn)了瀑布模型，它是期望通過嚴格的重文檔重流程的瀑布模式來解決業(yè)務(wù)需求多與軟件人員能力及人員供給不足所導(dǎo)致的軟件項目交付成功率低下問題。

然而，軟件工程并未像建筑工程那樣發(fā)揮相同的作用，軟件項目成功率仍舊不高。

在90年代出現(xiàn)了很多輕量級的軟件開發(fā)方法，更強調(diào)迭代與增量，與瀑布模式形成鮮明對比。

到了2001年，這些方法都被統(tǒng)稱為“敏捷開發(fā)方法”。當(dāng)然，強調(diào)迭代的同時，瀑布模型仍舊存在，很多團隊在每個迭代的粒度內(nèi)，還仍舊使用瀑布模型。軟件團隊經(jīng)過幾個迭代的開發(fā)以后，再把軟件發(fā)布到生產(chǎn)環(huán)境上。

2010年《持續(xù)交付》一書發(fā)布，并描述了這樣一種交付方式，即“持續(xù)交付”。讓軟件隨時處于可發(fā)布狀態(tài)，可以按需發(fā)布到生產(chǎn)環(huán)境。

這個時候，瀑布模型仍舊沒有消失，只是它在一個更小的粒度上發(fā)揮作用，即單一需求的粒度。

下面這個環(huán)就是一個軟件的交付環(huán)。

我們可以看到，在過去這么長時間，持續(xù)集成（CI）和敏捷軟件開發(fā)方法（Agile）中的很多實踐聚焦于解決從需求到構(gòu)建出軟件這一環(huán)節(jié)中各角色的合作。

而互聯(lián)網(wǎng)業(yè)務(wù)的崛起，使得如何讓構(gòu)建完成的軟件快速上線成為決勝的關(guān)鍵因素。而這也是“DevOps“這個名詞出現(xiàn)的巨大動力之一。

因為，此時傳統(tǒng)運維的工作方式成了“瓶頸”，必須改變原來研發(fā)部門與運維部門之間的協(xié)作方式，才能讓這一過程更加平滑流暢。

DevOps 強調(diào)的是軟件開發(fā)團隊和運維團隊的敏捷協(xié)作，讓軟件更加平滑、快速進入到生產(chǎn)環(huán)境上，從而發(fā)揮軟件價值。早在 2011 QCON 大會上，我有一個主題演講，題目就是《 DevOps，讓持續(xù)交付成為可能》。

其中，最后一個關(guān)鍵點就是：讓運維人員參與到軟件開發(fā)過程中，組建全功能團隊，建立信任關(guān)系，改變原有的工作方式，從而提升軟件的交付速度。

持續(xù)集成和敏捷打破了產(chǎn)品開發(fā)和測試之間的一個部門墻，讓他們更加快速的能夠迭代起來。

那么，迭代完之后呢，我們需要快速部署，盡早發(fā)揮軟件價值。此時就有了DevOps。

DevOps 讓我們的軟件交付團隊和軟件運維部署監(jiān)控團隊能夠合作起來。而持續(xù)交付1.0 需要將敏捷和 DevOps 結(jié)合在一起，才能從前到后貫穿。

持續(xù)交付并不僅僅指運維團隊每天多次從產(chǎn)品庫中取出二進制軟件包進行自動化部署。這一點應(yīng)該是大家想清楚的。

DevOps 到底是什么呢？由四位 DevOps 運動領(lǐng)軍人物共同出品的《 DevOps 實踐指南 》一書中，也沒有對 DevOps 完整定義。事實上，它沒有行業(yè)上統(tǒng)一的定義。

從我自己的理解的話，敏捷本身是一場運動，它旨在尋找一系列的方法和實踐，以提升軟件交付的質(zhì)量和效率。

我把“質(zhì)量”放在前面，是因為只有在確定質(zhì)量水平的前提下，提升軟件交付效率才更有意義。

那么，DevOps 是什么呢？DevOps 也可以說是一場運動，它的目標與敏捷一致，如上圖所示。

DevOps 已經(jīng)成長近10年，行業(yè)內(nèi)有很多很多的做法。上圖是我在網(wǎng)上找到的一張截圖，在這張圖里面可以看到很多工具，并且都被稱為 DevOps 工具。然而，這些工具已經(jīng)存在很久了，比如Git（一種分布式代碼版本管理工具）。難道企業(yè)使用了這些工具，就說明企業(yè) DevOps 了？

很多企業(yè)說：“我要做 DevOps 了，我要雇傭 DevOps 工程師！”現(xiàn)在好像DevOps 工程師的招聘薪資也的確比較高。但是并不是使用了一些工具，雇了一些 DevOps 的工程師，你的 DevOps 就可以做得很好。

很多的企業(yè)想：“我要做敏捷，我要做 DevOps 。做了之后，軟件交付速度就從一個月變成了兩個星期，進而兩天，甚至一天，或者更高。

然而，現(xiàn)實中的企業(yè)歷程通常是下圖藍色曲線這樣的。您可能已經(jīng)注意到，曲線的后半部分是虛線。 為什么是虛線呢？因為只有很少的企業(yè)可能跨過鴻溝，持續(xù)提升。

1?鴻溝產(chǎn)生的原因？

---

當(dāng)某個組織說：“我們要 DevOps 了”以后，會馬上找來一批工具，再找一些DevOps 工程師，將它的現(xiàn)有流程做成一系列的自動化步驟（比如自動提測，發(fā)通知郵件等）。

此時，我們會得到一些收益。當(dāng)流程優(yōu)化到一定階段以后，我們會開始關(guān)注“測試提速”這個問題。于是，就會開始做一些自動化測試。

在做自動化測試時，遇到的第一個問題就是測試環(huán)境準備的自動化。解決這個問題之后，我們也會得到一些收益，這個收益的大小決定于原來這個環(huán)境準備工作到底有多“痛苦”！

當(dāng)這一步準備好以后，測試人員可能就會開足馬力寫一些自動化測試了。最初的兩個月里，大家覺得這個效果也還不錯。然而，很快就會到達上圖中的第一個拐點。

此時很多人還沒有意識到，所以仍舊會按照現(xiàn)有的方式，由測試人員增加更多的自動化測試用例。

一段時間以后，就會覺察到，效果不像早期那樣明顯提升了。這個時候，常見的選擇有兩種，一是繼續(xù)堅持這樣做下去，很可能收益會下降。 另外一種做法是保持當(dāng)前這種現(xiàn)狀。也就是說，大部分企業(yè)會停留在該曲線上那段平臺期的某一點上。

此時，DevOps 的實施策略是“摘取伸手可得的蘋果”。也就是：

（1）別讓變動太多，太大；（2）先找容易的事情做。如下圖所示。

為什么這個曲線最開始有一個提升期？是因為流程自動化等工作減少了每個交付迭代中的事務(wù)性成本。

從最終客戶（用戶）的視角來看，每個軟件交付迭代包括兩類活動，一是增值活動，另一類是非增值活動，也可以叫做事務(wù)性成本。

這部分事務(wù)性成本是什么呢？例如，測試活動、迭代計劃會議、站會等等。我們希望在保證交付質(zhì)量水準的前提下，將這些事務(wù)性成本變得更低，從而增加更多的增值活動時間。

當(dāng)這些事務(wù)性成本降低后，我們的原有交付周期中增值活動的時間就會變多。此時可以將迭代交付周期進一步縮短，從而讓用戶更快地得到軟件。

但縮短到一定程度以后，你很可能會發(fā)現(xiàn)，每一個短迭代周期中的增值活動和事務(wù)性活動時間的比例會再次恢復(fù)到原來水平，如下圖所示。這會讓團隊非常惱火，無論從上到下都非常得惱火。

為什么會這樣呢？舉個例子，持續(xù)交付模式需要較多的自動化測試用例。而測試工作通常是由測試部門承擔(dān)的。測試部門有人力投入到自動化測試編寫之上。而最初寫的自動化測試都是端到端測試。

隨著端到端測試數(shù)量的增加，你會發(fā)現(xiàn)，維護這些測試用例需要很多的成本，很容易形成頭重腳輕的情況，如下圖所示。

這個時候就會有人跳出來，挑戰(zhàn)道：“你投入這么多自動化測試的成本，收益是什么？投入產(chǎn)出比值得么？” 這種場景通常會發(fā)生在平臺期。這就是很難再走下去的原因之一。

端到端的自動化測試運行成本高，維護成本高，診斷成本也高。而很多組織的測試人員并不具備編寫低層自動化測試用例的能力。即使具備更細粒度的下層自動化測試用例的編寫能力，由于協(xié)作流程與組織文化等原因，也無法及時獲得必要的寫作變更信息，這一樣會導(dǎo)致這些下層細粒度測試用例的編寫質(zhì)量，以及用例變更的及時性。

那么，如何跨越這個鴻溝呢？

2 實施 DevOps 的兩個關(guān)鍵思考？

第一：正確認識“度量”

怎么強調(diào)度量都不過分。通常度量項有三種屬性。包括它的可觀察性、可行動性與時間性。時間性又分為引導(dǎo)性和滯后性，如下圖所示。

有一些指標是可直接觀察獲得的，但是無法對它直接采取行動。例如千行代碼缺陷數(shù)量，它是可以直接統(tǒng)計并觀察到的，但它也有滯后性，因為當(dāng)你得到這個數(shù)據(jù)之時，它已經(jīng)成為事實結(jié)果。

與此同時，它也不具備可行動性，因為你無法采取哪些行動，直接降低這個指標。

相反，你可能使用一些引導(dǎo)性指標來指引團隊的行為，從而可能達成想要的結(jié)果，例如代碼review的數(shù)量、代碼規(guī)范檢查標準等。

另一個例子是：從提測到上線前發(fā)現(xiàn)的缺陷數(shù)量，這個指標也是滯后性指標，因為得到這個指標的數(shù)據(jù)時，它已經(jīng)是一個結(jié)果。與之相比，自測的測試用例數(shù)量可能就是一個引導(dǎo)性的指標，而且是一個可行動指標。

我們假設(shè)：自測的用例數(shù)量增高后，提測后的缺陷會減少，但這兩個指標之間的因果關(guān)系只是我們的推測，還有很多因素的影響。

軟件工程中的一大難題就是“研發(fā)效率度量”。總會有人問，這個軟件開發(fā)效率到底如何度量？我也一直沒有發(fā)現(xiàn)一個非常有效的且業(yè)內(nèi)可以達成完全一致的研發(fā)效率度量體系。

但我認為，在眾多的指標中，每一個度量指標都是意義的，但它對于你所在組織是否有效，就不一定了。這取決于組織能力、產(chǎn)品形態(tài)與人員技能水平。

上圖中，越靠近右側(cè)的指標具有更多的過程引導(dǎo)性，而越靠近左側(cè)的指標相對來說，就更多的是滯后性結(jié)果指標。兩個指標之間的距離越大，離得越遠，那么它們之間的直接相關(guān)性就越弱。而且，其中多個指標之間也會互相影響。

因此，在設(shè)計改進方案時，必須想清楚這些目標中，你到底要選擇哪一組指標。當(dāng)某一個指標發(fā)生變化以后，是否會引起其他指標的變化，預(yù)計這個影響有多大？這個影響預(yù)計需要多長時間才能夠體現(xiàn)出來？

另外，引導(dǎo)性指標通常會有延遲效應(yīng)，它的作用需要一段時間之后才可能傳導(dǎo)至對應(yīng)的滯后性指標，甚至因為距離太遠而無法被覺察過。

這些年積累的經(jīng)驗，我覺得可以從以下幾個方面進行著手。

獲取度量數(shù)據(jù)，需要一定的成本。假如當(dāng)前沒有任何準備的話，想要持續(xù)獲得全面性數(shù)據(jù)，前期投入一定不小。

因此，初期可以采用抽樣法以較小成本獲得一定量可信數(shù)據(jù)，以展開改進行動。但這種方式可能會有偏差，有一定的風(fēng)險性。

另外，我還想提及另一個突破性關(guān)鍵點。即“尋求第二序改變”。有一本名為《改變》的書，該書中講到了“問題的形成和解決的原則”。

給我留下比較深刻印象的是，“第二序改變”可以引起更大的差異性結(jié)果。所謂第一序改變，就是指以系統(tǒng)本身結(jié)構(gòu)不變?yōu)榍疤?#xff0c;對現(xiàn)狀進行改變，通常這種改變并不會引起“質(zhì)”的變化。要想帶來“質(zhì)”的變化，必須尋求第二序變化，即：通過對系統(tǒng)本身結(jié)構(gòu)的改變而帶來變化。

第二：尋求系統(tǒng)本身結(jié)構(gòu)的變化

例如，改變自動化測試用例的使用者。在沒有改變之前，自動化測試用例的使用者通常為測試人員。如果我們將它的使用者改為開發(fā)人員，此時，看待測試用例的視角，以及對測試用例的要求可能就完全不同。

通常為了讓開發(fā)人員能夠高效地利用這些自動化測試用例，改善開發(fā)人員的工作效率，這些自動化測試用例就必須符合四個原則，即：快、捷、信、時。

“快”是指每一個自動化測試用例的運行速度必須非常快。“捷”是指：一定要保證開發(fā)人員能夠非常便捷地一鍵運行其指定的測試用例集。“信”是指在測試運行完成之后，其結(jié)果是可信的。“時”是指用例準備的及時性。即當(dāng)開發(fā)人員想要測試自己剛剛開發(fā)完成的功能時，最好自動化測試用例就已經(jīng)準備好了。

如果所有的測試用例僅僅是針對那些非常穩(wěn)定的功能特性進行測試，那么它對當(dāng)前開發(fā)任務(wù)的作用就沒有那么明顯了。

自動化測試用例的使用者從測試人員改變?yōu)殚_發(fā)人員，這就是一個“第二序改變”。為了完成這種改變，就必須改變原有的思考和工作模式。

為了達到這些要求，我們可能需要將一些測試用例的層次從最上層的端到端測試下移到系統(tǒng)集成測試、組件測試，甚至單元測試，如下圖所示。

這很可能會導(dǎo)致團隊角色與職責(zé)的變化。因為這種變化打破了原有的工作流程與結(jié)構(gòu)，就很可能帶來新的改變。

這種改變可能就會改善我們的自動化測試用例數(shù)量的狀態(tài)，并向著良性的正三角形發(fā)展。

到目前為止，我們討論的都是“軟件交付領(lǐng)域”的內(nèi)容，也就是《持續(xù)交付 2.0》中所說的提升“快速驗證環(huán)”的努力，即如何快速交付那些已經(jīng)準備好的需求。

然而，從產(chǎn)品的角度考慮，這個閉環(huán)并不是一個完整的閉環(huán)，因為準備好的需求并不是問題的起點。那么問題的起點在哪里呢？當(dāng)然是在業(yè)務(wù)領(lǐng)域。

我們開發(fā)軟件，是為了解決某些業(yè)務(wù)問題。因此，如果我們從更完整的視角看待問題，那么軟件價值的交付應(yīng)該是兩個環(huán)的閉環(huán)模型，如下圖所示。

從“提問”開始，為什么要開發(fā)軟件功能？做了它以后，我們期望對哪些指標產(chǎn)生怎樣的影響，為什么我們認為會產(chǎn)生這種影響，這就是“錨定”。

有多少種不同方法可以達成我們期望的改變，這就是“共創(chuàng)”。到底哪個方案是我們認為最有可能達成我們目標的方式，這就是“精煉”。

然后才是“快速驗證環(huán)”這才是一個真正的、完整的價值交付的環(huán)，從提問開始，真到問題是否得到解答為止。

3 DevOps 走向哪里？

最后，讓我們暢想一下。在 DevOps 運動的催化下，未來的組織可能是什么樣的？DevOps 強調(diào)通過使用共同的語言，讓不同角色能夠更緊密地協(xié)作，從而提升交付效率。而相同的目標更容易產(chǎn)生共同的語言。

對企業(yè)來說，更有意義的目標是業(yè)務(wù)目標。目前，很多 IT 組織并非以業(yè)務(wù)目標建立組織結(jié)構(gòu)，而是以職能目標建立組織部門。

為了能夠更好地完成業(yè)務(wù)目標，企業(yè)就需要考慮如何圍繞業(yè)務(wù)目標來組織資源。并沒有哪一種組織結(jié)構(gòu)是完美的，但圍繞業(yè)務(wù)目標來組織團隊通常都是適合的。

“組織墻”總會存在的，當(dāng)我們打破不同職能部門之間的“墻”，同時也會建立“業(yè)務(wù)單元墻”。只要保證這種“墻”是容易打破并重建的，那么組織就是健康的。

只有這樣，我們才能建立一個靈活而又強大的彈性組織，它由一系列小的業(yè)務(wù)單元組成，以應(yīng)對市場的發(fā)展變化。

需要強調(diào)的是，不僅僅那些直接服務(wù)于外部客戶的組織是業(yè)務(wù)單元，服務(wù)于組織內(nèi)業(yè)務(wù)單元的團隊（例如基礎(chǔ)設(shè)施服務(wù)）也應(yīng)該按其服務(wù)的業(yè)務(wù)或內(nèi)部客戶不同而作為業(yè)務(wù)單元來對待。如何定義“業(yè)務(wù)單元”是一個復(fù)雜話題，因為其與企業(yè)內(nèi)外部環(huán)境強相關(guān)。

當(dāng)我們有眾多業(yè)務(wù)單元時，這些小的業(yè)務(wù)單元之間要做到 “對齊”是一個巨大的挑戰(zhàn)，尤其當(dāng)業(yè)務(wù)單元之間存在協(xié)作時。現(xiàn)在業(yè)內(nèi)經(jīng)常提到的“中臺”架構(gòu)，似乎是對“小業(yè)務(wù)單元”相左。然而，事實上，這個“中臺”也應(yīng)該是由多個小業(yè)務(wù)單元構(gòu)成，并要高度“對齊”的。

雖然，單一個體的效率最高（因為決策與行動一體化）。但是，個體的能量是有限的，所以我們?nèi)耘f需要高效溝通，以便“對齊”。

就像技術(shù)架構(gòu)中的微服務(wù)架構(gòu)一樣，需要將很多的小業(yè)務(wù)單元高效地串聯(lián)起來，才能真正發(fā)揮這種多個小團隊協(xié)作的優(yōu)勢。如果沒有協(xié)調(diào)好這些業(yè)務(wù)單元，那么可能提升了單一業(yè)務(wù)單元的內(nèi)部效率，但整體的價值產(chǎn)出并沒有增速。

那么，如何”高效對齊“呢？一種可能的方式（并不是唯一的方式）是參考”阿米巴經(jīng)營“。日本京瓷公司是生產(chǎn)陶瓷制品的公司，是典型的生產(chǎn)制造行業(yè)。它由稻盛和夫先生創(chuàng)辦，并在經(jīng)營過程中總結(jié)出了“阿米巴管理經(jīng)營方式”。

在2009年，稻盛和夫再次出山，成功運用這一管理工具，帶領(lǐng)日航走出困境。日航是一家提供航空運輸?shù)姆?wù)性企業(yè)。

他將由生產(chǎn)制造行業(yè)中總結(jié)的“阿米巴管理”也成功運用于服務(wù)性企業(yè)，將日航30000 多名員工分成 10 人左右為一個最小經(jīng)營單位的眾多阿米巴，并讓每個阿米巴作為獨立經(jīng)營核算，激活所有員工，讓他們自己組織起來，為自己的目標工作。

要想完成這樣的轉(zhuǎn)變，必須從以下三個方面著手。一是軟件架構(gòu)，二是組織機制，三是協(xié)作基礎(chǔ)設(shè)施，如上圖所示。

由于時間關(guān)系，我就不再展開討論。在《 持續(xù)交付 2.0 》一書中完整地講述了三個實踐案例。

根據(jù)組織規(guī)模、業(yè)務(wù)目標、產(chǎn)品形態(tài)的不同，這三個案例選擇了不同的實現(xiàn)路徑。如果你對它們感興趣，可以參考《 持續(xù)交付 2.0》的最后三章。

4 小結(jié)

在不改變系統(tǒng)結(jié)構(gòu)的前提下，優(yōu)化是容易進行的。但是，優(yōu)化到一定程度以后，可能就需要尋找第二序改變，才能夠”涅槃重生“，達到更上一層樓。

本文根據(jù) DevOps 國際峰會（DOIS）2018 · 深圳站喬梁老師分享整理而成，經(jīng)喬梁老師審定授權(quán)發(fā)布。

總結(jié)

以上是生活随笔為你收集整理的乔梁：实施 DevOps 过程中的两个关键思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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