DevOps

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

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

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

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

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

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

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

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

對應用程式釋出的影響

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

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

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

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

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

現狀

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

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

訴求

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

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

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

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

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

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

釋出協調人

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

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

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

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

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