一個前端項(xiàng)目上線后的各種指標(biāo)監(jiān)控是極其重要的，通過各種指標(biāo)數(shù)據(jù)可以知道項(xiàng)目存在的問題及未來優(yōu)化的方向，在各種維度監(jiān)控中的異常監(jiān)控是必不可少的，通過異常數(shù)據(jù)可以及時發(fā)現(xiàn)用戶遇到的問題，而異常上報中的各種數(shù)據(jù)指標(biāo)可以給解決問題提供參考及方向。

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

• 異常治理的重要性
• 前期異常數(shù)據(jù)處理
• 高效發(fā)現(xiàn)異常
• 高效解決異常

異常治理重要性

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

用戶體驗(yàn)

前端項(xiàng)目的用戶體驗(yàn)是很重要的一環(huán)，特別是公司業(yè)務(wù)面向C端的時候，一個好的用戶體驗(yàn)可以更高的促進(jìn)業(yè)務(wù)漏斗的轉(zhuǎn)化。

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

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

公司成本

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

前期異常數(shù)據(jù)處理

在解決問題之前需保證該異常數(shù)據(jù)是我們需要解決的問題，而不是無意義或干擾性的問題等著我們?nèi)ヌ幚恚祟悊栴}會影響后續(xù)的數(shù)據(jù)分析及降低解決問題的效率，以下處理方案大都可以在異常上報SDK中統(tǒng)一處理。

• 規(guī)范上報異常數(shù)據(jù)，規(guī)范上報異常標(biāo)題格式，以及其他附加數(shù)據(jù)，如sentry 中的 tag，additional 數(shù)據(jù)等，以便于在不同的項(xiàng)目中都可以快速參考分析問題，另外就是要規(guī)范異常上報的時機(jī)，除開被動上報異常，其他用戶主動操作行為產(chǎn)生的異常要及時上報，如接口異常，復(fù)雜邏輯中特定時機(jī)上報異常記錄分析。
• 部分異常過濾，針對某些框架底層異常或是已知業(yè)務(wù)場景正常接口異常等，可直接過濾處理，不再顯示到異常平臺中再次處理。這類異常過濾的過程可以在SDK 全局進(jìn)行過濾處理，針對不同的項(xiàng)目可額外增加不同的過濾條件，也可在異常平臺針對某些重要性較低的項(xiàng)目直接過濾處理。
• 部分自動處理，自動處理分為幾個情況：自動刪除，自動標(biāo)記解決，自動列為忽略異常。經(jīng)過上面的過濾后的異常，會再一次過濾處理，這類處理的異常內(nèi)容可以是某些業(yè)務(wù)場景需要上報的接口異常但不能歸屬于代碼邏輯錯誤，比如提交訂單時，某個新出的機(jī)型未在后臺新增，觸發(fā)這個異常后運(yùn)營會立即處理，后續(xù)不會再發(fā)生。針對這類型的異常可以使用程序自動處理。
• 完善健康度所需各維度數(shù)據(jù)，判斷一個項(xiàng)目產(chǎn)生的異常不能單純的以數(shù)量為依據(jù)，還要根據(jù)當(dāng)前項(xiàng)目的用戶量結(jié)合計(jì)算，所以要把當(dāng)前計(jì)算健康度所需的各維度數(shù)據(jù)都要提前準(zhǔn)備好，提高后期健康度計(jì)算結(jié)果的準(zhǔn)確性。

高效發(fā)現(xiàn)異常

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

異常上報后需要針對性的處理，優(yōu)先處理緊急核心項(xiàng)目及上報數(shù)據(jù)不正常的異常，可通過以下幾個方式高效發(fā)現(xiàn)異常，這里的異常并不是指全部的異常，而是值急需處理的異常。

項(xiàng)目健康度排名

通過一系列維度權(quán)重配置，給所有項(xiàng)目計(jì)算出一個健康度得分，通過得分排序即可得出當(dāng)前項(xiàng)目質(zhì)量的好壞程度，通知對應(yīng)的負(fù)責(zé)人及時處理。相關(guān)維度項(xiàng)及解釋如下：

• 24小時異常/PV比例：近24小時發(fā)生異常數(shù)量與該項(xiàng)目PV數(shù)量占比情況
• 14天異常數(shù)量：該項(xiàng)目14天發(fā)生異常數(shù)量總計(jì)數(shù)值
• 24小時異常數(shù)量：該項(xiàng)目24小時發(fā)生異常數(shù)量
• PV：統(tǒng)計(jì)該項(xiàng)目昨日所有頁面PV數(shù)量
• 是否核心項(xiàng)目：該項(xiàng)目是否標(biāo)記為核心項(xiàng)目

健康度得分計(jì)算公式：

每個維度權(quán)重占比可隨時調(diào)整，調(diào)整后會立即重新計(jì)算得分并排名，可通過維度權(quán)重的調(diào)整來提高整體項(xiàng)目的質(zhì)量要求。

sentry大盤異常監(jiān)控

對異常平臺內(nèi)所有項(xiàng)目上報的匯總值監(jiān)控，監(jiān)控的指標(biāo)有2個，突發(fā)異常數(shù)量過高，超出上一個區(qū)間數(shù)據(jù)的增量比例，另一個就是異常數(shù)據(jù)歸零，沒有收到任何異常，這種情況可能是短期異常太多導(dǎo)致平臺崩潰或其他情況導(dǎo)致無法處理異常處理，針對這兩個情況進(jìn)行異常波動記錄并觸發(fā)企業(yè)微信推送。

項(xiàng)目異常監(jiān)控

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

企微消息推送

以上2種情況最終都會觸發(fā)到企業(yè)微信消息推送，因?yàn)橄⑼扑偷挠|達(dá)更為精準(zhǔn)和迅速，但是也存在一些特殊的項(xiàng)目，比如夜間會定時任務(wù)可能存在過多的超時，本身 PV 量較高的項(xiàng)目所觸發(fā)的配置數(shù)值有所不同。所以針對推送的部分增加了相關(guān)維度的配置，推送配置有推送區(qū)間，多少時間段內(nèi)觸發(fā)一次推送，推送時異常起點(diǎn)數(shù)量，增量異常比例以及是否開啟推送。

最終企業(yè)微信推送效果如下：

超時未處理提醒

上面的項(xiàng)目波動監(jiān)控是針對項(xiàng)目整體異常情況的，除此之外還增加了針對項(xiàng)目內(nèi)部具體異常解決情況的監(jiān)控并推送，獲取到項(xiàng)目內(nèi)部所有異常，定期執(zhí)行推送，在消息推送內(nèi)容中標(biāo)明當(dāng)前存在的異常數(shù)量，針對超過3日還未處理的異常@對應(yīng)負(fù)責(zé)人，以提高相關(guān)人員警覺。最終企業(yè)微笑推送效果如下：

整體流程如下：

高效解決異常

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

知識庫解決方案沉淀

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

如該問題已有提交的文檔記錄，則進(jìn)入異常問題詳情頁面時，右上角會有提示已解決方案參考地址，點(diǎn)擊鏈接跳轉(zhuǎn)到內(nèi)部文檔查看對應(yīng)的解決方案。

內(nèi)部文檔搜索關(guān)聯(lián)

研發(fā)同學(xué)都有記錄文檔的習(xí)慣，但是歷史文檔和 Sentry 并沒有任何關(guān)聯(lián)關(guān)系，所以在 Sentry 異常詳情頁面中新增按鈕跳轉(zhuǎn)到內(nèi)部文檔搜索，如有類似文檔沉淀，則可以直接參考解決。

一鍵進(jìn)入開發(fā)，內(nèi)部系統(tǒng)打通

Sentry 本身是一套獨(dú)立的開源項(xiàng)目，所以和公司內(nèi)部其他的系統(tǒng)沒有任何關(guān)聯(lián)關(guān)系，導(dǎo)致無法和其他系統(tǒng)進(jìn)行聯(lián)動操作，比如創(chuàng)建分支，查詢內(nèi)部項(xiàng)目相關(guān)信息等。導(dǎo)致每次解決異常時都需要創(chuàng)建需求和分支才能進(jìn)入到開發(fā)中，整個流程重復(fù)且繁瑣。

基于這個背景在 Sentry 異常詳情頁面中增加一鍵創(chuàng)建需求和分支的能力，可快遞進(jìn)入到開發(fā)過程中。整個流程如下：

涉及調(diào)用其他系統(tǒng)的接口較多，細(xì)節(jié)就不過多說明。核心就是基于異常詳情中的頁面地址解析出項(xiàng)目內(nèi)部相關(guān)信息，基于這個數(shù)據(jù)創(chuàng)建tapd需求，創(chuàng)建項(xiàng)目倉庫開發(fā)分支并和當(dāng)前異常信息綁定記錄。

自動分發(fā)接口異常責(zé)任人

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

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

推送效果如下：

整體流程如下：

總結(jié)

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

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

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