跨国企业云迁移：不止于技术丨IDCF

来源：Thoughtworks商业洞见

作者：王妮、银大伟

受到文化和政策的影响，对于许多跨国企业来说，中国市场与全球其他市场(Rest of the World)有很大的不同，具体体现在四个层面：用户习惯、数字化生态、人才和法律法规。这些不同从根本上决定了对于跨国企业来说，进入中国意味着技术、文化和管理的深度本土化。在本文中，我们将首先分析跨国公司进入中国的阶段，探讨云迁移作为贯穿始终的主题所代表的核心问题及挑战。

跨国企业进入中国的

         三个阶段

从数字产品和服务本土化的程度，我们可以将跨国企业进入中国的过程分为三个阶段：快速启动(Access)，营销策略本土化(Scale)，数字化能力本土化(Stablize and Grow)。

快速启动阶段的关键字是“可用”。此类的跨国企业在海外有成熟的数字产品、稳定的客户群，但尚未对中国市场做出过任何定制化；他们的数字产品很大可能因为法律法规的限制、网络延迟的影响，无法很好的触达中国用户。作为探索中国市场的第一步，本阶段的重点在于合规，而技术上一般做法是尽可能复用现有系统，将必须迁移至中国的系统迁移，并替换一些无法在中国使用的平台（如谷歌的服务、支付和登陆方式等），复制或重新构建一份前端，做到数字产品在中国可用即可。

营销策略本土化阶段的关键字是“业务“。这个阶段业务的增长是首要目标。为了完成这个目标，跨国企业在中国组建市场和营销团队，购买必须的企业套件、营销工具等，以尽快融入本土数字化生态当中，并可能因此催生出本土化的业务模式。从用户视角来看，市面上会出现更多与该跨国企业相关的触点，例如小程序、手机应用、线上线下活动等。

数字化能力本土化阶段的关键字是“赋能”。并不是所有的跨国企业都需要进入这一阶段，而进入这一阶段的主要动力来源是解决一个内部矛盾和一个外部风险。

内部矛盾是指：随着中国境内业务的增长，跨国企业中国区更加深入的理解了自己的数字产品和对应的用户，开始期望拥有更多话语权，能够根据市场需求制定自己的产品策略，以辅助更大程度的增长；因此中国区会期望对部分核心业务系统做出定制化（例如供应商管理系统、核心业务流程管理系统等），而此时本土诉求与全球优先（Global Frist）之间就产生了严重冲突。

外部风险是指：受到地缘政治的影响，网络空间主权正在加剧Splinternet现象，进而给跨国企业在华业务连续性带来不可控风险。对于这两个问题，通常的应对方案是将更多核心业务系统迁移至中国，并构建中国境内的数字化能力，以对迁移过来的系统进行维护和定制化的修改。

   贯穿始终的云迁移是一场

牵扯到众多利益相关人的变革

受到中国防火墙和个人信息保护法的限制，从快速启动阶段开始，跨国企业就需要将部分必须的系统迁移至中国境内。我们遇到过很多这类的案例，无论目标是将APP在中国上架，还是在中国建立一个主页，都需要不同程度地将背后的部分系统延伸至中国。而在数字化能力本土化阶段，随着数字产品定制化需求的增长，越来越多的核心业务系统会被纳入到迁移范围之内。因此我们认为在跨国企业进入中国的过程当中，云迁移是一个逃不掉、始终存在的话题。

很多时候我们谈到云迁移，会将它定义为一个技术问题，并且认为它是一个一次性的动作，往往将关注点放在“迁什么、迁到哪里去、怎么迁”上面。对于其他云迁移场景来说，这或许是对的，但对于跨国企业进入中国来说，特别是处于数字化能力本土化阶段的跨国企业来说，云迁移不应该被简单的定义为一个可以一次性解决的技术问题，不仅仅因为它是长期存在的，也因为它意味着系统所有权的转变以及进而带来的架构的改变。

从很多客户案例中我们发现，迁移贯穿跨国企业进入中国的始终，从最开始的最小集迁移到数字化能力本土化阶段的核心系统迁移，涉及的服务数量众多，持续时间长，这个过程可能会不同程度地面临如下挑战：

• 迁移之后的系统由谁来更新和维护？如何更新和维护？需要根据场景给出系统的解决方案。

• 如何适应新的云环境？需要做出哪些修改？这会对现有的项目代码、交付流程、部署架构、线上监控带来什么变化？如何在影响最小化和本土能力最大化之间平衡？

• 当迁移服务数量比较大时，该如何组织迁移？由于各个服务的业务、技术栈各不相同，评估迁移工作量并制定最优迁移路径并不容易，以往通过手动分析的方式很可能不再适用。

• 如何相应快速变化的系统？在迁移过程中服务并不是静止的，各个业务线在根据自己的规划进行着活跃的开发活动，这就意味迁移的计划需要能够快速相应系统内容的变化。

• 一般而言进入中国是企业的战略计划，并非业务线驱动，因此迁移是由平台团队来主导和实施的，那么平台团队该如何管理好业务团队的期望？

基于以上原因，我们认为此时的云迁移是一场牵扯到众多利益相关人的变革，而非一项技术举措或者平台项目。在这场变革中，核心问题有两个：

这里我们就这两个问题分别给出其应对的思路，与读者一起探讨。

     将云迁移看作

一个持续学习的过程

云迁移实施过程的大部分时间是与业务部门的沟通和合作，因此充分掌握业务部门所拥有的系统的上下文，根据该上下文推荐迁移方案和计划便可以更好地推动事情的进展，这与市场学中的市场细分方法一脉相承：市场细分是指，为了更好的拓宽市场、发掘机会，营销者不再根据产品品种、产品系列来进行营销，而是通过市场调研，依据消费者的需要和欲望、购买行为、购买习惯等方面的差异，将市场整体划分为若干消费者群的市场分类，从而更加有效利用有限资源、提升客户满意度和忠诚度。

一个服务的上下文包括与该服务相关的方方面面，从编写语言到部署方式，从通信方式到所依赖的库或服务，从业务重要性到合规约束。服务上下文里的每一个指标都会一定程度的影响迁移的复杂度和优先级。因此在制定迁移策略的过程中，我们不能仅从宏观角度出发为服务划分迁移优先级，还应该从服务本身的上下文出发，从微观角度观察所有服务，为服务分类，以制定由简至难的服务迁移计划，将云迁移变成一个学习的过程，逐步增加平台团队和业务团队的信心。

一种基于自动化服务分类的云迁移方法[1]

     向平行多云架构

或可移植多云架构演进

与一般意义上的云迁移不太一样的地方是，由跨国企业进入中国而带来的云迁移会催生出一个多云环境。对于大多数跨国企业来说，迁移后系统的所有权是一个复杂的政治话题，不仅取决于Global的长期计划，也取决于中国区业务及IT团队的成熟程度。但大多数情况下，在真正实施差异化定制之前，被迁移的服务很长一段时间内都会由Global团队来维护，与部署在Global的服务一起升级和更新。在这段时间里，平台团队需要考虑的问题是如何帮助业务团队更好的维护部署在两朵云上的服务，也就是应该选择什么样的多云架构策略。

借鉴Gregor Hohpe所给出的5种多云架构类型，我们认为平行多云(Parallel Multi-Cloud)和可移植多云(Portable Multi-Cloud)是跨国企业进入中国这个场景下的可行多云架构。平行多云是指“开发一次，部署到多个云”的模式，而可移植多云是指因为应用具备足够的可移植性，从而可以在多个云服务之间切换。

相较于可移植多云，平行多云架构的侵入性较弱，比较容易被业务团队采纳。平行多云可通过将服务所依赖的云服务抽象出来，在编译打包阶段根据目标环境来替换所依赖库。而可移植多云架构则是完全将云服务隔离，需要依赖类似于OAM和KubeVela这样的解决方案来实现，要对服务做出大量的修改。

5种多云架构模型

 小结

我们接触到的很多想要进入中国的跨国企业都会面临这样那样的挑战，前期多集中在合规约束上，中期在产品本地化策略上，而当进入实施阶段后，迁移和架构便成了会产生更深远影响的问题。如何从第三视角给出专业的建议，减轻大规模迁移和服务所有权之争所带来的痛苦，是值得我们不断探索的方向。

#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。

2022年10月29-30日将在深圳举办，36小时内从0到1打造并发布一款产品。

企业组队参赛&个人参赛均可，赶紧上车~👇