跨国互联网公司并购中 用基础设施即代码进行架构迁移

本文介绍如何通过 DevOps的基础设施即代码实践，把架构以及开发/运维实践和规则固化为配置和代码。让所有的团队和成员能够依照同样的规则进行开发和运维；通过自动化的手段加速团队、产品和架构的融合过程，提升整个组织的技术水平。减少组织间的沟通摩擦。

跨国互联网公司并购案例

案例梗概：某企业收购了分布在泰国、马来西亚、印度尼西亚、新家坡等地的几家东南亚拥有相同业务的互联网公司。但如何在多国家、多语言文化的情况下，进行分布式IT敏捷产品团队的合并、步调一致的工作和实现统一的管理成为难题。

剖析组织现状

既要保留各个国家的业务团队，又要集中管理IT团队，首当其冲的是剖析组织现状。那么，做架构迁移要先了解哪些组织现状呢？ ″

康威定律原话：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。

这句话中“constrained”的意思是强制。也就是说，当系统架构与组织架构不匹配时，系统结构会被强制转化成与组织架构一致。要做到组织架构和基础设施架构保持一致，就需要根据未来的组织结构设计系统架构，减少系统架构演进中的适应性浪费。

如下图，是合并前架构的情况：

如图中所示，每个国家的公司运营着自己的网站。其中每一公司都有一部分是用WordPress运营的。虽然都是 Wordpress，但应用架构和使用方式上存在着诸多的差异。我们首先是要识别出这种差异。而这种差异不仅仅是技术上的，还有组织上的。 并购并不仅仅是把团队合并到一起就能解决问题，而是要把多国、多语言、多站点，变成多国、多语言、单站点。通过一个站点来支撑多个地区的业务，这里选择马来西亚作为这个站点进行举例。

那么，组织架构就会办成如下图所示：

当组织架构变成多国、多语言、单站点，那么所对应的就是一个IT团队。如图可以看到把Dev、Ops分开来表示，这样的组织结构和DevOps有什么关系呢？这就需要了解下DevOps的两种组织形式：

• Team Own Ops：团队内自有的Ops，把Ops当做团队成员，实现开发和运维合作。
• Team Share Ops：不同产品开发团队之间共享一个Ops。在这种情况下 Ops 团队就是一个平台团队。

为新组织设立目标 做团队合并之前，要为新组织设立目标，如下：

• 单一的产品开发团队及运维团队，各地区共享，由统一的产品经理协调各地的开发任务和业务需求。
• 每个地区可自有开发团队，但都由马来西亚开发团队来统一管理，所有运维都由马来西亚团队来支持。
• 在所有公司构建DevOps文化及机制，从 Team Own Ops 向 Team Share Ops 变化。
• 提升各个国家的Dev / Ops 水平，当水平达到一致，便可通过DevOps这个中间桥梁打通。

用DevOps加速团队之间合并的进程

虽然IT团队来自不同的国家，分布在不同的地理位置，他们的文化背景不同，说着不同的英语方言，但是大家的技术栈是相同的。

一方面，我们通过 Zoom 构建起了每天的在线视频会议，及时同步各个团队之间的状况。另一方面，我们遵守着同样的开发规则。 其中，测试驱动开发（TDD）在这样的分布式团队中十分重要。虽然对编程语言和技术框架的理解不同，但是自动化测试为开发人员构建出了统一的理解。这样就使得每个团队，每个成员去设计、实现自动化测试。

一方面，用测试作为对需求的理解，减少和降低了不一致性，此外，通过测试驱动开发可以保证代码品质，进而提升程序员的编码水平。此外，自动化测试在这里就相当于一种代码质量的标准， 组织被合并之后，架构也要随之改变，这时就要着手做架构迁移。可以用基础设施即代码把自动化作为一种制度去提升整体运行效果。

系统架构的迁移实践系统架构迁移要在了解当前组织架构现状的前提下，制定架构的目标、设计迁移策略。这三方面落实后，才能为新组织设计新架构。

架构要尽量设计要设定最高要求，这里不要将就现有人员的能力/精力，但是要规划成本，成本规划里不光要考虑迁移成本，还要考虑迁移后的维护成本。这样，有了最高的要求和标准，可以引导大家为共同的结论和方向一起努力，既可以提升个人及团队的技术能力，也是提升DevOps合作的过程，因为好的架构一定是和多方利益相关者在不断沟通下形成的。通过不断的开发团队沟通，解决开发痛点，来主动提升 Ops 团队的合作意识。所以，DevOps不仅是自动化，更是在磨合和共识团队合作的价值观和工作方式。

当前的组织与系统架构存在的问题

当组织和产品进行合并之后，不同的地区多系统的运维就变成了单一系统的运维。因此，很多运维人员不再被需要，在现在的案例中，仅剩四名运维工程师，剩下的运维工程师相继离职，运维工作由技术负责人兼任。 这里遇到的问题是，如此少量的运维人员，如何要去维护大量技术栈/语言/业务各异的站点。因为产品简单了，但架构复杂了，运维的环节和结点更多了。

此外，为了避免账户单点，平均每个系统至少要有三个AWS账户：开发环境、测试环境及生产环境。这样一来，三个人维护二十多个账户是一种浪费，还需要做账户合并。 这三个运维人员人还需要应对风格各异的其它遗留系统，因为每一个国家的系统都分别由不同的架构师主导，对于仅三人的运维团队来说也是非常大的挑战。 尽管收购的企业核心业务相似，但每个国家的现状、市场条件、用户群都不一样，所以仍然需要一部分本地定制化业务。 总之，在系统架构方面存在的主要问题如下：

• 每个国家的架构都由不同架构师设计，所以会留下很多隐藏知识，以至于维护困难。
• 基础设施即代码已在一些IT团队中被使用，却没有用好，存在很多硬编码。
• 旧架构在更新一个应用时，就需要把整个架构全部更新，并非部分更新。

架构迁移的目标

综合当前新组织的现状与旧架构的问题，制定架构迁移目标如下：

• 实现用基础设施即代码管理所有的基础设施，因为旧架构还有些应用在机房裸机上运行，并且需要手动安装。
• 现有基础设施架构全部迁移到云上。
• 基础设施的管理要规范化，可以把基础设施即代码看成一套制度，用来规范运维人员如何操作基础设施。
• 给所有运维人员、开发工程师提供统一界面，让他们基于基础设施即代码之上进行应用开发，进而实现部分更新，而不是全部更新。

实现能力和组织结构的迁移，基础设施即代码首先作为一个制度可保证以上几点。基础设施即代码一旦作为制度，在执行的过程中，要做到的最后一点就是能力的提升，即把基础设施变成一种产品。 如何把基础设施变成一种产品？首先是把基础设施架构经验在不同团队中复用，让不同国家、程序员、运维人员获得更安全，更稳定，更灵活的架构。其次是实现高度自动化，可以快速建设和定制。再次是要做到关注点分离，根据场景把变更缩小在一定的范围里。最后，要把开发和各环境做到抽象一致性，便于不同团队能够在不同环境中做到无缝切换。

架构的迁移策略

架构迁移有两大原则：一是最少的变更，实现做到只做一个简单的变更，就完成迁移；二是最小的影响，就是减少架构变更造成的不良影响。 架构迁移的整个策略如下：

• 将遗留系统应用按照（架构/应用/数据）进行封装。
• 用基础设施即代码构建一套新的架构，构建可复用架构模型。
• 对架构/应用/数据这三部分别用该脚本实施自动化迁移。
• 测试完成后切换总域名，切换子域名。
• 两周过后，遗留系统下线。

此架构策略除需要手动切换域名之外，其余全部实现自动化，主要涉及技术如下：

• 用 Ansible + Cloudformation 封装并构造新的基础设施。基础设施要能做到随时可以完全恢复。
• 全量数据 dump / import，自动化备份到 s3 上。减少数据库的状态。
• 用 Docker 封装 wordpress 应用。不同的国家用不同的主题和插件组合完成。
• 用 cdn + nginx + wordpress 共同做 301、302 跳转。要为每个角色做好区分。
• 用脚本做迁移，迁移脚本分类（开发/测试/生产）管理。
• 切换域名指向（手动）。

为新的组织结构设计架构

对组织进行重建，确定新组织对应架构的目标和策略之后，紧接着就是根据使用场景，设计基础设施即代码的架构，实现整个架构自动的搭建和还原。然后，根据使用场景设计安全策略，避免人为操作，减少人为故障。 顾宇老师认为，基础设施即代码和基础设施是类和对象的关系。通过定制化的模板结合不同的场景产生不同的基础设施实例。一方面统一了架构语言，另一方面减少了不经审计的认为操作。此外， 可以采用面向对象原则进行逻辑分层，隔离不同场景的关注点。例如：持续交付关注Docker 镜像的部署和变更，应用维护关注日志的查询和操作。

写在最后

在该案例中，利用基础设施即代码技术有几个关键要点，总结如下：

• 架构迁移要为组织结构迁移服务。
• 把自动化和基础设施即代码当做制度使用（康威定理和逆定理）。
• 把基础设施即代码当做一个产品开发。
• 安全的架构和架构的安全。
• 基础设施逻辑分层。
• 基础设施即代码本质上是一套类库，从面向对象的原则考虑基础设施的设计。
• 构建每日可用架构。

由于篇幅原因，还有众多相关细节如、没有一一纳入文章中，想要了解更过内容的开发者，可查看 视频与PPT 【讲师简介】