DevOps实践之打造自服务持续交付

adminlily · 发表于 2018-10-17 16:07:00

本帖最后由 adminlily 于 2018-10-17 16:12 编辑

导读：本案例讲述ThoughtWorks用三年时间成功帮助某大型金融组织植入ITILxf.com" target="_blank" class="relatedlink">DevOps实践与工作流程，并形成快速反馈、持续改进的组织文化，使团队能够快速适应市场变化、解决突然事故、创造客户价值。整个过程以技术与工作流程为驱动，反过来去撬动部门之间和团队之间的沟通和工作方式，打通运维、安全等公有团队与各个交付团队之间的高速通道，保证从需求分析阶段到软件最终上线的整个开发测试部署过程中，所有相关人员目标一致、快速反馈、最小化浪费。

在这个变革的过程中，从人、团队、技术、架构等各个层面入手，尝试了不同的策略和实践，帮助在稳定交付的基础之上，逐步适应新的基于DevOps的交付流程，形成高效的自动化交付文化和自治团队。

此案例涉及到了大型传统组织向敏捷转型过程中的：DevOps文化的导入、交付流程的定义和实施、跨部门合作、团队职能优化、持续交付流程和工具等应用在软件交付的实际场景中的成功实践，会带给很多正在进行敏捷和DevOps转型的企业和团队一些借鉴和启发。

（全文共4672字预计阅读时长：5分钟）

DevOps转型的动机

本案例的客户是一家海外本土最大的金融保险集团，总资产1000亿美元，旗下拥有银行、保险、寿险等业务线和20多个市场品牌。

发展到一定规模以后，他们意识到自己就像一头笨重的大象，举步维艰，面临着来自外部和内部的双重压力和挑战：

外部：

● 市场竞争白热化，深处开放性的金融市场；

● 产品创新乏力，好的想法落地成本高。

内部：

● 组织机构庞杂，业务冗余，效率低下。

● 人员成长遇到瓶颈，人才流失严重。

基于这些压力和挑战，以及对整个交付流程的思考分析，我们发现了一些严重影响交付速度的问题：

关于产品的好的想法很难落地

● 涉及到遗留系统的配置：调整、部署、扩展等，团队对发布没有信心；

● 新服务或应用的构建很难快速上线，卡在了生产环境部署阶段。

不同种类应用、服务的部署方式和流程不一致

● 运维作为支持部门，很难同时为大量团队提供快速反应和高效的服务。

微服务践行过程中，交付团队难以做到快速集成和部署

● 运维团队对微服务的部署运维方式不理解，依旧旧瓶装新药，很难适配新架构下的交付模式。

问题分析和挑战

通过对上述问题及各个团队反馈的深入分析，我们发现最大的瓶颈是交付团队与运维部门之间的依赖和沟通浪费，两种团队之间有一堵无形的墙，造成这种情况的原因有两个：

● 一是因为传统的部署流程非常繁琐和低效；

● 二是因为两种角色的关注点和目标不一致。

在这样的情况下想实现微服务架构转型，实现更快速和安全的交付，只会更快地暴露出这堵墙引起的各种问题，如图1所示。

● 开发阶段，系统的架构和依赖环境都是Developer说了算，对生产环境的关注度不高。

● 部署、发布阶段，Operations会考虑如何构建一套稳定的基础设施来部署和运维开发的产物，但是对于产物的了解不充分，对于产物的周边生态和它们之间的关系的了解也不够。

图1 问题和挑战分析

在这种状态下，引入DevOps文化、打造更高效的交付流程才是我们破局的关键。那我们具体应该怎么做？

当时有一个方案进入了我们的眼帘：Bimodel(双模IT)，什么是双模IT呢？

图2 双模IT

如图2所示，简单来说它将IT系统分成了两种模式：

● 一种是新型的数字化、高市场适应性的IT，聚焦企业新市场和业务的开拓、创新、发展，强调IT自身对于市场的高适应力。

● 另外一种模式则强调稳固发展，对于传统模式而言，稳定性比速度更为重要，因此我们倾向于用更加严谨和标准的流程去保护现有业务。

相应的在组织内部并存着两种速度的交付流程：采用敏捷开发流程的交付线，有着快速的交付能力；继续采用传统开发流程和运维方式的团队则保持着稳定且低效的交付能力。

图3 双模IT方案分析

通过验证，双模IT确实是很多组织存在的现状或必然经历的过程，但这并不是一个好的模式，如图3所示，从实际的交付来看：

● 双模IT的划分更多是基于软件系统，而不是从业务活动出发进行的，所有软件系统的交付都应该是面向价值的。

● 双模IT会让人误以为速度的提升会引起质量的下降，而敏捷实践的案例证明：随着交付的推进，质量内建是团队共同负责和持续改进的重点。提升交付速度的同时，不能忽视质量的保障。

● 实际生产过程中，一个新的产品或功能往往会依赖很多遗留系统提供的服务。

● 企业的创新不只是从零创造一个新的产品，还有很多是基于现有的资源。

由此看来，一个新的系统和功能往往既涉及新服务、应用的创建，也涉及遗留系统的修改、调整和改造。

而双模IT以一种试图掩盖问题的方式来逃避目前最重要的问题，那就是开发和运维之前的壁垒。

打造自服务持续交付

图4 打造自服务持续交付

如图4，我们采用了一种看似不可行的方式开启DevOps转型， ——建立公有DevOps团队。

很多人说这是一种反模式，怎么可能有一个团队专做DevOps相关的事情，这和之前的运维部门有什么区别？DevOps提倡的Dev与Ops高频度合作的文化怎么大面积传播？

因此我们需要明确定义这个团队的职责，它怎样和交付团队合作并影响交付团队，以及如何让DevOps的文化得到大面积传播，也就是他要像杠杆一样，翘起更大面积的DevOps转变。

我们认为这个团队要像其他交付团队一样，不同的是其目标和价值。主要体其主要价值在于帮助更多团队植入DevOps文化、优化持续交付流程，最终达到的目标是每个团队都可以自治、每个团队都可以实现端到端的开发、测试和部署，并自驱动持续改进。

同时，这个团队不仅为交付团队提供更多涉及基础设施、持续交付流水线、部署等活动所需的能力，还要支撑交付团队根据自身上下文定制和规划自己的持续交付流程和部署策略等。

相比于DevOps团队的称号，我们更愿意称呼这个团队为Platform团队，原因之一是避免被错误理解，还有另一个原因是随着各个交付团队逐步实现自服务持续交付，这个专有团队也有了更高的目标：持续打造和优化一个能够支持各交付团队快速交付的平台。

为实现这一更高目标，我们为团队定义了新的工作方式，以自服务、自动化和协作为核心文化，希望团队通过提供便捷的基础服务，让交付团队拥有自动化的交付流水线，并通过更多的沟通协作，尽可能让每个交付团队都能够独立设计、创建和更改自己的基础设施。然后再根据各个交付团队的实施情况和结果对流程和服务持续改进。

对于设计一个高效的持续交付流水线（图5），定义团队怎样和交付团队协作是我们做的第一件事情：

● 站在交付团队的视角，我们决定将基础设施构建、流水线构建、部署等活动都代码化，与应用代码放在同一个代码仓库中。

● 交付团队提交代码到仓库后，通过持续集成工具创建流水线。

● 接着自动出发构建、静态检查、测试覆盖率校测、代码规范验证等任务，最终输出构建产物并将构建产物推送到仓库。

● 然后根据交付团队对基础设施和环境的定义到当前要部署的网络环境中去创建或更改虚拟机、网络、存储方式等。

● 当基础设施创建成功以后，就会去仓库下载指定版本的构建产物进行最终的部署活动。

图5 设计持续交付流水线

这个过程中需要注意的是：

为了持续优化交付流程，我们对开发的许多活动进行数据收集和分析，以报表的形式展示代码提交频率、系统和代码的质量情况、缺陷和构建情况等，帮助团队找到自己的瓶颈或问题、实施监控自己应用的运行状态、设计和查看维护的日志等。

那主要通过什么技术来实现这样的持续交付流程呢？我们选择了一种轻量级、低耦合的技术组合Ansible+Jenkins+AWS. 其核心是Ansible。

我们用Ansible做了三件事：

● 创建和更改AWS中的资源

● 自动化部署和基础设施测试

● 建立开发与平台团队之间的沟通体系

基于yaml语法的Ansible配置简洁且易读，如图6，所以我们选择直接用它作为提供给交付团队的公有DSL模板，利用Ansible

Playbook的模块化思想将开发团队和平台团队的职责进行清晰地分离，平台团队关注Ansible提供给交付团队的服务是否满足需求和DSL模板是否易用，而交付团队只用关注如何基于公有DSL去定制自己的基础设施、环境依赖和部署等。

这满足了很多开发对Ansible和AWS的喜好，也使得之后在交付团队中的落地变得更容易。

图6 Ansible配置

接下来通过一个实例来看：

如图7，左边是Platform团队的仓库，这个仓库里包含了创建基础设施、环境配置和部署的实现。右边是交付团队的仓库，deployment目录下是公有的DSL模板，其中有不同环境的配置和创建基础设施、部署应用的DSL。

图7 技术驱动Devops落地

那他们是怎样相互知晓和配合的呢？他们会在持续集成流水线中被动态组合到一起：

● 在创建基础设施和部署的时候会分别拉取基础设施代码库和应用代码库；

● 此时应用代码为调用入库，公有基础设施为功能框架库，两者配合，完成环境的创建和应用部署。

我们在做微服务的团队中进行试点，发现大家的接受度非常高，能够快速上手，甚至有团队因为自身的需求，自己去写一些Ansible模块，然后向我们发起pull request.

在推广这套流程的过程中我们发现，一些实践能够帮助我们更快速落地：

DevOps团队的成员由各交付团队和原运维团队组成。

) x* ?' o A9 [* l; P9 O! q; g

这样的组成方式保证团队的视角可以关注到整个持续交付过程的每个环节。

应用团队成员与DevOps团队成员实行定期轮岗制。
* a7 }7 z2 c6 `5 Q1 l c9 [

DevOps小组中的文化（如自动化优先）可以蔓延开，让交付团队更快适应。

结对、Showcase和培训。
' a" k2 g' k. h3 ]# n/ |

主要目的是知识的传递，让更多的团队使用新的模式，得到更多改进的反馈。

提供给交付团队的自服务代码仓库对每个人开放。
, Q) `0 I [: N& N( G

交付团队被授权优化、新增基础设施，让DevOps文化和职责落地到交付团队。

曾作为整个支付流程依赖和瓶颈的集中式、审批式、被动响应请求的中央运维团队已基本转向自服务化、审查式、主动优化的去中心化交付团队，如图8所示。

图8 转向去中心化交付团队

通过技术驱动的改进，团队之间的合作方式发生了巨大改变，开发与运维之间的那堵墙也渐渐消失了，以前被动响应请求的中央运维团队逐步被平台团队所替代。平台团队中一部分人负责基础设施平台的发展，公有云与企业内部系统的对接、完善安全、灾备、提供基础设施的自服务机制；另一部分人为产品团队提供可定制的工作、平台、并为产品团队赋能。这时交付团队开始管理自己的环境、维护流水线、负责生产环境变更。

在推广和落地自服务持续交付流程的过程中，也有很多遗留系统和复杂部署应用的交付团队无法直接对接这套流程。

例如有一个40-50人的团队，其职能是基于AEM开发整个公司所有的前端门户，AEM是Adobe公司的CMS系统，安装和部署很复杂，以前都是通过手工安装和拷贝的方式进行部署，而且在开发-》测试-》部署阶段可能会动态扩张多套环境来支持，且每次代码变更的提交都会对已经安装的AEM进行修改、配置、重启等操作。

整个开发和测试流程很复杂，而且效率很低，出现问题和故障的风险也很大。由于AEM本身部署的复杂性，如果我们直接利用Ansible把AEM的安装和部署过程都自动化，可以预见以后这部分更新和维护的工作还是很难交由交付团队自治。

如图9，我们第一步要做的就是为其设计新的持续交付流水线，然后在这个流程中定义和识别两个团队的职责和关注中心，最后再通过打造高效的自服务使整个交付流程畅通无阻。

首先我们根据交付团队提交变更的频率，从低到高依次定义了三条持续集成流水线：

● 创建和测试基础设施资源

● 配置基础设施资源

● 部署应用程序

图9 复杂遗留系统自服务交付落地

因为AEM的安装很复杂，所以我们引入了镜像技术，基础设施和基础设施配置两条流水线的产物为一个image，应用流水线在部署阶段会去检查是否存在新的环境镜像，如果存在，就创建一个新的AEM环境，然后进行应用代码的部署。

通过这种新的自动化持续交付流水线大大加速了AEM团队的开发和测试速度，也使得整个环境更加可控和易维护。

对于交付团队来说，他们可以自己维护包括基础设施、环境变更和应用部署等在内的全生命周期交付活动。

对于Platform团队来说，只用考虑镜像的生命周期管理，以及如何优化镜像的创建速度等，这些可以帮助到更多其它团队解决类似问题的领域。

尽管对于这样有着特殊情况的团队，我们引入了很多与大多数团队不同的交付流程和技术，但所有的工作和优化都是基于之前打造的自服务持续交付流程之上的，保证了不同的交付团队与Platform的配合方式的一致性。

案例启示

通过在大量交付团队落地基于自服务的持续交付流程，我们更加清晰了两种团队的职责，如图10所示：

图10 两种团队的职责

实践过程抽象如图11：

图11 实践过程抽象

案例启示：

● 易用的通用DSL模板设计：提供交付统一的DSL模板，build and update anything。

● 通用持续交付流水线框架：提供给交付团队定制化流水线的能力，关注点始终在产品交付。

● 以技术驱动DevOps文化大面积传播：让DevOps团队成员走入交付团队，协作改进，知识传递，实践落地。

● 将一切自动化、自服务化：交付团队被授权优化、新增基础设施，让DevOps文化和职责落地到交付团队。

成功要点：

● 小步快跑；

● 交付团队赋能：

● 逐步用公有基础设施的自服务化替代运维部门的审批流程；

● 建立持续反馈和改进机制；

● 以Platform（DevOps）团队为杠杆，撬动更大范围自服务交付文化。

原创：钟健鑫

帐号		自动登录	找回密码
密码			立即注册