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

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

術語

一、全職TS產生的背景

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

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

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

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

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

二、TS組織模式的演變

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

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

三、采用模式三的收益

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

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

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

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

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

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

4.1 啟用AI智能對話的服務號

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

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

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

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

服務號中用戶和AI機器人交互：

服務號 wiki 自助效果如下表：

4.2 推送wiki和五問

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

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

推送后轉人工

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

推送后自助

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

推送后無操作

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

三種推送模式用戶的響應情況如下。

主動推送wiki

一鍵報障推送wiki

一鍵報障推送五問

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

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

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

4.3 啟用爬蟲工具

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

• 鏈接的文檔被誤刪除
• AI后臺的wiki內容被誤修改
• 鏈接文檔所在服務器宕機

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

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

• 檢測wiki中包含的內外網鏈接能否正常打開
• 檢查可正常打開鏈接的內容與預先提供的文檔主題與關鍵詞是否匹配
• 郵件通知檢查的結果

爬蟲工具的架構圖：

4.4 降低打標簽的費力度

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

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

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

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

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

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

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

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

為什么不打三個標簽呢?第1個表示報障歸屬的產品：Captain，第2個表示負責團隊：xxl，第3個表示模塊：pipeline 。原因如下：

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

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

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

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

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

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

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

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

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

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

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

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

五、TS運營體會

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

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

六、TS運營的展望

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

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

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

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