开发者体验与内部开发者门户：平台工程落地

DX = 开发者从"想法"到"生产可观察"整个旅程的顺畅度
坏体验代价：文档过时/环境难配/权限等三天 → 交付慢；把重复摩擦做成默认路径，DX 即交付速度

黄金路径 = 为 80% 常见场景定义的"推荐直达路线"：脚手架生成服务 → 自动接 CI → 建环境 → 部署 → 监控
模板内置安全基线（非 root/限制端口/审计日志）；偏离黄金路径的自定义要付出更高维护成本，由团队权衡

IDP = 开发者自助操作平台能力的统一入口：建服务/开环境/查目录/看 CI-CD/开权限/看评分
不是又一个运维后台，而是"以开发者为中心"的编排层，背后调用各平台 API

# 软件目录实体（catalog-info.yaml）：服务登记进目录
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: shop-api
  annotations:
    backstage.io/techdocs-ref: dir:.   # 技术文档即代码
    argocd/app-name: shop-api
spec:
  type: service
  lifecycle: production
  owner: team-payment

Backstage：开源、插件生态丰富（CI/CD/监控/文档/成本），需自部署维护，适合有平台团队的大中型组织

价值：把"新建服务 18 步操作"收敛为"填 5 个字段，一键生成 PR"
模板内置目录结构/CI/Dockerfile/K8s 清单/安全基线/监控/文档 → 新服务第一天就合规可观测

# Backstage Software Template（概念）
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: node-service
spec:
  parameters:
    - title: 基本信息
      properties:
        service_name: { type: string }
        language: { enum: [node, go, python] }
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.service_name }}
    - id: publish
      action: publish:github
      input: { repoUrl: "github.com?repo=${{ parameters.service_name }}" }
    - id: register
      action: catalog:register

自服务不等于放任：权限由角色模板控制，配额自动授予（命名空间/CI 并发/云资源限额），超限走审批
目标：90% 常规操作自助完成，只有"例外"才打扰平台团队

传统痛点：共享 staging 排队互踩、坏了没人修
环境即代码：环境由模板声明（Infra+数据+配置），一键创建/销毁，每个 PR 开独立预览环境

preview-env:          # 声明式描述一个预览环境
  cluster: dev-eu
  namespace: pr-${{ pr_number }}
  services: [shop-api, shop-db]
  ingress: true
  ttl: 4h          # 4 小时后自动销毁
  data: seed-order-dataset   # 种子数据

没有 TTL 的环境 = 昂贵的垃圾：PR 合并/超时自动销毁，空闲环境定期扫描下线
环境成本按团队/PR 计费曝光给开发者；非活跃环境 7 天自动回收

服务目录 = 组织的"服务户口本"：每个服务登记 owner/依赖/SLO/技术栈
新人可发现、架构可盘点、故障可找人、合规可审计；catalog-info.yaml 进 Git 自动同步

rules:                    # 未达标服务亮红灯
  has_owner:      { required: true }
  has_slo:        { required: true }
  has_techdocs:   { required: true }
  no_p0_vulns:    { required: true, source: snyk }
  oncall_set:     { required: true }

评分卡把"平台最佳实践"变成可执行门禁：新服务不达标 → 不能上生产；存量不达标 → 限期整改

评分可作为发布前置条件：P0 漏洞未清零、SLO 未定义 → 生产发布被阻断并给出修复指引

自助率：常规操作经 IDP 自助完成比例（目标 >80%）
等待时长：开环境/开权限/建服务的中位时长
流式时长：PR 到生产的手动干预次数；环境成本：按服务/团队的环境小时数

不要用"代码行数/PR 数"衡量生产力（易作弊且误导）；DX 度量是找摩擦不是考核人

第 1 步：盘点高频摩擦（建服务/开环境/开权限，各多少天）
第 2 步：先做最小 IDP：服务目录 + 一个高频自服务（建服务脚手架）
第 3 步：逐步接入环境即代码、评分卡、权限自服务
第 4 步：度量自助率与等待时长，迭代消除下一个摩擦点
原则：一次只解决一个痛点，别想一口吃成"全功能门户"

平台团队 = 产品团队，服务对象是内部开发者：收集需求（像对待外部客户）→ 提供能力（黄金路径+自服务）而非"救火队"
平台能力自身也要有 SLO：可用性、响应时间

先用低代码/SaaS 验证价值 → 规模化再上 Backstage 定制；平台能力做成"内部产品"：有路线图/反馈渠道/发布说明

IDP 能建服务/开权限/动环境 = 天然高权限系统：SSO+MFA、RBAC 细粒度、操作审计、暴露面最小化

roles:
  developer: { actions: [create_preview_env, scaffold_service], scopes: [own_team] }
  team-lead: { actions: [approve_env_ttl, manage_secrets], scopes: [own_team] }
  platform:  { actions: ["*"], scopes: ["*"] }

原则：最小权限 + 团队作用域；高风险动作（生产凭证/跨团队权限）走审批链

门户操作全留审计日志（谁/何时/做了什么/结果）接入 SIEM；定期评审角色清单、删僵尸账号

某支付公司（概念案例）：新建服务平均 5 天（等权限 2 天/配环境 1 天/改模板 2 天）
改造：Backstage 目录 + 脚手架模板 + 预览环境 + 评分卡
结果：首部署从 5 天降到 40 分钟；自助率 23%→82%；平台团队从"救火"转向"做能力"，工单降 60%

□ 定义 2-3 条黄金路径并内置安全基线
□ 用 IDP（Backstage/Port）建服务目录，catalog-info 进 Git
□ 脚手架覆盖"新服务第一天的全部标准配置"
□ 环境即代码：PR 预览环境 + TTL 自动回收
□ 评分卡联动发布门禁，新服务不达标不能上生产
□ 用 DORA+SPACE+自助率度量 DX，指标用于找摩擦而非考核
□ 权限最小化 + 团队作用域，高风险动作审批；门户操作全审计接入 SIEM
□ 一次只解决一个痛点，平台按内部产品运营