1、工單業(yè)務(wù)簡介及核心鏈路

1.1  業(yè)務(wù)簡介

得物客服工單系統(tǒng)主要承載著得物與用戶關(guān)聯(lián)需要客服處理的事件，其主要功能可以認(rèn)為有如下兩項：

• 承載事件的基本信息及關(guān)聯(lián)信息
• 允許客服處理事件，并可以流轉(zhuǎn)相關(guān)信息至關(guān)聯(lián)方或用戶

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

1.2  核心鏈路

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

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

工單作業(yè)的流程是相當(dāng)復(fù)雜的，我們需要另外一張圖將核心部分的流程表達(dá)出來，如下圖所示：

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

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

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

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

2、工單域前端問題

在參與工單業(yè)務(wù)開發(fā)時，工單在前端這方面存在很多的問題，這些問題集中在兩個方面：

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

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

3、多維度重構(gòu)優(yōu)化現(xiàn)有系統(tǒng)

在架構(gòu)設(shè)計中, 架構(gòu)形態(tài)往往是跟隨業(yè)務(wù)形態(tài)變化而變化。在客服域內(nèi)，面向一二線客服作業(yè)的章魚工作臺已使用微前端來區(qū)分IM，電話，工單及工具箱；而對工單域來說，除了要開發(fā)作為章魚工作臺的子應(yīng)用外，還有各個方面的架構(gòu)調(diào)整或性能提升優(yōu)化需要做：

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

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

3.2  區(qū)分快慢，縮短訂單FMP

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

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

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

3.3  引入Module Federation， 使應(yīng)用互聯(lián)

引入MF（Module Federation，遠(yuǎn)程組件）是一個十分創(chuàng)新和實用的新技術(shù)轉(zhuǎn)化的舉措，其解決了子應(yīng)用間互相渲染業(yè)務(wù)組件的困局：

• 使用iframe，性能差，渲染慢，內(nèi)存占用高，經(jīng)常導(dǎo)致崩潰；
• 使用npm包，嚴(yán)重推高研發(fā)維護(hù)成本，提升線上風(fēng)險。

而MF遠(yuǎn)程組件能十分完美的解決上述問題。

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

除了提升性能，在業(yè)務(wù)模塊間高效率復(fù)用也是該技術(shù)的亮點，所以這也是接下來幾個重要業(yè)務(wù)技術(shù)重構(gòu)的基礎(chǔ)技術(shù)。

該技術(shù)方案也獲得了2022年技術(shù)部微創(chuàng)新之星獎，相關(guān)詳細(xì)內(nèi)容也已發(fā)布到得物技術(shù)公眾號上：《Module Federation 在得物客服工單業(yè)務(wù)中的最佳實踐》。

3.4  推行單實例，提升性能

在開發(fā)工單工作臺工單詳情時，由于客服作業(yè)時經(jīng)常保留多個工單詳情tab，如果詳情使用多實例，那勢必會造成頁面dom節(jié)點數(shù)多，內(nèi)存占用高的情況，因此開發(fā)時就是設(shè)計成單實例的。

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

這個方案是在兩個互相關(guān)聯(lián)的應(yīng)用不是同一技術(shù)棧情況的下的過渡方案，隨著所有應(yīng)用都向React遷移，未來MF仍舊是主力方案。

3.5  動態(tài)渲染，降開發(fā)維護(hù)成本

簡單來說思路就是：過簡單的數(shù)據(jù)內(nèi)容的增減和修改，根據(jù)約定動態(tài)渲染，快速達(dá)成業(yè)務(wù)目標(biāo)。以替代工單創(chuàng)單，關(guān)單流程，訂單渲染等關(guān)鍵環(huán)節(jié)的各自問題。

3.5.1  創(chuàng)建工單的重構(gòu)

創(chuàng)建工單以往存在著這樣的問題：

• 不同工單類型對應(yīng)創(chuàng)單表單不一樣，模板渲染又十分復(fù)雜
• 多個應(yīng)用維護(hù)同樣業(yè)務(wù)代碼，代碼技術(shù)棧又不一致的情況，維護(hù)起來十分頭疼
• 在IM創(chuàng)單場景，由于客服切換IM會話頻次較快，又沒有涉及按會話ID維度的單獨表單內(nèi)存存儲空間，時常會發(fā)生表單信息丟失或錯亂的情況, 線上很多問題多是由于這樣的原因?qū)е碌摹?/li>

因此在設(shè)計新的架構(gòu)時，設(shè)計了兩個維度的數(shù)據(jù)隔離：第一維度是會話維度，第二維度是會話內(nèi)數(shù)據(jù)內(nèi)容和模板數(shù)據(jù)的隔離，以便提交表單時能立即將當(dāng)前表單數(shù)據(jù)內(nèi)容提交。

• 一份不同會話維度的數(shù)據(jù)表，該表會隨著客服與不同用戶的會話的新增結(jié)束而動態(tài)變化
• 客服切換會話時，根據(jù)對應(yīng)會話的數(shù)據(jù)，立即渲染出對應(yīng)的表單內(nèi)容
• 客服會高頻的切換不同的會話
• 將客服在當(dāng)前創(chuàng)建工單表單的修改內(nèi)容反應(yīng)至對應(yīng)的數(shù)據(jù)，這里的難點是：

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

假設(shè)這個過程中發(fā)生了客服切換會話，那有可能導(dǎo)致信息錯亂

解決手段是充分利用閉包緩存的特性，當(dāng)異步返回時設(shè)置對應(yīng)閉包下會話id的數(shù)據(jù)內(nèi)容

通過以上重構(gòu)的手段，再結(jié)合Module Federation統(tǒng)一不同應(yīng)用中的業(yè)務(wù)代碼，徹底解決了之前的問題。

相關(guān)流程圖：

3.5.2  關(guān)單流程的重構(gòu)

關(guān)單流程目前存在著數(shù)十個不同的流程類型，每種流程類型客服關(guān)單時的表單內(nèi)容和流程都是不一樣的，在以往都是按簡單的判斷邏輯堆砌流程，導(dǎo)致代碼十分冗長和復(fù)雜，在充分梳理不同流程類型的業(yè)務(wù)邏輯后，新的架構(gòu)設(shè)計方案如下：

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

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

3.5.3  訂單詳情的重構(gòu)

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

• 將變化較大的訂單基本信息及關(guān)聯(lián)信息通過統(tǒng)一schema維護(hù)
• 前后端約定schema的格式，后端將對應(yīng)數(shù)據(jù)通過該schema格式的數(shù)據(jù)返回
• 前端根據(jù)該格式渲染至頁面，簡單增減字段時前端無需開發(fā)，只需后端配置對應(yīng)字段值即可。

該方案是前后端共同推進(jìn)的，目前已上線，正在灰度中（2023年3月底），統(tǒng)計以往數(shù)據(jù)，訂單需求預(yù)計可節(jié)省66%的前端人力投入，在最近515的需求中已有部分需求無需在新的重構(gòu)版本中投入人力。

4、發(fā)布、值班機(jī)制的健全

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

4.1  發(fā)布機(jī)制

發(fā)布前會設(shè)置各項嚴(yán)格的卡口，都通過后才能發(fā)布，卡口如下

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

4.2  值班機(jī)制

在之前的值班機(jī)制上加強或增加這些環(huán)節(jié)：

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

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

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

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

5、階段性總結(jié)

5.1  線上TS問題歸零

在首先通過多項重構(gòu)優(yōu)化手段改進(jìn)當(dāng)前架構(gòu)后，架構(gòu)的文檔性，線上穩(wěn)定性在逐步提升，最顯著的表現(xiàn)就是線上TS問題反饋數(shù)在逐步的降低，至2023年Q1，線上歸因前端的TS問題數(shù)降至0個，如下所示：

5.2  滿意度穩(wěn)步提升

線上問題變少了，客服系統(tǒng)前端可用性變高了，架構(gòu)優(yōu)化了，速度性能提高了，也必定會助力二線客服的體驗和滿意度節(jié)節(jié)攀升，2023年Q1滿意度達(dá)到了80%，如下所示：

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

線上系統(tǒng)的穩(wěn)定性和客服滿意度這兩個指標(biāo)是系統(tǒng)健壯性，完善性的最終端指標(biāo)，這兩個數(shù)據(jù)可以說是這一系列工作的成果，能代表在工單域所做的事情是很有成效的。

6

類端能力的探索

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

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

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

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

6.1  流程閉環(huán)化

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

6.1.1  業(yè)務(wù)組件插件化

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

使用Mlodule Federation：鏈接不同項目間的插件，這一方式會隨著React技術(shù)棧的統(tǒng)一，應(yīng)用會越來越頻繁

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

6.1.2  路由跳轉(zhuǎn)規(guī)范化

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

6.1.3  便利工具內(nèi)建

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

6.2  資源緩存與接口數(shù)據(jù)持久化與管理

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

經(jīng)過SW緩存的接口，返回速度呈現(xiàn)了數(shù)量級的提升；

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

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

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

6.3  其他類端能力

接下來兩個優(yōu)化需要進(jìn)一步與產(chǎn)品探討和調(diào)研。

6.3.1  版本推送

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

6.3.2  獨立窗口

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