產品發佈過程演進——移動貼吧分級發佈實踐

摘要

爲了達到「在產品發佈過程當中，經過及時有效的發現和控制新引入線上缺陷的影響範圍，保護用戶體驗，提高上線質量」的目的，咱們在吸取和借鑑Facebook灰度發佈等技術的基礎上，探索出符合產品線現狀的「分級發佈」方案，並在移動貼吧產品線的實施中驗證和改良。本文主要介紹貼吧分級發佈的背景、方案、實施過程、實施效果和後續展望。

 

1、             背景

做爲貼吧這樣上億PV的產品線，一旦有bug遺留到線上，影響的將是成千上萬的用戶，對產品形象有很大的傷害；對工程師來講，在各類高優先級的修復項目間疲於奔命，也在必定程度上挫傷士氣，下降了效率。

那麼有沒有一種方法可讓咱們「在既有的開發測試水平下，更快發現線下測試難以找出的bug，以有效控制產品缺陷的影響範圍，提升產品質量呢？」

 

名詞解釋：

分級發佈：在本文中是指把產品發佈過程劃分爲多個級別，每一個級別限制必定的流量和用戶範圍，並在每一個級別對產品進行部署和驗證的迭代過程。

TIP: Test In Product，即對線上產品進行驗證（功能、性能等），本文特製對發佈過程當中的線上產品進行驗證。

2、             需求和目標   

2.1.  需求概述

目前大部分產品線的發佈方式是：一股腦把全部代碼發佈到線上機器集羣，而後再由QA進行線上驗證。其實代碼也是分節點逐步部署的，但RD、QA都沒法把請求命中到部署新模塊的機器進行驗證，RD一般只是在期間觀察下錯誤日誌，而這種方法很難有效發現線上bug，所以分節點發布其實對於控制質量風險也沒有什麼意義。

爲了能對發佈的代碼作到內心有底，工程師們但願找到一種方法，可以在產品沒有徹底發佈前進行有效驗證，驗證服務正常後再擴大部署的範圍。

咱們下文的「分級發佈「方案，既是脫胎於這麼樸素的需求。

2.2.  需求詳述

在對Facebook灰度發佈等業界比較領先的發佈方案進行了深度調研以後，結合自身的特色，咱們擬定了貼吧「分級發佈「的需求。

從上文能夠看出，要作到分級發佈，有兩個關鍵的過程：

一、  首先要能作到新產品能夠分紅多級逐步發佈到線上

二、  而後就是對於新發布的產品，可以在線上進行及時有效的驗證

 

分級發佈在移動貼吧產品線實施的需求以下所示：

一、  分級流程：發佈過程分爲對內發佈、小流量發佈、全流量發佈三級

二、  分流層次：只經過Webserver實現PHP UI層次的分流

三、  機器維度：對內1臺UI機器，小流量1組x臺UI機器；對WAPUI單機羣劃分

四、  流量維度：對內發佈環境只有內部流量，小流量環境爲內部流量+線上流量

五、  時間窗口：做爲發佈驗證的必要條件，須要在相鄰兩級之間有約10分鐘的暫停時間；爲了避免影響上線效率，C級項目總髮布時間須要在半小時左右

六、  質量保證應用：以線上自動化和監控爲主，人工check爲輔

3、             貼吧分級發佈方案

從質量保證角度出發，和傳統的線下測試相比，分級發佈帶來了什麼呢？

分級發佈就像放慢鏡頭同樣，把以往一次性的發佈過程拉長了，系統地切分紅了多個階段，每一個階段控制了發佈的範圍，並能夠單獨進行驗證。

拉長的發佈時間，爲發現和消滅bug帶來了可能性；

而分級發佈的過程，還帶來了：

l  真實的環境：真實線上環境的功能驗證（自動化、手工）

l  真實的流量：真實流量下的性能監控

l  真實的用戶：核心用戶衆測（由於管理成本及時間週期暫未採用）

這些特性是線下測試沒法得到的寶貴資源，也由於缺少這些資源，即便擁有很是有經驗的研發和測試工程師，也不能完美的控制線上缺陷。

3.1.  整體架構

要實現分級發佈，須要多個平臺和系統的配合，以下圖所示：

1)         上線平臺：實現新代碼的分級部署

2)         TIP平臺：部署完成後，驅動線上測試工具，驗證每級服務是否正常

3)         分流系統：對測試流量和線上流量進行正確分流

對每一個級別的發佈流程能夠描述爲：

1)         首先經過上線平臺將新代碼發佈到某一級機器集羣

2)         而後通知TIP平臺部署完畢

3)         TIP平臺驅動測試系統和監控系統對新服務進行線上驗證

4)         測試流量經過分流系統正確命中新部署服務

5)         工程師根據TIP平臺收集的報表進行決策並反饋給上線平臺

6)         上線平臺根據反饋決定是否進入下一級發佈

 

從技術實現上，主要須要解決流控基礎設施（分流系統）和平臺交互兩大部分的問題：

3.2.  分流系統

分流層是實現分級發佈「流量可控」這一目標最重要的基礎設施。貼吧的解決方案是在Nginx中經過擴展開發實現分流，判斷條件以下圖所示：

1)         內網IP+pub_env=1（自定義cookie）的請求會強制命中對內環境

2)         內網IP+pub_env=2的請求會強制命中小流量環境

3)         普通線上流量基於一致性分流規則分流到小流量環境和其餘線上環境

 

3.3.  平臺交互

主要指上線平臺和TIP平臺之間的交互，迭代進行部署、驗證的過程，以下圖所示：

4、             方案實施

4.1.  關鍵任務

要實現分級發佈，須要多個部門的緊密合做，任務表可劃分爲三個層次，以下所示：

1)         基礎設施：經過Nginx和頁面的改造，實現分流系統，做爲分級發佈的基礎

2)         平臺支持：上線平臺和TIP平臺開發，實現分級部署和驗證反饋

3)         應用層：線上測試體系和發佈流程建設

 

4.2.  實施收益

完成一期的開發工做以後，分級發佈在移動貼吧試行三週（5.7~5.25），印證了分級發佈對質量提高的確有立竿見影的做用，簡述以下：

l  結果維度：

n  觸發2次小流量回滾（1次由於性能，1次由於功能）

n  觸發1次對內環境回滾（功能問題）

l  過程維度：

n  對內發佈階段發現3個功能問題，1個編譯腳本問題

n  小流量發佈階段發現1次性能問題

n  其中1個功能問題屬線下漏測；其他功能、性能問題需在線上真實環境、真實流量下才能發現

5、             關鍵技術

實施分級發佈，涉及角色衆多也須要大量的開發工做，本節對部分關鍵技術進行闡述，但願對計劃實施分級發佈的其餘產品線提供一些幫助。

一、  運維節點劃分 & 跨機房訪問

           在線上部署爲雙機房的狀況下，若把UI集羣劃分爲：對內、小流量、全流量jx，全流量tc四個節點；那麼這種只保留一個小流量節點的方案，違背了運維的一個重要原則——不要跨機房訪問！當某個機房宕掉須要切機房的時候會出現白頁。

 

考慮到雙機房冗餘及切機房服務的操做，正確的節點劃分應保證每一個機房有一個小流量節點，以下所示：

 

二、  一致性分流 & 負載均衡

分級發佈拉長了上線的時間，咱們必須保證在發佈過程當中UI層異構期間，用戶的一致性體驗是不受影響的：

1)       在發佈過程當中，用戶不會一下子訪問到新產品，一下子訪問到老產品

2)       當新產品有缺陷時，只會影響到少許相對穩定的用戶羣，而不會波及全部用戶

須要知足用戶訪問一致性，意味着不能再在Webserver層使用隨機分流；而Webserver層的分流策略在知足用戶訪問一致性的同時，也必須考慮負載均衡。以Nginx的ip-hash策略爲例，雖然可以保證用戶一致性，但卻可能形成UI層負載不均衡（某些大型機構的出口IP含有大量請求）。

綜合考慮一致性和負載均衡，應選擇相似baiduid這樣具有更加離散特徵的cookie項來作分流。

三、  配置入庫 & 一鍵部署

由於OP的分級發佈部署平臺是以一鍵部署爲基礎的，因此產品線要作到分級發佈，一個重要的前提就是被部署的模塊（對貼吧來講是PHP UI模塊）可以被一鍵部署；而要作到一鍵部署，就要先作到配置模板入庫，而後在部署過程當中將模板變量替換爲真實的線上配置。這對於一些比較複雜的產品線來講，可能須要較大的改造代價，固然，對於已經實現持續集成上線的產品線，這就不是一個問題了。

四、  平臺支持

在產品線的基礎改造完成後，線上部署平臺和TIP平臺的實現和穩定運行，對於整個方案的實施，就有着相當重要的做用了。前者專一於分級部署和回滾；後者管理整個發佈過程，並對TIP（Test In Product）提供支持。

五、  線上自動化

爲了可以自動驗證線上服務，須要把自動化case遷移到線上運行，並結合cookie的使用以令驗證流量命中到正確的線上環境。

與在線下測試環境中運行自動化case相比，有一些特別須要注意的地方：

1)         設置cookie才能命中新發布代碼的線上機器，case結束後須要取消cookie

2)         頻繁登錄會被pass封禁

3)         規避antispam，驗證碼等問題

4)         線上提交流量對case驗證及穩定性的影響

運行效率：能夠考慮利 用分佈式系統等方案提高自動化的運行效率

by  Chenjie&Zhouren&Zhulei