2023-08-30 04:05:32 來源 : 字節(jié)跳動數(shù)據(jù)平臺
本文根據(jù) ArchSummit 全球架構(gòu)師峰會（深圳站）來自抖音數(shù)據(jù)研發(fā)負(fù)責(zé)人王洋的現(xiàn)場分享實錄整理而成（有刪減），本次分享主要包含字節(jié)跳動數(shù)據(jù)研發(fā)的模式與挑戰(zhàn)、DataOps理念在字節(jié)的具象 、DataOps產(chǎn)品化及落地、最佳實踐、未來展望五個部分，分享內(nèi)容皆來自于字節(jié)跳動業(yè)務(wù)實踐經(jīng)驗。
(相關(guān)資料圖)
字節(jié)在落地DataOps的過程當(dāng)中，與我們數(shù)據(jù)支持所采用的中臺工具+數(shù)據(jù)BP的組織模式相結(jié)合，由中臺工具團隊負(fù)責(zé)打造功能的基座，實現(xiàn)了數(shù)據(jù)開發(fā)的各項基礎(chǔ)能力并提供開放平臺，對數(shù)據(jù)BP團隊提供貼身的技術(shù)支持，同時也將這些能力通過火山引擎以內(nèi)外一體的模式輸出。所謂的內(nèi)外一體是指字節(jié)的各類數(shù)據(jù)工具如DataLeap在面向內(nèi)外部用戶使用上實現(xiàn)了一致性。
對于數(shù)據(jù)BP團隊來說，在落地DataOps的過程中，重點做了三件事情：第一件事是規(guī)范的制定，在字節(jié)內(nèi)部長期實踐過程中，我們認(rèn)為實踐團隊才是規(guī)范的最佳發(fā)源地；第二件事是基于中臺工具的開放平臺實現(xiàn)插件的開發(fā)，數(shù)據(jù) BP并不是一個純數(shù)倉團隊，其中也包含了部分工程團隊，與數(shù)倉一體的工程團隊可以將數(shù)倉日常的痛點以插件的形式實現(xiàn)并落地，不同數(shù)據(jù)BP團隊可以根據(jù)自己的特點開發(fā)不同插件；最后一件事是收益評估，DataOps推廣完了之后，也是放在 BP 來評估，而不是放在平臺來評估，中臺工具團隊就可以專注于能力本身，開發(fā)數(shù)據(jù) BP 團隊專注于整個規(guī)范跟價值。最后外部客戶可以同時享受到我們的平臺能力，以及沉淀下來的 BP 模式，這就是字節(jié)整個團隊在DataOps上落地的協(xié)作模式。
數(shù)據(jù)BP團隊做的好壞與否如何來評估，我們用了一套淺顯易懂的指標(biāo)0987來評價
0指不要出數(shù)據(jù)事故，這里的事故包括了時效、質(zhì)量等問題，由于我們支持了較多線上和資損場景，事故在我們的評價體系中是生命線；
9指需求滿足率，我們承接了來自多方的數(shù)據(jù)需求，希望能達成90%以上的需求我們都能按期交付的目標(biāo)；
8指分析覆蓋率，這個指標(biāo)指外部團隊基于數(shù)倉的查詢能80%使用到經(jīng)過我們建設(shè)和匯聚的表，而非原始表；
7指NPS 指標(biāo)，我們每個季度會面向所有提需用戶和數(shù)據(jù)使用用戶發(fā)放問卷，收集對應(yīng)的反饋信息，70%意味著大部分的同學(xué)對我們持正向評價且負(fù)向評價趨近于0；
在字節(jié)數(shù)據(jù)團隊當(dāng)前的支持模式下，由于支持模式多種多樣，覆蓋了各類核心決策及線上場景，我們遇到的首要挑戰(zhàn)是來自數(shù)據(jù)質(zhì)量的：
鏈路復(fù)雜 ：最長任務(wù)全鏈路節(jié)點數(shù)量上千個，單個任務(wù)的的下游數(shù)量最大也達到了千級別 變更頻繁 ：每周僅直播數(shù)據(jù)團隊數(shù)據(jù)鏈路變更次數(shù)就能達到上千次，涉及風(fēng)險場景上百次 事故易發(fā)： 質(zhì)量事故時有發(fā)生 ， 22年全年數(shù)據(jù)研發(fā)事故涉及到研發(fā)規(guī)范的占比56%在降本增效大背景下硬件成本也逐步變成數(shù)據(jù)團隊的一個核心挑戰(zhàn)，在過去我們控制成本與大多數(shù)公司一致，主要基于預(yù)算，先測算出一個全年計算和存儲資源目標(biāo)，然后基于預(yù)算開展治理動作，清理無效任務(wù)或降低TTL；但是現(xiàn)在需要朝著需求的精細(xì)化控制方向前進，需要進一步看清楚我做這個需求需要多少硬件成本，從而將硬件成本的管控精細(xì)化到需求層面
除去硬件成本外，我們的另一個成本大頭就是人力成本，我現(xiàn)在帶一個數(shù)據(jù)研發(fā)團隊，在每次進行HC盤點的時候我都會遇到兩個靈魂提問：
如何證明團隊當(dāng)前的狀態(tài)是高效的？ 如何用更少的人員創(chuàng)造更大的業(yè)務(wù)價值？這其實是一個很現(xiàn)實的挑戰(zhàn)，我們?nèi)绾巫C明一個數(shù)據(jù)團隊它的價值是什么？
既然面臨著這么多的挑戰(zhàn)，我們就要去思考如何能夠突破這些挑戰(zhàn)，從業(yè)內(nèi)取經(jīng)，我們發(fā)現(xiàn)DataOps就是一種能夠有效幫助我們解決上述問題的方案
我們認(rèn)為 DataOps 的核心包括以下部分
第一個是鏈接，所謂的鏈接是要打通從需求、開發(fā)、資產(chǎn)、用戶整個數(shù)據(jù)全鏈條的綁定關(guān)系。從功能上來講它比較簡單，解決了需求與代碼的關(guān)系問題，業(yè)務(wù)研發(fā)側(cè)早就已經(jīng)實現(xiàn)了這個能力，研發(fā)人員提交的每一段代碼，都能知道是哪個需求。但是在數(shù)據(jù)開發(fā)這件事情上，過去缺乏關(guān)注，所以首先需要做的事情是連接需求跟數(shù)據(jù)全環(huán)節(jié)。
第二個是規(guī)范，過去數(shù)據(jù)研發(fā)整個全流程較為缺乏規(guī)范的產(chǎn)品化，主要通過團隊內(nèi)部的文檔要求來承載，包括提需評審、模型開發(fā)測試、上線驗收這些環(huán)節(jié)，我們認(rèn)為 DataOps在規(guī)范上面最首要的事情是要把所有數(shù)據(jù)研發(fā)過程中的這些散落的規(guī)范產(chǎn)品化并嵌入到日常的開發(fā)鏈路中。
這張圖展現(xiàn)的是字節(jié)數(shù)據(jù)開發(fā)的dataleap套件能力，涵蓋了計算引擎、全鏈路開發(fā)、全域治理、資產(chǎn)等工具，這樣的一站式大數(shù)據(jù)開發(fā)套件，能夠幫助用戶快速完成數(shù)據(jù)集成、開發(fā)、運維、治理、資產(chǎn)、安全等全套數(shù)據(jù)研發(fā)工作，幫助數(shù)據(jù)團隊有效的降低工作成本和數(shù)據(jù)維護成本、挖掘數(shù)據(jù)價值、為企業(yè)決策提供數(shù)據(jù)支撐。DataLeap不是一個產(chǎn)品，是一個套件(Suite)。形象的類比就是類似Office，多個產(chǎn)品相互配合，解決同一個大的問題或者叫解決方案，產(chǎn)品之間是相互合作輔助的關(guān)系。
這是字節(jié)整個 DataOps 的產(chǎn)品化的整體框架圖，核心提供的一套DataOps敏捷規(guī)范研發(fā)平臺。以前有一種模式是平臺團隊自己全包，把這些所有的規(guī)范全部給制定好，由平臺團隊推給數(shù)據(jù)開發(fā)團隊，但這種模式不太適合我們，因為平臺團隊離業(yè)務(wù)遠。
我們認(rèn)為在這種情況下平臺應(yīng)該選擇優(yōu)先提供開放的能力，這里的開放能力包括開放數(shù)據(jù)與接口、開放流程等等，有了這套開放能力，意味著所有的數(shù)據(jù)開發(fā)團隊可以自己去編排流程，去做自己的規(guī)則規(guī)范。
另外我們發(fā)現(xiàn)開發(fā)團隊做好之后，這套DataOps敏捷規(guī)范研發(fā)平臺在所有的數(shù)據(jù)開發(fā)團隊都通用，舉個例子，測試的能力在字節(jié)不是在平臺做的，有專門的數(shù)據(jù) BP 團隊，實時這塊有特殊訴求：發(fā)布完了之后數(shù)據(jù)要做盯盤，盯住實時數(shù)據(jù)的變化。依托開放平臺提供的數(shù)據(jù)支持，在直播場景下會提供給到主播一些實時的數(shù)據(jù)，去輔助他們做及時的決策。這些實時數(shù)據(jù)包括用戶的數(shù)據(jù)、用戶的畫像等等，主播可以基于這些用戶的畫像去調(diào)整話術(shù)?；陂_放平臺 ，數(shù)據(jù)BP團隊做任務(wù)的整個發(fā)布能力，之后我們發(fā)現(xiàn)這套能力可以通用。
簡單的給大家看一下字節(jié)現(xiàn)在已經(jīng)上線的內(nèi)部版本的功能，包括了需求管理的各個維度，當(dāng)然需求管理這里其實核心的思路是讓需求能夠進入到數(shù)據(jù)研發(fā)的全流程當(dāng)中，大家可以看到我們會做需求的準(zhǔn)入要求，以及跟開發(fā)過程以及交付綁定，然后需求的進度追蹤、價值評估等相關(guān)的一些事情，這是一個標(biāo)準(zhǔn)需求流水線，是字節(jié)需求管理平臺上的一套流程，就是從需求開始，初評、詳評、排期、研發(fā)驗收、價值反饋結(jié)束。
這是需求綁定頁面，在做任務(wù)開發(fā)的時候需要對當(dāng)前的一些需求做綁定，當(dāng)然這只是提供了需求綁定開發(fā)環(huán)節(jié)的一個圖，我們也會有包，比如說資產(chǎn)環(huán)節(jié)以及任務(wù)環(huán)節(jié)等各種修改環(huán)節(jié)都會跟需求做綁定。這個功能很簡單，但是需求的全鏈路串聯(lián)為字節(jié)帶來的收益非常大，解決了第一個是可度量所有全流程的問題。
第二個是流水線管理，字節(jié)的流水線管理包括測試流水線、發(fā)布、離線、實時任務(wù)管理、任務(wù)優(yōu)先級管理等相關(guān)的能力，這是現(xiàn)在線上跑的一個任務(wù)，跑完的流水線的狀態(tài)，就發(fā)布會做登記、檢測、檢查、review，然后定時發(fā)布任務(wù)、盯盤等確認(rèn)等相關(guān)的動作。
重點講一下這里的發(fā)布跟測試環(huán)節(jié)，這兩塊在很多公司其實是有測試環(huán)境的，但是在數(shù)據(jù)量特別大的場景和數(shù)據(jù)，或者較為復(fù)雜的場景下測試環(huán)境是沒數(shù)據(jù)的。測試環(huán)境跟業(yè)務(wù)研發(fā)相比，沒辦法涵蓋各種各樣的問題，比如說銀行場景下測試環(huán)境和生產(chǎn)環(huán)境肯定是隔離的，但是在字節(jié)這種互聯(lián)網(wǎng)場景下我們的選擇是不分離，我們的發(fā)布和測試其實是基于的是同一套數(shù)據(jù)，同一套環(huán)境，那如何做測試跟生產(chǎn)的一個隔離？核心點在于我們要求所有沒有經(jīng)過發(fā)布流水線的任務(wù)是不能寫生產(chǎn)的表的，讀任何生產(chǎn)的表，但是不能寫任何生產(chǎn)的表。這樣帶來的好處是我們的測試和生產(chǎn)是完全一致的，同時也能保證測試完了之后直接推到生產(chǎn)上去，這樣下來后面的測試、 QA 介入的成本是極其低的，這是字節(jié)采用的一種方式。
做了這些工具之后要如何去推廣？這也是今年初字節(jié)面臨的問題，就是如何在公司內(nèi)大范圍去落地 DataOps 的能力。最早開始推得很辛苦，也遭遇了很多挑戰(zhàn)，不過也總結(jié)了一些經(jīng)驗。
第一個叫做鯰魚效應(yīng)，所謂的鯰魚效應(yīng)因為是數(shù)據(jù)BP 在主導(dǎo)這件事情，所以主導(dǎo)團隊可以先推起來。比如說在直播場景下先試用拿到非常多的指標(biāo)，總結(jié)經(jīng)驗，我們可以帶著這些指標(biāo)和經(jīng)驗去和其他團隊溝通，以提高人效的角度切入，在這種情況之下，有的團隊就會愿意來學(xué)習(xí)試用。
第二個是拆箱即用，我們向其他 BP 團隊提供的時候，其他 BP 團隊不需要多做任何其他的事情，只需要打開他的流程開關(guān)就 OK 了，切換路徑成本是非常低的。
第三個是自頂向下，類似的像 DataOps 這種工具跟能力，一定是需要先拿到自頂向上，或者是來自于業(yè)務(wù)側(cè)更高層的認(rèn)可之后，才能夠持續(xù)不斷地往下推，類似規(guī)范的事情，不是一個自下往上能推得起來的。
一個研發(fā) leader 肯定會關(guān)注研發(fā)效能問題，這里給大家分享一套字節(jié)基于研發(fā)效能的指標(biāo)牽引體系，該體系有四個維度的度量指標(biāo)，包括效率、質(zhì)量、資源投入、收益等相關(guān)的一些指標(biāo)。這些指標(biāo)是我們參照業(yè)務(wù)研發(fā)來形成了一套數(shù)據(jù)研發(fā)指標(biāo)體系，我們會去關(guān)注數(shù)據(jù)需求的交付周期、定容率、交付數(shù)、缺陷修復(fù)時長、線上事故、業(yè)務(wù)研發(fā)的配比。最后是重點專項相關(guān)的一些事情。這里面除了最后一個是需要人工去干預(yù)的，其余的現(xiàn)在都能做到線上化的統(tǒng)計，這是非常方便的。
所謂管理者視角是圍繞數(shù)據(jù)開發(fā)團隊的價值和未來，通過開放讓數(shù)據(jù)團隊有可輸出的專業(yè)價值。對于數(shù)據(jù)團隊來講有兩類價值，一類叫做業(yè)務(wù)價值，一類叫做專業(yè)價值。業(yè)務(wù)價值很好講，是我為業(yè)務(wù)做了多少個需求，其中哪些重點項目重點參與了，最后是為業(yè)務(wù)帶來了多少效率上的提升，通過某些數(shù)據(jù)的手段讓業(yè)務(wù)拿到了多少收益。其次是專業(yè)性的價值，這個事情對于很多數(shù)據(jù)團隊來講是一個很困擾的難題，數(shù)據(jù)團隊到底在業(yè)界、在公司內(nèi)部有哪些是不可替代的？有哪些是專業(yè)性的東西？這里我們在做 Datops 實踐的時候，發(fā)現(xiàn)通過開放讓數(shù)據(jù)團隊自己有可輸出的專業(yè)性價值，這非常關(guān)鍵，這能讓數(shù)據(jù)團隊很充分地來參與到這件事情當(dāng)中來。
在開發(fā)者視角層面，核心的事情是如何獲得工作當(dāng)中的成就感，這一點是留住人的關(guān)鍵：
認(rèn)可&執(zhí)行：規(guī)范本身是反人性的，在團隊內(nèi)落地DataOps需要充分溝通，結(jié)合團隊調(diào)整與個人發(fā)展，講清為什么，避免粗暴落地 參與&貢獻：構(gòu)建人人可參與的開發(fā)環(huán)境，讓數(shù)據(jù)開發(fā)可以深度的參與到流程制定與落地的過程中來，促進個人影響力的提升落地DataOps的收益主要包含規(guī)范、質(zhì)量、效率三部分，具體來看：
規(guī)范：在不同方向上規(guī)范制定與復(fù)用，保障流程100%落地 質(zhì)量：系統(tǒng)性的解決風(fēng)險場景上的研發(fā)流程問題，因研發(fā)流程導(dǎo)致的數(shù)據(jù)質(zhì)量事故數(shù)歸0 效率：通過更可靠的交付避免返工，同時疊加提效能力，預(yù)計可提升研發(fā)在業(yè)務(wù)需求滿足中的開發(fā)效率10%+最后是關(guān)于數(shù)據(jù)研發(fā)未來的展望，首先想談?wù)剺I(yè)務(wù)價值：
數(shù)據(jù)需求價值度量標(biāo)準(zhǔn) 基于需求價值最大化的調(diào)度策略數(shù)據(jù)需求的價值度量相對功能需求而言更為復(fù)雜，所以下一階段我們是希望能夠度量清楚數(shù)據(jù)需求的具體價值，然后實現(xiàn)基于需求價值最大化的調(diào)度策略，從而達成我們對于人效和成本的控制目標(biāo)。
關(guān)于質(zhì)量與效率，未來我們會主要關(guān)注以下三點：
基于大模型的需求對接能力 基于大模型輔助開發(fā)的能力 低成本的數(shù)據(jù)測試及驗證能力最近大模型特別火，我們認(rèn)為大模型參與數(shù)據(jù)研發(fā)是非常具有現(xiàn)實意義且具有挑戰(zhàn)的事情，不論從需求對接還是輔助開發(fā)視角上，大模型都能為我們提供更多自動化方案應(yīng)對過去需要依賴經(jīng)驗沉淀才能解決的問題；同時我們發(fā)現(xiàn)在字節(jié)的數(shù)據(jù)規(guī)模下數(shù)據(jù)測試的成本是非常高的，未來也希望探索低成本的數(shù)據(jù)測試的驗證方案。
DataOps理念在字節(jié)落地的成果后續(xù)也會通過火山引擎DataLeap對外輸出。火山引擎DataLeap是一站式數(shù)據(jù)中臺套件，能夠幫助用戶快速完成數(shù)據(jù)集成、開發(fā)、運維、治理、資產(chǎn)、安全等全套數(shù)據(jù)中臺建設(shè)，幫助數(shù)據(jù)團隊有效的降低工作成本和數(shù)據(jù)維護成本、挖掘數(shù)據(jù)價值、為企業(yè)決策提供數(shù)據(jù)支撐。
點擊跳轉(zhuǎn) 了解更多
