导读：今天首席CTO笔记来给各位分享关于Devops什么时候过时的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
devops职位什么时候最忙
每年中旬。devops是前端业务成为了产品快速迭代过程中最忙碌的岗位之一，前端的持续集成、交付、部署也成为企业研发效率提升的瓶颈。该职位每年中旬是订单最多也是最忙的时候。职位，它是指机关或团体中执行一定任务的位置，即只要是企业的员工就应有其特定的职位。
DevOps的概念和历史
当你看敏捷的时候，不经意间出现了DevOps这个词，你还在好奇，这是什么的时候，发现规模化敏捷也出现了，这个时候如果你还发现自己对这个词很陌生，那说明你的知识该补齐了，毕竟他们如果总是频繁出现，说明他们的相关性很高。
其实不只是敏捷，在CMMI、ITIL都在提到DevOps，说明我们真的很有必要对它进行一个系统性的了解了。
1.CMMI中提到关于Devops
图 CMMI
2.ITIL中提到关于DevOps
各类管理体系其实都在走向融合，而且都需要DevOps的支持，所以你还觉得自己不需要认真了解下它么？
如果你想快速的系统性的了解DevOps，可以先阅读以下几本书：
《凤凰项目》
《持续交付》
《独角兽项目》
《凤凰项目 一个IT运维的传奇故事》
《DevOps精要》
如果你报考了DevOps Master认证，那你《EXIN DevOps Master WhitePaper》是必读的。
DevOps是对敏捷软件开发与精益生产思想的演进，应用于IT端到端的价值链中，使得业务基于现代信息技术，并通过文化，组织与技术变革来获得更大的成功。
这是《DevOps精要》中关于DevOps定义，定义都有其严谨性，所以往往看完定义让我们摸不着头脑。DevOps其实是英文单词Development(Dev)和Operations(Ops)的组合，为什么要把这两个词组合到一起，最初创造这个词的人目的就是期望开发和运维能够紧密的合作，随后逐步的被扩展和衍生，下面这个“DevOps能力环”是对这种打破部门墙，进行顺畅交付的一个非常经典的一个表达。它强调了IT专业人员（研发，运维，测试）在应用和服务生命周期中的协作和沟通；强调整个组织合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。
[图片上传失败...(image-c93581-1650555848432)]
DevOps能力环
我们为什么要了解其历史，如果我们只是想用DevOps的一些工程实践，大可不必，但是如果你的团队还对这个概念很陌生，他们不知道为什么要用DevOps，如果是这样的话，我们还是有必要花几分钟来了解下它。
DevOps起源于敏捷，是在2008年敏捷论坛上被提出的，所以现在很多人会认为DevOps是敏捷的一部分，对于到底是谁属于谁，谁包含谁，这些观念大家不必纠结，各大体系都认为自己包括别人。敏捷认为它包括DevOps，而DevOps认为自己是它的衍生。
DevOps的概念在2010年的《What is DevOps》这篇文章中得到了较为完整的描述。DevOps在2013年之后被业界快速接受，源于相关技术的同步发展，2013年，dotCloud公司推出Docker项目，同年，Google推出开源项目Kubernetes，提供了以容器为中心的不部署、伸缩和运维平台，2015年云原生的概念也逐步成熟，他们的发展助推了DevOps的快速发展。
大家可能还听说过DevSecOps，Sec是不是安全，你猜的没错，就是安全和合规性，这是在2016年开始逐步推出的一个理念。关于历史的部分就讲到这里，大家感兴趣的可以再做进一步的了解。
大型企业实施 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很好，但却很难落地，大家对DevOps是怎么理解的？
DevOps不是一开始就有的，为什么现在的声音越来越大了。其实原因很简单，说明市场，也就是各软件公司碰到问题了，DevOps可以帮助解决这个问题，为客户创造价值。
那客户的问题又是什么呢？比如现在的互联网公司越来越多，市场的竞争也越来越激烈，产品迭代的频率越来越快，做得极致又成功的比如Netflix，可以做到一天发布好多次。如果还是像以前的模式，可能你的公司早就被淘汰掉了。
其实理解起来很简单，就像图上面一样Dev和Ops合作一起搞事情了（但上图的幽默用来隐喻实际的效果是刚刚好的）- 貌合神离。如果只管自己的一亩三分地，因为有各种KPI的原因，这也再正常不过。但试想一下，如果一家公司的KPI是：对开发团队，一个月内发布10个版本。对运维团队，线上环境可靠性是99.99%。很明显这样就会让开发团队和运维团队一下子变成了对立面。如果想快速发布版本，得过质量（测试团队）的关，还有运维团队的关，因为要上线，可能因基础设施等各种原因受到影响。再说运维团队，会很小心的测试，因为好容易弄稳定的环境，你又给我增加了新的风险，我当然不乐意了。
因为上面的种种制度的原因，再加上将Ops前置，导致的工作量和工作复杂度的加大，因为在软件行业，并没有因为新事务的出现，而消灭了一些复杂度，而是将复杂度从一个地方搬到了另一个地方。所以难度是变大了的。组织结构不动，观念不调整，就已经为DevOps落地埋下了失败的种子，再加上能力上需要提升，就会让这件好事情离成功越来越远。
萧田国：DevOps 时代，未来已来
如今，互联网的新浪潮云计算正席卷而来，“所有公司都会变成软件公司”这一趋势正在加速实现。如今，虽然互联网领先企业在软件研发效能方面已有诸多优秀实践。但对于互联网中小企业及广大传统企业来说，因缺少明确的方向和指引，变革步伐仍旧缓慢。如何将互联网一线名企的优秀实践分享给更多的企业，让更多的 IT 从业人员学习到落地实践经验，是我们不断摸索的动力。
本期节目的嘉宾是北京华佑 科技 有限公司的总经理萧田国先生，他是与互联网共同成长，沉浸行业十几年的知名 IT 专家，同时他也是业界 IT领袖，深受大家的喜爱。主持人对话北京华佑 科技 有限公司的总经理萧田国先生，共同探讨软件行业新风向。
萧田国，北京华佑 科技 有限公司总经理，DevOps 时代社区和高效运维社区发起人，DevOps 国际标准联合发起人，DAOPS 基金会中国区董事，开放运维联盟联合主席，GOPS 全球运维大会发起人，复旦大学特聘讲师。2004 年硕士毕业于北京 科技 大学，先后就职于联想集团、搜狐畅游、智明星通和触控 科技 等，十余年互联网运维及开发运维( DevOps)从业经验。
北京华佑 科技 有限公司(以下简称华佑 科技 )，成立于2015年，是一家提供 DevOps 和 RPA 等技术咨询服务以提升广大企业软件质量和研发效能的高新技术企业。华佑 科技 在中国信息通信研究院的牵头和指导下，协同组织互联网、金融和通信等行业名企，编写 DevOps 行业标准和国际标准，输出给广大企业，并较大程度地提高相关企业的软件质量和软件上线速度，提高企业的市场竞争力。华佑 科技 为广大企业提供高质量的技术咨询服务，帮助企业数字化转型。
华佑 科技 初期通过运营技术社区的形式，社区相关技术文章的阅读量达到千万级。同时社区也将 IT 技术从业人员聚拢在一起，多次举行线下千人技术峰会，为更多的软件行业从业者及企业提供了交流、学习和提升的平台和机会。四年间，凭借技术社区多年的耕耘和沉淀，华佑人 在 DevOps 等技术咨询领域打下夯实的基础，先后有工行、农行、中行、招商银行、浦发银行、腾讯、中信银行、PICC、华泰证券、中国移动和中国电信等名企，对于华佑 科技 的工作给予了充分的肯定。未来，华佑 科技 将目标定位为一家提供高端 IT 技术咨询及软件产品的企业，为传播新技术的火种，让企业数字化转型更高效而奋斗!
在采访中，萧老师提到：“正如吴军先生在《浪潮》一书提及的：无论是对于个人还是一间公司，赶上一波大浪潮无疑是最为幸运的。DevOps 是对于整个 IT 行业的浪潮。浪潮之下，我们能做的事更多，也更具有意义，我们致力于帮助更多企业实现 IT 的数字化转型。”从大厂运维总监到独立的创业人，从技术领袖到为企业数字化转型的领军者，萧老师具备着眼于未来的战略眼光及多年的IT一线实战经验，这些赋予更多企业敏捷化与智能化的无限可能。一路走来，萧老师的技术人生缤纷多彩，从一名传统运维工程师成长为 IT 变革带头人，从创立高效运维社区到举办享誉国内外的 IT 行业技术峰会，再到参与编写国际性的 IT 技术标准，萧老师带领着华佑 科技 一步一个脚印扎实成长，为中国 IT 行业发展与革新贡献着自己的力量!这份坚持与热爱让我们感动与钦佩!少年强则国强，希望有更多热爱 IT 事业的年轻人加入进来，为推动中国 IT 事业快速发展而相聚，为 科技 强国之路而共同奋斗!
关于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行业带来较大影响。
结语：以上就是首席CTO笔记为大家整理的关于Devops什么时候过时的全部内容了，感谢您花时间阅读本站内容，希望对您有所帮助，更多关于Devops什么时候过时的相关内容别忘了在本站进行查找喔。