导读：本篇文章首席CTO笔记来给大家介绍有关银行如何落地devops的相关内容，希望对大家有所帮助，一起来看看吧。
为什么DevOps很好，但却很难落地，大家对DevOps是怎么理解的？
DevOps不是一开始就有的，为什么现在的声音越来越大了。其实原因很简单，说明市场，也就是各软件公司碰到问题了，DevOps可以帮助解决这个问题，为客户创造价值。
那客户的问题又是什么呢？比如现在的互联网公司越来越多，市场的竞争也越来越激烈，产品迭代的频率越来越快，做得极致又成功的比如Netflix，可以做到一天发布好多次。如果还是像以前的模式，可能你的公司早就被淘汰掉了。
其实理解起来很简单，就像图上面一样Dev和Ops合作一起搞事情了（但上图的幽默用来隐喻实际的效果是刚刚好的）- 貌合神离。如果只管自己的一亩三分地，因为有各种KPI的原因，这也再正常不过。但试想一下，如果一家公司的KPI是：对开发团队，一个月内发布10个版本。对运维团队，线上环境可靠性是99.99%。很明显这样就会让开发团队和运维团队一下子变成了对立面。如果想快速发布版本，得过质量（测试团队）的关，还有运维团队的关，因为要上线，可能因基础设施等各种原因受到影响。再说运维团队，会很小心的测试，因为好容易弄稳定的环境，你又给我增加了新的风险，我当然不乐意了。
因为上面的种种制度的原因，再加上将Ops前置，导致的工作量和工作复杂度的加大，因为在软件行业，并没有因为新事务的出现，而消灭了一些复杂度，而是将复杂度从一个地方搬到了另一个地方。所以难度是变大了的。组织结构不动，观念不调整，就已经为DevOps落地埋下了失败的种子，再加上能力上需要提升，就会让这件好事情离成功越来越远。
DevOps Professional：实用的DevOps管理培训
EXIN DevOps管理培训体系
EXIN 全面的DevOps管理培训体系
EXIN DevOps ProfessionalTM，作为EXIN DevOps认证体系的实践层级认证
伴随DevOps Professional发布，EXIN DevOps认证体系已搭建起完整的框架。此次全新DevOpsProfessionalTM认证，是全球范围内唯一以DevOpsHandbook这本被誉为”DevOps领域的圣经“的集大成之作为核心教材的认证。
在认证发布前夕，EXIN组织全球讲师进行试点考试。24小时内，全球DevOps专家集中考试。日前放榜，中国讲师团独领风骚！
EXIN DevOps Program认证体系总览EXIN DevOps Program
No.1 认证体系架构
伴随DevOps Professional发布，EXIN DevOps认证体系已搭建起完整的框架。请注意，EXIN DevOps认证体系中各门认证均无前置认证要求，考生可根据自身情况选择考取合适的认证。
No.2 各门认证定价
各门认证及课程的具体价格方案如下：
说明：沙盘为1人1天的官方指导价格
* 考取以上任意三个方向认证即可获得EXIN DevOps Pre-Master认证
No.3 认证课程详情
No.4 课程定位
此门认证的主要目的是检测考生是否熟悉DevOps实践“三步工作法”。这三种方式包括：流Flow、反馈Feedback、学持续学习和实验Continuous Learning and Experimentation。通过学习和考试，考生将充分理解这些组织层面和技术层面的变革对其日常工作的影响。
如何选择 DevOps Master 还是 DevOps Professional ?
No.5核心内容
此门认证以DevOps Handbook为核心教材，具体模块比重详见图示。
No.6 全球讲师授权考试之中国授权讲师
No.7 全球讲师授权考试之中国授权讲师
全球DevOps专家与讲师参与了此次讲师授权考试，其中中国讲师团队11人，均分达到80分，位居全球各国之首。
欢迎爬楼，看更多北京老李-DevOps相关内容，ITIL内容请关注”豆列“
DevOps：转型从正确地认知开始
DevOps：从I型人才到E型人才
DevOps：智能服务台是企业不能缺少的基石
DevOps布道师:终身学习是终身成长的源动力
《把读到的知识转化为能力三步法及完美学习的四步法》
DevOps Master课程:脚踏实地学Pre-Master，一步一个脚印成为DevOps Master
DevOps布道师为深度工作写的序：深度工作是心身的一种修练方法
咨询基本功：咨询顾问基本功之书面沟通及“补充大餐”
DevOps定义编年史：通过DevOps定义看DevOps发展
DevOps应用：光大银行DevOps1.0到DevOps2.0研讨会
DevOps应用：民生银行IT一体化管理与自动化发展（1）
DevOps应用：工商银行DevOps进行时
DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）
敏捷辩论
敏捷服务管理：数字化转型核心
银行如何做好数字化转型升级？
数字化转型升级，通俗地讲，是企业运用互联网技术，达到营销、管理、服务等目的，并且能通过对互联网工具的使用，让企业重新定义商业模式，更有活力、更具有潜在的发展动力。
如此，数字化转型升级不仅仅是大企业的事情，任何一个企业哪怕是个人创业者，都可以运用数字化转型，达到自己的目的。
那么，银行的数字化转型怎样落地？
1、运用互联网工具，搭建自己的私域流量池。 银行需要用存量带增量，持续地做好引流，获取新生代的年轻客户，构建粉丝体系，做好私域运营，才可以维持业绩的稳定和利润。
2、使用好互联网工具，为银行打造一个价值千万的IP 。银行需要借助互联网工具，打造自己鲜明的IP，让客户在众多的银行里看到我们。互联网时代是注意力营销，用内容吸引注意力、用价值维持注意力，这是最好的广告。比如公众号的持续更新，吸引都是精准粉丝；视频号做到日更，也能每天有新的流量诞生；社群运营，可以为客户提供线上服务，形成复购和裂变的效益；
3、讲好银行的故事。 这是一个内容为王的时代，讲好自己的故事，就是用内容做广告。这样的广告温情和善，并且能够引起极好的共鸣，吸引一大批有共同感受和经历的粉丝。银行的故事可以从发展历程、经历了哪些事件、为客户做了哪些升级改变等这些方面入手。
4、做好产品矩阵。 之前的营销，是所有的产品都上架、所有的产品都交给客户自己去选择。现在的模式是，企业做好产品矩阵，分为引流产品、爆款产品、利润产品和价值产品。每一个产品的文案和海报设计都不一样，针对的人群也不一样，看似优惠很大，但其实利润很高。银行需要去思考如何构建自己的产品矩阵，如何为客户匹配合适的产品。
以上的这些内容，就是银行数字化转型的重要组成部分。因此不要畏难、不要排斥移动互联网时代带来的变革，这虽然是一个看上去很糟糕的时代，但这也一定是一个最好的时代，张开双臂去拥抱这个时代，做好数字化转型升级，为银行业即将迎来的金融快速发展打下基础！
大型企业实施 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。
精益思想在银行软件开发落地的一些思考
相比制造业，软件开发有其独特之处，”精益思想“落到方法、实践层面，需要做针对性的变通。
软件产品开发相对生产制造产品开发的不同可归类为：1）价值的不确定性；2）过程的不确定性。 价值不确定性 ，体现在：1）客户价值本身存在不确定性、无法一开始就精准定义且随时处于演变之中；2）行业处于快速变化和不确定之中。以上各种不确定性，所反映的本质可汇聚为一点，即 “变化“是软件开发的一大核心主题 ，这决定了精益软件开发 需要突出”迭代能力“ ，组织模式上需要更加扁平化。至于软件开发的 过程不确定性 ，则体现为每一次软件项目的开发过程 都是某种程度的创造过程 ，其中都有相当量的具体工作细节是无法提前精准确定的，事实上， 也正是软件开发工程师的核心价值体现之一 。
精益思想，应用到软件开发项目上，就是要让业务成功成为检验软件项目的唯一标准！
精益思想强调拉动式生产，即用户价值拉动，要确保下游的需要往上游生产环节的及时、准确的高效传递，不光让价值流动起来，还必须保证流动的是用户想要的价值。做到这一点的最佳手段是让最下游的客户价值（如用户订单）拉动整个价值流。——联系到银行信息科技的生产，就是要让信息科技的开发等工作是直接由用户对产品、服务的需求来拉动的；这里， 对“用户的需求”与“业务部门的需求”是要加以区分的 ，用户是指银行的最终用户（对公、对私） 。
为什么银行信息科技工作，在银行的整个运转体系里，总是容易陷入一种后台支持角色的状态？根本原因之一，就是信息科技部缺乏对用户价值拉动的直接感知。科技部门的所谓响应需求，完全是在对业务部门的想法进行响应，完全没有参与、也不用对最终用户价值的实现、流动负责。
这不是单单凭借信息科技部的力量所能改变的。
当然，业务部门也很委屈，他们已经在很努力的响应市场、捕捉客户需求，并已经在竭尽全力地提炼需求并传递给科技部门，并积极地推动科技部门又快又好的按需求规划交付系统。并且，为了能够最有有效地对接市场需求，业务部门作为一个一线环节，其必要性、重要性也是毋庸置疑的。
问题出在哪里呢？
是因为传统的银行架构决定了科技部门是被隔离在业务部门后面的，是不用直接接触用户一手需求的，更不用直接参与用户价值交付场景的。
正如何勉在《第一性原理和精益敏捷的规模化实施》一文中指出的， 组织架构的模式将决定价值流动的模式 。因此，从组织架构的模式这个源头就要基于用户价值的需要做出统筹安排。业务部门与信息科技部门之间，应该改变先后顺序、改变相互关系，科技部门不应该是对业务部门负责，业务部门也不应该是系统的最终验收者、不应该完全独扛系统的最终市场效果； 科技部门、业务部门应该共同作为敏捷小组的组员，互为顾问，科技部门是业务设计的技术顾问，业务部门是科技部门的业务顾问，双方共同直接对用户价值的最终实现效果承担责任 。
业务的成功（可以是小成功到大成功，简单成功到复杂地系统性成功）才是检验醒目、验收项目的唯一标准。 如果需要一个统筹者角色，那就是产品经理（或称为，敏捷小组的项目经理）。
附摘记一、理解精益思想的三个层面：价值观、方法论、实践集。
价值观 ：2001年问世的16页的《丰田之道》“丰田之道–2001”。它申明：尊重人和持续改进是精益价值观的核心。在这两个主题下具体又包含5个价值观，它们分别是，归属于持续改进的：挑战现状、改善和现地现物；归属于尊重人的：尊重和团队协作。“不给客户带来任何麻烦”——生产中的下一个环节也是自己的客户。
方法论 ：《精益思想》总结了精益的5个原则，这5个原则同时也是5个实施步骤。
实践集 ：从价值观到实践集，其操作性是越来越强的，同时，行业特性也越来越强，通用性也越来越低。就丰田的精益制造TPS而言，其成功的各种实践手段有看板（支撑准时化的重要工具），“一分钟换模”等。
附摘记二、产品开发与产品制造的不同之处：
附摘记三、精益产品开发的目标、方法学和实践：
目标 ：顺畅、高质量、有用的价值
方法 ：探索和发现有用价值、让价值顺畅流动——聚焦和提升价值流动效率
大野关注的是用户价值，以及价值流动的过程，所谓浪费是指一切从用户角度看无意义的行为和等待。这与德鲁克所说“任何组织的绩效都只能在它的外部体现”是一致的，这一思想同样适用于产品开发。
聚焦和提升价值流动效率，是精益产品开发的原则，也是精益产品开发与传统开发方法的又一本质区别。
实践 ：分为管理实践和技术实践。
管理实践的第一部分是精益创业和创新实践，解决的问题是发现、验证和探索价值。第二部分是精益需求分析和管理实践，解决的问题是如何有效的拆分、规划、分析和沟通需求。第三部分是精益看板方法实践。
技术实践则可围绕DevOps展开。
附摘记四、自働化
1. 働，人字旁的动，自働化。自働化是“内建质量”（Build Quality In）的基础，依赖每个环节保障质量，而不是依赖于最后的检测环节。
2.准时化和自働化是矛盾的统一体。
附摘记五、敏捷地初心
重要的是不忘初心，记住敏捷的业务目标——更早地交付价值，更灵活地应对变化。
附摘记六、传统软件的悖论
在知识最不充分的时候，做出了最重要的决定，并把它作为其后的基准，这就是传统开发下知识累积和决策时间之间的悖论。
流程本身有自我复杂化的趋势，对软件开发十分重要的人的能动性反而受到压制。
结语：以上就是首席CTO笔记为大家介绍的关于银行如何落地devops的全部内容了，希望对大家有所帮助，如果你还想了解更多这方面的信息，记得收藏关注本站。