变更前必须验证的三个检查点：一是检查/etc/fstab挂载项可用性（用mount -a）；二是验证systemctl服务依赖链完整性；三是核对内核模块兼容性（modinfo与uname -r比对）。
变更前必须验证的三个检查点
Linux 系统变更不是改完就重启了事，最常被跳过的其实是前置验证。没做这三步，80% 的线上故障都发生在变更后 5 分钟内。
- 检查
/etc/fstab中所有挂载项是否仍可访问：用mount -a测试，它会报出语法错误或设备不可达（比如 UUID 变了、LVM 逻辑卷名不匹配） - 验证服务依赖链是否完整：运行
systemctl list-dependencies --reverse <service></service>，确认新增配置没意外切断上游依赖（例如改了nsswitch.conf后，sshd可能因无法解析用户组而拒绝登录） - 核对内核模块兼容性：如果变更涉及驱动或内核参数（如
sysctl.conf修改），先用modinfo <module_name></module_name>查看版本要求，并比对当前uname -r输出
用 systemd-run 做原子化临时变更
直接改生产配置再 reload，一旦失败很难回滚。更稳妥的做法是把变更封装成一次性、带超时和自动清理的单元。
- 用
systemd-run --scope --on-failure=rollback.service --on-success=cleanup.service /bin/bash -c "echo 'new config' > /etc/myapp.conf && systemctl reload myapp"把操作包进 scope，失败时触发预设的rollback.service - 所有临时文件应写入
/run/（而非/tmp），因为/run是内存文件系统，重启即清，且systemd-run默认继承其 tmpfiles.d 规则 - 避免在
systemd-run中调用交互式命令（如vi或read），它会卡住整个 scope，导致超时后强制 kill，留下半截状态
配置文件变更必须带 diff 和签名追溯
“谁在什么时候改了哪行”不能靠人肉记日志。没有可审计的变更痕迹，等于没做风险控制。
- 所有配置变更前，先用
diff -u /etc/foo.conf{,.orig}生成补丁，并存为/var/log/changes/20240521-nginx-conf-abc123.patch（其中 abc123 是 git commit hash 或变更单号） - 用
gpg --clearsign对 patch 文件签名，确保后续有人篡改过内容能立刻发现；私钥不存服务器，只由变更发起人本地持有 - 如果用 Ansible，禁用
copy模块直传文件，改用template+checksum校验，且每次运行加--diff参数输出变更预览
重启服务前要绕过 systemd 的隐式依赖陷阱
systemctl restart nginx 看似简单，但实际可能顺带拉起 php-fpm、重载 iptables，甚至触发 NetworkManager 重协商——这些都不会写在 service 文件里，而是藏在 .wants 或 .requires 目录中。
- 运行
systemctl show --property=WantedBy,RequiredBy,Also nginx.service查看所有隐式关联单元 - 若只想 reload 配置不重启进程，优先用
systemctl reload nginx；只有当二进制升级或模块加载必须重启时，才用restart - 对关键服务（如
sshd、chronyd），在重启前先用ss -tlnp | grep :22确认监听端口未被意外释放，避免因 socket 激活机制失效导致服务不可达
真正难控的不是变更本身，而是那些没出现在变更清单里的间接影响——比如改了个时间同步策略，结果让 Kafka 消费者组心跳超时集体 rebalance。留好每一步的可观测锚点，比追求“零故障”更实在。
