from : https://www.zhihu.com/question/58702398

先搞清楚DevOps， 虽然是一堆营销号，但是可以看看他们提的概念，做的产品，然后自己来思考。这些做DevOps的企业，是从哪些方面来做这个产品。

网易云

DevOps目前并没有权威的定义，网易云认为，DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

如果从字面上来理解，DevOps 只是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009 年首次提出发展到现在，内容非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。

1. 组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。
2. 自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。
3. DevOps 的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。

所以，我们有上面的说法。那企业为什么需要DevOps，DevOps有什么依赖？我们认为：

1. 为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力，大而全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12 要素的原则来规范完成。
2. 系统被分成了几十个甚至几百个服务组件，则需要借助DevOps 才能很好地满足业务协作和发布等流程。
3. DevOps 的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求。

利益相关：以上内容摘自网易云架构团队写的《云原生应用架构实践》。

我是砖家我怕谁

DevOps 一词的来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps 其实包含了三个部分：开发、测试和运维。换句话 DevOps 希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。
DevOps平台的搭建可通过如下工具进行实现，具体安装步骤可参考链接：王教授-DevOps平台
项目管理（PM）：Jira
代码管理：GitLab
持续集成（CI）：GitLab CI
镜像仓库：VMware Harbor
容器：Docker
容器平台： Rancher
镜像扫描：Clairctl
编排：Kubernetes
服务注册与发现：etcd
脚本语言：python
日志管理：EFK
系统监控：prometheus
Web服务器：Nginx
数据库：MySQL redis

CODING

Ops 时，我们在谈论什么？
2018 年对许多人来说是艰难与变革的一年，势如破竹的发展势头似乎被打破，小微创新型企业生存艰难。“产业互联网”“企业数字化转型”等寻求从内破局的呼声也越来越高。
有趣的是，类似的情况不是第一次出现。1999 年金融海啸来袭，经济下行周期内，大家都寄希望于当时先进的信息技术，希望能以此提升自身的管理水平，增强企业竞争力。导致当年 ERP 进入中国后迅速走红，令无数缺乏管理经验的中国企业心驰神往。
而到了数字化转型的浪潮之年，这个风口上的词变成了 DevOps（/de’vɒps/）。大家纷纷开始讨论要不要采用 DevOps、DevOps 到底有没有那么神奇。

Google Trends 中 DevOps 历年的热度数据

DevOps 到底是什么

2018 年，我们走访了近百个分布在各行各业中的 IT 团队，意外的发现，大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，而是来源于业务部门的服务压力。正如同当年企业寻找 ERP，今天的企业将目光投向了 DevOps。但是 DevOps 并非像 ERP 那样可以直接部署的东西，而是一种由主流互联网巨头们所总结出来的的研发管理理念，是 Google、Netflix 等大型互联网公司实现快速迭代的秘诀。
作为一家专注于研发 DevOps 工具链的公司创始人，我在接触客户的时候，发现一个很有趣的现象：所有人都想“做” DevOps 并期待其能为他们带来商业上的成功，却对 DevOps 的核心理念知之甚少。这很大一部分原因是市面上对 DevOps 有着各种各样的说法，导致大家概念的混淆。想要弄清楚 DevOps 到底是什么，必须先从它的本质说起。
软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。

举个例子，对于运维来说，稳定压倒一切，新 Feature 越少越好。而对于研发来说，却希望能开发更多的功能。这种矛盾会导致大量的资源和时间的浪费。就像两匹马拉一辆车，如果马头向着的方向不一致，肯定是没法全速前进的。

DevOps 的理念就是希望能打破这种屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进。

字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。但深入理解了 DevOps 之后，你会发现 DevOps 其实是一种软件研发管理的思想，方法论，他追求的是一种没有隔阂的理想的研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。

比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：

1. 精简组织架构；
2. 愿意承担一部分试错带来的损失；
3. 分阶段地一小步一小步地进行转型；
4. 最大化地利用工具和自动化流程；
5. 对所有的过程和结果进行记录和分析。

所以 DevOps 不是简单的开发软件化，而是企业的学习能力不断提升的结果，将企业改造成敏捷应对的学习型组织，运用新的工具，优化组织架构和流程，不断地进行自我革命和创新的方式。工具是辅助，而非基础。
原文未完，完整内容可点击：
**

CODING 的专栏 DevOps 实践指南 持续分享敏捷开发、DevOps、持续集成/部署等领域优秀实践，感兴趣的同学可以了解一下，欢迎交流分享。

AWS云计算

DevOps 模式定义
DevOps 集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

DevOps 的工作原理
在 DevOps 模式下，开发团队和运营团队都不再是“孤立”的团队。 有时，这两个团队会合为一个团队，他们的工程师会在应用程序的整个生命周期（从开发测试到部署再到运营）内相互协作，开发出一系列不限于单一职能的技能。
在一些 DevOps 模式下，质保和安全团队也会与开发和运营团队更紧密地结合在一起，贯穿应用程序的整个生命周期。当安全是所有 DevOps 团队成员的工作重心时，这有时被称为“DevSecOps”。
这些团队会使用实践经验自动执行之前手动操作的缓慢流程。他们使用能够帮助其快速可靠地操作和发展应用程序的技术体系和工具。这些工具还可以帮助工程师独立完成通常需要其他团队协作才能完成的任务（例如部署代码或预置基础设施），从而进一步提高团队的工作速度。

DevOps 的优势

1.速度
高速运转，让您可以更快速地针对客户进行创新、更好地适应不断变化的市场，同时更有效地推动业务成果。DevOps 模式能够帮助您的开发人员和运营团队实现这些目标。例如，微服务和持续交付能够让团队充分掌控服务，然后更快速地发布更新。

2.快速交付
提高发布的频率和速度，以便您能够更快速地进行创新并完善产品。您发布新功能和修复错误的速度越快，就越能快速地响应客户需求并建立竞争优势。持续集成和持续交付是自动执行软件发布流程（从构建到部署）的两项实践经验。

3.可靠性
确保应用程序更新和基础设施变更的品质，以便您能够在保持最终用户优质体验的同时，更加快速可靠地进行交付。使用持续集成和持续交付等实践经验来测试每次变更是否安全以及能够正常运行。监控和日志记录实践经验能够帮助您实时了解当前的性能。

4.规模
大规模运行和管理您的基础设施及开发流程。自动化和一致性可在降低风险的同时，帮助您有效管理复杂或不断变化的系统。例如，基础设施即代码能够帮助您以一种可重复且更有效的方式来管理部署、测试和生产环境。

5.增强合作
建立一个适应 DevOps 文化模式的更高效的团队，强调主人翁精神和责任感。开发人员和运营团队密切合作，共同承担诸多责任，并将各自的工作流程相互融合。这有助于减少效率低下的工作，同时节约大家的时间（例如，缩短开发人员和运营团队之间的交接时间，编写将运行环境考虑在内的代码）。

6.安全性
在快速运转的同时保持控制力和合规性。利用自动实施的合规性策略、精细控制和配置管理技术，您可以在不牺牲安全性的前提下采用 DevOps 模式。例如，利用基础设施即代码和策略即代码，您可以大规模定义并追踪合规性。

DevOps 为什么很重要？

软件和 Internet 改变了我们身处的世界，同时也改变了购物、娱乐、银行等行业的运营方式。软件不再仅仅是为业务提供支持，而是成为业务的方方面面都不可或缺的组成部分。当前，公司通过采用在线服务或应用程序交付的软件，在各种设备上与客户进行互动。他们还使用软件改变了价值链的各个部分（例如物流、通信和运营），从而提高运营效率。在整个 20 世纪，生产实体产品的公司通过工业自动化改变了其设计、构建和交付产品的方式，而在当今的环境中，公司必须以同样的方式来改变其构建和交付软件的方式。

DevOps 的文化理念

向 DevOps 的过渡需要文化理念和心态上的转变。简单来说，DevOps 的宗旨就是消除两个传统上孤立的团队（开发团队和运营团队）之间的壁垒。有些组织甚至没有独立的开发团队和运营团队，工程师可能身兼两职。利用 DevOps，这两个团队可以携手合作，共同提高开发人员的生产力，同时增强运营的可靠性。他们力求频繁沟通、提高效率，并改善客户服务的质量。他们能够完全掌控自己的服务，并且经常越过自己的既定角色或职能的传统工作范畴，思考最终用户的需求以及解决这些需求。 质保和安全团队也可以与这两个团队紧密协作。凡是采用 DevOps 模式的组织，无论组织结构如何，参与团队都会将整个开发和基础设施生命周期视为己任。

DevOps 实践说明

有一些重要的实践经验能够通过自动实施和简化软件开发与基础设施管理流程，帮助组织加快创新速度。这些实践经验有大部分需要通过适当的工具来完成。
其中一个基本实践经验就是要频繁地进行小规模更新。这是组织能为客户快速提供创新的有效方式。与传统发布实践中偶尔的更新相比，这种更新通常更具渐进性质。频繁的小规模更新能够降低每次部署的风险。它们可以帮助团队更快速地处理错误，因为团队能够确定引发错误的最近一次部署。虽然更新的节奏和规模可能有所不同，但使用 DevOps 模式的组织与使用传统软件部署实践的组织相比，会更频繁更新。
此外，组织还可以使用微服务架构来提升应用程序的灵活性，从而加快创新步伐。微服务架构将大型的复杂系统拆分为简单的独立项目。应用程序被拆分为许多单个组件（服务），每个服务限定到单个目的或功能，这些服务既可以与其同级服务相互独立运行，也可以与应用程序一起作为整体运行。这种架构降低了更新应用程序的协调开销，当每个服务都与掌控各项服务的敏捷小型团队一一对应时，组织就可以实现更快的发展。
但是，微服务与较高的发布频率相结合会导致部署量大幅度增加，可能会带来运营挑战。因此，持续集成和持续交付等 DevOps 实践经验有助于解决这些问题，让组织能够以安全可靠的方式快速交付。与基础设施即代码和配置管理一样，基础设施自动化实践经验也有助于维持计算资源的弹性和对频繁变更的适应性。此外，进行监控和记录这一实践经验可帮助工程师追踪应用程序和基础设施的性能，以便他们快速应对出现的问题。
更多有关DevOps的实践经验与使用请点击下方链接：

LinuxerRocky

刚好最近在写DevOps的一些实践。第一篇文章就介绍了什么是DevOps。DevOps实践一：DevOps概述 。

优维科技EASYOPS

类似的话题曾经发过一篇原创文字加以说明，希望对你有点启发。
————————————————-

优维科技EASYOPS｜《凤凰项目》用几百案例解释DevOps

团队组织是否“DevOps化”很难被定义，因为它在IT中的各种角色的工作原理是不同的，其间也有很多误解。- Alan Koch

是否“DevOps化”真的很难被定义，以下会讲到这里面的几点原因。IT系统中各种角色的人还会存在不同观点，可能它看起来和它的工作原理看起来有很大区别吧。DevOps影响IT中的每个人，但它会以不同的方式去影响每个角色，从而产生不同的描述。
是否DevOps也很难定义，因为世间对它存有太多误解。那么，在我们尝试定义DevOps之前，先花几分钟来描述最常见的误解吧。

DevOps不是一种新工具

DevOps要求的许多工具无法在没有工具的情况下完成，随之DevOps社区很多无私奉献的大神创建了许多酷酷的新工具。当然，用着Puppet或Docker，又或Jenkins等其他工具并不意味着你就在做DevOps的事情。这些工具不代表DevOps，它们只是工具。

DevOps不是一个新团队

字面上看，“DevOps”把开发部分与Ops部分联系起来。事实上如果还要在开发和运维之间增加其他组织，这就会起反作用。创建DevOps团队测试流程和工具，并促进Dev and Ops共同合作，这是一个好的开始。

DevOps更不是一个新角色

许多公司都在暗地打听“DevOps工程师”，这说明他们不明白其内涵以及需求什么。其实，DevOps包括了IT组织中的一切，DevOps工程师将是一个IT-one-man-band，而且对象无所不包。

DevOps的世界等你来定义

DevOps领域没有权威，没有标准，DevOps也没有一个“永恒正确的打开方式”。

大神眼中的DevOps是什么

Gene Kim等人的DevOps手册说：DevOps及其产生的技术，构建和实践代表了许多哲学和管理运动（包括）的融合：精益，约束理论，Toyota生产系统，弹性工程，学习型组织，安全文化，人为因素，高信任管理文化，雇佣领导，组织变革管理和敏捷方法。
换句话说，DevOps是一个从许多不同领域获取良好做法的问题，并将其实施在IT组织中，以提升IT的绩效。
虽然DevOps来自一些非常完善的学科，但DevOps本身就是近年的东西。“DevOps”一词是在2009年底创造出来的，这个时候也标志着这个快速增长运动的开始。将其与2001年初出现的“敏捷”一词比较，敏捷性方面大涨两倍以上。
出现时间短也是DevOps难以界定的另一个原因。DevOps社区一直在增长和快速学习，这些实践正在发展，工具正在成熟，并且加入的每个组织都有助于我们对DevOps的进一步了解。

《凤凰项目》Gene Kim认为的三种方式：

Gene Kim曾在DevOps这个短暂的历史变动中清晰描绘过DevOps体系。他的2013年的novelette《凤凰项目》描述了一个虚构的IT组织及其使用DevOps原则来解决一系列严重的问题。他把之前数百家组织已经实施成的DevOps经验浓缩于2016年的《DevOps手册》，为任何开展DevOps之旅的组织提供了详细的指导。
两本书都以“三种方式”为基础展开描述。Gene Kim本人向我们描述：基金会的三种方式是DevOps旅程的主要组成部分，并提供了一种了解和实施DevOps的路线图。它们是：

1. 迁移（flow）
2. 反馈（feedback）
3. 持续学习（Continual Learning）

The First Way: Flow
第一种方式是专注于IT组织中的活动流程，往顺利，快速方面进行优化。在此环节中，需要解决的关键流程之一是从开发团队到生产中的价值流（the flow of value，以软件的形式），这涉及连续交付和优化部署Pipeline等概念。
以精益思维看，第一种方式是理解你追求的“价值流”，识别和消除阻碍流动的障碍，并自动化以增加流量。

The Second Way: Feedback
第二种方式是建立在第一种基础之上优化从右到左的反馈流程。这也包括最终的反馈 - 开发团队敏锐地了解他们的软件在生产中的表现以及最终用户实际如何使用它们。这部分还包括所有角色中所有人的任何类型反馈。
第二种方式目的是为在IT组织反应工作质量以及对客户的影响，并将之可见。这不仅包括确保反馈的稳定提供，且包括缩短和优化反馈循环，以便人们尽可能快地自动收到反馈。

The Third Way: Continual Learning
流动和反馈良好的前提下，第三种方式利用了建立继续学习和持续改进的模式。
它生来自带一些门槛问题：“我们可以从我们所做的和我们收到的反馈中学到什么？”以及“我们如何利用这些知识来改善IT组织的绩效？

最终，这种学习超出了我们工作的基础，包括尝试寻找新的和创新的方式来更好地满足客户、用户和组织的需求。例如，在“假设驱动的开发”中，我们假设用户和客户可能需要哪些软件功能，然后构建软件实验来测试这些假设，丢弃失败的实验，并建立在那些正向工作上的继续学习和持续改进。

第三条途径涉及到我们失败方法的文化转型：愿意把失败当作学习机会。无论是意想不到的操作失败，还是我们通过实验带来的失败，我们认为失败是好的，因为我们可以从中学习，逐渐完善。

**

尽可能的自动化

一个关键的DevOps原则是“自动化你尽可能想到的一切”。这个论调很重要，自动化利于优势流转（第一种方式），快速反馈回路（第二种方式）和高性能（随着持续学习和持续改进，第三种方式）。

自动化是DevOps底线，再看它想对现有模式的优势所在：

1. 加快速度 自动化比手动快。如果某环节实现了自动化，那就几乎是最快了。 > 2. 减少人为错误 工具不会像人们那样犯错误。一旦工具被配置和验证正确，它将每次都正确地完成任务。 > 3. 一致性 一旦每个工具都按照定义确保了一致性。那就可以用工具来检查和执行不自动化环节的一致性。 > 4. 减轻风险 由于工具不会出错，可用于检查手动活动，因此可以部署以减轻无法避免的风险。 高效能组织尽量的自动化一切 - 这就是他们高效的诀窍。

DevOps解决核心冲突

每个IT组织都有两个同时的核心/优先事项：

创新.通过开发和部署新的增强服务和应用，跟上客户和用户不断变化的需求。 > 稳定.确保客户和用户都可以使用这些IT服务和应用，并保证其数据和信息安全。 这两个优先事项是相互冲突的，因为将变更部署到生产环境中是造成中断和其他操作问题的最常见原因。更坑爹的是，这些相冲突的优先事项还经常引起其他功能性障碍，因为开发通常首选创新优先级，而运维首选稳定优先级。
DevOps不只是说Dev和Ops（以及QA和Security）必须合作， 同时DevOps也通过实现创新和稳定来解决核心慢性冲突。 DevOps的做法和工具确保整个IT操作的稳定性和可预测性，特别关注创新和部署过程中的稳定性。 这可以通过允许IT团队快速移动并经常部署，从而加速创新，而不会危及安全性和稳定性。

先知而后行

看到这里，你心里已经迈出DevOps旅程的第一步了（至少），DevOps并不意味着抛弃一切，重新做。相反，它注重的是你在做什么，用特定的工具和技术改造工作流程，改进反馈，并开始不断学习和改进。
什么困难暴击了你，Google下别人怎么解决的这个问题，然后学习改进。至少，你有了开始DevOps之旅的心。

Nebulogy 纳比云

官方微信公众号：Nebulogy 纳比云
1 人赞同了该回答
在业务敏捷化的需求背景下，传统的单体式架构及项目制瀑布开发模式已经无法满足业务快速开发交付及变更的需求。从企业IT部门的视角，为了更快速响应业务变化，实现应用的快速开发交付及迭代，敏捷开发（Agile）风靡一时，Scrum作为敏捷方法论被认为是全球最流行与最有效的敏捷项目管理理念与方法之一；
而以敏捷开发为基础的DevOps（Development和Operations），则进一步整合了开发测试和运维团队，通过组织、文化和工具，以及自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps 与传统瀑布式开发、敏捷开发的开发周期对比

DevOps可以有效提升软件交付效能，在实现更频繁更快速应用发布的同时，可以有效减少发布变更导致的故障及停机时间。
**
根据DORA公司与Google Cloud合作发布的《2018年DevOps现状报告》，实施DevOps的高效能团队在代码发布频率、代码提交至发布的速度、变更的故障率、事故恢复时间上的表现远远优于低效能团队：

代码发布频率高 46 倍
代码提交至发布的速度快 2555 倍
变更故障率少 7 倍
事故恢复时间快 2604 倍

—— 《2018 DevOps现状报告》DORA ( DevOps Research and Assessment ), Google Cloud
而在所有参与调查的企业当中，在实施DevOps的同时采用PaaS、云原生、容器技术的企业有更高的概率是高效能精英团队。IT团队的敏捷化转型，为业务团队更快速响应市场变化提供了能力支撑。在企业数字化浪潮下，能否比竞争对手更快的发现和响应市场变化，是保持企业竞争力的重要因素。

完整阅读：Nebulogy纳比云原创文章《BizDevOps推动企业数字化转型与高速增长》

执着zz
DevOps 是一种工程模式，本质上是一种分工，通过对开发、运维、测试，配管等角色职责的分工，实现工程效率最大化，进而满足业务的需求。
DevOps的核心是角色的分工，而不是组织架构变化，垂直化的组织架构不代表可以实现DevOps所需要的分工模式，横向的组织架构也不代表传统的分工模式。
DevOps的目标是工程效率最大化，它本身也只是一种方法论，是为了实现工程效率最大化的目标而存在的。
阿里专家带你玩转DevOps企业最佳实践
很多企业都了解DevOps理论，但仍然很难落地，在企业内部，该如何实施DevOps呢？阿里云容器技术专家为你解读DevOps企业最佳实践

5 人赞同了该回答
可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。2009年DevOps这个新理念出现，是为了应对IT环境中普遍面临的一些挑战。如图所示，第一个隔阂，存在于商业需求和开发之间，敏捷的出现缩小了这个鸿沟。但是这给运营带来了很多压力。所以这就诞生了第二个隔阂，存在于开发和运维之间，这就是DevOps理念要解决的问题。

DevOps的核心实践理念统称为CALMS：文化（Culture）、自动化（Automation）、精益（Lean）、度量（Measurement） 、共享（Share）。DevOps的优势很明显，但是为什么这些年来实际践行的企业却这么少呢？

一、为什么DevOps很好，但是80%的公司很难落地？
我觉得DevOps最大的难点，有以下几方面。

1、文化和理念障碍
DevOps体现了传统孤立团队之间的合作和团队精神，需要一个队伍的专家朝着一个目标工作，就像是一个足球队。但开发和运维之间就是存在沟通和理解的鸿沟。开发要的是快速实现新功能，不断满足客户的新需求，他们经常不考虑自己写的代码会对运营造成什么影响，运维关心的是稳定压倒一切，希望尽量避免修改功能，从而降低满足非功能性需求的风险。还有一些管你那也限制了DevOps的成功——InformationWeek的调查显示：“只有45%采用DevOps的技术专业人士表示期望它能提升安全性；32%认为DevOps对安全性没有任何影响；7%认为DevOps将导致IT运行可能更不安全。这种文化的东西，中间隔着的三八线，不是说打破就能打破的。

2、流程和工具差异各家公司的流程和工具都是有差异的，有的企业是主干开发、分支release；有的企业是分支开发、分支release……

3、决策层一线的IT人员认可了DevOps，但是到了决策层，DevOps的落地就更加艰难。要改变从前传统的开发方式，要付出大量的人力资源和资金，这对于老板来说，是一个需要考虑很久的决定。正如很多企业采用敏捷开发一样，这需要一个准备，尝试和逐步实施的过程。
所以对于团队leader来说，想实施好DevOps，需要理清现状，统一概念模型，制定阶段性目标，激发团队热情，有效规避风险，循序渐进地将这个先进的理念落地。

二、大企业如何让DevOps落地？
以华为为例，去年刚推出了一款工具：华为软件开发云。这是一款轻量级的DevOps工具。作为软件开发云的用户，我有这么几点体会。华为开发云有项目管理、配置管理、代码检查、编译构建、测试、部署、发布、流水线这几大服务。

从技术层面来看，用了刚才说的这几个服务，就能可视化地创建流水线，本流水线包含多个阶段（stage）；在每个阶段创建多个不同类型的任务（task）。比如代码检查任务、编译构建任务等。

在代码提交后，流水线的相关任务可以实现最大程度地并发，在小时级别自动化实现版本级集成发布，得到版本质量报告，并快速反馈给开发人员，以便进行快速修复，在开发人员修复版本后并再次进行流水线的集成发布。

在紧急状态下，还能实现版本的快速可靠回退。这样一来，版本就能实现每日构建了，项目管理服务提供了敏捷式、社交化的项目管理方式，可与配置管理关联，使得开发团队有效协同，通过看板等各种图表实时掌握项目进度和质量。

我在网上看到一个实际的案例，说是一个智慧城市和软件开发云合作后，产品版本的集成发布由原先的1天缩短为30分钟，整个项目的交付周期缩短到3个月。
体验地址：https://www.hwclouds.com/devcloud/

Worktile

已认证的官方帐号
DevOps是一种重视软件开发人员和IT运维技术人员之间沟通合作的文化、运动或惯例，透过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
所以前面所有的都是定语，只有最后一句最关键，就是 ：频繁可靠的发布软件，这就是我们的终极目标。

针对刚才定义的原始阐述，从这个环形图上的工作方式，一直在持续演进，好像看起来没有什么特别的，这个神奇点在哪？

如果你跟别人说你今天看了一篇分享是DevOps，或者你去搜DevOps，会发现所包含的含义和相关的含义特别多，包括 精益思想、自动化、持续集成、持续部署、价值流、三步工作法、持续交付、分级部署、敏捷思想、敏捷开发、团队合作 。

我们认为这是大家对于美好事物的一种期望，期望DevOps能承担更多。即使我们今天不提DevOps这个词，把敏捷这个词说出来，你也会说敏捷包含这些部分，换个词也是这样。我们 千万不要陷入于这个词的含义是什么 ，而是说 工程化 和 工程化背后美好的东西 。

极策科技

打造中国第一个“泛地产+大数据”孵化中心
1 人赞同了该回答
其实从DevOps的字母拼写就可以看出来，它就是英文Development和Operations的组合，上面几位答主也都提到了，DevOps 不能被简单认为是一种工具、方法、技能、文化或组织结构，DevOps的框架是结合所有这些元素建立一个流水线的过程，使业务更快地运营，并能更快地应对变化。企业级的DevOps不仅仅是增强的敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理来实现和促进业务增长并保障业务连续性。

而关于DevOps的特点，则有人用 CALMS（平静）来诠释，也就是：

而关于DevOps更深层次的价值，则是这些：

如果想了解更深入的话，可以关注极策科技的微信公众号：ex-mind,有空扫个码也是可以的哟～