导读：今天首席CTO笔记来给各位分享关于如何开展devops的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
请问：企业如何快速实现DevOps转型？
提出这个问题首先是否要思考一下：快速实现DevOps转型的目的是什么？
DevOps转型会面临哪些难题，哪些挑战作为CTO的你是否心中清晰？
采用 DevOps 会面临哪些挑战？
原有的习惯很难改变。深陷孤立工作方式的团队可能会难以应对，甚至抗拒彻底改变团队结构以采用 DevOps 实践。某些团队可能会错误地认为有了新工具就足以采用 DevOps。但是，DevOps 是人员、工具和文化的结合。DevOps 团队的每一个人都必须了解整个价值流，从构思、开发到最终用户体验。它要求打破孤岛，以便在整个产品生命周期中进行协作。
最终要明白——
Devops 不是任何一个个人的工作，而是每个人的工作。
从传统的基础架构转向使用基础架构即代码 (IaC) 和微服务可以加快开发和创新速度，但增加的运营工作量可能极具挑战性。最好为自动化、配置管理和持续交付实践奠定坚实的基础，以帮助减负。
过度依赖工具会使团队偏离 DevOps 的必要基础：团队和组织结构。一旦建立了结构，就应该建立流程和团队，然后确定工具。
如何采用 DevOps？而不是如何快速转型为DevOps团队，否则可能欲速则不达。
首先，采用 DevOps 需要致力于评估且可能更改或删除组织当前所用的所有团队、工具或流程。这表示需要构建必要的基础架构，以便团队能够自主构建、部署和管理其产品，而不必过分依赖于外部团队。
DevOps 文化
DevOps 文化是指团队采用新工作方式（包括加强合作和沟通）的环境。这是人员、流程和工具的协调一致，以实现更加统一的客户导向服务。多学科团队负责产品的整个生命周期。
DevOps如何提升企业IT效率的
DevOps最基本的一个功能，或者说优势，就是它可以将产品的开发团队跟运营团队合并成一个具有凝聚力的“个体”，而这样就可以很大程度地提升工作效率。
devops加快交付速度
devops填补了之前的空白部分，devops通过建立一个完整的生命活动周期，devops关注如何更好地获取IT运维团队的反馈。devops将敏捷原则应用于管理领域，devops使得开发人员和管理员可以进行毫无障碍的沟通。
devops还有很多不足，devops导致代码交接容易出现延迟。devops同样的情况也会出现在重大bug的修复过程中。
devops运行时软件优化
devops可以在两个方面提升知识水平和程序质量。首先，devops对于许多较新的、面向对象的操作系统，比如Linux，devops很有可能不关机而一直保持运行状态。因此，devops容易出现问题，比如错误的垃圾回收机制以及不能正确重新组织关系型数据存储。
devops借鉴了大型机管理员积累的经验来重新认识软件平台类型，以及可能引起这些类型问题的开发和/或测试流程。devops开发团队可以使用嵌入式模式保护代码来部署代码库和测试环境。
devops的目标是在测试环境中，或者devops以代码的形式嵌入到应用程序自身当中以获取大型机复杂性的现有知识，devops不希望大型机管理员发现问题所在。devops并不仅可以使得开发人员和测试人员的工作更加轻松，同样可以简化管理员的工作。
devops提高大型机管理员工作效率
devops可以改善这种大型机管理模式，devops提高大型机管理员的工作效率。首先，devops通过实现标准配置和Linux相关任务的自动化，devops可以保证管理员拥有更多时间来“救火”。devops通过确保解决方案是长期有效和高质量的来减少对于处理紧急情况的处理需求。此外，devops让管理员也参与敏捷开发流程，和开发团队进行沟通，当开发团队拥有了一个能够快速定位问题并且修复运行时问题的测试工具或者代码库之后，devops就可以减少管理员修复bug以及与开发部门协调所花费的时间。
您可以关注servicehot这家公司，他们比较熟悉这块。
DevOps的设计实践
起初对于DevOps的概念的理解仅仅停留在“使用Bamboo自动化部署服务到指定环境上”，当我们开始尝试着对DevOps的流程开始做推广，首先确定的方案是，推动各组使用Bamboo做CI/CD的集成，第二是针对当前项目面临管理混乱的痛点问题，进行项目发版采用语义化版本管理。但正如康威定律所言，“设计系统的组织其产生的设计等价于组织间的沟通结构。”，我们不能仅仅在一次讨论中确定的方案就企图变革组织间的长达几年的沟通协作习惯。并且DevOps也不简单是一个普适的解决方案，它是一个 平台（Platform）、流程（Process）和人（People）的有机整合。
根据 martinfowler博客 中发表的对DevOps文化的见解（如下图），他认为DevOps文化中最重要的原则是 责任共担和质量导向 。在这点上，我认为我司有天然的优势，在项目开展的初期，包括当前项目运行生命周期中，研发包揽了大部分运维工作。可以说我们不从来不缺敢于担责的“勇士”。但同时，在我司大幅扩招的现状中，加强流程管理，保证这种文化的延续，同时在人员流动中能动态的加强文化导向，这是DevOps指导思想中重要的一环。
工具 = 平台+ 流程，首先，平台最重大的意义是承载企业内部的标准化流程，平台固化的每种流程，都可以用来解决某些实际问题，这样就会形成一下特征：
通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。
任何方法论不结合企业实际的现状来分析都是耍流氓（无处不在的康威定律），那么对于我司的实际现状，建立这一套体系能解决哪些问题呢？在和研发童鞋讨论问题的时候，能看到他们往往是处于只见树木不见森林的状态，整个“森林”往往是被少数的人所掌握的，这点在季度述职时候已经被不少人提出来过。诚然我们作为安全公司，部分产品是敏感且需要保密的，但是从整个层次和架构来讲，我们需要适配一套流程，达到 对技术开放，对数据加密 ，安全的流程正是SecDevOps需要解决的问题。同时这也很切合“三步工作法”中 流动 原则，只有 把复杂的流程简单化，可视化 我们才有机会让更多的人看见森林。而目前结合生态，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，DevOps作为软件工程的第三次革命，总结来看它的价值体现在以下两点：
让一切软件交付过程的手动环节，都是未来可以尝试进行优化的方向。DevOps倡导职责共担，持续改进是需要将规则内建于工具之中，并通过工具来指导实践。如果仅仅是把线下的流程搬到线上执行，是没法发挥DevOps真正的价值。说到底，工具没法解决人的问题，这样一条看似取巧的路径，却没法解决企业的根本问题。这时候，就需要文化闪亮登场了。
总而言之，DevOps 中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。我们要做的是 关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。
敏捷管理不仅仅与研发敏捷，同时也要针对于业务敏捷， 开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想。
另外通过“研发一体化流程”图示，我们也能见微知著。在我司目前在产品使用JIRA的看板形式做需求管理，这套流程在敏捷业务管理中已经有很好的天然优势， 我们需要做的是打通产品和开发的交流屏障 ，这部分流程以及功能，在我们的排期中暂时靠后，现未有具体实施方案，目前仅给出 BizDevOps 的核心理念：
关于持续交付功能，是初期内我们重点投入的阶段，这也是作为研发真正的用武之地，首先面临着第一个问题，自研OR开源？在我们开始做DevOps之前，已经有了部分在用的优秀开源工具作为支撑点，Jira、Bamboo、BitBucket。这些工具一定程度上减少了我们初期的工作量，在后续的项目计划中，我们做了基础存储，权限、DevOps流程等多方调研。关于存储和权限这类基础架构目前都有着成熟的开源解决方案。但是DevOps流程关联公司TOG的业务性质，以及目前的项目现状，我们选择自研平台，主要的规划方向有：
1.版本控制、变更管理
主要核心思想是： 版本变更标准化，将一切纳入版本控制，全流程可追溯和单一可信数据源。 ，一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。
2.持续构建和持续集成、部署与发布的模式
主要核心思想是：用自动化的方式完成从项目编译到发布的流程
3.环境的搭建管理、元数据、初始数据的管理
这是目前我们项目发布中的瓶颈，配置、初始化数据应当纳入版本控制，同时制定标准的业务流程；
4.度量与反馈
针对于交付效率、交付能力、交付质量做指标统计，以及建立可视化平台。主要的指标包括， 需求前置时间、开发前置时间、发布频率、发布前置时间、交付吞吐量、线上缺陷密度、线上缺陷分布 等。
5.内建质量、保证测试
内建质量有两个核心原则 ：
在为期近4个月的DevOps实践中，我们主要做了三件事情， 部分项目Bamboo的集成、基础架构的建设、DevOps平台的开发 。
初期我们做了一些关于DevOps的调研和实践，在 尽可能采用开源项目 的原则上，依赖于现有的技术结构，摸出了一套关于Bamboo的使用流程
开源OR自研？这永远是一个需要不断权衡和取舍问题，之前我们已经谈论到持续交付要做的事情有哪些，当开源组件不能Cover我们当下的流程，自研平台自然得上线了
基于上图我们可以看到FlowDevOps平台的基本的交互和流向。平台开发到现在经历了四个小版本的迭代，主要包含以下几个特性：
值得一提的是，我们选型了Jinja2作为配置模块统一管理，对各个环境公共组件的地址存放与平台，保证了服务离线部署中各类连接出错的问题。同时这种方式对业务的侵入较小，符合我们短期内提升部署效率的预期。
诚然，DevOps的建设在短期内已经做了不小的工作量，但是还是存在一定程度的问题。包括以下方面：
根据全球云计算峰会成熟度模型预估来看
在我司云原生于我们似乎是非常遥远的，陌生的技术栈，各类反直觉的故障。但是为什么我还是坚持认为云原生是我们未来建立DevOps，以及发展基础设计的最佳实践呢？引用CNCF对云原生的官方定义：
关键词有 开源软件、微服务应用、容器化部署和动态编排 ，虽然我们目前部分业务场景有传输相关的瓶颈，容器化则可能带来更大的存储体积。但从宏观角度来看，这并不是大部分项目的现状，而我们更多的项目核心的问题在于 数据量大、业务和配置复杂、依赖模块多 。而云原生应用天生就和DevOps 是绝配，自带高可用、易维护、高扩展、持续交付的光环，同时原生支持微服务、不可变基础设施以及服务网格这些技术领域，能天然解决业务复杂，依赖模块多的现状。
这也是我在基础设施建设工作中，坚持积累云原生技术方案的原因，云原生的技术方案，我始终认为它能大大推进我司效率建设和技术发展。即便我们在云原生的方案技术积累还不足够，比如还不能确认大数据在容器中运行的效率这类技术问题，但是当我们建设起更具效率的运营一体化流程，也就有更多的资本去进行试错，这片星辰大海等待我们去探索。
我们都期待完美，但在绝大多数时候，任何事情都不可能完美。软件更是如此，DevOps亦是如此。我们能做的就是基于每次的反馈，一点点的改进流程，一次次的反思提高。在不断的持续改进中，可能永远触及不到完美，但是就像美国著名女演员莉莉·汤姆林（Lily Tomlin）的那句经典名言所说的那样： The road to success is always under construction.（通往成功的道路，永远在建设之中） 。
F5如何帮助公司推进DevOps这种新型工作模式？
了解的情况是这样的。
具体方案如下：DevOps可以大幅度地提升企业的生产效率。而F5在这个层面上可以提供非常好的入口：在数据层面上，企业可以用irules做各种各样的编程。譬如，你可以基于用户的地理位置提供更好的有针对性的服务（譬如用户周围有没有餐馆、有没有滴滴打车、有没有mobike、最近的mobike在哪里），这些都可以通过irules实现；在控制层面上，F5的icall可以根据业务的各种流量的特征或者出现的各种事件来触发调整设备的配置；在管理层面上，我们可以跟各种的编排软件实现无缝的合作。在接口层面，F5有非常完善的模板。借助模板可以减少IT系统99%的配置上的错误，从而让你的应用在第 一次上线的时候就能够非常好地交付服务。
大型企业实施 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
在软件开发的过程中，开发人员负责编写代码，然后将代码交给 QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去布署。
DevOps 就是 Development（开发）和 Operations（运维）两个词的组合。但这里的组合并不是简单地将两个团队合并，而是要从思维和流程上变革，根据 DevOps 思想重新梳理全流程的规范和标准。
DevOps 既是一种思维方式，同时也是一种工作方式，作为一套促进开发、技术运营和质量保障三个部门之间的沟通、协作与整合的方法论，使得组织的快速迭代，实现竞争优势成为现实。
在 DevOps 的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。
DevOps 的实施，打破了团队内各角色的职能壁垒，让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件开发的整体过程更加快捷和可靠。
结语：以上就是首席CTO笔记为大家介绍的关于如何开展devops的全部内容了，希望对大家有所帮助，如果你还想了解更多这方面的信息，记得收藏关注本站。