由數人云、優維科技、中生代社區聯合發起的markdown
系列 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.一、二、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 部門都提供很好的數據支撐。當把這些數據給團隊看的時候，他們就會比較客觀的瞭解本身的工程能力，從而根據自身的須要主動改進。
因此有了這些方法和實踐加上工具的支撐，百度在最近這幾年有了必定的工程效率提高，以上都是一些項目的實踐，但願對你們能有幫助。