最近与朋友聊天时，他们的公司遇到了一个常见的开发人员生产力陷阱。该公司已强制要求从他们的单体架构和单体存储库迁移，但迁移正在停滞不前。为了加快过渡，负责的基础设施团队决定停止支持单体应用，转而专注于新的服务环境。两年后，工程师为了避免在迁移的任何一方工作而辞职：新的、不完整的服务生态系统和旧的、停滞的、单一的生态系统。工程师们开始对基础设施团队及其艰难的迁移感到不满。基础架构团队也很恼火，尤其是工程领导层，他们通过资源不足来破坏这一关键迁移。
迁移故事对我来说特别有趣，因为我相信大规模迁移是唯一可扩展的技术债务方法。它们也很有趣，因为糟糕的迁移可能会出错。在这种情况下，他们的工程组织在短短两年内就失去了数十年的工程速度，而加速的人员流失让他们走上了再失去数十年的轨道。几十年！
在大多数组织中，集中式基础架构和开发人员生产力组织承担了大部分迁移。当迁移出了差错时，我在领导这项工作的人中遇到的最常见的自我限制信念是，由于缺乏员工人数或资源不足，他们失败了。我认为将人数归咎于自我限制的信念，因为它是对为什么会出错的最没有帮助的解释；即使部分正确，也总能找到更有趣的解释。
好吧，让我们在这里调查几个主题：
- 为什么缺乏员工人数不是一个有用的解释
- 寻找更好的方法来诊断陷入困境的迁移
- 作为负责艰难迁移的领导者的选择
让我们深入挖掘。
“我们需要更多的员工”
我发现对领导大型组织特别有用的一种工具是业务审查模板。领导者写下他们所在领域的摘要，并将他们的进展与过去和当前目标联系起来。这些文档的大多数版本都包含“是什么让你慢下来？”的部分，我已经足够频繁地推出和操作这个过程，知道区域领导者最初经常回答这个问题，说他们“需要更多完成目标的人数。”
我的建议是说几乎其他任何事情。有几个不同的原因让我觉得 headcount 是一个无用的答案：
- 人数只是预算的另一种说法，所以这大致相当于说，“如果我们在这里投入更多的钱，我们就不会遇到问题。”如果您有充分的理由相信您当前的策略和执行非常出色，这只是一个有趣的答案。否则，投入更多资金是一种非常低效的方法
- 同样，您的计划过程应该将您的目标与计划的员工人数进行索引。如果您有计划目标的人数，那么增加更多人数就是承认您没有跟踪计划。这意味着您的策略或执行不适用于您当前的问题和人数限制。你的方法或问题本身必须有一个更有趣的改变，而不是简单地强迫更多的人致力于当前的方法
根据我的经验，“资源不足”的基础架构团队的领导者要么不明白为什么他们的迁移进展不佳（在下一节中讨论），要么忘记了我在该领域工作中学到的重要经验之一：
如果你没有做好挑选问题和解决方案的工作，那么一家经营良好的公司就会裁掉你的团队。这是拥有大量可自由支配预算的获得和维护的机会。
如果您的基础架构组织的资源太少，那么您可能没有向制定组织预算的人展示足够的价值。他们知道你在做什么吗？他们同意这很重要吗？你是如何故意根据他们认为重要的东西来验证你的计划的？您如何从您的角度对他们进行有关组织当前需求的教育？将大部分时间花在推动实现领导关心的目标的影响上，预算问题变得容易得多。
调试迁移
询问员工人数的另一个问题是，即使员工人数获得批准，在短期内你不会有更多的人帮忙，而且你可能会因为额外的工作面试和培训这些员工而变得更慢。无论哪种方式，您都必须与您拥有的团队一起调试和改进迁移。
如果您不确定迁移进展不佳的原因，这里有一些问题要问：
- 人们在迁移过程中陷入了哪些困境？如果您在迁移漏斗上没有明确的工具，那么很难调试出了什么问题。对于任何足够大的迁移，您应该清楚迁移点的总数、尝试开始迁移的数量以及整个漏斗的进展情况（脚手架的新存储库、在开发环境中配置、设置 on-call 轮换、配置生产中等）
- 人们没有开始迁移吗？如果人们甚至没有开始迁移，那么他们认为这对他们的需求没有用处，或者他们从某个地方得到了相反的信号，即迁移是一个坏主意（可能来自以前尝试过迁移但遇到过不好的人）它的时间）
- 哪些群组迁移成功，哪些没有迁移成功？您经常会发现迁移有效和无效的用例群组。例如，有在生产服务器上实时调试的强烈习惯的团队倾向于抵制任何迫使他们改为通过日志进行调试的迁移。当您了解迁移成功和失败的群组时，您可以更好地将精力集中在困难的领域（我觉得在已经进展顺利的领域加倍迁移会更好，但这不会让您更接近精加工）
- 对于没有迁移的团队，他们在做什么？情况如何？当团队拒绝采用迁移时，他们通常会找到针对特定问题的更好解决方案。也许这是您在开始迁移时最初忽略的解决方案，或者您迁移所基于的实际问题并不像您最初认为的那么重要。例如，也许你的单体应用实际上是大多数产品代码的正确解决方案，只有大容量、低延迟的组件才应该迁移到它们自己的服务中。 （这是一个潜在的地方，可以利用您的开发人员生产力调查来获得整个组织的广泛视野。）
- 对于正在迁移的团队，迁移瓶颈在哪里，如何解决该瓶颈？在任何给定点，迁移漏斗中通常会有一两个点使人们放慢速度。解决这些问题，您将解锁整个迁移。例如，人们可能会要求您执行迁移步骤而没有提供解决它所需的所有必要信息，从而导致冗长的来回过程，可以通过更好的文档、结构化的工单字段和确保文档来防止无论在哪里提出请求，都明显链接
当您确定这些问题的答案时，您可以提出更细微的帮助请求：也许您需要组织批准修改后的迁移路径、减慢迁移速度、仅迁移某些类型的工作负载等。您甚至可能不需要组织批准任何事情，相反，您可能只需要改变团队每周的优先事项来解决当前的瓶颈。
当你负责
如果您正在运行迁移，您唯一的选择是诊断问题并根据您当前的限制调整策略，我认为这是“解决问题”。如果您是一个因迁移停滞不前而苦苦挣扎的组织的领导者，那么您将有更多的选择需要权衡。
好消息是失败的迁移是如此普遍，以至于有一套相当清晰的剧本可供选择。我见过的四个最常见的迁移恢复手册是：
- “解决问题。”当您开始迁移时，您会了解一定数量的事情，但您会学到很多很多。不断调整你的方法来整合你所学到的东西。这就是我们如何通过 Uber 的自助式迁移从单体架构中进行工作：我们尝试了一种“迁移试点”模型，其中一个人将所有迁移请求浸泡一周以保护团队的其余时间，我们推动一个组合的自我- 服务和自动化模型大大降低了复杂性，我们创建了脚手架来减少新服务中的错误（例如缺少配置等），我们创建了主动发现常见错误的 linter，等等。我们一直在快速迭代迁移工具，直到压力消退。从事这种自助服务配置和操作工具的核心团队在两年内仅从两个人增长到大约四个人。
- “不要迁移。”在带领 Uber 从他们的单体架构迁移之后，我加入了 Stripe，最初的想法是类似的迁移对 Stripe 很有价值。然而，在了解 Stripe 的设置时，我对自己的雄心保持沉默，几个月后我清楚地发现，环境非常不同。我最终采用了一种完全不同的迁移方法：根本不迁移。虽然这当然不是我一个人的决定，但我相当有信心，我本可以硬着头皮完成向服务的大规模迁移，但我更有信心，通过推动这一进程，我会直接导致公司失去数十年的工程生产力（为了记录，这绝不是说后来 Stripe 转向服务是错误的，只是它需要在符合勘探指导方针的时候发生）
- “取消迁移。”我曾经加入过一个正在从 Nodejs 单体迁移到 Go 微服务的组织。当我深入研究细节时，它被卡住了，两极分化，并且与我们最大的问题不一致：它优先考虑我们已经低成本基础设施的基础设施可扩展性，而不是我们提高产品速度的最紧迫需求。我取消了迁移，这是一个有争议的决定。相反，技术领导小组花时间重新考虑他们的目标并最终采用了不同的方法，逐渐从 Javascript 迁移到 Typescript，并在明年成功完成
- “为当前的迁移战略增加员工人数。”当然，您可以按照所属团队要求配备人员的方式为当前迁移策略配备人员。我将这个策略包含在逻辑上是完整的，但我个人从未见过通过遵循这种方法来恢复艰难的迁移。从根本上说，选择依赖于不存在资源的迁移的决策过程通常超出了纯粹的员工人数问题，还涉及更深层次的技术问题
虽然我不能推荐第四个剧本，但在一些最初的不适之后，其他的非常有效。停滞的迁移非常具有破坏性，如果您是工程主管并且您的组织正在运行失败的迁移，那么调试和解决它最终是您的责任。如果你不确定该怎么做，我会告诉你我在职业生涯早期得到的建议：你最好在做出决定之前果断做出合理的决定，而不是延长决定时间。
原文： https://lethain.com/migration-isnt-failing-due-to-lack-of-staffing/