linux生产事故应急预案核心是快速定位、隔离、恢复与复盘，需提前明确角色工具流程；按p0-p2分级响应，执行止血-取证-回退-验证四步法，针对磁盘满等五类高频问题提供速查指令，事故后24小时内完成简报、文档更新和站会复盘。
Linux生产事故应急预案的核心是快速定位、隔离影响、恢复服务、事后复盘。不能等故障发生再想对策，必须提前明确角色、工具、流程和常见场景的处置路径。
一、事故分级与响应启动
按影响范围和业务严重性划分等级，避免小题大做或反应迟缓：
- P0级（严重）：核心服务不可用、数据持续丢失、安全入侵确认。立即拉群，运维+开发+DBA+安全负责人同步在线，启动最高优先级响应。
- P1级（高）：部分功能异常、性能陡降（如响应超时率＞30%、CPU/内存持续95%+）、日志大量报错。30分钟内初步响应，1小时内输出根因分析草稿。
- P2级（中）：非关键模块报错、偶发超时、监控告警但服务仍可用。纳入当日排班处理，24小时内闭环。
二、现场应急操作四步法
不盲目重启、不随意删日志、不跳过验证——所有动作需可逆、可追溯：
- 止血：立即隔离故障源。例如：iptables封禁异常IP、systemctl stop故障服务、kubectl drain问题节点、临时关闭定时任务（crontab -e 注释掉可疑条目）。
-
取证：在操作前保留第一手现场信息。执行：
uptime && free -h && df -h && top -b -n1 | head -30；保存最近2小时关键日志（journalctl -u xxx --since "2 hours ago" > /tmp/xxx-incident.log）；用ps auxf和lsof -i :端口查异常进程。 -
回退：优先启用已验证的恢复手段。如回滚最近一次发布（
git checkout 上一版本 && ansible-playbook deploy.yml）、切换备用配置（cp /etc/app.conf.bak /etc/app.conf）、启用数据库只读从库接管流量。 - 验证：恢复后必须验证业务逻辑，不止看服务进程是否起来。例如：curl检查API返回HTTP 200且含预期字段；用真实用户行为脚本模拟登录→下单→支付链路；核对监控指标（QPS、错误率、延迟P95）回归基线。
三、高频事故类型与速查建议
针对最常触发P0/P1的五类问题，给出直击要害的排查指令：
-
磁盘满：用
df -h定位分区 →du -sh /* 2>/dev/null | sort -hr | head -5找大目录 →find /var/log -name "*.log" -mtime +7 -delete清理旧日志（勿直接rm -rf）。 -
CPU打满：用
top看PID →ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -10→cat /proc/PID/stack查内核态卡点，或strace -p PID -c看系统调用热点。 -
连接数耗尽：
ss -s看total sockets →ss -tuln | wc -l查监听数 →netstat -an | grep :端口 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5定位来源IP。 -
内存OOM：查
dmesg -T | grep -i "killed process"确认被杀进程 →cat /proc/meminfo看MemAvailable → 检查是否有未限制容器内存（docker inspect 容器ID | grep memory）。 -
网络不通：分层验证——物理层（
ethtool eth0查链路）、路由层（ip route get 目标IP）、防火墙（iptables -L -n -v）、服务层（telnet 目标IP 端口或nc -zv 目标IP 端口）。
四、事后动作：不闭环等于没处理
事故结束后24小时内必须完成三项动作，否则同类问题大概率复现：
- 输出《事故简报》：包含时间线（精确到分钟）、影响范围（接口/用户量/订单损失）、根因（如“Nginx worker_connections配置为512，突增并发至2000导致连接拒绝”）、改进项（如“将worker_connections设为65535，并加入配置巡检checklist”）。
- 更新应急预案文档：把本次有效操作固化为标准步骤，例如在“磁盘满”章节补充“自动清理脚本路径及执行权限说明”。
- 组织15分钟站会复盘：只问三个问题——哪里响应慢了？哪个环节缺乏自动化？下次谁来盯这个监控项？不追责，只补漏。
