导读：本篇文章首席CTO笔记来给大家介绍有关DevOps怎么消除浪费的相关内容，希望对大家有所帮助，一起来看看吧。
devops的优势有哪些？
DevOps 有哪些优势？
有“2020 年 DevOps 趋势调查”表明，99％ 的调查对象表示 DevOps 对他们的组织产生了积极影响。DevOps 的优势包括更快且更轻松的发布、团队效率、更高的安全性、更高品质的产品，以及更高的团队和客户满意度。
速度
更频繁地实践 DevOps 发布可交付成果的团队具有更高的品质和稳定性。事实上，DORA 2019 年 DevOps 状况报告发现，精英团队的部署频率和速度分别比表现不佳的团队高出 208 倍和 106 倍。持续交付使得团队可以使用自动化工具来构建、测试和交付软件。
改进协作
DevOps 的基础是开发人员和运营团队之间的协作文化，他们会分担责任，协调工作。此举可以提高团队的效率，并省去工作交接和编写专为其运行环境而设计的代码的时间。
快速部署
通过提高发布的频率和速度，DevOps 团队可以快速地改进产品。快速发布新功能和修复缺陷有助于获得竞争优势。
质量和可靠性
持续集成和持续交付等实践可确保变更正常运行且安全无误，从而提高软件产品的质量。监控则有助于团队实时了解性能。
安全性
通过将安全性集成到持续集成、持续交付和持续部署管道中，DevSecOps 成为开发过程中一个活跃的组成部分。通过将主动安全审计和安全测试集成到敏捷开发和 DevOps 工作流中，可将安全性植入产品内。
Devops 不是任何一个个人的工作，而是每个人的工作。
从传统的基础架构转向使用基础架构即代码 (IaC) 和微服务可以加快开发和创新速度，但增加的运营工作量可能极具挑战性。最好为自动化、配置管理和持续交付实践奠定坚实的基础，以帮助减负。
过度依赖工具会使团队偏离 DevOps 的必要基础：团队和组织结构。一旦建立了结构，就应该建立流程和团队，然后确定工具。
为什么DevOps的必然趋势是BizDevOps
编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：，下载完整版电子书，了解阿里十年DevOps实践经验。
本文作者：何勉，阿里云云效资深技术专家
谈到DevOps，就必须从敏捷和精益开发说起。DevOps在它们基础上发展而来，借鉴了其中的方法、理念，并发展和完善了它们的实践体系。
敏捷软件开发的实践最早出现在上世纪90年代。当时，一批轻量的软件工程方法和框架相继诞生，它们共同的特点是，相对传统软件工程，都遵循演进和迭代的模型，过程更加轻量灵活。其中Scrum和极限编程（ExtremeProgramming）在实践上最为成功，影响最大。它们都是迭代和增量的软件开发框架，区别是Scrum只包含管理实践，而极限编程则同时涵盖工程和管理实践。
上世纪90年代，PC软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，让小型项目的开发蓬勃发展。同时，互联网应用和开源社区兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用得到凸显。
这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，这部分促使了源自全面质量管理体系的CMM/CMMI在这一时间的繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到了新的可能。敏捷运动这时已经呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。
2001年2月，17位轻量级软件工程方法的代表人物，齐聚美国犹他州的雪鸟滑雪胜地，其中也包括Scrum和极限编程的几位发明人。在两天的会议之后，发布了后来产生巨大影响的敏捷宣言(参见 )，敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念，同样重要的是他们找到了敏捷这个词来总领这些理念。
敏捷概念在2001年出现，可以说适逢其时。当时，一方面传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展的最好助推剂。
敏捷宣言发布后，敏捷成为了一场运动，被迅速地推广和应用。但是，早期的敏捷专注的还是研发交付阶段，站在业务的角度，它的目标是帮助产品和研发团队提升敏捷响应能力，也就是：“更早地交付价值，更灵活地应对变化”。然而，在企业数字化转型的背景之下，IT不仅要保证产品的开发和交付，系统部署和运行同样重要。DevOps继承了敏捷开发的理念，又补上了运维的部分，但DevOps绝不是开发和运维的简单叠加，这个我们后面还会说到。
精益思想最早源自生产制造领域，根源于丰田在产品制造中管理和工程实践。1988年《斯隆管理评论》的一篇论文《精益生产系统的胜利》比较了西方的生产方式和丰田生产方式在效率和质量上巨大差距，挑战了规模生产带来效益的神话。从此，精益开始进入西方的视野，逐渐成为现代管理学的重要组成部分。
《精益思想》一书将精益定义为：有效组织人类活动的一个新的思维方法，目标是消除浪费，以更多地交付有用的价值。书中进一步总结了精益的5个原则，同时也是精益的5个实施步骤：
在这个抽象层次上，精益思想超越了其诞生的制造业，深刻影响了各个行业，如精益政务、精益医院、精益领导力、精益服务业、精益供应链、精益教育等，这其中也包含产品开发。事实上，主流的敏捷开发方法都直接受到了精益思想的影响，遵循精益的基本原则。
与此同时，精益产品开发作为独立的实践体系也快速发展，它聚焦两个方面的目标——价值交付过程和价值本身。
精益创业认为创业是一个巨大不确定的过程，其最大的浪费是交付没用的（不能解决用户问题，或带来业务成功）的东西。为此它把价值的 探索 和发现融入产品交付过程，提出了著名的“开发-测量-学习”循环。循环从关于市场和产品的待检验概念开始。接下来，循环的第一步是开发用以验证这一概念的最小可行产品（MVP，Minimal Viable Product）；第二步：基于最小可行产品收集市场、用户的反馈，并获得测量数据；第三步：用数据验证假设，证实或证伪它们，并加以调整，产生经实证的认知。然后，进入下一循环，持续 探索 商业模式和产品功能设计。
精益创业的影响远超初创公司，事实上“精益创业”一书中把“创业”定义为在不确定的环境下，开创新的业务和产品。而“不确定性”似乎已成为今天IT领域身处环境的共性，也因此，MVP、“开发-测量-学习”循环等理念已成为IT创新领域公认的实践，并且围绕精益创业发展出一套完整的创新实践体系，如精益数据分析、精益客户开发、精益交付设计等。
探索 和发现有效的价值，并让价值顺畅流动。围绕这两个目标，并遵循精益思想，精益产品开发已经发展成为系统的实践。精益思想对DevOps的影响也非常根本，DevOps三原则就完全遵循了精益思想。
在传统的IT组织下，开发团队（Dev）和运维团队（Ops）之间诉求不同——开发团队（尤其是敏捷团队）追求变化，运维团队追求稳定。双方往往存在利益的冲突，比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于IT价值的最大化。
2009年，在美国举行的第二届Velocity大会上，来自Flickr公司的John Allspaw和Pauk Hammond发表了一个演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在这个演讲中，Allspaw和Hammond以角色扮演的方式，生动地表现了开发与运维之间的各种冲突。演讲中出现很多金句，如“It's not my code, it's your machines!”，这深刻反映了Dev和Ops关系的现状。接着，他们又展示了如何通过消除开发团队（Dev）和运维团队（Ops）的壁垒，双方通力合作，借助工具和文化的改变让软件的发布和运维变得持续和高效。
这次演讲是DevOps发展历程中的标志性事件。它提出了正确的问题——为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案——为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革。
同一年，比利时独立IT咨询师Patrick Debois看到这个演讲，受到启发，组织了第一届DevOpsDays，DevOps正式登上舞台，DevOps的理念开始流行，其相关的工具和实践也快速发展。期间以容器化和自动编排调度为代表的云原生技术的出现也极大加速了这一进程。今天，DevOps已成为企业数字化的核心能力之一，是对IT交付和运行的基本要求。
其后，在《凤凰项目》和《DevOps实践指南》两本书中，Gene Kim等人总结了DevOps实施的三步工作法，它们分别是:
流动原则：聚焦IT系统的整体价值流，全局优化，保证价值从左（上游）到右（下游）的快速流动。
反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。
持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。
Kim等人认为，这三步工作法是其他一切DevOps流程、实践的价值和哲学根基，所有DevOps模式都可以从这三个原则派生而来。
稍作探究，就能够觉察，DevOps三步工作法是精益原则的翻版。更确切的讲，是精益原则在IT开发和运行上下文中的具体实例。事实上，DevOps的基础部分，体现了精益原则的影响和应用。
回顾敏捷、精益和DevOps的发展，我们可以得出如下两个结论。
第一，DevOps 是敏捷开发实践的自然发展。敏捷开发的目标是“更早地交付价值，更灵活地应对变化”。敏捷运动始于开发侧，但运维侧如果不做改变，就一定会成为瓶颈，最终敏捷的目标还是无法达成。为了让敏捷实践发挥真正的价值，开发运维的联动就势在必行了。
第二，DevOps是精益思想应用在IT领域的必然结果。精益产品开发的目标是：“顺畅的交付有效价值”，精益思想则要求端到端的系统优化和持续的改进。而开发和运维是系统的两个重要组成部分，缺一不可。DevOps三原则，正是精益思想在IT开发运维领域的具体实例。
最后，从精益思想出发，我们可以看到DevOps的必然发展方向，那就是向业务侧延伸。业务是产品开发和运维的源头，完整的价值流必须从源头开始。这不是预测，而是正在发生的事实，大部分DevOps的实施都已经将业务侧包含在内，成为BizDevOps，只不过DevOps的称谓已经深入人心，我们也将延续DevOps的说法，但缺省情况下，它包含了业务在内。
DevOps发展的同时，数字化转型也成为了企业界的共识，大部分企业数字化框架都把DevOps作为最核心的能力之一，DevOps的影响范围也不断扩大，成为力求提升数字化能力的企业必然选择。下一节我们将在数字化转型这一背景下，分析DevOps要解决的根本问题。
「链接」
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.（通往成功的道路，永远在建设之中） 。
大型企业实施 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如何提升企业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这家公司，他们比较熟悉这块。
结语：以上就是首席CTO笔记为大家整理的关于DevOps怎么消除浪费的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～