变更关联排查是什么
「故障前动过什么」是排障中命中率最高的线索。大部分突发故障并不是设备自己坏了，而是发布、配置调整、证书更换、割接、扩容或第三方变更带来的副作用。做法是先把故障时间点和变更时间点放在同一条时间线上对齐，再去看技术细节。它的价值不只是快，还在于结论能直接指向责任方与下一步动作：确认了变更就谈回滚，排除了变更才能安心深挖设备与链路。
基本信息
| 第一步问题 | 最近改了什么：配置、发布、证书、割接、依赖升级、第三方变更 |
|---|---|
| 证据来源 | 变更单、Git 提交记录、审计日志、监控告警时间线、文件修改时间 |
| 时间对齐 | 把故障开始时间与变更完成时间放在同一条时间轴上看间隔 |
| 常用手段 | 回滚验证：先留现场，再把可疑变更退回去观察现象是否消失 |
| 盲区 | 上游依赖、云平台、运营商与第三方接口的变更通常不在自己的变更单里 |
典型使用场景
- 发布窗口后十分钟内出现报错，优先确认本次发布涉及哪些模块
- 证书到期前后出现 HTTPS 报错，先查证书更换记录与生效时间
- 网络割接或设备替换后部分网段不通，对齐割接动作与故障范围
- 第三方服务同时异常，先确认是本地变更还是上游变更
- 周末无人报障、周一集中暴雷，需要用监控时间线还原真实开始时间
- 依赖版本升级后出现偶发超时，检查驱动、内核与运行时版本记录
查最近改动
查最近改动
find /etc -mmin -1440 -type f 2>/dev/null | head -30 # 24 小时内被改过的配置
systemctl list-units --since '24 hours ago' --state=failed # 最近失败的服务单元
rpm -qa --last | head -20 # 最近安装或升级的软件包（RHEL 系）
journalctl --since '24 hours ago' -p err | tail -50 # 最近 24 小时的错误级日志
git -C /path/to/config log --since='24 hours ago' --oneline # 配置纳管在 Git 时直接看提交
systemctl list-timers --all | head -20 # 定时任务与自动续期类作业的时间点常见变更与对应症状
| 变更类型 | 典型症状 | 验证方式 |
|---|---|---|
| 应用发布 | 接口报错、部分功能不可用、耗时抬升 | 对比发布前后版本与访问日志错误率 |
| 配置调整 | 重启后异常、特定路由或端口行为改变 | 比对配置备份与当前运行配置的差异 |
| 证书更换 | HTTPS 报错、部分客户端校验失败 | 用 openssl s_client 查看证书链与有效期 |
| 网络割接 | 单个网段或单条链路不通、路径变化 | 路径探测对比割接前后的跳数 |
| 扩容变更 | 分布式系统部分节点异常、数据不一致 | 核对新节点配置、时间同步与会话保持 |
发现可疑变更后优先走「回滚验证」，而不是在故障现场边猜边改：回滚后故障消失基本可以确认因果关系；但回滚前必须先把配置、抓包、日志留档，否则回滚没生效就失去了二次分析的依据。
变更结论本身也要交叉验证：文件修改时间晚于故障开始时间，说明这次改动不是原因；而监控时间线常常显示故障比人工报障时间早得多，别只按记忆判断先后。