DevOps（Development和Operations的組合詞）是一種重視「軟體開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合作的文化、運動或慣例。透過自動化「軟體交付」和「架構變更」的流程，來使得構建、測試、發布軟體能夠更加地快捷、頻繁和可靠。可以把DevOps看作開發（軟體工程）、技術運營和品質保障（QA）三者的交集。 傳統的軟體組織將開發、IT運營和品質保障設為各自分離的部門，在這種環境下如何採用新的開發方法（例如敏捷軟體開發），是一個重要的課題。按照從前的工作方式，開發和部署，不需要IT支援或者QA深入的跨部門的支援；而現在卻需要極其緊密的多部門共同作業。而DevOps考慮的還不止是軟體部署，它是一套針對這幾個部門間溝通與共同作業問題的流程和方法。 需要頻繁交付的企業可能更需要對DevOps有一個大致的了解。Flickr發展了自己的DevOps能力，使之能夠支撐業務部門「每天部署10次」的要求──如果一個組織要生產面向多種用戶、具備多樣功能的應用程式，其部署周期必然會很短。這種能力也被稱為持續部署，並且經常與精益創業方法聯絡起來。從2009年起，相關的工作群組、專業組織和部落格快速湧現。 DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──「熱修補程式」）起到意義深遠的影響。在缺乏DevOps能力的組織中，開發與運營之間存在著資訊「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施回應更快，而業務用戶的需求則是更快地將更多的特性發布給終端使用者使用。這種資訊鴻溝就是最常出問題的地方。 以下幾方面因素可能促使一個組織引入DevOps： 使用敏捷或其他軟體開發過程與方法 業務負責人要求加快產品交付的速率 虛擬化和雲端運算基礎設施（可能來自內部或外部供應商）日益普遍 資料中心自動化技術和組態管理工具的普及 有一種觀點認為，目前占主導地位的「傳統」美國式管理風格（「斯隆模型 vs 豐田模型」）會導致「煙囪式自動化」，從而造成開發與運營之間的鴻溝，因此需要DevOps能力來克服由此引發的問題。 DevOps經常被描述為「開發團隊與運營團隊之間更具共同作業性、更高效的關係」。由於團隊間共同作業關係的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產環境的風險也能得到降低。

Source: https://zh.wikipedia.org/wiki/DevOps