由數人雲、優維科技、中生代社區聯合發起的

系列 Meetup 《 DevOps&SRE 超越傳統運維之道》

先後在深圳、北京舉行過兩場

7 月 15 日上海站，敬請期待

▼

王一男老師在《 DevOps&SRE 超越傳統運維之道·北京站》活動中，結合百度的實踐，講述落地 DevOps 時，首先要拆掉業務→開發→測試→運維中間的這三面墻，一起來看一下吧！

數人雲友情提示：前方全文約 9000 字，且不含標點符號~建議先收藏~

效率=工具+方法+實踐的結合

最近有一篇比較火的文章大概說 DevOps 不是工具的堆砌。現在出現一種概念：將研發流程自動化就是 DevOps，個人不敢茍同。在百度內，研發效率的提升除了工具之外，更多是這些工具與方法以及一些實踐的結合，來共同支撐研發效率的提升。

再往前一步，在一個大版本開發的閉環中，產品如何更好地管理、需求如何更好的確定，百度也總結了一些比較好的實踐。這些實踐一般都方法和工具的集合，同時在實際項目中，將其落地實踐，最後歸納總結並分享出來。所以並不是僅有工具就能把所有事情都做好，但沒有工具也很難做到。

任何事情想要達成，都依賴於人、方法和工具的結合。

任發科老師也提到：最好不要做一個大而全的工具。之前百度的工具也曾是 All in one 的，那時候發現雖然一個工具能解決所有問題，但一線同學感覺工具特別重，不靈活。

當公司的規模或者團隊逐漸擴大以後，就會發現工具適用於所有團隊，讓工具去適應團隊的需求也不方便，所以在幾年前百度就把 All in one 的工具拆分成了三個更專註的工具：

項目管理或需求平臺 iCafe，它主要做需求管理和項目管理，目標用戶是項目管理的角色：產品經理以及一些研發團隊的 Leads。

代碼管理工具 iCode，全公司所有工程師都在使用 Git 的時候會遇到 Git 規模化的問題，一萬多名工程師每天頻繁的向這個 Git server 中提交代碼，此時會遇到一些性能問題，所以 iCode 工具首先要解決的就是 Git 規模化的問題。同時還要保證萬人研發的“快”和“有序”。

持續交付平臺 iPipe，它負責把從把從代碼到發布到部署的過程通過可視化流水線串聯起來。

軟件交付過程中的三面墻

當 DevOps 的概念逐漸被了解後，大家就一直在致力於實現持續交付，怎樣能讓業務的想法、或產品經理的想法、抑或是客戶的需求能快速通過開發和測試，並能快速發布上線，真正做到持續交付？

其實交付的不僅僅是產品功能，更是交付客戶的價值，怎樣能做到這一點呢？要想達到持續交付的這個過程，團隊之間的“墻”要拆掉。

DevOps 在拆墻，敏捷研發實踐也要拆墻，到底有幾面墻呢？將它畫了出來，在一個團隊裏面，無論團隊規模或大或小，即便角色分開後，這個墻可能也還存在。

主要能感到這三面墻（上圖）的存在，業務和開發之間有一面墻，開發同學可能會有非常深刻的認識。開發和測試之間是有一面墻的，有一些團隊可能開發測試間合作比較緊密。但在一些大的產品線上，開發和測試的墻還是存在的。

最後的是測試和運維的墻或叫開發測試團隊和運維的墻。今天談的 DevOps 是要重點拆除的墻。但前面的墻是怎麽被拆掉的呢？前面兩位老師講到：用精益的方法、敏捷的方法去打通前面的墻。

如今大家都在學習 DevOps，可是實踐 DevOps 真正解決了最重要的問題嗎？個人表示懷疑。

都在說 DevOps 有一個好處是能讓運維自動化、可視化，使得工作更高效，但是 DevOps 只是為了解決運維的問題嗎？

讓價值能快速地流動到客戶那裏。如果想讓價值從前至後快速流動，必須要把前面的墻打掉，若業務和開發那面墻、開發和測試那面墻仍舊存在，即便打通了測試和運維這堵墻也沒太大意義。以下有一組數據來證明觀點，其實關於 DevOps，國內可能尚未準備好。

真的只剩最後一面墻了？

這是 CSDN 在 2016 年對國內敏捷方法覆蓋的一個調查。假設精益、敏捷方法能夠把前面的兩堵墻打掉，在 2016 年的國內，用 Scrum、用看板、用 RUP 這種方法和實踐的企業及團隊加起來不到 30%，更多的國內企業或團隊一方面是在自己定制的流程，用瀑布的在 20%左右，所以一個結論——去年國內敏捷方法、實踐的覆蓋率也就 30%左右。

大家會看到企業裏面有一部分團隊是在嘗試使用敏捷方法，但整個企業還處在所謂“敏捷轉型”的過程中。

再對比一下歐美 2016 年類似的一個統計——

• 首先統計顯示 8%的企業或者是團隊全部使用了敏捷的方法，則裏面所有敏捷的方法涵蓋的實踐比較多，可能只要有一些敏捷實踐的都算。

• 其次 32%的企業和團隊超過了一半的團隊在用敏捷的方法和實踐。

• 最後 58%的是什麽呢？就是這些企業內部有少於二分之一的團隊在使用敏捷實踐。只有 2%的沒有用敏捷的方法。 所以個人感覺現在國外為什麽都在講 DevOps，可能是因為他們的敏捷已經做到了一定程度，前面兩堵墻已經拆的差不多了，只差最後那堵墻了。

實現持續交付的道路上，是否先 DevOps，應該看前面兩堵墻有沒有打通。

以上是個人觀點，但是我們一起學習 DevOps 包括去實踐，這是沒有問題的，因為它確實能提高組織的效率，並且能提高交付的能力。是否要先去做 DevOps 實踐，要從整個價值交付的角度來看，在百度不會強調用敏捷的方法、用 DevOps 的實踐來改進業務團隊，而是要從價值角度出發，需要依次把這幾面墻打掉，所以總結的方法和工具實踐只要能把墻拆掉，就是管用的。

打通業務到開發的墻

下面簡單介紹下有哪些比較好的實踐幫助拆墻，第一個比較好的實踐是需求管理。

當產品經理決定要做一個功能，首先要寫一篇需求文檔，然後把文檔交給開發同學。寫需求文檔有各種各樣的方法，如寫個 Word 文檔、或者用 Excel 來管理多個需求點，或者在系統中錄入一個個需求卡片，其實這都是常用的方法。

寫 MRD 的過程非常痛苦，因為研發同學基本不看，他們更希望你當面講清楚。寫得越長，他們越不願意看，寫得越短的話，他們覺得你幹脆給我講講就好了，所以總在自問，為什麽要寫個文檔？ 一直在想怎樣能更好地把需求管理起來，其實寫文檔目的是讓產品經理的想法快速進入到開發同學的腦海裏面，讓大家把產品的想法對齊了以後快速進入開發，所以怎樣能讓這個過程更高效？

下圖是溝通成效和溝通方式的關系，左下角是溝通方式最“冷”，溝通成效最低的，就是 Paper，文檔。說明用文檔的形式來傳遞思想、傳遞需求的溝通效率是最低的。

什麽樣的溝通方式效果最好？右上角是 Face To Face At Whiteboard，大家面對面的在一個白板面前溝通，這種效果是最好的。這也就是為什麽現在很多的研發優秀實踐大多是把這些流程、方法可視化出來，在看板上面對面溝通。

既然用文檔來進行需求傳遞效率最低，那麽，用什麽樣的方式能更好地管理和傳遞需求呢？一種比較好的方式就是——用戶故事地圖。這種方法把需求拆成一個一個用戶故事，並且讓所有的用戶故事在一個看板上能全部看得到。用戶故事地圖的方法介紹有一本書，書名就是《用戶故事地圖》。

很多時候，習慣用一個 Story 的列表排列需求優先級，我做產品經理時，感覺這種排列需求優先級的方法不太靈，會發現排出的需求分散在產品的各個板塊上，沒有連成一個完整的用戶體驗，用戶看到每次產品更新的功能，卻不知道產品到底升級了什麽。

用戶故事地圖能夠很好地解決這個問題，它一般分為三層結構，上面兩層從左到右用來把產品的骨架梳理出來，如產品的一級模塊、二級模塊。產品經理在寫需求文檔時會寫 1、1.1、2、2.1。有一個比較好的實踐：如果這個產品是一個用戶類的產品，比如一個手機 App，那可以從左到右把用戶的體驗進行排序，然後可以把詳細需求點拆到更細的顆粒度。

需求在用戶故事地圖上拆分以後——

• 首先，最下面層級的需求顆粒度基本上是一個 Story 的大小。這樣，研發同學比較願意接受大小顆粒度的需求。

• 其次就是把需求平鋪在看板上，能夠可視化整個產品的全貌。

• 第三點對產品經理的幫助，可以方便地排列需求的優先級。

• 最後是排開發計劃，無論是從精益的角度還是敏捷的方法，大家都認為最小、可用的產品需求集合是最優先要開發且驗證的，在用戶故事地圖上做一個橫向分組，分組內的需求最終連成一個完整的用戶場景，並且可以快速的開發出來，這就是 MVP。

以上就是用戶故事地圖在需求管理方面的實踐。

現在，用戶故事地圖做成了工具，放在百度效率雲，越來越多的團隊產品經理不再用 MRD 文檔來管理需求，使用故事地圖和研發團隊溝通，能更高效地把需求快速傳遞給研發，工具的好處就在於不受物理條件限制。過去做用戶故事地圖的時間，讓大家在墻上貼便簽，最後發現便簽不夠用或場地不夠大，所以這個實踐用工具做比較好。工具內能記錄下產品每一個版本的演進，不用考慮卡片數量和場地限制。

打通測試到開發的墻

第二個實踐是快速地做計劃。嚴格的 Scrum 流程，要求必須一個一個叠代去做。現實中有許多團隊做敏捷開發其實都有自己的開發節奏，除了做叠代，上層還有版本計劃，版本上層可能還有裏程碑計劃。所以工具並沒有限制必須采用哪種計劃的組織方式，而是大家可以很靈活計劃的層級結構，方便把計劃做的卡片拖拽到計劃中，並且能很方便看到每一個計劃裏面每人的工作量以及計劃總體的工作量。有了這些功能的配合，就能讓這個計劃做的更快速以及更合理一些。

計劃完成後要做進一步追蹤，之前提到，好的溝通實踐是大家共享一個看板把項目中的工作呈現出來。百度公司現在基本上都使用百度效率雲 iCafe 工具中提供的電子看板方式，開站會時打開這樣（上圖）一個板子，就能知道進度和風險。

邱戈川老師提到燃盡圖挺難畫的，因為在線下用卡片的形式做看板，確實很難。但用工具就能很方便計算並畫出燃盡圖，它能幫助我們看到很多項目中的風險和問題。

當實踐時首先要有這樣的意識：怎樣把質量提高？大家都認為質量不應該由測試來保證，而是應該由開發同學自己搞定。其實在許多外企，如谷歌、亞馬遜等，測試角色更多的是提高自動化測試能力，基本的質量保證大多是由開發同學來完成的。百度也是這樣學習和實踐的。

怎樣讓產品的質量做的更好？比較深刻的一點是開發同學自己保證質量，但是僅僅說這句話去告訴每一個開發同學，請你自己來保證質量。這仍不夠，還得需要有工具保證這個流程或者保證這個思想的實踐和落地，所以在百度效率雲中 iCode 的這個產品上做了一些比較嚴格代碼質量保證的功能。

首先是代碼提交前的檢查。研發同學不能直接把代碼提交到一個分支或者一個主幹中。在提交代碼以後，代碼工具先自動生成這樣一個評審單，上面首先要做的是自動檢查編碼規範，如果這次提交的代碼沒有滿足公司的編碼規範，那是不允許繼續提交的。

構建流水線被越來越多的 DevOps 提倡，其實它也是保證質量一個非常好的實踐。從前提交前構建流水線可能是在雲端編輯一下即可。現在越來越多的研發團隊，提交前的構建流水線做的越來越豐滿，除了編譯，還有自動化測試，包括單元測試，功能測試，甚至說集成測試，都得在提交前先跑一遍，保證這個代碼提交前把完整的自動化測試運行完。

一些優秀的實踐已經能夠做到 Review App，就是說真正能發布出來，研發同學自己在這個 Review 環境上去看運行得到底怎樣，直至沒有問題。

此時再做提交前的最後一步：人工代碼評審。

每次代碼提交後，僅運行自動代碼規範檢車和自動流水線還不能根本上保證代碼質量，需進行人工評審，必須由同行來給出這次代碼提交的評審結果。由嗲馬褲的 Owner 總和分析這段代碼實現了哪個需求，解決了哪個 BUG 以後，覺得沒問題了，打出評審通過，最後這次代碼提交才真正進入到公司的代碼庫內。

這些代碼開發實踐，能夠有效保證代碼及整個產品的質量。並且由於有了研發工具的支撐，現在百度每位工程師每次提交代碼，都能嚴格遵守整個規則。

一次代碼提交的質量保證是單人的視角，但是如果團隊擴大，如何保證不同類型的產品、團隊能夠快速有序的開發？像一些業務的核心團隊可能有兩三百人，他們每天都要提交代碼，此時如何能更好的協作，怎樣更好去保證質量，確實是一個問題，所以說就需要代碼研發的工作流。

其實代碼的工作流對於大家來說應該都非常熟悉，如主幹開發的工作流，分支開發的工作流。但是僅在團隊內部口頭約定有這些工作流，效果不會太好，因為這是團隊內部的約定，一旦新人進入不知道工作流的事情，可能就把重要的代碼分支沖掉了。所以團隊執行代碼工作流時更好的方式還得需要工具來保障。

iCode 有這樣的功能——在代碼庫管理配置裏面，可以開啟此代碼庫的工作流，開啟後就強制要求代碼庫按照工作流去提交，如此設置以後，無論團隊有新人進入後者團隊有人忘記工作流的事情，研發同學都只要提代碼即可，因為入托提交方式不滿足工作流的要求，代碼是無法正常提交的，同時 iCode 會提醒該如何正確提交。

做代碼提交前的嚴格檢查，加上團隊代碼協作工作流，基本上能保證讓開發同學提交的每一行代碼都是經過比較嚴格的質量保證。如此，測試同學就能更好的去專註於一些自動化測試工作。

前兩面墻基本上都打掉了，我們終於到了 DevOps 要打掉的這麽墻。

打通測試到運維的墻

DevOps 要打掉的這面墻，從前面往後看，就是前面這些團隊看運維同學：運維要求是穩定的，而且不能隨便變化，這樣就不能滿足快速開發的要求。若從後往前看，就是運維團隊往前看，會如此想：測試測的不太好，上線以後總出現問題，質量無法保證，讓運維如何上線？

另外運維排期緊張、上線存在等待，好多工作需要手工部署，比較容易出現人為錯誤，故而這都是現在 DevOps 要解決的問題。

首先用流水線的方式把整個軟件開發流程串起來、從代碼編譯一直到發布上線 iPipe 這個工具的特點在於流水線可以分成多個階段，階段裏面可以設置多個任務，任務既可以並行執行，也可以串行執行，如此，流水線配置也就非常靈活。有了這樣一個端到端持續交付工具框架以後，測試就能把自動化測試掛接到流水線上，用自動化的方法來保證整個產品的質量。

為了更好的指導自動化測試工作，QA 同學們做了自動化的測試分級。

測試會把自動化測試分成多個級別，根據不同的測試框架、方法、腳本能夠對應不同的測試級別，再把不同級別的測試腳本掛載到 iPipe 流水線上，此時大家看到的流線如下圖：

在流水線上，代碼編譯後，經過單元測試、系統測試、性能測試，就會到一個檢查點，如之前任發科老師所說，這條流水線不完全自動化，會有一個或多個檢查點。並不是每一次提交都要自動上線，而是說可能挑選一次或者幾次，最後認為這次功能已經比較完整，然後手動驗收測試執行，完成後再去執行後面的任務。

iPipe 讓流水線可視化，它能把從開發到測試、發布、再到最後的部署都可視化，可以使團隊中的多個角色的信息共享。通過這樣一種“半自動”流水線及可視化的方法就能夠有效打掉運維和開發和測試之間這堵墻，因為流水線可視化把這些信息串聯起來了。

iPipe 工具的思路，就是把各種各樣公司內部的、為外部的優秀工具能力都集成上來。測試過程中可以接入多種測試工具、環境資源管理工具，發布時可以對接公司運維部門的多種部署和監控系統。

如今都在學習 Docker 技術，這是百度在 iPipe 上的一個用 Docker 發布和部署流水線例子，編譯完成以後就自動部署鏡像，可以去走準入測試、鏡像轉推、發布。其實把更多通用的功能掛到流水線後，就看每個團隊需要什麽，靈活地配置流水線，幫助團隊更高效地持續交付。

DevOps 帶來了另外一個技術概念是微服務化，目前百度很多產品項目都開始實踐微服務化，那麽流水線及 DevOps 的工具怎麽能夠幫助團隊去做多模塊發布或者微服務的發布和部署？

iPipe 采用了這樣一種可視化的方法，左邊都是每一個代碼庫微服務模塊的版本，然後流水線自動將它集合在一起，去測試、發布、部署。集成的流水線確實是 DevOps 工具的一個重要功能。

度量與改進實踐

剛才講的是如何拆墻。但墻是否存在、改進後有沒有被拆掉，需要大家的一個評判。如果沒有一些數據的支持或沒有一些可視化展現，就很難了解墻是否存在，更不知是否被打掉。所以在整個研發工具的角度，除了做這些工具意外，還要做一個事情就是數據的積累和度量展現。

百度效率雲中，需求管理平臺 icafe、代碼管理平臺 iCode 和持續交付平臺 iPipe，它們的數據是完全打通的，打通後可以看到一個需求產生了多少代碼，做了幾次評審，評審市場，以及需求最後發布到哪個版本上、發布到哪個環境上。這些信息都是可追溯、可視化的。

有了這些研發數據後，在後臺做了一個研發數據中心，把所有研發數據全部匯總到一起，做一些研發數據的分析。

目前主要分析一些有助於團隊持續改進的基礎數據，做一些對比數據，比如現在看到的就是一個團隊完成一個需求的平均周期，用散點圖、累積流圖看。

舉例子，這是我們的項目團隊從開發到上線的交付周期的數據，每一個點表示一個 Story，縱坐標表示此 Story 停留的市場，橫坐標表示它在什麽時間完成的。這個綠色線顯示 Story 的交付周期在縮短，說明團隊交付 Story 的速度是越來越快的。具體為什麽會快呢？哪兒變快了呢？或者說過去哪兒慢呢？通過數據分析我們發現有一個測試等待狀態的時間，原來是非常長的，大概是 10 天，有了這個數據才能知道——開發和測試的這面墻是存在的。這面墻通過我們不斷的努力打沒打掉呢？最後發現打掉了，測試狀態等待時常降到了四五天左右，整體交付率有明顯提升。

總結

所以說怎樣去拆墻？有沒有數據來證明墻的存在以及墻被拆掉？這是工具能帶來的便利，如果手中工具是第三方開源工具搭建出來的，也要思考怎樣把這些研發的數據匯集到一起做數據的分析。

此外，之前提到分級測試在公司各個產品線做的如何？如果想真正 DevOps 起來，就得先把自動化測試、分級測試做了。做了以後還會問做得如何？誰做得好？誰做得不好？百度也有這些數據幫助團隊了解它們的自動化測試完備程度。每一個團隊或者每一個大的部門的測試能力數據，像紅燈修復時長，測試完備度等，QA 部門都提供很好的數據支撐。當把這些數據給團隊看的時候，他們就會比較客觀的了解自己的工程能力，從而根據自身的需要主動改進。

所以有了這些方法和實踐加上工具的支撐，百度在最近這幾年有了一定的工程效率提升，以上都是一些項目的實踐，希望對大家能有幫助。

百度王一男： DevOps 的前提是拆掉業務-開發-測試-運維中間的三面墻