揭開 Facebook Growth Hacking 的神祕面紗，微信、人人為何都在效仿？
接上一篇《Growth Hacking讓Facebook首頁5年未改版，人人網改版自掘墳墓的背後，缺少的是什麼》。
古語有云："一鼓作氣，再而衰，三而竭"。現在我一鼓作氣，寫完最後兩篇。這篇是下篇，另外下週還要發一篇叫番外篇。插播一句自己喜歡的話：
引用設計軟件有兩種方法: 一種是簡單到極致而明顯沒有缺陷; 另一種是複雜到極致以至於沒有明顯的缺陷。前者要難得多! ——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在關閉情況下的表現；這時程序的這塊功能邏輯應該和上一個版本保持一致，並且沒嚴重的不穩定性。
2. 員工測試階段：先將其GK開啟到 Employee 20%~50% （對於普通用户仍然關閉），看在員工羣體裏新功能的表現情況。一般這個過程是幾天，甚至是幾周。我們把功能開啟的員工羣叫做 實驗組，功能仍然關閉的叫做 參照組。對比兩組羣體的核心數據表現，比如Facebook App的話一般是看用户的session length（App使用時長），news feed engagement（like或者comment數量），廣告顯示時長和收入指標 等；而Messenger則是看 平均發消息數，消息收發的耗時；另外對於性能方面相關的功能還會看：App啟動時間，核心功能打開時間和App耗電量等數值。一般説來，對於重要功能，會在發佈前就會對這些數據的變化進行一個預測，對於不符合預期的變化會重點排查。
3. 小範圍發佈階段：等到在員工羣體裏，新功能被證明是有效，穩定，無害的時候，Facebook會將GK開啟到1%~5%的用户範圍。這裏主要是兩點考慮：
a) 對系統進行壓力測試，對於一些新的後台功能（比如：語音消息，VoIP電話，視頻聊天，或者 轉賬功能），看服務器是否能承受地住這麼大的用户流量。一般來説：5%，10%，30%，50% 是常見的幾個壓力測試坎，過了50%基本上沒有問題；
b) 看用户和媒體對於這個功能的評價。一般來説，PM會收集TechCrunch，VentureBeat，Wired上面的媒體評測，發到內部羣裏給大家分享；也有在Twitter上面搜索用户對此功能的討論。
4. 全部發布階段：等到服務器確認能抗住所有流量，這時會將GK開到95~98%的用户，同時依然保留2%的參照組作為對比用。這個階段最重要的是看 data dashboard 上的各種監控數據，看是否和其他預期的一樣，至少一些關鍵的指標不能出現下滑。
5. 收尾階段：技術人員開始修改程序代碼，把相應的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端進行控制，如果它想，隨時就可以改變。而且也有可能不同人的不一樣（比如我的微信是在北美下載和註冊的，我的列表進行少一些，另外我的發現裏面的京東購物也比中國區的朋友晚出現了將近一年；另外我從來沒看到過任何朋友圈廣告）。
5. Apple官網其實不支持這種server遠端控制app client的邏輯，因為它對於App store的審核有很大的阻礙。但是Apple一直對此一直睜一隻眼閉一隻眼。
6. 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）
(未完待續 -- 番外篇：Facebook裏的一些關於 growth hacking 的趣事、囧事、以及那些 Facebook 曾經踩過的坑）
--- END ---
公眾號： qc_empire
- Do have the faith in what you love
*文章為作者獨立觀點，不代表虎嗅網立場
本文由 hackerqc 授權 虎嗅網 發表，並經虎嗅網編輯。轉載此文章須經作者同意，並請附上出處(虎嗅網)及本頁鏈接。原文鏈接http://www.huxiu.com/article/132639/1.html
資料來源：虎嗅網