Request Tracker（RT）是一款让人长期舍不得换的工单系统，这是有道理的：它灵活、免费，很多实例几乎不用怎么照看就能稳定运行多年。但绝大多数 RT 管理员迟早都要面对同一件事——升级。如果你正在权衡要不要升级，不妨趁这个机会想一想：这些年积累的工单历史，下一站该放在哪里？

Specivo 现在提供了 RT 迁移工具，它以只读方式读取 RT 数据库，把工单及其完整历史搬到 Specivo 中。本文介绍团队为什么迁移、哪些内容会跟着过来、哪些不会，以及如何零风险地试一试。

RT 团队为什么开始另寻出路

我们梳理了 RT 用户在公开论坛和讨论中的发言，发现一个很明显的规律：很少有人抱怨 RT 不好用，但很多人抱怨 RT 不好运维。

  • 安装与升级。RT 基于 Perl 和 CPAN。RT 官方升级指南推荐全新安装再导入数据库，而不是原地升级。论坛里有人说升级花了好几周，也有站点在 4.x 上停留了多年。
  • 定制离不开 Perl。Scrips、Mason overlay 和本地扩展确实能解决问题，但得持续维护，升到 RT 6.0 时还常常要重写。
  • 邮件链路。如何通过 OAuth 从 Microsoft 365 收取邮件，是 RT 论坛上持续时间最长的帖子之一。
  • 单点登录（SSO）、报表和工时记录。这些需求经常被提出，通常得靠扩展，或者直接在数据库里动手。

这些都不说明 RT 是个差工具。它仍在维护，用户也称赞它可靠、专注。我们想说的只有一点：既然升级本来就意味着重做一遍定制，那在动手前先比较一下其他去处，成本并不高。

让多数迁移望而却步的顾虑：丢失历史

过去离开 RT 的团队，往往把历史留在了原地。比如 OpenSSL 迁到了 GitHub，但没有带走已关闭的旧工单。还有的团队把 RT 保留为只读存档，或者只转换未关闭的工单。在我们考察过的服务台和项目追踪产品里，没有一款提供官方支持的 RT 导入器。可选的路通常只有三条：调 API、自己写代码，或者从零开始。

这正是这款工具要填补的空白。多年积累的已关闭工单，记录着“为什么事情会变成今天这样”。丢掉它们，是实实在在的损失。

Specivo 能提供什么

Specivo 是一个可私有化部署的项目追踪与知识库平台，由你自己掌控。

  • 部署在你指定的地方。用 Docker 安装到你自己掌控的服务器上，物理隔离的内网也可以。不用维护 Perl 和 CPAN：升级就是换一个新的容器镜像。
  • 工作项、维基和工时记录合为一体。你的工单、RT Articles 里的文章，以及花在它们上面的工时，都在同一个地方。
  • AI 由你选择。云端大模型、本地模型，或者干脆不用，都可以。AI 智能体和人遵循同一套权限。
  • 没有付费墙。所有功能都在自托管版本里。

工具会迁移哪些内容

工具支持读取运行在 PostgreSQL、MySQL 或 MariaDB 上的 RT 4.4、5.0 和 6.0，不会对 RT 做任何改动。

  • 队列变成项目。已停用的队列会归档。
  • 工单变成工作项，保留状态、优先级、所有者和日期，第一条消息作为描述。
  • 往来回复和评论按原有顺序迁移，并带上字段变更的完整历史。回复和私密评论仍然区分开。
  • 附件，包括内嵌图片，以及 RT 转存到磁盘存储的文件。
  • 已耗工时变成工时记录。
  • 链接关系：父子、依赖、引用。正文里像“ticket 123”这样的提法会变成指向新工作项的链接。
  • 已合并的工单并入被合并到的目标工单，消息保持在一起，旧编号也仍能找到去处。
  • 工单上的自定义字段，连同其变更历史。
  • 人员、组和权限变成用户、用户组和项目角色。
  • Articles（文章）变成维基页面，保留每一个修订版本。

详情见文档中的迁移内容页面。

有意不迁移的内容

如果一款工具号称能搬走一切，RT 管理员有理由不信。这款工具会明确列出它不处理的内容，每一处遗漏都会计入导入报告，不会有东西悄无声息地消失。

  • 自动化：scrips 和模板。
  • Specivo 没有对应模型的内容：资产、审批、提醒、服务级别、保存的搜索和仪表盘。
  • 密码。所有人都需要重新设置。
  • 私密评论上的文件。Specivo 的附件没有私密标记，所以这些文件默认不迁移，除非你明确要求。
  • Everyone 权限。授予 RT 的 Everyone 组的权限不会让任何项目变成公开项目。报告会按队列逐一列出这些权限，由你来决定。

完整列表见不迁移的内容。

关于邮件，说句实话

很多人称赞 RT 以邮件驱动的工作流：队列绑定邮箱地址、通过邮件回复、请求者从不打开 Web 界面。Specivo 没有复制这套模式：它没有邮件进件的服务台，没有客户门户，没有服务级别，也没有 scrips。

所以，Specivo 最适合这样的场景：RT 是 IT、运维、研发或科研团队的内部追踪系统，而你希望把工单、知识和工时记录放在一起。如果某个队列本质上是面向客户的邮箱，那就暂时留在 RT 里。其余的队列可以先迁，剩下的原样不动。

先演练，再切换

你不必在一个周末之内完成切换：

  1. 导出一次试验性的数据，每个队列取几条工单即可。工具只需要一个有读取权限的数据库账户。
  2. 在 Specivo 测试实例中校验并试运行导入包。试运行不会做任何改动。
  3. 和团队一起到处看看，读一读报告，想重复多少次都可以。队列可以一个一个地迁，彼此之间的链接依然能正确解析。
  4. 准备好之后再切换：停止在 RT 里新建工单，做最后一次导出，然后加载到生产环境的 Specivo。

具体步骤见文档：安装、从 RT 导出和加载导入包。

前提条件

  • Specivo 0.11.0 或更高版本，使用 Docker 安装。
  • 运行在 PostgreSQL、MySQL 或 MariaDB 上的 RT 4.4、5.0 或 6.0。
  • 一个只读数据库账户，以及一台装有 Python 3.12 或更高版本、能访问该数据库的机器。

该工具已开源，v0.1.0 版本发布在 GitHub 上。

先拿一个队列试试

在一台闲置服务器上装好 Specivo，导出一个真实队列，看看你自己的历史数据在另一边是什么样子。如果你还要从其他系统迁移，Jira 和 Redmine 也有对应的迁移路径。

“Request Tracker”和“RT”是 Best Practical Solutions, LLC 的商标。Specivo 与 Best Practical Solutions 没有关联，也未获得其认可。