手工 DNS 工单在入口很少的时候可以工作。
但当每次活动、合作方页面、租户 workspace、内部工具都要新增或修改入口时，工单就会变成瓶颈。
问题不是 DNS 不好，而是业务入口已经变成一个高频工作流，而手工工单不适合跑高频工作流。
一句话说明白
从手工 DNS 工单迁移到托管子域名入口，应该先做 inventory，再选一个高频入口类型试点，定义 owner 和状态规则，先迁移活跃入口，最后再接 OpenAPI 自动化。
PushUlink 可以帮助团队通过 Console 和 OpenAPI 创建、统计、替换和下线托管子域名转发入口。
第一步：盘点现有入口
换工具前，先知道自己有什么。
至少记录：
- Hostname。
- 当前目标地址。
- 负责人。
- 业务用途。
- 当前状态。
- 最近修改时间。
- 最近是否有访问。
第一天不要急着清理。先把隐藏工作看见。
第二步：只选一种入口先迁移
很多迁移失败，是因为团队想一次搬完所有东西。
更好的做法是先选一种：
- 活动入口。
- 合作方入口。
- 租户入口。
- 内部工具入口。
- 临时迁移入口。
优先选最频繁、最烦人的类型。
第三步：定义生命周期
每个托管入口都应该有状态。
最简单可以用：
- Draft：草稿。
- Active：启用。
- Paused：暂停。
- Review：待复查。
- Retired：已下线。
有了状态，入口就不再只是永远存在的 DNS 记录。
第四步：先迁移活跃入口
不要从没人认识的老记录开始。
先迁移：
- 当前正在使用的入口。
- 有明确业务 owner 的入口。
- 经常修改的入口。
- 对活动或客户重要的入口。
这样团队能更快看到价值。
第五步：DNS 仍然是基础设施
托管入口不是替代 DNS。
DNS 仍然是基础设施层。托管入口层在它上面，负责业务创建、更新、统计、trace 和下线。
这个分层能让工程保留控制，同时减少重复工单。
第六步：规则清楚后再接 OpenAPI
自动化应该在生命周期清楚以后再做。
适合接 API 的场景：
- SaaS onboarding 创建租户入口。
- 活动系统创建草稿入口。
- 合作方门户创建 partner route。
- 清理任务把旧入口标记为待复查。
没有 owner 的自动化，只会更快制造混乱。
迁移检查清单
- 盘点现有入口。
- 找到最痛的入口类型。
- 定义 owner 和状态字段。
- 先迁移活跃入口。
- 保留变更日志。
- 单独复查老入口。
- 规则清楚后再加 API 自动化。
结论
离开手工 DNS 工单，不是为了抛弃 DNS，而是为了把重复的业务入口工作放到更适合的管理层。
当入口有 owner、状态、统计、trace 和生命周期时，团队就不用再把每次活动上线都变成一次基础设施工单。
