【工程實踐思考】百度DevOps提高之道

本文做者：francisk84

我是百度工程效能部資深敏捷教練--金銳，也是百度 DevOps 解決方案的運營負責人。從今天開始，我將在 開發者中心 經過一系列的文章，爲你們分享百度在軟件工程領域的思考和實踐。今天我先從百度工程效能部對提高百度軟件工程能力的實踐和思考介紹開始:

 

什麼是工程能力

 

工程是科學和數學的某種應用，經過這一應用，使天然界的物質和能源的特性可以經過各類結構、機器、產品、系統和過程，是以最短的時間和最少的人力、物力作出高效、可靠且對人類有用的東西。 --百度百科

上述定義摘自百度百科，從這裏咱們能夠看到，廣義的工程能力定義很寬泛，涵蓋了軟件，建築，機械生產等多個行業。當我在講百度的工程能力的時候，我更多提到的時百度的軟件工程能力，下面是幾年前公司內部一次會議上，公司領導層對軟件工程能力與公司業務競爭力的闡述:

 

百度如何看待軟件工程能力

百度是一家技術公司，研發工程能力的高低直接影響公司的持久創新力和公司在市場上的做爲。只有不懈追求卓越的工程能力，纔可以帶來長期的核心競爭力，才能爲每一個用戶、每一個企業客戶以及整個社會創造價值。

百度軟件研發體量
百度內部有多個業務形態萬千，團隊規模不一樣的產品線，下面一系列數據出自 2018 年工程效能部的數據統計：

從數據上能夠看到，平均每一個工程師天天要進行 3 次構建；執行 7 次以上的流水線；平均每一個披薩團隊，天天要進行一次服務的發佈。並且在這些數據的背後，是 10000 多名有着強烈的自驅意識，敢於不斷嘗新的軟件工程師。所以對於百度工程效能部來講，提高百度工程能力，是一件挑戰巨大的系統性工程。

 

百度工程能力的發展歷程

百度工程能力的發展歷程，大體經歷了三個階段, 分別是:

- 以瀑布式和 CMMI 標準爲研發模型的階段
- 以敏捷開發爲主要研發模型的階段
- 全面擁抱 DevOps，雲計算和 AI 的階段

在每一個階段，百度在軟件工程領域要解決的問題和麪臨的挑戰各異，下面我來簡單介紹一下:

瀑布式和 CMMI 階段

在這個階段，百度在軟件工程領域要解決的首要問題是: 百度的軟件研發管理對象是什麼？對象之間的關係是什麼？一個標準的，符合規範的研發流程是什麼樣的?

如今回顧起來，咱們很是感謝那個時代工程效能部門的同事，爲咱們後續的管理奠基了堅實的基礎，具體規範以下圖：

從這張圖上能夠看到，咱們當時定義了幾個最基礎的元素:

- 最小的可發佈代碼集合--模塊，以及代碼和業務的對應關係--產品線
- 服務發佈的版本關係: 線上版本和測試版本
- 圍繞發佈進行的一系列研發過程管理: 項目

當時的一切軟件研發工做，是圍繞着模塊級別發佈進行的: 每個項目在啓動的時候，RD（開發工程師）會從當前模塊基於線上的 3 位版本拉一條分支，創建一個新的 4 位版本；當開發完成後，RD 經過一個叫作"提測"的動做將構建產物傳遞給 QA（測試工程師）, QA 在測試過程當中發現的 BUG 會記錄在當前的 4 位版本上，RD 修正後從新生成一個 4 位版本號再次交付 QA 直至最終測試完成，模塊發佈上線後，更新三位版本號，作爲下一次拉取分支的基線。這樣的流程也很好的支持了當時百度的主營業務--核心搜索。

 

敏捷開發階段

時間前進到 2012 年，隨時互聯網思惟的普及，更重要的是，移動互聯網時代的到來，咱們發現: 當時百度的軟件研發效率跟不上市場競爭的需求了。2012 年 8 月，咱們作過一個統計，當時百度單個模塊的發佈週期平均值是 21 天，而當時小米號稱每週迭代。所以，當時咱們要解決的首要問題是如何縮短模塊的發佈週期。

基於這個目標，咱們引入的敏捷開發的概念，弱化項目的概念，強調產品的迭代。同時將原有的工具按照研發的不一樣階段，拆分紅三個獨立的產品: 負責項目和產品管理的 icafe，負責代碼和協同開發的 icode，負責持續交付的 ipipe，造成了目前研發工具鏈的雛形。咱們也創建了百度的敏捷教練團隊，引入了一批又一批業界優秀的軟件工程人才，將敏捷開發的理念帶入到產品線中。如今 DevOps 和敏捷圈中的各路英才，有至關一部分都曾經在百度工程效能部任職

通過 4 年的努力，截止 2016 年，咱們將百度的模塊發佈週期從 21 天，縮短到不到 6 天的樣子。敏捷開發已經成爲百度的主流研發模式，95%的模塊從 SVN 遷移到了更加適應互聯網研發模式的 GIT 上，咱們發佈了百度內部的研發方法論專輯: 百度方法+。

反思這個階段，咱們發現：

- 雖然總體的交付週期縮短了，可是團隊的交付能力並無特別明顯的提高
- 一部分團隊在專家實施改進並撤出以後，出現了不一樣程度上的倒退
- 公司內部平臺林立，技術上重複造輪子的現象嚴重

同時，DevOps，雲計算，AI 成爲主流的技術，咱們面臨着更大的挑戰:

 

百度工程能力的提高策略

前面鋪墊了這麼多的內容，終於進入到咱們今天要講述的內容主體: 當雲成爲主流 IT 架構，以模型訓練爲表明的 AI 開發興起，DevOps 成爲軟件研發的主流思想時，百度工程效能部如何繼續帶動百度工程能力的提高。

關於總體提高的策略，咱們能夠用下面一張圖來表示：

 

能力策略--人

首先，咱們來看一下人的方面，工程能力提高的根本仍是人（工程師）自己的工程素養提高。即便咱們有好的流程、方法和開發工具，若是開發者自己的能力和工程素養不夠的話，工程效率也會很是低。

爲了提高工程師的工程素養和工程能力，咱們作了一些實踐。例如招聘時，咱們必定招優秀的工程師。新人入職以後，咱們會爲新同窗提供工程師能力培養和文化建設的工做坊，這也咱們一直在作的事情。工程師入職後，會有「碼神訓練營」，這個訓練營除了介紹編碼的規範及開發流程、工程實踐以外，還會讓你們在工具平臺上實際操做，自主開發一個示例產品，促進你們在短期內瞭解百度工程開發的流程和規範，創建工程規範意識。除此以外，公司內還有不少培養工程師文化的項目，好比 Hackathon ，還有 Good coder、Excellent Coder 認證等。

 

提高策略--數據篇

和 16 年之前最大的變化是，咱們將**數據**也歸入了總體的提高策略中。
在 DevOps 的理念中，有一個很是重要的核心理念: 創建反饋閉環。咱們認爲在軟件研發過程當中，從 RD 天天的拉取分支--coding--提交代碼，到模塊測試--系統測試，最終到服務發佈，產品更新。都應該創建不一樣的閉環，而在每一個閉環中產生的數據，應該以最高的時效性反饋給研發/測試/運維人員。而且不斷的引導用戶去使用數據，信任數據，最終經過數據的驅動實現團隊工程能力的不斷提高。

而在以往，這些數據在生產出來以後便被束之高閣，只有在按期彙報的時候才被拿出來使用，爲了改變這個現狀，咱們首先明確了百度軟件研發的一系列閉環：

從上面的圖中能夠看到，在咱們的治理思路中，整個軟件研發的過程被劃分紅 4 個閉環：

- 開發閉環: 起始於 RD 創建 Feature Branch，終結於分支合入當前的 release branch，開發閉環持續時間以天爲單位，一般是 1-3 天
- 迭代閉環: 起始於每週的開發計劃更新，終結於當前的 release branch 經過驗收測試，迭代閉環持續時間以天爲單位，一般是 5-10 天(1-2 周)
- 項目閉環: 起始於一個 release plan 的啓動，終結於當前的服務/產品上線後業務數據的 review，其中對於一部分產品來說，項目閉環=迭代閉環；而對於移動端開發來說，一個項目閉環包括了多個迭代閉環。項目閉環以周爲單位，一般是 1-3 周。
- 產品閉環: 結合 OKR 或業務階段性目標，起始於目標的拆解和制訂，終結於階段性業務目標的 review。產品閉環的週期比較長，每每以月爲單位。

 

在以上閉環中，咱們認爲下列數據是須要被相關人員關注並使用的：

 

- 開發閉環: 代碼衝突；CodeStyle；代碼漏洞；CodeReivew 的反饋；單元測試的結果，覆蓋率；模塊測試的結果，覆蓋率；流水線執行結果；流水線執行時長；需求的開發進展；PM(產品經理)功能驗收的結論，沒錯，在百度咱們提倡產品經理對每個用戶故事進行驗收，而不是對迭代進行驗收。
- 迭代閉環: 分支的集成進展；系統測試結論；非功能性測試結論；測試中發現的 BUG 以及修復進展；團隊的迭代速率；
- 項目閉環: 線下 BUG 的修復進展；系統測試結論；非功能性測試結論；研發進度的累積圖；線上服務的穩定性；上線後的業務效果；上線後用戶的反饋；回顧會議的結論；
- 產品閉環: 階段性業務效果；產品下階段的規劃；技術下階段的規劃；團隊交付的散點圖；團隊工程能力地圖；

這麼多的數據，咱們是如何將其一一呈如今整個研發團隊的視野中的呢？這就離不開工具的貢獻了: 咱們在 17 年，自建了研發數據倉庫，前面提到幾大研發工具平臺: icafe, icode, ipipe，以前是每一個產品保存本身的數據，建了數據倉庫以後，咱們將數據如下面示意圖的形式組織在一塊兒，造成了從需求到發佈的完整研發數據鏈：

另外，除了這些基礎數據以外，有大量的測試結果，覆蓋率數據是如何被記錄下來的呢？這就得益於持續交付平臺 ipipe 的插件式架構設計：

百度內部有幾十個不一樣類型的測試，發佈，環境管理工具。爲了讓百度內部的用戶更好的使用這些插件，iPipe 平臺改善了底層的架構設計，使這些工具能夠經過簡單的改造接入 iPipe。作爲改造的一部分，這些工具須要經過統一的數據格式將本身生產的研發數據導入到研發數據倉庫。這樣，研發和測試人員只須要關心本身的平常工做，而數據很天然的就保留了下來。

接下來，數據是怎樣應用的呢？首先最頻繁的應用在流水線的執行結果中：

這是我在內部代碼庫提交的一次提交記錄, 在圖中看到咱們配置了一條簡單的流水線，只分爲編譯和測試兩個階段，如今展現的是編譯階段的全部 job。如圖所示，用戶能夠很是直觀的在流水線上看到每一個 JOB 的執行結果。一旦有錯誤發生，iPipe 會經過郵件，即時通信工具向用戶推送消息。同時，在展現結果的同時，QA,RD 也能很是方便的觀察每一個階段的執行時長，方便流水線的優化。

除了在流水線中應用，咱們根據產品，團隊，工程師的不一樣維度，將數據概括整理:

產品維度：工程能力地圖

這即是工程能力地圖的主頁面，如圖所示: 工程能力地圖以產品線(多個代碼庫)爲維度，按照不一樣技術類型(Server, App, SDK)的代碼庫分類, 將產品線在整個研發過程當中對管理，技術實踐的採納狀況進行記錄和評分，而全部的記錄都來源於插件的數據錄入。也能夠說，頁面上每個色塊中的實踐，背後都對應着一個標準的實踐工具。數據天天進行更新，而產品線的研發經理，測試經理，研發總監根據工程能力地圖上數據的變化趨勢便可瞭解本身團隊工程能力的改進進展。在百度內部，大多數產品線在創建本身 DevOps 實施目標時，已經將地圖上得分的提高作爲重要參考。

 

團隊維度：交付週期散點圖

 

交付週期散點圖顯示的是一個團度隨着時間的推移，交付週期的變化趨勢。怎樣解讀這張圖表呢？橫軸是時間軸，縱軸是交付週期(天爲單位)，圖表上的每個點都表明了一張需求卡片(統計粒度可自選)從創建到上線的確切時間流逝。從這張圖上，咱們能夠解讀到如下信息：

- 交付週期的標準差: 在圖上用淺藍色陰影顯示，陰影面積越小，表明該團隊的交付週期越穩定，可預測性越高
- 交付週期中位數的移動趨勢: 在圖上用綠色的曲線代替，該曲線表明了交付中位數的變化趨勢，曲線越走低，表明交付週期的不斷縮短
- 團隊的交付模式: 這個解讀頗有意思，從上面的圖咱們能夠看到，在 5 月 19 日以前，該團隊進行了屢次不斷的發佈，能夠認爲是在持續的交付價值；可是到了 7 月 19 號以後，咱們會發現交付週期較長的項目/需求開始出現，發佈的時間點相對集中，能夠認爲團隊在 5 月到 7 月集中作了幾個大型的功能，並在 7 月下旬進行了集中的發佈

 

工程師維度：工程師我的畫像

 

如圖，這是展現在代碼託管平臺 iCode 上的某位內部工程師的研發活動數據，上半部分表示了該工程師的提交頻次，每次的代碼提交量；下半部分的數聽說明了具體的量化信息。這個圖表是和咱們內部所提倡的工程師文化是密切相關的。什麼是百度工程師在工程方面應該作的事情，那就是持續的提交代碼，而且積極參與代碼的評審工做。每次工程師在申請晉級的時候，技術委員會會直接查看該工程師的這個頁面，並作爲晉級的重要參考。咱們常常說，是牛 X 的工程師就把我的頁面亮出來。

能力策略--技術篇

平臺化治理

爲了解決前文提到的技術重複造輪子問題，提高技術的複用，咱們也進行了百度內部的平臺的建設和治理

平臺建設包括平臺複用和源碼複用這兩方面。在平臺複用方面，咱們梳理出公司內部的幾百個平臺，將這些平臺劃分紅若干個類別，每一個類別都成立一個 TOC 組織來負責規劃這類平臺將來的發展。發展的目標就是讓這類平臺可用性增強、複用度提升，讓平臺自己的能力加強，以便讓每一個業務方可以更快速地使用平臺去搭建本身的業務，提升工程效能。

 

內部開源

上面介紹平臺複用會帶來一個問題：若是多數平臺逐漸收斂成少數平臺後，許多需求都會涌向這些平臺，會致使平臺研發團隊不能按時、高質量完成全部的需求，從而使研發效率降低。那麼咱們怎麼在平臺化的基礎上去作更好的工程複用呢？

那就是源碼複用。在代碼管理平臺（iCode）上，咱們作了內部開源功能。在平臺化治理的過程當中，平臺是否可以達標，有一個考察點是它能不能實現內部開源。若是一個平臺的 API 已經對外開放，而且又作到了內部開源可以讓其餘團隊貢獻代碼協做開發，咱們才認爲它是一個優秀的內部平臺。

 

C++的依賴治理

百度 C/C++模塊開發採用跨模塊依賴的形式，其中 97%爲固定版本依賴(表現爲 Depend on TAG 和 Depend on BRANCH:VERSION 兩種形式，本文統一使用 Depend on TAG 表示)。固定版本依賴會致使嚴重的版本碎片化問題，兩年前咱們作過一個統計: 百度 top 200 的基礎庫，在用的大約 5000 多個版本。

版本碎片化問題背後，是嚴重的技術債務: 維護基礎庫的同窗很難保證不一樣版本間代碼的兼容性，業務方爲規避版本不兼容的問題不肯意升級依賴模塊版本，致使基礎模塊發佈新版本後，三個月內只有十分之一不到的團隊主動升級。如此一來，一方面在基礎庫維護上浪費了大量沒必要要的人力，另外一方面，大量的業務線也沒有辦法享受基礎庫升級帶來的好處。

參考 Google 的 Head 依賴模式，即全部的類庫引用方，都直接引用類庫的 head 標籤。考慮到咱們內部改造的成本和業務方的穩定性，咱們決定推出 stable 模式--即每一個類庫維護一個 stable 標籤，全部的引用方都來引用 stable 標籤，基礎庫的維護團隊將基礎庫的更新發布到 stable 標籤上，這樣保證了基礎庫的穩定性，也極大的收斂了基礎庫的版本數量，減輕了團隊負擔。

百度工程能力的標準產出
百度 DevOps 產品解決方案--百度效率雲

2019 年 5 月, 咱們正式將百度內部的研發工具鏈對外輸出，成爲百度智能雲的子產品，並命名爲百度效率雲。效率雲包括內部的三大平臺(iCafe, iCode, iPipe)，並與智能雲上的容器引擎，微服務平臺一塊兒，支持雲原生 DevOps 的場景。目前產品處於免費試用階段，歡迎你們試用

百度效率雲首頁

百度工程師手冊

以上就是關於百度工程能力提高的介紹，歡迎你們提出建議和意見。

 

對於雲原生 DevOps，AI 服務開發感興趣的同窗，能夠關注"效率雲官方公衆號"，咱們會按期發佈產品的最新動態, 以及百度工程實踐的思考和經驗

再次感謝你們對百度軟件工程技術的關注

 

 

==========================

本篇文章轉載自:"百度效率雲官方公衆號"

歡迎搜索關注

 

原文連接地址：https://developer.baidu.com/topic/show/290270