关于devops:什么是-DevOps看这一篇就够了

本文作者：Daniel Hu
个人主页：https://www.danielhu.cn/

一、前因

我是一个“DevOps 工程师”，于是总会遇到有人问我：“什么是 DevOps？”

这个问题看似特地根底，根底到很多人懒得答复。但其实沉着一秒，问本人一句“什么是 DevOps？”可能每个 DevOps 工程师都晓得“什么是 DevOps”，然而他们给出的答案不尽相同。

所以我会怎么答复这个呢？上面咱们开展来聊聊。

特别强调：本文仅代表我集体现阶段的浅显认知，本文观点不代表思码逸公司也不代表 DevStream 团队。

二、记忆

我第一次看到 DevOps 这个词，大略是在 2016 年的秋天。那时候我在 H3C 从事云计算研发相干工作。记得我接到的第一个工作是钻研 OpenStack 的一个 CICD 相干的组件，叫做 Solum，那是我第一次晓得什么是 CICD，第一次看到 DevOps 这个词。没错，只是看到 DevOps，然而我无奈记住 DevOps 的定义。或者说，过后我甚至没有找到一个清晰易懂的对于 DevOps 的定义。可能很多人和我当年一样，对 DevOps 的印象，就是 Dev + Ops。

2018 年的夏天，我开始在太保成研任云平台 PaaS 组负责人，专任太保云 CMO(Configuration Management Officer) 一职。没错，我仍旧是一个“云平台研发工程师”，然而再一次与 DevOps 结缘。太保云的 CMO，简略说就是负责太保云平台的源码治理、研发合作流程、版本治理、CICD、制品治理、发版流程等等。这个时候我其实曾经开始钻研一些 DevOps 相干的工具了，比方 GitLab、Jenkins、禅道、Artifactory、Nexus 等等；同时也在主导一些 DevOps 文化层面的建设，比方怎么的模式或行为在团队里是被激励的，怎么的事件是被禁止的…… 不过我只是在制订规定，而没有意识到这是“文化”。总之，那几年我也算是投身于 DevOps，致力于晋升团队研发效率、交付效率与交付品质，然而同时我没有去认真思考过“什么是 DevOps？”这个问题，我也没有刻意去思考过本人是不是在玩 DevOps。

去年 (2021 年) 年底，我退出了思码逸，我的 title 第一次从“xxx 云平台研发工程师”变成了“xxx DevOps 工程师”（xxx 示意高级、中级、高级等）。那天我开玩笑说：“以前，我在云原生畛域兼职玩 DevOps；当前，我在 DevOps 畛域兼职玩云原生”。

好吧，这会我是名正言顺的“xxx DevOps 工程师”了，我总该晓得“什么是 DevOps”吧！

三、他们说……

咱们先来看一下几家典型的公司是如何定义他们眼中的 DevOps 的，包含：

• Atlassian（代表产品：Jira、Trello 等）
• 微软
• AWS

3.1、Atlassian 答复“什么是 DevOps？”

Atlassion 有一篇题为 DevOps 的文章，外面有这样一句话：

DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.

我尝试翻译一下：DevOps 是一系列 实际 、 工具 和一个交融开发及 IT 团队的 文化理念。DevOps 强调赋能团队、跨团队沟通与合作以及技术自动化。

能够看到 Atlassian 给的等式是：

DevOps = 工具 + 实际 + 文化

Atlassian 还提到一个 DevOps 团队蕴含了开发和 IT 运维，大家一起合作，独特参加产品的整个生命周期，一起为晋升软件品质和减速软件开发过程而致力。DevOps 模式下开发和运维不再是独立的“筒仓”，而是简直被整合成一个团队，这个团队的工程师技术栈会笼罩开发、测试、运维等。同时 DevOps 团队会利用一系列的 DevOps 工具链来实现诸如继续集成、继续公布、流程自动化、高效合作等等目标。

Atlassion 给的“无穷环”长这样：

用“无穷环”示意 DevOps 生命周期，是因为 DevOps 的基本理念是“继续”，也就是“没有起点”。Atlassion 将整个 DevOps 生命周期分成 6 个阶段，别离是：

• 打算（Plan）
• 构建（Build）
• 继续集成和部署（或者交付）（Continuous Integration and Deployment or Delivery）
• 监控和告警（Monitor and Alert）
• 运维（Operate）
• 继续反馈（Continuous Feedback）

另外从这个环里咱们还能看到 Atlassian 想强调 沟通与合作是贯通 DevOps 生命周期全过程的。

3.2、微软答复“什么是 DevOps？”

微软这篇 Introduce the foundation pillars of DevOps: Culture and Lean Product 我特地喜爱！这个题目的意思是“介绍 DevOps 的基柱：文化和精益产品”。

文章第一句话：

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

DevOps 是人、过程和产品的联合，使能继续地向终端用户交付价值。

微软还提到：

Typically, the goal for Development is to deliver more features faster, and the goal of Operations is to achieve better system stability. DevOps aligns these disciplines by using a framework of best practices proven to increase speed to market while improving system stability.

少数状况下，开发的指标是疾速公布更多的新个性，而运维的指标是保障更高的零碎可用性。DevOps 通过切实可行的最佳实际体系来拉齐这两个指标，在晋升零碎稳定性的同时减速产品交付到市场的速度。

这里微软能够看到微软给的第一个等式：

DevOps = 人 + 过程 + 产品

而后微软从“人 + 过程 + 产品”进一步提炼了 DevOps 的 4 大基柱：文化、精益产品、架构和技术。

也就是：人 + 过程 + 产品 -> 文化、精益产品、架构 + 技术

微软给的“无穷环”长这样：

图里描述的 DevOps 生命周期还是分成 6 个阶段，别离是：

• 打算（Plan）
• 构建（Build）
• 继续集成（Continuous Integration）
• 部署（Deploy）
• 运维（Operate）
• 继续反馈（Continuous Feedback）

外加贯通整个 DevOps 生命周期全过程的“合作（Collaboration）”。

在图外，微软还定义了对其而言 DevOps 的 8 大能力：

• 继续打算（Continuous Planning）
• 继续集成（Continuous Integration）
• 继续公布（Continuous Delivery）
• 继续运维（Continuous Operations）
• 继续品质（Continuous Quality）
• 继续平安（Continuous Security）
• 继续合作（Continuous Collaboration）
• 继续改良（Continuous Improvement）

每次看到这里我总感觉微软的图该更新一版。

另外微软有一句特地有深度总结：

What is new? Continuous Everything. The process is a journey and requires a growth mindset to continually evolve and improve.

“Continuous Everything”，铿锵有力！微软强调 DevOps 过程是一段没有起点的旅途，要求咱们抱着成长的观点模式，继续地改良，永不满足。

3.3、AWS 答复“什么是 DevOps？”

不难猜到，AWS 也有一篇文章来答复“What is DevOps?”

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.

DevOps 是文化理念、实际和工具等的组合，可能晋升一个组织疾速交付利用和服务的能力。

这里 AWS 给了一个等式：

DevOps = 文化 + 实际 + 工具

不过这篇文章里 AWS 不落俗套，没有画一个本人的“无穷环”，而是给了这样一张图：

这里提到了：

• 构建（Build）
• 测试（Test）
• 公布（Release）
• 监控（Monitor）
• 打算（Plan）

还能够看到这个“交付管道”和“反馈环”连贯的是“企业”和“客户”，可见 AWS 心愿强调“DevOps 的目标是更快地向客户交付”。

四、DevOps 文化

我曾一度全面认为 DevOps 要解决的问题就只是工具问题，也就是如何抉择或者开发好用的 DevOps 工具 or 平台，从而晋升企业外部整个研发生命周期的运行效率。不记得是哪一天，我忽然有一个强烈的想法：工具只是工具而已，文化建设才是成败的要害！

文化决定了咱们如何去做事，工具决定了，决定了啥？可能啥也决定不了。因为我认为工具也是被文化所决定的。

4.1、什么是文化？

简略说，文化就是一个组织的社交遗产，也就是一个组织对于其成员的各种行为的响应模式。

比方当咱们说一个企业有“加班文化”时，其实是在说在这个企业内，员工加班会失去奖赏，而不加班会受到惩办。或者咱们说一个企业是“狼性文化”、“奋斗者文化”…… 不同的文化背地对应的也就是这个企业对于员工不同行为的不同响应模式。

一个企业的文化决定了在这个企业内：

1. 什么事件是对的，什么事件是错的；
2. 什么事件是重要的，什么事件是不重要的；
3. 什么事件是值得做的，什么事件是不值得做的。

所以 文化决定了一个企业会去招聘哪些人，会开革哪些人，会提拔哪些人。

看到这里可能你曾经在思考本人呆过的企业对员工有哪些要求，在激励什么，在惩办什么…… 没错，此刻在你脑海中闪现的一幕幕就是企业文化。

4.2、什么是 DevOps 文化？

这幅图大家必定都不生疏：

什么是 DevOps 文化？

其实从这幅图中咱们就能看到文化的影子。咱们都晓得 DevOps 强调买通开发团队与运维团队的壁垒，要求两个团队拉齐认知与责任，不再各自为战，而是一起为更快地交付更高质量的产品而致力。没错，这就是最根底的 DevOps 文化。

那么如何拉齐认知与责任呢？

首先能够确认的是，咱们在组织架构上间接交融 Dev 和 Ops 团队，这并不是一个 DevOps 团队。人是不是坐在一起，扭转的只是沟通的效率。这里我想强调两点：

1. 责任共担，在一个 DevOps 模式组建团队里，每个人都须要为软件开发交付的整个生命周期而负责；
2. 技能共享，通过继续学习，互相学习，让本是传统 Dev 的工程师学习 Ops 的技能，同时传统 Ops 的工程师也须要学习 Dev 的技能。

Dev 与 Ops 互相学习彼此畛域技能，每个人都懂开发又懂运维，抱着“成长的观点”，继续学习，不满足于以后已把握的技术栈。

然而咱们也须要意识到不能要求每个工程师都精通开发与运维，这是不可能的。这里说的 Dev 把握 Ops 能力，更多的是 Dev 可能借助欠缺的工具链从而把握“利用运维”的能力，可能在本人实现开发之后，有能力和权限将利用部署上线，同时线上利用出问题后，可能间接对其负责，定位、修复、更新降级等。而一些基础设施的运维能力须要独立进去思考，比方机房里的局域网配置、虚拟机挂 NAS 盘等传统运维能力。

同理 Ops 须要了解利用开发的生命周期，晓得 Dev 的痛点，尤其是在流程上的痛点，比方怎么晋升利用的构建速度，怎么优化利用的 cd 流程等，Ops 要关注利用的“生产过程”，进而发力去优化这个过程或相应的工具，让利用可能更牢靠更疾速地实现 cicd 流程等，更容易地部署上线或者对外交付。也就是说咱们并不是要求 Ops 也去写业务代码，而是帮助 Dev 去解决业务代码之外的痛点，让 Dev 可能更加专一于业务性能实现。

最初，一个 DevOps 模式组件的团队中每个人都为整个软件研发生命周期的速度和品质负责，每个具体的角色就像一个大头钉，底部很宽，代表着技术面广，关注整个软件研发生命周期的所有环节；同时顶部很高，在某个环节里专一，做好做精。

DevOps 胜利落地的要害是什么？

咱们后面说到的“其乐融融”的场景，咱们心愿 Dev 和 Ops 可能互相学习，共担责任，一起为更快更好地交付产品而致力。然而，工程师们为什么要这样做？他们的能源在哪里？

4.3、领导与激励

Gartner 曾出过一个剖析报告，表明在 2023 年，90% 的 DevOps 改革将会失败（相较于预期）。而失败的次要起因是领导层治理办法的局限。

其实这是不言而喻的，DevOps 能够称为一种“改革”，而很多人是冲突“变动”，冲突“新事物”的。比方 DevOps 激励承受失败，疾速失败，从失败中学习教训，进而在更长的工夫维度上争取更大的胜利。然而可能你遇到的刚好是一个“失败惩办型”领导，那么你的团队就会害怕失败，从而放弃发明与尝试新技术，抉择安于现状。

一个技术团队的领导首先本人须要懂技术，有丰盛的教训，这是根底要求。然而除此之外，更重要的是团队领导可能激励整个团队，去施展整个团队的主观能动性，让所有团队成员都可能有能源继续学习，疾速学习，同时也可能敢于失败，疾速失败且不害怕失败，把失败当做一个学习的机会，进而一直成长，让整个团队的战斗力可能越来越强。

所以领导怎么激励工程师呢？

福利？比方一些大厂提供的收费零食或者定期的下午茶？收费的咖啡或者午餐？

没错，作为一个工程师，这所有的福利都会让其开心，然而其实无奈激励其更加认真致力地工作。工程师的薪资程度广泛不低，所有这些零食也好，咖啡也好，大概率不会到其月薪的零头。同理，工程师找工作时，看重的也绝不会是一个企业是否提供收费午餐和下午茶。

那么工程师看重的是什么？

在抉择一家企业的时候，可能工程师第一个思考的是薪资，剩下的可能是成长的空间、工作内容是否感兴趣等等等等。然而进入一家公司当前，真正开始工作的时候，工程师看重的是什么？我认为可能是：

• 精通
• 自驱
• 指标

咱们一一来解释一下。

1. 精通

咱们在某个工作方向做的好，咱们善于某个技术方向，进而很好地实现相应的工作，这时候咱们会有一种成就感，满足感，咱们会感觉本人得心应手，同时大概率会取得认可，投诉，因而接下来的工夫里咱们就更加违心在这个方向上持续致力，做的更好。也就是说一个工程师可能有机会专一于本人精通的技术上发力，那么他大概率会感触到激励。

反例是什么呢？比方你是一个 Java 工程师，然而你的领导善于 PHP，并且感觉 PHP 是世界上最好的语言，于是要求整个团队转向应用 PHP，这时候你会放弃本人钻研多年的 Java 技术栈，努力学习 PHP 并信心干出一番问题吗？

2. 自驱

咱们心愿组建一个学习型、创造型的团队，每个人可能继续成长，乐于翻新，自我驱动。这就须要领导可能容许团队花工夫去学习，去输出，而不是一味地输入，每时每刻汇报本人写了几行代码。同时这也要求领导本身敢于承受新事物，拥抱变动，而不是“不求有功，但求无过”。举个例子：如果你的领导最放心的是线上利用出事变，并且他认为稳固的第一因素就是不要引入新技术，新工具，那么这时候你的领导也不会在意你是不是有工夫学习，也不会容许你花工夫去钻研新技术，因为这所有只会带来不稳固。如果领导胆怯失控，因此回绝翻新，那么这样的团队成员也就只能满足于实现日复一日的惯例需要开发迭代，而不会享受技术，自我驱动，拥抱翻新。

3. 指标

不言而喻，团队每个成员都须要晓得本人为什么做？目标是什么？指标是什么？而不是领导心里藏着一个指标，而后简略地指挥团队成员实现一件件具体的零散的工作项。如果团队成员只晓得明天须要实现事务 A，今天须要实现事务 B，而不晓得为什么要做，最终要做成什么样，那么大家只会满足于机械地实现工作，而不会有能源谋求“如何做得更好”。

五、总结

所以 DevOps 是什么？

我尝试给出我的答案：

DevOps 是一种文化理念、工具与实际的联合，目标是更快更牢靠地向用户继续交付价值 。其中最重要的是 文化 ，文化要求 Dev 和 Ops 团队责任共担，指标统一，也要求整个团队继续学习，抱着成长的心态，Continuously Everything。其次 DevOps 离不开高效的 工具 集，工具是自动化的根底。最初咱们要在各个环节谋求最佳 实际，不论是工具的应用，还是团队的合作模式，沟通办法下面。

最初，对于题目“什么是 DevOps？看这一篇就够了！”，我想通知你，DevOps 文化里不存在“够了”，所以我不得不抵赖，我扯谎了。本文只代表我集体现阶段的 浅显 认知，我倡议你查阅更多的材料，继续学习，永不满足。当然如果本文对你有一点点的帮忙，那么我很满足。