导读：今天首席CTO笔记来给各位分享关于devops什么时候交付的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
什么是DevOps
什么是DevOps？
DevOps 是一套实践、工具和文化理念，可以实现软件开发团队和 IT 团队之间的流程自动化和集成。它强调团队赋能、跨团队沟通和协作以及技术自动化。
DevOps 运动始于 2007 年左右，当时软件开发和 IT 运营社区开始担忧传统的软件开发模式。在此模式下，编写代码的开发人员与部署和支持代码的运营人员会独立工作。DevOps 这一术语由“开发”和“运营”两个词构成，它反映了将这些领域整合为一个持续流程的过程。
DevOps 如何运作？
DevOps 团队包括开发人员和 IT 运营人员，他们在整个产品生命周期中进行协作，以提高软件部署的速度和质量。这是一种全新的工作方式，也是一种文化转型，对团队及其工作的组织具有重大影响。
在 DevOps 模式下，开发和运营团队不再是“孤立”的。有时，这两个团队会合并为一个团队，合并后工程师会参与整个应用生命周期中的工作（从开发和测试到部署和运营），并具备多学科的技能。
DevOps 团队使用工具实现流程自动化，并加速流程，这有助于提高可靠性。DevOps 工具链可帮助团队处理重要的 DevOps 基础事项，包括持续集成、持续交付、自动化和协作。
DevOps 的价值有时也会应用于开发团队以外的团队。当安全团队采用 DevOps 方法时，安全性则成为开发过程中一个活跃的组成部分。这就是所谓的 DevSecOps。
DevOps 生命周期
由于 DevOps 的连续性，从业人员使用无限循环来展示 DevOps 生命周期各个阶段之间的相互关系。尽管看似是按顺序进行的，但此循环实际表示需要在整个生命周期进行持续协作和迭代改进。
DevOps 生命周期由六个阶段组成，它们分别代表开发（循环的左半部分）和运营（循环的右半部分）所需的流程、功能和工具。团队会在每个阶段进行协作和沟通，以保持一致性、速度和质量。
规划
DevOps 团队应采用敏捷开发实践来提高速度和质量。敏捷开发是一种用于项目管理和软件开发的迭代方法，可帮助团队将工作分解成更小的部分，从而提供增量价值。
构建
Git 是一个免费的开源版本控制系统。Git 可为分支、合并和重写存储库历史记录提供出色的支持，而这已为开发构建流程带来了众多极具创新且功能强大的工作流和工具。
持续集成和交付
CI/CD 可让团队频繁且可预测地发布高品质产品，其范围涵盖从源代码存储库到使用自动化工作流的生产环节。团队可以频繁地合并代码变更、部署功能标记以及集成端到端测试。
监控和警报
快速识别并解决影响产品正常运行时间、速度和功能的事务。自动通知您团队有关变更、高风险操作或故障的信息，以便保持服务的运行。
运维
管理面向客户的端到端 IT 服务交付。这包括设计、实施、配置、部署和维护支持组织服务的所有 IT 基础架构过程中涉及的实践。
持续反馈
DevOps 团队应对每个版本进行评估，并生成报告以改进未来版本。通过收集持续反馈，团队可以改进其流程，并采纳客户反馈以改进下一个版本。
DevOps 工具
DevOps 工具可应对 DevOps 生命周期的关键阶段。它们通过帮助改进协作、减少上下文切换、引入自动化以及实现可观察性和监控功能来支持 DevOps 实践。
DevOps 工具链通常遵循两种方法：一体化或开放式工具链。一体化工具链提供完整的解决方案，通常不会与其他第三方工具集成。开放式工具链则允许使用不同工具进行自定义。这两种方法各有优缺点。
DevOps 有哪些优势？
有“2020 年 DevOps 趋势调查”表明，99％ 的调查对象表示 DevOps 对他们的组织产生了积极影响。DevOps 的优势包括更快且更轻松的发布、团队效率、更高的安全性、更高品质的产品，以及更高的团队和客户满意度。
速度
更频繁地实践 DevOps 发布可交付成果的团队具有更高的品质和稳定性。事实上，DORA 2019 年 DevOps 状况报告发现，精英团队的部署频率和速度分别比表现不佳的团队高出 208 倍和 106 倍。持续交付使得团队可以使用自动化工具来构建、测试和交付软件。
改进协作
DevOps 的基础是开发人员和运营团队之间的协作文化，他们会分担责任，协调工作。此举可以提高团队的效率，并省去工作交接和编写专为其运行环境而设计的代码的时间。
快速部署
通过提高发布的频率和速度，DevOps 团队可以快速地改进产品。快速发布新功能和修复缺陷有助于获得竞争优势。
质量和可靠性
持续集成和持续交付等实践可确保变更正常运行且安全无误，从而提高软件产品的质量。监控则有助于团队实时了解性能。
安全性
通过将安全性集成到持续集成、持续交付和持续部署管道中，DevSecOps 成为开发过程中一个活跃的组成部分。通过将主动安全审计和安全测试集成到敏捷开发和 DevOps 工作流中，可将安全性植入产品内。
采用 DevOps 会面临哪些挑战？
原有的习惯很难改变。深陷孤立工作方式的团队可能会难以应对，甚至抗拒彻底改变团队结构以采用 DevOps 实践。某些团队可能会错误地认为有了新工具就足以采用 DevOps。但是，DevOps 是人员、工具和文化的结合。DevOps 团队的每一个人都必须了解整个价值流，从构思、开发到最终用户体验。它要求打破孤岛，以便在整个产品生命周期中进行协作。
Devops 不是任何一个个人的工作，而是每个人的工作。
从传统的基础架构转向使用基础架构即代码 (IaC) 和微服务可以加快开发和创新速度，但增加的运营工作量可能极具挑战性。最好为自动化、配置管理和持续交付实践奠定坚实的基础，以帮助减负。
过度依赖工具会使团队偏离 DevOps 的必要基础：团队和组织结构。一旦建立了结构，就应该建立流程和团队，然后确定工具。
如何采用 DevOps？
首先，采用 DevOps 需要致力于评估且可能更改或删除组织当前所用的所有团队、工具或流程。这表示需要构建必要的基础架构，以便团队能够自主构建、部署和管理其产品，而不必过分依赖于外部团队。
DevOps 文化
DevOps 文化是指团队采用新工作方式（包括加强合作和沟通）的环境。这是人员、流程和工具的协调一致，以实现更加统一的客户导向服务。多学科团队负责产品的整个生命周期。
持续学习
在 DevOps 方面表现良好的组织鼓励进行实验和一定程度的冒险。在这些组织中，跳出固有思维模式是常态，而失败则被理解为学习和进步的自然组成部分。
敏捷
敏捷开发方法在软件行业中非常受欢迎，因为它们赋予了团队内在的灵活性、出色的有序性以及响应变化的能力。DevOps 是一种文化转型，可促进软件构建和维护人员之间的协作。搭配使用敏捷开发和 DevOps 时，可提高效率和可靠性。
DevOps 实践
持续集成
持续集成是将代码更改自动集成到软件项目中的实践。它允许开发人员频繁地将代码更改合并到执行构建和测试的中央存储库中。这有助于 DevOps 团队更快速地修复缺陷、提高软件质量以及缩短验证和发布新软件更新所需的时间。
持续交付
持续交付通过自动将代码更改部署到测试/生产环境中来扩展持续集成。它会沿着持续交付管道推进。而在此管道内，自动化构建、测试和部署会被编排为一个发布工作流。
情境意识
对于组织中的每个成员来说，能够访问他们需要的数据以尽可能高效和快速地完成他们的工作可谓至关重要。团队成员需收到部署管道中的故障警报（无论是系统性故障还是由于测试失败引起的故障），并及时收到在生产中所运行应用的运行状况和性能的最新信息。指标、日志、跟踪、监控和警报都是团队了解其工作进展所需的重要反馈来源。
自动化
自动化是其中一个最重要的 DevOps 实践，因为它能让团队更快速地完成高品质软件的开发和部署流程。利用自动化，将代码变更推送到源代码存储库的一个简单操作便可触发构建、测试和部署流程，从而大大减少这些步骤所花的时间。
基础架构即代码
无论您的组织是拥有本地数据中心，还是完全托管在云中，能快速、一致地调配、配置和管理基础架构是成功采用 DevOps 的关键。基础架构即代码 (IaC) 不仅仅是编写基础架构配置脚本，它还将基础架构定义视为实际代码：使用源控制、代码审查、测试等。
微服务
微服务是一种架构技术。在此技术中，应用被构建为一系列可以相互独立部署和运行的小型服务。每个服务都有其自己的流程，并通过接口与其他服务通信。这种关注点分离和剥离的独立功能支持 DevOps 实践，例如：持续交付和持续集成。
监控
DevOps 团队监控从规划、开发、集成和测试、部署到运营的整个开发生命周期。如此一来，团队就能迅速、自动地对客户体验中的任何降级做出响应。更重要的是，它允许团队“左移”至开发的早期阶段，并最大程度地减少具有破坏性的生产变更。
开始使用 DevOps
开始使用 DevOps 的最简方法就是识别小型价值流（例如：小型支持应用或服务），然后开始尝试一些 DevOps 实践。与软件开发一样，与一小群利益相关者一起转换单个数据流比尝试在组织内一次性过渡至全新的工作方式要容易得多。
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的时候，持续集成和持续交付这一块，有哪些需要特别注意的？
题主你好，我是Ghostcloud的高级架构师，这个问题我来守护！
持续集成一个主要的功能是让每个工程师的代码提交都不会影响到Mainline，以保证Mainline的可发布状态。实施持续集成时，需要注意的地方：
指定规则，提交代码时要一并提交新功能的测试用例。
集成的粒度和频度也很关键。一般一个小模块，不超过1周的时间。
持续集成通过后，根据应用程序的特点，在经过系统集成测试、性能测试、稳定的自动化测试通过率以及管理层的批准后，才是可持续交付和部署的应用程序。
持续交付有两种方式，一种就是基于DevOps的自动持续发布，一种是多个功能一并发布。在持续交付的过程中需要注意三个问题：
1. 部署到生产环境后也要有相应的测试；
2. 使用Toggle控制功能是否生效；
3. 要有回滚的手段（灰度发布）。
devops职位什么时候最忙
每年中旬。devops是前端业务成为了产品快速迭代过程中最忙碌的岗位之一，前端的持续集成、交付、部署也成为企业研发效率提升的瓶颈。该职位每年中旬是订单最多也是最忙的时候。职位，它是指机关或团体中执行一定任务的位置，即只要是企业的员工就应有其特定的职位。
大型企业实施 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
阅读原文
结语：以上就是首席CTO笔记为大家整理的关于devops什么时候交付的全部内容了，感谢您花时间阅读本站内容，希望对您有所帮助，更多关于devops什么时候交付的相关内容别忘了在本站进行查找喔。