灰度測試試驗流量“洗牌”

什麼是灰度測試

A/B測試系統的一個常用場景是App/小程式/後端服務精細化運營過程中的上線迭代管理，通常被稱為灰度測試或者灰度上線。

詳細來說，如果軟體產品要在不久的將來推出一個全新的功能，或者做一次比較重大的改版的話，要先進行一個小範圍的測試工作，給一小部分使用者先試用。通過埋點監控得到使用者反饋，確認新功能的效果達到預期之後，再慢慢放量，直到這個全新的功能覆蓋到所有的系統使用者。也就是說在新功能上線的黑（沒有使用者）白（所有使用者）之間有一個灰（部分使用者），所以這種方法也通常被稱為灰度測試。


在灰度測試的技術實現裡，一個關鍵的部分是試用使用者樣本的選擇策略。也就是說，新版本上線測試的首批（以及後續批次）灰度使用者是怎麼篩選出來，決定了灰度測試的技術選型和具體實現。從業務角度來說，我們要明確每一個新功能分別由哪些測試使用者來試用，誰扮演“小白鼠”的角色。

被廣泛使用的樣本選擇策略包括以下幾種：

1.白名單：我們主動選取一批使用者，打上白名單標籤。灰度版本首先開放給這批使用者。白名單使用者通常是業務同事根據業務經驗選取的，比如活躍的粉絲、喜愛嚐鮮的使用者、對產品問題比較包容的朋友等。當然也可以是隨機選取的。

白名單最大的好處是主動可控，出現問題的時候可以及時定位具體使用者，業務同事可以及時和這些具體客戶進行溝通，獲得深入的測試反饋。

但是白名單使用者組由於不具有普遍代表性，一般不能實現A/B測試的效果預測能力。另外，技術上實現白名單通常會有效能損耗（對每一個使用者都需要掃描一遍名單），再考慮到人工篩選的工作量，我們通常不會允許白名單裡的使用者數量太大。這種侷限性對於使用者量較大的業務來說，比較麻煩。

2.隨機抽樣：每個使用者都有一定概率可以參與測試。

隨機抽樣原理簡單，樣本選取的代表性也比較好。多數時候隨機抽樣產生的試驗組和對照組可以直接用於A/B測試檢驗。

但是隨機抽樣不可避免的會讓試驗管理陷入被動，萬一灰度測試給一部分使用者造成負面影響，很難挽回。這種不確定性的風險要求我們在測試階段有強大魯棒的干預技術手段，比如實時監控、實時回滾、實時捕捉到使用者在各渠道的負面反饋等。另外，要實現真正符合統計科學的真隨機（不是偽隨機），技術上也有不少坑。

3. 按照某種規則抽樣：我們主動建立抽樣規則，滿足規則條件的使用者就被指定參與測試。規則通常要考慮業務需求和測試使用者覆蓋。比如規則是“只選取手機尾號為9的使用者”，那麼測試使用者覆蓋可能在10%左右。另一種規則是“下過單的使用者”，那麼測試使用者大概會覆蓋已付費客戶。

規則抽樣比白名單更加靈活方便，通常能覆蓋顯著更多的使用者，技術實現的效能也會比較好。

但是規則抽樣的策略介於隨機抽樣和白名單之間，既不是完全可控，也不是均勻取樣，並不是滿足業務需求的最佳選擇。

4.A/B測試科學取樣：試驗組（和對照組）使用者是通過具有代表性的隨機抽樣選取，可能還經過了前期干預，只有符合統計學檢驗標準的使用者可以參與測試。

科學取樣生成的試驗組和對照組具有很高的使用者代表性，測試得出的資料可以精確的預測新功能全面上線之後帶來的整體效果。

和隨機抽樣一樣，A/B測試需要我們具有強大的試驗控制能力，能夠實時回滾、實時開關試驗功能、實時監控使用者行為、實時調整分流比例。

如果有一個像AppAdhoc A/B Testing一樣強大的科學A/B試驗系統，每一個灰度測試都可以用A/B測試來實施。更重要的是，當我們有多個新功能一起研發推進的過程中，可以同時啟動多組A/B測試，每組試驗檢驗一個功能，實現更精細化的產品管理。

2 A/B測試抽樣的長期問題

在實踐之中，我們注意到一個用A/B測試來做灰度上線的技術問題：長期試驗的科學性偏差。

舉例來說，一個長期運營的App，每個月上線一版新功能，也就是每個月上線一個A/B測試。A版對照組取樣5%的使用者，B版體驗新功能組取樣5%的使用者，同時開始試驗控制。兩週之後試驗結束，使用者喜愛的新功能全面釋出，使用者不喜愛的新功能全面回滾。再過兩週，新的一個月迭代週期開始，新的A/B測試上線，5%對照組5%試驗組……每個月一組A/B測試，長此迴圈。

假如A/B測試的樣本篩選演算法只考慮一次試驗的科學性，那麼只需要保證我們選出的5%對照組和5%試驗組足夠均勻即可。

假設試驗組取樣使用簡單的雜湊演算法：

Group ID for Client cid <= Hash(A/B Testing Client ID cid)

那麼每一個使用者都會被分到固定編號的試驗組裡。

假設試驗組資源分配使用簡單的貪心演算法：

Experiment Groups for X% <= FindFirstXGroups(Groups, X)

如果試驗頻率是一個月一次，測試流量5%，那麼每次試驗都會是前5個試驗組(Group)被選中參與測試。也就是說，有一批使用者，被固定分配到前5個試驗組的使用者，每個月都會被選中為“小白鼠”參與試驗。


這會造成一個長期問題，就是這些留存很久的樣本使用者，比如使用App長達半年、一年、多年的老使用者，作為試驗樣本，可能會出現“樣本偏差”。

如果一批老使用者總是在不停“嚐鮮”，一批老使用者總是體驗穩定版本，他們的行為習慣可能被培養成不同的型別，他們對產品的期待和需求也可能逐漸異化。比如說，長期參與試驗的“小白素”使用者更喜歡新功能更不在乎bug，而長期在對照組的使用者不適應新功能也對bug很敏感。一旦這種差異開始固化，這兩組使用者就異質了，不能拿來繼續做新的A/B測試。如果繼續用這些樣本做試驗，試驗結果是不符合A/B測試要求，結論是不可信的，無法用於業務指導。

其實A/B測試結果的科學和準確只是一個小問題，這個問題的最大影響是在於這些被反覆拿來做試驗的“小白鼠”使用者/客戶，有可能產生不必要的流失，甚至個別使用者被反向培養成“黑粉”，對我們的產品形成強化的壞印象。這種資深黑粉使用者會嚴重影響產品的口碑，也幾乎沒有辦法可以召回。

這個長期偏差問題對於白名單和規則抽樣等型別的取樣策略也都或多或少的存在。當然，白名單策略本身就是要篩選出特定的使用者群長期做“小白鼠”，我們在選擇白名單策略之初就得處理好這個問題。

理論上說，隨機抽樣不會出現長期偏差問題，因為每次參與試驗的使用者都是隨機篩選的一批，通常同一個使用者不會被不同的試驗反覆選中。但是在實踐之中，也要注意實現的演算法是否能支援真正的隨機性。很多時候，偽隨機數加上固定分支條件的程式碼實現會讓某些使用者有更大的可能被選中，這些使用者還是會成為長期的“小白鼠”。

3 試驗流量“洗牌”演算法

意識到灰度測試的長期“小白鼠”問題，我們需要在A/B測試系統裡引入“洗牌”機制，可以不斷把預先分配好的試驗組裡的使用者們重新打散，再重新分配到不同的試驗組裡。


“洗牌”機制有很多實現演算法，針對A/B測試系統，我們可以採用的一個簡單演算法：對每一個使用者，每過一段時間（比如30天），就給使用者一個機會，可以換到其他試驗組裡去。

假設我們用簡單的雜湊演算法來對使用者做試驗分組，那麼可以用類似這樣的實現：

// Runs every 30 days

Group ID for Client cid <=

Hash(A/B Testing Client ID cid + DateTime) % #Groups

注意不同的使用者加入系統的時間是不同的，所以他們的“洗牌”機會也會出現在不同的時間。但是整體來說，試驗組是每過一個月完成一次比較完整的“洗牌”。

引入“洗牌”機制之後，每個試驗組在長時間尺度上是不斷變化的，即便是同一個編號的試驗組反覆參與測試，也不會總是同一批使用者。我們再也不會總是逮著同一群小白鼠打針喂藥了。

總之，尊重使用者/客戶，不僅要用灰度A/B測試來避免有問題的產品迭代影響大面積的使用者，還要避免同一批使用者總是被拿來做試驗，確保所有使用者都能享受最佳的產品體驗。

來源：熱雲資料
原地址：https://mp.weixin.qq.com/s/wKd2_GwLE4iwrKEyaLmofA