DevOps

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