携程技术保障中心在2021年8月，把发布系统的技术支持团队转成了公共TS团队（公共技术服务中心），旨在持续提升TS的运营效率和服务质量。庆幸自己带着这支团队经历了这次蜕变，借这篇文章和大家分享TS运营的经验和感悟，以及对TS运营的展望。

术语

通用产研工具	研发团队向公司内部推出的产品或服务，如携程的发布系统。
一键报障	通用产研工具在其页面上提供的按钮，引导用户到服务号自助或转技术支持。
服务号	本文专指TripPal里面的公共技术服务号，集成了AI机器人。
IM+	携程的客户在线服务系统，初是携程客户与携程客服之间的在线沟通工具，目前被TS团队采用作为和内部用户沟通的工具。
TS	技术支持的简称，用来指代技术支持的工作，或指代技术支持工程师。
TS管家	公共TS的管理平台。

一、全职TS产生的背景

    

为了使业务不断从新技术中获益，通用产研工具的更新与换代是个常态。这些工具一旦功能稳定、性能良好就会上线，上线后往往存在“用户不会用” 的现象。用户就是上帝，“不完美”的工具如何让携程内部用户满意呢？

 

有人说，把使用文档写完美了可弥补易用性的不足。话虽不错，但现实是：

• 工具本身技术性强，但有不少无技术背景的用户，文档对此类用户不友好。
• 功能使用缺少具体的步骤，用户看了文档还是不会操作。
• 功能点多、用法灵活，文档很难覆盖所有的用户场景。
• 功能迭代快，文档跟不上服务的迭代。
• 用户忙，没时间看文档自己解决问题。

 

通过分析我们了解到：持续保持文档易用性的困难；即使有很好的文档仍然会有用户不会去使用。

如果用户少，来询问的次数也不多，那么研发团队自己处理用户报障即可。一旦用户达到成百上千，每天报障多达几十次，那只好配备专职的TS ，以便研发人员专心搞研发了。

二、TS组织模式的演变

    

携程研发团队技术支持的组织模式，前后采用过模式一和模式二，目前正在探索模式三。

各模式的优缺点和适合场景，分析如下：

三、采用模式三的收益

       

从2021年8月开始，携程技术保障中心采用模式三创建了一支TS团队。经过八个月的努力，2022年4月我们可同时为九款通用产研工具提供技术支持，服务号整体自助率达到53% ，一线TS解决率达81% ，TS上岗培养周期缩短50% 。

 

团队运营能力的提升，得益于先进的管理方法和高效的运营系统。本文分享的是我们这套运营系统。

四、TS运营系统的架构

     

我们用语境图来描述人与运营系统及运营系统中多个服务之间的关系。

   

接下来将和大家分享TS运营系统中具特色的五个部分：

• 启用AI智能对话的服务号，提升自助率。
• 推送wiki和五问，提升自助率。
• 启用爬虫工具，确保wiki的可用性。
• 降低打标签的费力度，高效完成报障分类。
• 借助数据统计分析，建立一套有效的TS运营监控体系。

4.1 启用AI智能对话的服务号

新产品上线后的一段时期，用户咨询和报障相对多。为了让用户尽快上手新产品，研发人员往往冲在技术支持的线，此时群聊是个不错的方式。

   

随着产品的接受程度变高，群支持的弊端就出现了：同类问题反复出现，研发人员不得不重复回答老问题。这种毫无创造性的工作是时候请AI来帮忙了。步骤如下：

• 在携程办公即时通讯平台TripPal上申请专用服务号——公共技术服务中心。
• 配置服务号启用AI机器人。
• 整理用户需要的wiki录入到AI客服机器人平台。
• 用户到服务号后先与AI机器人交流，机器人根据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后和服务号继续互动，没有转人工。这种代表用户自助成功。

• 推送后无操作

用户收到推动的wiki后，既没有转人工也没有和服务号互动。这种代表用户自助成功。

    

三种推送模式用户的响应情况如下。

• 主动推送wiki

 

• 一键报障推送wiki

 

• 一键报障推送五问

 

“一键报障推送五问”，用户看到的是五个wiki的问题，这种方式需要用户点击某个问题后再弹出结果。而“主动推送wiki”和 “一键报障推送wiki” 这两种方式，推送的是wiki完整的问题和解决方法，也就是在用户使用遇阻的时候，服务号上已及时为用户送上了解决问题的方法。从上面三幅图中我们可以看到，这三种方式对自助率的提升都起到了一定的作用。

 

2022年1月中旬我们上线了wiki推送的功能，1月份自助率有了大幅提升。2022年2月初我们优化了自动推送常用的30个wiki，2月份的自助率又有了一定的升高。如下图所示：

 

发布系统是个对用户日志进行分析和报告的产品，在接入的九款产品中，它从TS管家主动推送wiki的获益也大。从2021年后，发布系统整体相对成熟，日常报障量相对稳定。2022年1月开始推送wiki后，1月、3月和4月人工处理的报障量同比降幅明显。

4.3 启用爬虫工具

   

AI后台wiki数量庞大，由于wiki篇幅有限，大部分wiki中会包含URL链接，引导用户查看完整的操作内容。在实际应用场景中，wiki中的链接可能存在无法打开的情况，原因大致有以下三种：

• 链接的文档被误删除
• AI后台的wiki内容被误修改
• 链接文档所在服务器宕机
  
  

另外也可能存在wiki链接能够正常打开，但是链接内容与wiki完全不匹配的情况。如果安排人员定期检查不仅耗费大量人力，及时性也无法得到保证。

 

技术运营的研发团队特意设计了爬虫工具来帮我们保证wiki的可用性。该工具主要功能如下：

• 检测wiki中包含的内外网链接能否正常打开
• 检查可正常打开链接的内容与预先提供的文档主题与关键词是否匹配
• 邮件通知检查的结果

 

爬虫工具的架构图：

4.4 降低打标签的费力度

打标签是给每个用户报障做好标记，用来识别以下属性：

• 报障归属的产品
• 哪个模块的报障
• 用户使用问题，还是bug或需求

 

有了这些标签，才能准确地掌握某个产品某个周期用户报障的分布，才能有针对性优化wiki，才能向研发团队提供有效的反映产品质量和用户使用情况的情报，才能推动研发团队优先改进突出的问题。

 

一线TS每天处理多款产品的多个报障，如果打标签的费力度高的话，很大程度上会影响TS的工作效率。为了大可能地降低费力度，措施如下：

 

诉求	措施
打标签及时、便捷	在IM+客户端开发打标签的功能
识记标签容易	标签搜索提供关键词匹配功能
打少的标签	一个标签带多个属性，属性之前用空格分开

 

例如：有个报障来自Captain产品的用户，产生报障是因为该用户对某个基础服务不熟悉。处理完报障后，TS在标签的搜索栏只需输入 “Captain 用户“，系统就会返回所有与此匹配的标签，无需识记所有基础服务，就能很容易地找到标签，快速完成分类。

 

在设计标签的时候，还有一个创意也值得分享。像Captain这个产品，功能多模块也多，如果标签仅仅有 “Captain 模块名称“，模块数量一多，查找和识记就会变困难，这个怎么解决呢？我们在Captain和模块名中间增加了模块归属团队负责人的简称。

 

举个例子，A团队负责Paas和Captain两个产品的多个服务：sonar服务，pipeline，基础镜像，该团队的负责人缩写为xxl ，那么，我们就可以增加下面6个标签：

一旦遇到pipeline缺陷引起的报障，我们在标签搜索栏输入xxl就会返回A团队负责的所有模块。优点就是：即使TS忘了模块的确切名字，只要知道它归xxl也一样能快速找到这个标签。如下图所示：

为什么不打三个标签呢？第1个表示报障归属的产品：Captain，第2个表示负责团队：xxl，第3个表示模块：pipeline 。原因如下：

• 模块和负责人对应关系单一，不存在多对多的关系，所以，模块和负责人无需拆分成两个标签。

• 产品的数量是有限的，就像Paas和Captain都有基础镜像，但也就只是这两款产品有该模块，所以，产品和模块也就不拆分两个标签了。

• TS并行处理多个报障，须尽可能降低TS打标签的费力度，打标签的个数和费力度是成正比的，所以我们采用打一个标签。

通过上述打标签的方式，再借助携程报表系统，我们一键就能得到产品报障分类的情报，如下图：

4.5 建立TS运营监控体系

前面多个章节的报表均来自这套TS运营监控体系，本章对该体系再做个全面的介绍。

 

公共技术服务中心除了为各产品提供技术支持的工程师以外，设有专职的产品经理和运营经理。为了保证TS的高效运营，设置了以下目标类的监控指标：

• 总自助率，各产品的自助率
• 总一线解决率，各产品一线解决率
• 各产品报障平均处理时长
• TS用户满意度

 

为了保证目标指标能顺利达成，又新增了数据分析工具和过程指标：

• 各产品的PV和UV
• 各产品报障量
• 各产品报障分类
• 各产品wiki自助分析看板
• TS工程师个人监控看板（含报障量，处理时长，转二线数量）
• 各产品新用户看板（待增加）
• 各产品自助率波动分析工具（待优化，可考虑自动出分析报告）

 

目标类的监控指标在前面几章出现过，下面我们再展示部分数据分析工具和过程指标。

 

自助率波动分析看板（用来分析自助率变化的原因）：

wiki自助分析看板（用来分析哪些wiki能帮用户自助）：

TS工程师个人工作看板（用来了解工程师的成长）：

五、TS运营体会

转服务号后的八个月，携程内部已有九款通用产研工具接入。服务号为研发团队节省了35%的研发人力投入，为用户节省50%报障处理时长。作为负责TS运营的一线经理，切身感受到团队整体运营能力有了质的提升。除了自助率的提升、转人工报障量下降外，日常运营还出现了下面的变化：

• 大量优质的wiki，降低了技术支持的难度和费力度。
• TS从wiki中受益，积极参加wiki的建设已成为TS日常工作。
• TS从重复劳动中解决出来，接手更多产品的技术支持工作。
• 协同效应开始出现，TS能帮用户解决跨产品的问题。

六、TS运营的展望

公共TS的使命是：大限度地发挥TS团队的协同效应，和研发一起努力，让用户喜欢使用公共技术的产品和服务。

 

回首公共TS八个月的运营，虽然取得很大的进步，但还有很多有意义的事亟待尝试。

• 从被动接用户报障改为主动提供培训。形式不限，可根据场景提供wiki、小故事或直播演示。

• 从被动引导用户使用不好用的功能，改为主动向研发反馈带有解决方案的改进建议。

• 尝试努力帮助研发团队，打造一款易用性非常好的、用户非常满意的产品。

• 改进运营工具，降低TS费力度，降低向研发反馈建议的费力度，降低数据分析的费力度。

• 关注AI发展动态，降低TS和用户学习新产品和新功能的费力度。