为什么线上问题需要分类，如何分类？

见贤思齐

前文中我们提到过“线上问题分类”这个这字段，也收到读者来信咨询：线上问题分类中的有效咨询、无效咨询、技术 BUG 、产品 BUG 这几项具体是怎么定义的，今天小编就来具体介绍下，线上问题分类在有赞的具体实践。一、为什么要有线上问题分类？在技术支持团队开始接手处理线上问题以来，就已经通过工单的形式把问题数据存储下来了，面对这些原始的数据，怎么更利于看到承接的情况和质量，怎么体现出这些数据的价值，是一个非常重要且急需解决的问题。那么怎么才能实现预期的目的呢？回答这个问题之前，我们思考过以下几个问题：所有问题都需要一个一个分析吗？哪些问题需要分析，哪些问题不需要分析？哪些问题应该由协作方分析？哪些问题需要技术支持重点分析？显然，不是所有问题都重要，我们需要在有限的时间内，抓住重点问题做详细分析，那么问题来了？这么多问题，哪些才是重点？有没有什么快捷方法帮助快速识别？基于这些思考，我们提出了将线上问题归类的想法，跟上下游约定分类标准、制作监控面板。最终在分析问题时，利用线上问题分类字段筛选异常、重点数据，重点分析，效率大大提升。二、线上问题分类的类别众所周知，线上问题，要么是 BUG，要么是非 BUG，如何利用好这两个分类，是一门很深的学问。通过日常对问题的处理，我们发现，BUG 类问题中主要是技术 BUG ，但是其中也有不少是由于产品设计导致的，我们称为产品 BUG ；非 BUG 类中，也不是所有的问题都有效，例如 提交上来的问题只有一个，其他什么信息都没有，无法排查，属于无效问题，所以，非 BUG 类中，我们又将其分为有效咨询和无效咨询。由此，大类就确认了：有效咨询、无效咨询、技术 BUG、产品 BUG，这里暂时定义为一级分类。大类确定了，但是对问题分析的帮助还是效果甚微，于是，通过分析近 1000 个历史线上问题，我们将每一个大类再次细分，称其为二级分类；梳理完成后，跟研发测试、产品、服务一起讨论，并最终确定分类标准，以便在后续同步数据时和讨论解决方案时，大家的认知标准是一致的。技术 BUG 主要由测试进行分析，此处我们重点介绍下有效咨询、无效咨询的分类标准：有效咨询定义：问题描述清楚、知识库无法查询到、也没有可读性强的直观工具可以让提交人自查，或产品功能、产品体验上需要优化，提交人无法自行解决的需要提交工单的问题，认为是有效问题具体分类和场景说明如下：二级分类场景说明知识传播（文档沉淀、知识同步帮助理解）可以通过知识沉淀和传播来减少的这一类咨询工具需求（工具支持提升解决效率）可以通过完善工具，使报告人能够自行查询解决来减少的这一类咨询商家需求商家提出的场景目前功能无法支持，但需求又是合理的这类问题产品改进（通过优化提升用户体验）可以通过产品改进，提升用户体验来减少的这一类咨询流程优化（上下游优化流程提升解决效率）可以通过流程优化来减少，或者提升解决效率的这一类咨询三方系统（和第三方系统相关）与三方系统有关，非有赞逻辑的一类咨询无法复现 ?(问题曾经出现过, 后续无法复现)可以证明问题存在过，但当前用户侧已正常，且无法再复现和进一步定位的问题无效咨询定义：描述不清无法排查、同个问题重复提交、可通过帮助中心、知识库、工具自查等提交人可以自己解决，不需要提交工单的问题，认为是无效问题具体分类和场景说明如下：二级分类场景说明描述不清（缺少信息或者描述不清）因缺少必要信息，无法提供回复的一类问题重复提交同店铺且同问题，已有一个完全相同的提交（同店铺不同问题、同问题不同店铺，都不包含在内）帮助中心有FAQ在帮助中心已经有答案，可以直接回复，不需要提交线上问题确认的一类问题简单使用工具解决内部已有工具供查询，可以简单使用后直接回复，不需要提交线上问题确认的一类问题产品有过培训或公告已有文档产品已进行过宣导的相关内容咨询非线上问题不在线上问题对接流程内，不提交线上处理的一类问题报告人或商家自行解决虽然提交了线上问题，但提交后反馈报告人或商家已自行解决，无需再排查的这类问题页面已有文案提示产品功能页面上已经给到了明显的提示，可通过理解提示信息内容直接解决的问题报告人未核实准确信息因报告人没有核实准确信息而误认为需要提交线上问题来解决的问题报告人业务强化（基础业务知识或者可自行测试解决）基础业务知识，无需多加说明，只需要经过实操就能确认并解决的问题以上，是我们针对线上问题，做的具体分类，这些分类在我们对线上问题进行分析和提供解决方案时，提供了很大的便利。三、线上问题分类最佳实践有了线上问题分类后，我们在解决问题时，将这个字段设置为必填字段，并利用这个字段，搭建监控面板，将日常数据监控起来，定期输出线上问题数据报表，反馈相关业务方，并制定降量策略、推动产品优化及工具建设。下面，小编将针对其中比较典型的几种做具体介绍。无效问题针对无效问题，需要的是降量，提升问题在一线的解决时效和闭环率，进而提升商家的服务体验。先跟上游部门约定一个无效问题占比基线，在这个基线内的无效问题量，是技术支持可接受的范围，如果超过了这个基线，那么就会将问题反馈给上游部门，再由上游部门做具体分析，并一起讨论具体降量措施；过程中也会推动上游部门将降低无效问题占比的目标写进 OKR 里面，避免目标不一致导致大家不在同一个维度上讨论问题。针对描述不清/信息提供不全的问题：根据提交人习惯，整理并输出跟产品导航相对应的四级菜单，针对每个菜单配置需要提供的信息；推动提交工单入口做页面改造，提交人在提交工单时，只需要选择问题发生的页面，选择后，问题描述框会自动提示排查此问题需要提供的信息，提交人按照提示填写即可。针对非线上问题：整理输出线上问题范围，对非线上问题范围内的问题，针对性输出路由方案，引导提交人到正确的地方解决问题，例如 数据导出问题，引导提交人走专门的工单处理有效咨询有效咨询是技术支持需要重点分析的问题分类之一，并需要针对具体问题输出解决方案，以达到降量的目的。针对工具需求类问题：定期整理高频查询，将可以通过数据库、接口、日志查询的问题，利用前文提到的 Rundeck 统一转换到可读性更强的内部工具上，让服务小伙伴可以直接查询出需要的信息针对产品改进类问题：结合业务归属字段，定期输出各业务线上问题报告，例如 周报/月报，将高频问题反馈给对应产品经理，推动产品优化四、写在最后在降量、提升产品优化和商家体验上，针对不同分类的问题有不同分析方法及解决方案，由于篇幅有限，不做过多赘述，只在上述做了简单介绍，如果读者朋友们有更多想要探讨的内容，可私信公众号，做更多探讨。