摘要：现代云原生开发中，开发者追求速度，平台工程师注重安全稳定，二者目标冲突造成摩擦。解决方案是“黄金路径”，提供自助沙盒、安全镜像、自动化部署和引导式可观测性，实现开发者自主与平台控制的平衡，共赢发展。

现代云原生开发中，开发者追求速度，平台工程师注重安全稳定，二者目标冲突造成摩擦。解决方案是“黄金路径”，提供自助沙盒、安全镜像、自动化部署和引导式可观测性，实现开发者自主与平台控制的平衡，共赢发展。

译自：Speed Plus Safety: Ending the Dev vs. Platform Engineer Clash

作者：Jeroen van Erp

现代云原生世界已经造成了根本性的文化冲突。一方面，是开发者，他们像赛车手一样为速度而生。他们的目标是创新，以最快的速度发布新代码和新功能，挑战速度的极限。

另一方面，是平台工程师，他们是数字天空的空中交通管制员。他们的唯一使命是维护安全、稳定和控制，确保每个工作负载都是安全合规的。

这两个角色对业务都至关重要，但当他们的目标可能发生冲突时——自主性与控制——这会产生深刻且代价高昂的摩擦。这并非一方有错；而是两个基本职能背道而驰，这种脱节减缓了所有进程。

开发者的核心愿望很简单：发布代码。但这个看似简单的目标却是一段充满障碍和诸多摩擦点的复杂旅程。对于赛车手来说，这些相当于突然出现的减速弯和维修站，不断干扰对速度的追求。每一个都会延迟应用程序交付并需要不同的解决方案。

首先是访问摩擦。想象一下，一个开发者需要在 Kubernetes 集群中测试他们的新应用程序。他们不能简单地启动一个集群，而是必须提交工单，等待批准，并与平台团队反复沟通。将这种情况扩展到数十名开发者，平台工程师就会突然被堆积如山的重复请求所淹没。这将开发者变成了瓶颈式的工单系统，让双方都感到沮丧，并分散了他们进行更具战略性工作的时间。

接下来是交付摩擦。这源于手动交接、缓慢的审批和不一致的流程所造成的延迟。一个新功能可能需要为资源提交工单，然后等待安全审查和代码审查。由于这些步骤由不同的人处理，经常会出现不一致的情况，到代码最终发布时，业务已经损失了宝贵的时间。这并非轻微的减速；而是一种竞争劣势，赛车被困在维修站，而其他赛车正在赛道上行驶。当竞争对手每天发布多次时，每一次延迟都会成为严重的竞争劣势。

最后，我们有认知摩擦，它是由环境本身的复杂性造成的。开发者是构建业务逻辑和使用 Go 或 Java 等语言编码的专家，但他们通常不想成为 YAML 配置、Helm chart 或复杂网络的专家。当他们被迫应对这种复杂性时，他们的重心就从创造价值转移到与基础设施搏斗。这种“管道工程”耗尽了他们的精力，减缓了交付速度，并可能导致代价高昂的错误。

当开发者专注于终点线时，平台工程师正在管理整个生态系统。他们的工作不仅仅是构建和维护集群；而是要兼顾不断增长的职责清单。就像空中交通管制员一样，他们必须密切关注一切，以确保其安全稳定地运行。

他们是构建者，创建集群和 CI/CD 流水线，确保基础设施可靠且高性能。他们也是守护者，负责整个平台的安全和合规性，从理解数字主权法规到执行防止风险的策略。

最重要的是，他们是财务经理，承担着优化云成本并确保整个系统高效和可持续的艰巨任务。

他们还是战略家，始终展望新技术，并发展平台以保持业务竞争力。

但无论控制器多么熟练，他们都无法独自管理所有事情。现实是平台工程师的数量远远不足。典型的比例是每 10 名开发者对应一名平台工程师。在大型企业中，这个数字可能飙升到每 200 名开发者对应一名。这种不平衡造成了不可持续的局面，每个开发者请求——从简单的访问工单到复杂的故障排除问题——都堆积如山，导致平台工程师被淹没在大量小请求中。他们几乎没有时间进行对业务至关重要的战略性工作。

业界引入了“黄金路径”的概念，作为一种在不牺牲控制权的情况下赋能开发者的强大方式。对于赛车手来说，这是一条清晰、铺设良好的赛道，没有突然的障碍。对于空中交通管制员来说，这是一个标准化的飞行计划，确保每架飞机安全着陆。这是一条定义良好、标准化且安全的路线，可以穿越开发者面临的摩擦迷宫。

但虽然这个想法是一个好的开始，但它还不够。一个平台愿景必须包含一套全面的能力，才能真正弥合鸿沟。首先，必须提供自助式沙盒。开发者需要能够按需启动轻量级、本地环境和隔离的虚拟集群。这让他们可以自由地安全地进行实验，甚至破坏一些东西，而不会危及生产环境。

精选的基础镜像也是核心组成部分。开发者不应该担心他们从互联网上拉取的基础镜像是否包含漏洞。相反，平台团队应该提供一套安全且持续维护的构建模块，让开发者从一个几乎没有漏洞的基础开始。

一套精选的受信任组件，包括开源应用程序，使开发者能够从坚实的基础开始他们的项目，并实现真正的“左移”安全方法。

这条路径还必须包括内置安全性。安全性不应该是流水线末端的关卡。它必须从一开始就嵌入到整个工作流程中。通过自动应用策略强制和安全护栏，开发者可以自信地快速前进，而平台工程师则可以安心，知道每个工作负载都受到保护。

此外，自动化、一致的部署是不可协商的。黄金路径应采用 GitOps 等原则，以确保零接触自动化和零漂移一致性。这消除了手动、易出错的步骤，使开发者和平台团队都能从繁琐的部署工作中解脱出来。

最后，该路径必须提供引导式可观测性。平台不应让开发者淹没在大量的仪表盘中，而应提供清晰、相关的数据和引导式故障排除。这使开发者能够快速解决自己的问题，而无需成为底层基础设施的专家。

这种新方法的核心是找到速度和控制之间的平衡，让赛车手自信地加速，让空中交通管制员安全地引导他们。通过实施全面的黄金路径，我们可以超越仅仅管理脆弱的鸿沟，而是建立一个开发者和平台工程师都能成功的统一愿景。这是一个他们的目标不再冲突，而是完美同步的未来。

构建这条共享路径需要组织在平台工具方面进行根本性的思维转变。为了使企业真正具有韧性和灵活性，其平台必须植根于开源，提供创新的自由，而无需供应商锁定。

通过采纳开源黄金路径，公司可以创建一个强大可靠的基础，它不仅更快、更安全，而且真正可持续。我们很乐意在 KubeCon + CloudNativeCon North America 的 SUSE 展位 (110) 了解您弥合 DevOps 鸿沟的方法并交流经验。

KubeCon + CloudNativeCon North America 2025 将于 11 月 10 日至 13 日在佐治亚州亚特兰大举行。立即注册。

来源：小小兔Ra