一、背景

在文章云音樂曙光埋點(diǎn)：還原數(shù)據(jù)理想國中，我們介紹了曙光埋點(diǎn)項(xiàng)目方案，該方案基于多端一致埋點(diǎn)對象樹建設(shè)管理，實(shí)現(xiàn)了統(tǒng)一自動化埋點(diǎn)和鏈路追蹤，方案高度還原了大前端埋點(diǎn)的理想狀態(tài)、具備較強(qiáng)通用性和擴(kuò)展性。我們圍繞這套埋點(diǎn)方案研發(fā)了配套的埋點(diǎn)管理系統(tǒng)，以承載及埋點(diǎn)規(guī)則數(shù)據(jù)管理、埋點(diǎn)設(shè)計(jì)、埋點(diǎn)研發(fā)、埋點(diǎn)測試、埋點(diǎn)上線等功能，本文主要介紹該平臺功能及建設(shè)思路。

二、平臺現(xiàn)狀介紹

經(jīng)過前幾期建設(shè)，我們已經(jīng)實(shí)現(xiàn)了一個適配研發(fā)流程的、按版本來管理的埋點(diǎn)數(shù)據(jù)管理平臺，其核心功能為：

• 1、承載埋點(diǎn)研發(fā)生命周期
• 2、承載埋點(diǎn)的元數(shù)據(jù)管理

我們的研發(fā)生命周期如下：

平臺在埋點(diǎn)元數(shù)據(jù)管理設(shè)計(jì)如下，參考和學(xué)習(xí)了版本管理工具的功能，并且充分考慮了客戶端的研發(fā)流程特點(diǎn)

• 1、客戶端每個大版本需求研發(fā)時，BI對埋點(diǎn)需求進(jìn)行分類，建立需求組?？梢岳斫鉃榛贛aster CheckOut出了多個分支。
• 2、BI在各需求組內(nèi)，按埋點(diǎn)需求設(shè)計(jì)埋點(diǎn)。設(shè)計(jì)完成后，平臺會計(jì)算出埋點(diǎn)的變更列表，如新增對象、新增血緣關(guān)系、修改參數(shù)、刪除對象、刪除血緣關(guān)系。
• 3、上述變更由BI指派到任務(wù)，交由開發(fā)處理
• 4、經(jīng)過一個版本迭代開發(fā)后，若任務(wù)開發(fā)測試完成處于可上線狀態(tài)，會被打上版本的TAG，并且發(fā)布上線，在Master產(chǎn)生一個新版本；未完成的任務(wù)，則可在后續(xù)版本迭代開發(fā)完畢后再上線。

相比版本控制工具，適配研發(fā)流程的版本控制具有以下特點(diǎn)：

• 1、支持部分變更上線：需求內(nèi)的變更可以自由篩選出來部分上線，可以類比為分支內(nèi)提交數(shù)個文件，可以篩選出幾個文件單獨(dú)合入Master
• 2、需要走研發(fā)流程才可上線：每個埋點(diǎn)變更都擁有獨(dú)立的研發(fā)流程控制和校驗(yàn)。這些流程(設(shè)計(jì)完成->開發(fā)->測試通過)需要走完后，才準(zhǔn)許合入Master。
• 3、模型更加復(fù)雜：不是簡單的文本，而是復(fù)雜的層級對象結(jié)構(gòu)。

三、我們遇到的問題和痛點(diǎn)

在上述研發(fā)流程模式的落地過程中，我們發(fā)現(xiàn)了以下問題和痛點(diǎn)：

• 1、落地質(zhì)量問題

漏埋：因?yàn)樯婕拜^多埋點(diǎn)事件、埋點(diǎn)參數(shù)的組合，在某些組合下，埋點(diǎn)沒有上報(bào)。

錯埋：埋點(diǎn)參數(shù)缺失或格式不正確。

歸因錯誤：埋點(diǎn)里的歸因字段設(shè)置錯誤、不合理。

• 2、落地效率問題

• 大量重復(fù)埋點(diǎn)代碼編寫：如果涉及大量對象埋點(diǎn)，埋點(diǎn)工作勢必成為大量重復(fù)勞動，影響研發(fā)效率。

• 埋點(diǎn)進(jìn)行增量變更時，無法知道改動了什么：平臺只展示了某個埋點(diǎn)全量信息，并未展示其增量改動（沒有類似版本管理工具的Compare視圖）。

• 3、功能痛點(diǎn)

• 有一些埋點(diǎn)長期停留在研發(fā)階段未上線（類比于寫代碼時開發(fā)分支落后Master多次提交，沒有去Pull Master獲取最新的主線代碼改動），導(dǎo)致這些埋點(diǎn)很可能是過時的，如果不進(jìn)行卡點(diǎn)直接上線，就會導(dǎo)致問題

• 埋點(diǎn)數(shù)據(jù)是按APP+端兩個維度隔離的，但實(shí)際運(yùn)用時存在內(nèi)嵌情況，如APP端可內(nèi)嵌WEB端H5頁面的功能，這種情況下，需要把原本隔離的數(shù)據(jù)進(jìn)行整合，如把部分WEB埋點(diǎn)樹掛載在APP端樹上。

針對以上問題痛點(diǎn)，平臺在近半年內(nèi)進(jìn)行了針對性的解決。

四、埋點(diǎn)質(zhì)量建設(shè)

解決該問題的思路為先解決源頭防止增量質(zhì)量問題產(chǎn)生，再解決存量質(zhì)量問題。

1、建設(shè)實(shí)時埋點(diǎn)校驗(yàn)功能，從源頭解決埋點(diǎn)質(zhì)量問題

客戶端埋點(diǎn)開發(fā)完成后，需要進(jìn)行"實(shí)時校驗(yàn)"，從而對被指派的埋點(diǎn)任務(wù)進(jìn)行測試覆蓋，其步驟如下：

• 客戶端連接到實(shí)時校驗(yàn)平臺，平臺根據(jù)該任務(wù)需求，生成埋點(diǎn)校驗(yàn)樹
  
• 客戶端上報(bào)日志，平臺根據(jù)埋點(diǎn)校驗(yàn)樹進(jìn)行校驗(yàn)
  
• 平臺根據(jù)測試情況，決定測試是否通過
  

需求范圍內(nèi)有埋錯：不通過，且可以查看日志看到具體為何不通過，如下圖所示

需求范圍內(nèi)有漏埋：默認(rèn)不通過，但事實(shí)推進(jìn)落地中，存在部分分支客戶端難以復(fù)現(xiàn)覆蓋的情況，因此我們也支持了勾選某些分支無需測試的功能，如下圖所示

• 若測試為不通過，則將卡點(diǎn)阻塞流程，后續(xù)無法正常上線
  

經(jīng)過實(shí)時埋點(diǎn)校驗(yàn)功能的上線后，我們封堵住了大部分埋點(diǎn)錯誤源頭，達(dá)到了較好效果。

2、建設(shè)線上埋點(diǎn)稽查功能，發(fā)現(xiàn)存量埋點(diǎn)問題并推進(jìn)解決

稽查功能定位為企業(yè)日志的統(tǒng)計(jì)分析，解決以下問題：

• 1、分析日志是否按規(guī)則正確輸出，檢測出少參數(shù)、參數(shù)取值錯誤、歸因錯誤等問題，并對這類問題進(jìn)行歸類，并可進(jìn)一步鉆取，直至能夠看到原始日志的樣本。
  
• 2、自定義靈活業(yè)務(wù)統(tǒng)計(jì)監(jiān)控、報(bào)表、報(bào)警。通過監(jiān)控、報(bào)表中數(shù)值變化報(bào)警來發(fā)現(xiàn)、輔助定位端上發(fā)版后一些bug。如：某些點(diǎn)位日志變少、PV/UV比例變化等。
  

為實(shí)現(xiàn)上述功能，需要對日志進(jìn)行采樣分析計(jì)算(可以理解為打上各種標(biāo)簽)，并且將計(jì)算結(jié)果存儲在能夠支持篩選、統(tǒng)計(jì)查詢功能的數(shù)據(jù)庫中，為典型的OLAP場景，我們選型時，采用了ClickHouse來完成這塊功能，其主要考量點(diǎn)如下圖所示

經(jīng)過稽查功能上線和推進(jìn)，我們的線上埋點(diǎn)錯誤數(shù)已經(jīng)下降了95%，并且還在逐漸降低中，達(dá)到了較好的效果。

五、埋點(diǎn)效率建設(shè)

• 使用模版引擎自動生成代碼 上文提到，埋點(diǎn)時涉及大量重復(fù)埋點(diǎn)代碼編寫，我們針對該問題使用模版引擎語言自動生成埋點(diǎn)代碼，且支持適配了安卓、iPhone、Web、RN等多套客戶端，把代碼提前生成好，能自動填寫的部分全部自動填寫，客戶端復(fù)制代碼后只需要把代碼模版里剩余部分補(bǔ)全即可，如下圖所示

• 展示埋點(diǎn)DIFF，讓開發(fā)更容易理解埋點(diǎn)改動點(diǎn)
  

我們開發(fā)了埋點(diǎn)DIFF功能，相比與版本管理軟件中的代碼文本對比，埋點(diǎn)元數(shù)據(jù)是一種更加復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，因此在服務(wù)端計(jì)算DIFF和前端界面展示DIFF上相對來說較復(fù)雜一些。如下圖所示，我們通過在原有界面上通過背景色來區(qū)分變更操作是新增、修改、還是刪除。

六、研發(fā)中埋點(diǎn)自動Rebase到最新Master

前文提到，有一些埋點(diǎn)長期停留在研發(fā)階段未上線，目前沒有pull master的功能，導(dǎo)致：

• 1、這些未上線埋點(diǎn)元數(shù)據(jù)很可能是過時的，如果直接上線會導(dǎo)致業(yè)務(wù)問題。
• 2、無法使用到最新Master下的新增對象，或者還在使用已刪除對象

因此我們對在需求池內(nèi)未上線的研發(fā)階段對象，每次上線后，都自動pull master處理。如下圖所示為一個未上線需求從安卓8.8.11 Rebase到 安卓8.8.12的過程，rebase后可能存在部分變更需要刪除或重新研發(fā)。

rebase算法的核心在于計(jì)算出Master和本研發(fā)分支對比同一個基線的原子改動列表，并嘗試依次合并，并將合并后的變更應(yīng)用到基線上。其流程圖如下：

其中變更合并時的邏輯如下：

人工沖突解決時，我們采用了上文“展示埋點(diǎn)DIFF”的功能，讓埋點(diǎn)設(shè)計(jì)人員同時看到兩方改動，并在界面中錄入最終合并結(jié)果。

七、埋點(diǎn)跨空間打通

云音樂業(yè)務(wù)存在多個業(yè)務(wù)線，他們的“埋點(diǎn)空間”是相互獨(dú)立的。但云音樂存在內(nèi)嵌業(yè)務(wù)的情況，如云音樂APP下可內(nèi)嵌LOOK直播APP、以及WEB端的H5頁面等，即使云音樂APP不發(fā)版，內(nèi)嵌的業(yè)務(wù)的埋點(diǎn)也可能會發(fā)生變化。因此需要把內(nèi)嵌業(yè)務(wù)對應(yīng)的的埋點(diǎn)樹“橋接”到當(dāng)前APP埋點(diǎn)中。針對這種訴求，我們研發(fā)了“橋梁”模式，如下圖所示:

• 橋梁為一類特殊對象，用于銜接父子空間，如圖示為銜接云音樂APP和WEB H5兩個獨(dú)立的埋點(diǎn)空間，其中云音樂APP是父空間，WEB為子空間
• 橋梁在父空間定義
• 子空間對象可設(shè)置掛載在父空間橋梁下
• 父空間展示埋點(diǎn)樹時，只關(guān)心到橋梁為止
• 子空間展示埋點(diǎn)樹時，會把橋梁以上所掛載的父空間樹也展示出來
• 內(nèi)嵌開發(fā)完畢后，需要使用父空間APP驗(yàn)證子空間的帶橋梁埋點(diǎn)是否正確，其SPM為帶父空間的完整路徑

此外由于埋點(diǎn)按版本管理，因此埋點(diǎn)樹若變化，必須要在平臺內(nèi)產(chǎn)生新版本，因此：

• 子空間發(fā)布，父空間不需要發(fā)布新版本，因?yàn)樽涌臻g埋點(diǎn)樹對父空間不可見
• 父空間發(fā)布，若涉及橋梁更改，則會改變子空間埋點(diǎn)樹，此時需要在子空間同步發(fā)布一個新版本

八、未來規(guī)劃

在埋點(diǎn)領(lǐng)域中，除了純客戶端埋點(diǎn)，還有服務(wù)端埋點(diǎn)，以及雙端共同完成的混合埋點(diǎn)，常見的混合埋點(diǎn)包括：

• 服務(wù)端下發(fā)的字段，客戶端需要打到客戶端埋點(diǎn)里
• 客戶端上報(bào)的字段，服務(wù)端需要打到服務(wù)端埋點(diǎn)里

此類需求廣泛存在，但未在本平臺上進(jìn)行管控，其流程、效率、效果是不可控、不可監(jiān)控的，后續(xù)平臺將把服務(wù)端埋點(diǎn)及服務(wù)端+客戶端混合埋點(diǎn)也平臺產(chǎn)品化并進(jìn)行管控。

此外，網(wǎng)易云音樂全鏈路埋點(diǎn)管理平臺前后端、客戶端SDK等組件都將在近期貢獻(xiàn)到開源社區(qū)，為業(yè)界帶來更大價(jià)值。