DevOps是開發和運維的結合，有助于集成和自動化測試過程以及部署存儲庫，還提供了透明度以及靈活性。DevOps的目標如下：
- 更快的上市時間(TTM)；
- 減少各種修復之間的前置時間；
- 提高部署頻率；
- 更快的恢復時間；
- 降低新版本的失敗率。
許多商業部門的領導者都知道，提高營銷速度是一種生存技能，而不僅僅是目標。管理人員，特別是IT行業的管理人員，已經感受到了以更快的速度和更有效地執行流程以及做出更好的業務決策的壓力。
盡管大多數組織已經成功地部署了DevOps來完成必要的目標和目的，但是對于這種方法仍然存在一些誤解。以下是關于誤解的一些糾正：
一、DevOps不是一套自動化工具
DevOps不是一套可以購買的自動化工具。對于如何部署和監視應用程序而言，這是一種不同的思考方法。協作、持續交付、持續測試和持續集成不是實現工具。相反，它們是需要在項目中采用的實踐。盡管確實有很多工具，比如禪道、Git Hub和Docker，它們通常都有助于DevOps實踐的實現，但是只有當團隊成員知道如何優化并將它們引入到工作方法中時，它們才是有效的。
二、并不是每個項目的程序都要改變
為每一個新項目重新設計程序的概念與實現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的云。如果擁有高效的流程來獲取可以在應用程序中部署和測試更改的資源，那么也可以采用這種軟件。
