导读：本篇文章首席CTO笔记来给大家介绍有关devops怎么落地的相关内容，希望对大家有所帮助，一起来看看吧。
华为软件开发云如何让devops落地？用了该工具的企业效果效率提升了多少？
据了解，华为开发云（）提供了项目管理、配置管理、代码检查、编译构建、测试、部署、发布等端到端地覆盖软件生命周期的相关服务。
1、从技术层面来看，企业可以在软件开发云上利用 “配置管理-代码检查-编译-构建-部署-测试-发布”等服务，为产品版本集成发布可视化地创建流水线，本流水线包含多个阶（stage）；在每个阶段创建多个不同类型的任务（task），例如，代码检查任务、编译构建任务等。
2、在代码提交后，利用云上各服务的集群并发及加速能力，流水线的相关任务可以实现最大程度地并发，在小时级别自动化实现版本级集成发布，得到版本质量报告，并快速反馈给开发人员，以便进行快速修复，在开发人员修复版本后并再次进行流水线的集成发布。
在紧急状态下，还能实现版本的快速可靠回退。这样一来，版本每周或每日构建成为可能，项目管理服务提供了敏捷式、社交化的项目管理方式，可与配置管理关联，使得开发团队有效协同，通过看板等各种图表实时掌握项目进度和质量。
实际的效果：
实际使用过程中，以某个孵化器为例，在孵企业主要研发智慧城市解决方案相关的产品，多个公司经常会协同开发一款产品。每个公司使用不同的研发工具，没有一个统一的研发工具平台。为了解决瀑布模式难以快速迭代、跨地域多团队协同、手工编译构建周期长、不同团队的工具平台不统一等问题，选择了华为软件开发云进行项目联合开发。
在熟悉了DevOps研发模式、软件开发云服务特性（例如流水线等）后，产品版本的集成发布由原先的1天缩短为30分钟，整个项目的交付周期缩短到3个月。
大型企业实施 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
阅读原文
Devops概述
目前在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事？
DevOps一次词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。
DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。
换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。
由上所述，相信大家对DevOps有了一定的了解。但是除了触及工具链之外，作为文化和技术的方法论，DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式，可以发现大致有三个阶段：瀑布式开发、敏捷开发、DevOps。
DevOps早在九年前就有人提出来，但是，为什么这两年才开始受到越来越多的企业重视和时间呢？因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。
当今世界改变的速度已与过去不同，而每当经历一个颠覆性的技术革命时，都给这个世界带来了深刻的变化，大数据、云计算、人工智能、VR/AR和区块链等新兴技术推动着世界不断变化，如何应对这样一个VUCA时代，让我们能够在环境变化的时候快速响应呢？
在些我引用了圣贤王阳明的一句名言，他提倡“知行合一”，通俗的讲就是做事情要理论与实践相结合。我们在实现DevOps落地时也一定要遵循“理论与实践相结合”的方式进行，理论就是我们做事的指导思想，而实践就是具体做事的方法，接下来我就从我在公司中是如何按照理论与实践相结合来推动DevOps落实地。
首先我们还是要回到什么是DevOps，如果大家忘记了可以回到之前再温故一下，包括我总结的DevOps公式。
其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。其基本原则如下：
DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告中，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司可以完成平均每年1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。
DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。
快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地相应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。
因此，认为速度就意味着危险是一种偏见。此外，滞后软件服务的发布也并不一定会完全地避免问题，在竞争日益激烈的IT行业，这反而可能错失了软件的发布时机。
技术的发展使得DevOps有了更多的配合。早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack， Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。
IT行业已经越来越于市场的经济发展紧密挂钩，专家们认为IT将会有支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不仅体现在Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。
DevOps 2016年度报告给出了一个运维成本的计算公式：
而对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。（You build it, you run it）
上文提到了工具链的打通，那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下：
在工具的选择上，需要结合公司业务需求和技术团队情况而定。（注：更多关于工具的详细介绍可以参见此文： 51 Best DevOps Tools for #DevOps Engineers ）
DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在在业务人员与开发人员之间。出席了ITV公司在2012年就开始落地DevOps，其通用平台主管Clark在2016年伦敦企业级DevOps峰会接受InfoQ了采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品中实现什么，工程师们就按需交付，不做多余工作。这样，工程师们使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。此外，DevOps对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。
DevOps正在增长，尤其是在大企业中：调查发现，DevOps的接受度有了显著提高。74%的受访者已经接受了DevOps，而去年这一比例为66%。目前，在81%的大企业开始接受DevOps，中小企业的接受度仅为70%。
那么具体而言都有些公司在采用DevOps呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛欧实时全额自动清算系统）、Walmart、Sony等等。
首先，大企业正在自下而上接受DevOps，其中业务单位或部门（31%）以及项目和团队（29%）已经实施DevOps。不过，只有21%的大企业在整个公司范围内采用了DevOps。
其次，在工具层面上，DevOps工具的用量大幅激增。Chef和Puppet依然是最常用的DevOps工具，使用率均为32%。Docker是年增长率最快的工具，用量增长一倍以上。Ansible的用量也有显著增加，使用率从10%翻倍至20%。
并且调查还发现不到半数（43%）的公司在使用诸如Chef、Puppet、Ansible或Salt等配置工具；然而使用配置工具的公司更有可能同时使用多个工具。25%的受访者使用两种或更多配置工具，只使用一种工具的比例为18%。其中Chef和Puppet是最常用的组合：使用Chef的组织中有67%同时也使用Puppet，类似的，使用Puppet的组织中也有67%同时使用了Chef。
关于DevOps 的那些事
在2008年多伦多举办的敏捷大会（Velocity Conf 2008 ）上，Patrick DeBois 和AndrewClay Shafer 先生首次提议讨论“敏捷基础架构”这个话题。在第二年的敏捷大会上有一个具有里程碑的意义技术分享，来自Flickr公司《每天部署10次》的分享，它激发了随后Patrick DeBios在同年十月，在比利时的根特市举办的首届DevOpsDays活动，这个活动是两天的日程，为了大家方便在twitter上的传播，人们把DevOpsDays这个词简写为 “#DevOps” 。 此后，“DevOps”一词问世了，这个词所包含的理念和实践一时在越来越广大的人群中产生了共鸣，随后成为全球IT界在各种大会和论坛里热议和讨论的焦点话题，很多大型IT论坛也都开设出了DevOps专题讨论。这就是DevOps这个词的由来。
DevOpsDays活动随后在Patrick DeBios等相关核心发起人的推动下，在全球范围内蓬勃发展了起来。2010年在美国山景城(Mountain View) 举办的DevOpsDays 活动中，Damon Edwards先生使用“CAMS”这个缩写，高度概括和诠释了DevOps，即文化（Culture）、自动化（Automation）、度量（Measurement or Metrics）和分享（Sharing）。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。
♣ Culture（文化）- 是指拥抱变革，促进协作和沟通
♣ Automation（自动化）- 是指将人为干预的环节从价值链中消除
♣ Lean（精益）- 是指通过使用精益原则促使高频率循环周期
♣ Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期
♣ Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进
“CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。
从DevOps概念的产生，到如今它在全球范围内的蔓延和认同，已经经历了9个年头的时间。它的火爆推广也伴随着IT行业的迅速变迁和发展，现在已经到了移动互联网时代的后半场，国内的信息化建设已经完成了很多年；如今各行各业的企业也都亟待完成全方位的数字化转型。IT信息技术的先进程度标志着一个企业的核心能力，任何一个成功的企业，敏捷高效的软件开发创新实力和IT管理综合能力不只是门面而已，而是实实在在的市场竞争能力。DevOps倡导打敏捷、持续交付和ITIL三种实践的组合拳，同时应用精益生产理念为基础的管理思想，这正在逐渐地被广泛的接受和认可。
在过去的几年中，国内的各种IT大会也蓬勃发展，其中DevOps相关的专题和分会场也颇受人们的关注。各种云计算、运维等IT技术的社交媒体也都非常重视DevOps这个话题的分享。一个专属于DevOps社群的、国际性的、有影响力的DevOps大会正呼之欲出。在这样的时代背景下DevOpsDays大会北京站在2017年的3月18日来到中国，在同年的8月18日上海，还要举办DevOpsDays Shanghai站的大会。
下面列举一些DevOpsDays大会的相关数据，数据来源于DevOpsDays.org 网站。从2009年到2016年，已经在全球的61个城市/国家成功地举办了117场。
下图是在过去九年中DevOpsDays大会在各个城市/国家的分布和举办次数。
今年也就是2017年预计举办30场，其中已经有18场确定了举办城市和日期；还有12个城市的召开日期待定；这不包括年内还可能会提出申办的城市。以上数据的统计时间在2017年三月。
随着国内BAT等互联网巨头的崛起，互联网公司的开发运维经验也越来越多的在国内的各种技术大会上传播。从最近这两年（2016年和2017年）的技术活动日程中可以看出，国内互联网从业人员也不约而同的用DevOps来定位和分享自己的优势和经验。他们是传播和分享运维侧DevOps实践的先头部队。
出了技术论坛的分享之外，很多线上线下的大会、论坛和讨论组也都越来越热议DevOps这一专题。国内其它相关流派的人群，例如敏捷和精益等，也对DevOps的蓬勃发展表示比较惊讶，DevOps与老牌的敏捷和精益等阵营也产生过一些争论。但这一切的发生也都增加了人们对于DevOps的更深入的兴趣。
在培训认证这方面，Exin DevOps Master是一个国际认证的培训；其它公司和组织也正在举办关于DevOps工具链的培训，这些培训则注重于技术实操，关注在构建端到端的流水线的搭建方面。从DevOps的职位招聘方面，可以看到DevOps工程师相关的职位越来越多了，在职位需求中DevOps这个技能成了加分项，DevOps相关工具的技能也或将成为简历的亮点。在IT行业内不管是开发还是运维团队的人，都开始了学习和接受的过程。
据我观察DevOps方面的厂商在最近3年呈现爆炸式的发展。我把他们分为三类：
目前国内大部分企业慢慢地开始关注了DevOps，大型传统企业也开始逐渐地从各个角度做试点和尝试。试点的角度和方向各不相同，有的从底层基础架构的容器化开始，有的从交付部署流水线的自动化开始；总的来说还处于初级的尝试阶段，还没有大规模成体系的推广。
综上所述，目前国内DevOps发展的阶段还属于起步阶段。就像是ITIL/ITSM在2003年左右的状态。由于DevOps是去中心化的，所以没有唯一、权威的上游厂商的存在，各种理论实践的争执和PK都将终止与解决问题和提高效率的话题上，因此它具有百花齐放百家争鸣的发展条件。个人认为DevOps的实施和落地也不会完全依赖于传统的大型咨询厂商的咨询工作，由于它应该是在企业的内部，在内驱的作用下，自生长出来的；它必须是服务于企业的业务价值流的优化，加速业务价值产出的；而与之相关的工作和责任的担当，外部力量是很难以等量替换和承担的。
在谈这个话题前先看一下DevOps相关工具集的全貌，如下图所示：
最上面的箭头流程图表示了一个业务服务的全生命周期：开发协作、软件构建、质量测试、交付部署和投产运维。前三个阶段偏传统开发组织的工作内容，后两个阶段基本可以和运维组织的工作对应上。在每个阶段下可以看成是一个大分类，这些分类中还包含若干个小分类。这些工具可以粗放的划分为商业软件和开源软件两类；也可以分为SaaS服务类和企业内部部署型。大部分开源工具都有活跃的用户社区和群众基础，这给企业入手这些工具带来了很大的便利。在需要商业支持的场景里还可以选择使用这些开源软件的企业版。
Docker容器技术在最近三年中异军突起，持续交付的技术门槛因此被降到最低，软件生产供应链的格局和效率被彻底提升；基于Docker的微服务架构实践的热度和成熟度也与日俱增。因此，国内的传统企业纷纷试水DevOps和容器技术，在最近两年的各种技术大会中，我们可以看到国内各个行业出现了在不同维度上的DevOps先行者。他们分享的主题大多集中在自动化运维、容器化和PaaS平台的等项目经验。
从国内众多DevOps实践中，我们能看到下面三个技术尤其重要和火热：
以上三种技术相辅相成，有着比较深刻的关联。首先微服务和持续部署各自解决了特别多的传统IT的问题，这些问题都是长期以来制约企业业务发展的难题。容器技术由于它的快速、轻量、微服务化的天然特性，很好的从不同侧面支持了持续交付和微服务架构。容器可以为持续交付提供弹性和高速的系统资源，环境管理和利用率提高了很多；容器的不可变性的特点也更好地支持了微服务架构。
我把DevOps的按照不同的技术特征做了从到1.0 到2.0的时代划分，并尽量通过以下维度比较与传统方式的差异。
我比较认可和接受的企业实践DevOps参考框架如下，其中包含了所需的最佳实践，如下图所示。
（上图来源于：Exin DevOps白皮书）
下面简要描述一下这四大支柱型最佳实践：
由此可见DevOps在企业，特别是大规模传统企业的落地和推广还是比较复杂的。虽然相关的最佳实践都是已经存在了很多年的；但是，通过DevOps的价值观重构企业从研发到交付到运维的价值流谈何容易。基于我的IT从业经验，我似乎感觉到DevOps不能单独依靠自顶向下的推广，当然高层领导的支持依然是重要的和必备的支持条件之一。 可能还需要中层的带动和底层的创新；借鉴生产制造业已经久经考验的精益制造实践也是势在必行。总之DevOps运动会在近几年给IT行业带来较大影响。
为什么DevOps很好，但却很难落地，大家对DevOps是怎么理解的？
DevOps不是一开始就有的，为什么现在的声音越来越大了。其实原因很简单，说明市场，也就是各软件公司碰到问题了，DevOps可以帮助解决这个问题，为客户创造价值。
那客户的问题又是什么呢？比如现在的互联网公司越来越多，市场的竞争也越来越激烈，产品迭代的频率越来越快，做得极致又成功的比如Netflix，可以做到一天发布好多次。如果还是像以前的模式，可能你的公司早就被淘汰掉了。
其实理解起来很简单，就像图上面一样Dev和Ops合作一起搞事情了（但上图的幽默用来隐喻实际的效果是刚刚好的）- 貌合神离。如果只管自己的一亩三分地，因为有各种KPI的原因，这也再正常不过。但试想一下，如果一家公司的KPI是：对开发团队，一个月内发布10个版本。对运维团队，线上环境可靠性是99.99%。很明显这样就会让开发团队和运维团队一下子变成了对立面。如果想快速发布版本，得过质量（测试团队）的关，还有运维团队的关，因为要上线，可能因基础设施等各种原因受到影响。再说运维团队，会很小心的测试，因为好容易弄稳定的环境，你又给我增加了新的风险，我当然不乐意了。
因为上面的种种制度的原因，再加上将Ops前置，导致的工作量和工作复杂度的加大，因为在软件行业，并没有因为新事务的出现，而消灭了一些复杂度，而是将复杂度从一个地方搬到了另一个地方。所以难度是变大了的。组织结构不动，观念不调整，就已经为DevOps落地埋下了失败的种子，再加上能力上需要提升，就会让这件好事情离成功越来越远。
结语：以上就是首席CTO笔记为大家整理的关于devops怎么落地的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～