干货 | 携程公共技术支持运营实践

作者简介

Ling，携程公共技术服务中心运营经理，喜欢新技术，致力于提升研发效率与研发质量。

携程技术保障中心在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 用户“，系统就会返回所有与此匹配的标签，无需识记所有基础服务，就能很容易地找到标签，快速完成分类。