devops是當前it領域最熱門的話題之一，了解、掌握、應用devops對於提公升軟體交付與管控具有重要的意義。然而時至今日devops尚無統一的定義。
本文主要從業務及it的發展對devops的誕生背景、定義演進以及落地價值等方面進行了分析和闡述，以期對devops的內涵進行**。
devops在2023年提出以來，已經走過了十個年頭。近幾年來，devops的熱度呈快速**趨勢，從dora的年度報告也可以看出來，到2023年末全球主要行業的devops的應用程度已達到30%，上公升勢頭迅猛。
然而，時至今日，對於devops仍沒有乙個準確的定義，這對於我們理解devops，或者說在落地devops的過程中會帶來不小的困擾，各方都有自己的理解。那麼，devops的內涵究竟是什麼呢？我們期望從devops的發展背景、定義演進以及落地價值等方面進行一次**。
民用軟體系統的應用崛起於上個世紀八十年代， 2023年後蓬勃發展，其中，作為重要組成部分的軟體系統，逐漸深入到社會的每乙個角落，從整體的發展過來來看，業務與軟體系統的關係可分為三個階段。
輕度依賴
在這個階段主要出現在早期，軟體系統主要解決業務中重複多或計算量大的問題，支撐範圍主要侷限在業務中的某一過程或環節。或者說，在這個階段，業務離開了軟體系統也能開展，軟體對業務來說不是必選項，軟體功能的更新頻率可以是數天乃至數月、年。
重度依賴
隨著業務的發展，業務的關聯性與複雜度提高後，業務完全依賴人工完成已經成為不可能。到這個時期，軟體系統成為業務的核心支撐，業務的開展已經離不開軟體系統，但尚可接受短暫的非服務期存在，軟體功能的更新頻率被要求在數天、月。
完全依賴
隨著軟體服務深入社會各個角落，社會生活的衣、食、住、行、用都依賴於軟體系統，從某一領域或應用來說，軟體系統相對於業務已經進入了主導階段，軟體系統必須提供365*7*24的服務，任何中斷服務可能都會帶來極大的經濟或社會損失，軟體功能的更新頻率必須控制在數天、小時、分鐘。
it管理與研發模式的演進，與it對業務的響應效率密不可分，大致可分為三個階段；
「穩態」模式
在研發模式上，以瀑布模型為主要特點，其優勢是各階段劃分比較清晰、整體成本較低，但迭代速度較慢，其在業務對軟體輕度依賴階段適用性較好。
「穩態+敏捷」模式
隨著業務對軟體依賴程度的提高，傳統模式下軟體的迭代效率成為了乙個阻礙業務發展的主要問題點，於是針對軟體研發過程最耗時的開發過程出現了一系列的優化措施，敏捷研發是其代表。這個時期的it管理模式變成了「穩態+敏捷」的模式，研發仍舊以系統軟體包交付為目標，如下圖所示：
當然，在這個時期，針對各階段的效率提公升也進行得如火如荼，出現了了一大批針對不同階段提速的工具軟體，如下圖所示：
「敏態」模式
當業務對軟體系統完全依賴時，it管理與研發模式就需要進入「敏態」模式了。而這個模式也就是我們今天時常提起的devops。在這個模式下，研發交付目標不再是系統軟體包，而是面向業務的服務能力，如下圖所示：
由於業務與軟體的關係越來越緊密，研發的交付已經由原來的面向軟體包產品，而轉向面向業務需要的服務能力，然而，這種服務能力也是涉及多個方面，下面我們從devops的定義發展，來看看devops的內容豐富過程。
「穩態+敏捷」模型只能實現區域性效率提公升，而devops那麼唯一的途徑就是從整體上進行優化和提公升，使整個研運過程形成乙個有機的整體。從2023年提出依賴，devops的內涵也在進行著不斷的發展與豐富，我們先看一下不同時期的定義。
我們把不同時期的定義整理為乙個時間軸，並做一些關鍵字抽取：
可以看出針對devops的定義，隨著時間的推移，devops的內涵在不斷豐富，已經從最初一組過程、方法與系統的組合簡的單定義，發展為一套有理論、有方法、有文化、有實踐的體系。
devops體系與傳統模式是有著本質的不同的，主要體現在以下幾個方面：
組織方式不同
devops中強調以專案或產品的一體化管理為基本管理模式，從而消除傳統模式下分階段任務管理與執行，通過管理模式的調整，消除傳統模式下不同階段的銜接問題。
關注重點不同
devops是以最終向業務的服務能力交付為目標，而不是傳統模式下分階段任務交付為目標。
提公升維度不同
devops關注軟體系統的整個生命週期，是從整體上提公升軟體交付的質量與效率，而不單只關注某乙個階段的提公升，各階段的提公升可以更加的有機協同。
管控深度不同
devops強調全程監控，全程度量，通過技術手段透明化軟體交付的全程，包括過程與結果，而傳統模式下過程資料缺乏，難以進行有效的過程度量與分析。
效益效果不同
devops支援針對交付過程的持續優化，通過度量資料分析可以快速定位交付過程的問題與努力方向，支援持續科學的優化提公升，傳統模式難以做到。
devops的定義演進以及與傳統模式的對比，可以看出devops體系本身系統化、整體性的設計思想，其既包括了軟體全生命週期的系統化考慮，也包括了了it管理的多方訴求，devops的落地涉及devops平台的建設、流程體系建設、人員賦能、標準規範等多個方面，其可以為帶來如下方面的提公升。
業務響應能力提公升
devops的落地，在提公升效率的同時可以提公升交付的質量，自動化程度的提公升可以提公升對業務需求迭代的響應能力，研運吞吐量可以得到幾何級的提公升。
研發交付規範提公升
不同專案或產品的研發團隊，在同一套平台上開展研發交付活動，通過平台預先制定的流程、規則等約束不同研發團隊的交付活動，從而實現研發交付規範與標準的統一，實現企業級的優化提公升與改進。
研發交付效率提公升
通過針對研發交付過程中的環境準備、編譯構建、**質量檢查、系統測試、軟體部署等過程的自動化實現，降低人工操作或等待人工操作時間，全面提公升研發交付過程的自動化水平，提公升研發交付效率。
研發交付質量提公升
研發交付質量的從現有的部署結果質量保障，延伸到源**質量保障、測試覆蓋度保障等過程，從而實現從源**到部署全過程的質量檢查與提公升，全鏈路提公升研發交付質量
研發交付管控提公升
針對研發交付的需求、開發、測試、發布和部署等過程，進行全面的資料化和度量，針對重點關注指標建立質量門禁，從而實現自動化的技術管控，結合已有的行政管控，由單一的結果管控，實現研發交付「過程+結果」管控，提公升管控力度。
研發交付持續優化
基於devops平台，通過流水線過程資料收集，以及進一步的度量分析，實現研發交付過程的持續優化，既包括devops平台的優化，也包括研發交付流程、標準規範等方面的優化。
devops的演進簡單來說就是從一項技術到文化的構建與實踐；從無關緊要到依賴；從業務的區域性到全部。而devops的落地價值實現於研、運的整合並且提公升對業務需求的響應。趨勢已成，只願大家都能共襄盛舉。
對落地DevOps理念的一些反思
作者 杜屹東編輯 郭蕾 在 thoughtworks 的一篇題為 devops 團隊之殤 的文章中，thoughtworks 軟體工程師杜屹東反思了 devops 的價值以及挑戰。devops 理念從誕生到現在已經有近 10 年的時間，然而社群對於它的爭論卻未停止過。devops 希望能夠消除開發與...
乾貨 混沌工程落地的六個階段
從筆者所在團隊的實踐出發，我們將混沌工程總結為六個階段，並對各個階段的落地過程加以總結，希望能夠對大家落地混沌工程有所幫助。今天主要是拋磚引玉，後續針對每個階段，陸續會有專門的文章進行介紹。而混沌工程理論相關的部分，大家可以參考由 netflix 出版的 混沌工程 迷你書。混沌工程落地的六個階段 上...
基於容器和K8s的 Devops 探索和落地實踐
長話短說，本文全景呈現我司專案組gitlab flow devops 現代devops技術基於容器技術 自動化指令碼實現了依賴環境的打包 版本管理 敏捷部署。為在迭代便利性 部署嚴謹性上取得平衡，專案組設計了如下gitlab flow devops流程。乙個完整的功能迭代上線週期 這裡為什麼保留ma...