platform-engineering

平台工程

目的

构建内部开发者平台（IDP），通过黄金路径和平台即产品理念提供自助式基础设施、降低认知负担并提升开发者生产力。

平台工程代表了传统 DevOps 的演进，专注于打造具备产品品质的内部平台，并将开发者视为客户。这一领域致力于解决开发者生产力危机：工程师有 30-40% 的时间花在基础设施和工具上，而非开发功能。

何时使用此技能

在以下情况下使用此技能：

• 构建或改进内部开发者平台
• 设计开发者门户（Backstage、Port 或商业 IDP）
• 实施黄金路径和软件模板
• 建立或重组平台工程团队
• 衡量并改善开发者体验（DevEx）
• 将 IDP 与基础设施、CI/CD、可观测性或安全工具集成
• 推动工程组织采用平台
• 评估平台成熟度并找出能力差距

核心概念

平台即产品

以对待面向客户的产品的同等严谨程度来对待内部平台：

产品管理方法：

• 制定平台愿景、战略和路线图
• 找出开发者“客户”及其痛点
• 通过采用率指标、满意度调查和业务影响衡量成功
• 根据反馈循环和使用情况分析进行迭代
• 在新增能力与平台可靠性和支持之间取得平衡

与传统 DevOps 的主要区别：

• DevOps 专注于交付流水线；平台工程构建全面的开发者体验
• 平台团队以产品团队的方式运作（产品经理、UX 设计师、工程师）
• 成功与否由开发者生产力和满意度衡量，而不只是基础设施指标
• 自助服务是主要交互界面，而非工单队列

内部开发者平台（IDP）架构

三层架构：

1. 开发者门户（前端）

• 服务目录：列出服务及其所有者、依赖项和健康状态
• 软件模板：内置最佳实践的项目脚手架
• 文档中心：集中管理、可搜索、受版本控制的文档
• 自助服务工作流：环境配置、部署、访问请求

2. 平台编排（后端）

• 基础设施配置：多云资源管理
• 环境管理：开发、预发布、生产环境的生命周期管理
• 部署自动化：基于 GitOps 的持续交付
• 配置管理：分离应用与基础设施相关事项

3. 集成层（粘合层）

• CI/CD 集成：流水线可见性和触发
• 可观测性：在门户中呈现指标、日志和追踪
• 安全：漏洞扫描、策略执行、密钥管理
• FinOps：成本可见性、预算、优化建议

有关详细的架构模式和组件拆解，请参阅 references/idp-architecture.md。

黄金路径与脚手架

黄金路径原则： 提供有主见的模板，满足 80% 的使用场景，同时允许其余 20% 的场景灵活处理。

模板组件：

• 代码仓库结构和样板代码
• 基础设施即代码（Kubernetes 清单、Terraform）
• CI/CD 流水线配置
• 可观测性埋点（指标、日志、追踪）
• 安全配置（RBAC、网络策略、密钥）
• 文档模板（README、运行手册、架构图）

约束机制：

• 使用策略即代码（OPA、Kyverno）执行安全与合规要求
• 设置资源限制和配额，防止过度配置
• 要求配置健康检查和可观测性埋点
• 使用经批准的基础镜像并扫描依赖项

有关模板设计模式和示例，请参阅 references/golden-paths.md。

开发者体验（DevEx）优化

降低认知负担：

• 抽象基础设施的复杂性，但不隐藏必要细节
• 提供合理的默认设置，并明确说明覆盖机制
• 采用渐进式呈现（常见场景保持简单，同时提供高级选项）
• 整合工具（使用单一开发者门户，而非 15+ 个独立工具）

关键指标：

DORA 指标：

• 部署频率（代码到达生产环境的频率）
• 变更前置时间（从提交到部署至生产环境所需的时间）
• 平均恢复时间（事件的 MTTR）
• 变更失败率（导致事件的部署所占百分比）

SPACE 框架：

• 满意度：通过调查和 NPS 衡量开发者的满意度
• 绩效：已完成工作的吞吐量和效率
• 活动：代码提交、PR、部署（作为背景信息，而非单纯计数）
• 沟通：协作质量和信息的易发现性
• 效率：尽量减少干扰，减少繁琐工作

平台专属指标：

• 平台采用率（使用平台的团队所占百分比）
• 自助服务率（无需向平台团队提交工单即可完成的操作所占比例）
• 入职时间（新开发者从入职到首次部署至生产环境所需的时间）
• 模板使用情况（采用了哪些黄金路径）
• 支持工单数量及解决时间

平台成熟度评估

使用 5 级成熟度模型评估当前的平台能力：

级别 0：临时应对 - 手动配置，没有标准化 级别 1：基础自动化 - 部分采用 IaC 和 CI/CD，自助服务能力有限 级别 2：铺设路径 - 黄金路径模板、初期门户、覆盖范围有限 级别 3：自助服务平台 - 功能全面的门户，80% 以上操作可自助完成 级别 4：产品驱动的平台 - 数据驱动、采用产品团队结构、集成 FinOps 级别 5：AI 增强平台 - AI 辅助故障排查、预测性优化

详细的评估框架、差距分析和改进路线图，请参阅 references/maturity-model.md。

决策框架

自建还是购买 IDP

适合选择开源方案（Backstage）的情况：

• 大型企业（1000+ 名工程师）
• 有专职平台团队（5-10 名工程师）
• 需要深度定制
• 更偏好开源生态
• 长期投入（规划周期 3 年以上）

适合选择商业 IDP（Port、Humanitec、Cortex）的情况：

• 中型组织（100-1000 名工程师）
• 需要更快实现价值（3-6 个月，而非 6-12 个月）
• 更偏好由供应商支持的托管解决方案
• 平台工程资源有限（少于 5 名工程师）
• 使用标准场景（Web 应用、微服务、CI/CD）

适合选择混合方案的情况：

• 需要兼顾灵活性和速度的大型组织
• 复杂基础设施需要编排后端
• 希望采用一流的门户和编排组件
• 愿意集成多个系统（例如 Backstage + Humanitec）

完整的决策树、选择标准和 ROI 计算，请参阅 references/decision-frameworks.md。

黄金路径设计：灵活性与标准化之间的平衡

控制范围：

高度标准化（受监管行业）：

• 技术选择有限，必须使用指定模板
• 通过准入控制器（OPA、Kyverno）执行策略
• 例外通道需要审批流程

平衡方案（适合大多数组织）：

• 推荐使用黄金路径（易于使用、文档完善、支持到位）
• 允许使用替代方案，但需提供文档
• 软性约束（通过默认设置和教育引导，而非强行限制）
• 明确偏离标准的责任归属（“自行偏离，自行负责”）

高度灵活（创新型组织）：

• 黄金路径仅作建议（而非强制要求）
• 尽量减少策略执行（仅针对关键安全问题）
• “构建并运行”责任模式

有关如何选择合适的平衡点和执行策略的详细指导，请参阅 references/decision-frameworks.md。

平台团队结构

集中式模型：

• 单个平台团队（5-20 名工程师）为整个组织提供服务
• 适用于：中小型组织（100-500 名工程师）

联邦式模型：

• 中央团队（5-10 名工程师）+ 嵌入各业务部门的工程师（每个部门 1-2 名）
• 适用于：大型组织（500-2000+ 名工程师）、拥有多个业务部门的组织

中心辐射式模型：

• 中央“中心”团队（3-5 名工程师）+ 负责贡献插件的“辐射”团队
• 适用于：开源文化浓厚的组织

有关团队规模、角色、职责和治理模型，请参阅 references/decision-frameworks.md。

工具推荐

开发者门户

Backstage（开源，CNCF）

• 信任评分：78.7/100，8,876 个代码片段
• 软件目录、脚手架工具、TechDocs、插件生态系统
• 推荐用于：设有平台团队的企业

Port（商业产品）

• 托管平台、现代化的 UI/UX、更快实现价值
• 推荐用于：中型组织（100-1000 名工程师）

Cortex（商业 SaaS）

• 企业级 IDP，侧重合规性，强制执行工程标准
• 推荐用于：受监管行业

平台编排

Crossplane（开源，CNCF）

• 信任评分：67.4/100，适用于多云的通用控制平面
• Kubernetes 原生声明式基础设施
• 推荐用于：多云抽象

Humanitec（商业产品）

• 平台编排器后端，环境和部署管理
• 推荐用于：复杂基础设施，可与门户配合使用

Terraform Cloud（商业产品）

• 成熟的 IaC 编排、工作区管理
• 推荐用于：大量使用 Terraform 的组织

GitOps 持续交付

Argo CD（开源，CNCF）- 推荐

• 信任评分：91.8/100（最高）
• 面向 Kubernetes 的声明式 GitOps、多集群管理
• 业界领先的文档和社区

Flux（开源，CNCF）

• 工具包式方案，Kubernetes 原生
• 适用于：原生采用 GitOps 的运维

有关详细的工具对比、集成模式和选择标准，请参阅 references/tool-recommendations.md。

实施指南

搭建平台

基础阶段（第 1-3 个月）：

1. 明确平台愿景并组建平台团队（3-5 名成员）
2. 采访开发者，找出痛点
3. 搭建开发者门户（Backstage 或商业产品）
4. 创建初始服务目录和第一个黄金路径模板

试点阶段（第 4-6 个月）：

1. 选择 2-3 个试点团队，提供专属入驻支持
2. 根据反馈快速迭代
3. 扩展至 3-5 个黄金路径模板
4. 集成关键工具（CI/CD、监控、密钥）

扩展阶段（第 7-12 个月）：

1. 将覆盖范围扩大到 20-50% 的工程团队
2. 构建自助式文档和培训
3. 制定平台 SLO 并建立值班轮换机制
4. 在组织内部推广（演示、倡导者计划）

成熟阶段（第 2 年及以后）：

1. 在整个组织中实现 80% 以上的采用率
2. 平台团队以产品团队的方式运作
3. 通过指标和反馈持续改进
4. 拓展 AI 辅助能力和策略即代码

有关详细的实施步骤和搭建平台的代码，请参阅 references/implementation-backstage.md。

创建黄金路径模板

模板设计流程：

1. 确定最常见的用例（Web 应用、API、数据管道）
2. 明确约定的选项（语言、框架、部署模式）
3. 创建代码库结构和基础设施清单
4. 配置包含安全扫描的 CI/CD 流水线
5. 添加可观测性埋点并编写使用文档
6. 在大范围推广前与试点团队一起测试

模板类别：

• 全栈 Web 应用（后端 API + 前端 + 数据库）
• 数据管道（包含编排的 ETL/ELT）
• 机器学习服务（模型服务、监控）
• 事件驱动微服务（消息代理集成）
• 定时作业（cron 作业、批处理）

有关模板示例、脚手架代码和自定义模式，请参阅 references/golden-paths.md 和 examples/ 目录。

推动平台采用

推广策略：

• 展示试点团队的成功案例（内部博客文章、演示）
• 围绕平台功能举办午餐学习会
• 设立内部倡导者计划（由高级用户帮助同事）
• 提供答疑时间和 Slack/Teams 支持频道

激励机制对齐：

• 让平台比其他方案更易用（黄金路径是“铺好的道路”）
• 与开发者已在使用的工作流集成
• 提供即时价值（更快完成入职，更清晰地了解情况）
• 表彰早期采用者，展示他们的成功案例

有关采用指标、跟踪仪表板和成功模式，请参阅 references/maturity-model.md。

快速参考

平台工程检查清单

战略与愿景：

• 记录平台愿景和章程
• 组建平台团队并明确职责
• 通过访谈找出开发者的痛点
• 定义成功指标（DORA、SPACE、采用情况）

IDP 基础：

• 部署开发者门户（Backstage、Port 或商业产品）
• 建立服务目录（所有权、依赖关系、健康状况）
• 创建并验证第一个黄金路径模板
• 为所有工程师提供可访问的文档中心

自助服务能力：

• 环境配置（开发、预发布、生产）
• 部署自动化（使用 Argo CD 或 Flux 实现 GitOps）
• 在门户中展示 CI/CD 集成
• 为每项服务提供可观测性仪表板

安全与合规：

• 执行策略即代码（OPA、Kyverno）
• 集成密钥管理（Vault、云服务提供商）
• 在流水线中进行漏洞扫描
• 配置 RBAC 和访问控制

运维与支持：

• 定义并监控平台 SLO
• 建立支持渠道（Slack、答疑时间）
• 编写事件响应手册
• 建立反馈闭环和使用情况分析

常见陷阱

一开始就构建过多：

• 从小处着手（1 条黄金路径、1 个试点团队），再逐步迭代
• 避免“试图一口气解决所有问题”

忽视开发者反馈：

• 建立持续反馈闭环，而不只是每季度开展一次调查

过度标准化：

• 为高级用例提供明确的例外途径

对成功的衡量不足：

• 跟踪 DORA 指标、满意度调查和自助服务使用率

把平台当作 IT 项目：

• 平台工程是产品开发，而非基础设施配置
• 需要产品经理、UX 设计师，并以客户为中心

与其他技能集成

相关技能：

• kubernetes-operations：集群运维、命名空间管理、RBAC、网络策略
• infrastructure-as-code：使用 Terraform、Pulumi 配置基础设施，并将其集成到平台
• gitops-workflows：GitOps 原则、Argo CD / Flux 实现模式
• building-ci-pipelines：将 CI/CD 流水线设计集成到平台模板中
• security-hardening：通过黄金路径落实安全最佳实践
• secret-management：将密钥管理集成到平台中（Vault、云服务提供商）
• observability：将监控、日志记录、追踪集成到开发者门户

跨技能工作流：

平台引导：

1. 使用 infrastructure-as-code 配置平台基础设施
2. 使用 kubernetes-operations 配置集群
3. 在平台基础设施上部署开发者门户（Backstage）
4. 集成 gitops-workflows（Argo CD）以实现持续交付
5. 添加 observability 集成（Prometheus、Grafana 插件）

创建黄金路径：

1. 根据常见用例设计模板
2. 使用 building-ci-pipelines 模式配置 CI/CD
3. 应用 security-hardening 最佳实践（SAST、容器扫描）
4. 集成 secret-management（Vault、加密配置）
5. 添加 observability 监控埋点（指标、日志记录、追踪）

示例用例

用例 1：电商平台团队

背景： 一家拥有 300 名工程师的电商公司，采用微服务架构，手动配置导致瓶颈。

方案： 部署 Backstage，创建 3 条黄金路径，集成 Argo CD，先在 3 个团队中试点，再在 6 个月内扩展到 20 个团队。

结果： 入职时间从 2 天缩短至 2 小时，部署频率从每周 2 次提升至每天 10 次，开发者 NPS 提升 35 分。

用例 2：金融服务平台

背景： 一家拥有 1500 名工程师的银行，合规要求严格，基础设施陈旧，工具分散。

方案： 采用 Port（商业版），打造高度标准化的黄金路径，使用 OPA Gatekeeper、联邦模式和 Terraform Cloud。

结果： 合规审计准备时间从 3 周缩短至 3 天，基础设施漂移事件减少 90%，实现按服务进行成本归属。

用例 3：初创公司平台

背景： 一家拥有 50 名工程师的初创公司，快速发展，需要加快开发者入职。

方案： 部署轻量级 Backstage（由 2 名工程师负责），创建 2 条黄金路径，使用 GitHub Actions、PaaS 基础设施（Fly.io），并专注于文档。

结果： 新工程师从入职到投入生产仅需 1 天（原本需要 2 周），实现 100% 自助服务，由 2 名工程师支持 50 名开发者。

如需查看代码示例和模板结构，请参阅 examples/ 目录。