31-平台工程概念
平台工程（Platform Engineering）是近年 DevOps 领域最热的话题之一。它不是 DevOps 的替代品，而是把 DevOps 实践产品化。本章简要介绍平台工程的核心概念——IDP、黄金路径、开发者体验，以及与传统 DevOps 的区别。
平台工程 vs DevOps#
两者常被混淆，但解决的是不同层次的问题：
- DevOps 是一种文化和实践，强调开发与运维的协作——"你构建，你运行（You build it, you run it）"。
- Platform Engineering 是把这套实践产品化：平台团队构建一套自助服务平台，业务开发团队作为用户消费平台能力，不需要深入理解底层基础设施细节。
用一个类比：DevOps 是教大家做饭，Platform Engineering 是开一家餐厅——菜单固定、流程标准化，厨师（业务团队）只管炒好自己那道菜。
| 维度 | DevOps | Platform Engineering |
|---|---|---|
| 关注点 | 文化与协作 | 产品化基础设施能力 |
| 主要受益者 | 开发+运维双方 | 业务开发团队 |
| 核心产出 | 流程改善 | 可自助的平台产品（IDP） |
| 成功指标 | 团队协作效率 | 开发者体验（DX）、DORA 指标 |
IDP（内部开发者平台）#
Internal Developer Platform 是平台工程的 core 产出，至少包含：
- 开发者门户（Developer Portal）：IDP 的入口，看所有服务、文档、工具。业界主流是 Backstage。
- 服务目录（Service Catalog）：回答"我们有哪些服务，谁负责，文档在哪，依赖什么"。
- 黄金路径（Golden Path）：预设的最佳实践路径——标准化项目模板、CI 流水线、K8s 配置。
- 脚手架（Scaffolding）：自动生成项目骨架，5 分钟拿到完整可运行的新服务。
- 环境管理：开发者自助申请/创建/销毁测试环境，不需要找运维开票。
- CI/CD 模板库：预置的流水线模板，开发者只需引用。
黄金路径（Golden Path）#
黄金路径是平台工程最核心的产出——标准化的最佳实践路径，开发者不需要从零设计，走黄金路径就是走最佳实践。
设计原则：
- 对 80% 场景开箱即用，不需要额外配置。如果黄金路径需要填 20 个参数，没人会用。
- 错误路径走不通。不只提供黄金路径，还要确保错误路径被拦截——CI 强制安全扫描、没有 readinessProbe 的 Deployment 被 Admission Webhook 拒绝。
- 文档和代码放在一起。每个服务仓库包含
docs/目录，TechDocs 自动渲染成网页。
典型实现：维护一个"公司级基础 Helm Chart"，服务只需提供 values.yaml 写差异部分。基础 Chart 预设了生产级默认值（PDB、HPA、健康检查、安全上下文、ServiceMonitor）。
开发者体验（DX）#
平台工程的成功指标不是"部署了多少工具"，而是"开发者体验好不好"。
量化指标：
- 新服务创建时间：从 Scaffolder 提交到第一次生产部署的时长
- 服务信息完整率：有完整 catalog-info.yaml 的服务数 / 总服务数
- 文档新鲜度：过去 3 个月内有更新的文档 / 总文档数
- Catalog 月活：每月使用 Backstage 的独立用户数
- DORA 指标：部署频率、变更前置时间、变更失败率、恢复时间
典型成功案例：
- 新服务 onboarding 时间从 2 天 → 20 分钟
- "这个服务谁负责？"类型的 Slack 问题减少了 80%
- 服务文档覆盖率从 30% 提升到 85%
认知负担（Cognitive Load）#
Matthew Skelton 和 Manuel Pais 在《Team Topologies》里提出：认知负担是限制团队效能的核心因素。平台工程就是系统性地把认知负担从业务团队转移到平台团队。
具体做法：
"可以工作"是最低标准，"不需要思考"才是目标。以前让开发者配监控要学 Prometheus scrape 配置、ServiceMonitor CRD、Grafana 面板；现在只需
serviceMonitor.enabled: true，剩下全由平台自动完成。错误路径比正确路径更重要。CI 强制通过安全扫描才能发布、
values.yaml中resources.limits不填则流水线报错、没有 readinessProbe 的 Deployment 会被拦截。文档和代码放在一起。TechDocs 让文档不在 Confluence 里孤立存在，而是和代码一起经历 review、版本控制。
典型落地路径#
6 个月从零到 MVP：
Month 1-2：清点现状，建服务目录
不要急着上工具，先做"服务地图"——把所有服务、负责人、技术栈、依赖关系整理清楚。部署 Backstage，先只开服务目录功能。
Month 3：黄金路径 v1
选一个最典型的技术栈（如 Go + PostgreSQL），设计标准化模板，在 1-2 个新项目上试跑。
Month 4：CI/CD 模板化
把共用 CI 流水线逻辑抽成模板，现有服务逐步迁移。按团队分批，不要一次性大迁移。
Month 5：脚手架上线
在 Backstage 中添加 Software Templates，让新服务创建走标准化流程。
Month 6：可观测性标准化 + 开始度量
把监控、日志、告警配置标准化，同时开始收集 DORA 指标，让数据说话。
常见陷阱#
陷阱一：平台太复杂，开发者不愿意用。IDP 设计了二十几个参数表单，最后没人用。黄金路径要足够"黄金"——对 80% 的场景开箱即用。
陷阱二：平台团队和业务团队脱节。平台团队陷入"我觉得这个功能很重要"的自嗨。每两周和 2-3 个业务工程师做用户访谈，把反馈优先级排在新功能之上。
陷阱三：强制迁移。平台工具如果是强制的会产生抵触。选择"激励迁移"——走黄金路径的服务享受更快的部署审批、自动的安全合规证明等特权。
小结#
平台工程是 DevOps 的产品化——把基础设施能力打包成自助服务平台，业务团队消费平台能力不需要懂底层。IDP 的核心组件是开发者门户（Backstage）+ 服务目录 + 黄金路径 + 脚手架。成功的关键是降低认知负担——"不需要思考"才是目标，错误路径要拦住，文档和代码放一起。落地要渐进——先清点现状建服务目录，再逐步加黄金路径、CI/CD 模板、脚手架。工具选型只占 20%，剩下 80% 是平台团队跟业务团队磨合出来的东西。