Platform Engineering：如何构建内部开发者平台

spinny:~/writing $ less platform-engineering-internal-developer-platform.md

1 
2随着软件系统变得越来越复杂 -  - 微服务、Kubernetes、多云、CI/CD 流水线、可观测性技术栈 -  - 开发者花在基础设施上的时间越来越多，而用于构建产品的时间越来越少。**Platform Engineering** 通过创建一个抽象复杂性的内部平台，为开发者提供自助服务工具，从而加速交付来解决这个问题。
3 
4Gartner 预测，到 2027 年，**80% 的软件工程组织**将建立平台团队。在本指南中，我们将探讨什么是 Platform Engineering、为什么它很重要，以及如何从零开始构建 Internal Developer Platform。
5 
6## 什么是 Platform Engineering？
7 
8Platform Engineering 是一门设计和构建工具链与工作流的学科，为软件工程组织提供自助服务能力。其产出是一个 **Internal Developer Platform (IDP)** -  - 位于开发者和基础设施之间的一个抽象层。
9 
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17 
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24 
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31 
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43 
44### Platform Engineering 与 DevOps
45 
46Platform Engineering 不是 DevOps 的替代品 -  - 它是下一次演进。DevOps 说"你构建它，你运维它"。Platform Engineering 说"我们会让构建和运维变得毫不费力"。
47 
48| 方面 | DevOps | Platform Engineering |
49|------|--------|---------------------|
50| **关注点** | 文化和实践 | 产品和自助服务 |
51| **方法** | 每个团队管理基础设施 | 平台团队抽象基础设施 |
52| **认知负荷** | 高（每个团队都要学习所有内容） | 低（提供黄金路径） |
53| **产出** | CI/CD 流水线、IaC 脚本 | Internal Developer Platform |
54| **用户** | 所有工程团队 | 平台团队服务工程团队 |
55 
56## 为什么 Platform Engineering 很重要
57 
58### 认知负荷问题
59 
60在一个典型的现代组织中，开发者需要理解：
61 
62- Git 工作流和分支策略
63- CI/CD 流水线配置
64- 容器构建和镜像仓库管理
65- Kubernetes 清单和 Helm Charts
66- 云服务商服务（AWS/GCP/Azure）
67- 网络、DNS、TLS 证书
68- 监控、日志和告警配置
69- 数据库配置和迁移
70- 安全策略和合规性
71 
72这是一个巨大的认知负担，分散了对实际产品的注意力。
73 
74### 黄金路径
75 
76Platform Engineering 引入了**黄金路径**的概念 -  - 为常见任务提供的有主见的、支持良好且有文档记录的路径。黄金路径不是强制要求；开发者*可以*偏离，但平台让正确的做法变成最简单的做法。
77 
78```mermaid
79flowchart LR
80    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```
88 
89**创建新微服务的黄金路径示例：**
901. 开发者在门户中选择"新建后端服务"
912. 选择语言/框架（Node.js、Go、Python）
923. 平台自动创建：Git 仓库、CI/CD 流水线、Kubernetes 命名空间、监控仪表板和告警规则
934. 开发者克隆仓库，立即开始编码
94 
95## 构建 Internal Developer Platform
96 
97### 第一层：开发者门户
98 
99门户是开发者的唯一入口。最流行的开源选择是 **Backstage**（由 Spotify 创建，现为 CNCF 项目）。
100 
101核心功能：
102- **服务目录**：每个服务、其所有者、文档和依赖关系
103- **软件模板**：内置最佳实践的新服务脚手架
104- **技术文档**：文档即代码，可渲染和搜索
105- **插件生态系统**：通过自定义功能进行扩展
106 
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127 
128### 第二层：基础设施抽象
129 
130开发者不应该直接编写 Terraform 或 Kubernetes YAML。平台应该提供抽象层。
131 
132**工具：**
133- **Crossplane**：Kubernetes 原生基础设施配置
134- **Terraform 模块**：预构建、经过测试的基础设施模块
135- **Pulumi**：基础设施即真正的代码（TypeScript、Python、Go）
136 
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149 
150开发者不需要配置 RDS 参数、VPC 子网、安全组和备份策略，只需指定 `size: small` 和 `backup: daily`。平台处理其余一切。
151 
152### 第三层：CI/CD 标准化
153 
154标准化 CI/CD，这样团队就不需要各自构建自己的流水线。
155 
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163 
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172 
173**关键实践：**
174- 团队引用（而非复制）的共享 CI/CD 模板
175- 自动安全扫描（SAST、依赖审计）
176- 标准化部署策略（金丝雀发布、蓝绿部署）
177- 健康检查失败时自动回滚
178 
179### 第四层：可观测性
180 
181预配置的监控，让开发者开箱即获得仪表板和告警。
182 
183- **指标**：Prometheus + Grafana，每个服务提供标准仪表板
184- **日志**：结构化日志与集中收集（Loki、ELK）
185- **链路追踪**：使用 OpenTelemetry 的分布式追踪
186- **告警**：PagerDuty/Opsgenie 集成，提供合理的默认配置
187 
188```mermaid
189graph LR
190    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 --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199 
200## 衡量成功
201 
202你怎么知道你的平台在发挥作用？追踪以下指标：
203 
204### DORA 指标
205- **部署频率**：代码多久到达生产环境一次
206- **变更前置时间**：从提交到生产环境的时间
207- **变更失败率**：导致故障的部署百分比
208- **平均恢复时间**：事件发生后恢复服务的时间
209 
210### 平台特定指标
211- **首次部署时间**：从"新服务"到首次生产部署需要多长时间
212- **开发者满意度（NPS）**：定期调查你的用户
213- **自助服务比例**：无需工单处理的基础设施请求百分比
214- **黄金路径采用率**：遵循推荐路径的服务百分比
215 
216## 常见错误
217 
218### 1. 过早构建过多
219从最大的痛点开始，而不是宏大的愿景。如果部署很痛苦，从那里开始。如果配置需要数周，从那里开始。
220 
221### 2. 不把平台当作产品
222平台团队需要产品经理、用户研究和反馈循环。开发者是你的客户 -  - 理解他们的需求。
223 
224### 3. 强制而非吸引
225最好的平台是因为让开发者的生活更轻松而被自愿采用的。如果你必须强制使用，说明你的平台还不够好。
226 
227### 4. 忽视开发者体验
228用户体验糟糕的平台不会被使用。投资于清晰的文档、有用的错误消息和快速的反馈循环。
229 
230## 如何开始
231 
232构建你的第一个 IDP 的实用路线图：
233 
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239 
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243 
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247 
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251 
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256 
257### 最小可行平台
258 
2591. **服务目录**（Backstage） -  - 了解存在什么以及谁负责
2602. **一个服务模板** -  - 为你最常见的服务类型提供黄金路径
2613. **标准化 CI/CD** -  - 团队引用的共享流水线
2624. **基础文档** -  - 如何使用平台，在哪里获得帮助
263 
264你可以在 2-3 个月内用 2-3 名工程师的团队构建这个 MVP。
265 
266## 结论
267 
268Platform Engineering 不是要在第一天就构建完美的平台。它是关于逐步减少开发者的认知负荷，让他们能够专注于构建产品。从小处开始，衡量影响，并根据开发者反馈进行迭代。
269 
270投资于 Platform Engineering 的组织将拥有显著的竞争优势：更快的交付、更快乐的开发者和更可靠的系统。
271 
272**资源：**
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

2随着软件系统变得越来越复杂 - - 微服务、Kubernetes、多云、CI/CD 流水线、可观测性技术栈 - - 开发者花在基础设施上的时间越来越多，而用于构建产品的时间越来越少。**Platform Engineering** 通过创建一个抽象复杂性的内部平台，为开发者提供自助服务工具，从而加速交付来解决这个问题。

4Gartner 预测，到 2027 年，**80% 的软件工程组织**将建立平台团队。在本指南中，我们将探讨什么是 Platform Engineering、为什么它很重要，以及如何从零开始构建 Internal Developer Platform。

6## 什么是 Platform Engineering？

8Platform Engineering 是一门设计和构建工具链与工作流的学科，为软件工程组织提供自助服务能力。其产出是一个 **Internal Developer Platform (IDP)** - - 位于开发者和基础设施之间的一个抽象层。

10```mermaid

11graph TD

12 subgraph "Developers"

13 D1[Frontend Team]

14 D2[Backend Team]

15 D3[Data Team]

16 end

18 subgraph "Internal Developer Platform"

19 Portal[Developer Portal]

20 Templates[Service Templates]

21 CICD[CI/CD Pipelines]

22 Infra[Infrastructure Abstraction]

23 end

25 subgraph "Infrastructure"

26 K8s[Kubernetes]

27 Cloud[Cloud Services]

28 DB[Databases]

29 Monitor[Monitoring]

30 end

32 D1 --> Portal

33 D2 --> Portal

34 D3 --> Portal

35 Portal --> Templates

36 Portal --> CICD

37 Portal --> Infra

38 Infra --> K8s

39 Infra --> Cloud

40 Infra --> DB

41 CICD --> Monitor

42```

44### Platform Engineering 与 DevOps

46Platform Engineering 不是 DevOps 的替代品 - - 它是下一次演进。DevOps 说"你构建它，你运维它"。Platform Engineering 说"我们会让构建和运维变得毫不费力"。

48| 方面 | DevOps | Platform Engineering |

49|------|--------|---------------------|

50| **关注点** | 文化和实践 | 产品和自助服务 |

51| **方法** | 每个团队管理基础设施 | 平台团队抽象基础设施 |

52| **认知负荷** | 高（每个团队都要学习所有内容） | 低（提供黄金路径） |

53| **产出** | CI/CD 流水线、IaC 脚本 | Internal Developer Platform |

54| **用户** | 所有工程团队 | 平台团队服务工程团队 |

56## 为什么 Platform Engineering 很重要

58### 认知负荷问题

60在一个典型的现代组织中，开发者需要理解：

62- Git 工作流和分支策略

63- CI/CD 流水线配置

64- 容器构建和镜像仓库管理

65- Kubernetes 清单和 Helm Charts

66- 云服务商服务（AWS/GCP/Azure）

67- 网络、DNS、TLS 证书

68- 监控、日志和告警配置

69- 数据库配置和迁移

70- 安全策略和合规性

72这是一个巨大的认知负担，分散了对实际产品的注意力。

74### 黄金路径

76Platform Engineering 引入了**黄金路径**的概念 - - 为常见任务提供的有主见的、支持良好且有文档记录的路径。黄金路径不是强制要求；开发者*可以*偏离，但平台让正确的做法变成最简单的做法。

78```mermaid

79flowchart LR

80 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```

89**创建新微服务的黄金路径示例：**

901. 开发者在门户中选择"新建后端服务"

912. 选择语言/框架（Node.js、Go、Python）

923. 平台自动创建：Git 仓库、CI/CD 流水线、Kubernetes 命名空间、监控仪表板和告警规则

934. 开发者克隆仓库，立即开始编码

95## 构建 Internal Developer Platform

97### 第一层：开发者门户

99门户是开发者的唯一入口。最流行的开源选择是 **Backstage**（由 Spotify 创建，现为 CNCF 项目）。

100

101核心功能：

102- **服务目录**：每个服务、其所有者、文档和依赖关系

103- **软件模板**：内置最佳实践的新服务脚手架

104- **技术文档**：文档即代码，可渲染和搜索

105- **插件生态系统**：通过自定义功能进行扩展

106

107```yaml

108# backstage/catalog-info.yaml

109apiVersion: backstage.io/v1alpha1

110kind: Component

111metadata:

112 name: user-service

113 description: Manages user accounts and authentication

114 annotations:

115 github.com/project-slug: myorg/user-service

116 backstage.io/techdocs-ref: dir:.

117spec:

118 type: service

119 lifecycle: production

120 owner: team-auth

121 system: identity-platform

122 dependsOn:

123 - resource:postgresql-main

124 providesApis:

125 - user-api

126```

127

128### 第二层：基础设施抽象

129

130开发者不应该直接编写 Terraform 或 Kubernetes YAML。平台应该提供抽象层。

131

132**工具：**

133- **Crossplane**：Kubernetes 原生基础设施配置

134- **Terraform 模块**：预构建、经过测试的基础设施模块

135- **Pulumi**：基础设施即真正的代码（TypeScript、Python、Go）

136

137```yaml

138# Example: Crossplane composition for a database

139apiVersion: database.example.com/v1

140kind: PostgreSQLInstance

141metadata:

142 name: user-db

143spec:

144 size: small # Abstraction: small = 2 vCPU, 4GB RAM

145 version: "16"

146 backup: daily

147 team: auth-team

148```

149

150开发者不需要配置 RDS 参数、VPC 子网、安全组和备份策略，只需指定 `size: small` 和 `backup: daily`。平台处理其余一切。

151

152### 第三层：CI/CD 标准化

153

154标准化 CI/CD，这样团队就不需要各自构建自己的流水线。

155

156```yaml

157# .github/workflows/platform-ci.yml

158# Teams just include the shared workflow

159name: Build and Deploy

160on:

161 push:

162 branches: [main]

163

164jobs:

165 pipeline:

166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2

167 with:

168 language: node

169 deploy-target: production

170 secrets: inherit

171```

172

173**关键实践：**

174- 团队引用（而非复制）的共享 CI/CD 模板

175- 自动安全扫描（SAST、依赖审计）

176- 标准化部署策略（金丝雀发布、蓝绿部署）

177- 健康检查失败时自动回滚

178

179### 第四层：可观测性

180

181预配置的监控，让开发者开箱即获得仪表板和告警。

182

183- **指标**：Prometheus + Grafana，每个服务提供标准仪表板

184- **日志**：结构化日志与集中收集（Loki、ELK）

185- **链路追踪**：使用 OpenTelemetry 的分布式追踪

186- **告警**：PagerDuty/Opsgenie 集成，提供合理的默认配置

187

188```mermaid

189graph LR

190 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 --> Grafana

196 Tempo --> Grafana

197 Grafana --> PagerDuty[PagerDuty Alerts]

198```

199

200## 衡量成功

201

202你怎么知道你的平台在发挥作用？追踪以下指标：

203

204### DORA 指标

205- **部署频率**：代码多久到达生产环境一次

206- **变更前置时间**：从提交到生产环境的时间

207- **变更失败率**：导致故障的部署百分比

208- **平均恢复时间**：事件发生后恢复服务的时间

209

210### 平台特定指标

211- **首次部署时间**：从"新服务"到首次生产部署需要多长时间

212- **开发者满意度（NPS）**：定期调查你的用户

213- **自助服务比例**：无需工单处理的基础设施请求百分比

214- **黄金路径采用率**：遵循推荐路径的服务百分比

215

216## 常见错误

217

218### 1. 过早构建过多

219从最大的痛点开始，而不是宏大的愿景。如果部署很痛苦，从那里开始。如果配置需要数周，从那里开始。

220

221### 2. 不把平台当作产品

222平台团队需要产品经理、用户研究和反馈循环。开发者是你的客户 - - 理解他们的需求。

223

224### 3. 强制而非吸引

225最好的平台是因为让开发者的生活更轻松而被自愿采用的。如果你必须强制使用，说明你的平台还不够好。

226

227### 4. 忽视开发者体验

228用户体验糟糕的平台不会被使用。投资于清晰的文档、有用的错误消息和快速的反馈循环。

229

230## 如何开始

231

232构建你的第一个 IDP 的实用路线图：

233

234```mermaid

235flowchart TD

236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]

237 B --> C[Month 5-6: Iterate]

238 C --> D[Month 7+: Scale]

239

240 A --> A1[Interview developers]

241 A --> A2[Map pain points]

242 A --> A3[Choose first golden path]

243

244 B --> B1[Deploy Backstage]

245 B --> B2[First service template]

246 B --> B3[Standardized CI/CD]

247

248 C --> C1[Gather feedback]

249 C --> C2[Add infrastructure abstraction]

250 C --> C3[Improve docs and onboarding]

251

252 D --> D1[More templates and golden paths]

253 D --> D2[Self-service infrastructure]

254 D --> D3[Advanced observability]

255```

256

257### 最小可行平台

258

2591. **服务目录**（Backstage） - - 了解存在什么以及谁负责

2602. **一个服务模板** - - 为你最常见的服务类型提供黄金路径

2613. **标准化 CI/CD** - - 团队引用的共享流水线

2624. **基础文档** - - 如何使用平台，在哪里获得帮助

263

264你可以在 2-3 个月内用 2-3 名工程师的团队构建这个 MVP。

265

266## 结论

267

268Platform Engineering 不是要在第一天就构建完美的平台。它是关于逐步减少开发者的认知负荷，让他们能够专注于构建产品。从小处开始，衡量影响，并根据开发者反馈进行迭代。

269

270投资于 Platform Engineering 的组织将拥有显著的竞争优势：更快的交付、更快乐的开发者和更可靠的系统。

271

272**资源：**

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