正文
互联网企业的并购不仅是组织结构的融合，更是产品架构和产品团队的融合。
特别是涉及不同的企业文化、技术能力甚至是不同的国家法律法规上的融合，存在更多看不到的隐形成本。
近日，由 51CTO 主办的第十六期以“Tech Neo”为主题的技术沙龙在北京举行，此次活动邀请了来自 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”的意思是强制。也就是说，当系统架构与组织架构不匹配时，系统结构会被强制转化成与组织架构一致。
要做到组织架构和基础设施架构保持一致，就需要根据未来的组织结构设计系统架构，减少系统架构演进中的适应性浪费。
如下图，是合并前架构的情况：
如图中所示，每个国家的公司运营着自己的网站。其中每一公司都有一部分是用 WordPress 运营的。
虽然都是 WordPress，但应用架构和使用方式上存在着诸多的差异。我们首先是要识别出这种差异。而这种差异不仅仅是技术上的，还有组织上的。
并购并不仅仅是把团队合并到一起就能解决问题，而是要把多国、多语言、多站点，变成多国、多语言、单站点。
通过一个站点来支撑多个地区的业务，这里选择马来西亚作为这个站点进行举例。
那么，组织架构就会办成如下图所示：
当组织架构变成多国、多语言、单站点，那么所对应的就是一个 IT 团队。如图可以看到把 Dev、Ops 分开来表示，这样的组织结构和 DevOps 有什么关系呢？
这就需要了解下 DevOps 的两种组织形式：
做团队合并之前，要为新组织设立目标，如下：
单一的产品开发团队及运维团队，各地区共享，由统一的产品经理协调各地的开发任务和业务需求。
每个地区可自有开发团队，但都由马来西亚开发团队来统一管理，所有运维都由马来西亚团队来支持。
在所有公司构建 DevOps 文化及机制，从 Team Own Ops 向 Team Share Ops 变化。
提升各个国家的 Dev / Ops 水平，当水平达到一致，便可通过 DevOps 这个中间桥梁打通。
虽然 IT 团队来自不同的国家，分布在不同的地理位置，他们的文化背景不同，说着不同的英语方言，但是大家的技术栈是相同的。
一方面，我们通过 Zoom 构建起了每天的在线视频会议，及时同步各个团队之间的状况；另一方面，我们遵守着同样的开发规则。
其中，测试驱动开发（TDD）在这样的分布式团队中十分重要。虽然对编程语言和技术框架的理解不同，但是自动化测试为开发人员构建出了统一的理解。
这样就使得每个团队，每个成员去设计、实现自动化测试。一方面，用测试作为对需求的理解，减少和降低了不一致性；此外，通过测试驱动开发可以保证代码品质，进而提升程序员的编码水平。
自动化测试在这里就相当于一种代码质量的标准，组织被合并之后，架构也要随之改变，这时就要着手做架构迁移。可以用基础设施即代码把自动化作为一种制度去提升整体运行效果。
系统架构迁移要在了解当前组织架构现状的前提下，制定架构的目标、设计迁移策略。这三方面落实后，才能为新组织设计新架构。
架构要尽量设计为设定的最高要求，这里不要将就现有人员的能力/精力，但是要规划成本，成本规划里不光要考虑迁移成本，还要考虑迁移后的维护成本。
这样，有了最高的要求和标准，可以引导大家为共同的结论和方向一起努力，既可以提升个人及团队的技术能力，也是提升 DevOps 合作的过程，因为好的架构一定是和多方利益相关者在不断沟通下形成的。
通过不断的开发团队沟通，解决开发痛点，来主动提升 Ops 团队的合作意识。
所以，DevOps 不仅是自动化，更是在磨合和共识团队合作的价值观和工作方式。
当组织和产品进行合并之后，不同的地区多系统的运维就变成了单一系统的运维。
因此，很多运维人员不再被需要，在现在的案例中，仅剩四名运维工程师，剩下的运维工程师相继离职，运维工作由技术负责人兼任。
这里遇到的问题是，如此少量的运维人员，如何维护大量技术栈/语言/业务各异的站点。
因为产品简单了，但架构复杂了，运维的环节和结点更多了。此外，为了避免账户单点，平均每个系统至少要有三个 AWS 账户：开发环境、测试环境及生产环境。
这样一来，三个人维护二十多个账户是一种浪费，还需要做账户合并。
这三个运维人员还需要应对风格各异的其他遗留系统，因为每一个国家的系统都分别由不同的架构师主导，对于仅三人的运维团队来说也是非常大的挑战。
尽管收购的企业核心业务相似，但每个国家的现状、市场条件、用户群都不一样，所以仍然需要一部分本地定制化业务。
总之，在系统架构方面存在的主要问题如下：
每个国家的架构都由不同架构师设计，所以会留下很多隐藏知识，以至于维护困难。
基础设施即代码已在一些 IT 团队中被使用，却没有用好，存在很多硬编码。
旧架构在更新一个应用时，就需要把整个架构全部更新，并非部分更新。
综合当前新组织的现状与旧架构的问题，制定架构迁移目标如下：
实现用基础设施即代码管理所有的基础设施，因为旧架构还有些应用在机房裸机上运行，并且需要手动安装。
现有基础设施架构全部迁移到云上。
基础设施的管理要规范化，可以把基础设施即代码看成一套制度，用来规范运维人员如何操作基础设施。
给所有运维人员、开发工程师提供统一界面，让他们基于基础设施即代码之上进行应用开发，进而实现部分更新，而不是全部更新。
实现能力和组织结构的迁移，基础设施即代码首先作为一个制度可保证以上几点。基础设施即代码一旦作为制度，在执行的过程中，要做到的最后一点就是能力的提升，即把基础设施变成一种产品。
如何把基础设施变成一种产品？步骤如下：
把基础设施架构经验在不同团队中复用，让不同国家、程序员、运维人员获得更安全，更稳定，更灵活的架构。
实现高度自动化，可以快速建设和定制。
要做到关注点分离，根据场景把变更缩小在一定的范围里。
要把开发和各环境做到抽象一致性，便于不同团队能够在不同环境中做到无缝切换。
架构迁移有两大原则：
架构迁移的整个策略如下：
此架构策略除需要手动切换域名之外，其余全部实现自动化。
主要涉及技术如下：
用 Ansible + Cloudformation 封装并构造新的基础设施。基础设施要能做到随时可以完全恢复。
全量数据 dump / import，自动化备份到 s3 上，减少数据库的状态。
用 Docker 封装 wordpress 应用。不同的国家用不同的主题和插件组合完成。
用 cdn + nginx + wordpress 共同做 301、302 跳转，要为每个角色做好区分。
用脚本做迁移，迁移脚本分类（开发/测试/生产）管理。
切换域名指向（手动）。
对组织进行重建，确定新组织对应架构的目标和策略之后，紧接着就是根据使用场景，设计基础设施即代码的架构，实现整个架构自动的搭建和还原。然后，根据使用场景设计安全策略，避免人为操作，减少人为故障。
顾宇老师认为，基础设施即代码和基础设施是类和对象的关系。通过定制化的模板结合不同的场景产生不同的基础设施实例。
一方面统一了架构语言；另一方面减少了不经审计的认为操作。此外，可以采用面向对象原则进行逻辑分层，隔离不同场景的关注点。
例如：持续交付关注 Docker 镜像的部署和变更，应用维护关注日志的查询和操作。
在该案例中，利用基础设施即代码技术有几个关键要点，总结如下：
由于篇幅原因，还有众多相关细节没有一一纳入文章中，想要了解更过内容的开发者，可点击“阅读原文”查看视频与“回复关键词”下载PPT。
微信后台回复关键词“并购”，即可下载完整版PPT资料
作者：王雪燕
编辑：陶家龙、孙淑娟
投稿：有投稿、寻求报道意向技术人请联络 [email protected]
顾宇，ThoughtWorks 高级咨询师。专注于 DevOps、持续交付，微服务以及全功能产品团队的设计、实践、落地以及经验推广。并持续在多个专业平台和媒体发表相关文章，受多个行业大会邀请发表相关演讲。在加入 ThoughtWorks 之前，曾经参与中国移动 10086 呼叫中心以及中国联通省级 BOSS 系统的研发、实施和割接。任项目经理，维护经理，开发工程师等职务，拥有丰富的大型 IT 系统小型机生产环境实战经验。
程序员如何不被淘汰？一定要看11月的这十篇热门文章！
IT运维笔记：操着卖白粉的心，赚着卖白菜的钱！
从“菜鸟”码农到“资深”架构师，我到底经历了什么？
