作者|携程公共技术服务中心运营经理凌，喜欢新技术，致力于提升研发效率和质量。2021年8月，携程技术支持中心将发布系统的技术支持团队转为公共TS团队（PublicTechnicalServiceCenter），旨在不断提升TS的运行效率和服务质量。我很高兴带领这个团队完成了这次转型。我想通过这篇文章与大家分享TS运营的经验和感悟，以及对TS运营的展望。术语1.专职TS的背景为了使业务持续受益于新技术，一般产研工具的更新换代是常态。这些工具一旦功能稳定、性能良好就会上线，上线后往往会出现“用户不会用”的现象。用户就是上帝，一个“不完美”的工具怎么能让携程内部用户满意？有人说完善的文档可以弥补易用性的不足。话虽好，但现实是：工具本身技术性很强，但没有技术背景的用户很多，文档对这类用户并不友好。功能使用缺乏具体步骤，用户阅读文档后仍无法操作。功能众多，使用灵活，文档很难覆盖所有的用户场景。功能迭代快，文档跟不上服务迭代。用户很忙，没有时间自己阅读文档和解决问题。通过分析我们了解到：维护文档易用性的难度；即使有一个好的文档，仍然会有用户不会使用它。如果用户少，问询不多，那么研发团队可以自己处理用户反馈。一旦用户量达到数百或数千，每天有几十个故障报告，就需要配备一个专职的TS，让研发人员可以集中精力进行研发。2.TS组织模式的演进携程研发团队技术支持的组织模式前后采用了模式1和模式2，目前正在探索模式3。各模式的优缺点及适用场景如下：分析如下：三、采用模式三的好处2021年8月起，携程技术支持中心采用模式三创建TS团队。经过八个月的努力，到2022年4月，我们将能够同时为9款通用产学研工具提供技术支持。服务号整体自助率达到53%，一线TS解决率达到81%，TS上岗培训周期缩短50%。团队运营能力的提升得益于先进的管理方式和高效的运营体系。本文分享我们的操作系统。4.TS操作系统的架构我们使用上下文映射来描述人与操作系统之间的关系以及操作系统中的多个服务。下面给大家分享一下TS运营体系中最具特色的五个部分：开启AI智能对话，提升自助率的服务号。推送维基和五问，提高自助率。开启爬虫工具，保证wiki的可用性。减少标注工作量，高效完成故障报告分类。借助数据的统计分析，建立有效的TS运行监控系统。4.1AI智能对话服务号新品上线后的一段时间内，用户咨询和反映较多。为了让用户尽快上手新产品，研发人员经常冲在技术支持的第一线，此时群聊是一个很好的方式。随着产品的接受度越来越高，群支持的弊端就出现了：类似的问题反复出现，研发人员不得不反复回答老问题。这种没有创意的工作是时候请AI帮忙了。具体步骤如下：在携程办公即时通讯平台TripPal上申请专属服务账号——公共技术服务中心。配置服务帐户以启用AI机器人。整理用户最需要的wiki，录入AI客服机器人平台。用户到达服务号后，首先与AI机器人进行通信，机器人根据AI算法将wiki推送给用户。我们的服务号采用最适合TS场景的标准Q-matchingAI算法，已上线700多个wiki。经过2022年Q1的三轮训练，服务号TOP-4的准确率已经提升到79.5%，比训练前提升了34.7%。在服务号中，用户与AI机器人交互：服务号wiki的自助效果如下：4.2推送wiki和五个问题当用户在使用通用产研工具时遇到障碍，为了减少转人工障碍的报告数量，我们结合用户画像（用户正在使用哪个工具，用户在什么地方遇到问题，有什么错误信息），使用TSManager推送最合适的wiki到用户。目前有三种推送方式：对于推送的wiki和五个问题，用户的反应有以下三种：推送后，用户收到推送的wiki后会转为人工求助。这代表用户自助失败。推送后，自助用户在收到推送的wiki后继续与服务账号进行交互，无需切换到手动。这代表用户自助成功。推送后无操作用户收到推送的wiki后，既没有转手册，也没有与服务号进行交互。这代表用户自助成功。三种推送模式下用户的反应如下。主动推送wiki一键报错推送wiki一键报错推送五题“一键报错推送五题”，用户看到wiki的五题，这种方式需要用户点击一个问题，然后弹出结果.“主动推送wiki”和“一键错误推送wiki”两种方式，推送wiki完整的问题和解决方案，即用户在使用wiki遇到障碍时，服务号已将其发送至用户及时。解决问题的方法。从以上三个数字可以看出，这三种方式对于提高自救率起到了一定的作用。2022年1月中旬，我们上线wiki推送功能，1月自助率大幅提升。2022年2月初，我们优化了30个常用wiki的自动推送，2月份的自助率有了一定的提升。如下图所示：发布系统是第一个分析上报用户日志的产品。在接入的九款产品中，受益最大的还是TSManager主动推送wiki。2021年以后，发布体系整体比较成熟，日报量比较稳定。2022年1月wiki开始推送后，1月、3月、4月人工处理的故障报告数量同比明显下降。4.3开启爬虫工具AI后台wiki数量庞大。由于wiki空间有限，大部分wiki都会包含URL链接，引导用户查看完整的操作内容。在实际应用场景中，wiki中的链接可能打不开。大致有以下三种原因：链接文档被误删除。AI后台wiki内容被误修改。链接文档所在的服务器宕机了。也可能有wiki链接。可以正常打开，但是链接内容与wiki完全不符。如果安排人员定期检查，不仅会消耗大量人力，而且时效性也得不到保证。技术运营研发团队专门设计了一款爬虫工具来帮助我们保证wiki的可用性。该工具的主要功能如下：检查wiki中包含的内部和外部链接是否可以正常打开检查可以正常打开的链接内容是否与预先提供的文档主题和关键字匹配标注的力度标注是对每个用户的故障报告进行标记，以标识以下属性：故障属于产品的哪个模块，用户对故障的问题，或bug或需求。有了这些标签，我们就可以准确掌握产品在一定时期内用户报告的分布情况，可以有针对性地优化wiki，为研发团队提供反映产品质量和用户使用情况的有效信息，促进研发团队优先改进突出问题。一线TS每天处理各种产品的多起故障报告。如果标注工作量大，会极大地影响TS的工作效率。为了尽可能减少工作量，采取的措施如下：例如，某船长产品用户报错，由于用户对某项基础服务不熟悉而报错。TS处理完报错后，只需在标签搜索栏中输入“Captainuser”，系统就会返回所有匹配的标签。您可以轻松找到标签并快速完成分类，而无需记住所有基本服务。在设计标签时，还有一个想法值得分享。像船长这样的产品，功能多，模块多。如果标签只有“船长模块名称”，模块的数量将变得更难查找和记忆。如何解决这个问题呢？我们在Captain和模块名称之间添加了模块归属组长的简称。比如A团队负责两个产品PaaS和Captain的多个服务：sonar服务、pipeline、基础镜像。这个团队的负责人简称xxl。然后，我们可以添加以下6个标签：一旦遇到pipeline要报告由缺陷引起的错误，我们在标签搜索栏中输入xxl，它将返回团队A负责的所有模块。好处是：即使TS忘记了模块的确切名称，只要知道它属于xxl，就可以很快找到这个标签。如下图所示：为什么不使用三个标签呢？第一个表示报错产品：Captain，第二个表示责任团队：xxl，第三个表示模块：pipeline。原因如下：模块和负责人的对应关系是单一的，没有多对多的关系。因此，模块和负责人不需要拆分成两个标签。产品数量有限，就像Paas和Captain都有基础镜像，但是只有这两个产品有这个模块，所以不会把产品和模块拆分成两个标签。TS并行处理多个故障报告，需要尽可能减少TS标注的工作量。标签的数量与工作量成正比，所以我们使用一个标签。通过上述标注方式，借助携程报表系统，我们可以一键获取产品故障报表分类信息，如下图：4.5建立TS运行监控系统报表前面的章节都是出自这个TS运行监控系统。本章对系统进行了全面的介绍。除了为每个产品提供技术支持的工程师外，公共技术服务中心还有专职的产品经理和运营经理。为保证TS的高效运行，设置了以下目标品类的监控指标：总自助率、各产品自助率、总一线解决率、各产品一线解决率，每个产品故障报告的平均处理时间，以及TS用户满意度，以确保目标指标能够顺利达成，新增数据分析工具和流程指标：每个产品的PV和UV，故障报告量每个产品，每个产品的故障报告分类，每个产品的wiki自助分析看板，TS工程师个人监控板（包括故障报告量和处理时间），二线数量调）各产品新用户看板（待添加）各产品自助费率波动分析工具（待优化，可考虑自动分析报表）目标类别的指示器在前面的章节中已经出现，我们将在下面展示一些数据分析工具和流程指标。自助率波动分析板（用于分析自助率变化的原因）：wiki自助分析板（用于分析哪些wiki可以帮助用户自助）：TS工程师个人工作板（用于了解工程师成长）：5.TS运营服务号转入后的八个月时间里，九款通用产研工具接入了携程。服务号为研发团队节省了35%的研发人力投入，为用户节省了50%的排错时间。作为负责TS运营的一线管理者，个人感觉团队的整体运营能力有了质的提升。除了自助率的提高和人工报告数量的减少，日常运营中还发生了以下变化：大量优质维基减少了技术支持的难度和工作量。TS受益于wiki，积极参与wiki的建设已经成为TS的日常工作。TS解决重复劳动问题，承担更多产品的技术支持工作。协同效应开始显现，TS可以帮助用户解决跨产品问题。6.TS运营展望公共TS的使命是最大化TS团队的协同效应，与R&D共同努力，让用户喜欢使用公共技术的产品和服务。回顾PublicTS的八个月运营，虽然进步很大，但还有很多有意义的事情可以去尝试。从被动接受用户报告到主动提供培训。形式不限，可根据现场情况提供维基、短篇或现场演示。从被动引导用户使用不好用的功能，到主动向研发反馈改进建议和解决方案。尽量帮助研发团队打造一款非常好用、用户非常满意的产品。改进运营工具，减少TS的工作量，减少给研发反馈建议的工作量，减少数据分析的工作量。关注AI的发展，减少TS和用户学习新产品和功能的努力。
