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

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

(資料圖)

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

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

1.2 核心鏈路

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

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

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

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

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

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

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

2、工單域前端問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	首屏	二次（非首屏）
iframe	7076ms	2594ms
模塊聯(lián)邦	1279ms	428ms

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

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

3.4 推行單實(shí)例，提升性能

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

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

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

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

簡(jiǎn)單來說思路就是：過簡(jiǎn)單的數(shù)據(jù)內(nèi)容的增減和修改，根據(jù)約定動(dòng)態(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)建工單以往存在著這樣的問題：

不同工單類型對(duì)應(yīng)創(chuàng)單表單不一樣，模板渲染又十分復(fù)雜多個(gè)應(yīng)用維護(hù)同樣業(yè)務(wù)代碼，代碼技術(shù)棧又不一致的情況，維護(hù)起來十分頭疼在IM創(chuàng)單場(chǎng)景，由于客服切換IM會(huì)話頻次較快，又沒有涉及按會(huì)話ID維度的單獨(dú)表單內(nèi)存存儲(chǔ)空間，時(shí)常會(huì)發(fā)生表單信息丟失或錯(cuò)亂的情況, 線上很多問題多是由于這樣的原因?qū)е碌摹?p>因此在設(shè)計(jì)新的架構(gòu)時(shí)，設(shè)計(jì)了兩個(gè)維度的數(shù)據(jù)隔離：第一維度是會(huì)話維度，第二維度是會(huì)話內(nèi)數(shù)據(jù)內(nèi)容和模板數(shù)據(jù)的隔離，以便提交表單時(shí)能立即將當(dāng)前表單數(shù)據(jù)內(nèi)容提交。

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

有時(shí)修改數(shù)據(jù)的交互是異步的，例如修改訂單號(hào)會(huì)異步查詢訂單信息并自動(dòng)填充

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

解決手段是充分利用閉包緩存的特性，當(dāng)異步返回時(shí)設(shè)置對(duì)應(yīng)閉包下會(huì)話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ù)十個(gè)不同的流程類型，每種流程類型客服關(guān)單時(shí)的表單內(nèi)容和流程都是不一樣的，在以往都是按簡(jiǎn)單的判斷邏輯堆砌流程，導(dǎo)致代碼十分冗長(zhǎng)和復(fù)雜，在充分梳理不同流程類型的業(yè)務(wù)邏輯后，新的架構(gòu)設(shè)計(jì)方案如下：

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

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

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

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

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

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

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

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

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

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

各環(huán)境驗(yàn)證，需求確認(rèn)，權(quán)限配置確認(rèn)每個(gè)需求都會(huì)列出前端修改點(diǎn)以及前端評(píng)估的影響面每個(gè)需求都需要兩位以上前端對(duì)功能進(jìn)行實(shí)際的驗(yàn)收每個(gè)需求都需要測(cè)試知曉修改點(diǎn)和影響面，并確認(rèn)4.2 值班機(jī)制

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

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

解答客服對(duì)新迭代功能的可能的疑惑

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

線上客服作業(yè)問題反饋，查看最近一個(gè)季度數(shù)據(jù)，基本做到了5分鐘響應(yīng)，10分鐘左右給到相應(yīng)解答，大多數(shù)在響應(yīng)的同時(shí)給到解答方案。5、階段性總結(jié)5.1 線上TS問題歸零

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

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

線上問題變少了，客服系統(tǒng)前端可用性變高了，架構(gòu)優(yōu)化了，速度性能提高了，也必定會(huì)助力二線客服的體驗(yàn)和滿意度節(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三個(gè)分?jǐn)?shù)為滿意。

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

6

類端能力的探索

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

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

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

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

6.1 流程閉環(huán)化

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

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

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

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

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

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

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

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

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

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

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

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

但該方案仍有一個(gè)重點(diǎn)問題需要解決：

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

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

6.3 其他類端能力

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

6.3.1 版本推送

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

6.3.2 獨(dú)立窗口

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

關(guān)鍵詞：