1、?背景

客服一站式工作臺(tái)集成了在線、熱線和工單三個(gè)核心應(yīng)用，支撐著自營(yíng)客服和BPO客服每天處理大量的會(huì)話信息，工作臺(tái)的穩(wěn)定性就顯得非常重要。接入前端監(jiān)控以來(lái)，我們堅(jiān)持每雙周跟進(jìn)工作臺(tái)以及客服幾個(gè)核心應(yīng)用的線上穩(wěn)定性情況，圍繞頁(yè)面的訪問(wèn)情況、JS錯(cuò)誤率、資源加載異常情況、API接口成功率、自定義業(yè)務(wù)模塊指標(biāo)這五大監(jiān)控模塊，做了詳細(xì)的數(shù)據(jù)分析，從中發(fā)現(xiàn)了很多問(wèn)題并且通過(guò)實(shí)時(shí)告警解決了潛在的問(wèn)題，也通過(guò)數(shù)據(jù)分析推進(jìn)了客服職場(chǎng)完善工作臺(tái)的運(yùn)行環(huán)境。本文主要闡述我們是如何通過(guò)監(jiān)控穩(wěn)定性數(shù)據(jù)分析來(lái)提升應(yīng)用系統(tǒng)的穩(wěn)定性。

2、監(jiān)控的原理

客服一站式工作臺(tái)接入監(jiān)控時(shí)通過(guò)多方調(diào)研最終采用了Arms的監(jiān)控方案，并基于Arms的監(jiān)控方案，做了二次開(kāi)發(fā)，整體的監(jiān)控實(shí)現(xiàn)如下圖所示：

Arms提供的SDK功能比較齊全，為滿足一些定制化的數(shù)據(jù)上報(bào)訴求、應(yīng)用數(shù)據(jù)權(quán)限管控以及控制上報(bào)成本，客服域接入時(shí)基于alife-logger進(jìn)行了二次封裝，對(duì)功能更加的可控， 同時(shí)定期從阿里云平臺(tái)進(jìn)行數(shù)據(jù)初始化和生成定制化報(bào)表。

3、監(jiān)控的實(shí)踐?

3.1 頁(yè)面PV&UV監(jiān)控場(chǎng)景

PV即頁(yè)面瀏覽量，通常是衡量一個(gè)網(wǎng)站甚至一個(gè)模塊使用情況的主要指標(biāo)。UV即獨(dú)立訪客數(shù)，是指某站點(diǎn)被多少用戶訪問(wèn)過(guò)，以用戶登錄態(tài)作為統(tǒng)計(jì)依據(jù)。頁(yè)面的PV和UV很大程度上反饋了應(yīng)用各頁(yè)面功能的使用情況，能為產(chǎn)品功能優(yōu)化以及相關(guān)業(yè)務(wù)決策提供很好的數(shù)據(jù)支持。我們針對(duì)客服域已接入監(jiān)控的應(yīng)用連續(xù)幾個(gè)迭代的PV、UV數(shù)據(jù)分析，主要在如下事項(xiàng)起到了很好的推進(jìn)和決策作用：

• 新功能上線效果分析：通過(guò)分析頁(yè)面業(yè)務(wù)功能模塊PV相關(guān)數(shù)據(jù)，可以分析對(duì)應(yīng)上新功能的使用情況。若發(fā)現(xiàn)部分功能客戶觸達(dá)率較低，就可以與業(yè)務(wù)溝通確認(rèn)是功能設(shè)計(jì)問(wèn)題還是上線功能布達(dá)問(wèn)題，快速做出運(yùn)營(yíng)策略調(diào)整；
  
• 下線無(wú)用模塊：通過(guò)頁(yè)面使用情況分析，對(duì)系統(tǒng)中訪問(wèn)量比較少的頁(yè)面做了匯總分析，同產(chǎn)品運(yùn)營(yíng)確定之后，對(duì)在線客服管理系統(tǒng)和工單管理系統(tǒng)中的9個(gè)頁(yè)面做了下線處理，減少了頁(yè)面的維護(hù)成本；
  
• 支撐技術(shù)改造優(yōu)先級(jí)策略：在技術(shù)棧遷移的過(guò)程中，可以?xún)?yōu)先對(duì)訪問(wèn)量比較高的頁(yè)面進(jìn)行遷移，一般頁(yè)面訪問(wèn)量高的對(duì)應(yīng)的需求迭代也比較頻繁，通過(guò)頁(yè)面訪問(wèn)排序，按優(yōu)先級(jí)去做遷移可以提升整體投入的ROI；
  
• 助力系統(tǒng)體驗(yàn)優(yōu)化：通過(guò)分析較高PV頁(yè)面用戶訪問(wèn)鏈路，將取消訂單、創(chuàng)建賠付單等需要高頻但需要打開(kāi)其他頁(yè)面操作的功能集成到客服聊天頁(yè)座席助手模塊，提升客服的工作效率。
  

3.2 JS錯(cuò)誤率監(jiān)控

腳本錯(cuò)誤主要有兩類(lèi)：語(yǔ)法錯(cuò)誤、運(yùn)行時(shí)錯(cuò)誤。簡(jiǎn)單來(lái)說(shuō)就是用戶在一些特殊場(chǎng)景下瀏覽器上報(bào) JS 的異常，甚至?xí)斐上到y(tǒng)卡頓、頁(yè)面不可用等極端情況，這會(huì)極大地降低用戶體驗(yàn)。因此我們通過(guò)監(jiān)控系統(tǒng)對(duì)核心系統(tǒng)關(guān)鍵鏈路、關(guān)鍵指標(biāo)做好異常數(shù)據(jù)分析設(shè)置監(jiān)控預(yù)警，達(dá)到設(shè)定的閾值則發(fā)送飛書(shū)或短信告警，值班同學(xué)關(guān)注告警信息能夠及時(shí)做出響應(yīng)，同時(shí)針對(duì)告警錯(cuò)誤內(nèi)容進(jìn)行專(zhuān)項(xiàng)治理，達(dá)到效果如下：

• 提升系統(tǒng)穩(wěn)定性:  總計(jì)處理41個(gè)JS腳本異常治理，過(guò)程中發(fā)現(xiàn)異常業(yè)務(wù)場(chǎng)景并進(jìn)行專(zhuān)項(xiàng)治理，很大程度上提升系統(tǒng)的穩(wěn)定性。
• 發(fā)現(xiàn)隱藏問(wèn)題：通過(guò)監(jiān)控發(fā)現(xiàn)JS錯(cuò)誤數(shù)增加，排查發(fā)現(xiàn)數(shù)量正在上升，實(shí)時(shí)聯(lián)系一個(gè)正在觸發(fā)報(bào)錯(cuò)的客服遠(yuǎn)程，發(fā)現(xiàn)是接入的三方SDK發(fā)布新版版本，在特殊情況會(huì)出現(xiàn)報(bào)錯(cuò)，及時(shí)同步對(duì)應(yīng)的三方同學(xué)進(jìn)行改正，有效避免因外部依賴(lài)發(fā)布帶來(lái)的隱藏問(wèn)題。

3.3 API請(qǐng)求優(yōu)化

監(jiān)控提供應(yīng)用中每個(gè)API的調(diào)用情況，包括調(diào)用次數(shù)、調(diào)用成功率、返回信息、調(diào)用成功或失敗的平均耗時(shí)等數(shù)據(jù)。通過(guò)分析指定時(shí)間段內(nèi)應(yīng)用中所有API請(qǐng)求數(shù)據(jù)，可以深度挖掘以下業(yè)務(wù)代碼實(shí)現(xiàn)和接口穩(wěn)定性一些相關(guān)的問(wèn)題：

• 下線不必要調(diào)用：排查過(guò)程中發(fā)現(xiàn)部分埋點(diǎn)調(diào)用頻次很高，但是實(shí)際報(bào)表數(shù)據(jù)并未運(yùn)用起來(lái)，與業(yè)務(wù)溝通后發(fā)現(xiàn)為歷史遺留邏輯，目前已無(wú)用，所以進(jìn)行下架。減少不必要的接口調(diào)用，釋放更多的瀏覽器請(qǐng)求資源。
• 減少冗余調(diào)用：共治理接口高頻調(diào)用治理調(diào)用 5 個(gè)，通過(guò)分析發(fā)現(xiàn)部分非核心功能的接口調(diào)用量較大，代碼走讀發(fā)現(xiàn)此部分接口為實(shí)時(shí)性要求不高枚舉列表的接口，可以通過(guò)前端緩存的方式減少接口調(diào)用次數(shù)，從而提高用戶切換會(huì)話效率和減少服務(wù)器的調(diào)用壓力。
• 優(yōu)化技術(shù)方案：客服一站式工作臺(tái)存在長(zhǎng)鏈和短鏈調(diào)用結(jié)合的情況，在我們?nèi)粘１O(jiān)控分析中發(fā)現(xiàn)部分短鏈接口調(diào)用量大。經(jīng)過(guò)代碼走查和調(diào)用鏈路分析發(fā)現(xiàn)由于業(yè)務(wù)功能需要，只要客服切換會(huì)話，就會(huì)拉取當(dāng)前會(huì)話最近五條消息發(fā)起短鏈請(qǐng)求，造成切換會(huì)話會(huì)有卡頓感，同時(shí)很容易出現(xiàn)由于短鏈并發(fā)較多，頻繁切換回話后會(huì)出現(xiàn)串線的情況。所以與后端溝通后，將原先技術(shù)方案內(nèi)的短鏈調(diào)用改為長(zhǎng)鏈消息推送，很大程度上減少接口調(diào)用和消息不實(shí)時(shí)的情況，提升用戶體驗(yàn)和系統(tǒng)穩(wěn)定性。

3.4 靜態(tài)資源加載異常優(yōu)化

靜態(tài)資源加載分為頁(yè)面內(nèi)的圖片、CSS、JS等Assets資源加載失敗。目前客服BPO職場(chǎng)均有安全管控，所以會(huì)出現(xiàn)運(yùn)營(yíng)或者其他應(yīng)用上傳的靜態(tài)資源鏈接、圖片等資源，部分BPO打不開(kāi)的情況，通過(guò)前端監(jiān)控發(fā)現(xiàn)以下幾個(gè)問(wèn)題：

• 圖片資源加載異常：隨著一站式工作臺(tái)的業(yè)務(wù)拓展，陸續(xù)支持等其他租戶的客戶進(jìn)線。業(yè)務(wù)上線后，我們通過(guò)監(jiān)控發(fā)現(xiàn)資源錯(cuò)誤數(shù)量出現(xiàn)上漲，排查后確認(rèn)由于商品圖片等資源都是配置的CDN地址，需要BPO職場(chǎng)開(kāi)通網(wǎng)絡(luò)白名單客服才可以看到指定的圖片資源。通過(guò)監(jiān)控快速定位對(duì)應(yīng)的職場(chǎng)，同步對(duì)應(yīng)的職場(chǎng)IT負(fù)責(zé)人進(jìn)行處理。
• 運(yùn)營(yíng)配置錯(cuò)誤地址修正：通過(guò)監(jiān)控?cái)?shù)據(jù)分析，發(fā)現(xiàn)不少報(bào)錯(cuò)的靜態(tài)資源地址中有飛書(shū)內(nèi)網(wǎng)地址和竹間遷移遺留資源的情況，內(nèi)網(wǎng)地址外網(wǎng)是無(wú)法打開(kāi)的，會(huì)給客服帶來(lái)不少困擾。經(jīng)確認(rèn)為運(yùn)營(yíng)遷移過(guò)程中存在遺漏造成，聯(lián)系對(duì)應(yīng)的運(yùn)營(yíng)同學(xué)進(jìn)行專(zhuān)項(xiàng)治理，及時(shí)減少問(wèn)題影響面。

3.5 頁(yè)面加載性能優(yōu)化

頁(yè)面性能對(duì)用戶體驗(yàn)而言十分關(guān)鍵。每次重構(gòu)對(duì)頁(yè)面性能的提升，僅靠工程師開(kāi)發(fā)設(shè)備的測(cè)試數(shù)據(jù)是沒(méi)有說(shuō)服力的，需要有大量的真實(shí)數(shù)據(jù)用于驗(yàn)證；比如客服職場(chǎng)普遍反饋商品詳情頁(yè)面打開(kāi)慢，影響到了客服的工作效率，體驗(yàn)很不好。為了明確具體加載慢的點(diǎn)，我們針對(duì)頁(yè)面加載到頁(yè)面可用這個(gè)過(guò)程中以下幾個(gè)時(shí)間節(jié)點(diǎn)進(jìn)行埋點(diǎn)：

• e_product_finish【總耗時(shí)ms】: 商品詳情頁(yè)面打開(kāi)到所有資源均加載完成(包含圖片與請(qǐng)求)耗時(shí)
• e_product_loadImg【加載圖片耗時(shí)ms】：接口請(qǐng)求回來(lái)到所有圖片加載完成耗時(shí)
• e_product_loadAndfetch【請(qǐng)求耗時(shí)ms】：商品詳情頁(yè)面加載靜態(tài)資源&&發(fā)起請(qǐng)求耗時(shí)

經(jīng)過(guò)三天的線上數(shù)據(jù)分析發(fā)現(xiàn)，大部分耗時(shí)在加載圖片耗時(shí)上。分析耗時(shí)較長(zhǎng)的商品詳情上下鏈路，發(fā)現(xiàn)此類(lèi)商品的圖片大多為500kb+甚至1MB左右的圖片，單個(gè)商品最多的情況下商品輪播圖近52張圖，加上商品細(xì)節(jié)圖、商品穿搭效果圖等，單個(gè)商品詳情頁(yè)面首次打開(kāi)竟然需要加載80+張圖片，對(duì)于瀏覽器而言是災(zāi)難性的。

所以經(jīng)過(guò)和產(chǎn)品商量，我們針對(duì)商品詳情頁(yè)面進(jìn)行了加載略縮圖替換高清大圖，同時(shí)減少首次加載圖片個(gè)數(shù)(首次只加載5張圖，點(diǎn)擊查看更多后才加載剩余部分圖片資源)等一系列的優(yōu)化策略，很大程度上提升了商品詳情頁(yè)面的頁(yè)面體驗(yàn)。如圖下圖，為12月19日我們優(yōu)化上線后，圖片資源加載耗時(shí)均值趨勢(shì)圖，有了很明顯的下降趨勢(shì)。

4、監(jiān)控的成效?

接入監(jiān)控至今半年多的時(shí)間里，章魚(yú)一站式工作臺(tái)的穩(wěn)定性有了非常大的提升，通過(guò)治理和告警以及推進(jìn)各職場(chǎng)運(yùn)行環(huán)境的完善，大大減少了線上TS問(wèn)題的反饋以及避免了線上潛在問(wèn)題的發(fā)生。

4.1 線上TS問(wèn)題的減少

接入監(jiān)控以來(lái)，通過(guò)雙周穩(wěn)定性周會(huì)的治理，歸因于前端的TS問(wèn)題數(shù)量不斷的減少，在雙十一和雙十二大促期間，也持續(xù)的穩(wěn)定在5個(gè)以下。

4.2 潛在問(wèn)題的發(fā)現(xiàn)

通過(guò)監(jiān)控告警至少發(fā)現(xiàn)潛在的問(wèn)題不少于5處，通過(guò)告警信息及時(shí)解決了潛在問(wèn)題的風(fēng)險(xiǎn)，避免了線上問(wèn)題的發(fā)生。這里舉一個(gè)非常典型的接口超時(shí)告警的例子：獲取用戶標(biāo)簽信息接口超時(shí)告警

通過(guò)監(jiān)控告警發(fā)現(xiàn)，查詢(xún)用戶標(biāo)簽信息接口1分鐘內(nèi)1個(gè)用戶多次調(diào)用失敗，這個(gè)明顯是有問(wèn)題的。在跟網(wǎng)關(guān)和后端對(duì)接之后，發(fā)現(xiàn)主要的原因是：一站式工作臺(tái)里面的在線和離線進(jìn)線的會(huì)話列表有用戶標(biāo)簽的顯示，當(dāng)用戶重新刷新瀏覽器的時(shí)候，會(huì)同時(shí)調(diào)用在線和離線的用戶信息，離線用戶未及時(shí)關(guān)閉的話，會(huì)導(dǎo)致較多的超時(shí)短鏈請(qǐng)求。雖然該接口為非核心鏈路接口，但大量的短鏈調(diào)用是一個(gè)潛在的風(fēng)險(xiǎn)，后面跟產(chǎn)品商量之后，將進(jìn)線列表的用戶標(biāo)簽刪除，取消接口請(qǐng)求。

4.3 推進(jìn)客服職場(chǎng)工作臺(tái)運(yùn)行環(huán)境的穩(wěn)定

客服職場(chǎng)的環(huán)境是非常復(fù)雜的，瀏覽器使用的多樣性以及不一樣的版本都會(huì)帶來(lái)不可預(yù)知的問(wèn)題，導(dǎo)致前期很多的客服反饋，研發(fā)同學(xué)投入了大量的時(shí)間去做問(wèn)題定位，最終發(fā)現(xiàn)是瀏覽器版本過(guò)低導(dǎo)致。所以針對(duì)這個(gè)情況，我們定期匯總了瀏覽器版本的使用情況，告知給業(yè)務(wù)，讓業(yè)務(wù)推進(jìn)各職場(chǎng)瀏覽器版本的升級(jí)和統(tǒng)一。

從監(jiān)控?cái)?shù)據(jù)來(lái)看，存在火狐瀏覽器、搜狗瀏覽器、QQ瀏覽器和android手機(jī)瀏覽器，對(duì)于這些瀏覽器，基本都存在一些兼容性問(wèn)題，因?yàn)橐徽臼焦ぷ髋_(tái)里面的技術(shù)升級(jí)用了較多的瀏覽器新特性來(lái)對(duì)業(yè)務(wù)模塊做了重構(gòu)，故對(duì)于非chrome瀏覽器存在兼容性問(wèn)題，這也是為什么有些職場(chǎng)客服反饋如工單詳情打不開(kāi)、訂單詳情打開(kāi)異常等問(wèn)題。

chrome瀏覽器低版本數(shù)據(jù)匯總：

在幾次推進(jìn)之后，目前因?yàn)g覽器版本反饋的問(wèn)題已經(jīng)大大減少，很大程度減少研發(fā)在瀏覽器版本問(wèn)題排查的時(shí)間

4.4 核心性能指標(biāo)的監(jiān)控

目前除了上面商品詳情頁(yè)的監(jiān)控指標(biāo)，我們還對(duì)工單詳情頁(yè)面和訂單詳情頁(yè)面的渲染時(shí)間以及消息接收和發(fā)送的耗時(shí)做了監(jiān)控，當(dāng)超過(guò)一定的閾值，就會(huì)上報(bào)告警信息。目前工單詳情和訂單詳情頁(yè)面經(jīng)過(guò)多次的重構(gòu)，整體的渲染耗時(shí)已經(jīng)穩(wěn)定在500毫秒左右，做到了秒開(kāi)，具體可以看近一周的渲染趨勢(shì)：

近7天工單詳情頁(yè)面渲染趨勢(shì)：

近7天訂單詳情頁(yè)面渲染趨勢(shì)：

我們也對(duì)消息接收與發(fā)送耗時(shí)核心鏈路做了重構(gòu)，目前也沒(méi)有反饋消息接收和發(fā)送耗時(shí)帶來(lái)的延遲卡頓問(wèn)題。

對(duì)于接收消息的告警我們只會(huì)對(duì)超過(guò)700毫秒的時(shí)候做告警，因?yàn)榇蟛糠值南⒔邮蘸桶l(fā)送都在100毫秒以?xún)?nèi)，客服是無(wú)感知的。

5、總結(jié)?

客服各系統(tǒng)自接入監(jiān)控至今也有半年多的時(shí)間，監(jiān)控是我們系統(tǒng)發(fā)布上線的定心丸，同時(shí)通過(guò)監(jiān)控?cái)?shù)據(jù)也能夠幫助我們看出不少系統(tǒng)存在的問(wèn)題，為我們的系統(tǒng)穩(wěn)定性提升以及系統(tǒng)體驗(yàn)優(yōu)化做出不少貢獻(xiàn)。好消息是我們得物自研監(jiān)控平臺(tái)也正逐步建設(shè)完善中，目前前端平臺(tái)、穩(wěn)定性監(jiān)控平臺(tái)和效率工程一起協(xié)作開(kāi)發(fā)的前端監(jiān)控產(chǎn)品初版已經(jīng)完成，客服前端這邊也逐步將應(yīng)用遷移至自研的監(jiān)控平臺(tái)，相信隨著自研監(jiān)控能力的的不斷完善，我們能夠在前端監(jiān)控這一塊取得更好的成績(jī)。?