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

非常感谢您继续阅读下半部分，如果您还没有阅读上半部分，建议先去阅读以获取更多的上下文。上半部分主要讲 DevOps 转型的动机、策略和方法，本部分将会为大家带来更多 DevOps 转型的落地策略和实践。

四. 实践过程

下图是我们为团队设计的持续交付流水线，目的是让 Platform 团队和交付团队之间的触点都能够嵌入到流水线中，并以基础设施即代码的来沟通，通过自动化的方式实现开发与运维的连接。

(点击放大图像)

我们来看看我们给持续交付流水线赋予了哪些能力：

1. 站在交付团队的视角，我们决定将基础设施构建，流水线构建，部署等活动都代码化，与应用代码放在同一个代码仓库中。
2. 交付团队都通过提高自己代码到仓库后，通过持续集成工具创建流水线。
3. 接着会自动出发构建，静态检查，测试覆盖率校测，代码规范验证等任务，最终输出构建产物并将构建产物推送到仓库。
4. 然后会根据交付团队对基础设施和环境的定义去到当前要部署的网络环境中去创建或更改虚拟机、网络、存储方式等
5. 最后，当基础设施创建成功以后，就会去仓库下载指定版本的构建产物进行最终的部署活动。

但需要注意的是：

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

那我们来看看通过什么技术可以实现这样持续交付流程：

我们选择了一种轻量级、低耦合的技术组合 Ansible+Jenkins+AWS. 我认为其核心是 Ansible。

下面我们来看看 Ansible 可以帮助我们做些什么：

1. 创建和更改 AWS 中的资源
2. 自动化部署和基础设施测试
3. 建立开发与平台团队之间的沟通体系

考虑到基于 yaml 语法的 Ansible 配置简洁且易读，所有我们选择直接用它作为提供给交付团队的公有 DSL 模板，利用 Ansible Playbook 的模块化思想将开发团队的职责和平台退队的职责很清晰的分离，平台团队关注 Ansible 提供给交付团队的服务是否满足需求和 DSL 模板是否易用，而交付团队只用关注如何基于公有 DSL 去定制自己的基础设施，环境依赖和部署等。

于此同时也满足了很多开发对于 Ansible 和 AWS 的情趣和热情，更使得之后在交付团队落地变得更容易。

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

(点击放大图像)

左边是Platform 团队的仓库，这个仓库里面包含了创建基础设施、环境配置和部署的实现。

右边是交付团队的仓库，其中deployment 目录下，是公有的DSL 模板，其中有不同环境的配置和创建基础设施，部署应用的DSL。

那他们是怎么样相互知晓、相互配合的呢？

(点击放大图像)

他们会在持续集成流水线中被动态组合到一起：

1. 在创建基础设施和部署的时候会去分别拉取基础设施代码库和应用代码库。
2. 此时应用代码为调用入库，公有基础设施为功能框架库，两者配合，完场环境的创建和应用部署。

在做微服务的团队，接受度非常高，能够快速上手，而且甚至有团队因为自身的一些需求，自己去写一些 Ansible 模块，让后向我们发起 pull request。

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

1. DevOps 团队的成员由各交付团队和原运维团队组成，这样的组成方式，能够保证团队的视角可以关注到整个持续交付过程的每个环节
2. 交付团队成员与 DevOps 团队成员定期轮岗制，DevOps 小组中的文化（如自动化优先）可以蔓延开，让交付团队更快适应
3. 结对、Showcase 和培训，主要目的是知识的传递，让更多地团队逐步采用新的交付模式，得到更多改进中的反馈。
4. 提供给交付团队的自服务代码仓库对每个人开放，交付团队被授权优化、新增基础设施，让 DevOps 文化和职责落地到交付流程中

现在来看，集中式、审批式、被动响应请求的中央运维团队不再是整个交付流程中依赖和瓶颈，以基本转向带自服务化、审查式、主动优化的去中心化交付团队：

(点击放大图像)

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

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

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

整个开发和测试流程都很复杂，而且效率很低，出现问题和故障的风险也很大，如果我们直接利用 Ansible 把 AEM 的安装和部署过程都自动化，由于 AEM 本身部署的复杂性，可以预见以后这部分更新和维护的工作还是很难交由交付团队自治。所以我们第一步要做的就是为其设计新的持续交付流水线，然后在这个流程中去定义和识别两个团队的职责和关注中心，最后再通过打造高效的自服务使整个交付流程得到改进。

首先我们根据校服团队提交变更的平率，从低到高依次定义了三条持续集成流水线 (如下图)：

1. 创建和测试基础设施资源
2. 配置基础设施资源和环境
3. 部署应用程

(点击放大图像)

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

通过新的自动化持续交付流水线大大加速了AEM 团队的开发和测试速度，也使得整个环境更加可控和易维护。对于交付团队来说，他们可以自己去维护包括基础设施、环境变更和应用部署等全生命周期交付活动。对于Platform 团队来说，只用去考虑镜像的生命周期管理，如果去优化镜像的创建速度等，这些可以帮助到更多其它团队解决类似问题的领域。对于这种特殊情况，我们尽管引入很多与大多数团队不同的交付流程和技术，但所有的工作和优化都是基于之前打造的自服务持续交付流程，协议和工具平台之上的，保证了不同的交付团队与Platform 的配合方式的一致性。

五. 实践启示

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

(点击放大图像)

所有好的实践都必须考虑规模化的问题，如果无法大规模的被接受和落地，再好的实践也没用。对于咱们这个转型的过程，我也给出一个套路：（如下图）

(点击放大图像)

有了套路，接下来总结一下应用这个套路，进行 DevOps 转型过程中的一些经验和思考：

1. 易用的通用 DSL 模板设计，提供交付与 Platform 团队统一的 DSL 模板 (build and update anything)。
2. 构建通用持续交付流水框架，提供给交付团队定制化流水线的能力，使流水线主要关注点始终在产品成功的交付。
3. 以技术驱动 DevOps 文化大面积传播，让 Platform 团队成员走入交付团队，协作改进、知识传递，确保实践落地。
4. 将一切自动化、自服务化。交付团队应该被授权优化、新增基础设施服务，让 DevOps 能力和职责在交付团队落地生根。

最后，我提取了 5 点对我们来说非常重要的策略或是推进方法：

1. 小步快跑，在有大方向的基础上，需要讲每一步改变都设计得足够小，这样才能足够快的区改进。
2. 交付团队赋能，给每个人都留一扇门，在他意识到要做些事情的时候，可以很快付诸行动。
3. 逐步用基础设施自服务化替代运维部门的审批流程。
4. 建立持续反馈和改进机制。
5. 以 DevOps 团队为杠杆，撬动更大范围自服务交付。

非常感谢您的耐心阅读，希望我们的文章能够带给你哪怕一点点启示。有任何问题或是想与我讨论的点都可以给我发 Emial: jxzhong@thoughtworks.com

参考文献

1. http://martinfowler.com/bliki/BimodalIT.html Martin ,Fowler
2. https://github.com/divious1/ansible-splunk-simple
3. 《持续交付》 Jez Humble / David Farley
4. 《精益创业实战》 Ash Maurya

感谢张凯峰对本文的策划，木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。