为什么规则变更要当变更管
WAF 的规则、阈值与白名单直接决定正常请求会不会被拦，改错一条规则的后果是业务报错或用户被拒，和改代码是一个量级。因此规则变更要走变更流程：评估影响、测试环境验证、灰度上线、观察一段时间、留档记录。批量调整还要拆成多次小变更，出问题时才定位得到具体是哪条规则造成的。
基本信息
| 高风险变更 | 启停规则、调整阈值、修改白名单、切换防护模式 |
|---|---|
| 流程要素 | 变更单、测试验证、灰度、观察期、回退方案 |
| 留痕内容 | 变更人、时间、内容、验证结果与回退记录 |
| 拆分原则 | 批量调整拆成多个小变更，便于定位问题 |
| 观察期 | 建议覆盖一个业务高峰，而不是只看平峰时段 |
| 回退准备 | 明确回退动作与回退触发条件 |
典型使用场景
- 新规则上线：先观察后拦截的推进过程
- 误报调优时修改白名单与阈值
- 版本升级带来的规则集行为变化
- 大促或活动期的临时策略收紧
- 攻击处置中紧急启用阻断规则
变更单示例
变更单示例
变更内容：规则 9xxxxx 动作由观察改为阻断 # 具体到规则
影响范围：门户站点全部 HTTPS 流量 # 范围
验证情况：测试环境通过，灰度 24 小时无异常 # 验证
观察期：覆盖一个业务高峰，重点看下单与支付接口 # 观察
回退动作：切回观察模式，规则保持启用 # 回退
回退条件：业务错误率上升超过预设阈值 # 判据变更环节与目的
| 环节 | 目的 |
|---|---|
| 评估 | 确认影响范围以及是否与业务高峰冲突 |
| 测试 | 在测试环境验证规则行为与误报情况 |
| 灰度 | 先小范围放量，限制误报的影响半径 |
| 观察 | 覆盖业务高峰，确认长尾场景也正常 |
| 留档 | 事后可追溯、可复盘、可解释 |
批量规则调整要拆成多个小变更：一次上线几十条规则，出问题时根本无法快速定位是哪一条。
变更后不设观察期，误报往往在业务高峰才暴露，那时回退的代价远大于提前灰度。