平台工程与IDP

平台工程与IDP分类聚合内部开发者平台、开发者门户、Golden Path、自服务流程和研发效能治理内容。建议结合平台工程学习路径按阶段学习，再回到本分类查找具体实践文章。

学习路径

DevOps学习路径从CI/CD流水线、GitOps到自动化发布与交付治理系统学习。 平台工程学习路径系统学习IDP、开发者门户、Golden Path和平台治理。

按方向查找文章

阅读建议：如果你在做系统学习，先进入平台工程学习路径；如果你已经在建设IDP或开发者门户，可以从本分类的具体实践、工具链和治理文章开始。

平台工程与IDP常见问题

DevOps 更强调协作和流程，平台工程则把高频能力沉淀为内部平台和自服务能力。平台工程可以看作 DevOps 在规模化团队中的工程化延伸。

平台工程通常承接 DevOps 规模化后的问题：流程已经自动化，但不同团队仍在重复申请环境、配置流水线、查日志和处理权限。此时把能力产品化，能显著减少平台团队的重复支持。

建议从应用模板、环境申请、发布流程、日志查询、权限申请和资源配额开始。这些是开发者最常用、平台团队也最容易重复支持的场景。

IDP 初期不要追求覆盖所有场景，优先选择高频、标准化、反馈明确的能力。应用脚手架、环境申请、部署模板、日志入口和权限申请通常比复杂门户功能更容易产生价值。

关键是从开发者体验和真实痛点出发，优先解决高频、重复、可标准化的问题，并通过使用率、等待时间和交付效率持续验证价值。

避免复杂化的关键是持续做能力边界管理。平台应该提供标准路径和少量可配置项，而不是把所有底层参数都暴露给开发者，否则只是把复杂度从运维侧转移到研发侧。

Kubernetes 提供运行底座，平台工程把部署、环境、权限、监控和回滚封装成开发者自服务能力，让业务团队不必直接面对集群复杂度。

结合 Kubernetes 时，IDP 应隐藏大部分集群细节，只暴露应用、环境、资源、发布和观测等开发者关心的对象。这样既能保持平台治理能力，也能降低业务团队使用门槛。