云迁移？是技术问题也是团队问题

Any organization that designs a system (defined broadly) will produce a design whole structure is a copy of the organization's communication structure

-- Melvin Conway

Good software architecture is very context-specific, analyzing trade-offs that resolve differently across a wide range of environments. But if there's one thing they all agree on, it's the importance and power of Conway's Law.

-- Martin Fowler

在本文中，我们将以一个项目为背景，探讨康威定律对跨国公司进入中国市场的数字化系统迁移过程所产生的重要影响。

项目背景

在这个项目中，我们的客户是一个跨国企业，这个跨国企业有一个全球集中的研发团队，开发了一套用于支撑其核心业务的数字化系统，在国外这套数字化系统运行在谷歌云上，在国内由于谷歌云的无法使用，客户决定将这个系统从谷歌云迁移到一个国内的公有云供应商提供的服务上。

整个数字化系统切分为不同的业务领域，在业务领域内部又有不同的子领域，研发团队以子领域为分界线，工作在不同的子领域内，每一个业务领域都对应了一个 monorepo，不同子领域的研发团队在 monorepo 内部协作开发，每一行代码实现都是以 PR 的方式进行，需要 codeowner 审批之后经 CI/CD 最终部署上线，架构层面依托容器实现了微服务架构。

目前这套核心的数字化系统已经有一定数量的真实用户，且研发团队每个月都会有新的业务功能正式上线，每天都会有代码部署到真实的生产环境。在这个背景下，对于此次数字化系统的迁移，客户期望以总部研发的优先级（“Global first”）为主，不影响现有数字化系统功能的迭代演进，并且希望迁移团队尽可能小的依赖研发团队的支持，并以最快的速度完成系统在中国区的上线。

这不是一个简单的技术产品 1:1 的映射

两个不一样的技术环境

技术层面讲，阿里云和谷歌云有很大的差异性，大部分在谷歌云上使用的云产品都可以在阿里云上找到相应的替代品，但是在技术细节上，阿里云和谷歌云提供的云产品细分功能有很大的差异性。现有应用对于云产品越约深入的使用，对于迁移来将挑战就越大。

基于此，对于迁移团队来说，需要清晰得了解业务场景中对技术产品的要求，根据这些细微的跨功能性需求层面的差异，对于替代品进行评估。现有的业务功能在设计和实现的时候并没有考虑阿里云上技术产品所带来的约束，在一些极端情况下，可能需要迁移过程中作额外的补偿才可以实现同样的效果。

时刻变化的系统

迁移的工作永远都是一个高速上面换轮胎的工作，目标系统不停演进引入新的依赖，增加新的功能。而已经迁移并运行在国内的系统也会随着真正的产品用户的出现而产生越来越多具有市场特色的需求。对于迁移团队而言，除非他的速率非常快，不然他似乎会一直处于对产品研发团队的追赶之中。

不一样的团队

迁移团队和业务开发团队是两个不同的团队，他们的合作本身就存在着很大的挑战:

• 跨国公司不同部门之间本身因所处地区问题，存在语言和时区方面的天然限制；

• 不同的文化、价值观以及工作方式，这种文化差异可能导致彼此之间的理解和信任问题；

• 不同团队之间也可能存在竞争和利益冲突，竞争和利益冲突可能导致敌对氛围的形成；

为了促进不同团队之间的顺利合作，需要在迁移过程中仔细安排资源分配、协作流程、职责划分等，构建良好的沟通渠道，促进有效的合作机制。

这是一场技术变革

综上，迁移过程中不仅要解决复杂的技术问题，更重要的是关注团队的准备程度，帮助不同团队顺利度过过渡期。基于不同的情况，我们认为跨国公司的迁移也存在不同的团队协作模式。

同一团队模式

在这种模式下，迁移团队和功能开发团队组成虚拟的统一团队（这里的虚拟主要是说就汇报线而言，迁移团队在中国区有自己的汇报线，研发团队在总部也有自己的汇报线，而在这条汇报线上在较高的位置可能会有汇合）。

在前期，研发团队依旧专注于业务功能在原有云基础设施上的实现，由迁移团队将开发好的业务功能实时转移到另一个云基础设施上。与此同时，迁移团队也可以在迁移的同时，向研发团队赋能，提供更多另一朵云基础设施的上下文。在后期，业务功能对于云基础设施的依赖趋于稳定，研发团队可以自行实现业务功能在两朵云上的支持，迁移团队也可以渐渐开始接触业务功能转向业务功能的开发。

优势

研发团队最为熟悉当前产品实现的上下文、业务上提供的功能、技术上存在的挑战，通过虚拟团队，研发团队可以更好的帮助迁移团队熟悉上下文。同时，这种方式也最大程度的减小了研发团队与迁移团队之间的差距。

劣势

时区与语言方面的差异一直存在，对虚拟团队的协作会产生非常大的挑战。同时，在协作的过程中，研发团队依然占有主动权，迁移团队在前期融入阶段存在感会较差。而从组织管理的角度，中国区对于迁移团队的研发人员的管理也会较弱，无从发力。

平台团队模式

在这种模式在，迁移团队以平台团队的模式存在，他们专注于提供中立的基础设施能力，由业务团队来基于业务决定引入什么样的基础设施能力。

优势

最大程度解耦迁移团队和研发团队，为各自团队设立了各自的关注点。因为各自关注点的不同，从合作关系的角度更容易构建协作关系而非竞争关系。也是因为两个团队各自关注点的不同，让各自可以专注在关注点本身，进而更好得实现最终目标。迁移团队关注的平台中立的基础设施能力亦可以固化为内部研发能力平台，不断沉淀、优化、演进。

劣势

从企业整体来看，这样的迁移方式，由于不同的业务团队本身优先级的差异，很难控制整体的进度。

两种团队方式实操总结

以上的两种模式展现了团队协作的两个极端模式，在实际项目运作中，通常不会是两个极端。实际情况中，都希望尽可能避开当下模式中的劣势，于是在实际项目中，就有了很多针对劣势的变形。

以“同一团队模式”为例，在我们的实际项目中，中国区团队考虑到迁移期间的团队管理以及长久的团队定位，将中国区原本的虚拟迁移团队组合成单独的迁移团队和 HQ 的研发团队并行开发，这个时候由于代码所有权和业务功能持续更新的问题，对两个团队的同步沟通就产生了极大的要求。而在实际项目执行中，又期望以“Global first”的方式避免对 HQ 研发团队的业务功能交付带来影响，业务研发团队并没有支持迁移的优先级，于是在实操过程中在沟通层面产生了很多依赖：

• 迁移团队没有新业务功能的上下文，不知何时需要作新的适配；

• 业务团队没有保障迁移的优先级，迁移团队针对迁移内容提的很多 PR 都没有办法在第一时间得到及时的回复；

• 业务团队面对堆积如山的 PR 也会感觉代码失去控制。

项目推进的过程中，由于不能充分沟通，双方团队都在合作中遇到了很大的困难。虽然最后项目还是成功交付，但是双方成员都倍感心力憔悴。

  反观整个过程，我认为恰恰是缺乏消除劣势之后的补偿手段，导致了项目推进的困难。

总结

最后，原引《Is Your Cloud Journey Stuck in the Value Gap?》中的观点，

很多企业在云迁移过程中陷入了“价值鸿沟”。他们投入了大量资源进行云迁移，但并没有获得与之相称的业务价值。

究其原因，组织的适配程度很大程度上起到了决定性因素。对于跨国公司而言，云迁移绝非简单的技术组件的 1 到 1 映射，它是不同角色的磨合、不同类型团队的合作，当我们为了一些劣势对现状做了妥协的同时，我们就触碰了优劣势的天平，预期的劣势消失的同时也会带来新的问题，为了弥合这些问题，我们就要作适当的补偿。

希望读完本文的你在今后的“云迁移”项目中都能找到适合的团队模式，事倍功半的完成目标！