DevOps 是开发和运维的联合，有助于集成和自动化测试过程以及部署存储库，还提供了透明度以及灵活性。DevOps 的指标如下：
●更快的上市工夫 (TTM)。
●缩小各种修复之间的前置工夫。
●进步部署频率。
●更快的复原工夫。
●升高新版本的失败率。
许多商业部门的领导者都晓得，进步营销速度是一种生存技能，而不仅仅是指标。管理人员，特地是 IT 行业的管理人员，曾经感触到了以更快的速度和更无效地执行流程以及做出更好的业务决策的压力。只管大多数组织曾经胜利地部署了 DevOps 来实现必要的指标和目标，然而对于这种办法依然存在一些误会。以下是对于误会的一些纠正：
DevOps 不是一套自动化工具
DevOps 不是一套能够购买的自动化工具。对于如何部署和监督应用程序而言，这是一种不同的思考办法。合作、继续交付、继续测试和继续集成不是实现工具。相同，它们是须要在我的项目中采纳的实际。只管的确有很多工具，比方禅道、Git Hub 和 Docker，它们通常都有助于 DevOps 实际的实现，然而只有当团队成员晓得如何优化并将它们引入到工作办法中时，它们才是无效的。
并不是每个我的项目的程序都要扭转
为每一个新我的项目从新设计程序的概念与实现 DevOps 的理念南辕北辙。领有一个能够依据须要轻松批改并利用于各种我的项目的繁多过程集，为可预测性留出了空间。在这种办法中，每个人都相熟本人的工作角色以及他们须要如何操作流程。
DevOps 实际在实质上须要具备适应性和灵活性，以便将它们实现到服务器配置、异样测试、部署周期和加强开发团队的实力中。这只有在通过反复来让团队彻底了解整个过程时才有可能实现。
不只实用于小型公司或初创公司
包含 Netflix、NASA、亚马逊、谷歌、星巴克、领英、通用电气、塔吉特、爱彼迎、HubSpot、耐克等在内的当先组织都在实际 DevOps。它是为每个人开发和应用的，并不限度行业和公司的规模。每个企业都心愿在其周期时间或上市工夫内进行所需的改良。DevOps 能够帮忙企业定期进步上市工夫，而且收益微小。这就是为什么大多数公司都施行这种办法。一家电子学习机构 Intellipaat 的首席执行官示意，他的 DevOps 认证我的项目为从小型到不同规模的大型公司提供服务。
DevOps 不是麻利的替代品
与大多数理念不同，DevOps 并没有取代麻利，能够将其视为麻利的连续或麻利激活器。在 DevOps 的帮忙下，能够实现继续部署、继续集成和继续交付管道的继续交付。此外，它容许在每次迭代完结时计算潜在可交付的代码。因而，DevOps 和麻利的合作提供了最佳后果和体验。
DevOps 没有勾销 IT 运维
依据无运维（NoOps）的概念，IT 行业将变得十分自动化，不须要任何外部团队来管理软件。此外，人们置信微服务会使 DevOps 操作过期。然而，无论服务变得如许自动化，运维总是须要的。只管这些运维的工作可能会有一些变动，但它们在 DevOps 中依然具备重要意义。
DevOps 并非只为开源软件开发的
通常，DevOps 是在应用 LAMP（Linux、Apache、MySQL 和 PHP）堆栈以及各种开源工具（如 Jenkins、Docker、Ansible、Git、Chef、ELK、Nexus、Sonar、Zentao、Nagios 和 Gerrit）的组织中实现的。然而，取得一个胜利的 DevOps 后果并不依赖于所应用的技术。许多组织应用 COBOL、Microsoft.NET、大型机汇编代码、SAP 以及嵌入式零碎。
它能够兼容 ITIL
ITIL 代表信息技术基础设施图书馆。它由 IT 服务治理 (ITSM) 的具体实际组成，旨在使各种 IT 服务与各自的业务需要保持一致。DevOps 与 ITIL 兼容，但各种 ITIL 流程都是齐全自动化的，以反对与 DevOps 相干的高部署频率和短交货工夫。这解决了与配置和公布治理过程相干的许多问题。
DevOps 不等同于继续交付
只管软件的继续交付表明企业曾经实现了 DevOps 的重要组件，但它不是一种二元关系。这两项服务并不能齐全等同，它们必定是不一样的。
DevOps 的次要关注点应该是改良工作文化，保护基础设施和软件。此外，它还必须反对销售和市场部门。
DevOps 不是来到云端就不能运行
大多数人把 DevOps 称为云。云为测试人员和开发人员提供了动静的基础设施资源，以疾速取得测试环境，而不是期待手动实现申请。然而，这并不意味着须要用于 DevOps 的云。如果领有高效的流程来获取能够在应用程序中部署和测试更改的资源，那么也能够采纳这种软件。