本文定位：面向平台工程、DevOps 和研发效能团队，讨论内部开发平台门户的信息架构、服务目录和权限治理，不限定某个具体工具。
内部开发平台门户的目标不是把所有系统链接放到一个页面里，而是让开发者围绕“服务”完成查找、申请、发布、观测和责任追踪。一个只做导航的门户很快会过时；一个围绕服务目录和权限边界设计的门户，才能成为平台能力的统一入口。
如果你还在建立平台工程基础认知，可以先阅读站内 平台工程 相关内容；已经在规划服务目录时，则应进一步拆清字段、责任人和治理流程。
图1：内部开发平台门户中服务、团队、环境、流水线和观测入口的对
内部开发平台门户先解决“找不到”和“没人认领”
很多企业建设 IDP 时，第一需求不是自动创建环境，而是解决基础混乱：服务在哪里、谁负责、现在部署在哪个环境、出了问题找谁、发布记录在哪里。
门户首页应该优先呈现：
- 服务目录：服务名称、Owner、仓库、语言、运行环境、依赖关系。
- 环境视图：开发、测试、预发、生产的部署状态和入口。
- 交付入口：流水线、发布申请、回滚记录和变更审计。
- 观测入口：日志、指标、链路、告警和值班负责人。
- 模板入口：新服务模板、数据库申请、消息队列申请和常用 Runbook。
这些能力不一定第一天全部自动化，但字段口径要先统一。否则门户会变成“各系统截图的集合”，开发者仍然不知道哪个信息可信。
服务目录是门户的核心数据模型
服务目录不是资产台账的另一个名字。资产台账关注“有什么”，服务目录关注“谁负责、如何交付、如何运行、如何排障”。CNCF Platforms White Paper[1]强调，平台应通过开发者自服务和清晰能力边界提升交付效率。
| 字段组 | 典型字段 | 使用场景 |
|---|---|---|
| 责任字段 | Owner、团队、值班、审批人 | 告警、发布、故障升级 |
| 代码字段 | 仓库、分支策略、构建流水线 | 变更追踪和制品定位 |
| 运行字段 | 集群、命名空间、环境、域名 | 部署状态和入口查询 |
| 依赖字段 | 数据库、消息队列、外部 API | 影响分析和故障定位 |
| 合规字段 | 数据等级、权限组、审计要求 | 安全审批和访问控制 |
服务目录字段要服务日常协作
表格之外还要有变更机制。谁能创建服务、谁能修改 Owner、谁能下线服务，都应进入权限模型。服务目录的可信度取决于更新流程，而不是字段数量。
图2：服务目录从创建、变更、发布到下线的字段状态流转
权限边界要按动作设计，而不是按页面设计
门户权限常见错误是按菜单授权：某人能看某个页面，就顺带能执行页面上的所有动作。这会让高风险操作被隐藏在普通入口中，例如生产发布、回滚、扩容、Secret 查看和负责人变更。
更稳妥的设计是按动作授权：
- 只读查看：查看服务、环境、发布记录和观测入口。
- 自助申请：申请新环境、模板服务、临时资源或测试域名。
- 变更执行：触发流水线、调整配置、扩缩容和回滚。
- 高风险审批：生产发布、权限提升、敏感配置查看和服务下线。
- 平台管理：模板维护、集群接入、全局策略和审计导出。
如果底层运行在 Kubernetes 上，命名空间、ServiceAccount 和 RBAC 可以作为底层边界；门户层再表达团队、服务和审批动作。Backstage Software Catalog 官方文档[2]也把组件、系统、API、资源等对象作为目录建模核心。这样既能避免直接暴露底层权限，又能保留审计链路。
门户落地要从高频路径开始
内部开发平台门户不必一次做成“全功能平台”。最容易产生价值的路径通常是：查服务、看环境、找日志、触发发布、申请模板。
建议按三阶段推进：
- 第一阶段：可信目录。把服务、Owner、仓库、环境和观测入口统一到一个地方。
- 第二阶段：自助交付。接入模板、流水线、配置申请和发布记录。
- 第三阶段：治理闭环。引入权限审批、合规检查、成本归属和体验度量。
如果团队正在重构交付链路，可以把门户放在流水线、制品、环境和观测之间，而不是作为独立展示层。
图3：内部开发平台门户从可信服务目录到自助交付和治理闭环的演进
小结
内部开发平台门户的价值不在于“统一入口”四个字，而在于把服务目录、权限动作、交付记录和观测入口连接起来。服务目录负责建立可信对象，权限模型负责控制风险，自助模板负责提升效率，审计记录负责让平台可持续运营。
平台团队可以先从高频场景切入：让开发者能快速找到服务、负责人、环境、发布和日志，再逐步把创建、发布、回滚和权限申请纳入门户闭环。
参考资料
常见问题
1. 内部开发平台门户一定要用 Backstage 吗？
不一定。Backstage 提供了服务目录和插件生态，但企业是否采用它，要看已有系统、权限模型、插件成本和团队维护能力。更重要的是先定义服务目录和流程边界。
2. 服务目录和 CMDB 有什么区别？
CMDB 更偏资产和配置关系，服务目录更偏研发交付和运行责任。两者可以集成，但不建议把 CMDB 字段原样搬进门户，否则开发者会看到大量与日常任务无关的信息。
3. 内部开发平台门户的权限应该由平台团队还是安全团队维护？
平台团队负责动作模型和体验，安全团队负责高风险策略和审计要求。最好由身份源、审批系统和门户共同完成闭环，避免权限只存在于某个后台页面里。
4. 门户上线后如何衡量是否有效？
可以看服务目录完整率、Owner 缺失率、自助申请成功率、发布等待时间、故障定位时间和开发者反馈。不要只统计登录量，登录量高不代表平台真的降低了认知负担。
