本篇是上一篇的延续。很早之前，我提到过，运维的本质其实是在做交付，没有做到面向用户的交付，不是好运维，IT也不是一个好IT。如下图：
- 可视化
- 拒绝碎片
- 服务与价值
- IT系统的ERP
从交付的目标来看，一定是朝着自动化的方向去走的，这个是从IT交付链的角度来分析，也就分析出IT自动化应该覆盖的范围了，公式如下：
IT自动化=DevOps自动化或者持续交付自动化 Ops自动化(Application Ops Platform Ops Infra Ops)。
为什么把Ops自动化独立？全都是因为Ops的场景非常特殊，很多是运维独立完成的，他覆盖了更多的一些运维资源、变更能力，其中大部分能力是和研发、测试无关的，比如说应用的上线、扩容、迁移、切换;平台运维对应paas；基础设施对应IaaS等等。
- DevOps自动化或者持续交付
DevOps自动化，可以认为是从应用的角度，构建一个安全、快速且可持续的变更过程，这个地方包括版本发布、升级、回滚等等，当前业界最佳标准实践是持续交付。持续交付可以说DevOps的核心工程实践，也是精益企业的核心工程实践。
构建一个完整的持续交付自动化平台，需要看到完整的能力框架。当前我在DevOps Master培训班讲授的持续交付课程里面，提出了以下【持续交付屋】模型：
- 目标是打造一个全自动化部署流水线，完整的整合构建实践、持续审查、测试、持续部署和反馈整个过程。
- 基于这个流水线自动化的能力目标，需要提供三大管理能力：平台管理、能力管理、管理过程等等。
- 在平台管理部分，需要提供标准化的持续交付平台，对应企业的每个业务提供交付流水线。可视化平台和监控平台分别是数据分析平台和监控平台，从业务质量优化和问题驱动两个层面来确保流水线的变更情况。
- 能力管理。提供了八大能力管理，这个能力管理的成熟度水平，决定部署流水线的水平。
- 管理过程。部署流水线打通公司部门墙，需要文化的支持、需要持续改善的机制、也需要有灰度实施的策略，从而取得突破。
打造持续交付流水线，我们过去的运维平台建设思维都要发生变化。过去各自独立建设的平台现状，都需要变化成以应用为中心的建设思路，详见【DevOps运维】构建面向应用的运维管理新思维。基于应用的整个生命周期的管理，才能打通整个交付过程。
很多运维在做自动化平台的时候，非常独立，忽略了早期的过程，运维应该走到前面阶段，去看如何做好系统的标准对接点。Jenkins那边提供提供的维度，应该自然的保留到运维的平台中来。
其实一个很强的持续交付能力，是可以量化的，是需要把这个能力直接映射到一些IT管理维度上，同时提出明确的阶梯管理要求。如下图：
- 运维Ops自动化
Ops自动化的过程可以算作一个独立的过程，比如说配置管理、IaaS、PaaS层的服务管理、应用层的运维自动化管理（迁移、容灾切换）等等，简单的应用持续部署不足以覆盖运维自动化所有。之前谈了很多，这个地方不讲了。
如何在企业里面实施一个成功的交付？是否有标准可言?
这个在一些场合不断的反复讨论,因为涉及到DevOps实施的问题。其实在组织里实施一个系统工程，要么顺序工程，要么并行工程。顺序工程就是把最重要的先做了，单点突破；并行工程就是让大家都动起来，一起参与，但这个依赖全局的组织动员能力、文化、执行力等等。我建议的顺序导入路径图：
最后和大家一起探讨一下交付的核心度量，一个好的交付应该关注哪些指标？
•（全局/核心）Cycletime/LeadTime。
•（全局/核心）交付频率
•（全局/核心）服务恢复时长
•（全局/核心）变更失败率
这个指标也是和DevOps 每年的规划指标是一致的，这个指标是很好精确理解的，和行业是无关的。
运维必须要关注端到端的交付能力，端到端的自动化能力需要运维对开发、测试的能力足够的了解，需要对运维平台的整体规划与设计，需要的是运维管理平台的开放和集成能力。一定要放弃对运维自动化在工具层面上的认知，跳出之前的思维边界。面向交付是运维自动化的新思维，你同意么？
