为什么没有人长大后想成为一名 DevOps 工程师

看着年轻一代不像我一样在成长过程中大量接触线下生活，我为他们感到些许惋惜。我已年过三旬，所以深知小时候为了避免长时间堵住电话线，只能尽快拨号上网，浏览几个维基百科页面做作业，却丝毫感觉不到缺憾。亲身经历了我们口袋里随处可见的个人电脑的崛起，我觉得自己并非完全免疫，而是更有能力利用它，而不是沦为它那些仅仅因为“联网”就能带来无限幸福和满足的虚假承诺的牺牲品。

另一方面，还有另一场革命，我并没有直接参与其中，这场革命发生在 21 世纪初，在 2009 年 O'Reilly Velocity 会议上那场如今已成为传奇的Flickr演讲之后，全球 IT 部门发生了这场革命。这场事件DevOps标志着一个未来，即从孤立的、行动缓慢的基于ITIL的组织向更好的方向转变。

自从不到五年前我从教学转行到科技行业以来，我从未想过在任何其他专业环境中工作会是什么样子，除非他们完全沉浸在那场开创性的 Flickr 演讲中传授的实践中。敏捷方法论和至今仍难以确定的“DevOps”定义，都是我从未质疑过的现状。

但我现在对此表示质疑。如果我认为新一代人缺乏基本的视角，并且能够从没有智能手机的生活中获得很多帮助，那么我必须用同样的逻辑来审视自己，并努力去理解 DevOps 的真正含义？它是为了应对什么而出现的？它最初的承诺是什么？这些承诺兑现了吗？人们最终是如何以及为什么成为 DevOps 工程师的？未来成为一名 DevOps 工程师意味着什么？

DevOps 的起源及其最初的承诺

我有时会想，以前开发人员必须填写基础设施配置申请表，然后等上几天甚至几周才能得到服务，那会是什么样的体验。我听说过那种文化中典型的运维人员是什么样子的，他们总是爱指责别人，脾气暴躁，最爱说的就是“NO““和” “Where’s my pager?“。

John Allspaw 和 Paul Hammond，以及他们著名的速度演讲“每天 10+ 次部署：Flickr 的开发和运营合作”的许多与会者都不必担心，开发和运营团队之间常见的摩擦对他们来说一定太过生动了。

这些年来，我看过好几遍这个演讲，有几点印象很深。首先，我之前没注意到演讲里竟然有这么多脏话，或者可能只是Allspaw先生的风格。其次，演讲者提出的关键信息是：开发和运营团队实际上拥有同一个目标：赋能业务。

他们继续探讨了组织机构可能希望采用的工具和文化特质，以实现一天内多次部署到生产环境。他们谈到了自动化基础设施、功能标记、共享警报和监控，所有这些都围绕着一种全新的协作文化而凝聚，这种文化重视信任，并以更健康的态度对待系统故障，避免责备高于一切。

在接下来的几年里，DevOps 的含义在很大程度上由极具影响力的《DevOps 手册》和《站点可靠性工程》书籍进一步明确。

前者的开篇用几句话描述了 DevOps 的工作方式所希望解锁的内容

“[多个团队共同努力]使计划工作能够快速投入生产（例如，每天执行数十、数百甚至数千次代码部署），同时实现世界一流的稳定性、可用性和安全性。”

我们兑现了承诺吗？

每当我想起那次 Flickr 演讲中提出的想法，我就会有一种站在巨人肩膀上的感觉。这些想法对很多人来说一定是革命性的，也是我所了解的唯一的职业现实。因此，无论当前的 DevOps 方法论、最佳实践和工具是否能够改进，我都对迄今为止取得的所有进展心怀感激。我问过所有在 2009 年之前配置过服务器或进行过黑客攻击的人，他们都证实，现在的情况比以前好多了。

话虽如此，大多数公司是否在实现世界级的稳定性、可用性和安全性的同时，还能疯狂地交付产品呢？答案大多是否定的。
即使 DevOps 世界拥有大量可用的现代化工具，但它仍然运行在与那次演讲中提出的框架完全相同的框架上。

用亚当·雅各布的话来说

问题不在于我们对系统各个部分优化不够。我们在每个环节都构建了更高效的工具。但整个系统的构建方式？使用体验？这和 2009 年基本一样，这也是我们陷入困境的原因。

孤岛现象依然存在，交接容易出错，协作在很多情况下显得僵硬僵化。任何担任过 DevOps 工程师的人，无论工作时间长短，都会列出一长串他们认为组织存在的问题，并且通常对组织是否有能力解决这些问题缺乏信心。
资深 DevOps 从业者 Adam 甚至呼吁掀起第二波 DevOps 浪潮，这股浪潮不仅仅是对工具进行简单的改进，更鼓励我们跳出固有思维模式，挑战既定规则，探索未来的发展方向。

说到 DevOps 从业者，这些人是谁？如何以及为何成为 DevOps 从业者？

人们最初是如何进入 DevOps 的？

短短15年间，科技行业发生了翻天覆地的变化。DevOps工程师、SRE（网站可靠性工程师）和平台工程师等职位如今在求职网站上随处可见，成为科技招聘人员的热门话题。然而，在IT行业之外，这些术语仍然鲜为人知。尽管DevOps发展迅速，但它尚未成为人们渴望加入的职业；相反，许多人只是“偶然”进入而已。

我偶然接触到 DevOps 是在和表哥的一次谈话之后。他建议我学习 DevOps，因为我在获得 CCNA 证书后，决定不走严格的网络工程道路。出于好奇，我最终会从事 DevOps 工作，以及未来的工程师是否会选择它作为他们的第一职业选择，我询问了Reddit 上的/devops子版块，结果惊讶地发现大家的意见五花八门。

我找到了一些“我只是掉进去了”的人：

其他人则对新一代产品持中等乐观态度：

其他人则不那么乐观：

尽管 DevOps 的定义仍然存在很大争议，但它似乎不太可能成为学生在招聘会上听到的职业，也不太可能被永久添加到大学课程中。这可能是因为我们倾向于想象自己在特定领域表现出色，相信专业化会增加我们成功的机会。

在我成长的过程中，我幻想着成为一支著名乐队的主音吉他手，拥有神级的速弹能力。我并没有梦想过能够熟练演奏所有乐器。

DevOps 没有吉他独奏。要想出类拔萃，你需要熟悉一系列工具、语言、框架、超大规模计算平台和流程。最优秀的 DevOps 工程师本质上是多面手。这种模块化、类似乐高积木的工作和经验特性，可能会让 DevOps 在 IT 部门之外不那么受欢迎。

通才、修补匠和胶水概念的案例

试图形成一个非主观的 DevOps 从业者应该具备的特质概况是不可能的，但根据我的短暂经验以及从与比我更有经验的人的交谈中学到的知识，我发现了一些特质。

通才

你读过“如何在 DevOps 领域找到工作”的指南吗？还记得知识要求部分吗？Linux、Docker、CI/CD、Git、所选的 Hyperscler、网络等等。这些要求通常会在 DevOps 职位要求中的经验要求部分列出。

如果你面试过开发人员或产品设计师之类的职位，你很可能需要在面试过程中的某个阶段展示作品集。但在 DevOps 面试中，这种情况很少见。我实在想不出有谁会定期整理和更新 DevOps 作品集？DevOps 职位本身就具有模块化和分布式系统构建的特性，因此很难在作品集中进行精心策划和展示。

作为一个在高中教了七年英语却感到无聊透顶的人，我自然而然地被 DevOps 所吸引。这个领域要求我学习许多工具和概念，并将它们协作地整合在一起。我并非专注于某个概念，而是精进快速学习新事物的技能，这正是我培养出来的技能。在这样的环境中茁壮成长的通才非常适合我。

修补匠

在 DevOps 方面表现出色的人可能会认为自己是修补匠。

我很喜欢这个想法，它也很符合我遇到的许多 DevOps 工程师的性格。我遇到的 DevOps 导师们都对学习事物的运作方式感兴趣，仅仅是为了获取知识。当然，花一个周末在家里的实验室安装一个更强大的交换机，或者用 3D 打印机打印新的迷你模型，并不能直接体现出你的 DevOps 技能，但这些背景知识比证书更能预示你在 DevOps 领域的潜在成功。

胶水

由于难以规划或预测，复杂系统中的许多工作可能被忽视。由于 DevOps 涉及将各种工具组合在一起以构建平台或交付系统，因此需要大量的“粘合剂”。

必须建立并自动化流程，以应对技术栈中每个工具伴随的技术债务和维护工作。那些能够自然而然地（尽管有时吃力不讨好）充当粘合剂，通过自动化、沟通或改进重复流程将系统的不同部分连接起来的人，对组织的成功至关重要。这项技能并非简历上必备的技能，但结合了“修补匠”的好奇心和“通才”的开放性，这是一个强大的组合。

现状：平台 vs. DevOps

这些讨论中经常出现一种错误的二分法，通常是出于市场营销的原因：DevOps 已死，平台才是未来。平台工程师的目标是让开发人员能够自主处理传统的 Ops 相关组件（Kubernetes、IaC 组件、IAM），而无需直接交互，从而实现自助服务并保持独立。

精心设计、特定场景的平台可以提高开发人员的速度。根据Puppet 发布的《2023 年 DevOps 现状报告》，超过三分之二（68%）的受访者在采用平台工程后看到了开发速度的提升。然而，速度不应是唯一的衡量标准。正如georgouslyhumble在 Reddit 上指出的那样，有时目标是在满足新的组织需求的同时保持现有速度。例如，日志 Sidecar 可以在不影响开发人员速度的情况下标准化日志收集，从而增强平台性能以满足日益增长的公司需求。

运维工作依然复杂且动态，达到一定复杂程度后，熟练的运维人员至关重要。平台为开发人员提供了便利，但需要注意的是，它们并不一定能减少团队间的隔阂，也不一定能更紧密地整合开发和运维团队。

团队在向其堆栈中添加新工具时务必谨慎，因为新工具通常会带来维护和保养开销，而这些开销很快就会累积起来。像Glasskube这样的工具可以降低运营开销，因此至关重要。我们需要更多这样的工具，以便为未来打造强大而高效的 DevOps 平台。

未来预测

某种类型的平台将胜出

最终胜出的系统、平台或工作方法无需“教”用户如何协同工作。未来的系统，若要提供无限软件交付的无限可能，同时又不损害安全性和稳定性，只有让团队协作成为最简单、最直观、最自然的工作方式，同时将开发人员和运维人员都不愿做的工作抽象化，才有可能实现。

但为了创造它，我们必须跳出固有的思维模式。

第二波 DevOps 浪潮可能即将到来

值得庆幸的是，许多永不放弃、不墨守成规的人正在为 DevOps 领域的方法论、流程和工具的不断改进做出贡献。
有人可能会说，一场重新思考 DevOps 的正式运动正在兴起，这非常令人兴奋。

多面手和能手越多越好

最有能力连接拼图碎片、形成反馈循环并反思糟糕想法的人，是那些不惧牺牲深度专业化、追求专业通才的人。那些敢于冒险，并通过不断尝试、不断测试和提问来学习的人，才能让这艘象征性的巨轮在越来越快地驶向工程卓越的道路上继续前行。

如何找到足够多的这样的人是另一个问题。

结论

看起来我还是不明白为什么人们长大后不想成为 DevOps 工程师，也许是因为这仍然是一个相对较新的领域，而且通才通常不被认为是最酷的孩子。

展望下一波人才，无论他们是有意识地选择还是偶然踏入 DevOps 领域，有一件事是肯定的：了解该领域的历史至关重要。这是未来工程师培养识别现状与理想未来之间差距的唯一途径。忽视这一差距，现状将占上风，我们注定会停滞不前，走向平庸。

不可否认的是，自 DevOps 时代以来，技术领域已经有了巨大的进步，但同样明显的是，15 年后，DevOps 仍在寻找立足点。

经验丰富的专业人士需要保持敏锐的洞察力，识别并鼓励年轻的修补匠、通才和周围的“粘合剂”，让他们不要担心追逐某些头衔，而是帮助重新定义和发展 DevOps，使其成为能够实现 2009 年最初愿望的东西。  

如果您喜欢这类内容并希望看到更多，请考虑在 GitHub 上给我们一个 Star 来支持我们🙏