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

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

術(shù)語(yǔ)

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

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

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

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

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

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

二、TS組織模式的演變

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

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

三、采用模式三的收益

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

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

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

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

接下來(lái)將和大家分享TS運(yùn)營(yíng)系統(tǒng)中最具特色的五個(gè)部分：

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

4.1 啟用AI智能對(duì)話的服務(wù)號(hào)

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

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

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

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

服務(wù)號(hào)中用戶和AI機(jī)器人交互：

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

4.2 推送wiki和五問(wèn)

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

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

推送后轉(zhuǎn)人工

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

推送后自助

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

推送后無(wú)操作

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

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

主動(dòng)推送wiki

一鍵報(bào)障推送wiki

一鍵報(bào)障推送五問(wèn)

“一鍵報(bào)障推送五問(wèn)”，用戶看到的是五個(gè)wiki的問(wèn)題，這種方式需要用戶點(diǎn)擊某個(gè)問(wèn)題后再?gòu)棾鼋Y(jié)果。而“主動(dòng)推送wiki”和 “一鍵報(bào)障推送wiki” 這兩種方式，推送的是wiki完整的問(wèn)題和解決方法，也就是在用戶使用遇阻的時(shí)候，服務(wù)號(hào)上已及時(shí)為用戶送上了解決問(wèn)題的方法。從上面三幅圖中我們可以看到，這三種方式對(duì)自助率的提升都起到了一定的作用。

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

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

4.3 啟用爬蟲(chóng)工具

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

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

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

技術(shù)運(yùn)營(yíng)的研發(fā)團(tuán)隊(duì)特意設(shè)計(jì)了爬蟲(chóng)工具來(lái)幫我們保證wiki的可用性。該工具主要功能如下：

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

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

4.4 降低打標(biāo)簽的費(fèi)力度

打標(biāo)簽是給每個(gè)用戶報(bào)障做好標(biāo)記，用來(lái)識(shí)別以下屬性：

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

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

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

例如：有個(gè)報(bào)障來(lái)自Captain產(chǎn)品的用戶，產(chǎn)生報(bào)障是因?yàn)樵撚脩魧?duì)某個(gè)基礎(chǔ)服務(wù)不熟悉。處理完報(bào)障后，TS在標(biāo)簽的搜索欄只需輸入 “Captain 用戶“，系統(tǒng)就會(huì)返回所有與此匹配的標(biāo)簽，無(wú)需識(shí)記所有基礎(chǔ)服務(wù)，就能很容易地找到標(biāo)簽，快速完成分類。

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

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

一旦遇到pipeline缺陷引起的報(bào)障，我們?cè)跇?biāo)簽搜索欄輸入xxl就會(huì)返回A團(tuán)隊(duì)負(fù)責(zé)的所有模塊。優(yōu)點(diǎn)就是：即使TS忘了模塊的確切名字，只要知道它歸xxl也一樣能快速找到這個(gè)標(biāo)簽。如下圖所示：

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

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

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

4.5 建立TS運(yùn)營(yíng)監(jiān)控體系

前面多個(gè)章節(jié)的報(bào)表均來(lái)自這套TS運(yùn)營(yíng)監(jiān)控體系，本章對(duì)該體系再做個(gè)全面的介紹。

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

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

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

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

目標(biāo)類的監(jiān)控指標(biāo)在前面幾章出現(xiàn)過(guò)，下面我們?cè)僬故静糠謹(jǐn)?shù)據(jù)分析工具和過(guò)程指標(biāo)。

自助率波動(dòng)分析看板(用來(lái)分析自助率變化的原因)：

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

TS工程師個(gè)人工作看板(用來(lái)了解工程師的成長(zhǎng))：

五、TS運(yùn)營(yíng)體會(huì)

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

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

六、TS運(yùn)營(yíng)的展望

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

回首公共TS八個(gè)月的運(yùn)營(yíng)，雖然取得很大的進(jìn)步，但還有很多有意義的事亟待嘗試。

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

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