【.com原稿】互联网公司的并购不仅是组织架构的整合，更是产品架构和产品团队的整合。尤其是涉及到不同企业文化、技术能力甚至不同国家法律法规的融合，更多的是看不见的隐性成本。近日，由公司主办的以“TechNeo”为主题的第十六期技术沙龙在北京举行。本次活动邀请了ThoughtWorks资深顾问顾宇先生。他在东南亚互联网公司的并购中分享了一个DevOps促进并购的实施案例，即利用AWS上的Ansible和CloudFormation作为基础设施即代码工具，实现产品架构的迁移。本文介绍如何通过DevOps基础架构即代码的实践，将架构和开发/运维实践和规则固化为配置和代码。让所有团队和成员遵循相同的规则进行开发和运维；通过自动化手段加速团队、产品和架构的集成过程，提升整个组织的技术水平。减少组织间的沟通摩擦。跨国互联网公司并购案例案例概要：某公司在泰国、马来西亚、印度尼西亚、新加坡等地收购多家东南亚互联网公司，业务相同。然而，如何在多国家、多语言文化的情况下，合并分散的IT敏捷产品团队，协同工作，实现统一管理成为难题。分析组织现状，需要保留各个国家的业务团队，集中管理IT团队。首先要做的是分析组织的现状。那么，架构迁移前需要了解的组织现状是什么？》康威定律原话：设计系统的组织被约束产生设计，这些设计是这些组织通信结构的副本。这句话中的“约束”是强制性的意思。也就是说，当系统结构和组织结构不一致时匹配，系统结构将被强制与组织结构保持一致，为保持组织结构和基础设施结构的一致性，系统架构需要根据未来的组织结构进行设计，以减少系统架构演进中的适应性浪费.如下图，是合并前的情况：如图所示，每个国家的公司都运营自己的网站，每个公司都有一部分是用WordPress运营的。虽然都是Wordpress，但是在应用架构和使用上还是有很多区别的。我们的首要任务是识别这种差异。而这种差异不仅是技术上的，也是组织上的。并购不仅仅是将团队合并在一起解决问题，而是将跨国、多语言、多站点变成多国家、多语言、单一站点。为了通过一个站点支持多个区域的业务，这里选择马来西亚作为示例。然后，组织结构会做成下图这样：当组织结构变成跨国、多语言、单站点的时候，那么对应的就是一个IT团队。如图所示，Dev和Ops是分开表示的。这样的组织结构和DevOps有什么关系？这就需要了解DevOps的两种组织形式：TeamOwnOps：Ops在团队内部，以Ops为团队成员，实现开发和运维之间的协作。团队共享操作：一个操作在不同的产品开发团队之间共享。在这种情况下，Ops团队是一个平台团队。为新组织设定目标在团队合并之前，为新组织设定目标，如下：单一的产品开发团队和运维团队，由所有区域共享，由统一的产品经理协调各个区域的开发任务和业务需求。地区。每个地区都可以有自己的开发团队，但都由马来西亚开发团队管理，所有运维都由马来西亚团队支持。在所有公司建立DevOps文化和机制，从TeamOwnOps转变为TeamShareOps。提高每个国家的Dev/Ops水平。当层级达到同等水平时，可以通过DevOps这个中间桥梁打通。使用DevOps加速团队之间的合并过程。虽然IT团队来自不同的国家，分布在不同的地理位置，有着不同的文化背景，说着不同的英语方言，但每个人的技术栈都是一样的。一方面，我们通过Zoom建立了每天的在线视频会议，及时同步各个团队的状态。另一方面，我们遵守相同的开发规则。其中，测试驱动开发（TDD）在这样的分布式团队中非常重要。虽然对编程语言和技术框架有不同的理解，但自动化测试为开发者构建了一个统一的理解。这允许每个团队和每个成员设计和实施自动化测试。一方面，使用测试作为对需求的理解可以减少和减少不一致。另外，测试驱动开发可以保证代码质量，提高程序员的编码能力。另外，这里的自动化测试相当于一个代码质量标准。组织合并后，架构也会随之改变。这个时候就必须开始架构迁移了。您可以使用基础架构即代码，将自动化作为一个系统来使用，以提高整体运行效果。系统架构的迁移实践在系统架构的迁移中，需要在了解当前组织架构现状的前提下，制定架构目标和设计迁移策略。这三个方面实现之后，就可以为新的组织设计新的架构。架构要尽量设计好，设定最好的需求。不要在这里使用现有人员的能力/精力，而是计划成本。在成本规划中，不仅要考虑迁移成本，还要考虑迁移后的维护成本。这样，以最新的需求和标准，引导大家一起为一个共同的结论和方向而努力，既可以提高个人和团队的技术能力，也可以改善DevOps合作的过程，因为一个好的架构必须与多方利益相关者通过不断的沟通形成。通过不断的开发团队沟通，解决开发痛点，积极提升Ops团队的协作意识。因此，DevOps不仅仅是自动化，更是磨合和共识团队合作的价值观和工作方式。当前组织和系统架构存在的问题当组织和产品合并时，不同区域的多个系统的运维变成了单个系统的运维。因此，不再需要很多运维人员。目前的情况下，只剩下四名运维工程师，剩下的运维工程师陆续离开。运维工作由技术总监兼任。这里遇到的问题是，如何用这么少的运维人员维护大量不同技术栈/语言/业务的站点。因为产品简单，但结构复杂，运维环节和节点较多。另外，为了避免单点账户，平均每个系统至少要有三个AWS账户：开发环境、测试环境和生产环境。这样一来，三个人维护20多个账号是一种浪费，还需要进行账号整合。这三个运维人员还需要处理其他风格各异的遗留系统，因为每个国家的系统由不同的架构师领导，这对于只有三个人的运维团队来说也是一个非常大的挑战。虽然被收购公司的核心业务相似，但每个国家的现状、市场情况、用户群体都不同，所以还是需要一些本土化的定制服务。总之，系统架构存在的主要问题如下：每个国家的架构都是由不同的架构师设计的，所以会留下很多隐藏的知识，维护起来很困难。Infrastructureascode已经在一些IT组使用了，但是不太好，有很多hardcoding。在更新旧架构中的应用程序时，需要更新整个架构而不是部分更新。架构迁移的目标基于新组织的现状和旧架构存在的问题，架构迁移的目标制定如下：以基础设施即代码来管理所有基础设施，因为旧架构中的一些应用程序运行在机房裸机，需要手动安装。所有现有基础设施都迁移到云端。基础设施的管理应该是标准化的，基础设施即代码可以看作是一套规范运维人员如何操作基础设施的制度。为所有运维人员和开发工程师提供统一的接口，让他们基于基础架构即代码开发应用，进而实现局部更新而不是全部更新。实现能力和组织结构的迁移，基础设施即代码可以作为一个系统首先保证以上几点。一旦基础设施即代码成为一个系统，在实施过程中最重要的就是提升能力，即把基础设施??变成产品。如何将基础设施变成产品？首先是在不同团队复用基础设施架构经验，让不同国家、不同程序员、不同运维人员获得更安全、更稳定、更灵活的架构。二是实现高度自动化，可快速构建和定制。三是实现关注点分离，根据场景将变化缩小到一定范围内。最后，需要实现开发和各个环境之间的抽象一致性，让不同的团队可以在不同的环境之间无缝切换。架构迁移策略架构迁移有两个原则：一是变更量最少，只需简单的变更即可完成迁移；另一个是最小的影响，就是减少架构变更带来的不利影响。架构迁移的总体策略如下：按照（架构/应用/数据）封装遗留系统应用。使用基础架构即代码来构建新的架构并构建可重用的架构模型。使用该脚本实现架构/应用/数据三部分的自动化迁移。测试完成后切换总域名和子域名。两周后，遗留系统下线。除了需要手动切换域名外，这种架构策略是完全自动化的。涉及的主要技术如下：使用Ansible+Cloudformation封装构建新的基础设施。基础设施需要随时完全恢复。完整数据转储/导入，自动备份到s3。减少数据库的状态。使用Docker打包wordpress应用程序。不同的国家使用不同的主题和插件组合。使用cdn+nginx+wordpress一起做301和302重定向。区分每个角色。使用脚本进行迁移，迁移脚本分类（开发/测试/生产）管理。切换域名指向（手动）。为新的组织结构设计架构，重建组织。在确定了新组织相应架构的目标和策略后，下一步就是根据使用场景设计基础设施即代码的架构，实现整个架构的自动化构建和恢复。然后根据使用场景设计安全策略，避免人为操作，减少人为故障。谷雨老师认为基础设施就是代码，基础设施就是类和对象的关系。通过自定义模板组合不同的场景，生成不同的基础设施实例。一方面统一了架构语言，另一方面减少了未经审计的操作。另外，可以利用面向对象的原则进行逻辑分层，隔离不同场景的关注点。例如：持续交付关注Docker镜像的部署和变更，应用维护关注日志查询和运行。写在***在此案例中，使用基础架构即代码技术有几个关键点，归纳如下：架构迁移应该服务于组织架构迁移。使用自动化和基础设施作为代码作为机构（康威定理和逆向）。将基础架构视为代码作为产品开发。安全架构和架构安全。基础设施的逻辑分层。基础设施即代码本质上是一组类库，从面向对象的原则考虑基础设施的设计。构建日常可用的架构。由于文章篇幅，还有很多相关的细节，比如，就不一一列举了。想了解更多内容的开发者可以观看视频和PPT【讲师简介】ThoughtWorks高级顾问顾宇。专注于DevOps、持续交付、微服务和全功能产品团队的设计、实践、实施和体验推广。并持续在多个专业平台和媒体发表相关文章，并受邀在多个行业会议上做相关演讲。在加入ThoughtWorks之前，他参与了中国移动10086呼叫中心和中国联通省BOSS系统的研发、实施和割接工作。历任项目经理、维护经理、开发工程师等，对大型IT系统、小型机生产环境有丰富的实践经验。【原创稿件，合作网站转载请注明原作者和出处为.com】
