1 背景
客服一站式工作台內建了線上、熱線和工單三個核心應用，支撐着自營客服和 BPO 客服每天處理大量的會話資訊，工作台的穩定性就顯得非常重要。接入前端監控以來，我們堅持每雙周跟進工作台以及客服幾個核心應用的線上穩定性情況，圍繞頁面的通路情況、JS 錯誤率、資源加載異常情況、API 接口成功率、自定義業務子產品名額 這五大監控子產品，做了詳細的資料分析，從中發現了很多問題并且通過實時告警解決了潛在的問題，也通過資料分析推進了客服職場完善工作台的運作環境。本文主要闡述我們是如何通過監控穩定性資料分析來提升應用系統的穩定性。
2 監控的原理
客服一站式工作台接入監控時通過多方調研最終采用了 Arms 的監控方案，并基于 Arms 的監控方案，做了二次開發，整體的監控實作如下圖所示：
Arms 提供的 SDK 功能比較齊全，為滿足一些定制化的資料上報訴求、應用資料權限管控以及控制上報成本，客服域接入時基于 alife-logger 進行了二次封裝，對功能更加的可控， 同時定期從阿裡雲平台進行資料初始化和生成定制化報表。
3 監控的實踐
3.1 頁面 PV&UV 監控場景
PV 即頁面浏覽量，通常是衡量一個網站甚至一個子產品使用情況的主要名額。UV 即獨立訪客數，是指某站點被多少使用者通路過，以使用者登入态作為統計依據。頁面的 PV 和 UV 很大程度上回報了應用各頁面功能的使用情況，能為産品功能優化以及相關業務決策提供很好的資料支援 。我們針對客服域已接入監控的應用連續幾個疊代的 PV、UV 資料分析，主要在如下事項起到了很好的推進和決策作用：
- 新功能上線效果分析：通過分析頁面業務功能子產品 PV 相關資料，可以分析對應上新功能的使用情況。若發現部分功能客戶觸達率較低，就可以與業務溝通确認是功能設計問題還是上線功能布達問題，快速做出營運政策調整；
- 下線無用子產品：通過頁面使用情況分析，對系統中通路量比較少的頁面做了彙總分析，同産品營運确定之後，對線上客服管理系統和工單管理系統中的 9 個頁面做了下線處理，減少了頁面的維護成本；
- 支撐技術改造優先級政策：在技術棧遷移的過程中，可以優先對通路量比較高的頁面進行遷移，一般頁面通路量高的對應的需求疊代也比較頻繁，通過頁面通路排序，按優先級去做遷移可以提升整體投入的 ROI；
- 助力系統體驗優化：通過分析較高 PV 頁面使用者通路鍊路，将取消訂單、建立賠付單等需要高頻但需要打開其他頁面操作的功能內建到客服聊天頁座席助手子產品，提升客服的工作效率。
3.2 JS 錯誤率監控
腳本錯誤主要有兩類：文法錯誤、運作時錯誤。簡單來說就是使用者在一些特殊場景下浏覽器上報 JS 的異常，甚至會造成系統卡頓、頁面不可用等極端情況，這會極大地降低使用者體驗。是以我們通過監控系統對核心系統關鍵鍊路、關鍵名額做好異常資料分析設定監控預警 ，達到設定的門檻值則發送飛書或短信告警，值班同學關注告警資訊能夠及時做出響應，同時針對告警錯誤内容進行專項治理，達到效果如下：
- 提升系統穩定性: 總計處理 41 個 JS 腳本異常治理，過程中發現異常業務場景并進行專項治理，很大程度上提升系統的穩定性。
- 發現隐藏問題： 通過監控發現 JS 錯誤數增加，排查發現數量正在上升，實時聯系一個正在觸發報錯的客服遠端，發現是接入的三方 SDK 釋出新版版本，在特殊情況會出現報錯，及時同步對應的三方同學進行改正，有效避免因外部依賴釋出帶來的隐藏問題。
3.3 API 請求優化
監控提供應用中每個 API 的調用情況，包括調用次數、調用成功率、傳回資訊、調用成功或失敗的平均耗時 等資料。通過分析指定時間段内應用中所有 API 請求資料，可以深度挖掘以下業務代碼實作和接口穩定性一些相關的問題：
- 下線不必要調用： 排查過程中發現部分埋點調用頻次很高，但是實際報表資料并未運用起來，與業務溝通後發現為曆史遺留邏輯，目前已無用，是以進行下架。減少不必要的接口調用，釋放更多的浏覽器請求資源。
- 減少備援調用： 共治理接口高頻調用治理調用 5 個，通過分析發現部分非核心功能的接口調用量較大，代碼走讀發現此部分接口為實時性要求不高枚舉清單的接口，可以通過前端緩存的方式減少接口調用次數，進而提高使用者切換會話效率和減少伺服器的調用壓力。
- 優化技術方案： 客服一站式工作台存在長鍊和短鍊調用結合的情況，在我們日常監控分析中發現部分短連結口調用量大。經過代碼走查和調用鍊路分析發現由于業務功能需要，隻要客服切換會話，就會拉取目前會話最近五條消息發起短鍊請求，造成切換會話會有卡頓感，同時很容易出現由于短鍊并發較多，頻繁切換回話後會出現串線的情況。是以與後端溝通後，将原先技術方案内的短鍊調用改為長鍊消息推送，很大程度上減少接口調用和消息不實時的情況，提升使用者體驗和系統穩定性。
3.4 靜态資源加載異常優化
靜态資源加載分為頁面内的圖檔、CSS、JS 等 Assets 資源加載失敗。目前客服 BPO 職場均有安全管控，是以會出現營運或者其他應用上傳的靜态資源連結、圖檔等資源，部分 BPO 打不開的情況，通過前端監控發現以下幾個問題：
- 圖檔資源加載異常： 随着一站式工作台的業務拓展，陸續支援等其他租戶的客戶進線。業務上線後，我們通過監控發現資源錯誤數量出現上漲，排查後确認由于商品圖檔等資源都是配置的 CDN 位址，需要 BPO 職場開通網絡白名單客服才可以看到指定的圖檔資源。通過監控快速定位對應的職場，同步對應的職場 IT 負責人進行處理。
- 營運配置錯誤位址修正： 通過監控資料分析，發現不少報錯的靜态資源位址中有飛書内網位址和竹間遷移遺留資源的情況，内網位址外網是無法打開的，會給客服帶來不少困擾。經确認為營運遷移過程中存在遺漏造成，聯系對應的營運同學進行專項治理，及時減少問題影響面。
3.5 頁面加載性能優化
頁面性能對使用者體驗而言十分關鍵。每次重構對頁面性能的提升，僅靠工程師開發裝置的測試資料是沒有說服力的，需要有大量的真實資料用于驗證；比如客服職場普遍回報商品詳情頁面打開慢，影響到了客服的工作效率，體驗很不好。為了明确具體加載慢的點，我們針對頁面加載到頁面可用這個過程中以下幾個時間節點進行埋點：
- e_product_finish【總耗時 ms】: 商品詳情頁面打開到所有資源均加載完成(包含圖檔與請求)耗時
- e_product_loadImg【加載圖檔耗時 ms】： 接口請求回來到所有圖檔加載完成耗時
- e_product_loadAndfetch【請求耗時 ms】： 商品詳情頁面加載靜态資源 &&發起請求耗時
經過三天的線上資料分析發現，大部分耗時在加載圖檔耗時上。分析耗時較長的商品詳情上下鍊路，發現此類商品的圖檔大多為 500kb+甚至 1MB 左右的圖檔 ，單個商品最多的情況下商品輪播圖近 52 張圖，加上商品細節圖、商品穿搭效果圖等，單個商品詳情頁面首次打開竟然需要加載 80+張圖檔，對于浏覽器而言是災難性的。
是以經過和産品商量，我們針對商品詳情頁面進行了加載略縮圖替換高清大圖，同時減少首次加載圖檔個數(首次隻加載 5 張圖，點選檢視更多後才加載剩餘部分圖檔資源)等一系列的優化政策，很大程度上提升了商品詳情頁面的頁面體驗。如圖下圖，為 12 月 19 日我們優化上線後，圖檔資源加載耗時均值趨勢圖，有了很明顯的下降趨勢。
4 監控的成效
接入監控至今半年多的時間裡，章魚一站式工作台的穩定性有了非常大的提升，通過治理和告警以及推進各職場運作環境的完善，大大減少了線上 TS 問題的回報以及避免了線上潛在問題的發生。
4.1 線上 TS 問題的減少
接入監控以來，通過雙周穩定性周會的治理，歸因于前端的 TS 問題數量不斷的減少，在雙十一和雙十二大促期間，也持續的穩定在 5 個以下 。## 4.2 潛在問題的發現通過監控告警至少發現潛在的問題不少于 5 處 ，通過告警資訊及時解決了潛在問題的風險，避免了線上問題的發生。這裡舉一個非常典型的接口逾時告警的例子：擷取使用者标簽資訊接口逾時告警
通過監控告警發現，查詢使用者标簽資訊接口 1 分鐘内 1 個使用者多次調用失敗 ，這個明顯是有問題的。在跟網關和後端對接之後，發現主要的原因是：一站式工作台裡面的線上和離線進線的會話清單有使用者标簽的顯示，當使用者重新重新整理浏覽器的時候，會同時調用線上和離線的使用者資訊，離線使用者未及時關閉的話，會導緻較多的逾時短鍊請求。雖然該接口為非核心鍊路接口，但大量的短鍊調用是一個潛在的風險，後面跟産品商量之後，将進線清單的使用者标簽删除，取消接口請求。
4.3 推進客服職場工作台運作環境的穩定
客服職場的環境是非常複雜的，浏覽器使用的多樣性以及不一樣的版本都會帶來不可預知的問題，導緻前期很多的客服回報，研發同學投入了大量的時間去做問題定位，最終發現是浏覽器版本過低導緻。是以針對這個情況，我們定期彙總了浏覽器版本的使用情況，告知給業務，讓業務推進各職場浏覽器版本的更新和統一。
從監控資料來看，存在火狐浏覽器、搜狗浏覽器、QQ 浏覽器和 android 手機浏覽器 ，對于這些浏覽器，基本都存在一些相容性問題，因為一站式工作台裡面的技術更新用了較多的浏覽器新特性來對業務子產品做了重構，故對于非 chrome 浏覽器存在相容性問題，這也是為什麼有些職場客服回報如工單詳情打不開、訂單詳情打開異常等問題。
chrome 浏覽器低版本資料彙總：
在幾次推進之後，目前因浏覽器版本回報的問題已經大大減少，很大程度減少研發在浏覽器版本問題排查的時間。
4.4 核心性能名額的監控
目前除了上面商品詳情頁的監控名額，我們還對工單詳情頁面和訂單詳情頁面的渲染時間以及消息接收和發送的耗時做了監控，當超過一定的門檻值，就會上報告警資訊。目前工單詳情和訂單詳情頁面經過多次的重構，整體的渲染耗時已經穩定在 500 毫秒左右，做到了秒開，具體可以看近一周的渲染趨勢：近 7 天工單詳情頁面渲染趨勢：
近 7 天訂單詳情頁面渲染趨勢：
我們也對消息接收與發送耗時核心鍊路做了重構，目前也沒有回報消息接收和發送耗時帶來的延遲卡頓問題。
對于接收消息的告警我們隻會對超過 700 毫秒的時候做告警，因為大部分的消息接收和發送都在 100 毫秒以内，客服是無感覺的。
5 總結
客服各系統自接入監控至今也有半年多的時間，監控是我們系統釋出上線的定心丸，同時通過監控資料也能夠幫助我們看出不少系統存在的問題，為我們的系統穩定性提升以及系統體驗優化做出不少貢獻。好消息是我們得物自研監控平台也正逐漸建設完善中 ，目前前端平台、穩定性監控平台和效率工程一起協作開發的前端監控産品初版已經完成，客服前端這邊也逐漸将應用遷移至自研的監控平台，相信随着自研監控能力的的不斷完善，我們能夠在前端監控這一塊取得更好的成績。