面试 · 场景排查型

SSH 连不上
├── 网络层
│   ├── ping <ip> → 通？→ 通则 IP 可达，不通则查网络/防火墙
│   ├── telnet <ip> 22 → 通？→ 通则 SSH 端口正常，不通则端口未开
│   └── traceroute <ip> → 哪一跳断了？
├── 服务层
│   ├── 确认 sshd 是否运行：systemctl status sshd
│   ├── 确认 sshd 监听：ss -tlnp | grep 22
│   │   └── 监听 127.0.0.1:22？→ 只本机可连，改 /etc/ssh/sshd_config ListenAddress 0.0.0.0
│   └── 确认端口号：是否改了默认 22？
├── 认证层
│   ├── 密码登录 → /etc/ssh/sshd_config PasswordAuthentication yes？
│   ├── 密钥登录 → authorized_keys 权限 600？.ssh 目录权限 700？
│   └── 查日志：tail -f /var/log/auth.log 看拒绝原因
├── 防火墙
│   ├── iptables -L -n | grep 22
│   ├── ufw status（Ubuntu）
│   └── 云平台安全组/防火墙规则
├── 资源限制
│   ├── 连接数满了？ss -an | grep ':22' | wc -l
│   └── MaxStartups/MaxSessions 配置
└── SSH 配置问题
    ├── /etc/ssh/sshd_config PermitRootLogin yes？AllowUsers 白名单？
    └── 改了配置后：systemctl reload sshd

磁盘写满
├── Step 0: 先分清是"没空间"还是"没 inode"（易漏！）
│   └── df -h 显示有空间、写入却报 No space left on device？
│       └── → df -i 看 IUse%：inode 耗尽（海量小文件：session/缓存/邮件队列/大量空文件）
│           └── 定位：for d in /*; do echo "$(find $d -xdev 2>/dev/null|wc -l) $d"; done | sort -rn
├── Step 1: df -h 确认哪个分区满了（空间维度）
├── Step 2: du -sh /* 2>/dev/null | sort -rh | head -20
│   ├── 找最大的目录
│   │   ├── /var/log 很大 → 检查日志
│   │   │   ├── 容器日志？→ /var/lib/docker/containers/ 的 json.log
│   │   │   ├── journal？→ journalctl --disk-usage
│   │   │   └── 应用日志未轮转？→ logrotate 配置
│   │   ├── /tmp 很大 → 清理 > 10 天的文件
│   │   ├── /var/lib/docker 很大 → docker system prune -a
│   │   └── 某个应用目录很大 → 联系开发确认
├── Step 3: du 和 df 差距很大？
│   └── lsof | grep deleted → 找到幽灵文件 → kill/重启进程释放
├── Step 4: 应急清理
│   ├── 删除 /tmp 旧文件：find /tmp -mtime +7 -delete
│   ├── 清理 journal：journalctl --vacuum-size=500M（保留最新 500M）
│   ├── 清理 apt 缓存：apt-get clean（Debian/Ubuntu）
│   └── 清理 docker：docker system prune -af
├── 修复后
│   ├── 加磁盘监控告警：df -h | awk '$5>85{print}' → 钉钉/邮件
│   └── 调整 logrotate：/etc/logrotate.d/ 配置应用日志轮转

df -h                                    # 看哪个分区满了（空间）
df -i                                    # inode 使用率（df 有空间却报 No space 时必查）
du -sh /* 2>/dev/null | sort -rh | head  # 哪一级目录最大
lsof | grep deleted                      # 幽灵文件
docker system prune -a -f                # 清理 Docker 垃圾
journalctl --disk-usage                  # journal 占多少

CPU load 高但利用率不高
├── load average 含义：= R 状态 + D 状态进程数
├── 区分 R 还是 D
│   ├── ps aux | awk '$8~/R/{print}' → 纯 R 进程数量
│   ├── ps aux | awk '$8~/D/{print}' → D 状态进程数量
│   └── D 状态多 → IO 瓶颈！
├── D 状态 → 查 IO
│   ├── iostat -x 1 → 看 %util 和 await
│   ├── iotop → 哪个进程大量 IO？
│   ├── 检查 NFS 挂载：df -h | grep nfs → 是否 NFS 卡住
│   └── 检查存储：磁盘是否故障/降级
├── R 状态多但 CPU idle 高 → 锁等待/繁忙等待
│   ├── top -H -p <pid> → 看哪个线程占 CPU
│   ├── strace -p <pid> -c → 系统调用分布
│   └── 检查是否线程数过多导致负载高
└── 确认虚拟化层
    └── 云主机 CPU steal time：top 看 %st（被 hypervisor 偷的时间）

内存高但没 OOM
├── Step 1: free -h 区分 used / buff/cache / available
│   ├── buff/cache 很高？→ 正常，Linux 主动用空闲内存做缓存
│   ├── available 很低 (<200MB)？→ 真的内存不足，马上要 OOM
│   └── used 高但 available 也高？→ 没事，系统正常
├── Step 2: 找内存大户
│   ├── ps aux --sort=-%mem | head -10 → 内存前 10 的进程
│   ├── smem -t → 按 PSS（实际分配）排序（更准）
│   └── 检查容器：docker stats / kubectl top pods -A
├── Step 3: 检查 Swap
│   ├── free -h 看 Swap 用量
│   ├── vmstat 1 看 si/so → 大量换入换出 → 内存真的不够
│   └── cat /proc/sys/vm/swappiness → 调整 swap 倾向
├── Step 4: OOM 风险评估
│   ├── dmesg | grep -i "killed process" → 曾经 OOM 过的进程
│   ├── cat /var/log/syslog | grep oom
│   └── 查看 K8s Pod 的 OOMKilled 状态：kubectl describe pod | grep OOMKilled
└── 治理
    ├── 加内存告警：available < 10% 告警
    └── 容器设合理的 memory limit

服务启动失败
├── Step 1: systemctl status myapp
│   ├── 显示 Active: failed → 看下面的错误信息
│   └── 显示 Active: activating → 卡在启动中
├── Step 2: journalctl -u myapp --since "5 min ago"
│   ├── 有错误日志 → 直接定位原因
│   ├── 无日志 → 应用没写日志或日志级别太低
│   └── 有 OOM 相关 → 内存不足被杀
├── Step 3: 手动启动验证
│   ├── 直接运行启动命令（如 /usr/bin/myapp）→ 看报错
│   ├── 检查依赖：ldd /usr/bin/myapp → 缺库？
│   └── /usr/bin/myapp --version → 二进制是否完整？
├── Step 4: 常见原因
│   ├── 端口冲突：ss -tlnp | grep <port> → 端口已被占用
│   ├── 权限不足：无法打开日志文件/监听 <1024 端口/访问数据目录
│   ├── 配置错误：/etc/myapp/config.yaml 格式错误或路径不存在
│   ├── 依赖未就绪：数据库/Redis/Kafka 连不上 → 加等待逻辑或 depends
│   └── 资源限制：ulimit -n 不够 → Too many open files
├── Step 5: systemd 相关
│   ├── systemctl cat myapp → 看 ExecStart 命令是否正确
│   ├── Type= 是否正确？(simple/forking/notify)
│   └── 环境变量是否正确？Environment= 或 EnvironmentFile=

# 方法1: ss
ss -tlnp | grep :8080
# 输出: LISTEN 0 128 0.0.0.0:8080 users:(("java",pid=12345,fd=42))

# 方法2: lsof
lsof -i :8080
# 输出: java 12345 app 42u IPv4 123456 0t0 TCP *:8080 (LISTEN)

# 方法3: fuser
fuser 8080/tcp
# 输出: 12345/java
fuser -k 8080/tcp  # 直接杀掉

# 方法4: netstat(net-tools，已弃用，新系统最小安装可能没装；优先用 ss)
netstat -anp | grep 8080

系统慢
├── Step 1: top/htop — 整体快照
│   ├── load average 高？→ 查 D/R 状态进程
│   ├── %CPU 谁最高？→ 按 P 排序
│   ├── %MEM 谁最高？→ 按 M 排序
│   ├── %wa (iowait) 高？→ IO 问题
│   └── %st (steal) 高？→ 云主机被 hypervisor 偷时间
├── Step 2: 资源维度
│   ├── CPU：top 看利用率 + 进程消耗
│   ├── 内存：free -h + vmstat 1
│   ├── IO：iostat -x 1（%util/await/svctm）
│   └── 网络：ss -s + iftop/nethogs
├── Step 3: 应用层
│   ├── 日志中是否有大量 timeout/retry？
│   ├── 数据库连接池是否满了？
│   ├── GC 日志是否频繁 Full GC？
│   ├── 是否有线程死锁？（jstack <pid> / python pprof）
│   └── 上游是否有重试风暴？
├── Step 4: 对比变更
│   ├── 最近有没有发布？→ 回滚
│   ├── 流量有没有突增？→ 扩容
│   └── 有没有配置变更？→ 对比 git diff

# 1. 确认是幽灵文件
lsof | grep deleted | grep big.log
# 输出: app 12345 user 5w REG 253,1 10737418240 12345 /app/logs/big.log (deleted)

# 2. 找到持有句柄的进程 PID=12345
# 3. 处理
# 方式A：重定向清空 > /proc/12345/fd/5
# 方式B：重启进程 systemctl restart app
# 方式C：kill -HUP 12345（如果能触发日志重开）

# 4. 确认释放
df -h /app

# 前提：有 root 密码或物理/Console 访问
su -                                 # 切换到 root（需要 root 密码）
visudo                               # 修复 sudoers

# 如果是 WSL/容器/无 root 密码
pkexec visudo                        # PolicyKit 方式修复（如果安装了）

# 云主机
# 通过云平台 Console/VNC 登录，用 root 修复
# AWS: EC2 → Connect → EC2 Instance Connect
# Aliyun: 远程连接 → VNC

crontab 不执行
├── Step 1: 检查 cron 服务
│   └── systemctl status cron/crond → 是否运行？
├── Step 2: 检查语法
│   ├── crontab -l 查看 → 时间格式是否正确？
│   ├── * * * * * → 分 时 日 月 周
│   └── 常见错误：星期三写成 3（应该是 3，0=周日）
├── Step 3: 检查环境
│   ├── cron 的环境是极简环境（PATH=/usr/bin:/bin）
│   ├── 命令用绝对路径：/usr/bin/python3 /path/to/script.py
│   └── 或脚本开头加：PATH=/usr/local/bin:/usr/bin:/bin
├── Step 4: 检查日志
│   ├── grep CRON /var/log/syslog → 看 cron 是否调起了任务
│   ├── 有 "(root) CMD" 行但没执行 → 脚本本身的错误
│   └── 脚本加日志：echo "$(date): started" >> /tmp/cron.log
├── Step 5: 脚本权限
│   ├── chmod +x /path/to/script.sh
│   └── 脚本中引用的文件/目录权限
└── Step 6: 特殊问题
    ├── % 在 crontab 中会被解释为换行 → 需转义 \%
    └── crontab 最后的空行不能省（部分 cron 要求）

应用层  → curl -v http://target:port
传输层  → ss -tlnp | grep <port> / telnet <ip> <port>
网络层  → ping <ip> / traceroute <ip> / ip route
链路层  → arp -a / ethtool <iface>
物理层  → ip link show / dmesg | grep -i link
DNS     → dig <domain> / nslookup
防火墙  → iptables -L -n / ufw status / 云安全组

# 确认 TIME_WAIT 数量
ss -s                              # 快速统计
netstat -an | awk '/TIME_WAIT/{count++} END{print count}'

# 看具体连接
ss -tan state time-wait | head -20

# 复用 TIME_WAIT：仅对【主动发起连接的一方，即客户端出站】生效，且需两端开启 tcp_timestamps
sysctl -w net.ipv4.tcp_tw_reuse=1

# 扩大可用端口范围（缓解端口耗尽）
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# GRUB 启动时按 'e' 编辑启动项
# 在 linux 行末尾加：
systemd.unit=rescue.target    # 救援模式（基本服务+root shell）
systemd.unit=emergency.target # 紧急模式（只有 root shell）

# 或加 init=/bin/bash 直接到 bash

# 进入后常见操作：
mount -o remount,rw /          # 重新挂载根分区为读写
journalctl -xb                 # 看启动日志
systemctl list-units --failed  # 看失败的服务
vi /etc/fstab                  # 检查挂载配置

# 宿主机看容器的 cgroup 限制
cat /sys/fs/cgroup/cpu,cpuacct/kubepods/.../cpu.cfs_quota_us

# 容器内看实际可用 CPU
nproc                                    # 可能会显示全节点核数（误导）
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us  # 实际调度配额

Node NotReady
├── Step 1: kubectl describe node <node> → 看 Conditions
│   ├── MemoryPressure=TRUE → 内存不足 → free -h / dmesg | grep oom
│   ├── DiskPressure=TRUE → 磁盘 >85% → df -h / du -sh /*
│   ├── PIDPressure=TRUE → 进程数过多 → ps aux | wc -l
│   ├── NetworkUnavailable=TRUE → CNI 插件问题 → kubelet logs
│   └── KubeletReady=FALSE → kubelet 异常
├── Step 2: systemctl status kubelet
│   ├── 没运行 → systemctl restart kubelet
│   └── 运行但报错 → journalctl -u kubelet --since "10m ago"
├── Step 3: 常见根因
│   ├── 磁盘满（容器日志/镜像 → docker system prune）
│   ├── kubelet 证书过期 → kubeadm certs check-expiration
│   ├── containerd/docker 挂了 → systemctl restart containerd
│   ├── GPU 驱动崩溃 → nvidia-smi 无响应 → 重装驱动
│   └── 系统 OOM 导致 kubelet 被 kill → dmesg | grep oom
├── Step 4: 恢复步骤
│   ├── 清理磁盘 → df -h 确认降到 80% 以下
│   ├── 重启 kubelet → systemctl restart kubelet
│   ├── 如不行 → reboot
│   └── 仍不行 → drain + 重装节点