2. 开发者门户的产品定位与用户旅程

开发者门户（Developer Portal）不是“内部官网”，也不是简单的文档站。它的产品定位应当被理解为平台能力的统一交付界面：把散落在 CI/CD、Kubernetes、可观测性、工单、权限、成本等系统中的能力，收敛成开发者可自助完成的一条路径。判断门户是否成功，不看页面数量，而看开发者能否在不提工单、不找平台同学的情况下，完成从“我来了”到“我的服务稳定运行”的全过程。

因此，本节的核心任务是绘制一张门户用户旅程地图：以开发者为主角，按生命周期阶段识别关键触点、门户应承载的能力，以及每个阶段可观测的体验指标。旅程地图的价值在于，它把“门户该做什么”从功能清单变成一条有先后依赖、有情绪起伏、有量化标准的路径。

一、旅程的五个阶段与关键触点

结合平台工程实践，开发者旅程可归纳为五个阶段：入职（Onboarding）、服务创建（Create）、部署（Deploy）、调试（Debug）、运维（Operate）。每个阶段都有明确的“入口触点”和“出口判据”。

• 入职阶段：开发者首次访问门户，需要完成身份绑定、环境申请、工具链获取。关键触点是“首次登录后的引导页”和“环境就绪通知”。出口判据是：开发者能在 30 分钟内拿到可用的命名空间、代码仓库和本地 CLI 凭证。
• 服务创建阶段：从模板或脚手架生成服务骨架。关键触点是“服务模板选择器”和“元数据填写表单”。出口判据是：仓库自动创建、CI 流水线自动注册、服务目录中出现该服务条目。
• 部署阶段：触发流水线并观察发布状态。关键触点是“部署面板”和“环境晋级按钮”。出口判据是：镜像构建成功、部署到目标环境、健康检查通过。
• 调试阶段：当部署异常或运行时出错，开发者需要日志、指标、链路追踪和临时调试入口。关键触点是“服务详情页的可观测性聚合面板”。出口判据是：能在门户内定位到错误根因，或明确知道该找谁。
• 运维阶段：日常巡检、告警响应、扩缩容、成本查看。关键触点是“告警中心”和“服务健康度看板”。出口判据是：告警有归属、有处理入口、有复盘记录。

这五个阶段不是线性的，调试和运维会反复回到部署。门户的设计必须允许开发者在任意阶段“跳回”上游，而不是强迫他们重新走一遍流程。

二、体验指标：每个阶段都要有可度量的“好”

旅程地图如果没有指标，就只是流程图。门户应承载的体验指标建议按阶段定义，并尽量从平台侧自动采集，避免人工填报。

这些指标的意义在于：它们把“门户好不好用”从主观感受变成可对比、可回归的工程数据。例如，如果“首次部署成功率”从 92% 掉到 78%，即使页面没有报错，也说明模板或流水线出现了回归。

三、旅程地图的绘制方法

绘制门户用户旅程地图时，建议按以下顺序操作：

1. 确定主角与场景：主角是“新入职的后端开发者”还是“已有服务的维护者”？场景不同，触点优先级不同。建议先画新入职场景，因为它覆盖最多首次体验。
2. 逐阶段列出触点：每个阶段至少列出 2～3 个门户页面或交互动作，并标注该触点依赖的后端系统。
3. 标注情绪与摩擦点：在旅程图上用颜色区分“顺畅”“等待”“受阻”。摩擦点通常出现在跨系统跳转、权限审批、文档缺失三个位置。
4. 绑定指标：为每个阶段选 1 个主指标和 1 个辅助指标，写入门户的埋点需求。
5. 验证闭环：找 2～3 名真实开发者走一遍，记录实际耗时与卡点，修正地图。

四、门户应承载的关键触点与系统边界

门户本身不生产能力，它是能力的编排层。下图展示了开发者从入职到运维的旅程中，门户作为统一入口，如何连接身份、模板、CI/CD、可观测性和告警系统，并标注每个阶段的体验指标。

五、从地图到落地：门户功能优先级

有了旅程地图，门户的功能排期就有了依据。建议按“摩擦点密度 × 指标影响面”排序：

• P0：入职引导页、服务模板、部署状态面板。这三项直接决定首次体验，缺失会导致开发者立刻退回工单模式。
• P1：可观测性聚合面板、告警中心。它们决定日常使用频率，是门户从“一次性工具”变成“每日入口”的关键。
• P2：成本看板、服务健康度评分、复盘记录。属于治理增强，可在基础旅程稳定后接入。

最后，旅程地图需要落到一个可执行的检查动作：选一名真实开发者，从登录门户开始计时，记录他完成“创建服务并部署到测试环境”的总时长和卡点。这个数字就是门户当前体验的基线。后续每次迭代，用同一路径复测，才能判断门户是否真的在缩短旅程，而不是仅仅增加了页面。