如下图：

·         可视化

·         拒绝碎片

·         服务与价值

·         IT系统的ERP

从交付的目标来看，一定是朝着自动化的方向去走的，这个是从IT交付链的角度来分析，也就分析出IT自动化应该覆盖的范围了，公式如下：

IT自动化 =

DevOps自动化或者持续交付自动化 +

Ops 自动化( Application Ops + Platform Ops + Infra Ops)。

为什么把 Ops 自动化独立？全都是因为 Ops 的场景非常特殊，很多是运维独立完成的，他覆盖了更多的一些运维资源、变更能力。

其中大部分能力是和研发、测试无关的，比如说应用的上线、扩容、迁移、切换;平台运维对应 PaaS ；基础设施对应 laaS 等等。

一、DevOps自动化或者持续交付

DevOps 自动化，可以认为是从应用的角度，构建一个安全、快速且可持续的变更过程，这个地方包括版本发布、升级、回滚等等，当前业界最佳标准实践是持续交付。

持续交付可以说 DevOps 的核心工程实践，也是精益企业的核心工程实践。

构建一个完整的持续交付自动化平台，需要看到完整的能力框架。

当前我在 DevOps Master 培训班讲授的持续交付课程里面，提出了以下【持续交付屋】模型：

·         目标是打造一个全自动化部署流水线，完整的整合构建实践、持续审查、测试、持续部署和反馈整个过程。

·         基于这个流水线自动化的能力目标，需要提供三大管理能力：平台管理、能力管理、管理过程等等。

a.    平台管理，需要提供标准化的持续交付平台，对应企业的每个业务提供交付流水线。可视化平台和监控平台分别是数据分析平台和监控平台，从业务质量优化和问题驱动两个层面来确保流水线的变更情况。

b.    能力管理，提供了八大能力管理，这个能力管理的成熟度水平，决定部署流水线的水平。

c.    管理过程，部署流水线打通公司部门墙，需要文化的支持、需要持续改善的机制、也需要有灰度实施的策略，从而取得突破。

二、如何打造持续交付流水线

打造持续交付流水线，我们过去的运维平台建设思维都要发生变化。过去各自独立建设的平台现状，都需要变化成以应用为中心的建设思路，

基于应用的整个生命周期的管理，才能打通整个交付过程。

很多运维在做自动化平台的时候，非常独立，忽略了早期的过程，运维应该走到前面阶段，去看如何做好系统的标准对接点。

Jenkins 那边提供提供的维度，应该自然的保留到运维的平台中来。

其实一个很强的持续交付能力，是可以量化的，是需要把这个能力直接映射到一些IT管理维度上，同时提出明确的阶梯管理要求。如下图：

三、运维 Ops 自动化

Ops 自动化的过程可以算作一个独立的过程，比如说配置管理、IaaS、PaaS 层的服务管理、应用层的运维自动化管理（迁移、容灾切换）等等，简单的应用持续部署不足以覆盖运维自动化所有。之前谈了很多，这个地方不讲了。

如何在企业里面实施一个成功的交付？是否有标准可言?

这个在一些场合不断的反复讨论,因为涉及到 DevOps 实施的问题。其实在组织里实施一个系统工程，要么顺序工程，要么并行工程。

顺序工程就是把最重要的先做了，单点突破；并行工程就是让大家都动起来，一起参与，但这个依赖全局的组织动员能力、文化、执行力等等。我建议的顺序导入路径图：

四、度量交付的指标

最后和大家一起探讨一下交付的核心度量，一个好的交付应该关注哪些指标？

•（全局/核心）Cycletime/LeadTime。

•（全局/核心）交付频率

•（全局/核心）服务恢复时长

•（全局/核心）变更失败率

这个指标也是和 DevOps 每年的规划指标是一致的，这个指标是很好精确理解的，和行业是无关的。

运维必须要关注端到端的交付能力，端到端的自动化能力需要运维对开发、测试的能力足够的了解，需要对运维平台的整体规划与设计，需要的是运维管理平台的开放和集成能力。

一定要放弃对运维自动化在工具层面上的认知，跳出之前的思维边界。面向交付是运维自动化的新思维，你同意么？（王津银原创）

如下图：

·         可视化

·         拒绝碎片

·         服务与价值

·         IT系统的ERP

从交付的目标来看，一定是朝着自动化的方向去走的，这个是从IT交付链的角度来分析，也就分析出IT自动化应该覆盖的范围了，公式如下：

IT自动化 =

DevOps自动化或者持续交付自动化 +

Ops 自动化( Application Ops + Platform Ops + Infra Ops)。

为什么把 Ops 自动化独立？全都是因为 Ops 的场景非常特殊，很多是运维独立完成的，他覆盖了更多的一些运维资源、变更能力。

其中大部分能力是和研发、测试无关的，比如说应用的上线、扩容、迁移、切换;平台运维对应 PaaS ；基础设施对应 laaS 等等。

一、DevOps自动化或者持续交付

DevOps 自动化，可以认为是从应用的角度，构建一个安全、快速且可持续的变更过程，这个地方包括版本发布、升级、回滚等等，当前业界最佳标准实践是持续交付。

持续交付可以说 DevOps 的核心工程实践，也是精益企业的核心工程实践。

构建一个完整的持续交付自动化平台，需要看到完整的能力框架。

当前我在 DevOps Master 培训班讲授的持续交付课程里面，提出了以下【持续交付屋】模型：

·         目标是打造一个全自动化部署流水线，完整的整合构建实践、持续审查、测试、持续部署和反馈整个过程。

·         基于这个流水线自动化的能力目标，需要提供三大管理能力：平台管理、能力管理、管理过程等等。

a.    平台管理，需要提供标准化的持续交付平台，对应企业的每个业务提供交付流水线。可视化平台和监控平台分别是数据分析平台和监控平台，从业务质量优化和问题驱动两个层面来确保流水线的变更情况。

b.    能力管理，提供了八大能力管理，这个能力管理的成熟度水平，决定部署流水线的水平。

c.    管理过程，部署流水线打通公司部门墙，需要文化的支持、需要持续改善的机制、也需要有灰度实施的策略，从而取得突破。

二、如何打造持续交付流水线

打造持续交付流水线，我们过去的运维平台建设思维都要发生变化。过去各自独立建设的平台现状，都需要变化成以应用为中心的建设思路，

基于应用的整个生命周期的管理，才能打通整个交付过程。

很多运维在做自动化平台的时候，非常独立，忽略了早期的过程，运维应该走到前面阶段，去看如何做好系统的标准对接点。

Jenkins 那边提供提供的维度，应该自然的保留到运维的平台中来。

其实一个很强的持续交付能力，是可以量化的，是需要把这个能力直接映射到一些IT管理维度上，同时提出明确的阶梯管理要求。如下图：

三、运维 Ops 自动化

Ops 自动化的过程可以算作一个独立的过程，比如说配置管理、IaaS、PaaS 层的服务管理、应用层的运维自动化管理（迁移、容灾切换）等等，简单的应用持续部署不足以覆盖运维自动化所有。之前谈了很多，这个地方不讲了。

如何在企业里面实施一个成功的交付？是否有标准可言?

这个在一些场合不断的反复讨论,因为涉及到 DevOps 实施的问题。其实在组织里实施一个系统工程，要么顺序工程，要么并行工程。

顺序工程就是把最重要的先做了，单点突破；并行工程就是让大家都动起来，一起参与，但这个依赖全局的组织动员能力、文化、执行力等等。我建议的顺序导入路径图：

四、度量交付的指标

最后和大家一起探讨一下交付的核心度量，一个好的交付应该关注哪些指标？

•（全局/核心）Cycletime/LeadTime。

•（全局/核心）交付频率

•（全局/核心）服务恢复时长

•（全局/核心）变更失败率

这个指标也是和 DevOps 每年的规划指标是一致的，这个指标是很好精确理解的，和行业是无关的。

运维必须要关注端到端的交付能力，端到端的自动化能力需要运维对开发、测试的能力足够的了解，需要对运维平台的整体规划与设计，需要的是运维管理平台的开放和集成能力。

一定要放弃对运维自动化在工具层面上的认知，跳出之前的思维边界。面向交付是运维自动化的新思维，你同意么？（王津银原创）