去年，写了一篇 《什么是 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 系统工程的改进本质在于分工的合理性和协调工具的先进性，需要通过优秀工程师文化的渗透和底层技术的不断突破创建科学的工程化的效能产品矩阵，来最终实现极致的高质量的研发生命周期和高效的研发过程体验。