DevOps实习生面试宝典 - 第3节
第3章 Linux与网络技术深度：高频命令、文件系统、网络故障排查、面试考察点
本章聚焦 DevOps 实习生最常被问到的 Linux 和网络基础。面试官通过命令熟练度、文件系统理解、网络故障排查思路三个维度评估你的动手能力和底层认知。掌握结构化回答比背命令更关键。
📌 面试问题 1：请描述你会如何排查一台 Linux 服务器的网络不通问题？
| 面试官考察点 | 逻辑排查思维（从链路层到应用层）；常用网络命令熟练度；能否区分“网络不通”的不同场景（丢包、延迟、拒绝连接）。 |
| 回答框架 | 1. 确认本机网络状态（ip a / ifconfig）→ 2. 测试网关连通性（ping 网关）→ 3. 检查 DNS 解析（dig/nslookup）→ 4. 路由跟踪（traceroute）→ 5. 检查目标端口（telnet/ss）→ 6. 查看防火墙/iptables 规则 → 7. 查看系统日志。 |
| 简短示例回答 | 我会先 `ip a` 确认网卡有 IP，再 `ping 8.8.8.8` 测外网，不通则 `ping 网关` 定位。然后用 `dig` 检查 DNS，`traceroute` 看路由跳转，最后 `ss -tlnp` 和 `iptables -L` 检查端口与防火墙。整个过程从底层到顶层逐步缩小范围。 |
| 可能追问 | ① 如果 ping 通但业务端口不通，你会怎么排查？② 如何判断是网络丢包还是应用层故障？③ 你用过 mtr 吗？它的优势是什么？ |
| ⚠️ 避坑提醒 | 避免直接背诵命令列表而不讲逻辑顺序；不要只说 “ping、traceroute” 而不说明判断条件；注意 `ping` 不通时先确认是否禁止 ICMP。 |
📌 面试问题 2：Linux 下 `df -h` 和 `du -sh` 的区别是什么？什么时候用它们？
| 面试官考察点 | 文件系统视图理解；命令差异理解（磁盘块 vs 文件内容）；能否根据场景选择正确命令。 |
| 回答框架 | 1. 描述 df 看分区已用/可用，基于文件系统超级块（显示的是已分配块数）→ 2. du 计算实际文件占用大小，遍历目录统计 → 3. 当磁盘报警但 du 统计总和小于 df 时，说明有已删除但未释放文件的进程（lsof | grep deleted）→ 4. 举例：排查 /tmp 目录空间。 |
| 简短示例回答 | `df -h` 查看分区总容量和可用量，适合快速判断磁盘是否满。`du -sh *` 计算当前目录下各文件/目录实际大小，用于找大文件。有一次磁盘报警但 `du` 总和小于 `df`，我用 `lsof +L1` 找到删除但未释放的日志文件，kill 进程后空间恢复。 |
| 可能追问 | ① inode 满了怎么处理？ ② 什么是硬链接和软链接？对 df/du 结果有影响吗？ ③ 如何监控某个目录的实时写入？ |
| ⚠️ 避坑提醒 | 不要混淆“分区大小”和“文件大小”；回答时明确说明 `df` 显示的是块设备视角，`du` 是文件系统视角。 |
📌 面试问题 3：你用过哪些 Linux 性能排查命令？请举例说明一次排查 CPU 高负载的经历。
| 面试官考察点 | 常用性能命令熟练度（top、htop、vmstat、iostat、perf）；关联分析能力；能否区分 CPU 使用率高 vs I/O 等待高。 |
| 回答框架 | 1. `top` 看整体负载和占用 CPU 的进程 PID → 2. `top -Hp PID` 看线程级 → 3. `strace -p PID` 跟踪系统调用（定位频繁 syscall）→ 4. 如果是 Java 进程，用 `jstack` 打印堆栈 → 5. 结合 `vmstat 1` 看上下文切换和中断 → 6. 如果是 I/O 等待高，换 `iostat -x 1`。 |
| 简短示例回答 | 曾遇到一个 Java 服务 CPU 持续 90%，先 `top` 找到进程 PID，`top -Hp` 发现多个线程占用高，用 `jstack` 导出堆栈发现某接口循环写入日志。优化后 CPU 降至 10%。平时排查还会用 `vmstat` 看上下文切换，`strace` 追踪系统调用。 |
| 可能追问 | ① 如何判断是 CPU 瓶颈还是锁竞争？ ② perf 的采样原理是什么？ ③ 遇到 CPU 空闲但系统慢怎么排查？ |
| ⚠️ 避坑提醒 | 不要只说 “用 top 看”，必须给出具体字段（us/sy/id/wa）；注意区分用户态 CPU 和内核态 CPU；I/O 等待高时不要误判为 CPU 问题。 |
📁 项目案例：基于 Nginx + Flask 的日志收集系统部署与调优
| 项目名称 | 内网日志实时收集与可视化平台 |
| 业务背景 | 运维团队需要统一收集 200+ 台后端服务器的访问日志和错误日志，实时分析异常并生成报表。前期使用 rsyslog 直接写盘，查询慢且无告警。 |
| 规模指标 | 日均处理日志 500GB；峰值 TPS 约 8000；部署节点数：1 台收集服务器 + 5 台 Filebeat 客户端；总数据量 2TB+。 |
| 技术栈 | Linux (CentOS7) + Nginx (反向代理) + Flask (日志处理 API) + Redis (缓冲) + Filebeat (采集) + Logstash (过滤) + Elasticsearch (存储) + Kibana (展示)。 |
| 核心难点 | ① 海量写入导致 Nginx 连接数打满，需调优 worker_connections 和 keepalive；② Filebeat 在部分旧服务器上因 inotify 限制无法监控文件变更，改用 backoff 轮询；③ 日志格式不统一，使用 Logstash 的 grok 模式多次调整正则。 |
| 面试高频追问 | ① Nginx 的 worker_processes 和 worker_connections 如何计算？② 如果日志写入突然暴涨，你会怎么限流？③ Filebeat 和 Logstash 的区别？什么时候不用 Logstash？④ Elasticsearch 的索引分片如何设置？ |
| 可迁移回答话术 | “当时我通过 `ulimit -n` 先确认系统最大文件句柄数，再同步调整 Nginx 的 `worker_rlimit_nofile` 和 `worker_connections`。对于日志格式解析，我先把常见日志样本导出，用 Logstash 的 grok 调试器逐个验证，最后合并为多个 match 分支，处理效率提升 30%。” |
💡 面试提示： 项目案例中提到的 `ulimit`、`worker_connections`、`grok` 都是 DevOps 面试高频考点。建议你亲手在虚拟机中搭建一次 ELK + Nginx 的小型实验，加深对参数变化的理解。
📚
核心命令速查表（本章涉及）
| 命令 | 用途 | 常用参数 |
|---|
| ping | 测试连通性与延迟 | -c 4, -i 0.5 |
| traceroute | 路由跳数探测 | -n (不解析主机名) |
| ss | 查看 socket 统计 | -tlnp (TCP、listen、numeric、pid) |
| df -h | 查看分区使用量 | -i (inode) |
| du -sh | 查看目录实际大小 | --max-depth=1 |
| top | 进程实时监控 | -H (线程模式), -bn1 (批处理) |
| strace | 跟踪系统调用 | -p PID, -c (统计) |