阿里妹導讀
一. 寫在前面
由於閒魚沒有日常環境，開發的除錯，專案聯調，測試驗證等流程都集中在預發環境進行，所以預發環境問題會集中爆發。
面對大量爆發的問題，我們依靠之前已有的閒魚全鏈路日誌查詢平臺能力，可以實現異常日誌的定時掃描+統計，提供了我們快速發現問題的能力。
之前，我們處理掃描出來的異常問題，需要測試先過濾一遍異常，然後指派給一個指定的開發owner（一個應用對應一個開發owner），然後由開發owner 自己去看程式碼識別 判斷指派的問題是不是自己寫的，如果不是，需要轉發給其他開發，這裡面會涉及到測試+開發兩方面的精力投入，如果BUG很多的情況下，開發和測試都會有相當大的成本。我們之前實踐下來確實會存在效率相對較低的情況（往往開發自己排查的成本相對較大，畢竟需要一個個的去翻程式碼）。
針對這種情況，我們研發了一套異常日誌問題自動追蹤-定位-分發機制，幫助0成本的找到測試環境/線上環境 BUG的製造人，自動分發缺陷給到對應開發，同時我們指派的BUG可以精確到行級別（哪一行日誌報錯，自動指派給那一行的提交人），做到又準又快又省力。
以後，誰寫的BUG，一個也別想跑（顫抖吧，開發們~~~）
二. 功能實現
示意圖：
下面介紹一下如何自動追蹤定位BUG：
1. 過濾異常堆疊資訊
當我們日誌掃描到異常問題時，我們會記錄下異常的日誌內容資料，如下圖所示：
第一步我們會透過正則匹配過濾出異常資料資訊：
正則的規則是透過堆疊報錯的典型關鍵詞 at ，每一個at 後的異常程式碼行資料實際就是一個錯誤溯源路徑，路徑中攜帶了程式碼類資訊和報錯的具體程式碼行資訊，我們會將這部分資料批次獲取。
2. 獲取異常程式碼行
at com.alibaba.xxx.xxx.xxxxx.xxx.xxx.xxxxxxxx.updatexxxx(AXXXXXXX.java:447)
以上面為例，異常的程式碼行資訊：AXXXXXXX.java:447
如1中所述，每一個異常的程式碼行資訊包含：類的全路徑資訊和報錯的具體程式碼行資訊。
我們繼續透過正則匹配，拿到這部分資料中的兩個核心資訊：報錯類名稱 AXXXXXXX和報錯程式碼行447 ，這樣一個異常程式碼行的資料就提取完成。
之後我們依次迴圈，最終針對每一個異常日誌堆疊，我們會提取出5個異常程式碼行佇列資料。
至於為什麼是5個，因為我們在實際判斷過程中，前面的異常點位不一定是業務程式碼引入的，例如一些線類轉換異常的報錯點位，其實不是開發提交程式碼導致的，但是再往後的呼叫處報錯，才是開發引入的，所以，我們需要往後繼續排查，才能找到問題所在。
故我們做了一定的配置化，可以控制查詢的點位數量，迴圈的嘗試異常程式碼行佇列，直到查詢到有效值資料。
3. 獲取目標分支資訊branch
預發環境存在多個分支，我們想定位問題和人的前提是必須拿到對應目標分支的資料，才能進一步去判斷異常的位置。
另外，預發日誌打印出來的報錯，都是基於當前部署分支進行列印的，所以打印出來的異常程式碼行資訊也是基於部署分支，故我們必須要獲取當前應用在我們日誌掃描期間，存在於預發環境的部署分支資訊，同時也要將master分支作為備份，因為有時候問題不在部署分支上，我們需要再以master分支進行兜底查詢。
4. 獲取Git檔案路徑file_path
透過 應用對應的 倉庫ID +分支資訊branch+ 異常程式碼類信息 AXXXXXXX.java +認證授權資訊 。
可以拿到 異常的 AXXXXXXX.java類 對應的 GIt 檔案路徑地址資訊 file_path，只要獲取到程式碼路徑資訊，才能拿到具體的程式碼檔案源資料資訊，所以這個 file_path 對我們後面查明“真兇” 至關重要。
5. 獲取異常程式碼git提交行的人
從2中，我們還可以拿到具體的程式碼行line , 我們透過具體的對應的倉庫ID + GIt 檔案路徑地址資訊file_path+具體的異常程式碼行line +認證授權資訊 ，可以拿到對應git 程式碼的提交人資訊。
最後，我們可以看到 對應開發提交這行 AXXXXXXX.java:447 程式碼的時間，開發可以自行檢查是否符合，是否是自己提交的程式碼，然後麻溜的趕緊修復掉問題！！！
三. 寫在最後
在S2，我們會在每週一次自動分發異常問題精準的給到對應開發同學，同時為了過濾噪音，也會針對特定型別的日誌異常做過濾，支援配置，讓每一個分發到開發同學手中的BUG都是有修復價值的。
最終我們會形成兩份針對應用維度和人維度的異常問題修復統計表，能夠清晰的讓大家看到異常問題修復進度。
我們衷心期望：所有的異常問題都能消滅在預發環境，不讓一個小問題遺留到線上！！
如何讓你的AI大模型開啟“外掛”之旅？
面向需要高效文件管理與解析、有精細化內容分析與洞察需求的企業，透過將文件智慧和檢索增強生成（RAG）結合起來構建強大的LLM知識庫，包括清洗文件內容、文件內容向量化、問答內容召回後透過特定的Prompt，提供給LLM足夠的上下文資訊，以此來滿足對於企業級文件型別知識庫的問答處理。
點選閱讀原文檢視詳情。