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的雲。如果擁有高效的流程來獲取可以在應用程式中部署和測試更改的資源，那麼也可以採用這種軟體。

對DevOps的九大誤解，是時候糾正了！