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

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

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

異常治理重要性

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

用戶體驗(yàn)

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

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

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

公司成本

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

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

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

• 規(guī)范上報(bào)異常數(shù)據(jù)，規(guī)范上報(bào)異常標(biāo)題格式，以及其他附加數(shù)據(jù)，如sentry 中的 tag，additional 數(shù)據(jù)等，以便于在不同的項(xiàng)目中都可以快速參考分析問題，另外就是要規(guī)范異常上報(bào)的時(shí)機(jī)，除開被動(dòng)上報(bào)異常，其他用戶主動(dòng)操作行為產(chǎn)生的異常要及時(shí)上報(bào)，如接口異常，復(fù)雜邏輯中特定時(shí)機(jī)上報(bào)異常記錄分析。
• 部分異常過濾，針對(duì)某些框架底層異?；蚴且阎獦I(yè)務(wù)場(chǎng)景正常接口異常等，可直接過濾處理，不再顯示到異常平臺(tái)中再次處理。這類異常過濾的過程可以在SDK 全局進(jìn)行過濾處理，針對(duì)不同的項(xiàng)目可額外增加不同的過濾條件，也可在異常平臺(tái)針對(duì)某些重要性較低的項(xiàng)目直接過濾處理。
• 部分自動(dòng)處理，自動(dòng)處理分為幾個(gè)情況：自動(dòng)刪除，自動(dòng)標(biāo)記解決，自動(dòng)列為忽略異常。經(jīng)過上面的過濾后的異常，會(huì)再一次過濾處理，這類處理的異常內(nèi)容可以是某些業(yè)務(wù)場(chǎng)景需要上報(bào)的接口異常但不能歸屬于代碼邏輯錯(cuò)誤，比如提交訂單時(shí)，某個(gè)新出的機(jī)型未在后臺(tái)新增，觸發(fā)這個(gè)異常后運(yùn)營(yíng)會(huì)立即處理，后續(xù)不會(huì)再發(fā)生。針對(duì)這類型的異常可以使用程序自動(dòng)處理。
• 完善健康度所需各維度數(shù)據(jù)，判斷一個(gè)項(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ù)處理，接下來(lái)經(jīng)過 SDK 上報(bào)到異常平臺(tái)顯示的數(shù)據(jù)就是我們要真正處理的異常數(shù)據(jù)。以轉(zhuǎn)轉(zhuǎn)舉例，目前已經(jīng)接入 Sentry 的前端項(xiàng)目有 **500+**，每天上報(bào)的異常數(shù)量約 250 萬(wàn)次，在如此大的體量下如何快速發(fā)現(xiàn)哪些才是目前緊急需處理的異常呢？

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

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

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

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

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

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

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

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

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

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

企微消息推送

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

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

超時(shí)未處理提醒

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

整體流程如下：

高效解決異常

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

知識(shí)庫(kù)解決方案沉淀

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

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

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

研發(fā)同學(xué)都有記錄文檔的習(xí)慣，但是歷史文檔和 Sentry 并沒有任何關(guān)聯(lián)關(guān)系，所以在 Sentry 異常詳情頁(yè)面中新增按鈕跳轉(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)致無(wú)法和其他系統(tǒng)進(jìn)行聯(lián)動(dòng)操作，比如創(chuàng)建分支，查詢內(nèi)部項(xiàng)目相關(guān)信息等。導(dǎo)致每次解決異常時(shí)都需要?jiǎng)?chuàng)建需求和分支才能進(jìn)入到開發(fā)中，整個(gè)流程重復(fù)且繁瑣。

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

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

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

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

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

推送效果如下：

整體流程如下：

總結(jié)

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

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

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