3. 设计开发者自助服务的黄金路径

平台工程的核心目标之一，是把开发者从“申请资源、等待审批、反复沟通”的摩擦中解放出来。所谓“黄金路径”，并不是一条唯一正确的技术路线，而是平台团队为最常见、最高频、最值得标准化的开发任务，预先设计好的一条从意图到可用环境的顺畅通道。它把原本分散在工单、邮件、聊天记录和口头约定中的步骤，固化为可自助触发、可审计、可复用的工作流，并映射到 Azure 原生服务上。

要设计黄金路径，第一步不是选服务，而是识别开发者到底在反复做什么。平台团队可以通过访谈、工单分类、CI/CD 日志和云资源标签，归纳出高频任务。典型任务包括：新建一个微服务仓库并接入流水线、申请一套开发/测试环境、部署一个带数据库的 Web 应用、开通对某个存储账户的读写权限、发布一个 API 并配置网关、以及为已有服务增加日志与告警。这些任务往往跨越多个 Azure 资源，且每次都要重复填写相似参数，正是黄金路径的候选对象。

识别出任务后，需要把它拆解为标准化工作流。标准化不是把所有细节写死，而是把“必须一致”的部分固定下来，把“允许差异”的部分参数化。以“新建微服务并部署到开发环境”为例，必须一致的部分包括：命名规范、资源组划分、标签策略、网络出口规则、日志采集方式、密钥存放位置；允许差异的部分包括：服务名称、语言运行时、副本数、数据库规格、是否暴露公网入口。把这些差异抽象为少量输入参数，开发者只需填写服务名、选择运行时和规格档位，其余由平台自动完成。

接下来是映射到 Azure 原生服务。黄金路径的“自助入口”通常由 Azure DevOps 或 GitHub Actions 承载，开发者通过一个模板仓库或流水线表单触发；资源编排使用 Bicep 或 Terraform，把资源组、App Service、Azure SQL、Key Vault、Application Insights 等声明为代码；权限与合规通过 Azure RBAC、Azure Policy 和托管标识实现；环境隔离通过订阅或资源组加标签区分；可观测性统一接入 Log Analytics 与 Azure Monitor。这样，开发者的一次触发，背后是一条由 Azure 原生能力支撑的自动化链路。

把上述结构落到具体实现时，一个可参考的黄金路径参数表如下。它既是平台团队设计模板的依据，也是开发者填写自助表单时的输入界面。表中“固定项”由平台在模板中写死，“参数项”由开发者选择或填写。

以“order-api”为例，开发者在自助表单中填写服务名 order-api、运行时 .NET 8、副本数 2、数据库规格 S0、公网入口否。平台流水线随后执行：创建资源组 rg-dev-team-a-order-api；部署 App Service 计划与 Web App；创建 Azure SQL 数据库并写入 Key Vault 连接串；为 Web App 分配托管标识并授予 Key Vault 读取权限；接入 Application Insights 与 Log Analytics；最后输出访问地址、数据库连接串引用和日志查询入口。整个过程无需人工审批，但每一步都受 Azure Policy 约束，例如禁止公网数据库、强制标签、限制可用区域。

需要强调的是，黄金路径不是“唯一路径”。平台团队应允许开发者在特殊场景下走例外流程，但例外必须被记录、被审计，并定期回看是否应转化为新的标准路径。黄金路径的价值在于覆盖 80% 的常见任务，而不是追求 100% 的强制统一。随着团队反馈和 Azure 服务更新，路径本身也应版本化演进，例如从 App Service 扩展到 Container Apps，或从单环境扩展到多环境晋升。这样，开发者自助服务才不是一次性的模板，而是持续降低认知负荷、提升交付速度的平台能力。