模型示意图

考点范围：

进程与线程、僵尸进程、负载与 CPU 使用率
内存管理、缓存、Swap、OOM
磁盘与文件系统、inode、IO 性能分析
网络基础、连接状态、端口排查、路由与防火墙
权限模型、用户组、sudo、特殊权限位
systemd / journalctl / 服务管理
Shell 基础、日志分析、文本处理命令
定位线上故障的排查思路

Q1. Linux 中 load average 和 CPU 使用率是什么关系？为什么 load 很高但 CPU 不一定高？

核心要点
- load average 表示一段时间内处于可运行状态和不可中断睡眠状态的任务平均数，不等于 CPU 使用率。
- CPU 使用率高，通常说明进程在大量占用计算资源。
- load 高但 CPU 不高，常见原因是：
  - 大量进程在等待磁盘 IO
  - 进程处于不可中断睡眠状态
  - 锁竞争严重
- 判断是否异常要结合：
  - CPU 核数
  - top / uptime
  - vmstat
  - iostat
易错点
- 把 load average 直接理解成“CPU 百分比”。
- 只看 1 分钟负载，不看 5 分钟、15 分钟趋势。
- 不结合核数判断，例如 8 核机器 load=8 不一定异常。
深挖点
- 为什么 D 状态进程会拉高 load。
- vmstat 1 中 r、b 字段分别代表什么。
- 在 K8s 节点上，哪些场景会造成高 load：
  - 容器频繁读写日志
  - 存储挂载异常
  - 节点磁盘抖动

Q2. 线上 Linux 机器 CPU 飙高时，你会怎么排查？

核心要点
- 先看整体：
  - top
  - uptime
  - mpstat -P ALL 1
- 再定位进程：
  - top -Hp <pid> 看线程级 CPU
  - ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
- 分析系统态还是用户态：
  - 用户态高：业务代码计算密集
  - 系统态高：系统调用、网络包、磁盘 IO、内核开销
- 必要时用：
  - pidstat
  - perf
  - strace
易错点
- 只看到 Java / Go / Python 进程 CPU 高，却不继续定位线程或调用热点。
- 忽略 sys 高的情况，误以为都是业务代码问题。
- 不区分瞬时毛刺和持续性飙高。
深挖点
- CPU 飙高但容器指标不高，可能是哪些原因。
- 为什么内核软中断高会导致 CPU 高。
- 容器场景下如何结合 cgroup、kubectl top、节点指标一起看。

Q3. Linux 中内存是怎么划分的？为什么 free 很少不一定代表内存不足？

核心要点
- Linux 会尽量利用空闲内存做：
  - page cache
  - buffer cache
- free 少不一定有问题，要重点看：
  - available
  - swap 使用情况
  - 是否触发 OOM
- 常用命令：
  - free -h
  - vmstat
  - cat /proc/meminfo
- 真正紧张通常表现为：
  - available 很低
  - swap 持续增长
  - 频繁 page reclaim
  - OOM Killer 触发
易错点
- 只看 free，不看 buff/cache 和 available。
- 把缓存误当成“内存泄漏”。
- 看到 swap 使用就断定系统有问题。
深挖点
- page cache 为什么对文件读性能重要。
- kswapd 是做什么的。
- 在 K8s 中，容器 OOM 和节点 OOM 有什么区别。

Q4. 什么是 OOM？Linux 发生 OOM 时如何排查？

核心要点
- OOM 是系统内存不足时，内核选择部分进程杀死以释放内存的机制。
- 常见排查思路：
  - dmesg | grep -i oom
  - journalctl -k | grep -i oom
  - 查看进程内存占用：
    - ps aux --sort=-%mem | head
- 关注：
  - 是系统级 OOM，还是容器 / cgroup 限制导致的 OOM
  - 是否存在内存泄漏
  - 是否 limit 设置过小
易错点
- 把应用退出都当成 OOM，没有查看内核日志。
- 只排查应用，不看节点总内存是否被其他进程吃掉。
- 忽略 cgroup memory limit。
深挖点
- OOM Killer 的选择依据是什么。
- oom_score 和 oom_score_adj 的作用。
- K8s 中 requests / limits 配置不合理如何引发 OOM。

Q5. 磁盘满了应该怎么排查？df 和 du 为什么可能不一致？

核心要点
- 先看磁盘整体使用：
  - df -h
  - df -i
- 再看目录占用：
  - du -sh /*
  - du -sh /var/*
- df 和 du 不一致常见原因：
  - 文件被删除但进程仍持有文件句柄
  - 挂载点覆盖
  - 文件系统元数据或保留空间差异
- 可用：
  - lsof | grep deleted
易错点
- 只清理“看得见”的文件，忽略 deleted 文件仍被进程占用。
- 只看空间，不看 inode。
- 清理日志后不重启或不 reload 进程，空间不释放。
深挖点
- inode 耗尽和磁盘空间耗尽的区别。
- 为什么容器日志容易撑满节点磁盘。
- overlay2、镜像层、容器层对磁盘占用的影响。

Q6. Linux 中 inode 是什么？inode 用完会有什么现象？

核心要点
- inode 用来存储文件元信息，如：
  - 文件类型
  - 权限
  - 所有者
  - 时间戳
  - 数据块指针
- 文件名和 inode 是映射关系。
- inode 用完后，即使磁盘还有剩余空间，也无法创建新文件。
- 查看方式：
  - df -i
  - ls -i
易错点
- 以为“磁盘没满就还能写文件”。
- 不理解大量小文件比大文件更容易耗尽 inode。
深挖点
- ext4/xfs 在 inode 管理上的差异。
- 为什么日志碎片化、小文件爆炸会成为线上问题。
- K8s 中哪些目录可能产生海量小文件。

Q7. 线上服务器网络不通时，你一般怎么排查？

核心要点
- 先确认问题范围：
  - 本机服务未监听
  - 本机到对端不通
  - 对端到本机不通
  - DNS 解析异常
- 常用命令：
  - ip addr
  - ip route
  - ss -lntp
  - ping
  - traceroute
  - curl
  - telnet / nc
  - dig / nslookup
- 还要看：
  - 防火墙规则
  - 安全组
  - 路由配置
  - 服务监听地址
易错点
- 一上来就 ping，但很多服务问题和 ICMP 无关。
- 只看端口是否监听，不看监听在 127.0.0.1 还是 0.0.0.0。
- 忽略 DNS 解析问题。
深挖点
- ss 和 netstat 的区别。
- 三次握手过程中，在哪一步失败会出现什么现象。
- K8s 中 Pod 能通、Service 不通可能涉及哪些组件。

Q8. TIME_WAIT 和 CLOSE_WAIT 分别是什么？出现很多该怎么办？

核心要点
- TIME_WAIT：
  - 主动关闭连接的一方进入
  - 主要为了保证最后 ACK 可重传、避免旧报文影响新连接
- CLOSE_WAIT：
  - 被动关闭一方收到 FIN 后进入
  - 通常说明应用层没有及时调用 close
- 查看方式：
  - ss -ant | grep TIME-WAIT
  - ss -ant | grep CLOSE-WAIT
易错点
- 看到 TIME_WAIT 多就认为一定异常。
- 把 CLOSE_WAIT 当成内核参数问题，实际上更多是应用未正确关闭连接。
深挖点
- 为什么短连接服务容易出现大量 TIME_WAIT。
- 哪些内核参数可优化，但为什么不能乱改。
- 在高并发网关、Ingress、Nginx 场景下如何理解连接状态。

Q9. Linux 权限模型是怎样的？chmod 755 和 644 分别表示什么？

核心要点
- Linux 基本权限分为：
  - r 读
  - w 写
  - x 执行
- 权限对象分为：
  - u 所有者
  - g 所属组
  - o 其他人
- 755 表示：
  - 所有者：读写执行
  - 组：读执行
  - 其他人：读执行
- 644 表示：
  - 所有者：读写
  - 组：只读
  - 其他人：只读
易错点
- 误以为目录的 w 就够了，实际上目录操作通常还依赖 x。
- 文件和目录权限的语义混淆。
- 给脚本加了 x 仍不能执行，却忽略了解释器或挂载参数问题。
深挖点
- 目录的 r、w、x 分别意味着什么。
- setuid、setgid、sticky bit 的作用。
- 为什么 /tmp 通常是 1777。

Q10. systemd 常用管理命令有哪些？服务启动失败怎么排查？

核心要点
- 常用命令：
  - systemctl status <service>
  - systemctl start/stop/restart <service>
  - systemctl enable/disable <service>
  - journalctl -u <service>
- 排查服务失败：
  - 看 unit 状态
  - 看日志
  - 看配置文件是否正确
  - 看依赖服务是否就绪
  - 看端口、权限、路径是否正确
易错点
- 只重启服务，不先看日志。
- 改完 unit 文件后忘记：
  - systemctl daemon-reload
- 把应用报错当成 systemd 问题。
深挖点
- unit 文件中常见字段：
  - ExecStart
  - Restart
  - After
  - WantedBy
- journalctl 如何按时间、服务过滤日志。
- 在 K8s 节点上如何查看 kubelet 的 systemd 状态与日志。

Q11. 常见 Linux 日志分析命令有哪些？如何快速定位错误日志？

核心要点
- 常用命令：
  - tail -f
  - less
  - grep
  - awk
  - sed
  - sort
  - uniq
  - wc
- 常见组合：
  - grep -i error app.log | tail -n 50
  - awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
- 分析日志时关注：
  - 时间范围
  - 错误关键字
  - 请求链路
  - 异常频率
易错点
- 全量 cat 大日志，效率低且容易卡终端。
- 不限定时间窗口，导致误判旧日志。
- 日志关键词检索不结合上下文。
深挖点
- 如何分析 Nginx access log 中的热点 IP、慢请求。
- 如何在日志中定位某个 Pod / 容器异常。
- 为什么结构化日志更利于自动化运维。

Q12. 你如何理解“Linux 排障思路”？遇到线上问题的通用方法是什么？

核心要点
- 通用排障顺序通常是：
  - 先确认现象
  - 再界定范围
  - 再收集证据
  - 再定位根因
  - 最后验证修复
- 常从几个维度切入：
  - CPU
  - 内存
  - 磁盘
  - 网络
  - 进程
  - 日志
- 要有“对比”意识：
  - 当前 vs 历史
  - 异常机器 vs 正常机器
  - 业务变更前 vs 变更后
易错点
- 凭经验直接重启，没保留现场。
- 没确认影响范围就盲目操作。
- 只盯一个指标，不做交叉验证。
深挖点
- K8s 节点异常时，如何区分是：
  - 容器问题
  - kubelet 问题
  - 节点 OS 问题
  - 存储/网络基础设施问题
- 如何沉淀成 SOP 和巡检项。
- 如何把 Linux 排障经验映射到 Kubernetes 运维。

速记笔记

load average 不是 CPU 使用率，D 状态进程会拉高 load。
CPU 排查：top → pidstat / top -Hp → perf / strace。
内存重点看 available，不是只看 free。
OOM 先查：dmesg、journalctl -k。
磁盘排查：df -h 看整体，du -sh 看目录，lsof | grep deleted 看幽灵文件。
空间没满但不能写，记得查 inode：df -i。
网络排查顺序：IP、路由、DNS、监听端口、防火墙、链路连通性。
TIME_WAIT 多不一定异常，CLOSE_WAIT 多更像应用未正确关闭连接。
权限题高频：755、644、目录权限、1777、sudo。
systemd 高频命令：systemctl status、journalctl -u。
日志分析核心：限定时间范围、抓关键字、做上下文关联。
面试回答要体现：现象判断 + 命令工具 + 根因分析 + 处理方案。