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的云。如果拥有高效的流程来获取可以在应用程序中部署和测试更改的资源，那么也可以采用这种软件。
