網易雲音樂全鏈路埋點管理平臺建設

　　一、背景

　　在文章雲音樂曙光埋點：還原資料理想國中，我們介紹了曙光埋點專案方案，該方案基於多端一致埋點物件樹建設管理，實現了統一自動化埋點和鏈路追蹤，方案高度還原了大前端埋點的理想狀態、具備較強通用性和擴充套件性。我們圍繞這套埋點方案研發了配套的埋點管理系統，以承載及埋點規則資料管理、埋點設計、埋點研發、埋點測試、埋點上線等功能，本文主要介紹該平臺功能及建設思路。

　　二、平臺現狀介紹

　　經過前幾期建設，我們已經實現了一個適配研發流程的、按版本來管理的埋點資料管理平臺，其核心功能為：

　　1、承載埋點研發生命週期

　　2、承載埋點的後設資料管理

　　我們的研發生命週期如下：

　　平臺在埋點後設資料管理設計如下，參考和學習了版本管理工具的功能，並且充分考慮了客戶端的研發流程特點

　　1、客戶端每個大版本需求研發時，BI對埋點需求進行分類，建立需求組。可以理解為基於Master CheckOut出了多個分支。

　　2、BI在各需求組內，按埋點需求設計埋點。設計完成後，平臺會計算出埋點的變更列表，如新增物件、新增血緣關係、修改引數、刪除物件、刪除血緣關係。

　　3、上述變更由BI指派到任務，交由開發處理

　　4、經過一個版本迭代開發後，若任務開發測試完成處於可上線狀態，會被打上版本的TAG，並且釋出上線，在Master產生一個新版本；未完成的任務，則可在後續版本迭代開發完畢後再上線。

　　相比版本控制工具，適配研發流程的版本控制具有以下特點：

　　1、支援部分變更上線：需求內的變更可以自由篩選出來部分上線，可以類比為分支內提交數個檔案，可以篩選出幾個檔案單獨合入Master

　　2、需要走研發流程才可上線：每個埋點變更都擁有獨立的研發流程控制和校驗。這些流程(設計完成->開發->測試透過)需要走完後，才准許合入Master。

　　3、模型更加複雜：不是簡單的文字，而是複雜的層級物件結構。

　　三、我們遇到的問題和痛點

　　在上述研發流程模式的落地過程中，我們發現了以下問題和痛點：

　　1、落地質量問題

　　漏埋：因為涉及較多埋點事件、埋點引數的組合，在某些組合下，埋點沒有上報。

　　錯埋：埋點引數缺失或格式不正確。

　　歸因錯誤：埋點裡的歸因欄位設定錯誤、不合理。

　　2、落地效率問題

　　大量重複埋點程式碼編寫：如果涉及大量物件埋點，埋點工作勢必成為大量重複勞動，影響研發效率。

　　埋點進行增量變更時，無法知道改動了什麼：平臺只展示了某個埋點全量資訊，並未展示其增量改動（沒有類似版本管理工具的Compare檢視）。

　　3、功能痛點

　　有一些埋點長期停留在研發階段未上線（類比於寫程式碼時開發分支落後Master多次提交，沒有去Pull Master獲取最新的主線程式碼改動），導致這些埋點很可能是過時的，如果不進行卡點直接上線，就會導致問題

　　埋點資料是按APP+端兩個維度隔離的，但實際運用時存在內嵌情況，如APP端可內嵌WEB端H5頁面的功能，這種情況下，需要把原本隔離的資料進行整合，如把部分WEB埋點樹掛載在APP端樹上。

　　針對以上問題痛點，平臺在近半年內進行了針對性的解決。

　　四、埋點質量建設

　　解決該問題的思路為先解決源頭防止增量質量問題產生，再解決存量質量問題。

　　1、建設實時埋點校驗功能，從源頭解決埋點質量問題

　　客戶端埋點開發完成後，需要進行"實時校驗"，從而對被指派的埋點任務進行測試覆蓋，其步驟如下：

　　客戶端連線到實時校驗平臺，平臺根據該任務需求，生成埋點校驗樹

　　客戶端上報日誌，平臺根據埋點校驗樹進行校驗

　　平臺根據測試情況，決定測試是否透過

　　需求範圍內有埋錯：不透過，且可以檢視日誌看到具體為何不透過，如下圖所示

　　需求範圍內有漏埋：預設不透過，但事實推進落地中，存在部分分支客戶端難以復現覆蓋的情況，因此我們也支援了勾選某些分支無需測試的功能，如下圖所示

　　若測試為不透過，則將卡點阻塞流程，後續無法正常上線

　　經過實時埋點校驗功能的上線後，我們封堵住了大部分埋點錯誤源頭，達到了較好效果。

　　2、建設線上埋點稽查功能，發現存量埋點問題並推進解決

　　稽查功能定位為企業日誌的統計分析，解決以下問題：

　　1、分析日誌是否按規則正確輸出，檢測出少引數、引數取值錯誤、歸因錯誤等問題，並對這類問題進行歸類，並可進一步鑽取，直至能夠看到原始日誌的樣本。

　　2、自定義靈活業務統計監控、報表、報警。透過監控、報表中數值變化報警來發現、輔助定位端上發版後一些bug。如：某些點位日誌變少、PV/UV比例變化等。

　　為實現上述功能，需要對日誌進行取樣分析計算(可以理解為打上各種標籤)，並且將計算結果儲存在能夠支援篩選、統計查詢功能的資料庫中，為典型的OLAP場景，我們選型時，採用了ClickHouse來完成這塊功能，其主要考量點如下圖所示

　　

　　經過稽查功能上線和推進，我們的線上埋點錯誤數已經下降了95%，並且還在逐漸降低中，達到了較好的效果。

　　五、埋點效率建設

　　使用模版引擎自動生成程式碼 上文提到，埋點時涉及大量重複埋點程式碼編寫，我們針對該問題使用模版引擎語言自動生成埋點程式碼，且支援適配了安卓、iPhone、Web、RN等多套客戶端，把程式碼提前生成好，能自動填寫的部分全部自動填寫，客戶端複製程式碼後只需要把程式碼模版裡剩餘部分補全即可，如下圖所示

　　展示埋點DIFF，讓開發更容易理解埋點改動點

　　我們開發了埋點DIFF功能，相比與版本管理軟體中的程式碼文字對比，埋點後設資料是一種更加複雜的資料結構，因此在服務端計算DIFF和前端介面展示DIFF上相對來說較複雜一些。如下圖所示，我們透過在原有介面上透過背景色來區分變更操作是新增、修改、還是刪除。

　　六、研發中埋點自動Rebase到最新Master

　　前文提到，有一些埋點長期停留在研發階段未上線，目前沒有pull master的功能，導致：

　　1、這些未上線埋點後設資料很可能是過時的，如果直接上線會導致業務問題。

　　2、無法使用到最新Master下的新增物件，或者還在使用已刪除物件

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

　　

　　rebase演算法的核心在於計算出Master和本研發分支對比同一個基線的原子改動列表，並嘗試依次合併，並將合併後的變更應用到基線上。其流程圖如下：

　　

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

　　

　　人工衝突解決時，我們採用了上文“展示埋點DIFF”的功能，讓埋點設計人員同時看到兩方改動，並在介面中錄入最終合併結果。

　　七、埋點跨空間打通

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

　　橋樑為一類特殊物件，用於銜接父子空間，如圖示為銜接雲音樂APP和WEB H5兩個獨立的埋點空間，其中雲音樂APP是父空間，WEB為子空間

　　橋樑在父空間定義

　　子空間物件可設定掛載在父空間橋樑下

　　父空間展示埋點樹時，只關心到橋樑為止

　　子空間展示埋點樹時，會把橋樑以上所掛載的父空間樹也展示出來

　　內嵌開發完畢後，需要使用父空間APP驗證子空間的帶橋樑埋點是否正確，其SPM為帶父空間的完整路徑

　　此外由於埋點按版本管理，因此埋點樹若變化，必須要在平臺內產生新版本，因此：

　　子空間釋出，父空間不需要釋出新版本，因為子空間埋點樹對父空間不可見

　　父空間釋出，若涉及橋樑更改，則會改變子空間埋點樹，此時需要在子空間同步釋出一個新版本

　　八、未來規劃

　　在埋點領域中，除了純客戶端埋點，還有服務端埋點，以及雙端共同完成的混合埋點，常見的混合埋點包括：

　　服務端下發的欄位，客戶端需要打到客戶端埋點裡

　　客戶端上報的欄位，服務端需要打到服務端埋點裡

　　此類需求廣泛存在，但未在本平臺上進行管控，其流程、效率、效果是不可控、不可監控的，後續平臺將把服務端埋點及服務端+客戶端混合埋點也平臺產品化並進行管控。

　　

　　此外，網易雲音樂全鏈路埋點管理平臺前後端、客戶端SDK等元件都將在近期貢獻到開源社群，為業界帶來更大價值。