平台工程实战指南基于 claude-skills 的 devops-engineer Skill 构建内部开发者平台【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills平台工程Platform Engineering的目标是把基础设施交付从人工审批工单转变为开发者在几分钟内自助完成。claude-skills 仓库中的devops-engineerSkill 内置了 10 余份领域参考文档其中 platform-engineering.md 正是面向内部开发者平台IDP的实战手册覆盖 Crossplane 自服务组合、Terraform 模块化、Backstage 模板与服务目录、GitOps 仓库布局、ArgoCD 部署、平台指标、多租户隔离与采纳策略。读完本文你将掌握从零搭建一条开发者在门户上点几下即可获得生产级服务的完整技术链路并能直接用 devops-engineer Skill 快速产出可落地的平台配置。平台工程四大核心原则在动手写任何 YAML 之前先建立平台的顶层设计原则。devops-engineerSkill 在触发自服务基础设施、开发者门户、黄金路径golden paths、Backstage等场景时会加载 platform-engineering.md其开篇即给出四条原则自服务优先Self-service first将人工操作降到 10% 以下。衡量标准是开发者无需找平台团队提工单即可完成日常基础设施操作的比例。黄金路径Golden paths提供预先批准、有明确意见的模板让按规范走成为阻力最小的路径而不是靠文档和培训强制约束。开发者体验Developer experience持续度量并优化开发者的生产效率把平台对开发者的摩擦力当作一等公民指标。平台即产品Platform as product用产品思维运营平台有用户、有路线图、有反馈闭环、有版本演进而不是把它当作一次性交付的工程项目。这四条原则贯穿本文后续所有小节Crossplane 负责自服务Backstage 模板承载黄金路径平台指标回答开发者体验而采纳策略则落实平台即产品。自服务基础设施Crossplane Composition实现自服务的第一个技术栈是 Crossplane。它的思路是把云资源RDS、S3、VPC 等封装为集群内的自定义资源CRD应用开发者只需提交一个Database对象控制平面就负责创建底层云资源。核心编排对象是Composition——它定义了用户申请一个Database时底层实际要创建什么# Composition for self-service database apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: postgres-database spec: compositeTypeRef: apiVersion: platform.example.com/v1alpha1 kind: Database resources: - name: rds-instance base: apiVersion: rds.aws.crossplane.io/v1alpha1 kind: DBInstance spec: forProvider: dbInstanceClass: db.t3.micro engine: postgres engineVersion: 15 masterUsername: admin allocatedStorage: 20要点拆解compositeTypeRef声明了对外暴露的复合资源类型XRD——这里是platform.example.com/v1alpha1的Database。开发者永远不会直接看到DBInstance只面对这个简化后的抽象。resources是实际资源模板本例为 AWS RDS 的DBInstancedb.t3.micro、PostgreSQL 15、20GB 存储。一旦开发者kubectl apply一个Database对象Crossplane 就会渲染这个模板并调用 AWS Provider 完成实例创建——这就是自助申请数据库的最小闭环。与仓库内 terraform-iac.md 中的 RDS 配置对照可以看到同样的生产要素storage_encrypted true、backup_retention_period 7、skip_final_snapshot false。建议在 Composition 模板中同样补上存储加密、备份保留、monitoring_interval等字段把平台的安全基线固化在模板层而不是依赖开发者自觉。用 Terraform 模块封装自服务能力在非 Kubernetes 的交付路径上Terraform 模块是自服务的另一种主流实现。原文档给出了一个一个服务 部署 数据库 监控的组合模块骨架# modules/service/main.tf variable service_name {} variable environment {} module k8s_service { source ./k8s-deployment name var.service_name env var.environment } module database { source ./postgres name ${var.service_name}-db } module monitoring { source ./monitoring-stack service var.service_name } output service_url { value module.k8s_service.url }这个模式的价值在于组合与标准化平台团队把k8s-deployment、postgres、monitoring-stack三个子模块维护到生产级服务团队只需要声明service_name和environment两个变量即可获得完整栈。输出service_url供上层如 Backstage直接消费。仓库中的 module-patterns.md 对模块工程化给出了更细的规范与本例配合使用标准目录结构main.tf、variables.tf、outputs.tf、versions.tf声明 provider 版本约束、examples/完整可用示例、tests/Terratest 等。输入校验每个变量用validationblock 校验例如名称长度 1~32、CIDR 必须是合法网段把错误在terraform plan阶段就拦截掉。版本管理组合模块通过source git::https://github.com/org/terraform//servicerefv1.2.3或version ~ 19.0锁版本见 module-patterns.md 的 Module Versioning 小节保证开发者拿到的是经过验证的模块版本。for_each优先于count便于按 key 管理多个资源实例。一致命名与打标签所有可打标签的资源打统一标签为后面的成本分摊Cost Allocation打基础。terraform-engineerSkill见 SKILL.md本身也强调远程状态 DynamoDB 锁、terraform fmt/terraform validate/tflint校验、terraform plan -outtfplan人工批准后再 apply。自服务模块同样要继承这套质量门槛——模块发布前必须通过全部校验而不是把未经验证的模块直接开放给开发者。Backstage 服务模板把黄金路径变成门户操作自服务门户Developer Portal最流行的落地产品是 Backstage其 Scaffolder 用 Template 定义新建一个服务的向导流程。原文档给出了一个微服务黄金路径模板# templates/microservice/template.yaml apiVersion: scaffolder.backstage.io/v1beta3 kind: Template metadata: name: microservice-template title: Microservice Golden Path spec: owner: platform-team type: service parameters: - title: Service Info properties: name: type: string owner: type: string ui:field: OwnerPicker language: type: string enum: [go, python, nodejs, java] steps: - id: fetch action: fetch:template input: url: ./skeleton values: name: ${{ parameters.name }} - id: publish action: publish:github input: repoUrl: github.com?ownerorgrepo${{ parameters.name }} - id: register action: catalog:register工作流解读parameters门户渲染表单收集name、owner用OwnerPicker选择器对接服务目录实体、language限定go/python/nodejs/java即平台的受支持技术栈白名单。stepsfetch:template用./skeleton骨架生成项目并注入参数 →publish:github创建 GitHub 仓库 →catalog:register把新服务自动注册进服务目录。平台团队只需要维护一个高质量的服务骨架目录skeleton/已含 CI/CD 配置、Dockerfile、健康检查、依赖注入的 Terraform 模块引用等整个新服务的创建流程就被标准化、可审计、可重复。这正是让黄金路径成为最简单路径的落地形式。Service Catalog服务目录与依赖关系建模服务创建之后要在 Backstage 目录中登记。原文档给出了典型的catalog-info.yaml# catalog-info.yaml apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: payment-service annotations: github.com/project-slug: org/payment-service pagerduty.com/integration-key: abc123 grafana/dashboard-selector: servicepayment spec: type: service lifecycle: production owner: payments-team system: checkout dependsOn: - resource:default/payment-db - component:default/auth-service providesApis: - payment-api建模要点annotations是 Backstage 的插件挂载点github.com/project-slug关联代码仓库pagerduty.com/integration-key关联告警与值班grafana/dashboard-selector关联监控面板。这意味着开发者门户直接变成点开服务 → 看到代码、告警、监控的单一入口。spec.dependsOn/providesApis表达服务间依赖图payment-service依赖payment-dbresource和auth-servicecomponent并对外提供payment-api。有了这张图平台就可以自动生成架构关系图、做变更影响分析、识别单点依赖。目录实体与 SLO 结合后价值更大——仓库的 slo-sli-management.md 给出了按服务等级设置目标的参考Tier 1 关键服务 99.99%月停机约 4 分 23 秒、Tier 2 重要服务 99.9%约 43 分 28 秒、Tier 3 标准服务 99.5%约 3 小时 37 分。可以在catalog-info.yaml的 annotations 中挂上对应服务的 SLO 实体让门户直接展示每个服务的健康水位。Golden Path 脚手架脚本一条命令创建服务在尚未接入 Backstage 的团队可以先用一个 Bash 脚本实现最小黄金路径。原文档的create-service.sh完整地演示了模板建仓 → 配 CI/CD → 挂基础设施 → 提交推送的端到端流程#!/bin/bash # create-service.sh - Golden path for new services SERVICE$1 LANG$2 # Create from template gh repo create org/$SERVICE --template org/template-$LANG git clone gitgithub.com:org/$SERVICE.git cd $SERVICE # Setup CI/CD cat .github/workflows/ci.yml EOF name: CI/CD on: [push] jobs: pipeline: uses: org/workflows/.github/workflows/standard.ymlv1 with: service_name: $SERVICE EOF # Create infrastructure cat terraform/main.tf EOF module service { source git::https://github.com/org/terraform//service name $SERVICE } EOF git add . git commit -m Golden path init git push echo ✓ Service created! Merge to main to deploy.脚本的核心价值有三点模板即标准org/template-$LANG是平台团队维护的仓库模板语言不同则骨架不同但都内置统一的安全基线、代码规范和初始流水线。复用组织级工作流.github/workflows/ci.yml引用org/workflows/.github/workflows/standard.ymlv1可复用工作流标准流水线的演进只需更新被引用的工作流仓库所有服务自动获得新能力。这与仓库 devops-engineer/SKILL.md 输出模板中GitHub Actions 构建 → 测试 → Trivy 镜像扫描 → 推送 ghcr.io的最小流水线思路一致。基础设施随服务走每个服务目录内置terraform/main.tf引用前面定义的组合模块基础设施变更跟随应用代码评审天然符合基础设施即代码、不可手工变更的约束见 devops-engineer/SKILL.md 的 MUST DO 清单。GitOps 仓库结构代码与集群的单一事实来源黄金路径创建出的服务最终都要流入统一的 GitOps 仓库。原文档给出了一种按应用 / 基础设施 / 平台三维划分的目录布局gitops/ ├── apps/ │ ├── production/ │ │ ├── payment-service/ │ │ └── auth-service/ │ └── staging/ │ └── payment-service/ ├── infrastructure/ │ ├── clusters/ │ │ ├── prod-us-east/ │ │ └── prod-eu-west/ │ └── base/ │ ├── ingress/ │ └── monitoring/ └── platform/ ├── backstage/ ├── argocd/ └── vault/这种布局遵循的环境分离原则与仓库 terraform-iac.md 中的Workspaces / 环境分离实践一致apps/按环境staging、production组织应用清单同一服务的不同环境清单天然隔离infrastructure/描述集群级资源按集群分目录prod-us-east、prod-eu-west共享基线放base/ingress 控制器、监控组件等platform/放平台自身的声明式配置Backstage 的 catalog 与模板、ArgoCD 的应用配置、Vault 的密钥策略。GitOps 的核心承诺是合并即部署。devops-engineerSkill 的约束清单明确要求Kubernetes 必须走 GitOpsArgoCD/Flux因为只有把集群状态收敛到 Git 仓库平台才能获得可审计、可回滚、可复现的部署能力。ArgoCD Application声明式同步与自动恢复落到集群上的部署由 ArgoCD Application 管理。原文档给出了一个生产可用的配置apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: payment-service spec: project: default source: repoURL: https://github.com/org/gitops path: apps/production/payment-service destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true selfHeal: true retry: limit: 5 backoff: duration: 5s maxDuration: 3m关键字段说明source.path直接对应前面 GitOps 布局中的apps/production/payment-service即应用清单在哪个仓库哪个目录。automated.syncPolicyselfHeal: true让集群状态偏离清单时自动纠正对抗漂移prune: true让清单中删除的资源在集群中同步删除需谨慎配合评审流程使用。retry同步失败自动重试limit: 5退避从5s递增到3m减少人工干预。当集群中发生状态漂移时selfHeal就是 GitOps 的核心安全网。配合 kubernetes.md 中 Deployment 的livenessProbe/readinessProbe与resources.requests/limits规范ArgoCD 的自动同步才不会把不健康的配置推进生产。平台度量指标用 PromQL 量化自服务效果平台好不好不能靠感觉要用指标说话。原文档提供了三组核心 Prometheus recording rule# prometheus/platform-metrics.yaml groups: - name: platform rules: # Self-service adoption rate - record: platform:self_service:rate expr: | sum(rate(platform_provision_automated[1h])) / sum(rate(platform_provision_total[1h])) # Provisioning time P95 - record: platform:provision:p95 expr: | histogram_quantile(0.95, rate(platform_provision_duration_bucket[5m])) # Golden path adoption - record: platform:golden_path:adoption expr: | count(service{templategolden-path}) / count(service)三组指标分别回答三个关键问题自服务采用率platform:self_service:rate自动化供给次数占全部供给次数的比例直接对应自服务优先人工操作 10%的目标。供给时长 P95platform:provision:p95platform_provision_duration_bucket是 histogram 指标用histogram_quantile(0.95, ...)求供给耗时 P95。要生成这类指标平台 API 需要在每次供给任务完成时上报耗时——与后文平台 API小节的provision_service任务遥相呼应。黄金路径采用率platform:golden_path:adoption以templategolden-path标签标记用模板创建的服务除以全部服务数量。指标埋点的工程实现可参考 prometheus-metrics.md用Counter记录累计事件platform_provision_total、Histogram记录耗时分布platform_provision_duration_seconds并遵守命名规范_total、_seconds后缀。注意 histogram 的 bucket 设计要覆盖预期分布如[1, 5, 10, 30, 60, 300, 900]秒。自定义 Backstage 插件把指标搬进门户指标有了还要让开发者和管理者看得见。原文档给出了一个极简 Backstage 插件组件把平台健康数据渲染成卡片// plugins/platform-stats/PlatformMetrics.tsx import React from react; import { InfoCard, Progress } from backstage/core-components; export const PlatformMetrics () { const metrics { selfServiceRate: 92, avgProvisionTime: 3.5min, uptime: 99.95%, satisfaction: 4.6 }; return ( InfoCard titlePlatform Health Progress value{metrics.selfServiceRate} labelSelf-Service / pProvision Time: {metrics.avgProvisionTime}/p pUptime: {metrics.uptime}/p pSatisfaction: {metrics.satisfaction}/5/p /InfoCard ); };示例中数据是硬编码的生产实践应把它替换为对 Prometheus/Grafana 或平台 API 的实时查询自服务采用率、平均供给时间、平台可用性平台自身也要有 SLO见 sre-engineer 的 slo-sli-management.md、开发者满意度来自 NPS 或反馈工具。把平台健康仪表盘直接内嵌到开发者每天打开的门户中是推动采纳策略最直观的手段。成本分摊让成本可归因到团队与项目平台必须回答钱花在谁身上。原文档用 Kubecost 的 allocation 配置演示了成本标签策略# kubecost/allocation.yaml apiVersion: v1 kind: ConfigMap metadata: name: cost-allocation data: allocation.json: | { defaultLabels: { team: team, service: app, environment: env }, shareNamespaces: [kube-system], shareCost: weighted }defaultLabels声明成本分摊的三维标签team、service、environment。这就要求前置环节Crossplane 组合、Terraform 模块、K8s 清单必须统一打上这三个标签——再次印证 module-patterns.md 中为所有可打标签的资源打标签的实践也呼应terraform-iac.md中tags { Environment var.environment }的写法。shareNamespacesshareCost: weighted把kube-system这类共享平台组件的成本按权重分摊到各租户避免平台开销无人认领。成本数据最终可以暴露到平台 API如GET /api/v1/services/{name}/cost?periodmtd让每个服务在门户上直接可见月度成本示例中cost_mtd: $142.50推动开发者在做技术选型和扩容决策时把成本纳入考量。平台 API把能力封装成产品接口原文档用 FastAPI 给出了平台自服务 API 的最小实现。这段代码是构建 API 而非仅仅构建工具原则的直接体现# Platform API for self-service provisioning from fastapi import FastAPI, Depends from pydantic import BaseModel app FastAPI() class ServiceRequest(BaseModel): name: str environment: str language: str database: bool False app.post(/api/v1/services) async def create_service(request: ServiceRequest): # Validate and enqueue task platform.provision_service( namerequest.name, envrequest.environment, templatefgolden-path-{request.language} ) return {task_id: task.id, status: provisioning} app.get(/api/v1/services/{name}/status) async def service_status(name: str): return { status: running, url: fhttps://{name}.example.com, health: healthy, cost_mtd: $142.50 }设计要点异步供给POST /services只负责校验和入队platform.provision_service返回task_id立即返回provisioning状态由后台任务如 Argo Workflows、Temporal异步完成避免同步长任务阻塞客户端。这也为前面platform_provision_duration_bucket指标提供了上报点。请求模型即契约ServiceRequest用 Pydantic 声明name/environment/language/database非法输入在入口被自动拒绝language应对应黄金路径模板golden-path-{language}与 Backstage 模板中的语言白名单保持同源。状态与成本接口GET /status把运行状态、访问地址、健康度和月度成本聚合到一个端点前端门户插件、CLI只需消费这一个接口。仓库中fastapi-expert与api-designer等 Skill 可作为该 API 的设计补充但核心思想不变平台以 API 为产品界面门户、CLI、CI/CD 都是同一接口的不同消费者。原文档 platform-engineering.md 后文的 CLI 示例正是这条 API 的第二个客户端。多租户架构配额与权限的硬隔离自服务不等于无约束。原文档用一对 Kubernetes 资源展示了租户级隔离ResourceQuota限制资源上限RoleBinding授予租户在自属命名空间的管理权限。# Policy: Resource quotas per tenant apiVersion: v1 kind: ResourceQuota metadata: name: team-quota namespace: team-payments spec: hard: requests.cpu: 20 requests.memory: 40Gi persistentvolumeclaims: 10 services.loadbalancers: 2 --- # RBAC: Namespace admin apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: team-admin namespace: team-payments roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: namespace-admin subjects: - kind: Group name: team-paymentsResourceQuota是平台防滥用边界CPU、内存、PVC 数量、LoadBalancer 数量都设硬上限防止某个团队耗尽集群资源拖垮全局namespace-admin这个 ClusterRole 通过RoleBinding限定在team-payments命名空间内生效团队在其命名空间内拥有自治权但碰不到其他命名空间。这种平台集中治理边界 团队自治工作区的组合是 IDP 安全模型的支柱Quota 与 RBAC 模板化后新团队入驻只需创建一组命名空间清单与前面 Crossplane/Terraform 的模板化供给理念完全一致。采纳策略与目标追踪平台工程是持续运营不是一次交付。原文档给出了量化的目标追踪配置# Platform metrics tracking apiVersion: v1 kind: ConfigMap metadata: name: platform-goals data: goals.yaml: | q1_2024: self_service_rate: 90% avg_provision_time: 5min developer_satisfaction: 4.5/5 golden_path_adoption: 80% tracking: weekly_provisioning: true team_feedback: true support_tickets: true training_completion: true解读季度目标把原则量化自服务率 90%、平均供给 5 分钟、开发者满意度 4.5/5、黄金路径采用率 80%。这些数字直接对应用户前面 platform-engineering.md 中Platform Metrics小节的 PromQL——目标值与实际值必须能一一对照。tracking声明了追踪手段每周供给统计、团队反馈收集、支持工单数量、培训完成度。这是平台即产品的运营节奏每周看数据、收集反馈、处理工单、推动培训。配套的运营要求原文档 Best Practices 一节还包括持续度量开发者满意度、每周追踪采纳指标、以产品团队方式运营平台、投资开发者布道developer evangelism、为平台自身维护 SLO、提供快速的支持响应。自服务 CLI把平台 API 交给终端门户之外CLI 是开发者的第二个入口。原文档用一个 Bash 函数封装了平台 API 的常用操作#!/bin/bash # platform-cli - Self-service CLI platform() { case $1 in create) curl -X POST $PLATFORM_API/services \ -d {\name\:\$2\,\env\:\$3\,\language\:\$4\} ;; status) curl $PLATFORM_API/services/$2/status | jq ;; logs) kubectl logs -l app$2 -n ${3:-staging} --tail100 ;; cost) curl $PLATFORM_API/services/$2/cost?periodmtd ;; esac }create调用平台 API 的POST /services与上一节 FastAPI 接口一一对应status/cost分别是状态与成本查询的薄封装jq格式化输出logs直接落到 Kubernetes默认命名空间为staging可指定环境。CLI 的价值在于把自服务延伸到非门户场景CI 流水线、脚本、本地开发环境都可以platform create。真正的产品化应进一步补充参数校验、错误处理、命令帮助、--json输出等但核心模式不变——CLI 只是平台 API 的客户端所有逻辑收敛在 API 层避免平台能力散落在各处脚本里。平台工程最佳实践清单综合原文档 platform-engineering.md 的 Best Practices 一节以及仓库中 devops-engineer / terraform-engineer / monitoring-expert 等 Skill 的约束一份可执行的实践清单如下实践落地要点相关参考第一天就设计自服务所有资源供给走模板化 API/CRD杜绝手工操作platform-engineering.md让黄金路径成为最容易的选项模板内置安全基线、CI/CD、IaC比自建更省事本文 Backstage / 脚手架小节持续度量开发者满意度NPS、反馈工具、SLO 追踪纳入每周运营slo-sli-management.md自动化平台运维GitOps 同步、自愈、自动重试kubernetes.md提供优秀的文档每个模块有 README 与示例模板有使用说明module-patterns.md构建 API 而非工具门户、CLI、CI 统一消费平台 API本文平台 API小节支持安全实验沙箱命名空间 Quota实验环境可随时销毁本文多租户小节维护向后兼容模块/模板语义化版本管理~ 1.x约束module-patterns.md平台即产品路线图、版本演进、用户反馈闭环platform-engineering.md每周追踪采纳指标PromQL 记录自服务率、供给 P95、黄金路径采用率本文平台指标小节为平台维护 SLO平台自身可用性目标用错误预算驱动投入slo-sli-management.md快速帮助与布道支持渠道 开发者布道 培训本文采纳策略小节部署纪律提醒devops-engineerSkill 要求任何生产或面向客户的变更必须先给出部署摘要与回滚方案并获得显式批准见 devops-engineer/SKILL.md 的核心工作流。平台的模板、模块与 GitOps 清单同样适用这一约束用terraform plan、kubectl diff、ArgoCD 预演等确认无破坏性变更后再合入。总结本文以 claude-skills 中devops-engineerSkill 的 platform-engineering.md 为主线串联了从原则到落地的完整平台工程链路Crossplane 与 Terraform 提供自服务供给Backstage 模板与服务目录承载黄金路径与依赖建模GitOps ArgoCD 保证声明式交付与自愈Prometheus 指标与 Backstage 插件量化平台健康与采纳度平台 API 与 CLI 把能力产品化Quota RBAC 守住多租户边界。所有这些环节仓库内都有对应参考文档可随时加载——当你用 Claude Code 触发devops-engineerSkill 时它会在平台工程场景下自动加载本文所依据的参考文档并依据其约束清单见 devops-engineer/SKILL.md输出生产级的平台配置。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平台工程实战指南基于 claude-skills 的 devops-engineer Skill 构建内部开发者平台【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills平台工程Platform Engineering的目标是把基础设施交付从人工审批工单转变为开发者在几分钟内自助完成。claude-skills 仓库中的devops-engineerSkill 内置了 10 余份领域参考文档其中 platform-engineering.md 正是面向内部开发者平台IDP的实战手册覆盖 Crossplane 自服务组合、Terraform 模块化、Backstage 模板与服务目录、GitOps 仓库布局、ArgoCD 部署、平台指标、多租户隔离与采纳策略。读完本文你将掌握从零搭建一条开发者在门户上点几下即可获得生产级服务的完整技术链路并能直接用 devops-engineer Skill 快速产出可落地的平台配置。平台工程四大核心原则在动手写任何 YAML 之前先建立平台的顶层设计原则。devops-engineerSkill 在触发自服务基础设施、开发者门户、黄金路径golden paths、Backstage等场景时会加载 platform-engineering.md其开篇即给出四条原则自服务优先Self-service first将人工操作降到 10% 以下。衡量标准是开发者无需找平台团队提工单即可完成日常基础设施操作的比例。黄金路径Golden paths提供预先批准、有明确意见的模板让按规范走成为阻力最小的路径而不是靠文档和培训强制约束。开发者体验Developer experience持续度量并优化开发者的生产效率把平台对开发者的摩擦力当作一等公民指标。平台即产品Platform as product用产品思维运营平台有用户、有路线图、有反馈闭环、有版本演进而不是把它当作一次性交付的工程项目。这四条原则贯穿本文后续所有小节Crossplane 负责自服务Backstage 模板承载黄金路径平台指标回答开发者体验而采纳策略则落实平台即产品。自服务基础设施Crossplane Composition实现自服务的第一个技术栈是 Crossplane。它的思路是把云资源RDS、S3、VPC 等封装为集群内的自定义资源CRD应用开发者只需提交一个Database对象控制平面就负责创建底层云资源。核心编排对象是Composition——它定义了用户申请一个Database时底层实际要创建什么# Composition for self-service database apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: postgres-database spec: compositeTypeRef: apiVersion: platform.example.com/v1alpha1 kind: Database resources: - name: rds-instance base: apiVersion: rds.aws.crossplane.io/v1alpha1 kind: DBInstance spec: forProvider: dbInstanceClass: db.t3.micro engine: postgres engineVersion: 15 masterUsername: admin allocatedStorage: 20要点拆解compositeTypeRef声明了对外暴露的复合资源类型XRD——这里是platform.example.com/v1alpha1的Database。开发者永远不会直接看到DBInstance只面对这个简化后的抽象。resources是实际资源模板本例为 AWS RDS 的DBInstancedb.t3.micro、PostgreSQL 15、20GB 存储。一旦开发者kubectl apply一个Database对象Crossplane 就会渲染这个模板并调用 AWS Provider 完成实例创建——这就是自助申请数据库的最小闭环。与仓库内 terraform-iac.md 中的 RDS 配置对照可以看到同样的生产要素storage_encrypted true、backup_retention_period 7、skip_final_snapshot false。建议在 Composition 模板中同样补上存储加密、备份保留、monitoring_interval等字段把平台的安全基线固化在模板层而不是依赖开发者自觉。用 Terraform 模块封装自服务能力在非 Kubernetes 的交付路径上Terraform 模块是自服务的另一种主流实现。原文档给出了一个一个服务 部署 数据库 监控的组合模块骨架# modules/service/main.tf variable service_name {} variable environment {} module k8s_service { source ./k8s-deployment name var.service_name env var.environment } module database { source ./postgres name ${var.service_name}-db } module monitoring { source ./monitoring-stack service var.service_name } output service_url { value module.k8s_service.url }这个模式的价值在于组合与标准化平台团队把k8s-deployment、postgres、monitoring-stack三个子模块维护到生产级服务团队只需要声明service_name和environment两个变量即可获得完整栈。输出service_url供上层如 Backstage直接消费。仓库中的 module-patterns.md 对模块工程化给出了更细的规范与本例配合使用标准目录结构main.tf、variables.tf、outputs.tf、versions.tf声明 provider 版本约束、examples/完整可用示例、tests/Terratest 等。输入校验每个变量用validationblock 校验例如名称长度 1~32、CIDR 必须是合法网段把错误在terraform plan阶段就拦截掉。版本管理组合模块通过source git::https://github.com/org/terraform//servicerefv1.2.3或version ~ 19.0锁版本见 module-patterns.md 的 Module Versioning 小节保证开发者拿到的是经过验证的模块版本。for_each优先于count便于按 key 管理多个资源实例。一致命名与打标签所有可打标签的资源打统一标签为后面的成本分摊Cost Allocation打基础。terraform-engineerSkill见 SKILL.md本身也强调远程状态 DynamoDB 锁、terraform fmt/terraform validate/tflint校验、terraform plan -outtfplan人工批准后再 apply。自服务模块同样要继承这套质量门槛——模块发布前必须通过全部校验而不是把未经验证的模块直接开放给开发者。Backstage 服务模板把黄金路径变成门户操作自服务门户Developer Portal最流行的落地产品是 Backstage其 Scaffolder 用 Template 定义新建一个服务的向导流程。原文档给出了一个微服务黄金路径模板# templates/microservice/template.yaml apiVersion: scaffolder.backstage.io/v1beta3 kind: Template metadata: name: microservice-template title: Microservice Golden Path spec: owner: platform-team type: service parameters: - title: Service Info properties: name: type: string owner: type: string ui:field: OwnerPicker language: type: string enum: [go, python, nodejs, java] steps: - id: fetch action: fetch:template input: url: ./skeleton values: name: ${{ parameters.name }} - id: publish action: publish:github input: repoUrl: github.com?ownerorgrepo${{ parameters.name }} - id: register action: catalog:register工作流解读parameters门户渲染表单收集name、owner用OwnerPicker选择器对接服务目录实体、language限定go/python/nodejs/java即平台的受支持技术栈白名单。stepsfetch:template用./skeleton骨架生成项目并注入参数 →publish:github创建 GitHub 仓库 →catalog:register把新服务自动注册进服务目录。平台团队只需要维护一个高质量的服务骨架目录skeleton/已含 CI/CD 配置、Dockerfile、健康检查、依赖注入的 Terraform 模块引用等整个新服务的创建流程就被标准化、可审计、可重复。这正是让黄金路径成为最简单路径的落地形式。Service Catalog服务目录与依赖关系建模服务创建之后要在 Backstage 目录中登记。原文档给出了典型的catalog-info.yaml# catalog-info.yaml apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: payment-service annotations: github.com/project-slug: org/payment-service pagerduty.com/integration-key: abc123 grafana/dashboard-selector: servicepayment spec: type: service lifecycle: production owner: payments-team system: checkout dependsOn: - resource:default/payment-db - component:default/auth-service providesApis: - payment-api建模要点annotations是 Backstage 的插件挂载点github.com/project-slug关联代码仓库pagerduty.com/integration-key关联告警与值班grafana/dashboard-selector关联监控面板。这意味着开发者门户直接变成点开服务 → 看到代码、告警、监控的单一入口。spec.dependsOn/providesApis表达服务间依赖图payment-service依赖payment-dbresource和auth-servicecomponent并对外提供payment-api。有了这张图平台就可以自动生成架构关系图、做变更影响分析、识别单点依赖。目录实体与 SLO 结合后价值更大——仓库的 slo-sli-management.md 给出了按服务等级设置目标的参考Tier 1 关键服务 99.99%月停机约 4 分 23 秒、Tier 2 重要服务 99.9%约 43 分 28 秒、Tier 3 标准服务 99.5%约 3 小时 37 分。可以在catalog-info.yaml的 annotations 中挂上对应服务的 SLO 实体让门户直接展示每个服务的健康水位。Golden Path 脚手架脚本一条命令创建服务在尚未接入 Backstage 的团队可以先用一个 Bash 脚本实现最小黄金路径。原文档的create-service.sh完整地演示了模板建仓 → 配 CI/CD → 挂基础设施 → 提交推送的端到端流程#!/bin/bash # create-service.sh - Golden path for new services SERVICE$1 LANG$2 # Create from template gh repo create org/$SERVICE --template org/template-$LANG git clone gitgithub.com:org/$SERVICE.git cd $SERVICE # Setup CI/CD cat .github/workflows/ci.yml EOF name: CI/CD on: [push] jobs: pipeline: uses: org/workflows/.github/workflows/standard.ymlv1 with: service_name: $SERVICE EOF # Create infrastructure cat terraform/main.tf EOF module service { source git::https://github.com/org/terraform//service name $SERVICE } EOF git add . git commit -m Golden path init git push echo ✓ Service created! Merge to main to deploy.脚本的核心价值有三点模板即标准org/template-$LANG是平台团队维护的仓库模板语言不同则骨架不同但都内置统一的安全基线、代码规范和初始流水线。复用组织级工作流.github/workflows/ci.yml引用org/workflows/.github/workflows/standard.ymlv1可复用工作流标准流水线的演进只需更新被引用的工作流仓库所有服务自动获得新能力。这与仓库 devops-engineer/SKILL.md 输出模板中GitHub Actions 构建 → 测试 → Trivy 镜像扫描 → 推送 ghcr.io的最小流水线思路一致。基础设施随服务走每个服务目录内置terraform/main.tf引用前面定义的组合模块基础设施变更跟随应用代码评审天然符合基础设施即代码、不可手工变更的约束见 devops-engineer/SKILL.md 的 MUST DO 清单。GitOps 仓库结构代码与集群的单一事实来源黄金路径创建出的服务最终都要流入统一的 GitOps 仓库。原文档给出了一种按应用 / 基础设施 / 平台三维划分的目录布局gitops/ ├── apps/ │ ├── production/ │ │ ├── payment-service/ │ │ └── auth-service/ │ └── staging/ │ └── payment-service/ ├── infrastructure/ │ ├── clusters/ │ │ ├── prod-us-east/ │ │ └── prod-eu-west/ │ └── base/ │ ├── ingress/ │ └── monitoring/ └── platform/ ├── backstage/ ├── argocd/ └── vault/这种布局遵循的环境分离原则与仓库 terraform-iac.md 中的Workspaces / 环境分离实践一致apps/按环境staging、production组织应用清单同一服务的不同环境清单天然隔离infrastructure/描述集群级资源按集群分目录prod-us-east、prod-eu-west共享基线放base/ingress 控制器、监控组件等platform/放平台自身的声明式配置Backstage 的 catalog 与模板、ArgoCD 的应用配置、Vault 的密钥策略。GitOps 的核心承诺是合并即部署。devops-engineerSkill 的约束清单明确要求Kubernetes 必须走 GitOpsArgoCD/Flux因为只有把集群状态收敛到 Git 仓库平台才能获得可审计、可回滚、可复现的部署能力。ArgoCD Application声明式同步与自动恢复落到集群上的部署由 ArgoCD Application 管理。原文档给出了一个生产可用的配置apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: payment-service spec: project: default source: repoURL: https://github.com/org/gitops path: apps/production/payment-service destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true selfHeal: true retry: limit: 5 backoff: duration: 5s maxDuration: 3m关键字段说明source.path直接对应前面 GitOps 布局中的apps/production/payment-service即应用清单在哪个仓库哪个目录。automated.syncPolicyselfHeal: true让集群状态偏离清单时自动纠正对抗漂移prune: true让清单中删除的资源在集群中同步删除需谨慎配合评审流程使用。retry同步失败自动重试limit: 5退避从5s递增到3m减少人工干预。当集群中发生状态漂移时selfHeal就是 GitOps 的核心安全网。配合 kubernetes.md 中 Deployment 的livenessProbe/readinessProbe与resources.requests/limits规范ArgoCD 的自动同步才不会把不健康的配置推进生产。平台度量指标用 PromQL 量化自服务效果平台好不好不能靠感觉要用指标说话。原文档提供了三组核心 Prometheus recording rule# prometheus/platform-metrics.yaml groups: - name: platform rules: # Self-service adoption rate - record: platform:self_service:rate expr: | sum(rate(platform_provision_automated[1h])) / sum(rate(platform_provision_total[1h])) # Provisioning time P95 - record: platform:provision:p95 expr: | histogram_quantile(0.95, rate(platform_provision_duration_bucket[5m])) # Golden path adoption - record: platform:golden_path:adoption expr: | count(service{templategolden-path}) / count(service)三组指标分别回答三个关键问题自服务采用率platform:self_service:rate自动化供给次数占全部供给次数的比例直接对应自服务优先人工操作 10%的目标。供给时长 P95platform:provision:p95platform_provision_duration_bucket是 histogram 指标用histogram_quantile(0.95, ...)求供给耗时 P95。要生成这类指标平台 API 需要在每次供给任务完成时上报耗时——与后文平台 API小节的provision_service任务遥相呼应。黄金路径采用率platform:golden_path:adoption以templategolden-path标签标记用模板创建的服务除以全部服务数量。指标埋点的工程实现可参考 prometheus-metrics.md用Counter记录累计事件platform_provision_total、Histogram记录耗时分布platform_provision_duration_seconds并遵守命名规范_total、_seconds后缀。注意 histogram 的 bucket 设计要覆盖预期分布如[1, 5, 10, 30, 60, 300, 900]秒。自定义 Backstage 插件把指标搬进门户指标有了还要让开发者和管理者看得见。原文档给出了一个极简 Backstage 插件组件把平台健康数据渲染成卡片// plugins/platform-stats/PlatformMetrics.tsx import React from react; import { InfoCard, Progress } from backstage/core-components; export const PlatformMetrics () { const metrics { selfServiceRate: 92, avgProvisionTime: 3.5min, uptime: 99.95%, satisfaction: 4.6 }; return ( InfoCard titlePlatform Health Progress value{metrics.selfServiceRate} labelSelf-Service / pProvision Time: {metrics.avgProvisionTime}/p pUptime: {metrics.uptime}/p pSatisfaction: {metrics.satisfaction}/5/p /InfoCard ); };示例中数据是硬编码的生产实践应把它替换为对 Prometheus/Grafana 或平台 API 的实时查询自服务采用率、平均供给时间、平台可用性平台自身也要有 SLO见 sre-engineer 的 slo-sli-management.md、开发者满意度来自 NPS 或反馈工具。把平台健康仪表盘直接内嵌到开发者每天打开的门户中是推动采纳策略最直观的手段。成本分摊让成本可归因到团队与项目平台必须回答钱花在谁身上。原文档用 Kubecost 的 allocation 配置演示了成本标签策略# kubecost/allocation.yaml apiVersion: v1 kind: ConfigMap metadata: name: cost-allocation data: allocation.json: | { defaultLabels: { team: team, service: app, environment: env }, shareNamespaces: [kube-system], shareCost: weighted }defaultLabels声明成本分摊的三维标签team、service、environment。这就要求前置环节Crossplane 组合、Terraform 模块、K8s 清单必须统一打上这三个标签——再次印证 module-patterns.md 中为所有可打标签的资源打标签的实践也呼应terraform-iac.md中tags { Environment var.environment }的写法。shareNamespacesshareCost: weighted把kube-system这类共享平台组件的成本按权重分摊到各租户避免平台开销无人认领。成本数据最终可以暴露到平台 API如GET /api/v1/services/{name}/cost?periodmtd让每个服务在门户上直接可见月度成本示例中cost_mtd: $142.50推动开发者在做技术选型和扩容决策时把成本纳入考量。平台 API把能力封装成产品接口原文档用 FastAPI 给出了平台自服务 API 的最小实现。这段代码是构建 API 而非仅仅构建工具原则的直接体现# Platform API for self-service provisioning from fastapi import FastAPI, Depends from pydantic import BaseModel app FastAPI() class ServiceRequest(BaseModel): name: str environment: str language: str database: bool False app.post(/api/v1/services) async def create_service(request: ServiceRequest): # Validate and enqueue task platform.provision_service( namerequest.name, envrequest.environment, templatefgolden-path-{request.language} ) return {task_id: task.id, status: provisioning} app.get(/api/v1/services/{name}/status) async def service_status(name: str): return { status: running, url: fhttps://{name}.example.com, health: healthy, cost_mtd: $142.50 }设计要点异步供给POST /services只负责校验和入队platform.provision_service返回task_id立即返回provisioning状态由后台任务如 Argo Workflows、Temporal异步完成避免同步长任务阻塞客户端。这也为前面platform_provision_duration_bucket指标提供了上报点。请求模型即契约ServiceRequest用 Pydantic 声明name/environment/language/database非法输入在入口被自动拒绝language应对应黄金路径模板golden-path-{language}与 Backstage 模板中的语言白名单保持同源。状态与成本接口GET /status把运行状态、访问地址、健康度和月度成本聚合到一个端点前端门户插件、CLI只需消费这一个接口。仓库中fastapi-expert与api-designer等 Skill 可作为该 API 的设计补充但核心思想不变平台以 API 为产品界面门户、CLI、CI/CD 都是同一接口的不同消费者。原文档 platform-engineering.md 后文的 CLI 示例正是这条 API 的第二个客户端。多租户架构配额与权限的硬隔离自服务不等于无约束。原文档用一对 Kubernetes 资源展示了租户级隔离ResourceQuota限制资源上限RoleBinding授予租户在自属命名空间的管理权限。# Policy: Resource quotas per tenant apiVersion: v1 kind: ResourceQuota metadata: name: team-quota namespace: team-payments spec: hard: requests.cpu: 20 requests.memory: 40Gi persistentvolumeclaims: 10 services.loadbalancers: 2 --- # RBAC: Namespace admin apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: team-admin namespace: team-payments roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: namespace-admin subjects: - kind: Group name: team-paymentsResourceQuota是平台防滥用边界CPU、内存、PVC 数量、LoadBalancer 数量都设硬上限防止某个团队耗尽集群资源拖垮全局namespace-admin这个 ClusterRole 通过RoleBinding限定在team-payments命名空间内生效团队在其命名空间内拥有自治权但碰不到其他命名空间。这种平台集中治理边界 团队自治工作区的组合是 IDP 安全模型的支柱Quota 与 RBAC 模板化后新团队入驻只需创建一组命名空间清单与前面 Crossplane/Terraform 的模板化供给理念完全一致。采纳策略与目标追踪平台工程是持续运营不是一次交付。原文档给出了量化的目标追踪配置# Platform metrics tracking apiVersion: v1 kind: ConfigMap metadata: name: platform-goals data: goals.yaml: | q1_2024: self_service_rate: 90% avg_provision_time: 5min developer_satisfaction: 4.5/5 golden_path_adoption: 80% tracking: weekly_provisioning: true team_feedback: true support_tickets: true training_completion: true解读季度目标把原则量化自服务率 90%、平均供给 5 分钟、开发者满意度 4.5/5、黄金路径采用率 80%。这些数字直接对应用户前面 platform-engineering.md 中Platform Metrics小节的 PromQL——目标值与实际值必须能一一对照。tracking声明了追踪手段每周供给统计、团队反馈收集、支持工单数量、培训完成度。这是平台即产品的运营节奏每周看数据、收集反馈、处理工单、推动培训。配套的运营要求原文档 Best Practices 一节还包括持续度量开发者满意度、每周追踪采纳指标、以产品团队方式运营平台、投资开发者布道developer evangelism、为平台自身维护 SLO、提供快速的支持响应。自服务 CLI把平台 API 交给终端门户之外CLI 是开发者的第二个入口。原文档用一个 Bash 函数封装了平台 API 的常用操作#!/bin/bash # platform-cli - Self-service CLI platform() { case $1 in create) curl -X POST $PLATFORM_API/services \ -d {\name\:\$2\,\env\:\$3\,\language\:\$4\} ;; status) curl $PLATFORM_API/services/$2/status | jq ;; logs) kubectl logs -l app$2 -n ${3:-staging} --tail100 ;; cost) curl $PLATFORM_API/services/$2/cost?periodmtd ;; esac }create调用平台 API 的POST /services与上一节 FastAPI 接口一一对应status/cost分别是状态与成本查询的薄封装jq格式化输出logs直接落到 Kubernetes默认命名空间为staging可指定环境。CLI 的价值在于把自服务延伸到非门户场景CI 流水线、脚本、本地开发环境都可以platform create。真正的产品化应进一步补充参数校验、错误处理、命令帮助、--json输出等但核心模式不变——CLI 只是平台 API 的客户端所有逻辑收敛在 API 层避免平台能力散落在各处脚本里。平台工程最佳实践清单综合原文档 platform-engineering.md 的 Best Practices 一节以及仓库中 devops-engineer / terraform-engineer / monitoring-expert 等 Skill 的约束一份可执行的实践清单如下实践落地要点相关参考第一天就设计自服务所有资源供给走模板化 API/CRD杜绝手工操作platform-engineering.md让黄金路径成为最容易的选项模板内置安全基线、CI/CD、IaC比自建更省事本文 Backstage / 脚手架小节持续度量开发者满意度NPS、反馈工具、SLO 追踪纳入每周运营slo-sli-management.md自动化平台运维GitOps 同步、自愈、自动重试kubernetes.md提供优秀的文档每个模块有 README 与示例模板有使用说明module-patterns.md构建 API 而非工具门户、CLI、CI 统一消费平台 API本文平台 API小节支持安全实验沙箱命名空间 Quota实验环境可随时销毁本文多租户小节维护向后兼容模块/模板语义化版本管理~ 1.x约束module-patterns.md平台即产品路线图、版本演进、用户反馈闭环platform-engineering.md每周追踪采纳指标PromQL 记录自服务率、供给 P95、黄金路径采用率本文平台指标小节为平台维护 SLO平台自身可用性目标用错误预算驱动投入slo-sli-management.md快速帮助与布道支持渠道 开发者布道 培训本文采纳策略小节部署纪律提醒devops-engineerSkill 要求任何生产或面向客户的变更必须先给出部署摘要与回滚方案并获得显式批准见 devops-engineer/SKILL.md 的核心工作流。平台的模板、模块与 GitOps 清单同样适用这一约束用terraform plan、kubectl diff、ArgoCD 预演等确认无破坏性变更后再合入。总结本文以 claude-skills 中devops-engineerSkill 的 platform-engineering.md 为主线串联了从原则到落地的完整平台工程链路Crossplane 与 Terraform 提供自服务供给Backstage 模板与服务目录承载黄金路径与依赖建模GitOps ArgoCD 保证声明式交付与自愈Prometheus 指标与 Backstage 插件量化平台健康与采纳度平台 API 与 CLI 把能力产品化Quota RBAC 守住多租户边界。所有这些环节仓库内都有对应参考文档可随时加载——当你用 Claude Code 触发devops-engineerSkill 时它会在平台工程场景下自动加载本文所依据的参考文档并依据其约束清单见 devops-engineer/SKILL.md输出生产级的平台配置。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
