结论先行：把策略开通做成服务目录，不是把原来的邮件申请搬进工单系统，而是把"业务方要什么"翻译成"平台能直接执行的条目"。可行做法是先定义四类服务条目（点到点开通、按应用开通、临时开通、批量开通），每类配一套必填字段与校验规则，再与平台做三段衔接：提交前预检、自动生成配置、下发后连通性验证。同时守住四条边界——查询前置、范围授权、全程留痕、退回要有具体原因。
为什么光有工单系统还不够
很多企业已经有了工单系统，但开通周期没有明显变化，问题通常出在三个地方：
- 条目是自由文本。申请里写"开一下访问"，运维要反复追问源、目的、端口、用途，来回三轮才能开工。
- 申请与设备是脱节的。工单审批通过了，但没人知道这条需求要改哪几台设备、中间有没有地址转换。
- 结果没有回写。开通完没验证、没回执，业务方不知道好了没有，只能再来问一次。
服务目录要解决的就是这三件事：把输入结构化、让申请直接驱动配置、把结果回写给申请人。
四类服务条目
| 条目 | 适用场景 | 必填字段 | 自动化程度 |
|---|---|---|---|
| 点到点开通 | 明确源地址、目的地址与端口的常规访问 | 源、目的、端口、协议、业务标识、有效期 | 高，可直接生成配置 |
| 按应用开通 | 业务方只知道应用名，不知道地址 | 应用标识、访问方应用、服务端口、环境 | 中，需先做应用到地址的解析 |
| 临时开通 | 项目联调、临时支撑、应急放行 | 同上 + 失效时间、申请人、审批人 | 高，且到期自动回收 |
| 批量开通 | 新业务上线、机房搬迁的一次性大批量需求 | 需求清单附件、业务域、期望时间窗 | 中，需先做路径计算与冲突检查 |
条目不宜过多。四类已能覆盖绝大多数场景，再多就会让业务方在选条目这一步卡住，最后又退回自由文本。
每个条目要填什么
| 字段 | 作用 | 校验规则 |
|---|---|---|
| 源地址/地址组 | 确定访问发起方 | 必须是已登记的地址对象，不支持自由填写 |
| 目的地址与服务端口 | 确定访问目标 | 端口必须来自服务目录，不填"任意" |
| 业务标识 | 关联到业务系统，便于后续治理 | 从资产台账选择 |
| 有效期 | 临时策略的自动回收依据 | 临时条目必填，最长不超过约定上限 |
| 用途说明 | 审批依据与审计材料 | 不少于 15 字，不接受"测试"这类词 |
与自动化平台的三段衔接
- 提交前预检。申请人填完表单，平台先做一次连通性预检——如果这条访问本来就是通的，直接提示并附上依据，这张单就不必提；如果不通，预检结果一并作为附件提交，审批人有据可依。
- 自动生成配置。审批通过后，平台根据拓扑与路径计算，自动算出需要经过哪些设备、翻译成对应品牌的命令，不再依赖人工翻译。
- 下发后验证并回写。配置下发完成立即做连通性验证，把结果与工单绑定，申请人收到明确回执。验证不通过走回退并说明卡点。
防止工单质量回落的四条边界
- 查询前置。把"源到目的是否能通"的自助查询放在提单入口之前，能直接削掉相当比例的无效工单。
- 范围授权。按业务域授权查询与申请范围，避免跨部门看到不该看的访问关系。
- 全程留痕。谁申请、谁审批、哪台设备改了什么、验证结果如何，全部可追溯，满足合规审计要求。
- 退回要具体。退回原因必须是可执行的具体项，如"目的端口不能填任意"，而不是"信息不全"。
落地清单
- 先梳理现网高频申请类型，再定条目，不要照搬别人的目录。
- 每个条目的必填字段控制在六项以内，超过这个数填写质量会明显下降。
- 把预检、生成、验证三段都打通，只做前两段等于把风险留到下发环节。
- 临时策略必须带有效期与自动回收，并纳入季度复核。
- 上线后统计一次退回原因分布，用真实数据反过来优化条目与校验规则。
奇摩深耕 IT 基础架构服务 25 年，在证券、银行、制造与能源行业的网络自动化项目里，通常把服务目录与工单字段字典一起设计，避免出现"系统上线了但单子还是提不明白"的情况。若您希望评估现有工单流程的改造空间，欢迎了解网络自动化运维方案或预约咨询。