快手大時長應用可觀測挑戰及應對實踐.pdf

《快手大時長應用可觀測挑戰及應對實踐.pdf》由會員分享，可在線閱讀，更多相關《快手大時長應用可觀測挑戰及應對實踐.pdf（26頁珍藏版）》請在三個皮匠報告上搜索。

1、快時應可觀測挑戰 及應對實踐演講：王輝快/移動端數據架構負責個介紹王輝 快/移動端數據架構負責 團隊主要負責快的埋點體系、研發數倉等可觀測基礎設施 在互聯業從事開發作多年，開發過前端、后端、客戶端、數據，也帶過業務、架構等不同類型的團隊01020304錄超路徑帶來的挑戰可觀測體系構建路徑歸因實踐總結與展望01時 短內容=超路徑超路徑帶來的挑戰背景：鏈路數據基建，嚴重影響了決策效率、實驗效率、排障效率缺數據應淺徑亂 流量路徑摸底看不清 訂單僅能做到80%精確歸因 埋點發版放量3周起步 萬億級別表關聯,慢！業務間數據打架 前后端數據不通 個實驗埋點需要個 平均時級 故障處置(變更引起）P4+故障4

2、 起，P5級1 起 約80%的故障來于變更，變更數據挖掘 分析師說，社區算法說，客戶端開發者說，為埋點、算法特征、技術埋點等三類埋點都存在嚴重問題 問題涉及事業部（L5）級別組織 8+，業務線（L4）級別組織 20+流量歸因問題案例：電商希望能看到精確流量路徑、流量來源，需要推動全站基建 精確描述戶路徑 萬億級數據量避免關聯 是否可以動化、平臺化降低埋點成本問題洞察客戶：產品經理、分析師 算法歸因問題案例：搜索為將策略信息100%透傳到所有下游葉結點，需要推動全站基建 策略需要統標準 需要兼容多策略 需要SDK來保證正確性問題洞察客戶：推薦算法 算法歸因問題案例：算法架構團隊希望不再被埋點bl

3、ock實驗 要100%覆蓋存量、增量 策略參數要有擴展彈性 全鏈路要打通 后端臨 M*N 復雜度 是否可以動化 實時性與成本的平衡問題洞察客戶：推薦算法 故障歸因問題案例：未能及時定位的變更故障，影響持續上升 損效率取決于定位效率 變更導致故障占 變更數據、故障數據如何關聯？問題洞察客戶：客戶端開發整體解題思路對泛的跨領域問題，需要有套完整的打法來保障落地效果。Todo：如何解決？先框架，再逐個擊破02組織、規范、流程+平臺化可觀測體系構建組織規范建設通過橫向組織實現多領域協同；通過規范化建設和治理來達成底層共識；通過流程保障防劣化。埋點委員會界定關鍵問題全鏈路規范協同建設質量&穩定性保障埋點

4、SDK埋點Server算法特征流量數倉數據產品分析師規范化建設及治理界定責任邊界規范公參&私參存量治理&增量收為埋點規范算法信號規范異常事件規范變更管控規范公參規范業務公參規范流程建設規范有卡跨組織協同質量&穩定性需求評審技術案評審動化測試動化校驗驗收機制故障處置機制平臺化建設通過端到端平臺建設，實現全鏈路聯動、動化、助化。埋點需求、驗收流程 路徑助埋點 埋點動化校驗 基礎質量監控 埋點SDK 標準化流量數倉 流量拆分模型 實驗體系模型 基礎流量監控流量數倉 實時特征規范/管理 全站特征加 算法實驗數據管線 全站流量分發校準實時特征平臺 PB規范管理 統棧模型 統透傳機制 路徑數據校驗埋點平臺

5、流量產品端架構流量架構算法架構03流量、算法、穩定性三個領域的歸因架構探索路徑歸因實踐 流量歸因：路徑助染（URT）案要點 通過圈選來注冊染點(效)染信息基于后端配置動態提?。ńy機制）在公參中攜帶路徑信息(需關聯)個性化場景 跨技術棧：統命周期 窗半屏：統框架業務主 流量歸因：染（URT）質量檢測機制要點 原理：通過志對埋點進交叉驗證 端上質檢SDK 2M mmap存儲精簡志 可配置場景進路徑還原、檢測 算法歸因：內容策略（STID）通道規范要點 趟班多個座位（多策略）每個座位規格致（統規范）次實施多通道復 算法歸因：內容策略（STID）通道 與 效率提升要點 服務端通過SDK實現內容策略透傳

6、 客戶端SDK與業務聯合實現實體參數的動態提取 服務端SDK、客戶端SDK、絡SDK聯合升級實現透傳能及圈選式動態擴展能 配置化的極簡實時通道 故障歸因：變更數據鏈路要點 原理：變更群與故障群的強相關性 強時間相關性，帶來了時效性 AB、開關、危運營系統全覆蓋 三端歸因難點在于服務端變更不是基于群是基于服務器節點只能依靠Trace 其他有效假設：時間起點相關性、趨勢相關性、領域相關性 故障歸因：變更歸因架構要點 原理：變更群與故障群的強相關性 強時間相關性，帶來了時效性 AB、開關、危運營系統全覆蓋 三端歸因難點在于服務端變更不是基于群是基于服務器節點只能依靠Trace 其他有效假設：時間起點

7、相關性、趨勢相關性、領域相關性04更全、更易總結與展望效果覽染（URT）歸因平臺策略通道（STID）訂單精確追蹤例 99%+埋點作量 0（平臺圈選），隔取數 億級表，且需關聯 數據質量問題接近100%監控召回 全公司個通道，套模型 全域流量覆蓋率 99%+端到端打通，實驗隔上線 Showcase：60pd(開發)5pd(變更)13個團隊 2個團隊 故障定位損均值 10分鐘 端側變更歸因準召 90%+后端客戶端歸因準召 60%+P4+級故障 1 起，P5級 4 起For 分析師For 社區算法For 客戶端排障徑：變更引起的故障（占盤80%）實踐反思 流量歸因 路徑數據質量難保障，端側檢驗效率最（帶診斷能）。邊界設定定要明確，如擴展參數度（eg.100字符）、染層數（eg.10層）等。策略通道 以端側事實數據為主，端Batch時效性可調（eg.實時、20s、1min、2min）。策略信號下發定要求100%覆蓋，上報則要動態可選。變更歸因 量變更同時放量會有沖撞，按事件群聚合有定短板，強假設必不可少（如領域相關度等）。召回 vs.準確，我們選擇優先保證召回。THANKS