复盘Linux生产事故的核心是快速定位根因并防止重复发生，需保全证据、交叉验证时间线、逐层验证根因、将改进固化到流程或自动化中。
复盘Linux生产事故，核心是快速定位根因、防止重复发生，而不是追责。关键在于建立可追溯的日志链、明确责任边界、用数据说话，并把改进措施固化到流程或自动化中。
一、事故现场：第一时间保全证据
事故发生后5分钟内必须完成基础留证，避免系统自愈或日志轮转覆盖关键信息：
- 保存当前进程快照：ps auxf > /tmp/ps_$(date +%s).log
- 导出内存占用TOP10进程的详细信息：top -b -n1 | head -20 > /tmp/top_$(date +%s).log
- 抓取网络连接与监听状态：ss -tulnp > /tmp/ss_$(date +%s).log
- 同步系统日志缓冲区（尤其rsyslog未落盘时）：sync; logger "INCIDENT TRIGGERED $(hostname)"
- 若使用journalctl，立即导出最近1小时完整日志：journalctl --since "1 hour ago" > /tmp/journal_$(date +%s).log
二、时间线还原：用日志+指标交叉验证
单看一类日志容易误判。需将系统日志、应用日志、监控指标（CPU/内存/磁盘IO/网络延迟）按毫秒级时间对齐：
- 用date -d "2024-06-12 14:23:18.456" +%s.%N统一转换为Unix时间戳，便于比对
- 重点关注“第一个异常信号”：如dmesg里首次OOM killer日志、Prometheus中CPU突增至95%的精确时间点、Nginx error.log中第一条upstream timed out
- 检查crontab、systemd timer、CI/CD流水线触发记录，排除定时任务或自动发布引发的连锁反应
三、根因判定：拒绝“看起来像”，坚持可验证逻辑
常见误区是把现象当原因（如“CPU高所以服务慢”）。应逐层向下验证：
- CPU高？用perf top -p $(pgrep -f your_app)确认是用户态计算密集，还是频繁系统调用（syscalls）或锁竞争
- 磁盘IO高？用iostat -x 1 5看await和%util，再结合pidstat -d 1定位具体进程读写行为
- 内存不足？查cat /proc/meminfo中MemAvailable而非free；用smaps_rollup分析进程实际RSS与PSS分布
- 网络超时？用tcpdump -i eth0 port 8080 -w /tmp/incident.pcap抓包，过滤重传、零窗口、RST包
四、改进落地：不写进Wiki，就等于没改
所有改进必须可执行、可验证、可审计：
- 配置类问题（如ulimit过低）→ 改成systemd drop-in文件，systemctl daemon-reload && systemctl restart app后用systemctl show --property=LimitNOFILE app验证
- 代码缺陷（如未关闭文件描述符）→ 在CI阶段加入lsof -p $(pgrep your_app) | wc -l阈值检查
- 监控盲区（如未采集进程打开句柄数）→ 补齐Prometheus node_exporter textfile collector脚本，并在Grafana加告警面板
- 变更流程风险 → 在Ansible Playbook或Argo CD sync policy中强制加入pre-sync健康检查钩子
一次有效复盘，不在于报告多厚，而在于下次同类操作是否自动拦截、指标是否提前报警、故障是否不再需要人工介入。把经验变成代码，把教训变成检查项，事故才真正结束。
