复盘必须盯住时间、影响、进程、日志四个硬指标并互相印证；追问四层Why需命令/配置支撑；改进项须明确主体、时限、验证方式；知识沉淀应为可直接执行的操作卡片。
盯住四个硬指标，别被“好像”“可能”带偏
复盘不是讲故事，是找证据链。第一件事：把时间、影响、进程、日志全部钉死到秒和数字上。journalctl --since "2026-01-24 00:30:00" --until "2026-01-24 00:35:00" 拉出故障窗口；top -b -n 1 快照抓当时 CPU/MEM 最高 PID；netstat -s | grep -i "retransmit" 看 TCP 重传是否跳变；df -h 和 iostat -x 1 5 同步比对磁盘使用与 await。四者必须能互相印证——比如日志说 Redis 连不上，ss -tulnp | grep :6379 却显示端口根本没监听，那“连不上”就不是网络问题，而是服务压根没起来。
追问四层 Why，每一层都要有命令或配置作支撑
停在“磁盘满了”是失败的复盘。“du -sh /var/log/journal/* | sort -hr | head -3” 找出最大 journal 目录；“journalctl --disk-usage” 确认实际占用；再查“cat /etc/systemd/journald.conf | grep -E "(MaxRetentionSec|SystemMaxUse)"” 看轮转策略是否关闭。这三层下来，“磁盘满”才变成“journald 未设 MaxRetentionSec + 应用狂打 DEBUG 日志”，而不是一句模糊归因。组织层也一样：如果发现变更清单里从不检查日志配置，那就得明确写进 SOP：“所有上线 Checklist 第 7 条：验证 /etc/systemd/journald.conf 中 MaxRetentionSec 已设为 30d”。
改进项必须带执行主体、截止时间、验证方式
“加强监控”等于没说；“2026-02-10 前由 SRE 组通过 Ansible 在全部生产节点部署 logrotate 配置，覆盖 /var/log/*.log 和 /var/log/journal/，执行 ansible all -m shell -a "logrotate -d /etc/logrotate.d/journal" 验证语法无报错”才算落地。同理，开发侧不能只写“优化日志”，而要写成：“Java 服务 Dockerfile 新增 ENV LOG_LEVEL=INFO，CI 流水线增加 grep -q 'DEBUG' target/*.jar || exit 1 校验步骤”。没有可验证动作的改进，就是给下次事故埋伏笔。
知识沉淀要能直接抄进终端，不是锁在 Wiki 里
复盘产出不是 PDF 报告，是“即插即用”的操作卡片。比如遇到 systemd-journald RSS 突增至 4GB+，知识卡就该写清楚：
• 症状：dmesg | grep -i "Out of memory" 显示 kill systemd-journald，ps aux --sort=-%mem | head -5 确认其排第一
• 第一响应：journalctl --vacuum-size=500M（不是 rm -rf /var/log/journal/*）
• 验证恢复：journalctl --disk-usage 回落到 800MB 以下 + systemctl restart systemd-journald 后 RSS 稳定在 300MB 内
复杂点在于：很多人以为清空 journal 就安全了，但没关 rate limiting 或没改 Storage=volatile，几天后照样爆。这点必须写进卡片的“高危提醒”里。
