回退是为先恢复业务
特征库升级后如果出现大面积误报、明显性能下降或业务访问异常，且时间点与升级高度吻合，正确的第一动作是回退到上一版本特征库，先把业务恢复起来，再从容分析是哪些规则引入的问题。回退不是失败，而是预案的一部分——前提是升级前就把上一版本的特征库文件保存好，否则预案只是一句话。
基本信息
| 触发条件 | 升级后集中出现误报、性能下降或业务异常，且与升级时间强相关 |
|---|---|
| 前提条件 | 升级前已保存上一版本特征库文件，并记录版本号与日期 |
| 执行方式 | 导入旧版本特征库文件覆盖当前版本（离线方式最稳妥） |
| 双机处理 | 两台设备都要回退到同一版本，避免检测能力出现落差 |
| 后续动作 | 记录事件、保留问题规则样本，向厂商反馈并跟踪修复版本 |
典型使用场景
- 升级后关键业务接口被误拦，业务方已在催办，需要尽快恢复
- 新特征导致设备 CPU 明显升高，影响转发与响应速度
- 同一版本在多台设备上均出现同类误报，判断为规则问题而非配置问题
- 升级后告警量暴增，值守无法区分真实攻击与误报
- 厂商已确认某版本特征存在问题，等待修复版本期间先回退运行
- 需要与业务方共同确认影响范围时，先回退创造稳定的分析环境
回退操作步骤
回退操作步骤
1. 确认问题与升级时间强相关，排除业务侧与链路侧的改动 # 先确认因果再动手
2. 检查权限与状态：确认有回退所需特征库文件与操作权限
3. 导入上一版本特征库文件，等待生效并确认版本号已变化
4. 验证误报是否消失，同时抽测关键业务连通性
5. 两台设备都完成回退，核对版本号一致
6. 记录事件经过与影响范围，提交厂商分析并跟踪修复回退动作与核对项
| 动作 | 核对内容 | 异常时的处理 |
|---|---|---|
| 导入旧版本 | 版本号与日期是否回到目标版本 | 导入失败时检查文件完整性与权限 |
| 验证误报 | 原误报是否不再产生 | 仍存在说明问题未必来自特征库 |
| 业务抽测 | 关键业务访问是否恢复正常 | 未恢复需并行排查策略与链路 |
| 双机一致性 | 两台特征库版本是否相同 | 不一致时补齐另一台再观察 |
| 记录归档 | 事件、影响、处置是否留档 | 缺失则补记，供后续复盘使用 |
回退同样属于变更，需要记录并通知相关方。悄悄回退而不留痕，会导致后续复盘时时间线对不上，也无法向厂商提供准确的问题定位信息。