09 · 运维案例集

前面几章是"工具"，这一章是"用工具解决过的具体问题"。每个案例都按 现象 → 定位过程 → 处置 → 复盘 四段写，包括当时走错的弯路。

案例清单

案例	关键词	状态
磁盘被日志写满	df 与 du 不一致、已删除文件仍占空间	已写
负载很高但 CPU 空闲	D 状态进程、NFS 卡住、磁盘 await	已写
Java 进程半夜被杀	OOM killer、swap、容器 memory limit	已写
TIME_WAIT 堆积	短连接、tw_reuse、连接池缺失	已写
Redis 主从漂移	网络抖动、sentinel 配置、客户端写死 IP	已写
Kafka 消息积压	分区数与消费者数、慢消费、毒丸消息	已写
定时任务不执行	crontab 环境变量、时区、日志重定向	已写
备份与恢复演练	mysqldump、xtrabackup、Redis RDB、异地存放	已写
批量运维脚本	多机 ssh、并行控制、失败中断	已写
监控告警落地	指标采集、阈值设计、告警收敛	已写

应急处理通用顺序

线上出事时按这个顺序做，别一上来就重启：

# 1. 留现场（三分钟内能抓到的都抓）
date; uptime; dmesg -T | tail -30 > /tmp/incident-$(date +%s)/dmesg.txt

# 2. 看变更：绝大多数故障来自发布、配置改动、证书到期、磁盘涨满
last -n 20; journalctl --since "2 hours ago" -p warning | tail -50
ls -lt /etc/nginx/conf.d/ /opt/app/config/ | head

# 3. 判断影响面：是个例还是全局，能不能先摘流量
ss -s; curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' http://127.0.0.1:8080/health

# 4. 止血（回滚/扩容/限流），确认稳定后再做根因分析

先止血，后诊断

生产环境的第一目标是恢复服务。根因分析可以在回滚之后慢慢做，但别为了保留现场让故障持续扩大。抓完关键快照就回滚。