漂移从哪来
常见成因有五类：排障时的手工应急改动（事后忘了回写）；自动化之外的变更，例如别人用安装脚本、云控制台或安全设备策略改过；软件包升级把配置文件重写或追加了默认段；配置管理没覆盖到该项、或这一轮执行失败但没人看结果；运行环境本身变了——地址段、证书、依赖服务地址变了，配置却还是旧的。识别时先做时间轴对齐：漂移时间点与哪次变更、哪次发布、哪个人的动作重合，这比盯着差异本身更有用。
基本信息
| 常见成因 | 手工应急改动、第三方自动化、软件升级重写、管理工具未覆盖或失败、环境变化 |
|---|---|
| 识别手段 | 与基准或快照比对内容、文件时间与版本记录、审计子系统的写入记录 |
| 判断要点 | 先对齐变更时间轴，再看影响范围是单机还是整组 |
| 关键约束 | 「与基准不同」不等于「有问题」，环境差异属于正常偏离 |
典型使用场景
- 事故复盘：确认故障前是否有未经流程的配置改动
- 重要节点前巡检：找出长期未收敛的历史残留项
- 人员变动后核查：新同事按经验改过的项是否仍在生效
- 多种自动化并存时排查：两套工具交替覆盖，行为难以预测
- 软件升级后核对：升级是否悄悄替换了服务端配置文件
- 环境变更后同步：地址、证书、镜像源变化是否已落到位
定位漂移来源的步骤
定位漂移来源的步骤
# 1 看文件改动时间，先缩出时间窗
stat -c '%y %n' /etc/nginx/nginx.conf
# 2 与基准或上次快照比对，确认差异内容
diff -u /var/lib/baseline/nginx.conf /etc/nginx/nginx.conf
# 3 查审计记录，确认谁在何时写入
ausearch -f /etc/nginx/nginx.conf -ts yesterday | tail -20
# 4 确认运行态是否已加载新配置（改文件不等于生效）
nginx -T | grep -n 'worker_processes'
# 5 与变更单、发布记录对齐时间轴后，再判断成因
# 注意：软件升级可能追加默认段而非整行替换，比对时要看新增而非只看修改成因与识别特征
| 成因 | 典型特征 | 识别方法 | 处置方式 |
|---|---|---|---|
| 手工应急改动 | 单机、改动零散、时间贴近故障 | 审计查询加内容比对 | 确认有效后回写模板 |
| 第三方自动化 | 整组主机同类改动 | 按分组统计差异 | 明确唯一真源，避免互覆盖 |
| 软件升级重写 | 升级后出现默认段或格式变化 | 对照旧版本与包内默认文件 | 纳入模板并固定关键项 |
| 管理工具失败 | 该主机应改未改或部分改 | 查看执行结果与日志 | 修复后重跑并回读校验 |
| 环境变化 | 地址、证书、依赖相关项过期 | 按依赖清单核对 | 更新变量并统一收敛 |
识别漂移时先区分「合理差异」与「异常偏离」：不同机房、不同规格、已登记的例外都属于前者。把合理差异纳入基线分层或分组变量，剩下的才需要作为问题跟踪。
只看文件内容会漏掉真正的风险：文件改了但服务没重载、服务重载了但依赖没同步，这类「半生效」状态在文件比对里看起来是干净的。收敛后应回读运行态确认。