为什么按批次记录
WAF 的规则变动频率远高于防火墙策略：误报调优、新业务上线、防护模式切换、例外放行几乎每周都在发生。逐条登记不现实，按「变更批次」记录即可：一个批次对应一次有明确原因的改动，包含改了什么、为什么改、影响哪些业务、怎么验证、怎么回退。批次记录能回答两个关键问题——这条例外是谁在什么时候为什么加的，以及出问题时怎么退回去。
基本信息
| 记录字段 | 变更内容、变更原因、影响范围、验证结果、回退方式 |
|---|---|
| 关联单据 | 触发变更的误报处置单或业务需求单编号 |
| 归档关联 | 与配置备份版本关联，能对应到当时的规则集状态 |
| 审阅要求 | 涉及放行类改动（白名单、例外、规则关闭）需第二人复核 |
| 复核节奏 | 月度回顾一次，重点看是否存在只加不减的例外累积 |
典型使用场景
- 误报调优：业务反馈某个接口被拦，加例外后记录原因，后续判断是否可回收
- 新业务上线：为特定路径放开某类规则检测，记录业务方与责任边界
- 模式切换：从观察切换到拦截、或临时的观察模式，需记录切换原因与时点
- 规则集升级：CRS 或厂商规则包升级后出现的差异处置，作为版本对比依据
- 事件复盘：某次绕过或漏防事件后，回溯当时的规则状态与例外清单
- 季度合规检查：出示例外清单与审批记录，证明放行是受控的
批次记录示例
批次记录示例
批次 CHG-20261012-07
变更 为 /api/order 增加签名参数例外（规则 ID 942100）
原因 订单签名含 base64 串触发误报（误报单 INC-20261012-03）
影响 仅订单接口，其他接口保持拦截
验证 下单流程全链路通过，观察 24 小时无新增误报
回退 删除该例外规则，恢复原规则集（配置备份 20261012.cfg 已归档）记录字段读法
| 字段 | 写什么 | 用途 |
|---|---|---|
| 变更内容 | 改动的规则 ID、路径、模式与动作 | 精确还原改了什么，便于回退与复查 |
| 变更原因 | 对应的误报单号或业务需求 | 判断该例外是否仍然必要 |
| 影响范围 | 受影响的域名、路径或接口 | 评估变更的暴露面与风险 |
| 验证结果 | 验证方式与观察时长 | 证明变更达到预期且无副作用 |
| 回退方式 | 撤销动作与所需备份 | 紧急情况下无需重新摸索 |
例外与白名单只加不减是常见的规则腐化路径。按月回顾一次，把已经不需要的例外回收，防护强度才不会被慢慢磨掉。