平台团队应该铺就从第 2 天到第 50 天都能优化流程的黄金路径，而不仅仅是第1天。这里有一些例子。
译自 How to Pave Golden Paths That Actually Go Somewhere 。
更多的软件工程组织正在转向平台工程，以通过设计实现标准化和真正的开发者自助服务。平台工程师构建内部开发者平台(IDP)，这是所有捆绑在一起的技术和工具的总和，为开发者铺平黄金路径。根据 Humanitec 的 CEO Kaspar von Grünberg 的说法，黄金路径是“软件开发生命周期中用户可以以最小认知负载遵循并推动标准化的任何过程”。黄金路径长久以来一直被认为是成功的平台(和 DevOps)设置的一个重要目标。
Grünberg 在 PlatformCon 2023 的演讲 “Build golden paths for day 50， not day 1!” 中深入探讨了软件工程组织为何以及如何应将重点转移到长期黄金路径，并给出了具体例子。让我们来探究大多数平台团队处理黄金路径的方式所存在的问题，平台团队如何纠正优先事项以及可扩展的黄金路径实际上是什么样的。
在决定构建哪些黄金路径以及构建顺序时，太多组织将应用和开发生命周期中的首要过程视为首要任务。他们开始优化只在应用生命周期的第 1 天发生的过程，如通过脚手架创建新的应用或服务。但是，当评估应用的整个生命周期时，很明显，第 1 天的黄金路径并没有走多远。优先考虑第 2 天到第 50 天(或者第 1000 天)的黄金路径对开发者生产力和业务表现的影响要大得多。
Grünberg 在平台工程成为所有人关注的焦点 manyears 之前就开始研究顶级工程组织的做法。他长期以来一直认为这种优先级失败是平台工程中十大谬论之一，他写道：“您的团队将投入到应用中的时间，创建过程不到 1%。”在他看来，这个链中很小的一部分的投资回报率太小，不足以证明先投资其黄金路径。组织应该转而投资第 50 天及以后的黄金路径。
Netflix 联合平台控制台的第一个版本，即开发人员门户网站，表明并非所有黄金路径都具有同等价值。高级软件工程师 Brian Leathem 分享说，平台团队的原始目标之一是“统一端到端体验以改善可用性”。
通过用户研究，Leathem 的团队发现，开发人员在工作流程中分布的大量工具中挣扎。他们还发现，有限的发现既伤害了新开发人员，也伤害了老开发人员，这使他们很难上手，或者不知道可以改进现有工作流程的新产品。他们选择的解决方案是一个平台控制台，或者如 Leathem 所描述的那样，是一个“开发人员的共同前门”。
他们采用了 Backstage 插件 UI，以便他们可以将开发资源投入到为 Netflix 门户建立自定义 UI 组件中。结果是一个门户，用户可以在单个视图中管理软件开发生命周期中的软件。他们引入了“收藏集”，也就是开发人员希望一起查看和评估性能的一组服务，以减轻管理多个服务和软件的负担。他们决定仅使用黄金路径(Leathem 使用术语“铺好的道路”)来解决发现问题。
起初，黄金路径是一个静态网站，其中包含所有文档，并为开发人员解决的问题推荐适当的工具。目标是将黄金路径编织到控制台中，以更深入地将文档与其对应的运行服务集成。在更长远的将来，Leathem 的团队还希望建立功能，以便开发人员通过控制台创建、修改和操作服务。
在对平台控制台第一版的反馈中，Netflix 的开发人员表示“查看和访问”的体验还不够吸引人，不足以促使他们放弃旧习惯和例行程序。作为响应，平台团队将重点转移到现有工具无法提供的端到端工作流程上，以保持用户返回控制台。在 Leathem 的 PlatformCon 2023 演讲中，他说这种方法极大地提高了控制台上用户的复现。
Netflix 的例子表明，平台不仅仅是需要开发者门户组件才能吸引用户。开发者希望端到端工作流程的黄金路径。
此外，可用性只是平台可以改进的众多问题之一。例如，组织可以设计黄金路径，通过关注端到端工作流程来改善可用性、生产力和可扩展性。不同工作流程的黄金路径可以通过设计实现标准化和真正的开发者自助服务。
要涵盖应用生命周期的更大部分，针对第 50 天的黄金路径确定优先级可能很艰巨。受他的研究的启发，von Grünberg 提出了一个简单的练习，以帮助平台团队确定他们的优先顺序应该是什么，这取决于开发人员和运维人员与特定过程相关的频率和等待时间。下表是一个根据对 100 次部署的评估得出的这个分析可能的样子。
| 过程 | 频率(部署的百分比) | 开发时间(小时,包括等待和错误) | 运维时间(小时,包括等待和错误) |
|---|---|---|---|
| 添加/更新应用配置(如环境变量) | 5%* | 1* | 1* |
| 添加服务和依赖关系 | 1%* | 16* | 8* |
| 添加/更新资源 | 0.38%* | 8* | 24* |
| 重构和记录架构 | 0.28%* | 40* | 8* |
| 因环境阻塞而等待 | 0.5%* | 15* | 0* |
| 启动环境 | 0.33%* | 24* | 24* |
| 开发人员入职,重新训练和换挡团队 | 1%* | 80* | 16* |
| 回滚失败部署 | 1.75% | 10* | 20* |
| 调试,错误跟踪 | 4.40% | 10* | 10* |
| 等待其他团队 | 6.30% | 16* | 16* |
*每100次部署
从此表中，组织可以对其黄金路径需要解决的过程获得全面的了解。
自 2022 年初格林伯格分享了这个练习以来，他说平台工程社区的爆炸式增长使他能够观察到数千个顶级工程组织中最常见和最紧迫的痛点，并了解缓解这些痛点的成功方法。这些见解对于理解平台团队需要优先优化的第 50 天过程类型以及最好的优化方式非常有价值。他发现，首先用黄金路径解决最紧迫的痛点始终能带来最好的投资回报率。更重要的是，他了解到大多数组织在这些过程中的痛点具有相同的根本原因，可以通过直接解决这个共同原因来很大程度上加以缓解。
问题在于，大多数组织的 IDP 只在应用基础架构不变的情况下才允许开发人员将更新的镜像从一个阶段部署到另一个阶段。这些静态配置文件是针对一组静态环境和基础设施手动编写脚本的，因此，在超出最简单用例的情况下，它们容易出错或产生过多的开销。
使用静态配置管理，回滚、更改配置、添加服务和依赖关系以及类似的复杂任务对开发人员来说都是艰巨的。他们可以选择自己管理基础设施，减少编码时间并创建影子运维，或者他们可以提交工单给运维人员，增加等待时间并加剧现有的瓶颈。
使用静态配置管理，开发人员和运维人员都得不到好处。因此，解决静态配置管理挑战的黄金路径具有优化更大范围流程的更大潜力。
组织不应该满足于静态配置管理，而应该实现动态配置管理(DCM)。DCM 是“用于构造计算工作负载配置的方法学。开发人员创建工作负载规范，描述工作负载成功运行所需的一切。然后将该规范用于动态创建配置，以便在特定环境中部署工作负载。” 使用 DCM，开发人员不会因需要为工作负载定义或维护任何特定于环境的配置而受阻。DCM 通过设计推动标准化，并实现真正的开发者自助服务。
Humanitec Platform Orchestrator 与工作负载规范 Score 的组合通过遵循RMCD(读取、匹配、创建、部署)模式实现 DCM:它读取并解释工作负载规范和上下文，匹配正确的配置模板和资源，创建应用程序配置并将工作负载部署到连接到其依赖项的目标环境。 平台编排器是任何企业级 IDP 的核心，因为它使平台团队能够在每次 git push 时强制执行组织范围的标准。
在他的 PlatformCon 2023 演讲中，von Grünberg 分享了一些例子，说明平台编排器如何促进具有重大影响力和可扩展性的黄金路径的创建。这些示例也出现在基于 AWS 的 Humanitec IDP 参考架构的设置中。
例如，下图所示的黄金路径可以更有效、更一致地将开发人员对工作负载所做的更改部署到 dev。
假设开发人员想要将工作负载上的更改部署到 dev。开发人员所要做的就是修改工作负载并将其推送到代码。从那里，CI 流水线获取代码并运行它，镜像被构建并存储在镜像仓库中。
工作负载源代码包含工作负载规范 Score:
在这个例子中，工作负载规范的 resources 部分说明开发人员需要一个 Postgres 数据库类型、S3 存储类型和 DNS 的 DNS类型。
CI 构建完成后，平台编排器意识到上下文并查找与其匹配的资源。它检查资源是否已创建，并访问亚马逊网络服务(AWS) API 以检索资源凭据。目标计算在此体系结构中是 Amazon Elastic Kubernetes Service (EKS)，所以平台编排器会以清单的形式创建应用配置。 然后，平台编排器使用 Vault 在运行时将机密注入容器来部署配置。
这样的部署经常发生，所以优化这个过程对开发者和整个业务有很大帮助。
在静态设置中，许多黄金路径在面对系统不熟悉的开发人员请求时就会失败。使用 DCM，一切都是基于存储库的，开发人员可以扩展可用资源集或自定义资源。
例如，如果开发人员需要 ArangoDB 但迄今为止设置还不知道，他们可以将资源定义添加到组织的一般基线中。通过这种方式，开发人员已经以可以由下一个开发人员重用的方式轻松扩展了设置。
更新资源是一个很好的例子，说明平台工程师如何使用平台编排器保持高度标准化。
假设您想更新资源“Postgres”到最新版本的 Postgres。
使用动态方法处理黄金路径，您需要更新的“事物”只是指定 Postgres 的资源定义。
您可以通过 ping 平台编排器 API 或在资源定义部分的 UI 中查找当前依赖于资源定义的工作负载。 一旦确定，您可以在所有依赖资源的工作负载上自动强制部署。
通过这个黄金路径，在所有工作负载和依赖项中推出更新的资源变得简单且可扩展。
当平台团队投资于这些可扩展的黄金路径时，von Grünberg 认为，每个人都会受益。 利用平台编排器和 DCM 的黄金路径使开发人员和运维人员能够从 IDP 开发的最早阶段起更轻松、更安心地执行常见任务，提供更多价值。
根据 von Grünberg 的说法，使用这种方法铺设黄金路径还可以催生平台团队的一个重要心态转变。 使用 DCM，每一天都可以成为第 1 天，成为进一步优化和减少技术债务的机会。 这种转变使组织能够发挥平台工程的最大效用。
Humanitec 基于麦肯锡的研究创建了针对 AWS、Azure 和 GCP 的参考架构。这些资源更详细地演练了推荐的黄金路径示例，以及它们如何适应更大的 IDP 架构。