技术债务如何治理？迁移是解决技术债务的唯一可规模化方案

我参与过的最有趣的系统迁移项目之一，是某海外出行平台从基于配置管理工具的服务部署模式，迁移到完全自助式的部署模型。在新的模型下，公司里的任何工程师只需点击几下，就能启动一个新服务。

他们不仅可以这样做，而且确实每天都会这样做：工程师可以在服务尚未完全完成之前，就先部署多个新服务。甚至每位新入职的工程师在入职第一天，都需要从零开始搭建一个服务。

这次迁移之所以值得关注，是因为它的规模非常大。

迁移开始时，部署一个新服务大约需要两周的自然时间，以及两天的工程时间。而且，我们每天都在进一步落后。当时的压力确实不小，但它也提供了一个绝佳的实验场，让我们学习如何运行大规模软件迁移：规模大到足以观察细微变化，周期又长到足以尝试不同方法。

随着代码库老化、业务持续增长，迁移会变得既必要，又频繁到令人沮丧。大多数工具和流程只能支撑大约一个数量级的增长。一旦规模超过这个量级，它们就会开始失效。因此，在快速增长的公司里，系统迁移往往会成为常态。

这并不是因为原来的流程或工具不好。恰恰相反：某个工具在规模显著扩大后不再适用，通常说明它在设计之初合理考虑了当时的约束，而不是一开始就过度设计。

换句话说，你会频繁更换工具和方法。而迁移到新软件、新架构或新流程的能力，很容易成为限制整体研发速度和研发效能的关键因素。

既然迁移如此重要，我们却很少认真讨论它。现在，是时候改变这一点了。

为什么迁移是治理技术债务的重要方法

迁移之所以重要，是因为它通常是解决技术债务的唯一有效途径。

工程师讨厌技术债务。如果有一个简单项目可以由他们独立完成，从而减少技术债务，他们通常会主动去做。工程经理也同样讨厌技术债务。如果有一个简单项目可以由他们的团队独立完成，他们也会安排团队去做。

最终，这会导致一种局面：那些容易处理的技术债务，通常早就已经被处理掉了。剩下的大多数问题，都需要多个团队协作才能解决。

这类问题，就是迁移。

每次迁移的目标，通常都是创造技术优势，或者减少技术债务。

比如：

“你的索引不再需要塞进单台服务器里。”

或者：

“即使主节点发生故障转移，已确认的写入仍然能得到保证。”

迁移处在一个尴尬的位置上：为了换取未来更大的容量、更好的可靠性或更低的维护成本，你必须牺牲一部分当下产出。

这也使得迁移排期经常充满争议。而且，随着系统规模扩大，迁移成本也会越来越高。

坊间曾流传过一句话，用来形容那些几乎把所有精力都花在升级依赖和更新模式上的团队：他们只是在“原地跑步”。团队虽然一直很忙，却没有时间推进自己负责的产品或系统。

把所有时间都花在迁移上当然很极端。但几乎每一家中型公司，都会有一长串人手不足的迁移任务：从虚拟机迁移到容器、部署熔断机制、迁移到新的构建工具、升级基础设施、替换旧框架……这类清单似乎永远不会结束。

随着公司和代码规模增长，迁移是有效管理技术债务的唯一可规模化机制。

如果你无法有效推进软件迁移和系统迁移，最终就会深陷技术债务泥潭。而且，到最后你还是得迁移，只不过那时很可能已经不是迁移，而是被迫重写。

如何做好一次大规模系统迁移

好消息是，虽然迁移很困难，但它有一套相对标准且非常有效的操作流程：

降低风险，赋能迁移，然后完成收尾。

第一阶段：降低迁移风险

迁移的第一阶段是降低风险，而且要尽可能快速、低成本地完成。

先写一份设计文档，然后提交给那些你认为迁移难度最大的团队。根据他们的反馈反复迭代。

再把设计文档提交给那些拥有特殊模式和极端情况的团队。继续迭代。

接着，结合未来六到十二个月的路线图进行验证。继续迭代。

当设计方案逐渐完善之后，下一步不是先找最容易迁移的团队，而是深入到最具挑战性的一个或两个团队中，与他们并肩工作，共同构建、改进并迁移到新系统。

不要从最简单的迁移开始。那会给你一种虚假的安全感。

有效降低风险至关重要。因为每一个支持迁移的团队，本质上都在押注：你能够把这件事真正完成，而不是让他们面对一个半途而废、最后不得不回滚的系统。

如果你让一次迁移半途而废，人们就会对下一次迁移保持高度怀疑。

第二阶段：用工具和文档赋能迁移

一旦验证了解决方案确实能解决预期问题，就该开始完善工具。

很多人会在这一步直接创建跟踪工单，让各个团队自己实施迁移。但更好的做法，是先放慢脚步，构建工具，以程序化方式完成最容易迁移的 90% 工作。

这会大幅降低整个组织的迁移成本，提高迁移成功率，也会为未来更多迁移创造条件。

当你已经尽可能多地用程序化方式处理迁移之后，下一步要考虑的是：如何提供自助式工具和文档，让使用者能够轻松完成必要变更。

最好的迁移工具应该是增量式、可逆的。

如果出现问题，用户应该能够立即恢复到之前的行为。同时，工具也应该具备足够的表达能力，帮助用户降低特定迁移路径上的风险。

文档和自助服务工具，本质上也是产品。它们只有在同样的产品迭代模式下，才能真正发挥作用。

你可以先找几个团队坐下来，观察他们如何按照你的指引操作。然后改进文档和工具。

再找另一个团队，重复这个过程。

在大规模迁移中，花两天时间认真打磨文档，让工具更直观易用，可能为整个组织节省数年时间。

对于研发团队来说，迁移过程中的设计文档、迁移工单、测试验证、发布节奏和经验沉淀都需要被持续管理。像 PingCode 这样的智能化研发管理工具，可以把团队目标、需求评审、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让迁移过程中的状态、风险和知识能够持续流转，而不是散落在不同系统里。

所以，这件事值得认真去做。

第三阶段：完成迁移收尾

迁移的最后阶段，是废弃被替换掉的旧系统。

这意味着你必须实现新系统 100% 的采用率。而这往往非常困难。

第一步是止损：确保所有新写的代码都采用新方法。

你可以通过在代码检查工具中加入限制机制，或者更新文档和自助工具来实现这一点。

这永远应该是第一步，因为它能让时间站在你这一边。这样一来，你不再是在默认落后，而是在默认前进。

接下来，你应该开始生成跟踪工单，并建立一种机制，把迁移状态持续推送给需要迁移的团队和管理层。

向管理层提供更全面的迁移信息非常重要。因为真正需要决定迁移优先级的人，往往是管理层。如果某个团队迟迟没有开始迁移，通常并不是因为他们不知道要迁，而是因为他们的领导层没有把这件事列为优先级。

在跨团队迁移项目中，除了研发管理本身，还会涉及会议纪要、任务协同、审批、日历安排和跨部门沟通。对于这类更通用的项目协作场景，Worktile 这类项目协作系统可以帮助团队把任务、文档、IM、目标和审批集中起来，减少迁移后期因为信息分散带来的推进成本。

到这个阶段，你已经接近完成了。但通常还会剩下一些棘手问题，或者一些缺少人手、迟迟没有推进的迁移项。

这时，你唯一的办法就是亲自深入进去，把它们完成。

这未必有趣，但要达到 100% 的完成度，负责迁移的团队就必须愿意深入每一个细节。

迁移项目的认可机制：奖励完成，而不是启动

关于完成迁移，还有一个重要建议：如何给予认可。

在迁移进行过程中，适当庆祝当然很重要。但大部分庆祝和认可，应该留到迁移真正完成之后。

尤其需要注意的是，启动但未完成的迁移，往往会制造大量新的技术债务。因此，你的激励机制和认可机制必须谨慎设计，避免产生错误激励。

真正值得奖励的，不是“启动迁移”，而是“完成迁移”。

因为在迁移这件事上，只有完成，才真正创造价值。