Linux 系统变更的风险控制方法

变更前必须验证的三个检查点：一是检查/etc/fstab挂载项可用性（用mount -a）；二是验证systemctl服务依赖链完整性；三是核对内核模块兼容性（modinfo与uname -r比对）。

变更前必须验证的三个检查点

linux 系统变更不是改完就重启了事，最常被跳过的其实是前置验证。没做这三步，80% 的线上故障都发生在变更后 5 分钟内。

• 检查 /etc/fstab 中所有挂载项是否仍可访问：用 mount -a 测试，它会报出语法错误或设备不可达（比如 UUID 变了、LVM 逻辑卷名不匹配）
• 验证服务依赖链是否完整：运行 systemctl list-dependencies --reverse ，确认新增配置没意外切断上游依赖（例如改了 nsswitch.conf 后，sshd 可能因无法解析用户组而拒绝登录）
• 核对内核模块兼容性：如果变更涉及驱动或内核参数（如 sysctl.conf 修改），先用 modinfo 查看版本要求，并比对当前 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。留好每一步的可观测锚点，比追求“零故障”更实在。