嘉賓 | 韓云飛

整理 | 云昭

字節(jié)跳動內(nèi)部有著非常濃厚的數(shù)據(jù)文化和實驗文化，數(shù)據(jù)中臺已經(jīng)成為研發(fā)流程中的新基建，A/B測試也基本上是整個研發(fā)鏈路上的必經(jīng)一環(huán)。那么如何將數(shù)據(jù)驅動有效應用在研發(fā)體系中呢？

日前，在51CTO主辦的WOT全球創(chuàng)新技術大會上，火山引擎DataTester技術負責人韓云飛從“研發(fā)流程中無處不在的數(shù)據(jù)驅動”、“如何建立可持續(xù)的數(shù)據(jù)驅動文化”、“數(shù)據(jù)驅動的ROI”三個方面，帶來了以“構建數(shù)據(jù)驅動的新型研發(fā)體系”為主題的精彩分享。現(xiàn)整理如下，希望能對諸君有所啟發(fā)。

無處不在的數(shù)據(jù)驅動

字節(jié)跳動在整個研發(fā)流程中，數(shù)據(jù)驅動無處不在。首先，以火山引擎的AB測試為例，探究研發(fā)流程中數(shù)據(jù)驅動。

火山引擎A/B測試，由來已久。包括抖音、今日頭條的名字都做過A/B測試，今天再爆個料，西瓜視頻的名字也做過A/B 測試，我還有幸參與過這件事，當時取的名字叫“咸蛋視頻”，如果沒有AB測試，也許現(xiàn)在用的就是“咸蛋視頻”這個名字。

平臺自建立之初至今，已經(jīng)承載著500+業(yè)務線、150W+實驗總量的能力，日新增實驗2000+，同時運行試驗3W+的。

AB測試，究竟是怎樣支撐這樣海量的實驗和這么多的并行度的呢？

首先在數(shù)據(jù)層我們是有SDK來采集我們端上的埋點和服務端的埋點，還包括用戶進組的信息。在數(shù)據(jù)集成上，其實我們會有大量用戶業(yè)務的數(shù)據(jù)和第三方的數(shù)據(jù)，我們通過數(shù)據(jù)集成的能力把它進入到我們的系統(tǒng)。

在功能層，它又分成幾個模塊。首先是從整個實驗的設計、實驗的配置、調試、數(shù)據(jù)報告，包括這種出結論，以及上線發(fā)布，這些都歸由實驗管控的模塊來負責。

做實驗最重要的是要來評估報告，所以我們在實驗報告里面其實提供了包括執(zhí)行度的檢驗、統(tǒng)計的分布，包括實驗數(shù)據(jù)的趨勢，還有一些指標的配置。還有更多的能力，這里不再贅述。

除此之外，我們還配套了一些比較好用的工具，包括比如說實驗受眾管理，因為我們做實驗其實有時候會針對于特定的用戶群體，比如我的新用戶，某個城市的用戶，甚至于說它有一些用戶的畫像。

還有業(yè)務目標管理，隨著接入的業(yè)務線越來越多，我們是想沉淀出可復制的經(jīng)驗，可能用于提升留存，或者是其他的業(yè)務目標，進一步將它拆解成業(yè)務上有哪些事要做，最終通過指標跟實驗之間建立關聯(lián)，未來其他的業(yè)務線再做類似的事，或者同一個業(yè)務線到了第二年，可以考量之前針對這個指標到底做了哪些實驗。

除此之外，我們還提供了端到端的實驗模板，包括比如編程實驗、多鏈接實驗、可視化實驗，還有針對于不同的場景，推送運營的實驗等。

在接入層其實我們提供了SDK以及分流，來給各種業(yè)務系統(tǒng)包括會話層的服務端、客戶端，還有一些to B的其他的小程序做一些對接。

應用層，我們提供了面向不同行業(yè)的解決方案，包括比如在泛互聯(lián)網(wǎng)，其實泛互聯(lián)網(wǎng)分得更細，有內(nèi)容、電商、社交、工具。金融其實包括銀行、證券、保險，也都會用到這樣的能力。包括在大消費的行業(yè)，比如包括家電、客戶、汽車行業(yè)等等。

接下來，我們一起看看研發(fā)流程中怎么使用數(shù)據(jù)驅動。 

開發(fā)新功能的正確姿勢是什么?

假設PM提了一個需求，如果要給抖音增加一個“熟人tab”，如果在數(shù)據(jù)驅動情況下，我們是怎么做這件事呢？

我們在產(chǎn)品評審的環(huán)節(jié)之后，會增加兩個東西，一個叫做埋點的設計，一個叫做AB方案的設計。其實從前面開始，PRD的方案開始，就可以猜出來，它可能是提供了不只一種方案。tab，到底是加在頂部，還是加在底部？策略到底應該是什么樣的。這是一個不確定的事。

草率的決定可能會對整個抖音大的生態(tài)有很大的影響。所以其實是需要來試驗，先小規(guī)模、小流量的來試驗。

我們可能就有這樣一個方案。

比如我們有了V1組和V2組，把熟人tab加了進去。這時候通過驗證各自的流程時長等指標得到最終的實驗結論，發(fā)現(xiàn)V2組是比較好的，對社交價值有更為顯著的提升，就把這個方案全量上線。 

怎樣才能做好一次復雜系統(tǒng)重構?

今日頭條是一個通用信息平臺。頭條早期的信息流服務是用一個Python的單體服務。隨著業(yè)務發(fā)展迅猛，流量在爆發(fā)式增長，業(yè)務工程上的復雜度也在急劇升高。為了更好地長期支撐業(yè)務發(fā)展，信息流同學做了一次大規(guī)模的服務化重構：

語言選型從Python切換到了golang，從單體服務架構演變成了分層的微服務架構。以往大家做重構時更多關注質量、性能等技術上的指標，以為這樣就夠了，其實是對用戶體驗和業(yè)務目標的忽視。這樣一次大規(guī)模重構，設計實現(xiàn)并沒有太久，但需要保障重構的信息流服務在各種業(yè)務指標上是不能有損的，這就花了大半年的實驗去做AB測試，通過幾十次AB測試不斷的灰度，分析業(yè)務指標影響，最終在大部分全局指標幾乎沒有影響，甚至有些關鍵指標正向的情況下完成了這個復雜系統(tǒng)大規(guī)模重構上線。

Bugfix難道不是應該修復完就上線?

這是一個我們直播的場景，整個直播的實驗背景我介紹一下。在一個精排的模型里用到了抖音的Universal Embedding，用到了一些特征，我們在召回階段也用一下這些特征，能夠讓召回的模型學習到更多信息，提前做一些召回符合用戶興趣的一些內(nèi)容，保持召回和精排在一致性的情況下，能夠提升一些指標。

這個想法很好，但是由于配置的問題，導致文章的一些內(nèi)容特征獲取是失敗的，這個功能沒有成功上線?，F(xiàn)在對這個功能做了fix，那是不是fix完就能直接上線呢？其實是未必的。這個bug你會發(fā)現(xiàn)它很隱蔽，它不會造成用戶很明顯的感知，但是你的系統(tǒng)跟你設想的是不一致的。即使修了但是不是真的修了就是好的呢？我覺得也未必，因為這個系統(tǒng)本身太復雜了，加了這個特征，如果沒有用，但它讓系統(tǒng)變得更復雜了，也不是一件好事。更不用說還有負向的風險。所以我們還是采用了AB測試。我們分了新用戶、老用戶分別去測，發(fā)現(xiàn)對于新用戶其實是沒有什么實質性的影響，指標就是在波動。這是可以理解的，新用戶可能本身就沒有太多的特征可以用。對于老用戶實驗，我們發(fā)現(xiàn)在他的人均的展現(xiàn)上和人均的閱讀上，都有0.3%左右的顯著提高。這個數(shù)字可能不高，但是對于抖音的體量，提升這么多，其實已經(jīng)是非常大的了。

上線發(fā)布如何更安全絲滑?

說下上線發(fā)布的例子，比如整個微服務中，上游服務對下游服務的調用過程中，很多流量直接打到各個機器上。在一些場景上，這么做會有一些問題。比如說新模型上線，模型需要機器來承載，在測試階段的流量顯然是遠遠不及真實上線時那么大。那么上線時能不能讓流量直接打過來，以及上線過程中重啟機器等等是否會帶來一些不太好的影響，這都是需要做AB測試的。

所以我們針對于上線場景，把AB的能力開放給基礎架構部門。首先根據(jù)預先的配置對目標服務進行切分，切分成不同的集群，比如說里面有AB的集群，還有基線版本的集群。集群切分之后，會調平臺的OpenAPI來開啟實驗，實驗里面配了一些環(huán)境參數(shù)，比如叫env。上游服務會通過RPC框架跟我們AB之間有一個交互，能讀到環(huán)境參數(shù)具體是什么，然后它就能夠把它的流量正確的調度到下游相應的集群。

這個過程中，需要多大流量，分配多少機器，開發(fā)人員可以通過OpenAPI是能夠把這兩件事關聯(lián)起來的，可以得到恰當?shù)奶幚?。線上的整個升級包括重啟機器等都可以非常平穩(wěn)、非常絲滑。 

SQL優(yōu)化讓人禿頭，怎么破?

再比如Spark SQL的優(yōu)化，首先想做好優(yōu)化，你需要知道m(xù)apper數(shù)、reducer數(shù)、excutor數(shù)等參數(shù)怎么設置，還要面料executor堆內(nèi)內(nèi)存不夠、driver堆外內(nèi)存不夠、序列化結果過大等讓人頭大的錯誤。

其次，SQL運維優(yōu)化會花費大量的人力，隨著數(shù)據(jù)量的上升，隨著整個邏輯越來越復雜，包括其執(zhí)行的環(huán)境也會變化。一次好的優(yōu)化不一定永遠都是對的，可能需要隨著數(shù)據(jù)量上漲、需要隨著環(huán)境的變化不停地去調，有可能未來也變得很差。我們有一些SQL專家是非常厲害的，他的SQL優(yōu)化經(jīng)驗都可以寫成一本書了，寫的SQL也確實比平均水平好很多倍。但是讓每位同事都具備SQL優(yōu)化的能力，其實既不現(xiàn)實，也沒有太大的必要。

針對這件事怎么做更好呢？我們大數(shù)據(jù)的同學想到了AB測試。

在數(shù)據(jù)提交的階段引入AB測試，在開啟任務的時候能夠開啟一個優(yōu)化列表，這個過程中我們團隊開發(fā)了一個叫做DataOptimizer的優(yōu)化引擎，會根據(jù)任務來不斷優(yōu)化，比如它歷史跑的執(zhí)行情況，環(huán)境數(shù)據(jù)等，最終會讓你進行一些調優(yōu)，調完之后看效果。最終我們發(fā)現(xiàn)，這套優(yōu)化系統(tǒng)會比專家經(jīng)驗還要好5%。

AB測試作為研發(fā)全流程基礎設施

因此，把剛才的案例串聯(lián)起來，包括開發(fā)、上線、BugFix、優(yōu)化、重構。你會發(fā)現(xiàn)在整個研發(fā)流程中，其實AB測試是可以像存儲、計算、網(wǎng)絡一樣，作為一個基礎設施來服務于整個研發(fā)流程。通過剛才的例子，大家應該會比較有體感，在我們整個研發(fā)的日常流程中，怎樣去把它用于我們的工作實踐，成為我們一個得力武器。

建立可持續(xù)的數(shù)據(jù)驅動文化

第二部分介紹一下基于我們前面的大量的實踐，我們總結出來怎么樣能夠在一個公司內(nèi)去建立一個可持續(xù)的數(shù)據(jù)驅動的文化。

前面說了很多案例，其實就是想讓大家更深有體會，通過這樣大量的實踐，得出來一些小小的知識，就是怎么來建立可持續(xù)的數(shù)據(jù)驅動的文化。

字節(jié)跳動的數(shù)據(jù)驅動的文化是怎么建立的？從我個人來看，我認為有三件事是非常重要的。

價值觀：從企業(yè)基因上鼓勵數(shù)據(jù)驅動

第一，價值觀。整個公司的價值觀是不是在引導數(shù)據(jù)驅動這件事，我做數(shù)據(jù)驅動是不是被鼓勵的、被允許的，不會是跟價值觀相違背的。

其次，我們會有一些平臺、工具來承載大家日常去做數(shù)據(jù)驅動這件事。

再次，在機制流程上我們有一個叫做Launch Review的機制，它來確保大家在日常中不會被變形，是真的在做數(shù)據(jù)驅動，而不是在做一個假的數(shù)據(jù)驅動。

我分別介紹這三部分。

首先第一部分價值觀，要從整個企業(yè)的基因上去鼓勵大家去做數(shù)據(jù)驅動，這里我截了幾個我們字節(jié)圈的截圖。這個例子是說，上次去出差，遇到一個老大爺，非常關注互聯(lián)網(wǎng)，喜歡刷抖音。他說了好多問題。但是他又提到，競品的自動播放不用刷，但是冬天特別冷，可能沒有暖氣，可能會比較舒服。還有一些創(chuàng)作者也提出來這樣的功能，就是我們公司比較鼓勵大家提出想法，包括跟用戶去交流。

大家直接就說，你其實可以做一個AB測試，或者我們把這個反饋給相關的抖音的業(yè)務部門，讓他們來做這樣一個嘗試，看是不是有收益的，或者能夠對用戶非常友好。所以我們其實是鼓勵大家不同的想法去涌現(xiàn)的。

第二個例子，其實跟這個有點相似。抖音自動播放完畢之后，上滑的功能，其實跟上面這個需求是非常相似的。其實已經(jīng)在做了，就有同學說，我希望能夠加入到這個內(nèi)測，先體驗體驗。

還有兩個例子更生動有趣的例子。

我們在北京有很多工區(qū)，有一個互金的工區(qū)，有一天行政把馬桶圈給換了，有同學就反饋說，好像很尷尬，非常麻煩。我們行政的同學就在下面回復，其實這件事是我們在做一件AB測試，是非常小的流量，只不過這個同學比較倒霉，剛好可能命中了實驗組。我們的行政同學就跟進去解決。其實你會發(fā)現(xiàn)，到行政這樣離研發(fā)流程非常遠的序列都在積極參與，已經(jīng)在嘗試把數(shù)據(jù)驅動的理念用于他們的生產(chǎn)。我覺得我們做研發(fā)就更需要做了。

其次，還有大家已經(jīng)形成了很多段子，比如大家在內(nèi)網(wǎng)發(fā)“我要做可樂雞翅，到底是應該放可口可樂還是放百事可樂”，其實這個問題猛然問到你，你可能也不一定能那么好的回答起來，到底哪個口味更好，這個就需要試，有同學就說你需要自己在家AB測試一下。

數(shù)據(jù)平臺：從數(shù)據(jù)應用把門檻降到最低

剛才講到價值觀和企業(yè)文化，接著我們講第二個，我們需要一個好的工具。前面的分享講了底層基建，怎么樣把數(shù)據(jù)弄進來，大家直接可以看數(shù)據(jù)，怎么治理數(shù)據(jù)之類。到這里其實我們想強調的我們的特色我們是在數(shù)據(jù)應用層做了比較多的工作，去降低大家的使用門檻。

我們拿三個我們的數(shù)據(jù)應用層的工具舉例。比如我們的DataFinder，它其實是一個用戶行為分析的工具。它有兩個典型的功能就在降低門檻。一個叫做場景模板，它會根據(jù)大家不同的業(yè)務場景，甚至于不同行業(yè)的需求，可能有40多個模板，企業(yè)來了之后，也許可能一開始不知道怎么樣把看板搭起來，這個模板就給你參考，告訴你要做運營該怎么做，我要做支付轉化該怎么建看板。其次我們還提供了看板的洞察，就是背后我們其實用了一些AI的能力，這個數(shù)據(jù)假設有一些波動，我們告訴你它可能真的是波動了，雖然每天都在波動，有一些集群點的偏離，發(fā)現(xiàn)它也許有一些有意思的地方，我們會把這個東西告訴你，我們幫你分析出來這個點，也許它不一定是完全對的，但可能我們會有一個概率的保證。但它就相當于代替了一部分大家原來手動分析的功能。

我們的DataTester就是AB測試的工具，里面也提供了可視化編輯的能力，我們把SDK接入之后，我們的一些PM、運營同學可能直接就在網(wǎng)站上比如改變一下它的Slogan、改變一下它按鈕的文案、甚至一些顏色，能做一些所見即所得的AB測試。在運營觸達上也是，我們接通了很多通道，運營、增長的同學來到我們平臺上，可以直接測試一下不同的推送時機、不同的推送文案、不同的頻次，想到的都可以去試。

還有一個DataWind，它是一個BI的工具，它提供的其實就是可視化的拖拉拽分析，在有這個平臺之前原來是寫SQL非常多，但仍然還是會有更多人不會寫SQL。我們通過把想要的數(shù)據(jù)，比如它的一些指標、維度通過拖拽建立一個數(shù)據(jù)集，直接就能去使用。這里面也提供了一些比較偏智能化的能力，比如自動歸因，來幫你發(fā)現(xiàn)整個數(shù)據(jù)集、數(shù)據(jù)看板中的一些增長/下降是什么維度上的變化引起的。

總之，這些能力都是在幫助大家降低門檻。

Launch Review：業(yè)務一號位的科學決策流程

Launch Review是字節(jié)的一個傳統(tǒng)，公司業(yè)務線負責人會對大家做的事情進行科學決策，具體的流程流程如下。

每一周或雙周，我們部門都會主持這樣一個例會，大家會對做的一些算法迭代的實驗或者產(chǎn)品的實驗，來做一個總結分析。中間會有包括部門的負責人、業(yè)務方、peers等很多人來聽，大家會進行提問和互動。但最終是要部門的一號位來做出決策，確定是不是能上線。

有時候實驗做得正向了，并不一定能上。如果只是在某些指標正向了，但是在一些更重要的地方?jīng)]有做出改進，甚至可能讓整個系統(tǒng)變得更復雜了，但收益提升卻不足夠，這樣也上不了，這樣要去考慮更好的方案。有時候你會發(fā)現(xiàn)它負向了，也能上，為什么也能上？大家會判斷，它可能損失了一些時長，甚至影響一部分廣告收入，但是用戶體驗變得更好了，或者對產(chǎn)品這個階段是非常重要的，也許這個事情是可以上的，這都需要部門的領導業(yè)務一號位來做好平衡。

總結一下，這個流程體現(xiàn)了下面幾個點。

復盤的文化：復盤是需要天天做，日常每天都要做的，我做這件事到底它的價值是什么，SWOT分別是什么。

保持信息透明：我要上線了，這件事是怎么做的，為什么做，5W1H到底是什么，大家要始終保持信息透明的。比如推薦系統(tǒng)有那么多工程師在改進，現(xiàn)在就是一個非常黑盒的系統(tǒng)，但是對于部門的一號位或者非常核心的負責人來說，他還是要非常清楚里面的一些關鍵的東西到底是怎么work的。

全局視角：其實通過這個機制，就能保證大家每次上新的東西的時候，他們會思考這個東西對我既有的系統(tǒng)加上去之后，整個系統(tǒng)是長什么樣子，這樣能夠幫助業(yè)務一號位總攬全局，這樣在新的改進加進來之后，才能做出更趨全局最優(yōu)的決策。

經(jīng)驗沉淀：我們通過這種比較開放的會議，鼓勵讓大家都能參與進來，互相借鑒，也許抖音做了一件什么改進，頭條的人說我也可以拿去試試，這樣大家的想法收益就能夠無限的放大。

數(shù)據(jù)驅動VS信仰判斷：正向的不一定能上，負向的也許可以上。數(shù)據(jù)驅動不是唯一，數(shù)據(jù)驅動是你要在業(yè)務價值信仰之間跟數(shù)據(jù)驅動之間做一個平衡和判斷，它是來輔助人的科學決策。

數(shù)據(jù)驅動的ROI

前面講了怎么建立數(shù)據(jù)驅動的文化，但是在降本增效的大背景下，如果要落地數(shù)據(jù)驅動，它的ROI應該是什么樣的，是不是值得大家去做呢？

數(shù)據(jù)驅動的成本

我們先講成本。首先有這樣三件事：

第一，我們需要在企業(yè)文化上進行數(shù)智化轉型，這里我用了智能的“智”，而不是數(shù)字的“字”。這是有區(qū)別的，我們不能光是有數(shù)據(jù)的，還需要數(shù)據(jù)要真正驅動業(yè)務。數(shù)據(jù)如何跟業(yè)務結合，來輔助進行決策。

第二，我們需要在整個研發(fā)流程上做數(shù)智化轉型。因為很多互聯(lián)網(wǎng)企業(yè)、科技企業(yè)很重要的流程就是在做產(chǎn)品的研發(fā)、業(yè)務的研發(fā)，最終在最核心的流程中是否能夠讓數(shù)據(jù)被驅動，而不是讓大家在一個錯誤的方向上越走越遠，這也是非常重要的。

第三，為了完成以上兩點的落地，需要搭建一個以數(shù)據(jù)驅動的基礎設施，這里有兩種方法，一個是自建，可以根據(jù)自身的實際情況來進行，再一個是外采，最終要能幫助業(yè)務來實現(xiàn)價值。

總結成一句話，你需要讓整個企業(yè)變成一家數(shù)字原生的企業(yè)，這就是付出的成本。

當企業(yè)變得數(shù)智化原生，意味著企業(yè)進化得更好了，這本身也是一種收益。

這里再分享個小故事。我們之前有個用戶，后來他從A公司離職了，去創(chuàng)業(yè)了，去到B公司，他剛到B公司又采購了我們的產(chǎn)品。后來我們就經(jīng)常會跟他交流，你為什么那么快就想到用我們的產(chǎn)品呢？他說他們對工具還是非常挑剔的，企業(yè)辦公用Lark、產(chǎn)品設計用Figma、AB測試就用DataTester。他解釋說，除了好用，還能間接幫助他們?nèi)谫Y。對工具的挑剔給投資人留下了深刻的印象，最終體現(xiàn)出團隊品味、能力和前景。

數(shù)據(jù)驅動的收益

講完成本，我們來看下收益。數(shù)據(jù)驅動的收益，一言以蔽之，“幫助業(yè)務團隊低損耗地朝正確方向持續(xù)小跑！”

第一，它能激發(fā)創(chuàng)新，提升收益。只有大家對業(yè)務比較有Owner意識，才能去貢獻自己的想法，才能激活這個企業(yè)的發(fā)展，大家才會有更多的創(chuàng)新涌現(xiàn)出來。

其次，我們能夠低成本低去試錯，就是試錯成本會降低，人效是提高的。比如通過AB測試要搞兩個版本，好像聽起來成本是增加的，其實是未必的。也許你拍的那個版本壓根兒沒有用，甚至帶來了比較大的負向，這個損失是更大的。我們通過在非常小的范圍去做這樣的驗證，反而是降低成本，提高人效的。這個對應的，可能有一定的損耗，它的損耗對應的收益是，你能持續(xù)一直做正確的決策，你也不用做AB測試，但是誰能保證你一直對呢？所以數(shù)據(jù)驅動是有損耗的，但它的損耗是可接受的必要成本。

再次，通過數(shù)據(jù)驅動是能夠積累大家的經(jīng)驗的，最終提升整個團隊的決策力。我們剛才講的Launch Review，它其實是讓整個團隊共同決策個通過數(shù)據(jù)驅動最終實現(xiàn)了一個決策的平民化和公平化。

最后，我們整個研發(fā)流程做的大部分事情，收益是可以被量化的，這樣就知道什么改進對業(yè)務幫助更大，最終就能賦能給我們公司的管理團隊，讓大家在管理上有更好的科學的輔助。

這就是我想講的整個數(shù)據(jù)驅動的收益。

嘉賓介紹

韓云飛 火山引擎DataTester技術負責人

火山引擎DataTester技術負責人韓云飛。負責火山引擎企業(yè)級實驗平臺團隊，致力于打造業(yè)界最先進好用的實驗平臺，把A/B測試變成驅動業(yè)務增長的新基建。從0到1參與搭建了字節(jié)跳動內(nèi)實驗中臺Libra，服務于抖音、今日頭條等500多個業(yè)務線；對外發(fā)布火山引擎A/B測試DataTester等產(chǎn)品。