1. 平台工程与开发者自助服务导论

在云原生与微服务架构普及之后,许多组织发现一个矛盾现象:基础设施能力越来越强,但开发者交付一个可运行服务的周期却没有同步缩短。原因往往不在技术本身,而在于“能力”与“使用者”之间缺少一层被精心设计的产品化界面。平台工程(Platform Engineering)正是为弥合这一鸿沟而出现的工程学科,而开发者自助服务(Developer Self-Service)则是它最直接、最可感知的交付形态。

平台工程的核心价值:把基础设施能力产品化

传统模式下,基础设施团队以“工单+审批”的方式响应需求:开发者提交申请,运维排期、手工配置、回传连接信息。这种模式在规模小、变更少时可行,但当团队数量增长到几十个、服务数量达到数百个时,瓶颈会迅速显现——等待时间不可预测、配置漂移难以审计、知识集中在少数人身上。

平台工程的核心主张是:把基础设施与运维能力封装成“内部产品”,由平台团队像产品经理一样运营,向开发者提供稳定、可发现、可自助使用的接口。这里的“产品”不是抽象口号,而是有明确契约的交付物,例如:

  • 一个标准化的服务模板,包含代码骨架、CI/CD 流水线、可观测性接入与安全基线;
  • 一个自助门户或 CLI,开发者可在数分钟内申请命名空间、数据库或消息队列;
  • 一套策略即代码(Policy as Code)约束,在自助的同时保证合规与成本可控。

平台工程的价值可以归纳为三个维度:速度(缩短从想法到生产的时间)、一致性(所有服务遵循同一套安全与运维标准)、认知减负(开发者不必成为 Kubernetes、网络或 IAM 专家即可交付)。需要强调的是,平台工程不是“把运维工作推给开发者”,而是把重复、易错、低价值的操作自动化,让开发者专注于业务逻辑。

开发者自助服务的定义与边界

开发者自助服务是指:开发者通过受治理的自动化通道,在不依赖人工审批或人工操作的前提下,获取并使用平台所提供的能力。它的关键特征包括自助性(无需等待他人)、治理性(在预设策略内)、可重复性(同样输入得到同样结果)和可观测性(谁在何时申请了什么、结果如何)。

但自助服务并非“无边界”。边界通常由三类因素决定:

  1. 风险等级:创建开发环境命名空间可以完全自助;而涉及生产数据库主库删除、跨订阅网络对等连接等高风险操作,仍需人工审批或双人复核。
  2. 成本归属:自助申请的资源必须绑定成本中心与预算阈值,超出阈值时自动降级或触发审批。
  3. 合规要求:受监管行业的数据驻留、加密、审计日志等要求,必须内嵌到模板与策略中,而不是依赖开发者自觉遵守。
判断一项能力是否适合自助化,可以用一个简单问题:如果 100 个开发者同时以相同方式申请,平台能否在不增加人工负担的前提下保证结果一致且合规?若答案是否定的,应先完善策略与自动化,再开放自助入口。

Azure 在平台工程中的定位

Azure 既是平台工程要封装的“能力来源”,也是承载自助服务控制面的“运行底座”。从平台团队视角看,Azure 提供了几类关键构件:

  • 资源与身份底座:订阅、资源组、托管标识(Managed Identity)、Microsoft Entra ID,用于隔离、授权与审计;
  • 基础设施即代码:Bicep、ARM 模板、Terraform,用于把环境定义成可版本化、可重复部署的代码;
  • 策略与治理:Azure Policy、RBAC、成本管理,用于在自助通道上施加约束;
  • 交付与运行:Azure DevOps、GitHub Actions、AKS、Container Apps、Azure Functions,用于构建、部署与运行工作负载;
  • 自助入口:Azure Portal、CLI、Developer Portal(如 Backstage 集成)或自定义门户,作为开发者触达平台能力的界面。

一个常见的架构分层是:最底层是 Azure 订阅与网络等基础资源;中间层是平台团队维护的“黄金模板”与策略;最上层是开发者自助入口。开发者只与最上层交互,中间层与底层由平台团队持续演进。下图展示了这一分层关系以及一次典型自助申请的流转路径。

平台工程分层与开发者自助申请流转 开发者自助入口层 自助门户 / CLI 服务模板目录 Backstage 插件 GitOps 仓库入口 平台控制面(平台团队维护) 黄金模板 Bicep / Terraform 策略即代码 Azure Policy / RBAC 流水线模板 CI/CD 与安全扫描 成本与配额 预算 / 标签策略 Azure 基础资源层 订阅 / 资源组 隔离与生命周期 Entra ID 身份与授权 AKS / Container Apps 运行工作负载 数据库 / 消息 / 存储 托管服务能力 自助流转:开发者选择模板 → 平台校验策略与配额 → 自动部署到 Azure → 返回连接信息与可观测入口

图中自上而下分为三层:开发者自助入口层、平台控制面、Azure 基础资源层。一次典型的自助申请从入口层发起,经过控制面的模板渲染与策略校验,最终在 Azure 基础资源层落地,并把连接信息、可观测性入口和成本标签回传给开发者。整个过程无需人工工单,但每一步都受策略约束。

从“能自助”到“敢自助”:治理是前提

很多团队在引入自助服务时容易走向两个极端:一是开放过度,开发者可以随意创建高成本或高风险资源,导致账单失控与安全漏洞;二是管控过严,自助入口形同虚设,开发者仍要回到工单流程。平衡点在于把治理“左移”到模板和策略中。

以 Azure 为例,一个可落地的做法是:平台团队在管理组(Management Group)层级分配 Azure Policy,强制要求所有资源必须带 costCenter 与 environment 标签;在订阅层级设置预算与配额;在模板中预置诊断设置与私有终结点。开发者自助申请时,只需选择“开发环境 / 测试环境 / 生产环境”和成本中心,其余合规细节由平台自动补齐。这样,自助服务既保持了速度,又不会突破组织底线。

平台工程的成熟度可以用一个简单指标衡量:新服务从代码提交到生产可用的时间,以及其中人工介入的次数。自助服务做得越好,这个时间越短、人工介入越少,同时合规审计的覆盖率反而越高。

本课程的学习路径