面向未来的技能再培训：为什么开发人员和基础架构专业人士需要走出舒适区

Matthew Finio：开发人员和基础架构专业人员之间的关系发生了哪些变化？

Miha Kralj：随着“软件定义一切”（软件定义网络、软件定义存储、软件定义计算）的出现，整个开发行业都迎来了变革。

过去，基础架构人员和软件开发人员各自为政，几乎互不沟通。一个负责服务所有底层管道和资产，另一个则负责所有编码工作并让企业梦想成真。

如今，这一现状正在逐步瓦解。双方都还没有做好应对这个时代的准备。他们都不了解安全的定义，因此我们可以将这一概念引入企业。他们需要开始互相学习，但这对双方来说都是一道难题。

这就像《谁动了我的奶酪》这本书所描绘的：如果双方都来自老派传统的世界，他们在相处时就会感到很不舒服。年轻一代伴着 Gmail 和 YouTube 长大，他们生活在一个多元融合的新世界中。但是，来自传统基础架构层面或开发领域的人仍在苦苦挣扎，因为他们在职业生涯早期并未学习另一方所掌握的知识。

MF：那么开发人员和基础架构人员都应该重新思考他们的职责描述吗？

MK：没错。开发人员不应再自视为单纯的应用程序开发者，基础架构人员也不应再自视为运营人员。产品工程环境的现代团队架构同样适用于这一场景，每个人都能在必要时完成他人的工作。专业分工依然存在，但开发人员需在必要时能够快速介入，编写传统上高度偏向基础架构的 Terraform 脚本。

因此，当您询问某人的职业时，他们不应该说“我是软件开发人员”或“我是基础架构/运营人员”。他们都负责构建某个产品或帮助开发某项服务，如果不将这些琐碎环节整合为一体，它就永远无法启用。每个人都需要了解整个产品/服务链、整个生命周期，乃至从底层到顶层的各项事务。

MF：您提到了 Terraform。开发人员还需要学习哪些基础架构概念？

MK：开发人员往往不了解底层基础架构的运作原理，且无法区分长期任务和短期任务。

例如，如果您对正在运行某些操作的主机、容器或无服务器组件进行更改，当该组件或虚拟机跳转到其他位置时，这一更改是否会持续存在？因此，将状态存储在其他位置的系统（无状态系统）这一概念，可作为开发人员理解基础架构的入门基石。如何实现无限可扩展？如何构建持久且有弹性的系统？所有这些架构概念都可在软件中实现，但实际上，它们基于基础架构模式。

此外，还需透彻理解所有安全模式——即如何在代码中构建最小攻击面的实现方法。以及如何正确地与某些远程服务进行通信。您是否打算编写一个小型聊天服务程序，每秒通过网络发送一百个小型聊天问题？或者，您计划将所有请求打包，以更小的频率分块发送？

这些都是每个软件开发人员需要做出的非常重要的决定，但是如果他们不了解幕后发生的事情，即实际系统是如何工作的，他们就无法理解自己为什么要做出这些决定。对系统从下到上的理解至关重要。开发人员需要编写良好、整洁的代码，这些代码不会阻塞系统，不会锁定数据库，也不会做坏事。

回溯 20 或 30 年前，我们曾设立专业岗位，负责优化数据库查询，以满足 CPU 所需的最小周期数，即最少数据锁定量。很多晦涩难懂的知识早已丢失。但是，了解如何构建高性能系统以及成本优化的系统仍然非常重要。所有这些经验教训都不应被遗忘。

您或许在想，“哦，嘿，现在是 2025 年，老兄，坐下！当今世界已截然不同，你对此一无所知！”我们建立了这个现代化的世界，需要帮助新的开发人员和新的基础架构人员尽可能实现高效利用。

MF：您能否举例说明开发人员使用基础架构即代码工具改进工作流的一些方法？

MK：是的。一个很好的例子是，开发人员如何为自己的代码创建适当的工作流，以便在他们创建代码并将其提交到存储库时自动测试，然后进行编译和打包。开发人员不应该需要某个基础设施人员来代劳。在 GitHub 上编写良好的 YAML 脚本是一项基础设施即代码任务，每个开发人员都可以对其进行优化，使该过程尽可能高效。

比如，如果开发人员只负责开发分支，就无需负责全面打包、全面验证和全面测试。这个开发人员会说：“嘿，我负责开发分支，可以忽略生产分支中的其他 20 个任务。”

但如果您负责生产工作，就需要进行大量的自动化任务，启动即将进行全面安全审查和代码验证的机器等设备。所有这些微小的决策都会影响您完成编译的速度以及提交代码后获取结果的速度：每个开发人员都应具备更改基础架构即代码脚本的能力，并使其匹配自己的工作流。

就像这类开发人员喜欢自行微调集成开发环境一样。他们都有各自的字体、颜色和键盘快捷键等偏好。他们还应具备自行配置工作流的能力，并在提交代码后观察会出现哪些变化。这些知识都源自基础架构即代码 (IaC)。

MF：当今基础设施专业人员应该了解应用程序开发的哪些具体知识？

MK：基础设施即代码，或 IaC，字面意思是基础设施人员正在成为编码者。基础设施是用脚本、数据和代码定义的，这意味着基础设施脚本或代码与开发人员编写的任何代码一样，需要经历相同的软件开发生命周期：

• 这些知识需要妥善记录，
• 正确存放于存储库中，
• 进行适当的版本控制，

并以完全相同的方式进行处理。传统的基础架构人员并不了解这一点，也无法加以实践。基础架构人员可以通过点击鼠标进行配置，也许还能编写一些 Bash 脚本或其他代码。

但在当下，基础架构团队需具备基础架构即代码的开发能力，这已成为基本要求。他们需要了解 Git，以及如何对其基础架构即代码资产进行安全扫描，对其资产进行适当的版本控制，并接受同行评审，还需要了解什么是拉取请求。这些都是每个软件开发人员均应掌握的标准术语和活动。

基础架构人员需要具备全栈开发能力，而全栈工程师很难培养和寻获。当前极度缺乏这类全栈人才：他们既精通底层（数据包传输、网络运行及操作系统内核运作），又通晓顶层架构。例如，我要如何编写多个软件依赖项？应使用开源还是内部软件包？我要如何编写异步代码？这些都是涉及纯软件开发的问题。两个巨大的领域合二为一。变革管理以及人才再培训和技能提升的体系尚未完善。

MF：如果再培训和技能提升的挑战如此艰巨，那么基础架构专业人员应该如何紧跟发展趋势和技术演变的步伐？

MK：如今，专攻基础架构的人员与专职开发的人员已不复存在，两者完全融合为统一领域。他们都在学习这些新趋势，即软件开发生命周期的变化，尤其是 AI 的变化。

当我们探讨 AI 原生开发类型时，基础架构人员和应用程序开发人员都需要学习这一概念。每个人都会受到 FOMO 效应的影响，认为自己早已落后。他们刚刚掌握了如何进行提示工程，现在又被告知要学习如何在 Semantic Kernel 上编写智能体等程序。

人们需要互相帮助并寻求适当的平衡。需要花多少时间了解最新动态以及自身现有的竞争优势？以前是 5%，现在则需投入 10% 的时间。生成式 AI 可以助您一臂之力。但是，学习所需的时间与应用知识创造商业价值或 IT 价值所需的时间之间的比例，越来越倾向于前者。

MF：在结束访谈之前，您能否解答一下开发人员和基础设施专业人员在了解现代应用程序时应该牢记哪些关键事项？

MK：现在已经不再拆分任务了。现代应用程序几乎已全部实现内置基础架构。例如，现代开发人员将编写代码并请求创建容器，而无需依靠基础架构人员为其制作容器。有的工作需要更多地专注于基础架构任务，但也需要进行开发。有的工作则需要完成更多的软件开发，但同时还需要基础架构知识和访问权限。

因此，基础架构专业人员需转型为软件开发人员的角色。软件开发人员也是如此，他们需要实现向基础架构专业人员的转型。

这些角色并不是分开的，而是正在合并。这就像十年前或更长时间之前一样，当时每个专业的软件开发公司都有开发人员和测试人员。现在没有人再谈论测试人员，因为这两个角色已经融合。同样类型的角色崩解和融合现在正再次发生，这次是在开发人员与基础设施人员之间。