跨国互联网公司并购,如何实现统一的IT管理?

互联网企业的并购不仅是组织结构的融合,更是产品架构和产品团队的融合。

跨国互联网公司并购,如何实现统一的IT管理?

特别是涉及不同的企业文化、技术能力甚至是不同的国家法律法规上的融合,存在更多看不到的隐形成本。

近日,来自 Thought Works 高级咨询师顾宇老师,他分享了一个东南亚互联网企业并购中的 DevOps 促进并购的实施案例,即通过在 AWS 上使用 Ansible 和 Cloud Formation 作为基础设施即代码的工具实现产品架构的迁移。

本文介绍如何通过 DevOps 的基础设施即代码实践,把架构以及开发/运维实践和规则固化为配置和代码。

让所有的团队和成员能够依照同样的规则进行开发和运维;通过自动化的手段加速团队、产品和架构的融合过程,提升整个组织的技术水平。减少组织间的沟通摩擦。

跨国互联网公司并购案例

案例梗概

某企业收购了分布在泰国、马来西亚、印度尼西亚、新家坡等地的几家东南亚拥有相同业务的互联网公司。

但如何在多国家、多语言文化的情况下,进行分布式 IT 敏捷产品团队的合并、步调一致的工作和实现统一的管理成为难题。

剖析组织现状

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

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

这句话中“constrained”的意思是强制。也就是说,当系统架构与组织架构不匹配时,系统结构会被强制转化成与组织架构一致。

要做到组织架构和基础设施架构保持一致,就需要根据未来的组织结构设计系统架构,减少系统架构演进中的适应性浪费。

如下图,是合并前架构的情况:

跨国互联网公司并购,如何实现统一的IT管理?

如图中所示,每个国家的公司运营着自己的网站。其中每一公司都有一部分是用 WordPress 运营的。

虽然都是 WordPress,但应用架构和使用方式上存在着诸多的差异。我们首先是要识别出这种差异。而这种差异不仅仅是技术上的,还有组织上的。

并购并不仅仅是把团队合并到一起就能解决问题,而是要把多国、多语言、多站点,变成多国、多语言、单站点。

通过一个站点来支撑多个地区的业务,这里选择马来西亚作为这个站点进行举例。

那么,组织架构就会办成如下图所示:

跨国互联网公司并购,如何实现统一的IT管理?

当组织架构变成多国、多语言、单站点,那么所对应的就是一个 IT 团队。如图可以看到把 Dev、Ops 分开来表示,这样的组织结构和 DevOps 有什么关系呢?

这就需要了解下 DevOps 的两种组织形式:

  • Team OwnOps:团队内自有的 Ops,把 Ops 当做团队成员,实现开发和运维合作。

  • Team ShareOps:不同产品开发团队之间共享一个 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 镜像的部署和变更,应用维护关注日志的查询和操作。

写在最后

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

  • 架构迁移要为组织结构迁移服务。

  • 把自动化和基础设施即代码当做制度使用(康威定理和逆定理)。

  • 把基础设施即代码当做一个产品开发。

  • 安全的架构和架构的安全。

  • 基础设施逻辑分层。

  • 基础设施即代码本质上是一套类库,从面向对象的原则考虑基础设施的设计。

  • 构建每日可用架构。

 

 



    标签: