1、?背景

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

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

客服一站式工作臺接入監(jiān)控時(shí)通過多方調(diào)研最終采用了Arms的監(jiān)控方案，并基于Arms的監(jiān)控方案，做了二次開發(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)行了二次封裝，對功能更加的可控， 同時(shí)定期從阿里云平臺進(jìn)行數(shù)據(jù)初始化和生成定制化報(bào)表。

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

3.1 頁面PV&UV監(jiān)控場景

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

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

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

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

• 提升系統(tǒng)穩(wěn)定性:  總計(jì)處理41個(gè)JS腳本異常治理，過程中發(fā)現(xiàn)異常業(yè)務(wù)場景并進(jìn)行專項(xiàng)治理，很大程度上提升系統(tǒng)的穩(wěn)定性。
• 發(fā)現(xiàn)隱藏問題：通過監(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í)同步對應(yīng)的三方同學(xué)進(jìn)行改正，有效避免因外部依賴發(fā)布帶來的隱藏問題。

3.3 API請求優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

4.1 線上TS問題的減少

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

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

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

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

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

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

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

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

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

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

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

近7天工單詳情頁面渲染趨勢：

近7天訂單詳情頁面渲染趨勢：

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

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

5、總結(jié)?

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