譯者注:本文來自 Facebook 工程師團隊博客web
兩年前,咱們重寫了咱們移動端(iOS,Android)的應用,使用了原生的開發棧(native development stacks)代替咱們之前定製開發的 Web 棧(custom web-stack)。這給了咱們在關於項目在那裏/怎樣下載、緩存、釋放等等方面一個更好的控制。它分別深刻地和操做系統整合在一塊兒,提供在底層調整修改全部系統的一整套工具。segmentfault
測試是咱們開發的一個重要部分,但在轉換到原生的以後,咱們沒有了 A/B 測試的能力。並非每一個測試均可以用到生產中,但即便是失敗的測試也能幫助咱們理解如何才能更好地改進。失去的這部分能力變成了一個咱們要應對的挑戰。緩存
要把咱們的應用移植到 iOS 和 Android 上,須要來自不一樣團隊的人來進行協做,每四周就要產生一個新的修復一些 bug 和帶有一些新特性的二進制軟件包。在咱們發佈一些更新以後,對於咱們很重要的事情是要去明白:服務器
爲了去了解這些事情,咱們須要一個移動端進行 A/B 測試的基礎組件,這個組件能讓咱們的用戶分別使用不一樣版本的應用(版本 A 和版本 B),這些版本在除某些特別須要測試的部分外,其餘各層面都是同樣的。因此咱們創造了 Airlock,一個可讓咱們比較不一樣版本應用的度量數據(metric data)和進行各類各樣測試的測試框架,這幫助咱們決定採用那個版本或者後續如何迭代。網絡
咱們儘量從最簡單的試驗開始:使用已有的 Web-Stack A/B 分箱(binning system)系統。咱們構造了一個測試:把聊天按鈕換成文字"Chat"的試驗。當應用啓動的的時候,它會發送一個到咱們服務器上的網絡請求,詢問這個試驗的參數。當有迴應返回後,咱們就會更新按鈕。一些員工會有按鈕,另外一些員工會有文字"Chat"。咱們指望這僅僅會影響信息發送的數量(看起來不會太多),其餘的東西不會受影響。框架
當這個版本的應用公開發布了,咱們等待數據能穩定下來,而後發現看到文字"Chat" 的版本會更熱衷於使用這個應用。是否是咱們發現了什麼祕密,或者誘惑般的魔法?沮喪地說,並非。咱們遇到了不少 bug,其中一個很大的問題是,某個組件並不能正確地緩衝數值。因爲這是個大的系統,基礎設施(the infrastructure)必需要是 "防彈的",否則收集到的數據就沒用了。工具
從服務器開始的數據管道決定某我的的版本是屬於那種變體的。而後,數據就會被打包,接着發送到設備上,設備分析返回的信息而後保存。接着,這個值會被用於從新配置 UI,而後最終在屏幕上顯示。問題是咱們在依靠服務器對咱們數據分析的分類。一個簡單的 bug 就致使了一大羣用戶在使用有別於咱們指望的的變種版本。服務器還在堅持:"我告訴了設備去顯示字符串!" 但在某處地方這個語句變得有點使人模糊(一個在客戶端存貯邏輯上的 bug)。post
一個試驗的部署圖:
上面圖表展現了一個試驗的部署。淺綠色的條柱是試驗用戶的數量,黑綠色的條柱是實際被影響的用戶數。咱們能夠看到,服務器和設備的數據區別仍是很大的: 在第一天,大多數用戶收到這個配置,但大多數用戶沒有留意到咱們試驗。測試
當問題不只僅是設備收到返回的數據,而須要加上咱們的數據分析須要知道何時收到信息,而後把它正確地顯示在 UI 上時,問題變得更大了。即便信息能正確地到達,在 UI 不正確時也有一個延遲。咱們經過
添加雙向握手(wo-way handshake)解決了這個問題。設備請求用於試驗的數據,服務器記錄它發出的迴應。所以,即便某用戶沒有看到咱們想讓他看到的,咱們仍然能夠進行正確性分析(但也必須意識到選擇性誤差(selection bias)的問題,還有分發時因爲某些緣由變得不平均)。spa
在進行了幾個月這樣的"課程"以後,咱們必須將支持兩個試驗的系統升級支持整個應用的系統。這個促使 Airlock 發生變革的試驗是之前咱們原想着進化和簡化咱們應用內的導航模塊而開發的。在經歷這幾個月以後,咱們把這個應用改變了不少,你能夠去下載 Facebook for iPhone 來體驗一下,這裏面不少是測試的功勞。
隨後,Airlock 被用於支持更多的試驗,其請求的參數,數據的記錄、客戶端計算等等都快速地變多。Airlock 充分地被用於測試原生的應用,使得咱們的應用運行得史無前例的輕快,伴隨着測試的自由,再測試,和評估測試結果,咱們指望能建造更好的測試和創造更好的用戶體驗。
原文:Airlock - Facebook's mobile A/B testing framework
翻譯:Segmentfault