配置漂移是什么
配置漂移指运行配置与设计文档不一致，来源通常是应急临时改动、多管理员并行操作，或工具批量下发时的覆盖。它的危害不在某一条参数，而在「同一策略处处不同」：同类问题总在某区域复发，变更的效果也变得不可预期。要治它，既要有变更记录，也要有定期与基线的逐项比对。
基本信息
| 主要来源 | 应急临时改动、多管理员并行操作、工具批量覆盖 |
|---|---|
| 典型症状 | 同类问题在某区域老复发；变更效果不可预期 |
| 核对方法 | 导出运行配置与基线逐项 diff |
| 管理机制 | 变更记录 + 定期基线核查，例如每季度 |
| 核查模块 | SSID、安全、射频、漫游、限速等分模块比对 |
典型使用场景
- 某区域问题反复出现，同类处理在其他区域却有效
- 变更后效果与预期不符，怀疑实际配置与设计不同
- 多个管理员并行维护后配置口径混乱
- 工具批量下发后个别 AP 配置被覆盖
- 交接或审计时需要确认实际配置与文档一致
做法
做法
# 导出运行配置，与基线配置做文本 diff
# 按模块核对：SSID、安全、射频、漫游、限速
# 差异项登记为待确认清单，逐项确认是变更还是漂移
# 确认后的设计变更回写基线，保持两者一致漂移来源与对策
| 来源 | 特征 | 对策 |
|---|---|---|
| 应急临时改动 | 未归档的个别参数 | 事后补记录并回写基线 |
| 多管理员并行 | 配置互相覆盖 | 建立变更审批与登记 |
| 工具批量下发 | 大范围覆盖 | 下发前先做差异比对 |
| 长期无人复核 | 差异逐渐累积 | 定期执行基线核查 |
配置漂移不修复，任何优化都会陷入「按下葫芦浮起瓢」：统一基线是优化生效的前提。
建议把基线核查写进运维日历并定期执行；差异项要逐条确认是「设计变更」还是「意外漂移」，不要一律改回。
没有变更记录时，diff 出来也不知道哪一边是设计意图，所以记录和比对必须同时具备，缺一不可。