規模 300+ 的研發團隊，怎樣保持工程高質高效？

七牛雲從最初發展到如今已經七年了，目前有 300 多名研發同窗、六大業務線：雲存儲、CDN、直播雲、容器雲、大數據、以及人工智能實驗室。而在七牛雲優秀的產品研發團隊身邊，還存在着一個負責質量管理、工程賦能、以及過程改進的重要部門——七牛雲工程效率部。

本期牛人說，由七牛雲工程效率部負責人李倩和你們一塊兒探討工程效率的問題。分享她一路以來的心路歷程，以及整個團隊從 0 到 1 的演進過程。

#01工程效率部發展歷程

我認爲組織的變革應該基於對業務和發展更有利的角度進行，並非非要有測試組、質量保障部、工程部等等。更重要的是在公司現有條件下，你能提供什麼能力，以及這樣的能力是否能讓業務更好地發展。

同時，在創業公司最大的感覺就是擁抱變化。在這個過程當中，你會發現不少事情並無爲你準備好，你要作的就是去不斷適應，不斷地尋找最大價值，提高自我。下面我爲你們簡單介紹一下工程效率部的發展歷程：

• 2014 年，工程效率部介入，當時主要負責跟進前、後端測試。這時咱們要作的第一步就是搭建完備的測試環境；
• 2015 年 3 月成立測試組，對三大業務線（存儲、數據處理、CDN 測試）進行平常質量保障。從一開始咱們就傾向於用自動化的方式解決問題，因此招聘的也都是測試開發工程師。也是從這個時候，咱們引進了基本的 CI / CD 交付能力；
• 2016 年 2 月成立質量保證部，服務於整個研發，開始寫測試服務，並完善CI / CD的能力，將 pipeline 自動化。除此以外，咱們還同時管理着公司內部平臺及工具鏈，並寫了一套質效分析平臺；
• 2017 年 2 月成立平臺服務組，並研發了效能平臺，引入容器，把容器做爲效能平臺裏最基礎的技術使用。同時，部門正式更名爲工程效率部（V1.0）；
• 2017-2018 年，工程效率部（ V2.0） 內部組織結構優化，以適應七牛業務飛速增加，爲技術體系賦能。

#02工程效率部的團隊架構

做爲一家作基礎服務雲計算的公司，咱們要幫助客戶更快、更好的提供技術能力。咱們的內部願景是：縮短優質代碼到生產上線 / 客戶間的距離。這也是工程上很是重要的一段距離。

咱們的體系主要分三大塊：**質量管理、工程賦能、以及過程改進。**雖然這裏有虛線、實線組織，但總體來講是有機的總體。咱們不但要作質量，更重要的是在有效率的狀況下，如何把質量作到最好。

• 質量管理：有專門的 QA 同窗深刻研發業務，識別質量風險，創建質量反饋閉環。同時圍繞目標不斷加深自動化程度，適配更多交互場景，大客戶。這裏主要的人員是測試開發工程師；
• 過程改進：PMO 流程管理，保障咱們整個流程儘可能簡化，並適於公司發展，適當的時候咱們會經過它來作最佳實踐傳播；
• 工程賦能：是 CI/CD 的主線，也是咱們的軸心，它讓咱們作的全部工做都能有很好的平臺化追蹤。完善優化質效度量體系，讓你們更有目標感，知道咱們應該從哪些角度去解決問題。

總結成一句話就是：工程效率主要是關注交付鏈條中研發交付環節的品控，以及效率的總體的交付能力。

#03質量意識的傳承與升級

那麼如何作到質量意識足、代碼敢交付、服務敢升級，主要有三點：

1. 工程師對質量有極致的追求。代碼和 Bug 都是人寫出來的，因此咱們會要求工程師對本身的代碼負責 —— Eat your own dog food 。
2. 內建質量的創建。內建質量決定外建質量，在交付以前的全部過程要儘可能提早，並提高內部質量。好比：單測、靜態掃描分析、集成測試等等，每一步失敗就要去修復。每走一步都要提供驗證機制，讓代碼有辦法校驗，對總體的質量負責；
3. DevOps 工程文化引入：作一件事情若是超過兩遍的，咱們就須要去思考這樣作是否真的更有效率。因此我總結了一句話：Everything is Code。

#04技術演進

這方面我主要想跟你們講一下質量小組的基本的技術實踐路徑，這是每一個 QA 同窗都要去作的，以及每一個開發同窗都要理解的。

首先，我想解釋一下爲何會有上圖這種看似 step by step 的效果。咱們的產品不少是從 0 到 一、再到 10，因此一開始咱們須要介入不少工做，而不是自始至終作同一件事。每一個技術人都要不斷進化本身，把本身的工做重心從 A 轉到 B，再到 C。

• 第一階段，提高代碼自己的質量、內建質量，咱們爲開發人員提供反饋，讓他知道哪裏作得有問題；
• 第二階段，針對產品業務，輸出 API 級測試服務；
• 第三階段，從代碼分析去提升測試的覆蓋率，基於測試覆蓋率，輔助進行精準化測試；
• 第四階段，針對服務間的依賴，作 mock 或回調的輔助測試；
• 第五階段，考慮錯誤注入，模擬故障狀況下的應對錶現；
• 第六階段，推出更多維度的檢測手段，不只是 e2e，還須要有基於業務的調用鏈衡量，服務自身健康情況等等，評估產品的每一次迭代；
• 第七階段，將各個階段的產出、總結、抽象，進行服務化，產品化輸出，以服務模式提供質量保證。

#05平臺演進

平臺演進比較重要，咱們須要考慮是否有可能把更多的東西搬上服務。同時，平臺化是服務化以後的階段 —— 如何把服務融入到整個流程中，而且被完整的管理，提供必定的工程能力。咱們的目標就是量化產品的質量和效率，提供質效分析能力，識別薄弱環節。

上圖是以服務級別或模塊級別列出來的主要功能：包括單測覆蓋數據、靜態掃描和代碼檢查、集成測試覆蓋、缺陷和事故分析、發佈跟蹤、服務探測，競品性能 benchmark 檢測和工具箱。

這是咱們質效平臺的後臺，這是其中的幾個指標，裏面有冠、亞軍之分，是一種激勵和評比。我認爲，沒有對比就沒有傷害，沒有對比也就沒有進步。咱們會把一些關鍵指標量化，也會相應推出獎勵措施。但並非獎勵冠軍，咱們會按照各團隊的成長速度進行獎勵。

工程效率平臺狹義上是 Devops 或 CI/CD 平臺，廣義上是軟件工程的信息化平臺。

• 編譯：經過 Jira HOOK 定時觸發任務，同時在 GitHub上 聲明要討論的任務，觸發系統編譯。再將構建結果 push 到容器裏，把結果 Archive 到存儲裏作備份；
• 部署：對服務進行分組，提供必定的組裝能力，讓多個服務構成服務組，同時支持實時日誌檢索，把生成的日誌打到Pandora大數據平臺；
• 測試：由於測試服務和生產服務比較相似的，因此部署方式也相似的。咱們會生成 test report ，同時讓 Log 打到質效平臺。在測試方面比較重要的一點是：和質效平臺交互產生大量的數據，每個數據都記錄下來；
• 分發：咱們針對對象存儲作分發。容器化部署會用容器平臺作發佈；物理級部署會用相應統一的位置發佈。

  

下面我和你們分享一下七牛在實踐上的結果。指向會從上圖的兩方面考慮：質量和效率。

質量方面：核心服務單測覆蓋包括上傳、下載、刪除、直播推流播放等，這些核心服務覆蓋率在 60% 以上、合規 80% 左右、pipeline 經過率 80% 以上、集成測試覆蓋率 35%；

效率方面：pipeline 構建 2 - 10 分鐘、缺陷解決率 82%+、發佈頻度每週 40+、核心服務 MTTR 在 2 小時之內。

效率方面：pipeline 構建2 - 10分鐘、缺陷解決率82%+、發佈頻度每週40+、核心服務MTTR在2小時之內。

最後，說一點本身的感悟：作正確的事情，不要給本身設限。尤爲在創業公司，你會發現有不少事要作，也許你會認爲有些事該作，有些不應作，但我認爲沒有應該與不該該，只要這件事是正確的，就必定要推進 get it down。

關注公衆號「七牛雲」 瞭解更多信息哦～