上周三凌晨两点，公司官网突然打不开。排查半小时才发现，是前一晚手动升级Nginx后没记清楚改了哪几行配置——重启时加载了旧版ssl参数，证书链直接断裂。这种事儿，翻翻更新日志本该一眼看清，结果翻遍/var/log/也没找到自己写的记录。
更新日志不是交差，是给自己留的救命纸条
很多同事把更新日志当成“做完再补”的形式主义：随手在钉钉群里发一句‘已升级内核到5.15’，或者往共享文档里丢个‘2024-06-12 服务器维护’。等真出问题回溯时，才发现缺了关键信息——当时用的是yum还是rpm安装？是否停过nginx服务？有没有备份/etc/sysctl.conf？
一条合格的更新日志，至少包含这五样
时间（精确到分钟）：别只写‘6月12日’，得写成‘2024-06-12 02:17’。凌晨操作和白天操作的风险等级完全不同，时间戳就是第一道责任锚点。
操作人：写真实姓名或工号，不写‘运维组’。谁执行、谁确认、谁兜底，清清楚楚。
变更内容（具体到文件和参数）：‘升级OpenSSL’太模糊；‘openssl-1.1.1w → 3.0.13，替换/usr/lib64/libssl.so.1.1为libssl.so.3，/etc/ssh/sshd_config中Ciphers新增chacha20-poly1305@openssh.com’才算到位。
前置检查与备份动作：例如：
md5sum /boot/grub2/grub.cfg > /root/grub.cfg.bak.md5
cp /etc/fstab /root/fstab.pre-upgrade-20240612验证方式与结果：不能只写‘服务正常’，要写‘curl -I https://api.xxx.com/health 返回HTTP/2 200，latency<80ms；ss -tlnp | grep :443 显示nginx进程在监听’。
本地存一份，别全靠Git或Wiki
我们团队现在强制所有线上服务器在/root/update-log/下建当日日志文件，命名如20240612-nginx-hardening.log。为什么？因为Git挂了、Wiki打不开、甚至跳板机连不上时，只要还能SSH进机器，就能cat这个文件看最后一步干了啥。它不漂亮，但管用。
顺便提一句：日志里少用‘应该没问题’‘大概OK’这类词。服务器不认大概，只认exit code 0和curl返回码200。