DevOps开发运维的一套方法论。这边文章主要借鉴万达的DevOps的建设过程。谈谈DevOps主要解决那些问题和怎么解决。

DevOps的是一种IT项目开发管理方法论，它旨在提供全面的持续集成、持续交付等能力，并持在续进行过程度量和改进，不断提升 IT 运行效率。

问题背景：

传统的管理方式很难高效率、高质量的进行管理和把控较多的的产品线和项目，人肉运维成本越来越高。并且随着虚拟化、容器云、微服务等技术的发展，应用底层的运行环境愈发多样化，物理机、虚拟机、容器云三种异构环境、移动应用、Springboot 应用、纯前端应用等数十个异构应用都需要通过一个平台进行统一的部署和管理。

DevOps 达成的目标：

1.通过 DevOps 平台统一管理所有产品、项目，对团队、对人能进行数字化的考核。

1. 实现所有应用的持续集成、100% 自动化部署，提升应用的软件交付效率。

如何实施：

从逻辑上把 DevOps 平台划分为三大领域：敏捷过程、持续交付、持续改进。

敏捷过程针对于软件过程进行管理，包括产品、项目、团队、计划、任务等，持续交付则关注从需求到上线交付的管理，包括持续集成、自动化测试、自动化部署、交付流水线等。持续改进则体现了平台的核心价值，不断的度量和优化软件过程，为提升 IT 运行效率打下坚实的基础

在上面三大领域的基础上，又做了一些模块拆分，平台的逻辑架构如下：

DevOps 平台划分为领域层、基础服务层、工具层三层。工具层封装了一些开源工具，提供基础能力。服务层在此基础上封装的一些基础服务，如编译、部署、代码管理等。领域层主要包括项目管理、产品管理、构建、部署、交付流水线、度量优化等模块。底层运行环境支撑物理机、虚拟机、容器云平台。

产品管理& 项目管理

软件的整个生命周期可以从不仅仅是项目的生命周期，而是应该也包括了产品的生命周期。在企业内部，通常我们先决定做哪个产品，然后需求调研、版本划分，确认了具体版本要实现的需求范围后，便可以组建项目进行研发。研发完成进行交付后，有进入产品的线上运营阶段。直至产品下线。一个产品可以对应多个项目，当然，对于有些企业而言，一个项目也是持续稳定的维护一个产品。

持续集成

持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中，DevOps 平台将构建任务分成了四种类型：

• 编译类任务：Maven、Ant、Gradle、纯前端构建等

• 测试类任务：Sonarqube、Jmeter、Selenium等

• 打包类任务：Npm、Archive、Docker 等

• 其他工具类任务：Copyfile、Shell、介质提交到Nexus 仓库、介质上传二方库等。

在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤编排，组装成一个完整构建流程。代码提交时触发构建（支持 gitlab、github、svn 等常用代码库版本管理工具）、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。

自动化部署

在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：设计、转换、运维。

设计阶段： 将部署架构分为三层：部署装配（Assembly）、部署容器（Platform）、部署组件 (Component)。部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。

转换阶段： 将部署架构与部署策略（全新、蓝绿、灰度、滚动升级等）、资源（具体资源如物理机、虚拟机、容器）、组件配置参数（端口号、JVM 参数、健康检查 url 等）进行结合，生成部署计划，一键执行自动化部署。

运维阶段： 对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等。

持续交付流水线

为什么需要持续交付流水线？举个例子来说，我们常常苦恼最终上线版本和系统集成测试环境不一致。这一般是因为在系统集成测试完成后发现了问题，作了代码变更但没有重新构建，而是直接在介质里进行了调整进而发布上线。在持续交付流水线中是不允许这种情况出现的。所有上线入口一定是最初的构建，所有的后续产物都是基于这一介质，如果有变更必须重走流程。这样可以保证发布的安全性和统一性，线上出现问题也是可以追溯的。当然过程中的环境可以配置人工介入或自动执行。

发布流水线从构建到生产部署共 9 大环节，涵盖 SIT/UAT/LAB/PROD 四大环境。驱动了开发、测试、质量、运维等多个角色的协作。

在设计流水线能力时，我们主要考虑到几点：

• 结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置

• 流程的每一个环节都要支持自动执行的配置

• 流程中每个环节的属性和配置信息可以自定义，灵活扩展

• 流程以构建开始，让 buildNumber 贯穿整个流程，方便追根溯源

• 要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是 SIT 还是 UAT，结果如何

• 要有一个看板，直观的看到每个环境下，有哪些介质在运行

以这些为基础准则，我们底层基于了我们的 BPS 流程引擎，支撑流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。整个流水线从构建开始，保证全局介质唯一，避免人为修改介质导致的生产介质不可追溯。

在交付看板上，环境看板和发布看板如下

度量优化

精益运营的基础是度量，度量的三大维度：指标、执行监控、预测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当 DevOps 平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug 燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。

难点1：统一流程和规范

回顾一下前文的发布流水线的介绍，其实这其中我们在介绍时省略了大量的细节。比如，在开始构建时是否要打一个 Tag，此时针对构建介质产物是否不应该是 snapshot 版本，而应该是 Stage 预发版本。如果 UAT 等测试通过之后，这个介质版本即为可发布版本，此时介质需要转移到 Release 版本的介质仓库。这就是一个完整的流程，也是需要加入到规范中去的。

梳理企业的流程和规范是企业建设 DevOps 的前提，甚至即使不建设 DevOps 平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的 DevOps 平台，否则到最后，有可能会让 DevOps 平台脱离实际，导致没有人会去使用。

我们在建设过程中，每一个模块都需要结合万达的流程规范以及我们的最佳实践共同进行建设，在前期，当一些流程规范不是那么明确的时候，还需要一起讨论，同时规范也不是一蹴而就的，实施过程中发现一些不合适的地方就需要进行修改，这也就带来了需求的反复的可能。以持续交付流水线为例，这个就需要结合万达的环境、发布规范来定制流程，对于其他企业而言，持续交付流水线未必就是这样的一个流程，有可能会少一些环境，也有可能多个预发环境，又或者会把这一个流水线拆分成多个流水线。

难点 2：异构兼容

对于应用运行环境而言，需要同时支撑物理机、虚拟机、容器云、Android 设备、IOS 设备多种类型的环境。而应用本身又分为纯前端应用、SpringBoot 应用（Fat JAR）、传统应用（WAR）、Android、IOS 等各种类型。这就对自动化部署框架提出了很高的要求，一套架构要能同时支撑异构应用部署在异构环境上。

以移动应用的自动化部署为例，os 部署组件可以用来区分系统、computer 可以用于校验机型。选择部署资源时，从 cmdb 中导出项目的移动设备资源，最后将应用自动化部署到移动设备上。

难点 3：职能切面

DevOps 平台建设之前，企业可能已经有不少系统了，比如云资源管理平台、容器云云平台、自动化测试平台、统一监控平台等等。那么很多时候一个困难点就在于 DevOps 的定位了，在测试的能力上，DevOps 平台要不要完整的把测试的能力都管理起来呢？在自动化部署的时候，要不要直接创建虚拟机对资源进行操作呢？我们在万达落地 DevOps 的过程中，也遇到了这些问题。我们认为：

• DevOps 无法让每个人的工作都在上面，高级能力还是专人在专业系统上完成；

• 如果专业系统足够自动和自助化，可考虑逐步纳入 DevOps 平台

• 我们做的是工程效率平台，不是给多个系统做个统一门户

本着这些理念，我们就明确了对职能的切分。像对底层资源的管理，是统一通过 CMDB 进行管理，DevOps 只是进行资源的申请与使用。在测试环节，则是对接自动化测试平台，将持续交付流水线中的测试环节拉起来，保障整个流水线的完整。在对已部署应用的监控，可以对接企业的统一监控平台进行健康监控。