技术迁移失败，未必是因为人手不足：如何诊断架构迁移问题

最近我和一位朋友聊天。他提到他们公司遇到了一个很常见的开发者生产力瓶颈公司强制要求团队从单体架构和单体代码库迁移出去但技术迁移进展非常缓慢。为了加快迁移负责基础设施的团队决定停止维护旧的单体架构转而专注于新的服务化环境。两年后工程师们开始陆续离职只为避免在迁移过程中同时承受两套系统的压力一边要维护尚不完善的新服务生态另一边还要维护已经停滞不前的旧单体生态。工程师们开始怨恨基础设施团队也怨恨这场迟迟无法完成的架构迁移。基础设施团队同样感到恼火尤其不满工程领导层没有为这项关键迁移提供足够资源。很多技术迁移失败时团队的第一反应往往是“人手不足”。但更常见的真实问题是迁移目标没有被充分验证迁移瓶颈没有被清楚识别或者迁移策略没有根据现实约束及时调整。迁移案例对我来说尤其有趣因为我相信大规模迁移是解决技术债务唯一可扩展的方法。它们之所以有趣还因为糟糕的迁移会造成极其严重的后果。在这个案例中他们的工程团队在短短两年内就损失了数十人年的工程产能而加速的人才流失还让他们面临继续损失更多工程生产力的风险。数十人年在大多数组织中集中式基础设施团队和开发者生产力团队承担了大部分迁移工作。当迁移出现问题时我发现负责这项工作的人最常陷入的一种自我限制性判断是失败是因为人手或资源不足。我认为把失败归因于人手不足是一种自我限制性判断因为它对理解真实问题几乎没有帮助。即使它部分属实通常也总会有更有解释力、更值得处理的原因。下面我们来讨论几个问题为什么人手不足并不是一个有效解释。如何更好地诊断技术迁移困境。作为负责处理迁移困境的领导者你有哪些选择。让我们深入展开。为什么技术迁移失败不应先归因于人手不足在领导大型组织时我发现业务回顾模板特别有用。领导者需要撰写一份关于自己负责领域的总结并将当前进展与过去和当前目标进行对比。大多数这类文档都会包含一个问题“是什么阻碍了你的进度”我经常推动和执行这一流程因此我很清楚各领域领导者最初对这个问题的回答通常都是“我们需要更多人手才能完成目标。”我的建议是尽量回答另一个问题。我认为“人手不足”这个回答帮助不大原因有以下几点。首先人员编制本质上是预算的另一种说法。因此这句话大致等同于“如果我们在这里投入更多资金就不会有问题了。”只有当你确信当前战略和执行方式都非常出色时这种说法才真正有意义。否则增加投入往往是一种效率很低的解决方式。其次你的规划流程本应让目标与计划中的人员编制相匹配。如果你的实际人员编制与制定目标时预期的一致那么要求增加人手实际上就是在承认你没有按计划推进。这意味着你的战略或执行方式无法在当前问题和人员约束下奏效。此时你真正需要的是对方法或问题本身做出更有意义的改进而不是简单增加人手来推进原有方法。根据我的经验资源不足的基础设施团队领导者通常要么还没有弄清楚迁移为什么进展不顺利要么忘记了我在这一领域学到的一条关键经验如果你不能有效选择问题和解决方案那么一家管理良好的公司最终会削减你的团队。拥有可观的自主预算是一种必须努力争取并持续维护的机会。如果你的基础设施部门资源不足很可能是因为你还没有向负责制定组织预算的人充分展示价值。他们理解你的工作内容吗他们认同这项工作的重要性吗你是否有意识地用他们真正关心的目标来验证你的计划你是否能从自己的专业视角向他们解释组织当前真正需要什么把大部分时间用于推动工作朝着领导层关心的目标前进预算问题往往会变得容易得多。如何诊断技术迁移和架构迁移问题申请增加人手还有另一个问题即使申请获得批准短期内也不会立刻有更多人来帮忙。而且随着你投入更多时间面试和培训新人团队短期工作效率甚至可能下降。无论如何你都必须依靠现有团队来诊断并改进迁移工作。如果你不确定迁移为什么进展不顺利可以问自己以下几个问题。第一个问题人们在迁移过程中遇到的瓶颈是什么如果没有清晰的迁移流程监控就很难诊断问题所在。对于任何规模较大的迁移你都应该清楚了解迁移点总数是多少有多少用户尝试启动迁移以及他们在整个流程中分别推进到了哪里。例如他们是否已经创建了新的代码库是否已经在开发环境中部署是否已经设置值班机制是否已经在生产环境中部署在真实的研发组织中这类迁移信息往往分散在需求、任务、代码、测试、发布和文档之中。如果缺少统一记录和追踪迁移瓶颈很容易被误判为“团队不配合”或“人手不足”。例如PingCode 这类智能化研发管理工具可以将团队目标、需求评审、项目开发、测试发布和 Wiki 知识沉淀串联起来帮助团队用更完整的研发过程数据判断迁移到底卡在了哪里。第二个问题人们是不是还没有开始迁移如果团队连迁移都没有开始说明他们认为这项迁移对自己的需求没有帮助或者他们从某些地方接收到了相反信号认为迁移是个坏主意。这种信号可能来自之前尝试过迁移、但体验糟糕的人。第三个问题哪些用户群体迁移成功哪些用户群体迁移失败你通常会发现某些用例群体迁移得很顺利而另一些群体则不断失败。例如习惯于在生产服务器上进行实时调试的团队往往会抵触任何迫使他们只能通过日志调试的迁移方案。当你知道哪些用户群体迁移成功、哪些用户群体迁移失败后就可以更好地把精力集中在进展缓慢的领域。虽然继续在已经进展顺利的领域加大投入可能会让你感觉更好但这并不能真正让你离完成迁移更近。第四个问题对于那些没有迁移的团队他们采用了什么替代方案效果如何当团队抵制迁移时他们往往已经找到了一种更适合自身特定问题的解决方案。也许这正是你在最初启动迁移时忽略的方案也许你当初认为必须通过迁移解决的问题并没有你想象中那么重要。例如也许你的单体架构实际上仍然是大多数产品代码的最佳解决方案只有那些高流量、低延迟的组件才应该迁移为独立服务。这里可以利用开发者生产力调查更全面地理解整个组织的真实情况。第五个问题对于正在迁移的团队来说迁移瓶颈到底在哪里如何解决这个瓶颈在任何特定阶段迁移流程中通常都会有一两个环节拖慢整体进度。解决这些环节整个迁移就可能顺利推进。例如用户可能在没有提供足够信息的情况下请求你执行某个迁移步骤导致双方反复沟通。通过完善文档、采用结构化工单字段并确保所有提交请求的位置都能清楚看到文档链接就可以避免这类问题。当你找到这些问题的答案后就可以提出更细致、更有针对性的帮助请求。比如你可能需要组织批准修改后的迁移路径放慢迁移速度或者只迁移特定类型的工作负载。你甚至可能不需要组织批准任何事情而只需要调整团队每周的工作重点优先解决当前最关键的瓶颈。对于涉及多团队协作的迁移也可以借助 Worktile 这类通用项目协作系统把任务、项目、文档、目标、日历、甘特图、工时和审批等信息统一承载起来让迁移工作从口头协调变成可追踪、可推进的日常协作流程。当你负责一项失败的技术迁移时如果你正在负责一项迁移唯一可行的选择就是诊断问题并根据当前约束调整策略。我把这称为“解决问题”。如果你是组织领导者而组织中的迁移工作已经陷入停滞那么你会有更多选择需要权衡。好消息是迁移失败非常常见因此也有一套相当成熟的恢复方案可供选择。我见过的最常见的四种迁移恢复方案是第一种方案解决问题。迁移刚开始时你也许只掌握了一些基本信息。但随着迁移推进你会学到更多东西。你需要不断调整方法把新学到的经验纳入其中。这正是我们在海外某出行平台公司帮助团队从单体架构迁移到新架构时所采用的自助服务流程。我们尝试过一种“迁移试点”模式安排一个人在一周内集中处理所有迁移请求以保护团队其他成员的时间。我们推广了一种结合自助服务和自动化的模型大幅降低复杂度。我们创建了脚手架以减少新服务中的错误例如配置缺失。我们还开发了代码检查工具用来主动发现常见错误。我们不断快速迭代迁移工具直到压力缓解。负责自助服务配置和运维工具的核心团队在两年内也只是从两人增长到大约四人增长幅度非常有限。第二种方案不要迁移。在加入海外某支付技术公司之前我曾主导过海外某出行平台公司从单体架构向服务架构的迁移。最初我坚信类似迁移也会对这家支付技术公司大有帮助。然而在深入了解它的架构之后我并没有公开推动这一想法。几个月后我逐渐意识到两家公司的实际情况截然不同。最终我采取了完全不同的迁移策略根本不迁移。这当然不是我一个人的决定但我相当确定如果我执意推动也完全可以强行推进一次大规模服务架构迁移。可是我更确信如果那样做将会直接导致公司损失数十人年的工程生产力。需要说明的是这并不是说这家公司后来转向服务架构是错误的而是说迁移的时机必须符合探索和诊断的原则。第三种方案取消迁移。我曾加入过一个正在从 Node.js 单体架构迁移到 Go 微服务的组织。深入了解细节后我发现这场迁移已经陷入僵局内部矛盾重重而且它和我们真正面临的最大问题背道而驰。这场迁移优先解决的是基础设施可扩展性问题而我们的基础设施成本其实已经很低。相比之下我们最迫切需要解决的问题是提升产品迭代速度。于是我取消了这场迁移。这是一个颇具争议的决定。取而代之的是技术领导团队花时间重新思考他们的目标。最终我们采取了另一种方法逐步从 JavaScript 迁移到 TypeScript并在接下来的一年内成功完成了这项迁移。第四种方案为当前迁移策略增加人手。当然你也可以按照项目团队的要求增加人员继续执行当前迁移策略。我之所以列出这个方案主要是为了逻辑完整性。但就我个人而言我从未见过哪个陷入困境的迁移项目能够通过这种方法真正扭转局面。从根本上说选择一种依赖尚不存在资源的迁移方案本身就说明决策过程存在问题。这通常不只是人员配置问题还涉及更深层次的技术判断和战略选择问题。虽然我不推荐第四种方案但其他几种方案在克服最初的不适之后通常都非常有效。迁移停滞会造成极大的混乱。如果你是工程负责人而你的组织正在经历一场失败的迁移那么最终诊断并解决问题就是你的责任。如果你不确定该怎么做我想分享一条我职业生涯早期得到的建议尽早、果断地做出一个合理决定几乎总是比拖延决策更好。