题目与范围
为拥有许多服务、团队和部署环境的组织设计内部开发者平台。平台要降低常见交付任务的成本，同时避免变成工单队列，也不能强迫所有团队使用单一架构。
把开发者当作拥有不同工作负载的客户。Backstage 描述了跟踪服务、库和领域等实体的软件目录；DORA 建议把交付表现与开发者体验信号结合起来，而不是用一个生产力数字判断成效。
面试官考察什么
面试官考察平台产品思维、用户分层、工作流优先级、变更管理、治理和指标设计。好的回答会把平台能力连接到开发者任务和可测结果，同时为合理例外保留出口。
作答前需要确认的问题
- 第一批用户是谁：新团队、值班工程师、服务负责人还是安全审核者？
- 哪个重复任务成本最高：初始化、部署、查找负责人、可观测性还是合规证据？
- 需要支持多少语言、运行时、云和成熟度？
- 哪些约束强制执行，哪些允许退出？
- 目标是更快交付、更安全变更、更快入职还是降低认知负担？
30 秒回答框架
“我会从反复创建服务、又难以找到负责人和安全部署默认值的团队开始。MVP 包括明确负责人的目录、自助服务模板、一条安全部署黄金路径和可搜索运行手册。团队可以说明理由后退出。我会邀请三个代表性团队试点，衡量首次生产变更时间、失败部署恢复、入职时间、自助完成率和开发者满意度，再根据证据扩大范围。”
分步深入
第一步：按开发者任务分层
分别访谈服务负责人、新人、值班工程师和平台运维。痛点不同：发现依赖、创建仓库、安全发布或证明控制措施。使用真实工作流和支持工单，不只收集功能请求。
第二步：绘制黄金路径
选择一个高频且有风险的旅程，定义输入、默认值、审批和输出。黄金路径应是最容易的安全路线，不是隐藏的强制要求。说明团队可以在哪里定制或退出。
第三步：构建最小可用目录
先提供负责人、生命周期、关键依赖、部署与运行手册链接及新鲜度。Backstage 目录使用实体和元数据；要求负责人和来源文件，避免目录变成无人维护的通讯录。
第四步：增加自助动作
为下一个瓶颈提供模板：创建服务、接入标准 CI、申请环境或启用可观测性。每个动作说明前置条件、预计耗时、结果和自动化失败后的恢复路径。
第五步：把治理做成护栏
自动化安全和可靠性默认值，同时把政策与实现分开。平台可以用可解释原因阻止高风险部署并提供例外流程，不应静默改写团队代码或隐藏负责人。
第六步：规划采用与迁移
招募设计伙伴，端到端迁移一个真实服务，发布示例并提供答疑。记录迁移成本并保留旧路径文档。通过降低摩擦获得的采用，比没有支持的强制要求更持久。
第七步：定义平台可靠性
平台也要有 SLO：目录新鲜度、模板成功率、部署工作流可用性和事故响应。内部平台故障会成为生产依赖，因此要提供状态、回滚和支持负责人。
第八步：衡量结果和护栏
使用部署频率、失败部署恢复时间等交付指标，再加创建服务、首次部署、自助完成和支持工单等任务指标。加入开发者调研，并关注变更失败、平台事故和团队间不均衡影响。
权衡与边界
权衡一：标准化还是自主性
统一默认值能降低认知负担，自主性保留团队适配。优先标准化接口和安全控制，让实现选择藏在接口后面。
权衡二：自建还是集成
只自建真正差异化的工作流或政策。目录、CI、密钥和可观测系统若满足契约就优先集成；每个集成都会成为平台可靠性边界的一部分。
权衡三：更多功能还是更高完成率
二十个半成品插件会比少量可靠动作更增加摩擦。优先端到端任务完成，而非功能数量。
失败演练与演进计划
演练一：模板执行到一半失败
告诉用户已创建什么、如何安全重试以及谁负责清理。尽量让动作幂等，并在不需要管理员权限的情况下提供日志。
演练二：团队绕过黄金路径
先访谈再贴“不合规”标签。路径可能缺少真实用例、默认值差或迁移成本隐藏。改善旅程并记录合理退出。
演练三：平台故障阻断发布
测试降级操作、状态沟通和手动备选。平台应降低运维风险，不应成为不透明的单点故障。
常见错误与追问
错误一：把门户当主页
只有链接不会减少工作。先识别任务，再提供自助结果。
错误二：衡量代码行或点击数
那是活动量，不是产品结果。把交付数据与任务完成和开发者体验信号结合。
错误三：强制单一技术栈
平台契约可以支持多种运行时。说明哪些约束出于安全，哪些只是偏好。
错误四：忽视元数据负责人
过时目录会伤害事故响应。要求负责人、版本控制元数据、新鲜度检查和升级路径。
错误五：先迁移全部团队
先与设计伙伴验证一个可量化旅程。证据不足就大规模迁移会制造阻力并掩盖可用性问题。
错误六：忘记平台本身是生产软件
为平台设置 SLO、事故负责人、发布控制和回滚路径。