一、常見問題
我們收集日誌，目的還是爲了分析用戶行爲，挖掘潛在價值，最終能優化產品體驗。因此，“高質量”是最基本要求，這是保證分析效果準確性的基石。那麼，常見的質量問題有哪些呢？
- 事件重複&丟失。重複是由於SDK自身或者前端開發疏忽的問題，導致相同事件重複發送；丟失可能是設備、網絡原因，或者是開發者漏埋導致。
- 事件參數錯誤。常見的情況有：”必傳而未傳“、”非空而爲空“、”值類型不對“、”值內容不對”等。
- 前端常見錯誤。比如值爲“undefined”、“null”，通常是前端代碼bug導致的值錯誤。
- 事件斷流。這種case經常發生，前端在做改造升級的時候，可能導致事件上報不規範，或者誤下線。
二、保障機制
針對埋點質量問題，我們嘗試以下的保障機制，去解決。從業務開發的過程出發，在不同階段提供服務支持，形成一個解決問題的閉環，保障日誌處於高質量狀態。
2.1 準確登記
業務需要根據“埋點規範”，規劃好頁面、組件和事件，並且在埋點平臺上準確地登記。登記的信息越全，內容越細，越有利於自動化判定日誌的準確性。目前我們登記的要素有：
- 頁面/組件類型，登記該元素的業務標識，以及是否有業務ID。日誌上報時，會有對應的字段記錄該信息。
- 事件信息，事件的名稱/標識/描述，所屬頁面/組件，以及所處狀態等信息。
- 事件參數，屬於該事件的一系列業務參數，比如一個點擊事件的參數可能是被點擊的商品的ID。對於參數的登記，我們支持標識/類型/是否必傳/參數結構的設置。其中類型支持int/string/float/list/map，用於申明值內容結構；參數結構支持對複雜的數據類型，進一步定義其細節。
2.2 實時校驗
做好了埋點的登記工作，開發就可以按照埋點方案做相應的開發了。如何快速驗證上報日誌的準確性，以及如何及時發現線上問題，是我們面臨的直接問題。因此，我們做了實時校驗。除了實時外，校驗還需要考慮更新及時性/完備性/擴展性，避免規範或校驗點的變更，帶來頻繁的修改代碼或重啓任務。另外，對於校驗結果，還需要要做到可解釋/可沉澱/可分析。
對於實時性，我們採用Flink開發校驗模塊，實現秒級日誌校驗；校驗規則更新的及時性上，每分鐘從埋點平臺同步；可沉澱，校驗結果除了推送給測試工具外，還會落到druid，用於後續分析。這些點的思路比較直接，就不贅述了。下面着重介紹下其他考慮點：
2.2.1 完備性/擴展性
完備性比較好理解，校驗需要支持的，除了底層的埋點規範外，還有分業務的頁面/組件的合法性、事件關聯頁面/組件的情況、事件參數格式內容等；擴展性的考慮點在於，校驗點會持續不斷完善，如何“以不變應萬變”。這點上，主要思路有兩個：
通過分析校驗規則，抽象語義，我們設定以下語法（示例）：
{
"compare":"length",
"condition":[
"sdk_type",
"in",
[
"iOS",
"Android",
"js"
]
],
"assert":"true",
"assert_fail":"ERROR",
"value":36,
"key":"uuid",
"fail_msg":"did/uuid invalid",
"require":1
}
本示例的含義：在sdk_type爲iOS、Android或js的情況下，檢查uuid參數，保證其是必傳的字符串，且長度是36，如果不是則是ERROR級錯誤，錯誤信息爲“did/uuid invalid”。具體字段說明：
- key：參數名
- value_type：參數值類型，默認爲string，可指定int
- compare：參數值檢查方式，支持：
- in：在一系列值內
- length：對於字符串類型，指定長度
- regex：對字符串類型，指定正則
- value：參數值約束，對於compare=in是一個list；對於compare=length是一個數值；對於compare=regex是一個正則字符串
- assert：檢查結果需符合的值，true或false
- assertfail：檢查失敗給出的異常等級，WARNING、ERROR、TESTWARNING
- fail_msg：檢查失敗給出的錯誤信息
- condition：檢查前置條件，符合該條件才進行檢查。
- require：該參數是否必須，非必需情況下，若爲空則不檢查
開關&配置化
不同時期，校驗關注的點可能是不一樣的，不同階段，校驗的邏輯也會有所區別。比如初期在問題重災區，我們對未登記的事件，沒有直接發送異常告警，但後期會；在新校驗點試驗階段，其校驗登記會設定爲WARNING或TEST_WARNING，而上線穩定後，可能會改成ERROR。因此，在實現中，就特別注意使用開關或配置，達到功能點的可定製。
2.2.2 可解釋/可分析
校驗發現了問題，是爲了解決問題。因此對結果，要求是可解釋的：在哪個層次，哪個參數發生什麼樣的錯誤，原因是啥；可分析的：分析不同級別、不同維度組合的異常分佈、走勢，便於集中定位和解決問題。
實現上，我們會對校驗的層次、範圍、結果等級作區分，對於每條日誌可能產出多條校驗結果（1+n）。 其中的n，是指不同層次和字段，可能會有ERROR/WARNING/TEST_WARNING狀態；1指的是整體上，會有個最嚴重的狀態彙總。
簡化後的校驗結果格式，是這樣的（包含多個關鍵維度，維度所處層級，問題字段、級別等）：
{
"log_id":"571531737e29586094318d3bf64e9407",
"timestamp":1556174577000,
"event_type":"click",
"sdk_version":"0.7.7",
"sdk_type":"js",
"display_url":"url",
"scope":"OVERALL",
"field1":"",
"field2":"",
"status":"SUCCESS",
"value":""
}
有了這樣的校驗結果，可以做很多事：埋點錯誤重災區、錯誤趨勢、原因分佈等，實現可解釋和可分析。
2.3 定時監控
除了上線前的把關，事後的監控也是很有必要的。從質量角度，關心規範的實際約束情況；從流量角度，特別關注事件斷流和異常波動情況；另外，業務上有很多約束，也需要去做監控。
基於實時校驗結果，我們做到分鐘級的質量和流量監控，在業務層面，會有小時級的個性化監控。
監控的“低誤報”是一個很重要的考慮點，氾濫的監控等於沒監控，在這點上，我們對監控做了一系列優化，如設定流量門檻、結合歷史流量飽和度判定斷流等。
2.4 專項優化
發現問題是手段，解決問題纔是目的。
對於質量問題，會反饋到業務方去整改；除了業務上，還有許多基礎SDK或開發上的通病問題，需要單獨去做分析，成立專項，集中整改。比如SDK的重複率和丟失率問題，需要具體分析問題，推動底層優化。
這類工作主要是：問題分析>追根溯源>確定解法>持續跟蹤。這裏邊涉及到許多特定場景的細節問題，就不展開講了。
2.5 評估模型
如何去評估質量狀態，是一個值得深思的問題。如果不能正確評價，就會摸不清重點，不知道如何優化，以及狀態是在改善還是惡化。我們的衡量維度目前是這樣的：
需要注意的是，各維度的權重，不應該是一成不變的，而要隨着問題的重點而調整；甚至考慮的問題，也要不斷去做優化，加入新的考量點。
有了一套這樣的評估模型，質量的狀態就可以以“分數”的形式直觀地呈現。對於問題的關鍵點，也可以有重點有方向地去解決。
2.6 質量中心
日常的質量問題，需要統一的呈現和管理，便於業務方有整體的感知，集中解決。
此外，對於彙總信息，也會以日報/週報的形式提醒到。
三、現狀&規劃
在以上介紹的一整套體系化的質量保障工作下，有讚的埋點質量有了大幅度提升。從狀態未知到數字化的衡量；從缺少管理到集中化的呈現，並能提供優化輔助功能；從“不及格”的低質量到絕大部分問題被解決，質量問題已經不是業務分析的絆腳石。
我們的質量保障工作已經取得不錯的成果，並形成良性的循環。但是還有許多可以優化的點：
- 支持更豐富的校驗功能，將複雜的校驗配置可視化
- 結合流量預測做監控告警，優化誤報率
- 評估模型優化，結合現狀，調整維度和權重
- 更完善的質量中心，集成快捷的優化操作
- 明確獎懲機制，推動業務方主動關心和優化質量問題，讓前文提到的閉環，順暢運行通過這些方向的努力，相信有讚的埋點質量會持續保持高質量狀態，更有力地爲業務分析保駕護航。
本文轉載自公衆號有贊coder（ID：youzan_coder）。
原文鏈接：