揭開 Facebook Growth Hacking 的神祕面紗，微信、人人爲什麼都在效仿？

設計軟件有兩種方法: 一種是簡單到極致而明顯沒有缺陷; 另外一種是複雜到極致以致於沒有明顯的缺陷。前者要可貴多!

—— C.A.R.Hoare

本篇開始！

灰度發佈 和 A/B testing

不少朋友應該對Facebook首頁和人人網首頁改版的例子印象深入。這裏Facebook使用的一大法寶就是灰度發佈和A/B testing。這一利器像宙斯盾同樣（想不出好的比喻），屢次將Facebook從出錯的懸崖上拉回來。就好像上一篇裏面所說的那樣：

即便像 Facebook 這樣的航母，在創業的大海里仍是猶如「盲人」同樣，不少產品的改動沒人真正知道方向到底在哪兒。因此這裏採用的方式就是 「Everything must be tested」。在灰度發佈後，data dashboard + A/B testing 就猶如航母上的雷達或者聲納同樣，對於方向和航線起到驗證做用。

因此來重點介紹一下Facebook的這臺雷達系統。

Facebook早在2007-2008年就在網頁服務端（PHP）上開發了這套 發佈和測試系統，代號叫 GateKeeper （最先在Boz的文章中提到），本質上它就是一個開關，能夠在一個admin page上定義一個個的開關，而後控制某些開關究竟是開仍是關。這些開關的屬性預先都緩存在內存中，因此讀取開關的操做不重。示例代碼以下：

主要的邏輯就在 if 中，判斷這個開關是否對相應的用戶開啓，若是是則跑實驗代碼，不然跑老代碼。很是直接和簡單對吧！後來，Facebook又陸陸續續對它進行了各類增強，讓其能夠更加精細地分割和控制用戶，好比說 對於US的1%用戶開放，或者對於 日本的年齡25歲如下的男性用戶開放，等等。能夠從時間，國家，加入日期，好友數，是否爲FB員工，性別，年齡等等各類維度進行控制。

這極大方便了咱們對於用戶分批進行 A/B testing。Gatekeeper（簡稱GK）對於Facebook的整個internal tools組來講一個很重要的基礎設施。隨着Facebook用戶量的增大，每一個GK每日的被訪問量也大大增長；同時Facebook本身的功能和相應的GK項也不斷增長， 這對於整個GK的規模能力後來也提出了很大的挑戰。

到了移動時代後，iOS和Android的 core team 也相應地推出了比較強大的移動灰度發佈和 A/B testing 工具，代號叫作 Airlock ，其中咱們的一位中國工程師也參與它的開發。固然，相似的工具還有很多，好比 Twitter 開源的 Clutch IO 。移動上的 Airlock 系統稍微複雜一點：

1. 首先，用戶在手機上登陸或者打開Facebook App後，airlock會從FB server取得全部的GK值；而後在本地緩存起來；

2. 而後在 iOS 或者 Android 代碼裏寫相同 if 判斷邏輯，來檢查當前用戶是否已經開啓這個屬性。是的話，跑試驗代碼；不然跑老代碼；

3. 而後app每隔一段時間去和server同步一次（FB用的是一個小時的間隔）；固然app隨時也能夠強制去取server上的最新值。

4. 最關鍵的是：移動端的logging會把當前用戶的每一個GK的值記錄在logging中，這樣當這些logs被上傳到server後， server能夠根據這些logs來統計用戶的GK值和相應的動做。

回顧來看，移動上的灰度發佈和 A/B testing 本質就是要在本地代碼加入一個庫，來負責和server同步全部開關的值，以及在logs裏記錄好相應的這些開關，便於後來分析用戶的行爲，來了解此用戶是暴露在怎樣的開關組合中。

案例一：Facebook iOS app的演化

下面來講一下iOS下面的Facebook app界面演化過程。衆所周知，Zuck 和 Steve Jobs 的私交一直不錯，Zuck 也把 喬幫主 當作本身的模樣，私下裏常常去喬老爺家裏共進晚餐和請教 run company 的竅門。因此，用 iPhone 初版SDK開始，Facebook就有iOS原生應用開始入駐App Store：

能夠看到iOS仍是擬物化的風格，Facebook用的是當年紅極一時的九宮格首頁。消息提示在首頁的最下面，當時Facebook尚未 Like button，只能夠comment。此版本的Facebook app爲最初一版，由一大牛獨自完成。此大牛把後來的經常使用組件開源成 Three20 庫。

後來Facebook通過一次大的UI改變：

最大的變化就是九宮格改成了左側抽屜式的導航欄，左上角出現著名的」Hanburger」按鈕。

因而來到2013年，Facebook app準備進行新一輪的大改版，由左側抽屜式改成 Tab bar 格式：

這一版的改動，在乎義上主要是讓用戶能夠更加方便切換到news feed之外的其餘功能區；但是卻引起了另一個問題：到底下面的tab bar放幾個按鈕？每個位置上應該放什麼？

此時已是2013年，前一年在Facebook在WWW首頁的改版失敗依然影響着公司的engineering team，因而在iOS app決定更偏好保守和務實。Airlock在此次的改版上起到巨大的做用。Facebook iOS core team的人寫好了tab bar的代碼後，並無立刻發佈給全部用戶，而是開始了長達4個月的灰度發佈和A/B testing；測試了下面 tab bar 各類可能的狀況：好比 5個tab項 或者 4個？

第二個放 Requests or Messages？ Notifications 或者 Groups 暴露在外面？ 同時對於右上角的按鈕的功能和樣式也進行了測試，好比是放 通信錄 仍是 Messages？ 是放一個 圖標 仍是 直接寫字 等等。一度由於出現新的測試組合，以及對於好幾個組合的測試結果在數據上的比較模棱兩可而把發佈時間一拖再拖。整個iOS app界面重組的項目由 Mick Johnson 主導，他是我見過執行力最強的Facebook的幾個PM之一。

他認真審視了各類組合的數據後，結合Facebook當時要大力推行Messenger的大背景，最後肯定上圖的組合順序。這個組合在各類測試中數據的綜合表現最好，可以有效地讓用戶查看news feed，增長用戶的好友數（好友數是從Facebook data組裏試驗出來的一個很是重要的指標，這在文章最後能夠和你們介紹），方便地收發消息，以及查看新消息，可是 groups，events，還有其餘一些輔助功能被藏入了 「more」 之中。

案例二：Voice message 的發佈過程

下面拿我以前負責的 voice message（語音消息）功能在Facebook messenger中的發佈來分解一下整個Facebook 灰度發佈和 A/B testing 的過程：

同理，在 iOS messenger 中，用戶一登陸後（以及之後的每個小時），iOS messenger client都會和server通訊一次，拿到全部 gatekeeper（控制屬性）的值，而後緩存在本地。Messenger上重要的新功能在發佈以前都要放在一個GK（gatekeeper）後面，根據Server端的設置來控制每一個功能在 網頁，iOS和Android端 的打開或者關閉，而後經過控制GK開啓的範圍（用戶的百分比）來實現功能逐步開放給全部的用戶。

整個功能的發佈過程分解以下：

1.準備階段：寫好以後代碼都已經在App裏，且提交給app store審覈經過，可是GK爲關閉狀態。等到上線後，先看擁有版本X的代碼的App在關閉狀況下的表現；這時程序的這塊功能邏輯應該和上一個版本保持一致，而且沒嚴重的不穩定性。

1. 員工測試階段：先將其GK開啓到 Employee 20%~50% （對於普通用戶仍然關閉），看在員工羣體裏新功能的表現狀況。通常這個過程是幾天，甚至是幾周。咱們把功能開啓的員工羣叫作 實驗組，功能仍然關閉的叫作 參照組。對比兩組羣體的核心數據表現，好比Facebook App的話通常是看用戶的session length（App使用時長），news feed engagement（like或者comment數量），廣告顯示時長和收入指標 等；而Messenger則是看 平均發消息數，消息收發的耗時；另外對於性能方面相關的功能還會看：App啓動時間，核心功能打開時間和App耗電量等數值。通常說來，對於重要功能，會在發佈前就會對這些數據的變化進行一個預測，對於不符合預期的變化會重點排查。

2. 小範圍發佈階段：等到在員工羣體裏，新功能被證實是有效，穩定，無害的時候，Facebook會將GK開啓到1%~5%的用戶範圍。這裏主要是兩點考慮：

a) 對系統進行壓力測試，對於一些新的後臺功能（好比：語音消息，VoIP電話，視頻聊天，或者 轉帳功能），看服務器是否能承受地住這麼大的用戶流量。通常來講：5%，10%，30%，50% 是常見的幾個壓力測試坎，過了50%基本上沒有問題；

b) 看用戶和媒體對於這個功能的評價。通常來講，PM會收集TechCrunch，VentureBeat，Wired上面的媒體評測，發到內部羣裏給你們分享；也有在Twitter上面搜索用戶對此功能的討論。

1. 所有發佈階段：等到服務器確認能抗住全部流量，這時會將GK開到95~98%的用戶，同時依然保留2%的參照組做爲對比用。這個階段最重要的是看 data dashboard 上的各類監控數據，看是否和其餘預期的同樣，至少一些關鍵的指標不能出現下滑。

2. 收尾階段：技術人員開始修改程序代碼，把相應的GK和舊功能代碼刪除，這樣下一個或者下下個新版本將擁有純粹的新功能X代碼。這一步，通常會常常1個月或者幾個月的時間，並且最終純粹的X代碼發佈會很謹慎，由於一旦上線給用戶，功能X的出現會不受Facebook server的控制；假設忽然出現App端的惡性bug，Facebook除了立刻發佈一個新版App，等待App Store審覈，同時拜託用戶立刻升級以外沒有任何辦法。

綜合來看，灰度發佈 (shadow release) 和 A/B testing 的特色和注意事項：

1. 前端代碼預先發布；且有可能同時多套不一樣版本的代碼存在；

2. 移動端或者前端MVC的代碼須要按照必定頻率獲取來自服務器的控制信息，從而展現相應的形態；

3. 後臺能夠對發佈進行精密的控制。好比說：發佈給多少比例的用戶，用戶所在區域等；而且即便在開放給100%用戶後，只要 GK檢查 沒有清楚，則server仍然能夠遠程控制（或回滾）試驗中的功能。在某些嚴重bug出現的狀況下，能夠徹底回滾某一功能。

4. 注意：因爲有A/B testing的緣由，不一樣用戶A和B坐在一塊兒，都剛剛下載和安裝了最新的Facebook App，可是打開app後所看到的功能（甚至UI佈局）卻可能不同；而且對於同一用戶，今天看到的app裏展現的功能可能和明天展現的也不同，即便他並無更新本身的app。

其實，微信早在幾年前就已經藉助此方式來進行測試和數據採集（微信團隊的主力在2012年時來Facebook訪問，當年咱們FB的一些工程師和他們的一些工程師+張小龍有對於產品和技術上的深度討論）。好比說微信的一大特色是右上角的快捷菜單：

上面的選項和順序就是在server端進行控制，若是它想，隨時就能夠改變。並且也有可能不一樣人的不同（好比個人微信是在北美下載和註冊的，個人列表進行少一些，另外個人發現裏面的京東購物也比中國區的朋友晚出現了將近一年；另外我歷來沒看到過任何朋友圈廣告）。

1. Apple官網其實不支持這種server遠端控制app client的邏輯，由於它對於App store的審覈有很大的阻礙。可是Apple一直對此一直睜一隻眼閉一隻眼。

2. iOS程序員都知道，Objective C是純動態語言，全部的函數都是虛函數，也就是說任何函數調用均可以在runtime時改變（特別有變態的 method swizzling 機制）。這就致使了當用戶下載了你的app以後，能夠本地hack你的GK開關。以前就有不少次，Facebook發佈了一個新版本後，那些iPhone界的破解高手就開始研究Facebook app，而後找到好些GK值，人爲地把它們打開，而後嚐鮮未開放的新功能；有時還會把一些功能的使用體驗寫到博客裏，或者發給 TechCrunch 用與報道。後來使得Facebook內部把比較重要有戰略意義的功能，直接用 compile flag 將其從 product build 中剝離。

最後 ——Don’t reinvent the role

最後也是最重要的一點：從上面能夠看出，對於整個灰度發佈還有A/B testing，無論是產品自己仍是作灰度發佈的系統，都有着不小的開發量。也就是說：灰度發佈+ A/B test一方面 會減慢產品迭代速度，另外一方面會大大提升迭代穩定性的。這對於特別是初創公司（成立半年之內，用戶量不大的）要慎用（或者明確說來：禁用）。

然而對於發展得不錯的創業公司，特別是在同質化競爭比較嚴重（中國特點）的時候，要儘快地開始使用 A/B test。好比：Nice和In，去哪兒和攜程（合併以前） 這種。在作 A/B test 方面，我以爲國內作得很不錯的創業公司公司是 AppAdhoc；創始人王曄有着很強的技術背景，以前一直在 Google mountainview 效力。公司網站：吆喝科技 AppAdhoc。 我以前去看過他們產品的界面和使用，和FB的inhouse系統類似度很大；我的還以爲他們的UI更加接近於你們習慣的 bootstrap 風格，而不是 FB 本身的藍色風：吆喝科技 AppAdhoc（感興趣的公司，能夠我直接幫大家推薦 :D）

— END —

本文做者：覃超，公衆號： qc_empire

– Do have the faith in what you love