第69章|平台工程 1:Internal Developer Platform(IDP)与 Golden Path

当团队从十人扩到百人,“每个人自己搭一套流水线”会变成不可承受的认知税:同样的坑被踩一百遍,同样的集成问题在 Slack 里重复一百次。 内部开发者平台(IDP)把合规的默认值、模板与工具链产品化Golden Path(黄金路径)则是那条被官方认可、有人维护、可观测的默认交付高速公路。 本章讲清 IDP 的分层、Golden Path 的边界,以及如何把自助能力做成可持续运营的内部产品。

IDP

Curated platform

  • templates · APIs · guardrails
  • one paved road per stack
  • owned by platform team
Golden Path

Opinionated default

  • scaffold → CI → deploy
  • batteries included
  • escape hatches documented
Self-serve

Reduce toil

  • RBAC + quotas
  • service catalog
  • next: developer portal

1. 从“工具清单”到“平台”:差的是一个产品愿景

很多组织买了一堆 SaaS(Git、CI、K8s、观测),却缺少把它们粘成一致体验的那一层。 IDP 不是某一个工具,而是面向内部开发者的能力组合:身份、项目脚手架、流水线模板、环境供应、密钥与策略、可观测性与成本标签——并且有 owner、有版本、有弃用策略。 若把 IDP 当成“运维顺便维护的脚本堆”,它会迅速腐烂;若当成内部产品,就会有路线图、SLO、文档与满意度调研。

一句话:Golden Path 是“推荐路线”;IDP 是“修路、立牌、设收费站(治理)与救援电话(支持)”的一整套体系。

2. IDP 分层:体验层、编排层、资源层

体验层可以是开发者门户、CLI 或 ChatOps;编排层是 CI/CD、GitOps、策略引擎;资源层是集群、数据库、消息队列与网络。 平台团队通常在编排层施加最大杠杆:一条标准流水线胜过十份 wiki。

Internal Developer Platform — layered view Experience — portal / CLI / API discover templates · request env · view pipelines & SLOs Developer as customer Orchestration — CI/CD · GitOps · policy reusable workflows · OPA · secrets rotation · approvals Resources — K8s · data · network · observability quotas · multi-tenant isolation · FinOps tags
图 1:IDP 是分层蛋糕——上层决定“好不好用”,中层决定“是否一致”,下层决定“是否安全且付得起”。

3. Golden Path:不是唯一路径,而是“默认且体面”的路径

Golden Path 常被误解为“禁止偏离”。更健康的定义是:官方维护、测试充分、与合规一致的路径; 偏离(escape hatch)必须可文档化、可审计、有时限——例如临时集群、例外审批、技术债 backlog。 路径上应内建观测默认值(tracing/metrics/logs)、安全默认值(mTLS、镜像策略)与成本默认值(标签、副本下限)。

From many options → one paved Golden Path custom CI hand-rolled K8s snowflake scripts Golden Path maintained · tested · governed Escape hatch: time-boxed exceptions + architecture review — not “shadow IT forever” platform team merges learnings back into the path (version bumps, new templates)
图 2:Golden Path 把“无数种野路子”收敛成一条可运营的默认路线;例外是制度化的,而不是隐形的。

4. 自助能力:模板、脚手架与流水线即代码

自助不是“把 root 密码给开发者”,而是在边界内授权:命名空间配额、预置网络策略、批准的 base image、可克隆的 cookiecutter / backstage 模板。 流水线应参数化(语言版本、区域、特性开关),并把差异收敛在少量受支持的组合上——组合爆炸是平台债务的温床。

# Illustrative Backstage template parameters (conceptual YAML)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: spring-api-golden
spec:
  parameters:
    - title: Service identity
      properties:
        componentId:
          title: Name
          type: string
        owner:
          title: Team
          type: string
        region:
          title: Region
          type: string
          enum: [eu-west-1, us-east-1]
  steps:
    - id: fetch
      name: Fetch skeleton
      action: fetch:template
    - id: publish
      name: Push repo & register catalog
Capability Anti-pattern Golden Path way
New service bootstrap copy-paste from random repo versioned template + catalog entry
Deploy kubectl apply from laptop GitOps + approved chart values
Secrets shared kubeconfig / long-lived tokens OIDC + short-lived creds + vault integration
Observability opt-in tracing “when we have time” auto-instrumented defaults on path

5. 平台团队如何运作:内部客户、路线图与 SLO

借用 Team Topologies 的语言,平台团队常扮演赋能型(Enabling)平台型(Platform)的混合体:既要交付 paved road,也要通过结对、文档与办公时间降低采纳摩擦。 成功的 IDP 会公开内部 SLO:模板 PR 合并时效、流水线 P95、门户可用性;并把“减少开发者等待时间”当作北极星之一。

Platform-as-product loop Discover pain surveys · DORA · support tickets Prioritize roadmap · OKRs · deprecations Ship & measure adoption · MTTR · toil reduced Communicate changelog · lunch & learn continuous feedback (not annual “platform project”)
图 3:平台若没有反馈环,就会退化成“没人用的完美架构”;产品化运营让它活着进化。

6. 与下一章的衔接:开发者门户与可发现性

IDP 的“体验层”往往落在一个门户上:服务目录、文档、所有权、运行手册与流水线链接同屏出现。 下一章将深入 Backstage 等门户的插件模型,以及如何把可发现性(Discoverability)做成治理的一部分。

7. 本章清单

  1. 能区分 IDP(能力组合 + 运营)与单一工具;理解体验/编排/资源三层。
  2. 能定义 Golden Path:默认路线、例外策略、与逃逸舱口(escape hatch)。
  3. 能把模板、脚手架、流水线参数化与组合控制联系起来。
  4. 理解平台团队作为内部客户的交付方式:路线图、SLO、弃用与沟通。
  5. 预告:第 70 章 Backstage 与开发者门户
← 上一章:FinOps 下一章:Backstage 与开发者门户 →