技术支持日常工作中，非常依赖工具来定位、排查问题，一款高效易用的工具决定了技术支持工作的效率。由技术支持主导的线上问题运营平台项目在最近一次的产品研发霸王龙评比中获得了：卓有成效奖，本文就介绍一下线上问题运营平台的诞生过程。

现状和痛点

有赞也是微服务架构，线上应用非常多，有赞技术支持是按照不同的业务域来划分的，不同业务域权限申请非常麻烦。业务间的关联也非常多，表面看上是交易的问题，实际上可能是调用营销导致的异常。交易的技术支持想查营销的问题，就需要先去申请营销的应用权限，等待审批通过之后，问题才能继续推进，非常耗时。

在有赞我们主要依赖几个途径来查询信息，有赞数据库，有赞日志系统：天网，数据平台：DP，有赞各个业务自己开发的工具，比如交易工作台，支付运营平台等等，类似的工具平台有好几十个，质量良莠不齐，一个问题往往要查询多个工具平台，非常麻烦。

而且，各个业务方工具往往更新维护也很慢，内部工具类的需求优先级远比不上业务和商家需求优先级，导致很多工具更新滞后，无法为排查提供正确的信息。

此外，线上问题查询需求大多来自客服，很多问题排查技术含量并不大，但因为权限限制，客服无法直接使用数据库查询，且学习 SQL 也有一定的门槛，导致同类问题反复咨询，从商家提问到客服提交 JIRA，再到技术支持，流转环节多，耗时长，商家满意度低。

为了解决以上问题，我们了解了到国外的开源工具：Rundeck，尝试通过 Rundeck 将一些常规 SQL 查询类的工作界面化。

Rundeck 的出现

为了将 SQL 查询界面化，我们搭建了 Rundeck 平台，跟线上的只读库打通。结合 Rundeck 的一款 SQL 转换插件，我们可以非常方便的使用 Groovy 的脚本将线上的 SQL 查询转换成 Rundeck 界面。这里以查询确认收货操作人为例，看 SQL 如何转换成界面化查询工具，一起来看下 2 条 SQL 的界面化之旅。

第一条 SQL 通过订单号，查询到该操作人的用户 ID，第二条 SQL 通过用户 ID 查询到操作人对应的手机号，通过手机号，商家可以非常直观定位到具体操作人。

通过 Groovy 脚本，将 SQL 中的订单号作为入参，将 SQL 查询返回的信息中的关键字段打印出来。

Rundeck 完成之后的界面查询如下，在 order_no 输入要查询的订单号，点击运行，即可查询。

这个方案可以非常容易地将 SQL 查询转换成上述界面化的工作，从此涉及到数据库查询类问题都可以被界面化，这套方案帮助技术支持节省了大量申请权限，写 SQL 查询的操作的时间，大大提升了解决问题的效率。

我们把这个工具推荐给了客服的小伙伴，希望能够赋能客服，提升解决数据库查询类的问题效率。但发现效果不太好，Rundeck 是国外的开源软件，英文界面，对于中文支持不好，即使已经界面化也需要一些理解成本。字段很多的时候，Rundeck 无法表格打印输出，定位所需字段困难。

为了彻底改善体验，让工具发挥更大的作用，我们决定在 Rundeck 基础上再封装一层，提供更加友好的查询体验，线上问题运营平台应运而生。

线上问题运营平台介绍

线上问题运营平台首页如下，为了方便查询，左侧设计成了跟商家后台一致的菜单，方便根据功能模块查询排查方法，右侧常见功能是根据查询次数的排序，经常用到的查询方法，直接展示在首页。

线上问题运营平台通过 API 接口，拉取 Rundeck 上的 job （job 代表 Rundeck 上的一个查询功能，例如查询确认收货操作人这个功能对应 1 个 job， 有对应的 job_id），将返回的字段配置化。

上述查询确认收货的操作人的例子，在线上问题运营平台的最终展示效果如下图：

优势和规划

整体工具的架构图，通过 Rundeck 整合原有内部的各个工具，将原来散落到各个地方的查询工具聚合到线上问题运营平台，同时降低技术查询的难度，赋能给一线的业务同学。目前我们已经可以做到将数据库和 Dubbo 接口转换成界面化的查询工具，未来还会覆盖更多的内部查询场景。

这套方案的技术难度并不大，它最大的优势还是在于方案的敏捷和灵活，可以不依赖产品研发资源，将工具能力在技术支持内部闭环，只要有代码基础，就能上线新功能，可以做到持续的更新维护。此外，为了安全和合规，我们增加了权限控制，操作审计，全站水印等，确保操作有据可查，重要信息不被泄漏。

成果和感受

我们很早就想把内部工具做整合，最初的想法是整合现在所有的工具，重新开发，后来发现这个成本比较高，且需要一个单独的开发团队长期维护。这个事情就一直搁置，但我们没有就此放弃，一直在寻找方案，直到怀叔（产研技术负责人）来了之后，介绍了这个工具，帮助打下了基础。

本来是为了解决自己内部的效率问题，后来发现它实际上可以帮助到更多的人，让更多的人有能力解决技术类的问题。做事情的时候，要多思考能给外部 & 业务带来什么价值。

原本的流程是商家 - 客服 - 技术支持 - 开发，现在商家 - 客服，流转链路缩短了一半。释放了产研在解决这类问题的精力，解决问题的时间短了，商家满意度自然就高了。

工具解决了短期问题，提升了效率。但这些查询需求最终要被产品化，才能从根本上解决问题。所以在规划初期，运营平台可以通过埋点和数据分析，查看哪类查询问题多，从而能够在推动产品优化的时候，提供有力数据支持，让产品在价值评估的时候，能非常直观的感受到，产品化之后可以降低多少咨询量和人力投入，从而提升被优化的优先级。

最近的一例 case 是商家需要知道某个操作信息，我们通过数据发现，该信息在运营平台被查询超过 100 次，背后意味着至少有 100 个以上的商家在咨询这个问题。于是跟产品对接，通过将这个查询产品化，让商家可自行查询，彻底解决了此类问题，大大降低了一线客服小伙伴的压力。

未来挑战

新增的需求可以通过工具解决，但存量的业务方自行开发的工具仍然像一个个烟囱一样树立在内部，系统之间彼此没有打通。解决问题的时候，往往需要跨越多个系统，才能获取到想要的信息。为此，我们利用开源的能力，使用 RPA （机器人自动化）的方式将这些信息孤岛连接到了一起，"Cross the Wall，See the World" 。

感兴趣的商家，可点击 → 免费试用有赞店铺~