结论先行：网络安全策略最大的风险往往不是配错，而是没人知道某条策略为什么存在。老工程师离职后，历史策略变成不敢碰的黑盒，团队只能"只加不删"，策略库越积越脏。解决思路是把策略从设备上的一串命令，变成带上下文的资产：每条策略绑定工单、申请人、业务用途与预期生命周期，统一沉淀并在平台上可检索。这样新人接手时能查到前因后果，也才敢动。
新人为什么不敢动老策略
"不敢动"不是能力问题，是信息问题。新人面对一条三年前的规则，缺少三个关键信息：
- 它为什么存在。是为某个已下线的系统开的，还是仍在支撑核心业务？
- 它影响什么。删掉之后谁会受影响，影响面有多大？
- 谁能拍板。这条规则的归属方是谁，该找谁确认？
三个问题都答不上来，理性的选择就是不动。于是策略库只增不减，性能下降、暴露面扩大，最终所有人一起承担后果。
一条"可交接"的策略要带哪些信息
| 信息项 | 解决什么问题 | 来源 |
|---|---|---|
| 业务用途描述 | 为什么开 | 申请工单的需求说明 |
| 关联业务系统与责任人 | 谁能拍板 | 资产台账／配置管理系统 |
| 创建工单号与时间 | 可追溯到具体事项 | 工单系统自动带入 |
| 预期的生命周期 | 何时该复核 | 申请时填写，临时规则必填 |
| 依赖与影响范围 | 删掉会影响谁 | 路径计算与命中日志分析 |
| 变更与复核记录 | 历史沿革 | 平台自动生成 |
其中"预期的生命周期"最容易被省略，也最有用。临时开通的规则如果申请时就填了到期时间，后续的回收就有了明确依据，而不用等人记得。
存量策略补上下文的三步
- 认领。把存量策略按网段、地址对象、历史工单关联到业务系统，分发给对应业务方认领。认领不了的进入待认领清单，单独跟踪。
- 分类。按用途分成几类：核心业务必需、临时开通、历史遗留、用途不明。分类的意义在于确定后续处理优先级——临时与不明项优先清理。
- 补录。对确认保留的策略补齐用途、责任人与生命周期字段，写进策略描述并同步到平台的策略台账。
这一步工作量不小，但不必一次做完。建议按业务重要性分批：先补核心业务的策略，其余的在日常变更中顺带补录。
让上下文自动产生，而不是靠人补录
靠人补录的上下文一定会过时。更稳的做法是把上下文的产生嵌进流程：
- 字段随工单带入。申请人在工单里填写用途、业务系统、到期时间，这些字段自动写入设备的策略描述，不需要事后录入。
- 责任人随资产同步。资产归属与负责人从资产平台同步，业务调整时策略上的责任人自动更新。
- 变更记录自动留痕。每一次修改都记录操作人、时间与前后差异，形成沿革，新人查看时能看到完整脉络。
- 到期自动提醒。生命周期字段到期前自动推送复核任务给责任人，把"记得清理"变成"系统提醒"。
常见坑
- 描述写得太简略。"业务需要"这四个字等于没写。应要求写清"哪个业务访问哪个服务、用于什么场景"。
- 只补新策略不管存量。新策略有上下文、老策略一片空白，检索时依然两眼一抹黑。存量必须分批补完。
- 补录后没人维护。责任人离职、业务下线后信息失效。应与资产平台和工单系统联动，让信息随业务变化自动更新。
奇摩在实施网络自动化项目时，通常把策略描述规范与字段映射作为一期交付内容之一，与设备纳管、拓扑发现同步推进，避免后期补录成本翻倍。
如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可基于现网数据做一轮评估，再决定是否推进。