平台工程与内部开发者平台

“每个团队自己搭 CI/CD、自己写部署脚本、自己维护一套 YAML"是微服务时代最昂贵的隐性成本。平台工程（Platform Engineering）给出的答案不是"再造一个运维团队”，而是把基础设施能力当成产品来做，为开发者提供一条被精心铺好的黄金路径。本文讲清楚它和传统 DevOps 的分工、能力怎么分层、以及如何用数据证明平台的价值。

1. 平台工程：从"运维工具"到"内部产品"

1.1 为什么"你构建它，你运行它"没有解决问题

DevOps 的初衷是打破开发与运维的墙，让团队端到端负责。但落到规模化组织，它带来了新问题：

DevOps 把责任下放了，却没有把能力沉淀。平台工程补的正是这一环：把重复的基础设施工作集中成产品，让业务团队专注业务。

1.2 平台即产品（Platform as a Product）

最核心的观念转变：平台是产品，开发者是用户。这意味着平台团队要像做 C 端产品一样思考：

传统运维团队                    平台团队
─────────────                  ─────────────
以工单驱动                      以产品驱动
指标：工单量、SLA               指标：采纳率、开发者满意度
交付：脚本、文档                交付：自助服务、模板、黄金路径
关系：服务提供方-请求方          关系：产品团队-用户
成功：系统不挂                    成功：开发者愿意用、用得爽

“开发者愿意用"是唯一真正的验收标准。如果平台是强制摊派的，团队会绕开它自建（Shadow IT），平台就变成了昂贵的摆设。

1.3 与 DevOps / SRE 的分工

三者不是替代关系，而是分工：

• DevOps：文化与协作方式——开发与运维共担责任。
• SRE：可靠性工程方法——SLO、错误预算、减少琐事。
• 平台工程：把前两者需要的能力产品化，降低使用门槛。

平台工程是 DevOps 理念在规模化组织下的工程化落地，它让"共担责任"变得可行——因为该有的工具都现成且好用。

2. 黄金路径与自助服务

2.1 什么是黄金路径

**黄金路径（Golden Path）**是为最常见场景预设的、经过验证的、开箱即用的端到端路径：从创建仓库、写代码、跑 CI、部署到生产、观测，全部有默认答案。

黄金路径的三个特征：

1. 有主见（opinionated）：给出默认选择而不是一堆选项。默认 Node.js + Postgres + K8s，而不是"你想用什么就用什么”。
2. 可脱离（escapable）：黄金路径是默认而非唯一，遇到特殊需求可以退出，但要付出额外成本。
3. 端到端：覆盖从零到上线的完整链路，而不是只解决其中一段。

开发者视角的黄金路径

  scaffold ──→ commit ──→ CI ──→ 部署 ──→ 观测
     │           │        │       │        │
  一条命令    自动检查  默认流水线  一条命令  默认看板
  生成骨架    代码规范  测试/构建  上预发/生产  日志/指标/追踪

  每一步都有默认答案，特殊需求才需要额外配置

2.2 脚手架与模板

黄金路径的入口是脚手架（Scaffolder）。它把"新建一个服务"从半天的手工操作压缩成一条命令：

# Backstage Software Template：服务脚手架
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-microservice
  title: Go 微服务模板
spec:
  parameters:
    - title: 基本信息
      properties:
        name:
          type: string
          description: 服务名（小写字母与连字符）
        owner:
          type: string
          ui:field: OwnerPicker
        tier:
          type: string
          enum: [tier1, tier2, tier3]   # 影响 SLO 与告警策略
  steps:
    - id: fetch
      action: fetch:template
      input: { url: ./skeleton, values: { name: "${{ parameters.name }}" } }
    - id: publish
      action: publish:github
      input: { repoUrl: "github.com?repo=${{ parameters.name }}" }
    - id: register
      action: catalog:register
      input: { repoContentsUrl: "${{ steps.publish.output.repoContentsUrl }}" }
    - id: pipeline
      action: github:actions:dispatch
      input: { workflowId: bootstrap.yaml }

一次执行产出：代码骨架（含 Dockerfile、健康检查、结构化日志、OpenTelemetry 埋点）、CI 流水线、K8s 清单、监控看板、服务目录登记。开发者拿到的不是"空仓库 + 一堆文档"，而是能直接跑起来并上线的服务。

踩坑点：模板一旦发布就会长期存在，更新旧仓库极其困难。因此模板里应尽量少放业务代码、多引用共享库，把可变部分（如基础镜像版本）做成可集中升级的依赖。

2.3 自助服务的边界

自助服务不等于"什么都让开发者自己点"。要划清三档：

判断标准是风险与频率的乘积：高频低风险的全自助，低频高风险的走审批或代办。把高风险操作也做成全自助，是在给未来的事故埋雷。

3. 平台能力分层

3.1 四层能力模型

平台不是一个大泥球，清晰的分层让各层独立演进：

┌───────────────────────────────────────────────┐
│  L4 开发者门户（Portal / 服务目录 / 文档）      │  ← 开发者看到的那一层
├───────────────────────────────────────────────┤
│  L3 黄金路径（模板 / 脚手架 / 流水线编排）      │  ← 把下层串成路径
├───────────────────────────────────────────────┤
│  L2 平台能力（CI/CD / 环境 / 可观测 / 密钥）    │  ← 可复用的能力单元
├───────────────────────────────────────────────┤
│  L1 基础设施（K8s / 云资源 / 网络 / 存储）      │  ← 底座
└───────────────────────────────────────────────┘

关键纪律：上层只能调用下层的接口，不能绕过。开发者门户不应该直接调 K8s API，而应通过 L2 的能力接口——否则换基础设施时门户要重写。

3.2 各层职责与典型实现

L2 是投入产出比最高的一层：每封装一个能力，所有团队都少做一次重复劳动。优先封装那些"每个团队都要做、做法还都不一样"的能力——CI/CD、密钥管理、可观测性接入、环境申请。

3.3 云原生底座的角色

平台通常建在云原生底座之上。K8s 提供了统一的抽象与调度，但直接把 K8s 暴露给开发者是反模式——开发者不该关心 Deployment、Service、Ingress 的细节。平台的价值之一正是把 云原生架构模式 的复杂度挡在开发者视野之外，只暴露"部署一个服务"“申请一个数据库"这类业务语义。

4. 采纳度与价值度量

4.1 采纳度指标

平台最容易犯的错是"建好了没人用”。必须持续跟踪采纳度：

自助完成率最能反映平台成熟度：如果大量操作仍需找平台团队人工处理，说明能力还没真正产品化。

4.2 价值指标：用 DORA 说话

采纳度证明"有人用"，价值指标证明"用了有效"。DORA 四项指标是公认的度量基准（详见 DORA 指标与研发效能 ）：

# 平台前后对比（示例口径）
deployment_frequency:
  before: "2 次/周"
  after:  "12 次/周"        # 部署更频繁
lead_time_for_changes:
  before: "9.5 天"
  after:  "1.2 天"          # 交付更快
change_failure_rate:
  before: "18%"
  after:  "6%"              # 变更更稳
mttr:
  before: "4.2 小时"
  after:  "35 分钟"         # 恢复更快

度量纪律：必须在平台推广前建立基线，否则事后无法归因。同时要排除干扰因素（同期是否还有组织调整、业务变化），不要把所有改善都算到平台头上。

4.3 反指标：警惕这些信号

有些指标看似漂亮，实则危险：

• 门户访问量暴涨：可能是流程被迫绕路，开发者被迫频繁登录。
• 工单量下降但采纳率也下降：团队绕开平台自建了。
• 平台团队加班时长上升：能力没有产品化，平台团队在手工兜底。
• 模板分支数激增：每个团队都 fork 一份改，说明模板不够灵活。

5. 落地路线与组织

5.1 组织形态

平台团队的组织方式直接影响成败：

推荐第三种：专职团队负责平台，各业务线指定联络人（champion），双向反馈。联络人既把平台能力带回业务线，也把业务线的痛点带回平台。

5.2 分阶段推进

不要一开始就追求"大平台"。按价值递进：

阶段 2 的"速胜"至关重要：先用一个明显的痛点（如"新服务上线要两周"）做出效果，赢得信任，再推进更大的改造。反过来先做大平台再找用户，几乎必然失败。

5.3 与 GitOps 的关系

平台的部署与配置能力通常以 GitOps 为载体：声明式配置进 Git，控制器负责收敛。这样开发者只需提交 YAML，平台负责把它变成真实资源——既自助又可控。具体的 Argo CD 落地方式可参考 GitOps 与 Argo CD ，平台层的做法是把 GitOps 的复杂度完全封装，开发者只面对"部署到哪个环境"这一个语义。

6. 踩坑清单

7. 总结

平台工程的本质是把基础设施能力产品化，为开发者铺一条默认好用的黄金路径。四条主线：

1. 平台即产品：开发者是用户，采纳率与满意度是验收标准。
2. 黄金路径：有主见、可脱离、端到端，脚手架作为入口。
3. 能力分层：L1 基础设施、L2 能力、L3 路径、L4 门户，上层只调下层接口。
4. 度量驱动：采纳度证明有人用，DORA 证明有效，反指标预警偏离。

平台做得好，开发者从"搞定基础设施"转向"专注业务价值"——这才是平台工程真正的产出。它与 平台工程实践 的关系是架构方法论与工程实践的一体两面：前者讲清怎么分层与度量，后者给出具体的工具与流水线实现。