spinny:~/writing $ less platform-engineering-internal-developer-platform.md
12随着软件系统变得越来越复杂 - - 微服务、Kubernetes、多云、CI/CD 流水线、可观测性技术栈 - - 开发者花在基础设施上的时间越来越多,而用于构建产品的时间越来越少。**Platform Engineering** 通过创建一个抽象复杂性的内部平台,为开发者提供自助服务工具,从而加速交付来解决这个问题。34Gartner 预测,到 2027 年,**80% 的软件工程组织**将建立平台团队。在本指南中,我们将探讨什么是 Platform Engineering、为什么它很重要,以及如何从零开始构建 Internal Developer Platform。56## 什么是 Platform Engineering?78Platform Engineering 是一门设计和构建工具链与工作流的学科,为软件工程组织提供自助服务能力。其产出是一个 **Internal Developer Platform (IDP)** - - 位于开发者和基础设施之间的一个抽象层。910```mermaid11graph TD12 subgraph "Developers"13 D1[Frontend Team]14 D2[Backend Team]15 D3[Data Team]16 end1718 subgraph "Internal Developer Platform"19 Portal[Developer Portal]20 Templates[Service Templates]21 CICD[CI/CD Pipelines]22 Infra[Infrastructure Abstraction]23 end2425 subgraph "Infrastructure"26 K8s[Kubernetes]27 Cloud[Cloud Services]28 DB[Databases]29 Monitor[Monitoring]30 end3132 D1 --> Portal33 D2 --> Portal34 D3 --> Portal35 Portal --> Templates36 Portal --> CICD37 Portal --> Infra38 Infra --> K8s39 Infra --> Cloud40 Infra --> DB41 CICD --> Monitor42```4344### Platform Engineering 与 DevOps4546Platform Engineering 不是 DevOps 的替代品 - - 它是下一次演进。DevOps 说"你构建它,你运维它"。Platform Engineering 说"我们会让构建和运维变得毫不费力"。4748| 方面 | DevOps | Platform Engineering |49|------|--------|---------------------|50| **关注点** | 文化和实践 | 产品和自助服务 |51| **方法** | 每个团队管理基础设施 | 平台团队抽象基础设施 |52| **认知负荷** | 高(每个团队都要学习所有内容) | 低(提供黄金路径) |53| **产出** | CI/CD 流水线、IaC 脚本 | Internal Developer Platform |54| **用户** | 所有工程团队 | 平台团队服务工程团队 |5556## 为什么 Platform Engineering 很重要5758### 认知负荷问题5960在一个典型的现代组织中,开发者需要理解:6162- Git 工作流和分支策略63- CI/CD 流水线配置64- 容器构建和镜像仓库管理65- Kubernetes 清单和 Helm Charts66- 云服务商服务(AWS/GCP/Azure)67- 网络、DNS、TLS 证书68- 监控、日志和告警配置69- 数据库配置和迁移70- 安全策略和合规性7172这是一个巨大的认知负担,分散了对实际产品的注意力。7374### 黄金路径7576Platform Engineering 引入了**黄金路径**的概念 - - 为常见任务提供的有主见的、支持良好且有文档记录的路径。黄金路径不是强制要求;开发者*可以*偏离,但平台让正确的做法变成最简单的做法。7778```mermaid79flowchart LR80 Dev[Developer] -- "Create new service" --> Portal[Portal]81 Portal -- "Select template" --> Template[Service Template]82 Template -- "Auto-provision" --> Repo[Git Repository]83 Template --> Pipeline[CI/CD Pipeline]84 Template --> Infra[Kubernetes Namespace]85 Template --> Monitor[Dashboards + Alerts]86 Repo --> Ready[Ready to Code!]87```8889**创建新微服务的黄金路径示例:**901. 开发者在门户中选择"新建后端服务"912. 选择语言/框架(Node.js、Go、Python)923. 平台自动创建:Git 仓库、CI/CD 流水线、Kubernetes 命名空间、监控仪表板和告警规则934. 开发者克隆仓库,立即开始编码9495## 构建 Internal Developer Platform9697### 第一层:开发者门户9899门户是开发者的唯一入口。最流行的开源选择是 **Backstage**(由 Spotify 创建,现为 CNCF 项目)。100101核心功能:102- **服务目录**:每个服务、其所有者、文档和依赖关系103- **软件模板**:内置最佳实践的新服务脚手架104- **技术文档**:文档即代码,可渲染和搜索105- **插件生态系统**:通过自定义功能进行扩展106107```yaml108# backstage/catalog-info.yaml109apiVersion: backstage.io/v1alpha1110kind: Component111metadata:112 name: user-service113 description: Manages user accounts and authentication114 annotations:115 github.com/project-slug: myorg/user-service116 backstage.io/techdocs-ref: dir:.117spec:118 type: service119 lifecycle: production120 owner: team-auth121 system: identity-platform122 dependsOn:123 - resource:postgresql-main124 providesApis:125 - user-api126```127128### 第二层:基础设施抽象129130开发者不应该直接编写 Terraform 或 Kubernetes YAML。平台应该提供抽象层。131132**工具:**133- **Crossplane**:Kubernetes 原生基础设施配置134- **Terraform 模块**:预构建、经过测试的基础设施模块135- **Pulumi**:基础设施即真正的代码(TypeScript、Python、Go)136137```yaml138# Example: Crossplane composition for a database139apiVersion: database.example.com/v1140kind: PostgreSQLInstance141metadata:142 name: user-db143spec:144 size: small # Abstraction: small = 2 vCPU, 4GB RAM145 version: "16"146 backup: daily147 team: auth-team148```149150开发者不需要配置 RDS 参数、VPC 子网、安全组和备份策略,只需指定 `size: small` 和 `backup: daily`。平台处理其余一切。151152### 第三层:CI/CD 标准化153154标准化 CI/CD,这样团队就不需要各自构建自己的流水线。155156```yaml157# .github/workflows/platform-ci.yml158# Teams just include the shared workflow159name: Build and Deploy160on:161 push:162 branches: [main]163164jobs:165 pipeline:166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2167 with:168 language: node169 deploy-target: production170 secrets: inherit171```172173**关键实践:**174- 团队引用(而非复制)的共享 CI/CD 模板175- 自动安全扫描(SAST、依赖审计)176- 标准化部署策略(金丝雀发布、蓝绿部署)177- 健康检查失败时自动回滚178179### 第四层:可观测性180181预配置的监控,让开发者开箱即获得仪表板和告警。182183- **指标**:Prometheus + Grafana,每个服务提供标准仪表板184- **日志**:结构化日志与集中收集(Loki、ELK)185- **链路追踪**:使用 OpenTelemetry 的分布式追踪186- **告警**:PagerDuty/Opsgenie 集成,提供合理的默认配置187188```mermaid189graph LR190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]191 Collector --> Prometheus[Prometheus]192 Collector --> Loki[Loki]193 Collector --> Tempo[Tempo]194 Prometheus --> Grafana[Grafana Dashboards]195 Loki --> Grafana196 Tempo --> Grafana197 Grafana --> PagerDuty[PagerDuty Alerts]198```199200## 衡量成功201202你怎么知道你的平台在发挥作用?追踪以下指标:203204### DORA 指标205- **部署频率**:代码多久到达生产环境一次206- **变更前置时间**:从提交到生产环境的时间207- **变更失败率**:导致故障的部署百分比208- **平均恢复时间**:事件发生后恢复服务的时间209210### 平台特定指标211- **首次部署时间**:从"新服务"到首次生产部署需要多长时间212- **开发者满意度(NPS)**:定期调查你的用户213- **自助服务比例**:无需工单处理的基础设施请求百分比214- **黄金路径采用率**:遵循推荐路径的服务百分比215216## 常见错误217218### 1. 过早构建过多219从最大的痛点开始,而不是宏大的愿景。如果部署很痛苦,从那里开始。如果配置需要数周,从那里开始。220221### 2. 不把平台当作产品222平台团队需要产品经理、用户研究和反馈循环。开发者是你的客户 - - 理解他们的需求。223224### 3. 强制而非吸引225最好的平台是因为让开发者的生活更轻松而被自愿采用的。如果你必须强制使用,说明你的平台还不够好。226227### 4. 忽视开发者体验228用户体验糟糕的平台不会被使用。投资于清晰的文档、有用的错误消息和快速的反馈循环。229230## 如何开始231232构建你的第一个 IDP 的实用路线图:233234```mermaid235flowchart TD236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]237 B --> C[Month 5-6: Iterate]238 C --> D[Month 7+: Scale]239240 A --> A1[Interview developers]241 A --> A2[Map pain points]242 A --> A3[Choose first golden path]243244 B --> B1[Deploy Backstage]245 B --> B2[First service template]246 B --> B3[Standardized CI/CD]247248 C --> C1[Gather feedback]249 C --> C2[Add infrastructure abstraction]250 C --> C3[Improve docs and onboarding]251252 D --> D1[More templates and golden paths]253 D --> D2[Self-service infrastructure]254 D --> D3[Advanced observability]255```256257### 最小可行平台2582591. **服务目录**(Backstage) - - 了解存在什么以及谁负责2602. **一个服务模板** - - 为你最常见的服务类型提供黄金路径2613. **标准化 CI/CD** - - 团队引用的共享流水线2624. **基础文档** - - 如何使用平台,在哪里获得帮助263264你可以在 2-3 个月内用 2-3 名工程师的团队构建这个 MVP。265266## 结论267268Platform Engineering 不是要在第一天就构建完美的平台。它是关于逐步减少开发者的认知负荷,让他们能够专注于构建产品。从小处开始,衡量影响,并根据开发者反馈进行迭代。269270投资于 Platform Engineering 的组织将拥有显著的竞争优势:更快的交付、更快乐的开发者和更可靠的系统。271272**资源:**273- [Team Topologies](https://teamtopologies.com/) - - 推广平台团队概念的书籍274- [Backstage](https://backstage.io/) - - Spotify 的开源开发者门户275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - - 社区定义和最佳实践276- [platformengineering.org](https://platformengineering.org/) - - 社区、活动和资源277
:Platform Engineering:如何构建内部开发者平台lines 1-277 (END) — press q to close