作者 ｜ Ling，攜程公共技術(shù)服務(wù)中心運營經(jīng)理，喜歡新技術(shù)，致力于提升研發(fā)效率與研發(fā)質(zhì)量。

攜程技術(shù)保障中心在2021年8月，把發(fā)布系統(tǒng)的技術(shù)支持團隊轉(zhuǎn)成了公共TS團隊(公共技術(shù)服務(wù)中心)，旨在持續(xù)提升TS的運營效率和服務(wù)質(zhì)量。慶幸自己帶著這支團隊經(jīng)歷了這次蛻變，借這篇文章和大家分享TS運營的經(jīng)驗和感悟，以及對TS運營的展望。

術(shù)語

一、全職TS產(chǎn)生的背景

為了使業(yè)務(wù)不斷從新技術(shù)中獲益，通用產(chǎn)研工具的更新與換代是個常態(tài)。這些工具一旦功能穩(wěn)定、性能良好就會上線，上線后往往存在“用戶不會用” 的現(xiàn)象。用戶就是上帝，“不完美”的工具如何讓攜程內(nèi)部用戶滿意呢?

有人說，把使用文檔寫完美了可彌補易用性的不足。話雖不錯，但現(xiàn)實是：

• 工具本身技術(shù)性強，但有不少無技術(shù)背景的用戶，文檔對此類用戶不友好。
• 功能使用缺少具體的步驟，用戶看了文檔還是不會操作。
• 功能點多、用法靈活，文檔很難覆蓋所有的用戶場景。
• 功能迭代快，文檔跟不上服務(wù)的迭代。
• 用戶忙，沒時間看文檔自己解決問題。

通過分析我們了解到：持續(xù)保持文檔易用性的困難;即使有很好的文檔仍然會有用戶不會去使用。

如果用戶少，來詢問的次數(shù)也不多，那么研發(fā)團隊自己處理用戶報障即可。一旦用戶達到成百上千，每天報障多達幾十次，那只好配備專職的TS ，以便研發(fā)人員專心搞研發(fā)了。

二、TS組織模式的演變

攜程研發(fā)團隊技術(shù)支持的組織模式，前后采用過模式一和模式二，目前正在探索模式三。

各模式的優(yōu)缺點和適合場景，分析如下：

三、采用模式三的收益

從2021年8月開始，攜程技術(shù)保障中心采用模式三創(chuàng)建了一支TS團隊。經(jīng)過八個月的努力，2022年4月我們可同時為九款通用產(chǎn)研工具提供技術(shù)支持，服務(wù)號整體自助率達到53% ，一線TS解決率達81% ，TS上崗培養(yǎng)周期縮短50% 。

團隊運營能力的提升，得益于先進的管理方法和高效的運營系統(tǒng)。本文分享的是我們這套運營系統(tǒng)。

四、TS運營系統(tǒng)的架構(gòu)

我們用語境圖來描述人與運營系統(tǒng)及運營系統(tǒng)中多個服務(wù)之間的關(guān)系。

接下來將和大家分享TS運營系統(tǒng)中最具特色的五個部分：

• 啟用AI智能對話的服務(wù)號，提升自助率。
• 推送wiki和五問，提升自助率。
• 啟用爬蟲工具，確保wiki的可用性。
• 降低打標簽的費力度，高效完成報障分類。
• 借助數(shù)據(jù)統(tǒng)計分析，建立一套有效的TS運營監(jiān)控體系。

4.1 啟用AI智能對話的服務(wù)號

新產(chǎn)品上線后的一段時期，用戶咨詢和報障相對多。為了讓用戶盡快上手新產(chǎn)品，研發(fā)人員往往沖在技術(shù)支持的第一線，此時群聊是個不錯的方式。

隨著產(chǎn)品的接受程度變高，群支持的弊端就出現(xiàn)了：同類問題反復(fù)出現(xiàn)，研發(fā)人員不得不重復(fù)回答老問題。這種毫無創(chuàng)造性的工作是時候請AI來幫忙了。步驟如下：

• 在攜程辦公即時通訊平臺TripPal上申請專用服務(wù)號——公共技術(shù)服務(wù)中心。
• 配置服務(wù)號啟用AI機器人。
• 整理用戶最需要的wiki錄入到AI客服機器人平臺。
• 用戶到服務(wù)號后先與AI機器人交流，機器人根據(jù)AI算法推送wiki給用戶。

我們的服務(wù)號采用了最適合TS場景的標準Q匹配的AI算法，已上線700多個wiki。2022年Q1經(jīng)過三輪訓(xùn)練，服務(wù)號TOP-4的準確率提升到79.5%，比訓(xùn)練前提升了34.7% 。

服務(wù)號中用戶和AI機器人交互：

服務(wù)號 wiki 自助效果如下表：

4.2 推送wiki和五問

當用戶使用通用產(chǎn)研工具遇到阻礙時，為了降低轉(zhuǎn)人工的報障量，我們結(jié)合用戶畫像(用戶在用哪個工具，用戶在哪里遇到問題，有什么報錯信息)，利用TS管家向用戶推送最適合的wiki 。目前推送模式有三種：

對于推送的wiki和五問，用戶的響應(yīng)有以下三種：

推送后轉(zhuǎn)人工

用戶收到推送的wiki后轉(zhuǎn)人工尋求幫助。這種代表用戶自助失敗。

推送后自助

用戶收到推送的wiki后和服務(wù)號繼續(xù)互動，沒有轉(zhuǎn)人工。這種代表用戶自助成功。

推送后無操作

用戶收到推動的wiki后，既沒有轉(zhuǎn)人工也沒有和服務(wù)號互動。這種代表用戶自助成功。

三種推送模式用戶的響應(yīng)情況如下。

主動推送wiki

一鍵報障推送wiki

一鍵報障推送五問

“一鍵報障推送五問”，用戶看到的是五個wiki的問題，這種方式需要用戶點擊某個問題后再彈出結(jié)果。而“主動推送wiki”和 “一鍵報障推送wiki” 這兩種方式，推送的是wiki完整的問題和解決方法，也就是在用戶使用遇阻的時候，服務(wù)號上已及時為用戶送上了解決問題的方法。從上面三幅圖中我們可以看到，這三種方式對自助率的提升都起到了一定的作用。

2022年1月中旬我們上線了wiki推送的功能，1月份自助率有了大幅提升。2022年2月初我們優(yōu)化了自動推送常用的30個wiki，2月份的自助率又有了一定的升高。如下圖所示：

發(fā)布系統(tǒng)是第一個對用戶日志進行分析和報告的產(chǎn)品，在接入的九款產(chǎn)品中，它從TS管家主動推送wiki的獲益也最大。從2021年后，發(fā)布系統(tǒng)整體相對成熟，日常報障量相對穩(wěn)定。2022年1月開始推送wiki后，1月、3月和4月人工處理的報障量同比降幅明顯。

4.3 啟用爬蟲工具

AI后臺wiki數(shù)量龐大，由于wiki篇幅有限，大部分wiki中會包含URL鏈接，引導(dǎo)用戶查看完整的操作內(nèi)容。在實際應(yīng)用場景中，wiki中的鏈接可能存在無法打開的情況，原因大致有以下三種：

• 鏈接的文檔被誤刪除
• AI后臺的wiki內(nèi)容被誤修改
• 鏈接文檔所在服務(wù)器宕機

另外也可能存在wiki鏈接能夠正常打開，但是鏈接內(nèi)容與wiki完全不匹配的情況。如果安排人員定期檢查不僅耗費大量人力，及時性也無法得到保證。

技術(shù)運營的研發(fā)團隊特意設(shè)計了爬蟲工具來幫我們保證wiki的可用性。該工具主要功能如下：

• 檢測wiki中包含的內(nèi)外網(wǎng)鏈接能否正常打開
• 檢查可正常打開鏈接的內(nèi)容與預(yù)先提供的文檔主題與關(guān)鍵詞是否匹配
• 郵件通知檢查的結(jié)果

爬蟲工具的架構(gòu)圖：

4.4 降低打標簽的費力度

打標簽是給每個用戶報障做好標記，用來識別以下屬性：

• 報障歸屬的產(chǎn)品
• 哪個模塊的報障
• 用戶使用問題，還是bug或需求

有了這些標簽，才能準確地掌握某個產(chǎn)品某個周期用戶報障的分布，才能有針對性優(yōu)化wiki，才能向研發(fā)團隊提供有效的反映產(chǎn)品質(zhì)量和用戶使用情況的情報，才能推動研發(fā)團隊優(yōu)先改進突出的問題。

一線TS每天處理多款產(chǎn)品的多個報障，如果打標簽的費力度高的話，很大程度上會影響TS的工作效率。為了最大可能地降低費力度，措施如下：

例如：有個報障來自Captain產(chǎn)品的用戶，產(chǎn)生報障是因為該用戶對某個基礎(chǔ)服務(wù)不熟悉。處理完報障后，TS在標簽的搜索欄只需輸入 “Captain 用戶“，系統(tǒng)就會返回所有與此匹配的標簽，無需識記所有基礎(chǔ)服務(wù)，就能很容易地找到標簽，快速完成分類。

在設(shè)計標簽的時候，還有一個創(chuàng)意也值得分享。像Captain這個產(chǎn)品，功能多模塊也多，如果標簽僅僅有 “Captain 模塊名稱“，模塊數(shù)量一多，查找和識記就會變困難，這個怎么解決呢?我們在Captain和模塊名中間增加了模塊歸屬團隊負責(zé)人的簡稱。

舉個例子，A團隊負責(zé)Paas和Captain兩個產(chǎn)品的多個服務(wù)：sonar服務(wù)，pipeline，基礎(chǔ)鏡像，該團隊的負責(zé)人縮寫為xxl ，那么，我們就可以增加下面6個標簽：

一旦遇到pipeline缺陷引起的報障，我們在標簽搜索欄輸入xxl就會返回A團隊負責(zé)的所有模塊。優(yōu)點就是：即使TS忘了模塊的確切名字，只要知道它歸xxl也一樣能快速找到這個標簽。如下圖所示：

為什么不打三個標簽?zāi)?第1個表示報障歸屬的產(chǎn)品：Captain，第2個表示負責(zé)團隊：xxl，第3個表示模塊：pipeline 。原因如下：

• 模塊和負責(zé)人對應(yīng)關(guān)系單一，不存在多對多的關(guān)系，所以，模塊和負責(zé)人無需拆分成兩個標簽。
• 產(chǎn)品的數(shù)量是有限的，就像Paas和Captain都有基礎(chǔ)鏡像，但也就只是這兩款產(chǎn)品有該模塊，所以，產(chǎn)品和模塊也就不拆分兩個標簽了。
• TS并行處理多個報障，須盡可能降低TS打標簽的費力度，打標簽的個數(shù)和費力度是成正比的，所以我們采用打一個標簽。

通過上述打標簽的方式，再借助攜程報表系統(tǒng)，我們一鍵就能得到產(chǎn)品報障分類的情報，如下圖：

4.5 建立TS運營監(jiān)控體系

前面多個章節(jié)的報表均來自這套TS運營監(jiān)控體系，本章對該體系再做個全面的介紹。

公共技術(shù)服務(wù)中心除了為各產(chǎn)品提供技術(shù)支持的工程師以外，設(shè)有專職的產(chǎn)品經(jīng)理和運營經(jīng)理。為了保證TS的高效運營，設(shè)置了以下目標類的監(jiān)控指標：

• 總自助率，各產(chǎn)品的自助率
• 總一線解決率，各產(chǎn)品一線解決率
• 各產(chǎn)品報障平均處理時長
• TS用戶滿意度

為了保證目標指標能順利達成，又新增了數(shù)據(jù)分析工具和過程指標：

• 各產(chǎn)品的PV和UV
• 各產(chǎn)品報障量
• 各產(chǎn)品報障分類
• 各產(chǎn)品wiki自助分析看板
• TS工程師個人監(jiān)控看板(含報障量，處理時長，轉(zhuǎn)二線數(shù)量)
• 各產(chǎn)品新用戶看板(待增加)
• 各產(chǎn)品自助率波動分析工具(待優(yōu)化，可考慮自動出分析報告)

目標類的監(jiān)控指標在前面幾章出現(xiàn)過，下面我們再展示部分數(shù)據(jù)分析工具和過程指標。

自助率波動分析看板(用來分析自助率變化的原因)：

wiki自助分析看板(用來分析哪些wiki能幫用戶自助)：

TS工程師個人工作看板(用來了解工程師的成長)：

五、TS運營體會

轉(zhuǎn)服務(wù)號后的八個月，攜程內(nèi)部已有九款通用產(chǎn)研工具接入。服務(wù)號為研發(fā)團隊節(jié)省了35%的研發(fā)人力投入，為用戶節(jié)省50%報障處理時長。作為負責(zé)TS運營的一線經(jīng)理，切身感受到團隊整體運營能力有了質(zhì)的提升。除了自助率的提升、轉(zhuǎn)人工報障量下降外，日常運營還出現(xiàn)了下面的變化：

• 大量優(yōu)質(zhì)的wiki，降低了技術(shù)支持的難度和費力度。
• TS從wiki中受益，積極參加wiki的建設(shè)已成為TS日常工作。
• TS從重復(fù)勞動中解決出來，接手更多產(chǎn)品的技術(shù)支持工作。
• 協(xié)同效應(yīng)開始出現(xiàn)，TS能幫用戶解決跨產(chǎn)品的問題。

六、TS運營的展望

公共TS的使命是：最大限度地發(fā)揮TS團隊的協(xié)同效應(yīng)，和研發(fā)一起努力，讓用戶喜歡使用公共技術(shù)的產(chǎn)品和服務(wù)。

回首公共TS八個月的運營，雖然取得很大的進步，但還有很多有意義的事亟待嘗試。

從被動接用戶報障改為主動提供培訓(xùn)。形式不限，可根據(jù)場景提供wiki、小故事或直播演示。

• 從被動引導(dǎo)用戶使用不好用的功能，改為主動向研發(fā)反饋帶有解決方案的改進建議。
• 嘗試努力幫助研發(fā)團隊，打造一款易用性非常好的、用戶非常滿意的產(chǎn)品。
• 改進運營工具，降低TS費力度，降低向研發(fā)反饋建議的費力度，降低數(shù)據(jù)分析的費力度，。
• 關(guān)注AI發(fā)展動態(tài)，降低TS和用戶學(xué)習(xí)新產(chǎn)品和新功能的費力度。