我們日常工作中雖然會遇到很多 BUG,我們也熟練掌握使用搜尋引擎解決開發中的問題。
但是當遇到線上 BUG 應該如何排查呢?
我將我過往遇到的一些異常整理了出來,並將我遇到的干擾項以及問題點都做了詳細記錄。
希望對你有所幫助
排查路徑
確定是否變更導致?
- 如果是變更導致需要及時回滾止損。
- 非變更導致可以排查一下異常版本,根據當前情況靈活判斷是否恢復成某一個版本。
確定復現路徑。
- 這可以看使用者是否有反饋?
- 是否有日誌。fundebug、sentry、埋點等等
- 是否有特徵之類的?比如說機型、ip地域、服務主機等等
分析問題歸屬
- 先自查程式碼是否處理異常。比如說邏輯錯誤、相容性錯誤
- 然後排查是否資料異常。可以透過 charles 偽造資料,也可以透過 chrome 斷點控制檯修改。
測試環境驗證問題
- 將上述的問題在測試環境復現出來。證明確實是因為這裡有問題後就可以著手修復了。
修復|移交
- 自己的問題自己修。相容性babel、babel-polyfill 之類的。邏輯錯誤改邏輯。
- 合作方的問題,就反饋移交。
測試環境驗收
- 修完之後記得先驗證一下,別因為著急修 bug 又出現新的 bug。
預發&上線
- 分級釋出
- 做好線上迴歸
實戰案例
【公司2】FMP 異常
縮小時間節點
- 3天前開始劣化
上線單歷史排查
- 近期存在多次變更,但無明顯關聯,所以沒有進行回滾。
日誌查詢、特徵收集
- 內部有一個自建的前端日誌平臺,收集了所有日誌,前端按需查詢分析
透過(頁面、FMP5s+)查詢日誌,人眼找特徵。(這裡應該有自動啊喂)
- 時間為非工作時間(有可能是服務不穩定,網路波動)
- 頁面生存時間長(有可能是後臺,或者下班鎖屏等情況)
- 聯絡特徵使用者,獲取一手反饋(使用者沒吐槽沒印象)
- 頁面資源載入不穩定(網路或後臺+1)
- 【真問題】UA 為 移動端 ios(mac 和 ios 這個關鍵特徵其實被我忽略了。因為我們是內網專案,所以我第一波沒有注意到這個特徵。老闆們用 mac 和 ios 有問題嗎?沒問題啊)
- 網速不佳、網路不穩定(可不,用手機那網路能穩定到哪裡)
路徑確認,嘗試復現
- 用上面找到的特徵,我都嘗試了沒有復現。
擴大搜尋範圍
- 聯絡了 UA 對應的客戶端負責人,明確反饋因為客戶端記憶體洩漏,導致 webview 重啟。(這不應該有通報嗎,而且不應該只有我們在排查FMP異常的問題吧。)
- 移交、等待修復、總結匯報。
- 【公司1】上傳失敗
- 【公司3】使用者訪問慢
【公司2】使用者訪問超長白屏
- 針對使用者查詢訪問日誌(使用者名稱、時間)
特徵收集
- 資源載入異常(三方資源)
嘗試復現
- network block 資源。(非強關聯資源,載入不到不會白屏)
- charles 阻塞資源。(白屏)
分析問題制定修復方案
- 資源體積不大,但是耗時長,切不穩定。問題責任方在 cdn,偶現資源異常問題,屢教不改。
- 非強依賴資源沒有 async defer,導致頁面白屏,影響使用者體驗。
- 綜合考慮,defer 一下。
- 修復&測試環境驗證(同復現步驟)
- 上線
日誌平臺&監控平臺 功能點
日誌查詢
支援多條件
- 使用者
- 頁面
- traceid (page、SPA、ajax)具體的命名規則可以自定義。
- 上報的資訊,比如說 FMP、erorr、埋點、ajax、操作、還是自定義打點等等
- 其他通用資訊,比如說 ip、地域、ua
自動分析&告警通知
- 1 分鐘 10 次 500 觸發告警
- 1 分鐘 3 次
erorr data in not defined
觸發告警
大盤、報表
- xxx 介面 fmp90 5s,pv 1w+
本質上來講監控平臺就是把常用的日誌分析替你整合了。
本文參與了SegmentFault 思否面試闖關挑戰賽,歡迎正在閱讀的你也加入。