DevOps转型的动力我们的客户是一家知名的海外本土金融保险集团。当他们成长到一定规模后，才意识到自己就像一头沉甸甸的头大象在挣扎。通过对整个交付过程的思考和分析，他发现了以下严重影响交付速度的问题：一些关于产品改进和创新的好想法很难实施。涉及到一些遗留系统的配合：调整、部署、扩容等，导致团队对发布没有信心。新服务或应用的构建难以快速上线，停留在生产环境的部署阶段。各种应用和服务的部署方式和流程不一致。运维作为支撑部门，难以对大量团队进行快速响应。运维人员对环境中需要部署和运行的产品了解不够。微服务运行过程中，交付团队难以实现快速集成部署。运维团队不了解微服务的部署和运维，对新架构下的交付模型仍然难以适应。开发团队主要关注代码和架构，对产品如何在生产环境中稳定运行，需要考虑哪些安全和可持续性因素没有很好的了解。问题分析与挑战通过深入分析这些问题以及各个团队的反馈，发现最大的瓶颈在于交付团队与运维部门之间的各种依赖和沟通浪费，而这个瓶颈就是解决大多数问题的前提。将瓶颈可视化后（如上图所示），我们可以看到实际上两队之间有一堵墙。一是因为传统的部署流程非常繁琐，效率低下。二是因为两个角色的侧重点和目标不一致。在这样的情况下，想要实现微服务架构的转型，实现更快更安全的交付，只会更快地暴露出这堵墙带来的各种问题。在开发阶段，系统架构和依赖环境都由Developer决定，对生产环境的关注度不高。在部署和发布阶段，Operations会考虑如何构建稳定的基础设施，以及如何部署和维护开发的产品。然而，他们往往对产品、产品周围的生态以及它们与产品的关系没有足够的了解。.那么引入DevOps文化，消除开发和运维之间的壁垒，逐步打造更高效的交付流程就成了破局的关键，那么我们应该怎么做呢？改革之初，我们发现并尝试了Bimodel（双模IT），看看能不能解决我们的问题：首先简单介绍一下什么是双模IT：它将IT系统分为两种模式：一种是新型数字化、市场适应性强的IT，这部分业务侧重于新市场、新业务的开拓、创新和发展，强调IT本身对市场的高度适应性。另一种模式，我们需要稳定的发展。对于传统模式，我们倾向于使用更严谨、更规范的流程来保护现有业务。稳定性比速度更重要。我们从采用这种模式的实际案例中发现：组织内部会存在两种速度的交付过程。好的情况下，可以采用敏捷开发流程的交付线，具有快速交付能力。相反，对于继续采用传统开发流程和运维方式的团队，保持着稳定但低效的交付能力。从业内众多企业的现状和发展趋势来看，双模IT确实是很多组织的现状或者必然过程，但并不是一个好的模式。从实际交付过程来看，存在四个问题：双模IT模块化IT的划分更多是基于软件系统而不是业务活动。所有软件系统的交付都应该以商业价值为导向。双模IT会让我们误以为速度的提升会导致质量的下降，但对于我们在ThoughtWorks的众多敏捷实践中所学到的：随着交付的推进，内建质量是团队共享的重点责任和持续改进。交货速度的提高往往伴随着质量的保证，而不是忽视质量。在实际生产中，一个新的产品或功能往往依赖于许多遗留系统提供的服务。如果他们只能实现稳定和低效的交付，企业对市场的整体反应会越来越低。一个企业的创新不仅仅是从无到有创造一个新的产品，更重要的是对已有的资源有很多机会。一个新的系统和功能，往往不仅要创建新的服务和应用，还要对遗留系统进行修改、调整和改造。可见，双峰IT是在掩盖问题，避免目前最重要的问题：开发与运维之间的隔阂。感觉就像一个病人先放弃治疗，然后努力寻找延长生命的方法。一些隐患最终会爆发。构建自助式持续交付紧接着，我们以看似行不通的方式开始了DevOps转型，并成立了一个公开的DevOps团队。很多人可能会说这是一种反模式。怎么可能建一个团队专门做DevOps相关的事情呢？和以前的运维部有什么区别？DevOps所倡导的Dev和Ops高频合作的文化，是不是不可能大规模传播？因此，我们需要明确定义我们对这个团队的期望以及它的职责是什么，它如何与交付团队合作，影响交付团队，最终让DevOps文化得以广泛传播。该团队的目标是像杠杆一样提升更大的DevOps转型。因此，我们认为公共DevOps团队应该与其他端到端交付团队具有相同的组成。不同的只是目标和价值，主要体现在帮助更多团队植入DevOps文化，优化持续交付流程。最终目标是每个团队都可以自治，每个团队都可以进行端到端的开发、测试和部署，并且可以自我驱动持续改进。同时，该团队不仅为交付团队提供了基础设施、持续交付流水线、部署等活动所需的更多自动化能力，还支持交付团队根据自己的上下文定制和规划自己的持续交付流程以及部署策略等。（图片来自：http://t.cn/R9jnzHR）现在，相比于DevOps团队，我们更愿意称这个团队为Platform团队。一个原因是避免像我之前说的那样被误解，另一个原因是随着每个交付团队逐渐实现自助式持续交付，这个敬业的团队也有一个更高的目标：持续构建和优化一个能够支持的平台每个交付团队的快速交付。当时我们首先为团队定义了一种新的工作方式：以自助、自动化、协作为核心文化，希望通过提供便捷的基础服务，让交付团队拥有自动化的交付流水线，并通过更多的沟通和协作，尽可能让每个交付团队能够独立设计、创建和更改自己的基础架构。然后根据每个交付团队的实施和结果不断改进流程和服务。所以第一件事，我们先设计一个高效的持续交付流水线，让平台团队和交付团队建立联系：如下图，蓝色基因链是交付团队的持续交付环，红色基因chain平台团队的持续交付循环。两个团队全程协作，低耦合弱连接。平台团队必须在整个端到端的交付过程中尽可能构建自动化能力，以支持交付团队快速、安全地进行持续集成、部署等活动。这种合作方式也为我们提供了触点优化的可能，通过优化和改进，我们可以缩短持续交付周期，让交付更加高效。文章到达高潮还请见谅。由于考虑到大家的阅读体验，文章分为上下两部分。上半场主要讲DevOps转型的动机、策略和方法，下半场会讲我们如何实际应用基础架构即代码来建立Platform团队和交付团队之间的联系点，以及如何乘以遗留系统团队和微服务团队的交付速度。敬请关注！【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
