DevOps

DevOps（Development和Operations的混成詞）是一種重視「軟件開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合作的文化、運動或慣例。通過自動化「軟件交付」和「架構變更」的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。

可以把DevOps看作開發（軟件工程）、技術運營和質量保障（QA）三者的交集。

傳統的軟件組織將開發、IT運維和質量保障設為各自分離的部門，在這種環境下如何採用新的開發方法（例如敏捷軟件開發），是一個重要的課題。按照從前的工作方式，開發和部署，不需要IT支持或者QA深入的跨部門的支持；而現在卻需要極其緊密的多部門協作。而DevOps考慮的還不止是軟件部署，它是一套針對這幾個部門間溝通與協作問題的流程和方法。

需要頻繁交付的企業可能更需要對DevOps有一個大致的了解。Flickr發展了自己的DevOps能力，使之能夠支撐業務部門「每天部署10次」的要求──如果一個組織要生產面向多種用戶、具備多樣功能的應用程序，其部署周期必然會很短。這種能力也被稱為持續部署，並且經常與精益創業方法結合。 從2009年起，相關的工作組、專業組織和博客快速湧現。

DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──「熱補丁」）產生意義深遠的影響。在缺乏DevOps能力的組織中，開發與運營之間存在着信息「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。

以下幾方面因素可能促使一個組織引入DevOps：

1. 使用敏捷或其他軟件開發過程與方法
2. 業務負責人要求加快產品交付的速率
3. 虛擬化和雲計算基礎設施（可能來自內部或外部供應商）日益普遍
4. 數據中心自動化技術和配置管理工具的普及
5. 有一種觀點認為，目前占主導地位的「傳統」美國式管理風格（「斯隆模型 vs 豐田模型」）會導致「煙囪式自動化」，從而造成開發與運維之間的鴻溝，因此需要DevOps能力來克服由此引發的問題。

DevOps經常被描述為「開發團隊與運維團隊之間更具協作性、更高效的關係」。由於團隊間協作關係的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產環境的風險也能得到降低。

對應用程序發布的影響

在很多企業中，應用程序發布是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備DevOps能力的組織中，應用程序發布的風險很低，原因如下：

與傳統開發方法那種大規模的、不頻繁的發布（通常以「季度」或「年」為單位）相比，敏捷方法大大提升了發布頻率（通常以「天」或「周」為單位）

減少變更範圍

與傳統的瀑布式開發模型相比，採用敏捷或迭代式開發意味着更頻繁的發布、每次發布包含的變化更少。由於部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程序會以平滑的速率逐漸生長。

加強發布協調

靠強有力的發布協調人來彌合開發與運維之間的技能鴻溝和溝通鴻溝；採用電子數據表、電話會議、即時消息、企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容並全力合作。

自動化

強大的部署自動化手段確保部署任務的可重複性、減少部署出錯的可能性。

現狀

很多組織將開發和系統管理劃分成不同的部門。開發部門的驅動力通常是「頻繁交付新特性」，而運維部門則更關注IT服務的可靠性和IT成本投入的效率。兩者目標的不匹配，就在開發與運維部門之間造成了鴻溝，從而減慢了IT交付業務價值的速度。

• 開發人員經常不考慮自己寫的代碼會對運維造成什麼影響。他們在交付代碼之前，並不邀請運維人員參與架構決策或代碼評審。
• 開發人員對配置或環境進行修改之後，經常沒有及時與運維人員溝通，導致新的代碼不能運行。
  • 開發人員在自己的機器上手工修改配置，而沒有記錄所有需要的步驟。想找到必要的配置參數，通常需要嘗試很多不同的參數；在得到一個可工作的狀態後，往往很難識別出通過哪些最小步驟就能到達該狀態。
  • 開發人員傾向於使用有利於快速開發的工具：對代碼修改更快的反饋，更低的內存消耗，等等。這樣的工具集與運維人員面對的目標運行時環境非常不同：後者對穩定性和性能的要求遠勝於靈活性。
  • 由於開發人員平時使用桌面電腦，他們傾向於使用為桌面用戶優化的操作系統。生產環境的運行時系統通常都運行服務器操作系統上。
  • 在開發過程中，系統在開發者的本地機器上運行。在運維過程中，系統經常分布在多台服務器上，例如web服務器、應用服務器、數據庫服務器等等。
• 開發是由功能性需求（通常與業務需求直接相關）驅動的。
• 運維是由非功能性需求（例如可獲得性、可靠性、性能等）驅動的。
  • 運維人員希望儘量避免修改功能，從而降低滿足非功能性需求的風險
  • 如果拒絕了小的修改，但給定時間段內需要修改的總量不變，那麼每次變更的規模就會變大
  • 變更規模越大，風險也越大，因為其中涉及的區域越多
• 由於運維人員嘗試避免變更，新功能流入生產環境的速度因此被延緩，從而延緩了開發人員將特性交付給用戶使用的速度。
• 運維人員可能對應用程序內部缺乏了解，從而難以正確地選擇運行環境和發布流程。
• 開發人員可能對運行環境缺乏了解，從而難以正確地對代碼進行調整。

訴求

• 更小、更頻繁的變更──意味着更少的風險
• 讓開發人員更多地控制生產環境
• 更多地以應用程序為中心來理解基礎設施
• 定義簡潔明了的流程
• 儘可能地自動化
• 促成開發與運維的協作

一般而言，當企業希望將原本笨重的開發與運維之間的工作移交過程變得流暢無礙，他們通常會遇到以下三類問題：

發布管理問題

很多企業有發布管理問題。他們需要更好的發布計劃方法，而不止是一份共享的電子數據表。他們需要清晰了解發布的風險、依賴、各階段的入口條件，並確保各個角色遵守既定流程行事。

發布/部署協調問題

有發布/部署協調問題的團隊需要關注發布/部署過程中的執行。他們需要更好地跟蹤發布狀態、更快地將問題上升、嚴格執行流程控制和細粒度的報表。

發布/部署自動化問題

這些企業通常有一些自動化工具，但他們還需要以更靈活的方式來管理和驅動自動化工作──不必要將所有手工操作都在命令行中加以自動化。理想情況下，自動化工具應該能夠在非生產環境下由非運維人員使用。

要開始優化發布流程，可以從問題識別開始：看看上面提到的哪種問題在你的團隊中具有最高的優先級。

發布協調人

這是企業級IT組織中一個新出現的角色，其主要任務就是協調安排將企業級軟件部署到預生產環境。對發布協調人的需求來自於以下幾方面原因：

1. 需要彌合開發與運維的鴻溝
2. 基礎設施日益變得複雜：為了運維web應用，需要多層基礎設施和多種平台
3. 發布頻率上升（由于敏捷和迭代式開發的引入）
4. 分布式團隊：位於全球多個地點的、包含外包人員的、混合開發/測試/基礎設施的團隊

發布協調人的角色（也被稱為部署協調人或集成協調人）源自發布管理或發布工程團隊。這個角色與航空交通管制有些類似──實時協調不同團隊的行動，有效使用共享的資源（空域、航道、跑道、航站門），達到組織的總體目標（安全起降）。

傳統意義上的發布管理往往只關注軟件變更的計劃與管理，發布協調則需要控制「將特定軟件變更發布至生產環境」的整個過程。這項工作需要系統地管理所有與「將代碼構建並部署到生產環境」相關的技術任務，也被稱為「發布工程」。

變更管理是跟蹤企業IT環境中各種變化──不管是應用程序還是基礎設施的變化──的基本原則。變更管理是ITIL v3的核心之一。

參見

• BizDevOps
• CI/CD

外部連結

• What Is This Devops Thing, Anyway? (by Patrick Debois, 2010/02/12)（頁面存檔備份，存於網際網路檔案館）
• 捷伴行Agile （頁面存檔備份，存於網際網路檔案館）

產品

• IBM DevOps（頁面存檔備份，存於網際網路檔案館）
• Nolio ASAP
• StreamStep SmartRelease（頁面存檔備份，存於網際網路檔案館）
• The ControlTier Framework（頁面存檔備份，存於網際網路檔案館）
• DevOps（頁面存檔備份，存於網際網路檔案館）