1、工單業務簡介及核心鏈路

1.1  業務簡介

得物客服工單系統主要承載著得物與用戶關聯需要客服處理的事件，其主要功能可以認為有如下兩項：

• 承載事件的基本信息及關聯信息
• 允許客服處理事件，并可以流轉相關信息至關聯方或用戶

簡單來說就是客服根據工單信息進行流轉處理，圍繞著這個核心鏈路，工單域在處理中心、信息分類的管理配置、客服人員的管理及分配，以及信息處理過程的質檢抽檢等做了很多建設。

1.2  核心鏈路

要完成這個核心鏈路作業那就需要有一個承載平臺，那就是工單工作臺，包括工單的來源，展現，處理流轉及最終處理方案的完結，如下圖所示：

工單工作臺作為核心鏈路承載平臺，是二線客服對工單作業的“生產流水線”，是整個工單作業的核心，因此在這篇文章后續所有的優化都是圍繞著這一點來進行的。

工單作業的流程是相當復雜的，我們需要另外一張圖將核心部分的流程表達出來，如下圖所示：

• 工單中心每天會收集來自各個來源的工單，在線客服進線產生的工單是主要部分，占比一半左右。
• 二線客服根據工單的信息還有與用戶溝通的情況，需要其他客服或其他域提供協助或其他信息，此時工單會流轉至關聯方。
• 當關聯方提供相關信息或協助后，大部分工單會返回到當前客服繼續下一步處理。
• 當客服本身與客戶，其他關聯方全部協商一致后，會根據工單情形進行對應的完結處理，而完結的處理流程目前有數十種。

在這個核心的作業流水線上，平均每天有很多很多的客服處理更多更多的工單，這些客服每天工作至少非常多的時間是在章魚工單工作臺上持續的作業。

這是我們在二線客服職場調研時的場景，在工位上的客服基本都在使用工單工作臺（10個打開屏幕的，至少有九個屏幕內容是工單工作臺），說實話，作為一個前端，當上百號客服同時在你面前使用你開發的應用時，還是相當震撼的，同時也深感責任的重大。

這在前端方面對工作臺從性能，穩定性，易用性等各個角度的體驗問題上提出了很大的要求！

2、工單域前端問題

在參與工單業務開發時，工單在前端這方面存在很多的問題，這些問題集中在兩個方面：

• 面向客服同學的使用體驗問題，集中在性能，穩定性和易用性等方面；
• 面向研發同學的研發體驗或效能問題，集中在代碼維護困難，花費大量精力處理線上問題等。

而需要解決這些問題，需要多種手段多種維度介入。

3、多維度重構優化現有系統

在架構設計中, 架構形態往往是跟隨業務形態變化而變化。在客服域內，面向一二線客服作業的章魚工作臺已使用微前端來區分IM，電話，工單及工具箱；而對工單域來說，除了要開發作為章魚工作臺的子應用外，還有各個方面的架構調整或性能提升優化需要做：

3.1  聚合接口，加速工單渲染

工單詳情每次渲染初始接口數有21個，在服務端同學梳理整合這些接口成本過高的情況下，與服務端同學一起推動使用網關聚合的模式，將前端請求接口數降低至5個，整體渲染完成時間降低至600ms以內。

3.2  區分快慢，縮短訂單FMP

訂單詳情接口字段有190多個，但是其中首屏接口100多個，其中有部分字段還依賴外域，導致整個接口RT過長，前端與后端協商后，推動了快慢接口的方案的落地，其原理如下：

• 快接口：將首屏較慢的依賴外域的字段去除，經過分析, 去除最慢5個字段后，接口rt能降低到300ms以內；
• 慢接口：即全量接口，作為補充快接口未返回字段之用；
• 接口批次處理：其他接口，在以往是返回即更新，會導致頁面過于頻繁的更新，甚至抖動，因此將頁面更新機會集中在三次，以降低渲染偏移量(CLS, Cumulative Layout Shift)。

其中首屏渲染能將首屏中95%的字段優先展示，方案運行后，首屏FMP渲染時間從873ms降至376ms，下降了57%，95分位567ms，下降了62%。另外我們也在推動優化外域接口，后續將進一步降低渲染時間。

3.3  引入Module Federation， 使應用互聯

引入MF（Module Federation，遠程組件）是一個十分創新和實用的新技術轉化的舉措，其解決了子應用間互相渲染業務組件的困局：

• 使用iframe，性能差，渲染慢，內存占用高，經常導致崩潰；
• 使用npm包，嚴重推高研發維護成本，提升線上風險。

而MF遠程組件能十分完美的解決上述問題。

使用后將渲染時間降低了6倍，內存占用減少到了之前的1/10以內：

除了提升性能，在業務模塊間高效率復用也是該技術的亮點，所以這也是接下來幾個重要業務技術重構的基礎技術。

該技術方案也獲得了2022年技術部微創新之星獎，相關詳細內容也已發布到得物技術公眾號上：《Module Federation 在得物客服工單業務中的最佳實踐》。

3.4  推行單實例，提升性能

在開發工單工作臺工單詳情時，由于客服作業時經常保留多個工單詳情tab，如果詳情使用多實例，那勢必會造成頁面dom節點數多，內存占用高的情況，因此開發時就是設計成單實例的。

而工單工作臺與工單系統兩個應用隔離后，工單系統使用工作臺的詳情頁面時，由于兩個系統的技術棧是不一樣的，因此不能通過遠程組件聯通，只能使用iframe，由于工單系統打開詳情頁也有較高的頻次，每次渲染iframe也依舊很慢，因此利用iframe的postMessage通信，及工單詳情的單實例特性，工單系統切換tab時將工單號通過postMessage通知工單工作臺，再通過工單詳情的單實例切換，在非首屏場景也能取得與MF相當的響應速度。

這個方案是在兩個互相關聯的應用不是同一技術棧情況的下的過渡方案，隨著所有應用都向React遷移，未來MF仍舊是主力方案。

3.5  動態渲染，降開發維護成本

簡單來說思路就是：過簡單的數據內容的增減和修改，根據約定動態渲染，快速達成業務目標。以替代工單創單，關單流程，訂單渲染等關鍵環節的各自問題。

3.5.1  創建工單的重構

創建工單以往存在著這樣的問題：

• 不同工單類型對應創單表單不一樣，模板渲染又十分復雜
• 多個應用維護同樣業務代碼，代碼技術棧又不一致的情況，維護起來十分頭疼
• 在IM創單場景，由于客服切換IM會話頻次較快，又沒有涉及按會話ID維度的單獨表單內存存儲空間，時常會發生表單信息丟失或錯亂的情況, 線上很多問題多是由于這樣的原因導致的。

因此在設計新的架構時，設計了兩個維度的數據隔離：第一維度是會話維度，第二維度是會話內數據內容和模板數據的隔離，以便提交表單時能立即將當前表單數據內容提交。

• 一份不同會話維度的數據表，該表會隨著客服與不同用戶的會話的新增結束而動態變化
• 客服切換會話時，根據對應會話的數據，立即渲染出對應的表單內容
• 客服會高頻的切換不同的會話
• 將客服在當前創建工單表單的修改內容反應至對應的數據，這里的難點是：

有時修改數據的交互是異步的，例如修改訂單號會異步查詢訂單信息并自動填充

假設這個過程中發生了客服切換會話，那有可能導致信息錯亂

解決手段是充分利用閉包緩存的特性，當異步返回時設置對應閉包下會話id的數據內容

通過以上重構的手段，再結合Module Federation統一不同應用中的業務代碼，徹底解決了之前的問題。

相關流程圖：

3.5.2  關單流程的重構

關單流程目前存在著數十個不同的流程類型，每種流程類型客服關單時的表單內容和流程都是不一樣的，在以往都是按簡單的判斷邏輯堆砌流程，導致代碼十分冗長和復雜，在充分梳理不同流程類型的業務邏輯后，新的架構設計方案如下：

• 將不同流程類型渲染邏輯通過schema表達，由于該表達較為復雜并且與交互關聯較大，因此維護在前端
• 通過schema組件渲染器邏輯，渲染對應流程表單，也可將通用信息或特殊業務信息透傳給該流程下的對應組件
• 不同流程類型通過schema配置，可快速插拔組件和復用組件

該方案有點類似低代碼的渲染邏輯，能很好的梳理出不同流程各自的邏輯，也便于后期的開發維護，該重構上線后，前后端在關單業務上的開發比例從1:1下降至1:3，節省了很多前端開發維護成本。

3.5.3  訂單詳情的重構

訂單詳情平常需求中，約60%的需求都是配合外域或者內部的簡單的字段增改，雖然前端開發內容不多，但每個也要花費前端的開發成本。在最新的重構中，設計是這樣的：

• 將變化較大的訂單基本信息及關聯信息通過統一schema維護
• 前后端約定schema的格式，后端將對應數據通過該schema格式的數據返回
• 前端根據該格式渲染至頁面，簡單增減字段時前端無需開發，只需后端配置對應字段值即可。

該方案是前后端共同推進的，目前已上線，正在灰度中（2023年3月底），統計以往數據，訂單需求預計可節省66%的前端人力投入，在最近515的需求中已有部分需求無需在新的重構版本中投入人力。

4、發布、值班機制的健全

在以往由于人力都陷入到平常繁雜的維護和線上問題處理中，對CR等機制投入度不足，在經過一系列重構后，線上問題得到很大的緩解，因此可以人力投入到一些預防性的機制中。

4.1  發布機制

發布前會設置各項嚴格的卡口，都通過后才能發布，卡口如下

• 各環境驗證，需求確認，權限配置確認
• 每個需求都會列出前端修改點以及前端評估的影響面
• 每個需求都需要兩位以上前端對功能進行實際的驗收
• 每個需求都需要測試知曉修改點和影響面，并確認

4.2  值班機制

在之前的值班機制上加強或增加這些環節：

• 正式迭代發布次日早上，會與二線客服上班時間同步值班（早上8點半左右）

解答客服對新迭代功能的可能的疑惑

如有問題能馬上定位，采取回滾或其他方式立馬止血

• 線上客服作業問題反饋，查看最近一個季度數據，基本做到了5分鐘響應，10分鐘左右給到相應解答，大多數在響應的同時給到解答方案。

5、階段性總結

5.1  線上TS問題歸零

在首先通過多項重構優化手段改進當前架構后，架構的文檔性，線上穩定性在逐步提升，最顯著的表現就是線上TS問題反饋數在逐步的降低，至2023年Q1，線上歸因前端的TS問題數降至0個，如下所示：

5.2  滿意度穩步提升

線上問題變少了，客服系統前端可用性變高了，架構優化了，速度性能提高了，也必定會助力二線客服的體驗和滿意度節節攀升，2023年Q1滿意度達到了80%，如下所示：

注：2022年Q1由于未開始調研，暫無數據，用Q2數據替代；該數據來源于二線客服直接發放的調研問卷，平均每季度回收400多份，取分數8,9,10三個分數為滿意。

線上系統的穩定性和客服滿意度這兩個指標是系統健壯性，完善性的最終端指標，這兩個數據可以說是這一系列工作的成果，能代表在工單域所做的事情是很有成效的。

6

類端能力的探索

工單工作臺與章魚其他工作臺一樣，與傳統的中后臺系統不同，其存在這么幾個特性：

• 使用頻次高：以二線工單詳情為例，二線客服一天打開工單詳情的中位數在數百次（含重復打開）左右
• 使用時間長：一天工作時間使用工作臺時間占比90%（7+小時）以上
• 操作強度高：即頁面內表單，按鈕點擊等操作的數量和頻率（該數據收集能力在建設中）

上面所述的很多優化就是為了更好的適配這些特性所要求的高性能高速度而建設的，上述的很多特性其實更接近于桌面客戶端的一些要求，例如常見的繪圖軟件、office等辦公軟件，桌面軟件除了上述性能要求外，其實還具備其他很多特性，如：本地特性（本地權限），版本化，閉環化，緩存、狀態持久化等等。

對于工單工作臺而言，除了本地權限要求不高外，接下來遇到的挑戰與其他桌面軟件其他特性高度相似！因此接下來將圍繞著這些能力進行建設，簡稱為類端能力，這些能力根據重要性將會分為這幾個方面：

6.1  流程閉環化

客服日常作業的特點是鏈路固定，操作流程清晰是連貫持續的，而且不希望操作流程被各種窗口跳轉給意外打斷，而目前工單工作臺中或多或少存在需要跳轉到工單系統或其他系統的情況，這種情況就是非閉環的，而從日常的客服反饋及到客服現場調研的結果來看，各種鏈接外跳也是最影響操作情況，是我們要克服的而建設路徑有這幾點：

6.1.1  業務組件插件化

分析很多外跳的原因，大部分都是關聯查詢類、操作類訴求，首先這些查詢功能可能不是歸為當前項目的，那可以將所有的被依賴的功能點都插件化，主要手段就是MF。

使用Mlodule Federation：鏈接不同項目間的插件，這一方式會隨著React技術棧的統一，應用會越來越頻繁

在2022年Q4，坐席輔助的SOP項目，就是大量使用了工單/訂單的業務遠程組件，而不需要各種外跳。而工單，訂單詳情本身的外跳則需要后期不斷的插件建設和React技術棧統一來解決。

6.1.2  路由跳轉規范化

引入MF后，加上仍有部分場景的iframe，路由跳轉是日常維護中很大的一個痛點，被引用方需要進行判斷以何種方式被打開，怎么通知父項目，根據不同的方式跳轉等等問題，導致這一方面的維護成本很大，未來將針對性對路由跳轉封裝相應SDK，將各種跳轉場景進行收斂和規范。

6.1.3  便利工具內建

一些可以便利客服作業的工具內建，例如之前客服反饋需要截圖的內容在工單上傳十分麻煩：截圖->保存本地->點擊上傳->查找選取對應圖片->上傳；可以發現，這個鏈路也不是閉環的，需要跑到操作系統進行操作，而加入自動粘貼截圖內容功能后，客服的操作就變成了：截圖 -> ctrl+v粘貼 ，在工作臺內就能完成。

6.2  資源緩存與接口數據持久化與管理

在工作臺內存在著一些數據不通用，一些情況需要重復請求的情況，如工單詳情頁面切回原來工單時，其數據會被重新請求，而頁面需要重新依賴新數據進行渲染的情況，在客服作業場景，平均同一個工單號會被重復打開5次，因此這個場景值得優化。一個優化辦法是將重點接口緩存并有機更新，將主要依賴service worker技術，在嘗試中取得了很好的成績：

經過SW緩存的接口，返回速度呈現了數量級的提升；

但該方案仍有一個重點問題需要解決：

• 如何有機更新同一工單接口數據，否則可能拿到的一直是老的數據

該方案成熟上線后將使應用響應速度上一新的臺階。

6.3  其他類端能力

接下來兩個優化需要進一步與產品探討和調研。

6.3.1  版本推送

與產品探討過，增加新版本推送通知能幫助客服及早使用到新的功能，也能在解決完線上故障或回滾時立馬推送及時線上止血。

6.3.2  獨立窗口

將工作臺獨立窗口，與部分客服溝通過，認為能增加作業效率，因為發現日常作業過程中，客服需要經常切換瀏覽器其他窗口或者切換飛書，當將工作臺作為獨立窗口后，1. 可以通過快捷鍵ctrl+tab快速切換不同的應用; 2. 獨立APP應用icon打開工作臺。