服务器宕机原因分析与处理

# 1. 确认主机是否存活（从另一台机器发起）
ping -c 4 10.0.0.11
# 2. 确认业务端口
nc -zv -w 3 10.0.0.11 80
curl -sv -m 5 http://10.0.0.11/healthz
# 3. 确认 SSH 是否可登（可登 = 系统还在，多半是应用层问题）
ssh -o ConnectTimeout=5 ops@10.0.0.11 'uptime; ss -lntp | head -20'

# 保存内核与系统日志（关键！reboot 后 journald 非持久化内容会丢）
journalctl -k -b -1 > /tmp/kernel_prev.log 2>/dev/null   # 上一次启动的内核日志
journalctl -b -1 --since "2 hours ago" > /tmp/sys_prev.log 2>/dev/null
dmesg -T > /tmp/dmesg.log

# 保存资源快照
ps aux --sort=-%mem | head -30 > /tmp/ps_top.log
free -m > /tmp/mem.log; df -h > /tmp/disk.log; df -i >> /tmp/disk.log
ss -s > /tmp/ss.log; ss -lntp > /tmp/ports.log

# 保存 OOM / panic 痕迹
grep -iE "oom|killed process|panic|call trace" /var/log/messages /tmp/kernel_prev.log 2>/dev/null

mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

# 查看是否被 OOM 杀过（CentOS/RHEL 系在 messages，Ubuntu 在 syslog/kern.log）
grep -iE "out of memory|killed process|oom-kill" /var/log/messages /var/log/syslog 2>/dev/null | tail -20

# journald 方式（推荐）
journalctl -k --since "1 hour ago" | grep -iE "oom|killed process"
journalctl -u nginx --since "1 hour ago" | tail -50

# 查看上次是否异常关机
last -x | head -20      # 看 reboot/shutdown 记录，正常 reboot 会有对应 shutdown 行
journalctl --list-boots # 列出历次启动，异常启动之间时间间隔突兀即为宕机

df -h                       # 空间
df -i                       # inode（小文件爆多时空间没满但 inode 满）
du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -15   # 定位大目录
lsof +L1                    # 已删除但仍被进程占用的文件（空间不释放的元凶）

ss -lntp | grep -E ":80|:443|:8080"   # 端口是否还在监听
systemctl status nginx --no-pager -l  # 服务状态与最后几行日志
curl -sv -m 5 http://127.0.0.1/healthz  # 本机自测，区分"服务挂"和"网络不通"

ip a; ip r                       # 本机地址与路由
ethtool eth0 | grep -E "Link detected|Speed"   # 网卡物理层
mtr -rw -c 50 8.8.8.8            # 沿途丢包定位（比 traceroute 更准）
ss -s                            # 连接数统计，判断是否被打满
cat /proc/net/sockstat           # 套接字状态

# 谁在什么时候执行过什么
grep -iE "sudo|su |rm -rf|systemctl (stop|restart)" /var/log/secure 2>/dev/null | tail -40
cat /var/log/audit/audit.log 2>/dev/null | tail -20
# 最近变更的配置文件
find /etc -maxdepth 3 -type f -mmin -120 2>/dev/null | head -20

## 故障复盘：<一句话标题>
- 故障等级：P0/P1/P2
- 影响时间：2026-03-12 14:23 ~ 14:58（共 35 分钟）
- 影响范围：订单下单接口 100% 失败，影响用户约 1.2 万

### 时间线（Timeline）
| 时间 | 事件 | 处理人 |
|---|---|---|
| 14:23 | 监控告警：5xx 比例 > 30% | 监控 |
| 14:26 | 值班响应，确认网关 502 | 张三 |
| 14:31 | 定位：应用节点 2 台 OOM 重启 | 张三 |
| 14:40 | 临时扩容内存 8G→16G 并重启 | 李四 |
| 14:58 | 业务恢复，核心接口成功率 99.98% | 李四 |

### 根因（Root Cause）
（写清楚直接原因 + 深层原因，避免只写"内存不足"）
直接原因：促销流量超预期 3 倍，JVM 堆上限 4G 被打满。
深层原因：压测未覆盖大促场景；堆内存告警阈值设置在 95%，缓冲不足。

### 为什么没早发现（Detection Gap）
- 缺少 JVM 堆使用率的趋势告警，只有瞬时阈值。

### 改进项（Action Items）
| 改进项 | 类型 | 负责人 | 截止 | 状态 |
|---|---|---|---|---|
| JVM 堆告警改为 80% 且持续 5 分钟 | 检测 | 李四 | 03-20 | 待办 |
| 大促前全链路压测纳入发布流程 | 预防 | 王五 | 03-31 | 待办 |

### 经验沉淀
- 有效动作：先切流量再修，避免影响面扩大。
- 无效动作：反复重启进程，浪费 8 分钟。

# /etc/systemd/system/myapp.service —— 用 systemd 实现进程崩溃自动拉起
[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
ExecStart=/opt/myapp/bin/myapp --config /etc/myapp/config.yaml
Restart=always
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=5
MemoryMax=4G          # 内存上限，超限触发 systemd OOM 而非整机 OOM
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target