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

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的雲。若是擁有高效的流程來獲取能夠在應用程序中部署和測試更改的資源，那麼也能夠採用這種軟件。