7
| 本文作者： 覃超 | 2015-11-28 21:14 |
【編者按】雷鋒網(wǎng)專欄特約作者覃超，前FB工程師，現(xiàn)為FREES技術(shù)合伙人。本文是 Growth Hacking 系列的下篇：揭開 Growth Hacking的神秘面紗（憋以為就這么結(jié)束了，咳咳，還有番外篇）。推薦閱讀前兩篇：1、10億日活躍用戶的背后，F(xiàn)acebook的大牛們都做了什么？（上）2、關(guān)于神秘的Growth Hacking，F(xiàn)acebook都做了什么？（中）。
古語有云："一鼓作氣，再而衰，三而竭"?，F(xiàn)在我一鼓作氣，寫完最后兩篇。這篇是下篇，另外下周還要發(fā)一篇叫番外篇。屆時再與雷鋒網(wǎng)讀者們一起分享，有興趣的可留言探討。
設(shè)計軟件有兩種方法: 一種是簡單到極致而明顯沒有缺陷; 另一種是復(fù)雜到極致以至于沒有明顯的缺陷。前者要難得多！
——C.A.R.Hoare
下篇開始！
如果看過中篇（《關(guān)于神秘的Growth Hacking，F(xiàn)acebook都做了什么？（中）》）的朋友應(yīng)該對于里面Facebook首頁和人人網(wǎng)首頁改版的例子印象深刻。這里Facebook使用的一大法寶就是灰度發(fā)布和 A/B testing。這一利器像宙斯盾一樣（想不出更好的比喻），多次將Facebook從出錯的懸崖上拉回來。就好像上一篇里面所說的那樣：
即使像 Facebook 這樣的航母，在創(chuàng)業(yè)的大海里還是猶如“盲人”一樣，很多產(chǎn)品的改動沒人真正知道方向到底在哪兒。所以這里采用的方式就是 "Everything must be tested"。在灰度發(fā)布后，data dashboard + A/B testing 就猶如航母上的雷達或者聲納一樣，對于方向和航線起到驗證作用。
所以來重點介紹一下Facebook的這臺雷達系統(tǒng)。
Facebook早在2007-2008年就在網(wǎng)頁服務(wù)端（PHP）上開發(fā)了這套 發(fā)布和測試系統(tǒng)，代號叫 GateKeeper （最早在Boz的文章中提到），本質(zhì)上它就是一個開關(guān)，可以在一個admin page上定義一個個的開關(guān)，然后控制某些開關(guān)到底是開還是關(guān)。這些開關(guān)的屬性預(yù)先都緩存在內(nèi)存中，所以讀取開關(guān)的操作不重。示例代碼如下：
主要的邏輯就在 if 中，判斷這個開關(guān)是否對相應(yīng)的用戶開啟，如果是則跑實驗代碼，否則跑老代碼。非常直接和簡單對吧！后來，F(xiàn)acebook又陸陸續(xù)續(xù)對它進行了各種加強，讓其可以更加精細地分割和控制用戶，比如說 對于US的1%用戶開放，或者對于 日本的年齡25歲以下的男性用戶開放，等等?？梢詮臅r間，國家，加入日期，好友數(shù)，是否為FB員工，性別，年齡等等各種維度進行控制。
這極大方便了我們對于用戶分批進行 A/B testing。
Gatekeeper（簡稱GK）對于Facebook的整個internal tools組來說一個很重要的基礎(chǔ)設(shè)施。隨著Facebook用戶量的增大，每個GK每日的被訪問量也大大增加；同時Facebook自己的功能和相應(yīng)的GK項也不斷增加， 這對于整個GK的規(guī)模能力后來也提出了很大的挑戰(zhàn)。
到了移動時代后，iOS和Android的 core team 也相應(yīng)地推出了比較強大的移動灰度發(fā)布和 A/B testing 工具，代號叫做 Airlock ，其中我們的一位中國工程師也參與它的開發(fā)。當然，類似的工具還有不少，比如 Twitter 開源的 Clutch IO 。移動上的 Airlock 系統(tǒng)稍微復(fù)雜一點：
首先，用戶在手機上登錄或者打開Facebook App后，airlock會從FB server取得所有的GK值；然后在本地緩存起來；
2. 然后在 iOS 或者 Android 代碼里寫相同 if 判斷邏輯，來檢查當前用戶是否已經(jīng)開啟這個屬性。是的話，跑試驗代碼；否則跑老代碼；
3. 然后app每隔一段時間去和server同步一次（FB用的是一個小時的間隔）；當然app隨時也可以強制去取server上的最新值。
4. 最關(guān)鍵的是：移動端的logging會把當前用戶的每個GK的值記錄在logging中，這樣當這些logs被上傳到server后， server可以根據(jù)這些logs來統(tǒng)計用戶的GK值和相應(yīng)的動作。
回顧來看，移動上的灰度發(fā)布和 A/B testing 本質(zhì)就是要在本地代碼加入一個庫，來負責和server同步所有開關(guān)的值，以及在logs里記錄好相應(yīng)的這些開關(guān)，便于后來分析用戶的行為，來了解此用戶是暴露在怎樣的開關(guān)組合中。
案例一：Facebook iOS app的演化
下面來說一下iOS下面的Facebook app界面演化過程。眾所周知，Zuck 和 Steve Jobs 的私交一直不錯，Zuck 也把喬幫主當做自己的模樣，私下里經(jīng)常去喬老爺家里共進晚餐和請教 run company 的竅門。所以，用 iPhone 第一版SDK開始，F(xiàn)acebook就有iOS原生應(yīng)用開始入駐App Store：
可以看到iOS還是擬物化的風格，F(xiàn)acebook用的是當年紅極一時的九宮格首頁。消息提示在首頁的最下面，當時Facebook還沒有 Like button，只可以comment。此版本的Facebook app為最初一版，由一大牛獨自完成。此大牛把后來的常用組件開源成 Three20 庫。
后來Facebook經(jīng)過一次大的UI改變：
最大的變化就是九宮格改為了左側(cè)抽屜式的導(dǎo)航欄，左上角出現(xiàn)著名的”Hanburger”按鈕。
于是來到2013年，F(xiàn)acebook app準備進行新一輪的大改版，由左側(cè)抽屜式改為 Tab bar 格式：
這一版的改動，在意義上主要是讓用戶可以更加方便切換到news feed以外的其他功能區(qū)；可是卻引發(fā)了另外一個問題：到底下面的tab bar放幾個按鈕？每一個位置上應(yīng)該放什么？
此時已經(jīng)是2013年，前一年在Facebook在WWW首頁的改版失敗依然影響著公司的engineering team，于是在iOS app決定更偏好保守和務(wù)實。Airlock在這次的改版上起到巨大的作用。Facebook iOS core team的人寫好了tab bar的代碼后，并沒有馬上發(fā)布給所有用戶，而是開始了長達4個月的灰度發(fā)布和A/B testing。
測試了下面 tab bar 各種可能的情況：比如 5個tab項 或者 4個？ 第二個放 Requests or Messages？ Notifications 或者 Groups 暴露在外面？ 同時對于右上角的按鈕的功能和樣式也進行了測試，比如是放 通訊錄 還是 Messages？ 是放一個圖標還是直接寫字？等等。
一度因為出現(xiàn)新的測試組合，以及對于好幾個組合的測試結(jié)果在數(shù)據(jù)上的比較模棱兩可而把發(fā)布時間一拖再拖。整個iOS app界面重組的項目由 Mick Johnson 主導(dǎo)，他是我見過執(zhí)行力最強的Facebook的幾個PM之一。他認真審視了各種組合的數(shù)據(jù)后，結(jié)合Facebook當時要大力推行Messenger的大背景，最后確定上圖的組合順序。這個組合在各種測試中數(shù)據(jù)的綜合表現(xiàn)最好，能夠有效地讓用戶查看news feed，增加用戶的好友數(shù)（好友數(shù)是從Facebook data組里試驗出來的一個非常重要的指標，這在文章最后可以和大家介紹），方便地收發(fā)消息，以及查看新消息，但是 groups，events，還有其他一些輔助功能被藏入了 “more” 之中。
案例二：Voice message 的發(fā)布過程
下面拿我之前負責的 voice message（語音消息）功能在Facebook messenger中的發(fā)布來分解一下整個Facebook 灰度發(fā)布和 A/B testing 的過程：
同理，在 iOS messenger 中，用戶一登錄后（以及以后的每一個小時），iOS messenger client都會和server通信一次，拿到所有 gatekeeper（控制屬性）的值，然后緩存在本地。Messenger上重要的新功能在發(fā)布之前都要放在一個GK（gatekeeper）后面，根據(jù)Server端的設(shè)置來控制每個功能在網(wǎng)頁、iOS和Android端的打開或者關(guān)閉，然后通過控制GK開啟的范圍（用戶的百分比）來實現(xiàn)功能逐步開放給所有的用戶。
整個功能的發(fā)布過程分解如下：
1. 準備階段：寫好之后代碼都已經(jīng)在App里，且提交給app store審核通過，但是GK為關(guān)閉狀態(tài)。等到上線后，先看擁有版本X的代碼的App在關(guān)閉情況下的表現(xiàn)；這時程序的這塊功能邏輯應(yīng)該和上一個版本保持一致，并且沒嚴重的不穩(wěn)定性。
2. 員工測試階段：先將其GK開啟到Employee 20%~50% （對于普通用戶仍然關(guān)閉），看在員工群體里新功能的表現(xiàn)情況。一般這個過程是幾天，甚至是幾周。我們把功能開啟的員工群叫做實驗組，功能仍然關(guān)閉的叫做參照組。
對比兩組群體的核心數(shù)據(jù)表現(xiàn)，比如Facebook App的話一般是看用戶的session length（App使用時長），news feed engagement（like或者comment數(shù)量），廣告顯示時長和收入指標 等；而Messenger則是看 平均發(fā)消息數(shù)，消息收發(fā)的耗時；另外對于性能方面相關(guān)的功能還會看：App啟動時間，核心功能打開時間和App耗電量等數(shù)值。一般說來，對于重要功能，會在發(fā)布前就會對這些數(shù)據(jù)的變化進行一個預(yù)測，對于不符合預(yù)期的變化會重點排查。
3. 小范圍發(fā)布階段：等到在員工群體里，新功能被證明是有效，穩(wěn)定，無害的時候，F(xiàn)acebook會將GK開啟到1%~5%的用戶范圍。這里主要是兩點考慮：
a) 對系統(tǒng)進行壓力測試，對于一些新的后臺功能（比如：語音消息，VoIP電話，視頻聊天，或者 轉(zhuǎn)賬功能），看服務(wù)器是否能承受地住這么大的用戶流量。一般來說：5%，10%，30%，50% 是常見的幾個壓力測試坎，過了50%基本上沒有問題；
b) 看用戶和媒體對于這個功能的評價。一般來說，PM會收集TechCrunch，VentureBeat，Wired上面的媒體評測，發(fā)到內(nèi)部群里給大家分享；也有在Twitter上面搜索用戶對此功能的討論。
4. 全部發(fā)布階段：等到服務(wù)器確認能抗住所有流量，這時會將GK開到95~98%的用戶，同時依然保留2%的參照組作為對比用。這個階段最重要的是看 data dashboard 上的各種監(jiān)控數(shù)據(jù)，看是否和其他預(yù)期的一樣，至少一些關(guān)鍵的指標不能出現(xiàn)下滑。
5. 收尾階段：技術(shù)人員開始修改程序代碼，把相應(yīng)的GK和舊功能代碼刪除，這樣下一個或者下下個新版本將擁有純粹的新功能X代碼。這一步，一般會經(jīng)常1個月或者幾個月的時間，而且最終純粹的X代碼發(fā)布會很謹慎，因為一旦上線給用戶，功能X的出現(xiàn)會不受Facebook server的控制；假設(shè)突然出現(xiàn)App端的惡性bug，F(xiàn)acebook除了馬上發(fā)布一個新版App，等待App Store審核，同時拜托用戶馬上升級之外沒有任何辦法。
綜合來看，灰度發(fā)布 (shadow release) 和 A/B testing的特點和注意事項：
前端代碼預(yù)先發(fā)布；且有可能同時多套不同版本的代碼存在；
移動端或者前端MVC的代碼需要按照一定頻率獲取來自服務(wù)器的控制信息，從而展示相應(yīng)的形態(tài)；
后臺可以對發(fā)布進行精密的控制。
比如說：發(fā)布給多少比例的用戶，用戶所在區(qū)域等；并且即使在開放給100%用戶后，只要 GK檢查 沒有清楚，則server仍然可以遠程控制（或回滾）試驗中的功能。在某些嚴重bug出現(xiàn)的情況下，可以完全回滾某一功能。
注意：由于有A/B testing的原因，不同用戶A和B坐在一起，都剛剛下載和安裝了最新的Facebook App，但是打開app后所看到的功能（甚至UI布局）卻可能不一樣；并且對于同一用戶，今天看到的app里展示的功能可能和明天展示的也不一樣，即使他并沒有更新自己的app。
其實，微信早在幾年前就已經(jīng)借助此方式來進行測試和數(shù)據(jù)采集（微信團隊的主力在2012年時來Facebook訪問，當年我們FB的一些工程師和他們的一些工程師+張小龍有對于產(chǎn)品和技術(shù)上的深度討論）。比如說微信的一大特點是右上角的快捷菜單：
上面的選項和順序就是在server端進行控制，如果它想，隨時就可以改變。而且也有可能不同人的不一樣
比如我的微信是在北美下載和注冊的，我的列表進行少一些，另外我的發(fā)現(xiàn)里面的京東購物也比中國區(qū)的朋友晚出現(xiàn)了將近一年；另外我從來沒看到過任何朋友圈廣告。
Apple官網(wǎng)其實不支持這種server遠端控制app client的邏輯，因為它對于App store的審核有很大的阻礙。但是Apple一直對此一直睜一只眼閉一只眼。
iOS程序員都知道，Objective C是純動態(tài)語言，所有的函數(shù)都是虛函數(shù)，也就是說任何函數(shù)調(diào)用都可以在runtime時改變（特別有變態(tài)的 method swizzling 機制）。這就導(dǎo)致了當用戶下載了你的app之后，可以本地hack你的GK開關(guān)。
之前就有很多次，F(xiàn)acebook發(fā)布了一個新版本后，那些iPhone界的破解高手就開始研究Facebook app，然后找到好些GK值，人為地把它們打開，然后嘗鮮未開放的新功能；有時還會把一些功能的使用體驗寫到博客里，或者發(fā)給 TechCrunch 用與報道。后來使得Facebook內(nèi)部把比較重要有戰(zhàn)略意義的功能，直接用 compile flag 將其從 product build 中剝離。
最后也是最重要的一點：從上面可以看出，對于整個灰度發(fā)布還有A/B testing，不管是產(chǎn)品本身還是做灰度發(fā)布的系統(tǒng)，都有著不小的開發(fā)量。
也就是說：灰度發(fā)布+ A/B test一方面會減慢產(chǎn)品迭代速度，另一方面會大大提高迭代穩(wěn)定性的。
這對于特別是初創(chuàng)公司（成立半年以內(nèi)，用戶量不大的）要慎用（或者明確說來：禁用）。然而對于發(fā)展得不錯的創(chuàng)業(yè)公司，特別是在同質(zhì)化競爭比較嚴重（中國特色）的時候，要盡快地開始使用 A/B test。
比如：Nice和In，去哪兒和攜程（合并之前） 這種。在做 A/B test 方面，我覺得國內(nèi)做得很不錯的創(chuàng)業(yè)公司公司是 AppAdhoc；創(chuàng)始人 王曄 有著很強的技術(shù)背景，之前一直在 Google mountainview 效力。公司網(wǎng)站：吆喝科技 AppAdhoc 。 我之前去看過他們產(chǎn)品的界面和使用，和FB的inhouse系統(tǒng)相似度很大；個人還覺得他們的UI更加接近于大家習(xí)慣的 bootstrap 風格，而不是 FB 自己的藍色風： 吆喝科技 AppAdhoc （感興趣的公司，可以我直接幫你們推薦）
(未完待續(xù) -- 番外篇：Facebook里的一些關(guān)于 growth hacking 的趣事、囧事、以及那些 Facebook 曾經(jīng)踩過的坑）
——Do have the faith in what you love
【作者介紹】覃超，前FB工程師，現(xiàn)為FREES技術(shù)合伙人。感興趣的可關(guān)注其微信公眾號： qc_empire。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
