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

外部連結

• What Is This Devops Thing, Anyway? (by Patrick Debois, 2010/02/12)

產品

• IBM DevOps
• Nolio ASAP
• StreamStep SmartRelease
• The ControlTier Framework