大家好，我是若川。我持續組織了近一年的源碼共讀活動，感興趣的可以?點此掃碼加我微信?ruochuan12?參與，每周大家一起學習200行左右的源碼，共同進步。同時極力推薦訂閱我寫的《學習源碼整體架構系列》?包含20余篇源碼文章。歷史面試系列。另外：目前建有江西|湖南|湖北籍前端群，可加我微信進群。

一個前端項目上線后的各種指標監控是極其重要的，通過各種指標數據可以知道項目存在的問題及未來優化的方向，在各種維度監控中的異常監控是必不可少的，通過異常數據可以及時發現用戶遇到的問題，而異常上報中的各種數據指標可以給解決問題提供參考及方向。

文章內所有異常上報及異常分析都是基于異常處理開源平臺 Sentry ，其他異常處理平臺或自建平臺可根據實際情況參考。本文主要分為以下幾個部分：

• 異常治理的重要性

• 前期異常數據處理

• 高效發現異常

• 高效解決異常

異常治理重要性

海恩法則指出: 每一起嚴重事故的背后，必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患。當一件重大事故發生后，我們在處理事故本身的同時，還要及時對同類問題的 “事故征兆” 和 “事故苗頭” 進行排查處理，以此防止類似問題的重復發生，及時消除再次發生重大事故的隱患，把問題解決在萌芽狀態。這個法則放在前端異常治理中同樣適用，通過及時發現存在隱患的異常并及時解決，避免釀成重大事故。

用戶體驗

前端項目的用戶體驗是很重要的一環，特別是公司業務面向C端的時候，一個好的用戶體驗可以更高的促進業務漏斗的轉化。

新增異常監控后，所有收到的異常數據都是實時的，異常發生時我們可以第一時間知曉且及時處理，對所有異常數據都要積極處理，不可敷衍了事，不能等到用戶反饋時才打開異常平臺修復問題，當你已經從其他渠道得到反饋有異常時，說明問題已經擴散到很大的范圍了，這個時候才想起去看異常平臺數據時沒有將平臺的作用最大化，也給用戶帶來了不好的體驗。

這里說的第一時間及時處理，并不是隨時都在觀察是否有新的異常產生，我們只需要在關鍵的節點提高警惕即可，主要是系統發布新的功能時，但這并不局限于本系統，比如 App 項目中 H5 未發布，但是App發布了新的版本；后端接口發布了新的版本；用戶升級了新的系統版本等會需要及時觀察是否存在異常數據波動。除此之外可能還有設備兼容性問題，復雜業務操作等產生的問題，這類問題可通過其他手段監測及時發現，后面的文章會說明。

公司成本

某些異常是不影響用戶使用的過程，比如組件卸載時未及時移除定時器或綁定的事件，雖然用戶是無感知的，但是異常數據會源源不斷的上報，如果這是一個日均PV上百萬的項目，可想而知每天會產生多少新的數據，會造成多少網絡流量的浪費。所以要及時處理異常，特別是高頻發生，穩定復現的問題，減少網絡流量及異常平臺服務器的壓力，及時減輕公司的運營成本。

前期異常數據處理

在解決問題之前需保證該異常數據是我們需要解決的問題，而不是無意義或干擾性的問題等著我們去處理，此類問題會影響后續的數據分析及降低解決問題的效率，以下處理方案大都可以在異常上報SDK中統一處理。

• 規范上報異常數據，規范上報異常標題格式，以及其他附加數據，如 sentry 中的 tag，additional 數據等，以便于在不同的項目中都可以快速參考分析問題，另外就是要規范異常上報的時機，除開被動上報異常，其他用戶主動操作行為產生的異常要及時上報，如接口異常，復雜邏輯中特定時機上報異常記錄分析。

• 部分異常過濾，針對某些框架底層異常或是已知業務場景正常接口異常等，可直接過濾處理，不再顯示到異常平臺中再次處理。這類異常過濾的過程可以在 SDK 全局進行過濾處理，針對不同的項目可額外增加不同的過濾條件，也可在異常平臺針對某些重要性較低的項目直接過濾處理。

• 部分自動處理，自動處理分為幾個情況：自動刪除，自動標記解決，自動列為忽略異常。經過上面的過濾后的異常，會再一次過濾處理，這類處理的異常內容可以是某些業務場景需要上報的接口異常但不能歸屬于代碼邏輯錯誤，比如提交訂單時，某個新出的機型未在后臺新增，觸發這個異常后運營會立即處理，后續不會再發生。針對這類型的異常可以使用程序自動處理。

• 完善健康度所需各維度數據，判斷一個項目產生的異常不能單純的以數量為依據，還要根據當前項目的用戶量結合計算，所以要把當前計算健康度所需的各維度數據都要提前準備好，提高后期健康度計算結果的準確性。

高效發現異常

經過以上的前期數據處理，接下來經過 SDK 上報到異常平臺顯示的數據就是我們要真正處理的異常數據。以轉轉舉例，目前已經接入 Sentry 的前端項目有 **500+**，每天上報的異常數量約 250 萬次，在如此大的體量下如何快速發現哪些才是目前緊急需處理的異常呢？

異常上報后需要針對性的處理，優先處理緊急核心項目及上報數據不正常的異常，可通過以下幾個方式高效發現異常，這里的異常并不是指全部的異常，而是值急需處理的異常。

項目健康度排名

通過一系列維度權重配置，給所有項目計算出一個健康度得分，通過得分排序即可得出當前項目質量的好壞程度，通知對應的負責人及時處理。相關維度項及解釋如下：

• 24小時異常/PV比例：近24小時發生異常數量與該項目PV數量占比情況

• 14天異常數量：該項目14天發生異常數量總計數值

• 24小時異常數量：該項目24小時發生異常數量

• PV：統計該項目昨日所有頁面PV數量

• 是否核心項目：該項目是否標記為核心項目

健康度得分計算公式：每個維度權重占比可隨時調整，調整后會立即重新計算得分并排名，可通過維度權重的調整來提高整體項目的質量要求。

sentry大盤異常監控

對異常平臺內所有項目上報的匯總值監控，監控的指標有2個，突發異常數量過高，超出上一個區間數據的增量比例，另一個就是異常數據歸零，沒有收到任何異常，這種情況可能是短期異常太多導致平臺崩潰或其他情況導致無法處理異常處理，針對這兩個情況進行異常波動記錄并觸發企業微信推送。

項目異常監控

接下來就是針對項目級別的監控，但是作為一個集團大公司下的項目太多，對于一些異常數量極低的項目需要過濾處理，減小服務器的壓力以及可以提升數據處理的速度。我們可以通過 Sentry 平臺 Stats 中的項目進行監控處理，這里的項目可傳入查詢的時間段，這里最小時間段是小時級別，返回的是當前條件下新增的異常數量排名列表，我們只針對這個列表進行監控處理，由于需要更快速更準確的監控異常波動，基于這個列表再次查詢每個項目5分鐘內的新增異常數量，通過定時任務處理即可得出以下走勢圖，可快速發現某個時間段中的哪個項目出現了項目數據不正常的情況。針對這部分異常同樣的也是進行異常波動數據存儲及企業微信消息推送。

企微消息推送

以上2種情況最終都會觸發到企業微信消息推送，因為消息推送的觸達更為精準和迅速，但是也存在一些特殊的項目，比如夜間會定時任務可能存在過多的超時，本身 PV 量較高的項目所觸發的配置數值有所不同。所以針對推送的部分增加了相關維度的配置，推送配置有推送區間，多少時間段內觸發一次推送，推送時異常起點數量，增量異常比例以及是否開啟推送。最終企業微信推送效果如下：

超時未處理提醒

上面的項目波動監控是針對項目整體異常情況的，除此之外還增加了針對項目內部具體異常解決情況的監控并推送，獲取到項目內部所有異常，定期執行推送，在消息推送內容中標明當前存在的異常數量，針對超過3日還未處理的異常@對應負責人，以提高相關人員警覺。最終企業微笑推送效果如下：整體流程如下：

高效解決異常

經過上一步的發現異常，接下來將通過幾個手段更加高效的解決異常，這個過程是基于公司內部現有情況處理，在不同的公司內部可能不一定適用，可參考處理。

知識庫解決方案沉淀

目前各小組解決項目異常問題都沒有沉淀具體的解決方案，但是大家所遇到的問題都是大同小異，很多場景下的異常問題其解決方案都是可以復用的。鑒于此，我們把解決問題的過程沉淀到內部文檔知識庫中，以供其他同學遇到類似的問題時，提供一定的解決思路，提高異常問題的解決效率。整體流程如下：

如該問題已有提交的文檔記錄，則進入異常問題詳情頁面時，右上角會有提示已解決方案參考地址，點擊鏈接跳轉到內部文檔查看對應的解決方案。

內部文檔搜索關聯

研發同學都有記錄文檔的習慣，但是歷史文檔和 Sentry 并沒有任何關聯關系，所以在 Sentry 異常詳情頁面中新增按鈕跳轉到內部文檔搜索，如有類似文檔沉淀，則可以直接參考解決。

一鍵進入開發，內部系統打通

Sentry 本身是一套獨立的開源項目，所以和公司內部其他的系統沒有任何關聯關系，導致無法和其他系統進行聯動操作，比如創建分支，查詢內部項目相關信息等。導致每次解決異常時都需要創建需求和分支才能進入到開發中，整個流程重復且繁瑣。

基于這個背景在 Sentry 異常詳情頁面中增加一鍵創建需求和分支的能力，可快遞進入到開發過程中。整個流程如下：涉及調用其他系統的接口較多，細節就不過多說明。核心就是基于異常詳情中的頁面地址解析出項目內部相關信息，基于這個數據創建tapd需求，創建項目倉庫開發分支并和當前異常信息綁定記錄。

自動分發接口異常責任人

現有項目中的接口異常占比約 80% ，導致需要花費大量的時間去溝通協調處理異常，處理的過程一般都是在 Sentry 監控平臺發現是接口異常，再發送相應的接口請求數據及響應數據給到對應的后端處理，每次的溝通繁瑣且耗費時間。基于這個背景優化整個溝通的過程，首先對異常上報的標題進行組裝統一，以便后期可以檢索時可以快速發現該問題屬于接口層面問題。然后根據標題中獲取到的接口地址從ZAPI(內部接口文檔平臺)平臺獲取到對應的后端開發人員，最后就是推送該接口異常情況到群聊@對應的開發人員。這里為了方便RD還原當前的請求場景，會再查詢一次 Sentry 平臺異常詳情接口，在詳情中獲取到接口請求時的traceid，這樣就不用再提供請求出入參數給后端人員了。

const?=?sendTitle?=?`${sendType}--${requestUrl}--${responseText}`

推送效果如下：整體流程如下：

總結

針對前端異常治理本文從兩個方面說明了其重要性，然后在處理異常的前期增加了對異常數據的準確度的過濾處理，對過濾后的數據通過幾個方式快速發現存在波動的異常情況，最后對需處理的異常增加了一些手段提高解決異常的效率。

異常治理的過程是一條漫漫長路，需要相關的同學一起努力才能有一個較好的結果，比如經過一系列手段可以發現很多不正常的異常情況，接下來就需要對應的同學快速處理且沉淀下來解決的過程以供后續其他同學參考，只有沉淀到一定的量后才會有比較顯著的效果。

本文異常處理平臺基于開源平臺Sentry，其他平臺處理邏輯類似，希望能給你帶來幫助。