devops前提条件：如何做好运维标准化与流程化建设

内容导航：

devops前提条件：如何做好运维标准化与流程化建设

DevOps究竟是如何改变开发和运维人员的？

如何实现DevOps？

大型企业实施 DevOps 的三个阶段

一、devops前提条件：如何做好运维标准化与流程化建设

概述

最近更多在思考：运维标准化与流程化建设这方面，还没有整理好一个大概的思路，下面先介绍一些理解方面，后面再补全这块。

当下企业很多都热衷于建设运维自动化、智能化，通过技术革新代替繁杂的手工运维，提高生产效率的同时最大程度的减少人为失误。但是如何建设自动化运维，在不同的企业有着不同的建设方法和技术栈，虽然大多是以Python为主。一般说来，企业的运维发展由起步到成熟，大致要经过三个大阶段：运维无序化、运维标准化和流程化、运维自动化。

运维无序化主要表现在运维工作无规范统一，更多是团队成员依赖自身技术各自为战，着重于眼前运维工作，过多处于被迫接受和疲惫应付工作的状态。运维无序阶段提升工作效率主要依赖加人和加班，而且此阶段运维工作效率低下，人为失误较多，故障排除难度较大。长时间的运维无序化，对内团队成员极度疲惫和不自信，对外主要表现为不再被各业务部门和其他IT兄弟团队所信任。一般创业初期的IT运维处于无序化较多，如何解决结束无序化的苦恼，解放生产力呢？答案更多被提及的是运维自动化。然而面对众说纷纭的运维自动化平台，如何结合自身条件进行落地实现呢？不管哪种方式，运维标准化和流程化一定是首先要做的，否则运维自动化只能是空中楼阁，欲求不得。

什么是运维标准化和流程化呢？如果非要给出定义的话，那么我的理解是两个字：文档。

运维的标准化和流程化首先要以文档的形式进行展示，并且能够指导日常运维工作。国有国法，家有家规，冰箱洗衣机都有说明书，运维标准化流程化就是运维工作的国法家规，运维工作如何进行的说明书。相比开发、测试等其他岗位，运维工作直面生产环境，每一步运维操作与生产系统能否正常运行息息相关，稍有不慎就易产生生产事故。并且运维自动化的落地实施也是要基于运维的标准化和流程化，所以作为运维管理的第一步，不可忽略。

标准化和流程化的建设思路一般是包括三大部分：日常工作梳理、标准化和流程化制定、日常工作标准化和流程化执行。

1 运维工作梳理

运维工作相对比较繁杂，结合实际运维工作，不同的公司又不同的划分方法，以某公司为例，大致分为数据中心（DC）运维、IT资源运维、服务运维、事件管理四个部分。

数据中心运维主要因为有自建IDC机房和部分托管在其他IDC机房的服务器，所以日常运维工作中有关于数据中心相关的工作，例如数据中心的设计和建设工作，数据中心日常巡检，数据中心权限管理、备件梳理管理、设备上下架等管理。如果是部署在云端的企业，对于数据中心的运维工作会少一些。

● IT资源运维主要是指计算、存储、网络和安全四大基础资源的运维工作。计算资源包括物理服务器的管理，如开关机、配置修改、资源增加等；存储资源管理一般包括自建分部署存储、商业存储、NAS等相关存储资源的账户权限管理、容量管理、监控等；网络资源运维管理工作主要包括网络权限管理、设备配置变更等等；安全资源运维管理主要日常与安全相关的规章制度和策略以及安全设备具体操作等。IT资源运维工作涉及日常运维工作基础资源，是整个运维工作的重点，基础资源的保障好坏，关系着上层应用服务的健康运行情况。

● 系统运维的日常大多是与服务运维相关。运维服务部署（如：Nginx部署、JDK、Tomcat的部署等）、服务的配置变更和服务发布、服务变更等。服务运维设计的标准和规范指导日常服务运维工作的进行，并且为自动化运维做铺垫，这要求在日常运维工作中，对于重复的手工运维工作尽量通过脚本或是其他变成语言实现自动化。

● 事件管理针对日常运维工作中出现的运维事件进行处理指导和提出管理方案。主要包括对事件进行分类、事件处理流程、如何汇报事件以及事件的总结等。

通过对日常运维工作所涉及的内容进行分类整理，并且加工提炼最后形成运维的标准和规范，将一些流程化的工作进行固化，并且逐步实现运维自动化，提高运维效率。

2 运维标准化流程化文档

通过对运维工作进行梳理，接下来进行运维标准护额和流程化文档的提炼。当然所做这一切都是基于公司自身的实际情况进行，切勿脱离实际，直接摘抄。另外一点，在制定运维标准流程之前，必须制定好文档编写得规范和标准，这样整体的规范流程文档的风格统一整齐。一般来讲，文档要尽量简洁，设计流程相关要图文并茂，着重对流程图的流程说明和关键点备注。

● 数据中心运维标准化和流程化

首先是数据中心运维相关标准流程规范。数据中心的建立在国内网以及不同行业都有相对比较同意的规范标准可供参考设置。一般对于自建数据中心的企业，对于数据中心的标准建立参考遵循国际标准、国家标准和行业规定即可。

● IT资源运维标准化和流程化

IT资源运维主要对涵盖系统基础设施的计算、存储、网络、安全四个基础部分的运维其中着重偏向于硬件以及硬件配置相关运维工作。

● 服务运维标准化和流程化

对于日常运维服务相关的标准化和流程化主要是标准化部署、配置以及流程化的处理如发布、变更等，这其中还包括数据库的数据处理流程、生产账号管理流程、以及备份和监控的标准规范等。

● 事件管理标准化和流程化

针对日常运维过程中出现的事件进行规范化和流程化管理与指导，使工程师在处理运维事件的时候有章可循，以达到事件通知上通下达、规范化处理、快速高效处理的目的。

3 标准流程化执行落地

通过运维工作梳理，进行运维标准化、流程化文档的编写之后，接下来就是最重要的落地执行。有了规范标准和流程，那么在日常运维工作中就不应该出现随心所欲、按照自己习惯进行运维工作的现象。

其实在标准化和流程化落地的初始阶段，往往会给工程师带来各种不方便和诸多不适应。典型的例子如下：标准化、流程化给工程师带来的感觉是事情变得复杂繁琐，自己的手脚被束缚，本来很简单的一个事情，几条命令几秒钟就可以搞定，但在执行标准化和流程化之后，变得需要涉及多人或岗位，同时也需要几十分钟甚至几个小时才能搞定，而最后实际操作的可能也就一开始的那几条命令。这是标准化初期的普遍现象，对于出现这种问题要积极沟通解决，让工程师们尽快度过这种看似繁琐、效率低下的初期阶段。解决方法有三：

首先是对工程师以及流程干系人进行标准化和流程化意义的普及。让大家了解知道进行标准化和流程化的意义，标准和流程得进行运维工作，可以大大减少人为失误，同时让大家在同一标准下工作，减少交流成本，相互之间的配合也会更加紧密。团队协作流程化处理问题最大程度的减少相互之间的影响。最后，标准化和流程化是最运维自动化最基础准备。加快运维自动化的建立。尽快将固化的标准和流程进行自动化的编码开发，大大减少人为操作，提高运维效率，这样运维工程师的日常工作因为大大减少人工操作，较以往会更加轻松。优化标准化和流程化。标准化和流程化的制定是基于实际的日常运维工作的，在实际执行过程中，应该根据实际情况，进行不断的优化调整，以达到最优。总结：

标准化和流程化作为运维管理体系的基石和运维自动化的第一步，在进行运维管理工作中必不可少，而且要实现彻底的标准统一。在进行落地的过程中，要适当的与运维自动化并行，加快自动化的脚步，只有这样才能最大程度的减少人为失误，减少人力成本，提高运维的效率和质量。

后面会分享更多devops方面的内容，感兴趣的朋友可以关注下。

一、DevOps究竟是如何改变开发和运维人员的？

如今，DevOps已经被越来越多的企业认可，DevOps不仅仅停留在开发和运维的范围，如今的DevOps是软件研发全生命周期管理的一整套方法论和最佳实践，是DevOps文化建设和人才培养。如果只涉及开发和运维人员，下面从实施DevOps之前和之后做个比较。

1、强化共同目标 2、对开发人员的改变 3、对运维人员的改变
DevOps使得开发和运维人员联系更加紧密，通过建立和强化彼此的信任关系，基于DevOps自动化服务，共同实现高效，高质量，稳定的交付用户价值的目标。

我来说下，接下来2022年DevOps实践的4个关键点

1、评估流程永远都是第一步。

DevOps 其实不是一个非常好理解的概念。如果我们不能很好了解DevOps 是什么以及它对组织的意义，那将可能是一个灾难。

不仅如此，团队中的每一个人都需要同步自己对 DevOps 的了解，只有团队在充分沟通的“同意”下，DevOps 实践才能顺利。这也就是为什么所有公司在切换至 DevOps 时的难点和重点都是——文化建设和学习。

此外，对开发周期的评估也应该是全方位的、从头到尾的。开发的不同流程，有不同的瓶颈和低效率，只有找到当前流程不足的领域，才能在实施 DevOps 时锁定重点。

2、协作和目标是DevOps团队的预备动作。

在实施 DevOps之前，就应该要确定团队有没有准备好一起工作和沟通。向每一位成员灌输强烈的协作意识，并为他们提供有助于他们沟通和协作的工具。

此外，明确的目标则为DevOps 实践设立方向，否则任何DevOps实践都将毫无意义。通常，我们可以从一个更小、更容易实现的目标开始，之后再转向更大、更复杂的目标，以防止一次性改变太多带来不可修复的破坏。

3、自动化是DevOps 的重要组成部分。

在DevOps过程中，我们应该尽可能多地使用自动化手段。无论是扫描错误配置的代码还是自动化测试，现下都有各种不同的自动化工具来实现，这对效率的提升无疑是巨大的。

在这个基础上，如果还想进一步的自动化，项目就不得不考量团队是否能跟上了。所以，最好的办法是，从需要大量时间和手工的工作入手，去一步步实现自动化。采用自动化之初，也最好让团队先监控几周，看看进展如何。

4、了解关键指标是重中之重。

从实施DevOps的一开始就应该设置关键指标。如果没有指标，我们将无法跟踪进展，也无法及时发现问题。

飞算全自动开发平台项目发布的应用服务，在监控运维指标方面已集成 健康 检查、审计、统计和HTTP追踪等运维性能指标数据，所有的这些特性可以通过JMX或者HTTP endpoints来获得。

同时还可以与外部应用监控系统整合对接，可以方便地通过第三方系统进行监控告警，比如 Prometheus、 Influxdb 、Grafana等。这些系统提供了非常好的仪表盘、图标、分析和告警等功能，使用户可以通过统一的接口轻松地监控和管理应用。

devops的概念我觉得很难用一句话去定义或解释，主要是流程和工具的结合，规范的流程加上高效的工具构建符合业务和公司实际的运维场景

说到底就是把繁琐的操作自动化，在得到快速集成和快速部署的同时，减少人为引入的失误。符合自动化发展的趋势，算是自动化在软件开发运营中的成功。

DevOps是一种打通开发和运维，并将所有环节自动化，摆脱人工束缚的理念，不仅仅只是字面上的将开发和运维打通结合。

多年以来，这两个群体一直被分开，尤其是在大型企业IT组织内部。开发者只关心编码，运维人员则确保其正常运行。他们之间完全脱节，导致需要更长的QA周期。并且经常不能在环境上部署新程序，因为这样可能会导致宕机或者破坏其它程序。

DevOps实现了高标准化，仅需几个工具，就可以替代人工干预，使用有效的方式来部署、配置和运行许多的服务。

随着DevOps的诞生，开发人员可以拥有配额，在一定的范围内他们可以按照需求，实时部署环境。

运维团队不再需要关心部署单个的应用程序，他们仍然采购硬件并且配置和管理服务器，但是规模远远大于单个的应用程序，他们的责任变成了管理开发人员更容易使用的自动化DevOps服务。

二、如何实现DevOps？

DevOps 是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。DevOps 旨在统一软件开发和软件操作，与业务目标紧密结合，在 软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控。

DevOps 的目标是缩短开发周期，增加部署频率，更可靠的发布。用户可通过完整的工具链，深度集成代码仓库、制品仓库、项目管理、自动化测试等类别中的主流工具，实现零成本迁移，快速实践 DevOps。

DevOps 帮助开发者和运维人员打造了一个全新空间，构建了一种通过持续交付实践去优化资源和扩展应用程序的新方式。DevOps和云原生架构的结合能够实现精益产品开发流程，适应快速变化的市场， 更好的服务企业的商业目的。在容器云PaaS、DevOps、微服务治理、服务网格、API网关等等方面，时速云做的还不错，他们是一家全栈云原生技术服务提供商，你可以了解一下。

三、大型企业实施 DevOps 的三个阶段

DevOps时代 发表于 DevOps时代的专栏

估计阅读时间12分钟

《DevOps 实施手册》介绍

现在开始我的分享，大家有这样一个感觉，现在技术发展的太快了，技术还没有普及就被淘汰了。在这样一个浮躁的时代我为什么翻译《DevOps 实施手册》这本书呢？因为在《DevOps实施手册》里研究的都是长久以来一直有效的理论，比如像福特汽车的生产流水线，像丰田的精益生产，还有敏捷开发思想。这些思想并不是近期出现的。

2009年，在这些思想的基础之上 DevOps 应运而生，让开发与运维甚至是运营之间的协作更加高效，希望这本书能够帮助到正在做 DevOps 转型的企业，解决数字化转型过程中遇到的实际问题。本书独家介绍了自上而下的 DevOps 实践（企业级），如何让领导者和参与到 DevOps 变革中，后面会进行详细的介绍。

另外一类是自下而上的 DevOps 的实践（团队级），还包含了如何让组织自发产生新实践的组织模型。

消费改变需求实现方式

我们开始今天的主题，首先，按照以往的经验，实施 DevOps 一定会提高生产效率，降低产品成本。如果成本足够低，就应该占领大部分市场，这个假设是正确的吗？下面有一个例子：

福特汽车在1914年引进了流水线技术，将一台汽车的成本做到 7000 块钱（一台IPhone），和手机一样的价钱，市面上有90%的汽车都是由福特生产的。如果事情按照这个逻辑发展下去，几年后福特将会统一汽车市场。

六年之后，流水线优化，每十秒钟就能生产一辆汽车，成本降到了2000元（一台小米手机）花一台小米手机的钱就能买一辆汽车。当时创始人老福特的有一个笑话，他说：“我的客户可以选择任意一种颜色的汽车，只要它是黑色的。”

实际情况是客户只能选择黑色的T型车。为了每10秒生产一辆汽车，只有黑色的油漆干燥的速度才能达到要求，所以生产的汽车都是黑色的。在随后的六年时间里，效率提升和成本降低做到了极值，但结果是订单远远低于了产量，生产出来的汽车只能积压在仓库里。

当汽车变成代步工具，同质化的T行车无法满足用户定制化的需求，因此通用汽车用不同颜色和配置的汽车和更高的售价，占领了个性化汽车市场，从而打败了福特汽车。这个案例证明只提高效率降低成本并不能统一市场，只有满足用户需求的产品才能生存。

当我们选择汽车的时候，如果我已经拥有了廉价T型车，下一个辆要买什么样的车呢？不再是 2000 元的同质化的代步工具，而是根据自己的喜好选择不同颜色和配置的汽车，哪怕是价格稍微高一些。通用汽车适时的推出了个性化汽车占领了汽车市场。

大部分的汽车点评网站都会把汽车按照价格分为以下几种，有5万元的汽车，有10万元的汽车，还有30万以上的汽车，这些不同的汽车为什么定这个价格，人们购买的是什么？

比如说5万的的汽车，做到了基本代步工具应有的功能（有座椅，可以遮风挡雨，重点是可以开），如果满足更高的需求，比如更强的动力，更大的空间，一边开车一边听听音乐，这一类是期望的需求，这样需求得到满足用户的满意度会直线上升。

还有另外一种就是兴奋型需求，比如我想买有自动泊车功能的，还有如果我手里拿着刚买的一堆东西，想放到后备箱里，只要脚在后备箱下面一滑，后备厢门就自动打开了，这就满足是特殊场景的需求。

再或者有自动驾驶的功能，车辆会把孩子按照导航制定位置送到幼儿园（在美国法律下的特斯拉可以做到）。简单的来说兴奋型需求就是黑科技。

用户的需求分为基本需求，期望需求和兴奋需求，因为不同的需求而购买产品的客户表现出很大的差异，而为了满足不同需求，对企业能力的也是不一样的，接下来看一下为了满足不同需求，要做哪些方面的设计和考虑。

为了满足期望型需求（定制化需求），厂商需要进行客户调研，使用组件方式批量生产，高效地满足定制化需求，达到快速高效的推出新产品的目的。 对于定制化软件产品使用将产品拆分为组件，通过对部分组件定制化开发高效满足定制化软件的需求。

为了满足基本需求（固定需求），厂商需要严格控制风险，减少新产品失败的可能性，通过流程固化部门协作，提高部门内部的效率，来降低成本。对于满足基本类型需求的软件产品，需求主要是短期内不会变化的协议和标准。提升竞争力的方法类似于T型车，不断优化流水线提高效率降低成本。

为了满足兴奋性需求（黑科技），厂商需要了解用户使用产品的场景和情绪，比如说像用脚在后备箱下面滑一下就能打开后备厢门，对于黑科技的软件产品，需要了解用户使用产品时的行为和情绪变化。

就像现在的电商网站，在用户浏览和购买产品时，记录用户行为（经常浏览商品种类，购物车内产品等等），从而判断用户喜好。在了解用户购买偏好后，提高推荐商品的购买成功率。

对于基本需求，就像买水买电和石油都一样，产品没有本质差别，只要便宜就好了，不断提高效率，降低成本，就像T型车不断优化流水线一样。

对于满足期望需求的软件企业，我亲身经历过这样一个案例，在十多前，我在一个通讯公司里，研发部门的产品是支持内部业务的IT系统，同时也对运营商销售企业内部使用的IT系统。这样的研发的模式中有一个业务分析（BA）的角色，定期去拜访客户了解客户业务和对软件的需求，然后对部分组件进行定制化开发。

这样的组织有两种研发模式：通用组件的研发和定制组件的研发。研发团队工作模式和对工程师的能力要求是完全不一样的。通用组件的团队注重软件执行效率和通用性，而定制化团队专注于实现业务需求。

从总体上说提高组件复用率，减少定制开发工作量降低总体成本是优化的方向。

谈到兴奋型需求，需要感知用户的行为和情绪，传统企业不直接面对个人消费者很难感知到客户情绪，但是对于有大量用户行为数据和互联网公司却可以做到。在用户使人某个功能不顺畅，导致用户不再使用，这种用户行为就表现出客户情绪的不满。了解用户用使用产品或服务的场景，感知使用过程用户情绪的变化，才有可能作出让客户惊喜的功能，甚至是黑科技。

最近我和一位BAT工作的前同事聊到短视频应用产品，他把内部产品和抖音做对比，过程是观看30条短视频，对某一类型的视频反复观看。结果是抖音可以识别出用户对这类视频的偏好，反复推荐类似的内容，而内部的产品却没有任何改变。通过算法和大量用户使用数据对产品或服务进行优化，明显提升了产品的竞争力。

满足三类不同的需求，需要具有不同的企业能力。从满足定制化需求的企业（通过用户调研，生产出相对便宜的定制化产品），跨越到与用户的协作，实时感知用户情绪的企业，推出令用户兴奋的黑科技。这个变化是数字化转型中企业所面临的挑战。需要打通从需求、研发到业务运营整个的协作过程，建立新角色，落地新能力。下面是我的一点总结：分工会提升个体效能（产出output），系统性全局优化才能提高业务价值（价值outcome），对最终价值交付的优化才是关键。

企业核心竞争力来自于协作效率

我们现在看一下用户对企业竞争力的影响，这个是一个如何提升企业竞争力的例子，IBM（国际商业机器）成功的关键是生产满足商业公司所需要的计算机设备（IOE的I就是指IBM的小型机），早期的计算机是用来为政府和科研机构服务的。IBM与UNIVAC不同之处在于IBM服务于企业的财务人员和银行业。

IBM在企业计算机领域使用相同的技术战胜了科研领域的UNIVAC，而当时UNIVAC的服务对象是政府机构和科学家，不削于给企业的财务人员做计算机，但是我们现在知道，企业的计算机市场规模是非常大。

IBM在这个市场里面获得了成功，我们所说的企业竞争力体现在服务的对象足够多，服务的市场是否足够大，这是第一位的前提。

第二点是企业的核心竞争力在于它有能力构建新的价值网络，价值网络源自于传统的供应链。企业给供应商下单的规格和数量变化不频繁。

价值网络的不同之处在于，在美国的苹果公司对中国深圳的企业提出变更需求，两个小时以后流水线改变已经完成，24小时之后就可以生产出来新的手机了，中国的柔性制造能力世界第一。价值网络的难点在于，协同价值网络中分工足够细的，大规模生产企业，快速重新组合的能力。

下面的这幅图是2007年的时候诺基亚推出的经典手机，也许在座的听众也用过其中的某个型号的手机。

放这张图的意思是说明诺基亚当年通过推出大量定制化外观的手机，很好的满足了我们对手机外观多样化的需求。但是被只有一种外观，而且每年只出一款手机的公司打败了，这是为什么呢？他就是IPhone手机。苹果把更加广大的开发者加入到了协作网络里面去，让手机从只能打电话的通信工具，变成个人的效率提升的工具，可能我们现在真的一分钟离不开手机，但在十年前是不可想象的。

下面的图是基于云计算的平台三家公司，每个公司都有自己的布局，从电子商务、社交领域和搜索入口建立生态。这些平台上的应用的图标可能大家很熟悉，在不同的维度收集用户行为的数据，感知用户使用产品时的情绪变化，从而把服务越做越好。数据在组织内部可访问，在一个云生态内部，共享用户行为数据的成本非常低。

第二个就是自动化的基础设施，在云平台上快速调度计算资源应对用户流量是很容易的事情。最后在集中化和分布式平台，本身有利也有弊，集中化会建立统一标准提高协作效率，在较大的生态中一定会有协议和标准，而在小团队里面对于自己的业务作出有针对性的工具提升用户满意度，有不同才有比较，有比较才有不断的创新，这也是集中和分布式的一些思考。

企业竞争力在于与外部价值网络高效协作，我们都认为企业做的好是企业内部管理做得好，企业的效率高，所以企业才有竞争力，其实不是这样的，企业的竞争力是来自于企业对外部协作网络提供的价值。

企业的竞争力来自于服务的客户和市场的规模，企业的竞争力来自于创建更大的协作网络，企业竞争力来自于促进生态合作，增加服务市场规模。这才是企业竞争力的三个表现。

最后有一点值得讨论，在云计算平台上构建生态，满足了不同规模的需求，甚至是某个用户某一次特殊的需求都能得到满足。在传统企业模式下是无法想象的，因为市场规模不够大，不能形成规模效应降低成本，所以只能对具有一定规模的需求推出产品和服务。

云平台也将引入需求众包模式，比如重筹的平台，会满足大量的小规模的需求，这个云计算具降低了信息发布的成本，对服务市场带来了新的增量。

大型企业实施 DevOps 三个阶段

下面进入正题了，首先 DevOps 是一次系统性的变革，下面是提升研发效率的3D原则。我们类比集装箱运输的体系，在集装箱运输发展的早期阶段中，用户的按照传统的方式使用集装箱，集装箱内的货物不一样，从汽车运到轮船转运过程中不断的开箱拆包，大大降低了转运效率。

在二战时期，美国军方需要把大量的物资运往前线，从而总结出了在装箱，分拣和送货过程中的高效原则，基于这些原则我提出了研发体系的3D原则，一键式部署，一次构建打包，一次配置分发，在构建、测试和发布环节减少再次打包和人工过程。在遵循这三个原则之后，发布软件的时间可以控制在10-30分钟以内。

其次，DevOps 不是一次性的工程，可以一劳永逸，下面是一个软件研发过程当中的价值流图。

下面是我非常喜欢的一句话：“比日常工作更重要的，是对日常工作的持续改进。”

其实我们每个人都在做很多工作，可能每一天都会比前一天做更多，李智桦老师给出了企业效能的公式，企业效能等于实际产生价值的工时除以是总工时。在这张图里算出来的企业效能仅为16%，原因就是很多的工作都有等待，有的工作有返工。粗略的算一下从目前的效能水平，优化到总体效能提升两倍、三倍是绝对有可能的。而在某些环节内部按照 DevOps 实践完全有可能做到5倍，十倍或者二十倍效能提升。

随着业务在不断变化，技术在不断进步，在工作流中的每一个环节的情况就像左边一样混乱。DevOps 变革是一次大爆炸式的变革，就向扔一把扑克牌，落地之后就是整整齐齐在那里，而且牌面都是朝上的。这就是实施 DevOps 变革的兴奋性需求，如果谁的 DevOps 能实施到这个程度那真是赞了。

这个过程是如何做到的？首先我们要考虑两种力量，第一种力量是敏捷，敏捷的目的是什么呢？就是把我们每次交付的时间缩，做对用户有价值的事情。第二种力量是精益，我减少价值流图中的浪费。只要持续的改进，最后的结果一定是把我们软件研发的过程，到最后的生产，甚至是运维的环节做到统一和高效。

我们说在 DevOps 发展的初级阶段立足于促进研发和运维的协作。但是在我们来看只有 DevOps 帮助业务达成业务目标，才是可以持续的模式。也就是说做了流水线，也做了很多改进工作（产出 output），但是业务并没有因此而获益（价值outcome）。

自上而下的实践要求的是统一性和确定性， DevOps转型需要投入非常大的成本，使用业务线思维的DevOps与业务沟通，把 DevOps 实践作为一个有利可图的实施项目。

决策层投资了 DevOps 实践就期望从中获得收益，我们要把DevOps 提升的结果翻译成业务人员能懂的语言，比如说我们可以缩短产品上市时间获得先机，可以让我们的生产更加稳定，减少以外带来的损失。

下面说如何产生新实践，工程师都喜欢去研究一些新技术，有很多团队在做这种尝试和创新的话，其中有各种比较，逐步找到创新的方向，所以说自上而下的 DevOps 实践带来业务价值，自下而上的 DevOps 实践获得新实践。使用企业级的实践提升业务价值，使用团队级别实践不断产生新实践。这样形成正向循环。

在我们推广 DevOps 的时候，大家感觉都是求着研发人员改进一样，为什么要求人呢？因为人家的工作内容里本来就没有实施 DevOps。还是上文说过的一句话：“比工作更重要的是工作的改进。” 如果改进不是每个人的工作内容，不作为考核的内容，实施DevOps实践就只是一时的事情，无法落地。

右边的图是稳定的学习型组织模型，比如说在一个公司的两个部门里，成立一个协会，会定期分享案例，或者是组织实践评选，在一个部门内部会有相同角色的人组成分会不定期分享工作中经验，让小团队中的实践在全公司范围内都是可见的，减少重复造实践的成本，同时也会把做相同的事情的人的经验整合起来。

最后还是说对领导的培训，做个广告，有的读者真的把《DevOps实施手册》的截图发到朋友圈里给老板看，用这种方式和领导沟通。因为有些话不能直接给领导说，所以就用我的书里的实践来影响领导。

最后总结一下，首先要有一个清晰的路线图，明确投资回报率，然后在试点团队验证新实践的交付有效性，最后，建立改进的考核目标和组织模型，鼓励分享经验的团队，吸引对变革有观望和怀疑心态的人加入到变更中来。

DevOps 五个能力能级

下面是我的一个思考，公司根据核心竞争力划分为三个等级，产品、平台、生态。

对于公司面临的商业环境来说分为五类，最复杂的一款是无序，最复杂的情况下即使可以复制之前的实践，也无法得到相同的结果。

同样的，对工程师取得的成就也为五类，很巧也是五类，最高等级是开创一个产业（爱迪生、福特、贝尔），比如说像开创一个产业的人，二级工程师是作出先前没有的东西，而改变世界（谷歌的云计算发明人迪恩Jeff Dean），三级工程师必须是一个非常好的产品经理，可以作出被市场认可的好产品。

在公司内作出有影响力的工作，就达到了四级工程师的要求。最后，一个人可以独立解决问题，完成工作即为五级工程师。

最后，从我们的环境和我们能取得的成就来看，DevOps服务能达到的极限就是服务所有云上的开发者和生态合作伙伴，将价值和信息传递给最终用户。第二个等级，是组织内部的业务平台，对价值网络其他组织提供价值。

从平台和生态角度看，引入更多外部协作，就是公司竞争力的体现。第三级，在一个组织内部协调各部门的资源，达成系统性优化，显著提升组织效率。第四级，通过可见性建立信任文化，提高团队协作效率。第五级，支持个人完成任务，并具备持续改进能力。

小节一下，当基本需求得到满足的时候消费者会提出最高的需求，如何满足更高层次的需求？就要不断的扩大协作范围，这对组织结构和能力是非常大的挑战，数字化转型就可以理解为一个组织从满足期望需求，向满足兴奋型需求转型的过程。

第二个就是说技术和业务的变化带来的组织模式的变化，打破仓筒结构形成全局优化，就是前面提到的， 4000名开发人员工按照相同的规则做研发。

大型企业通过三个阶段实施DevOps，首先要有路线图，要有商业化的试点案例明确投资回报率，在组织模型和考核方面鼓励创新。

最后是我对DevOps的服务发展的一些思考，通过引入更大规模的协作提升组织竞争力。

原文发布于微信公众号 - DevOps时代（DevOpsTimes）

原文发表时间：2018-12-26

阅读原文