一、背景

在文章云音樂(lè)曙光埋點(diǎn)：還原數(shù)據(jù)理想國(guó)中，我們介紹了曙光埋點(diǎn)項(xiàng)目方案，該方案基于多端一致埋點(diǎn)對(duì)象樹(shù)建設(shè)管理，實(shí)現(xiàn)了統(tǒng)一自動(dò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)測(cè)試、埋點(diǎn)上線等功能，本文主要介紹該平臺(tái)功能及建設(shè)思路。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 2、落地效率問(wèn)題

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

• 埋點(diǎn)進(jìn)行增量變更時(shí)，無(wú)法知道改動(dòng)了什么：平臺(tái)只展示了某個(gè)埋點(diǎn)全量信息，并未展示其增量改動(dòng)（沒(méi)有類(lèi)似版本管理工具的Compare視圖）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其中變更合并時(shí)的邏輯如下：

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

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

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

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

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

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

八、未來(lái)規(guī)劃

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

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

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

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