6.6. 平台工程：Golden Path、开发者门户与 DORA

平台工程不是「把 Kubernetes 包一层 UI」，而是把组织的交付经验固化成一条自助的 Golden Path：开发者不需要成为 Kubernetes 专家，也能安全地申请环境、部署、观测和回滚。它既是产品，也是组织能力。

层级:

L4 · 实战

难度:

进阶

预计:

50 分钟

前置:

GitOps、CI/CD、SRE、多集群基础

6.6.1. 从 DevOps 到平台工程

阶段

关注点

典型产出

DevOps

团队协作与反馈闭环

CI/CD、SLO、复盘

平台工程

把交付能力产品化

自助门户、Golden Path、模板

多集群治理

规模化与一致性

策略分发、集群生命周期、成本

平台工程不是替代 DevOps，而是把 DevOps 的最佳实践封装成「默认正确」的路径。

6.6.2. Golden Path

一条好的 Golden Path 应该包含：

  • 脚手架：新服务模板，自带 Dockerfile、Helm/Kustomize、CI、监控、告警。

  • 环境：dev/staging/prod 一键申请，配额与网络策略预置。

  • 交付：GitOps 仓库 + 流水线 + 渐进式发布。

  • 观测：默认仪表盘、日志、链路、SLO 模板。

  • 安全：签名、准入、密钥、依赖扫描默认开启。

  • 文档：如何做、如何排错、如何升级。

Golden Path 不是唯一路径；要允许团队偏离，但偏离要有理由与补偿控制。

6.6.3. 开发者门户：Backstage

Backstage 用 Software Catalog 管理服务、API、资源所有权，用 Templates 创建新项目，用 TechDocs 聚合文档。

catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: demoapp
  annotations:
    backstage.io/techdocs-ref: dir:.
    argocd/app-name: demoapp
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout

目录的价值不是「好看」，而是让 on-call 能快速找到 owner、runbook、仪表盘和部署状态。没有维护的目录会迅速腐烂。

6.6.4. 自助与多租户

  • 命名空间即产品：团队申请命名空间，自动带配额、NetworkPolicy、RBAC、监控。

  • vCluster/Capsule/HNC：为团队提供隔离的虚拟集群或层级命名空间。

  • Crossplane/Cluster API：把数据库、消息队列、集群变成 Claim。

  • 策略：所有自助资源都经过 Kyverno/Gatekeeper 校验。

自助的边界要清楚：团队能改什么、不能改什么、超出边界如何申请。

6.6.5. DORA 与平台指标

DORA 四项指标：

  1. 部署频率：多久发布一次。

  2. 变更前置时间：commit 到生产的时间。

  3. 变更失败率：发布导致回滚/事故的比例。

  4. 恢复时间：故障到恢复的时长。

平台还要看：自助完成率、Golden Path 采用率、环境申请时长、平台可靠性、单位成本。指标用于改进，不用于排名。

6.6.6. 组织与团队拓扑

  • 平台团队：把平台当产品，有产品经理、SRE、开发者体验工程师。

  • 应用团队：对自己的服务与 SLO 负责，使用 Golden Path。

  • 赋能团队：帮助应用团队采用平台能力，不长期替他们运维。

平台团队最常见的失败是「做了很多工具，但没人用」。先找 2-3 个种子团队，陪跑、收集反馈、迭代。

6.6.7. 实验：一条最小 Golden Path

  1. 用 Backstage Template 创建一个服务仓库（Dockerfile + Helm + CI）。

  2. 合并后 CI 构建镜像并更新 GitOps 仓库。

  3. Argo CD 部署到 dev，自动创建 ServiceMonitor 与告警。

  4. 用 Backstage Catalog 查看 owner、runbook、Argo CD 状态。

  5. 让一个不熟悉 Kubernetes 的开发者独立完成一次发布。

6.6.8. 验证清单

  • 新服务能在 30 分钟内走到 dev 环境。

  • Golden Path 自带 CI、GitOps、监控、告警、安全策略。

  • 服务目录有 owner、runbook、仪表盘、部署状态。

  • 自助资源的配额、网络、RBAC 默认正确。

  • DORA 与平台采用率有数据。

  • 平台有产品路线图与反馈闭环。

6.6.9. 排错表

现象

原因

处理

平台没人用

路径比手工还复杂

找种子团队，缩短路径

目录信息过期

无 owner/自动同步

用 Git 同步，定期清理

自助资源失控

无配额/策略

默认配额、Kyverno 校验

平台团队成瓶颈

所有变更都要平台审批

扩大 Golden Path，保留例外通道

指标好看但体验差

只考核采用率

加开发者满意度与 lead time

6.6.10. 进阶挑战

  1. 用 Backstage 创建一个服务模板，自动生成 CI 与 Helm Chart。

  2. 用 Crossplane 提供「数据库 Claim」，应用团队自助申请。

  3. 计算团队的 DORA 四项指标，找一项改进。

  4. 设计一条「偏离 Golden Path」的审批与补偿控制。

6.6.11. 小结

  • 平台工程把 DevOps 能力产品化，核心是 Golden Path 与自助。

  • 门户/目录要解决「找 owner、找 runbook、看状态」，不是装饰。

  • 多租户与策略要默认正确，例外有流程。

  • 用 DORA 与采用率衡量平台，不用工具数量。

6.6.12. 延伸阅读