建站
咨詢
售后
建站咨詢
新聞中心
1、?背景
客服一站式工作臺集成了在線、熱線和工單三個核心應(yīng)用，支撐著自營客服和BPO客服每天處理大量的會話信息，工作臺的穩(wěn)定性就顯得非常重要。接入前端監(jiān)控以來，我們堅持每雙周跟進工作臺以及客服幾個核心應(yīng)用的線上穩(wěn)定性情況，圍繞頁面的訪問情況、JS錯誤率、資源加載異常情況、API接口成功率、自定義業(yè)務(wù)模塊指標(biāo)這五大監(jiān)控模塊，做了詳細(xì)的數(shù)據(jù)分析，從中發(fā)現(xiàn)了很多問題并且通過實時告警解決了潛在的問題，也通過數(shù)據(jù)分析推進了客服職場完善工作臺的運行環(huán)境。本文主要闡述我們是如何通過監(jiān)控穩(wěn)定性數(shù)據(jù)分析來提升應(yīng)用系統(tǒng)的穩(wěn)定性。
成都創(chuàng)新互聯(lián)為客戶提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、程序、域名、空間一條龍服務(wù)，提供基于WEB的系統(tǒng)開發(fā). 服務(wù)項目涵蓋了網(wǎng)頁設(shè)計、網(wǎng)站程序開發(fā)、WEB系統(tǒng)開發(fā)、微信二次開發(fā)、移動網(wǎng)站建設(shè)等網(wǎng)站方面業(yè)務(wù)。
2、監(jiān)控的原理
客服一站式工作臺接入監(jiān)控時通過多方調(diào)研最終采用了Arms的監(jiān)控方案，并基于Arms的監(jiān)控方案，做了二次開發(fā)，整體的監(jiān)控實現(xiàn)如下圖所示：
Arms提供的SDK功能比較齊全，為滿足一些定制化的數(shù)據(jù)上報訴求、應(yīng)用數(shù)據(jù)權(quán)限管控以及控制上報成本，客服域接入時基于alife-logger進行了二次封裝，對功能更加的可控， 同時定期從阿里云平臺進行數(shù)據(jù)初始化和生成定制化報表。
3、監(jiān)控的實踐?
3.1 頁面PV&UV監(jiān)控場景
PV即頁面瀏覽量，通常是衡量一個網(wǎng)站甚至一個模塊使用情況的主要指標(biāo)。UV即獨立訪客數(shù)，是指某站點被多少用戶訪問過，以用戶登錄態(tài)作為統(tǒng)計依據(jù)。頁面的PV和UV很大程度上反饋了應(yīng)用各頁面功能的使用情況，能為產(chǎn)品功能優(yōu)化以及相關(guān)業(yè)務(wù)決策提供很好的數(shù)據(jù)支持。我們針對客服域已接入監(jiān)控的應(yīng)用連續(xù)幾個迭代的PV、UV數(shù)據(jù)分析，主要在如下事項起到了很好的推進和決策作用：
- 新功能上線效果分析：通過分析頁面業(yè)務(wù)功能模塊PV相關(guān)數(shù)據(jù)，可以分析對應(yīng)上新功能的使用情況。若發(fā)現(xiàn)部分功能客戶觸達(dá)率較低，就可以與業(yè)務(wù)溝通確認(rèn)是功能設(shè)計問題還是上線功能布達(dá)問題，快速做出運營策略調(diào)整；
- 下線無用模塊：通過頁面使用情況分析，對系統(tǒng)中訪問量比較少的頁面做了匯總分析，同產(chǎn)品運營確定之后，對在線客服管理系統(tǒng)和工單管理系統(tǒng)中的9個頁面做了下線處理，減少了頁面的維護成本；
- 支撐技術(shù)改造優(yōu)先級策略：在技術(shù)棧遷移的過程中，可以優(yōu)先對訪問量比較高的頁面進行遷移，一般頁面訪問量高的對應(yīng)的需求迭代也比較頻繁，通過頁面訪問排序，按優(yōu)先級去做遷移可以提升整體投入的ROI；
- 助力系統(tǒng)體驗優(yōu)化：通過分析較高PV頁面用戶訪問鏈路，將取消訂單、創(chuàng)建賠付單等需要高頻但需要打開其他頁面操作的功能集成到客服聊天頁座席助手模塊，提升客服的工作效率。
3.2 JS錯誤率監(jiān)控
腳本錯誤主要有兩類：語法錯誤、運行時錯誤。簡單來說就是用戶在一些特殊場景下瀏覽器上報 JS 的異常，甚至?xí)斐上到y(tǒng)卡頓、頁面不可用等極端情況，這會極大地降低用戶體驗。因此我們通過監(jiān)控系統(tǒng)對核心系統(tǒng)關(guān)鍵鏈路、關(guān)鍵指標(biāo)做好異常數(shù)據(jù)分析設(shè)置監(jiān)控預(yù)警，達(dá)到設(shè)定的閾值則發(fā)送飛書或短信告警，值班同學(xué)關(guān)注告警信息能夠及時做出響應(yīng)，同時針對告警錯誤內(nèi)容進行專項治理，達(dá)到效果如下：
- 提升系統(tǒng)穩(wěn)定性: 總計處理41個JS腳本異常治理，過程中發(fā)現(xiàn)異常業(yè)務(wù)場景并進行專項治理，很大程度上提升系統(tǒng)的穩(wěn)定性。
- 發(fā)現(xiàn)隱藏問題：通過監(jiān)控發(fā)現(xiàn)JS錯誤數(shù)增加，排查發(fā)現(xiàn)數(shù)量正在上升，實時聯(lián)系一個正在觸發(fā)報錯的客服遠(yuǎn)程，發(fā)現(xiàn)是接入的三方SDK發(fā)布新版版本，在特殊情況會出現(xiàn)報錯，及時同步對應(yīng)的三方同學(xué)進行改正，有效避免因外部依賴發(fā)布帶來的隱藏問題。
3.3 API請求優(yōu)化
監(jiān)控提供應(yīng)用中每個API的調(diào)用情況，包括調(diào)用次數(shù)、調(diào)用成功率、返回信息、調(diào)用成功或失敗的平均耗時等數(shù)據(jù)。通過分析指定時間段內(nèi)應(yīng)用中所有API請求數(shù)據(jù)，可以深度挖掘以下業(yè)務(wù)代碼實現(xiàn)和接口穩(wěn)定性一些相關(guān)的問題：
- 下線不必要調(diào)用：排查過程中發(fā)現(xiàn)部分埋點調(diào)用頻次很高，但是實際報表數(shù)據(jù)并未運用起來，與業(yè)務(wù)溝通后發(fā)現(xiàn)為歷史遺留邏輯，目前已無用，所以進行下架。減少不必要的接口調(diào)用，釋放更多的瀏覽器請求資源。
- 減少冗余調(diào)用：共治理接口高頻調(diào)用治理調(diào)用 5 個，通過分析發(fā)現(xiàn)部分非核心功能的接口調(diào)用量較大，代碼走讀發(fā)現(xiàn)此部分接口為實時性要求不高枚舉列表的接口，可以通過前端緩存的方式減少接口調(diào)用次數(shù)，從而提高用戶切換會話效率和減少服務(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ù)功能需要，只要客服切換會話，就會拉取當(dāng)前會話最近五條消息發(fā)起短鏈請求，造成切換會話會有卡頓感，同時很容易出現(xiàn)由于短鏈并發(fā)較多，頻繁切換回話后會出現(xiàn)串線的情況。所以與后端溝通后，將原先技術(shù)方案內(nèi)的短鏈調(diào)用改為長鏈消息推送，很大程度上減少接口調(diào)用和消息不實時的情況，提升用戶體驗和系統(tǒng)穩(wěn)定性。
3.4 靜態(tài)資源加載異常優(yōu)化
靜態(tài)資源加載分為頁面內(nèi)的圖片、CSS、JS等Assets資源加載失敗。目前客服BPO職場均有安全管控，所以會出現(xiàn)運營或者其他應(yīng)用上傳的靜態(tài)資源鏈接、圖片等資源，部分BPO打不開的情況，通過前端監(jiān)控發(fā)現(xiàn)以下幾個問題：
- 圖片資源加載異常：隨著一站式工作臺的業(yè)務(wù)拓展，陸續(xù)支持等其他租戶的客戶進線。業(yè)務(wù)上線后，我們通過監(jiān)控發(fā)現(xiàn)資源錯誤數(shù)量出現(xiàn)上漲，排查后確認(rèn)由于商品圖片等資源都是配置的CDN地址，需要BPO職場開通網(wǎng)絡(luò)白名單客服才可以看到指定的圖片資源。通過監(jiān)控快速定位對應(yīng)的職場，同步對應(yīng)的職場IT負(fù)責(zé)人進行處理。
- 運營配置錯誤地址修正：通過監(jiān)控數(shù)據(jù)分析，發(fā)現(xiàn)不少報錯的靜態(tài)資源地址中有飛書內(nèi)網(wǎng)地址和竹間遷移遺留資源的情況，內(nèi)網(wǎng)地址外網(wǎng)是無法打開的，會給客服帶來不少困擾。經(jīng)確認(rèn)為運營遷移過程中存在遺漏造成，聯(lián)系對應(yīng)的運營同學(xué)進行專項治理，及時減少問題影響面。
3.5 頁面加載性能優(yōu)化
頁面性能對用戶體驗而言十分關(guān)鍵。每次重構(gòu)對頁面性能的提升，僅靠工程師開發(fā)設(shè)備的測試數(shù)據(jù)是沒有說服力的，需要有大量的真實數(shù)據(jù)用于驗證；比如客服職場普遍反饋商品詳情頁面打開慢，影響到了客服的工作效率，體驗很不好。為了明確具體加載慢的點，我們針對頁面加載到頁面可用這個過程中以下幾個時間節(jié)點進行埋點：
- e_product_finish【總耗時ms】: 商品詳情頁面打開到所有資源均加載完成(包含圖片與請求)耗時
- e_product_loadImg【加載圖片耗時ms】：接口請求回來到所有圖片加載完成耗時
- e_product_loadAndfetch【請求耗時ms】：商品詳情頁面加載靜態(tài)資源&&發(fā)起請求耗時
經(jīng)過三天的線上數(shù)據(jù)分析發(fā)現(xiàn)，大部分耗時在加載圖片耗時上。分析耗時較長的商品詳情上下鏈路，發(fā)現(xiàn)此類商品的圖片大多為500kb+甚至1MB左右的圖片，單個商品最多的情況下商品輪播圖近52張圖，加上商品細(xì)節(jié)圖、商品穿搭效果圖等，單個商品詳情頁面首次打開竟然需要加載80+張圖片，對于瀏覽器而言是災(zāi)難性的。
所以經(jīng)過和產(chǎn)品商量，我們針對商品詳情頁面進行了加載略縮圖替換高清大圖，同時減少首次加載圖片個數(shù)(首次只加載5張圖，點擊查看更多后才加載剩余部分圖片資源)等一系列的優(yōu)化策略，很大程度上提升了商品詳情頁面的頁面體驗。如圖下圖，為12月19日我們優(yōu)化上線后，圖片資源加載耗時均值趨勢圖，有了很明顯的下降趨勢。
4、監(jiān)控的成效?
接入監(jiān)控至今半年多的時間里，章魚一站式工作臺的穩(wěn)定性有了非常大的提升，通過治理和告警以及推進各職場運行環(huán)境的完善，大大減少了線上TS問題的反饋以及避免了線上潛在問題的發(fā)生。
4.1 線上TS問題的減少
接入監(jiān)控以來，通過雙周穩(wěn)定性周會的治理，歸因于前端的TS問題數(shù)量不斷的減少，在雙十一和雙十二大促期間，也持續(xù)的穩(wěn)定在5個以下。
4.2 潛在問題的發(fā)現(xiàn)
通過監(jiān)控告警至少發(fā)現(xiàn)潛在的問題不少于5處，通過告警信息及時解決了潛在問題的風(fēng)險，避免了線上問題的發(fā)生。這里舉一個非常典型的接口超時告警的例子：獲取用戶標(biāo)簽信息接口超時告警
通過監(jiān)控告警發(fā)現(xiàn)，查詢用戶標(biāo)簽信息接口1分鐘內(nèi)1個用戶多次調(diào)用失敗，這個明顯是有問題的。在跟網(wǎng)關(guān)和后端對接之后，發(fā)現(xiàn)主要的原因是：一站式工作臺里面的在線和離線進線的會話列表有用戶標(biāo)簽的顯示，當(dāng)用戶重新刷新瀏覽器的時候，會同時調(diào)用在線和離線的用戶信息，離線用戶未及時關(guān)閉的話，會導(dǎo)致較多的超時短鏈請求。雖然該接口為非核心鏈路接口，但大量的短鏈調(diào)用是一個潛在的風(fēng)險，后面跟產(chǎn)品商量之后，將進線列表的用戶標(biāo)簽刪除，取消接口請求。
4.3 推進客服職場工作臺運行環(huán)境的穩(wěn)定
客服職場的環(huán)境是非常復(fù)雜的，瀏覽器使用的多樣性以及不一樣的版本都會帶來不可預(yù)知的問題，導(dǎo)致前期很多的客服反饋，研發(fā)同學(xué)投入了大量的時間去做問題定位，最終發(fā)現(xiàn)是瀏覽器版本過低導(dǎo)致。所以針對這個情況，我們定期匯總了瀏覽器版本的使用情況，告知給業(yè)務(wù)，讓業(yè)務(wù)推進各職場瀏覽器版本的升級和統(tǒng)一。
從監(jiān)控數(shù)據(jù)來看，存在火狐瀏覽器、搜狗瀏覽器、QQ瀏覽器和android手機瀏覽器，對于這些瀏覽器，基本都存在一些兼容性問題，因為一站式工作臺里面的技術(shù)升級用了較多的瀏覽器新特性來對業(yè)務(wù)模塊做了重構(gòu)，故對于非chrome瀏覽器存在兼容性問題，這也是為什么有些職場客服反饋如工單詳情打不開、訂單詳情打開異常等問題。
chrome瀏覽器低版本數(shù)據(jù)匯總：
在幾次推進之后，目前因瀏覽器版本反饋的問題已經(jīng)大大減少，很大程度減少研發(fā)在瀏覽器版本問題排查的時間
4.4 核心性能指標(biāo)的監(jiān)控
目前除了上面商品詳情頁的監(jiān)控指標(biāo)，我們還對工單詳情頁面和訂單詳情頁面的渲染時間以及消息接收和發(fā)送的耗時做了監(jiān)控，當(dāng)超過一定的閾值，就會上報告警信息。目前工單詳情和訂單詳情頁面經(jīng)過多次的重構(gòu)，整體的渲染耗時已經(jīng)穩(wěn)定在500毫秒左右，做到了秒開，具體可以看近一周的渲染趨勢：
近7天工單詳情頁面渲染趨勢：
近7天訂單詳情頁面渲染趨勢：
我們也對消息接收與發(fā)送耗時核心鏈路做了重構(gòu)，目前也沒有反饋消息接收和發(fā)送耗時帶來的延遲卡頓問題。
對于接收消息的告警我們只會對超過700毫秒的時候做告警，因為大部分的消息接收和發(fā)送都在100毫秒以內(nèi)，客服是無感知的。
5、總結(jié)?
客服各系統(tǒng)自接入監(jiān)控至今也有半年多的時間，監(jiān)控是我們系統(tǒng)發(fā)布上線的定心丸，同時通過監(jiān)控數(shù)據(jù)也能夠幫助我們看出不少系統(tǒng)存在的問題，為我們的系統(tǒng)穩(wěn)定性提升以及系統(tǒng)體驗優(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)控這一塊取得更好的成績。?
名稱欄目：前端監(jiān)控穩(wěn)定性數(shù)據(jù)分析實踐
本文網(wǎng)址：http://fisionsoft.com.cn/article/djdsdsj.html
