去年，寫了一篇 《什麼是 DevOps ?》入門文章，簡單介紹了 DevOps 概念的起源及核心理念，時隔一年，多了一些想法，有了這篇 DevOps 進階篇，探討對 DevOps 理念更深入的理解。

1. DevOps 是什麼

DevOps 是一個概念，在邏輯學中，揭示一個概念需要了解概念的兩個特徵：內涵和外延。

1.1 DevOps 的內涵

相信大家都有聽過，DevOps 是開發（Development）和運維（Operations）的組合詞，但是很多介紹並沒有揭示 DevOps 的內涵，如果用一句話給 DevOps 下一個定義，它的本質是什麼呢？DevOps 的本質是一項軟體研發領域的系統工程。

如何理解這句話，我們需要先理解這個概念的屬概念“系統工程”，“系統工程”又是兩個概念，分別是“系統”和“工程”。

系統：

• • 錢學森曾說，系統是由相互作用和相互依賴的若干組成部分結合而成的、具有特定功能的有機整體

  • 系統論的創始人貝塔朗菲把系統定義為“相互作用的諸要素的綜合體”

  • 美國著名系統論專家德內拉.梅多斯在《系統之美》中闡述，系統是一個由一組相互連線的要素構成的、能夠實現某個目標的整體。

工程：

• • 根據百度百科的定義，工程是指以某組設想的目標為依據，應用有關的科學知識和技術手段，通過有組織的一群人將某個（或某些）現有實體（自然的或人造的）轉化為具有預期使用價值的人造產品過程。

 

既然，DevOps 是一個系統工程，那麼它必然有系統的屬性和工程目標，即系統三元素：要素、連線、目標

要素（研發領域系統的重要元素）：研發領域系統中的重要元素主要包含“人”和“工具”，這裡的“人”指的是參與研發生命週期的所有干係人，“工具”是研發生命週期所有使用到的研發工具（即軟體研發系統）。

連線（研發要素之間的連線關係）：研發要素之間的關係本質是“人與人”、“人與工具”、“工具與工具”之間的連線關係。

目標（研發要素連線組成的整體的目標）：DevOps 系統工程的目標是高質量的縮短軟體研發生命週期時長和不斷提升軟體研發過程的體驗，以此才不斷提高研發交付效能。

 

1.2 DevOps 的外延

根據 DevOps 系統工程目標領域範圍的不同，可以將 DevOps 劃分（泛化）為 GitOps、DevSecOps、MLOps、DataOps、DocOps、ChatOps、DocOps 等等。未來可能還會有新的 xxOps 出現，但他們的本源都是 DevOps 在不同領域的泛化，目標都是系統化的縮短不同領域的研發生命週期和研發過程體驗。

比如，MLOps ，即 Machine Learning + DevOps，他的本質是機器學習研發領域的系統工程，其目標是高質量的縮短機器學習生命週期，提升過程研發體驗。介紹 MLOps 的詳細課程可見 DeeplearningAI 官網

吳恩達：MLOps 的關鍵思想是，以系統化方式來思考範圍確定、資料、建模和部署，並使用軟體工具支援其最佳實踐

2. DevOps 解決什麼問題

如何實現 DevOps 系統工程的目標？

DevOps 本質是軟體研發領域的系統工程，既然是系統，必有架構，而架構的問題的本質就在於，通過提高系統要素之間的連線效率，來實現系統的整體目標。

DevOps 系統工程的本質是解決 “人與人”、“人與工具”、“工具與工具”之間的“分工”和“協同”問題。其中，解決“人與人”之間的分工與協同，稱之為“上工程”；“工具與工具”之間的分工與協同，稱之為“下工程”。

 

在整個軟體研發系統中，“人”之間的協同是最複雜，最不可預測的，降低研發生命週期中人的參與度，會極大的提高協同效率。所以，我們會盡量把“人與人”之間的協同轉換為“人與工具”之間的協同，又將“人與工具”之間的協同轉換為“工具與工具”之間的協同，這類轉化又稱之為“自動化”。

 

在效能領域，為了解決這兩大工程問題，誕生了很多職位和工具

上工程：解決人與人之間的分工和協同問題

• 分工：在只有一個人的軟體研發團隊中，是不存在分工的，隨著人員的規模增大和解決問題的複雜性越來越高，單個人已無法實現全生命週期的研發活動，從整個研發生命週期上來看，原來需要一個人完成所有的事情，研發生週期會被分成很多小的非核心生命週期，並拆分給不同的人共擔，並有了人的分工，產生了不同的工種（PD、PM、UED、前端工程師、後端工程師、測試工程師、SRE、DBA、演算法工程師...）。

• 協同：在只有一個人的軟體研發團隊中，協同效率是很高的，但隨著分工的細化，人之間的協同效率成指數性驟減，這時思路是將“人->人”之間的協同，轉換成“人-> 工具 -> 人”之間的協同，誕生了了諸如 郵件、釘釘、飛書、語雀、Teambiton 工具來解決人之間的高效協同問題，並且誕生了很多工程文化思想，如極限程式設計、敏捷、協同程式設計、協同文件編輯等等。

 

下工程：解決工具與工具之間的分工和協同問題

• 分工：小規模團隊中，在成本的約束下，研發工具一般藉助開源工具或購買商業化產品，隨著規模的擴大，針對不同的工種的分工會誕生不同的研發工具維護團隊，諸如程式碼平臺、測試平臺、安全平臺、構建平臺、部署平臺等等。

• 協同：隨著研發工具平臺的分工越來越多，研發效率豎井開始呈現，研發系統之間的協同效率也開始驟減，如果研發想完成一次全生命週期的研發活動，發現需要學習非常多的平臺，並在他們之間不斷跳轉，這個時候誕生了諸如 AzureDevOps、CircleCI、Jenkins、GithubActions，在國內諸如有阿里的雲效、騰訊的藍鯨和 CodingDevOps 等等，這些平臺通過集中式的連線，關聯了軟體研發生命週期的不同工具，將“人與工具的協同”轉換成了“工具與工具之間的協同”，大幅降低了研發者在不同工具間的協同效率，降低了“人”的分工，使得不同工種的同學可以做跨工種的工作。

 

分工和協同是對立統一的

上工程和下工程的分工和協同是對立統一的，分工會提高協同效率也會間接的降低協同效率。分工的本質是“利益”的劃分，不當的分工會產生效率豎井，極大的損害整個系統的協同效率，最終無法實現系統的整體目標。

大規模協同的先進性取決於工具的先進性

小規模的協同效率取決於人職業素養的先進性，而大規模協同的效率取決於系統性工具的先進性。DevOps 系統工程的改進本質在於分工的合理性和協調工具的先進性，需要通過優秀工程師文化的滲透和底層技術的不斷突破建立科學的工程化的效能產品矩陣，來最終實現極致的高質量的研發生命週期和高效的研發過程體驗。