本文是上一篇文章【DevOps运维】构建面向应用的运维管理新思维的延续。很早以前我就提到运维的本质其实就是交付。没有做到面向用户的交付不是好的运维，IT也不是好的IT。如下图所示：从交付目标来看，视觉上拒绝碎片化服务和价值IT系统的ERP必须走向自动化的方向。这是从IT交付链的角度来分析的，也就是说IT自动化应该覆盖范围公式如下：IT自动化=DevOps自动化或者持续交付自动化+Ops自动化（ApplicationOps+PlatformOps+InfraOps）.为什么要独立于Ops自动化？都是因为Ops的场景很特殊，很多都是运维独立完成的。它涵盖了更多的运维资源和变更能力，其中大部分与研发和测试无关，比如谈谈应用的上线、扩展、迁移和切换；平台运维对应PaaS；基础设施对应IaaS等。1.DevOps自动化或持续交付DevOps自动化可以认为是从应用的角度构建一个安全、快速和可持续的变更过程。这个地方包括版本发布、升级、回滚等，目前行业标准的做法是持续交付。持续交付可以说是DevOps的核心工程实践，也是精益企业的核心工程实践。构建一个完整的持续交付自动化平台，需要看到一个完整的能力框架。目前，在我在DevOpsMaster培训班讲授的持续交付课程中，我提出了如下的【ContinuousDeliveryHouse】模型：目标是创建一个完全自动化的部署流水线，它完全整合了构建实践的全过程，持续审查、测试、持续部署和反馈。基于流水线自动化这一能力目标，需要提供三种管理能力：平台管理、能力管理、管理流程等。在平台管理部分，需要提供一个标准化的持续交付平台，提供与企业各个业务对应的交付流水线。可视化平台和监控平台分别是数据分析平台和监控平台，从业务质量优化和问题驱动两个层面保障流水线的变化。容量管理。提供八种能力管理，这种能力管理的成熟度决定了部署流水线的等级。管理流程。部署流水线突破公司部门墙需要文化支撑，需要持续改进的机制，需要灰度实施策略才能实现突破。构建持续交付流水线，我们之前构建运维平台的思路会发生变化。以往平台独立建设的现状需要转变为以应用为中心的建设思路。详见【DevOps运维】构建面向应用的运维管理新思维。基于对应用全生命周期的管理，打通整个交付流程。很多运维在做自动化平台的时候非常独立，忽略了前期的流程。运维要走到前期，看如何做好系统的标准连接点。Jenkins提供的维度应该自然保留在运维平台中。事实上，强大的持续交付能力是可以量化的。需要将这种能力直接映射到一些IT管理维度上，同时提出明确的分级管理要求。如下图所示：2.运维Ops自动化Ops自动化的过程可以看作是一个独立的过程，如配置管理、IaaS、PaaS层服务管理、应用层运维自动化管理（迁移、灾难）恢复切换）等，简单的应用持续部署不足以覆盖所有的运维自动化。之前讲过很多，这里就不讲了。企业如何实施成功交付？有标准吗？这个在一些场合被反复讨论过，因为涉及到DevOps的实现。事实上，在组织中实施系统工程要么是顺序工程，要么是并行工程。时序工程是先做最重要的事情，单点突破；并行工程是让大家一起行动，一起参与，但这要看组织的整体动员能力、文化、执行力等。序列导入路径图我建议：***一起来讨论交付的核心指标。好的交付应该关注哪些指标？（全球/核心）周期时间/交货时间。（全球/核心）交付频率（全球/核心）服务恢复时间（全球/核心）变更失败率该指标也与DevOps年度规划指标一致。这个指标很好理解，与行业无关。运维必须关注端到端的交付能力。端到端的自动化能力要求运维对开发测试能力有足够的了解，对运维平台进行统筹规划设计，对开放开放的运维管理平台。整合能力。我们必须放弃工具层面对运维自动化的认知，跳出以往的思维边界。【本文为专栏作家“王金银”原创稿件，转载请注明出处】点此阅读更多该作者好文
