20 题总结篇——三板斧 / 难度分级 / 面试通关路线图
到这一篇为止，Linux 面试通关手册的 20 道题全部讲完。从第 1 篇'日志文件 50G 怎么 10 分钟定位'到第 19 篇'OOM killer 为什么总是杀错进程'，每一题背后都是我或身边同事踩过的真实坑——没有教科书、没有面经抄袭，只有生产现场的故事和凌晨 3 点被叫起来排障的回忆。
这一篇不讲新题，而是做一件更重要的事：把 20 题的知识体系串成一张地图，标出每道题的难度、面试考察重点、以及我的'三板斧'排障心法。看完这一篇，你下一次被叫起来排障，应该知道大脑里第一反应该是什么。
20 题全览 & 难度分级
| # | 题目主题 | 难度 | 出现频率 | 区分力 |
|---|---|---|---|---|
| 01 | 50G 日志 10 分钟定位 | ★★☆ | 高 | 强 |
| 02 | top → top -H → jstack 链路 | ★★★ | 高 | 极强 |
| 03 | free -h 内存误读 | ★★☆ | 高 | 强 |
| 04 | inode & deleted files | ★★★ | 中 | 极强 |
| 05 | No space left on device | ★★☆ | 高 | 强 |
| 06 | top %CPU 780% 怎么读 | ★★★ | 中 | 极强 |
| 07 | D 状态线程 kill -9 打不掉 | ★★★★ | 中 | 极强 |
| 08 | Kafka connection refused 排查 | ★★★ | 高 | 强 |
| 09 | CLOSE_WAIT vs TIME_WAIT | ★★★ | 高 | 极强 |
| 10 | iostat %util 100% 找凶手 | ★★★ | 中 | 强 |
| 11 | Shell 防崩三件套 | ★★☆ | 高 | 强 |
| 12 | grep 30G 日志 OOM | ★★☆ | 中 | 中 |
| 13 | chmod -R 777 权限惨案 | ★★★ | 低 | 强 |
| 14 | cron 5 连坑 | ★★☆ | 高 | 中 |
| 15 | ssh 登录卡 30 秒 | ★★☆ | 中 | 中 |
| 16 | load 200 但 CPU 不高 | ★★★ | 中 | 极强 |
| 17 | vmstat si/so swap 抖动 | ★★★ | 中 | 强 |
| 18 | sysctl 10 参数调优 | ★★★ | 中 | 强 |
| 19 | OOM killer 杀错进程 | ★★★★ | 中 | 极强 |
| 20 | 系列总结 / 面试路线 | — | — | — |
难度读法：★★ 是初级（能看懂 top/free/df 即可）；★★★ 是中级（需要理解原理和链路）；★★★★ 是进阶（需要有真实事故经验）。出现频率指的是我在大数据岗面试里观察到的被问概率。区分力指的是'答得好'和'答不上来'的候选人差距大不大。
Wood 的 Linux 排障三板斧
20 道题背后，其实只有三个稳定可靠的'排障姿势'。凌晨被叫起来不管碰到什么，先按这三板斧走一遍，80% 的问题能在 10 分钟内定位到大方向：
第一板斧：先量体温。永远先跑这四条命令，花 60 秒扫一遍整机状态——uptime（load + 时长）、vmstat 1 5（CPU/IO/swap 趋势）、free -h（内存）、df -h（磁盘）。四条命令跑完，你对机器处于什么'病状'就有 60% 把握了：load 高但 CPU 低是 IO 病；free 低 swpd 高是内存病；df 满了是磁盘病。
第二板斧：定位病灶。知道大方向后，用专用工具往下钻。CPU 类用 top -H -p
第三板斧：止血 + 长期方案。定位根因不等于恢复，生产上'恢复'永远是第一优先。止血动作通常是'重启受影响进程 + 扩容/切流量/降级'，先让业务回来，再做根因分析。事后必写'防复发方案'——监控告警、sysctl 调参、脚本加保险、容量规划。没有防复发方案的事故复盘是零分答卷，因为同样的坑你还会再踩。
面试通关：不同阶段的准备策略
阶段一：1-3 年（大厂初面 / 小厂通用）
必会：01 (日志)、03 (free)、05 (No space)、11 (Shell 三件套)
必会：14 (cron)、15 (ssh 基础)
能说出具体命令，能讲一个小故事即可过关
阶段二：3-5 年（中大厂正式面 / 高级开发）
加上：02 (jstack 链路)、04 (inode/deleted)、08 (网络排查)
加上：09 (CLOSE_WAIT/TIME_WAIT)、12 (awk 哈希聚合)
要能讲真实故事、要能说 trade-off、要能对比不同方案
阶段三：5+ 年（资深 / 架构 / SRE）
加上：06 (%CPU 780%)、07 (D 状态)、10 (iostat)
加上：16 (load 原理)、17 (swap)、18 (sysctl)、19 (OOM)
要能从内核机制讲起，要能讲跨系统联动
要有完整的'事故处理 SOP'故事
阶段四：技术 Leader / 面试官
以上全部，外加：
- 能在 3 分钟内判断候选人是'见过'还是'背过'
- 能提炼出自己团队的排障规范和防复发体系
- 能把事故故事化成长期能力建设的推动力最常被忽略的 5 条'生产生存建议'
建议一：凡事先开 tmux / screen。SSH 上机第一件事 tmux new -s
建议二：日志比 metric 更值得信任。Grafana 监控能告诉你'哪里有问题'，但真正定位问题的永远是日志。生产机上建立'日志习惯'——所有脚本输出重定向到 /data/logs，所有服务日志结构化，所有 cron 任务必带 log。监控告诉你'病了'，日志告诉你'怎么病的'。
建议三：灭火时留一条命。永远不要改最后一个正常的生产节点。负载均衡后面 10 台机器坏了 9 台，最后 1 台千万别重启——留着它继续扛业务，你的精力用来把坏的 9 台救回来。'改最后一台'的冲动是所有事故的放大器。
建议四：复盘没有'防复发方案'就没完。每次事故处理完之后，'怎么避免再发生'必须作为交付物。这可能是 sysctl 一行、cron 一个监控脚本、systemd 一个 OOMScoreAdjust——但必须落到代码/配置/流程，而不是停留在'大家下次注意'的口号。口号只能让人内疚，代码才能让人不再犯。
建议五：把能力沉淀成工具。你排查过 10 次类似问题之后，就该写一个脚本把这 10 次的经验固化下来。我那些 check_d_state.sh / safe-run / log-query 都是这么来的——每次事故后多写一个小工具，半年后你就是团队里'出事找他最快能定位'的那个人。这才是'9 年老兵'和'9 年工龄'的区别。