20260704面试题

# 服务器磁盘突然报警使用率 95%，你如何快速定位占用空间的来源并处理？

这是故障排查类题目，用 SARC 框架 回答：

S 状况：一句话定性现象和影响
A 分析：排查路径，用哪些命令定位
R 解决：具体清理操作，短期止血 + 长期预防
C 复盘：监控和预防改进

磁盘 95% 告警，先跑 df -h 确认哪个分区，再用 du -sh /* | sort -rh 找占用最大的目录。

定位到 /var/log 下应用日志暴增，今日日志比昨日大 10 倍，确认是异常写入。

止血：清理 7 天前日志，活跃日志用 > app.log 截断不能直接 rm；同时跑 lsof | grep deleted 检查有无已删除未释放文件，有的话重启对应进程。

长期：调日志级别为 Warning，配置 logrotate 自动轮转，磁盘 80% 触发告警。

1
2
3
4
5
6
7

# Linux 服务器 CPU 负载持续飙高，load average 达到 20+，如何排查？

这是故障排查类题目，用 SARC 框架 回答：

S 状况：一句话定性现象，区分 CPU 使用率高 vs 负载高
A 分析：排查路径 + 具体命令
R 解决：针对不同根因的处理
C 复盘：监控和预防

Load average 20+ 不一定是 CPU 忙，先看 top 里 %wa——I/O wait 高说明进程在等磁盘，不是计算瓶颈。

跑 vmstat 1 确认 wa 列持续 > 30%，再用 ps aux | awk '$8=="D"' 找卡在 I/O 等待的进程，iostat -x 1 定位是哪块磁盘打满。

我遇到的根因是日志疯狂写入把磁盘 I/O 打满，调低日志级别后 wa 降到 2%，load average 恢复正常。

复盘：对 I/O wait 超 30% 和 load average 超 CPU 核数配告警。

1
2
3
4
5
6
7

# 服务器出现大量 `TIME_WAIT` 连接，导致端口耗尽，如何排查和处理？

这是故障排查类题目，用 SARC 框架 回答：

S 状况：一句话说清 TIME_WAIT 是什么现象，影响是什么
A 分析：用哪些命令确认问题，根因是什么
R 解决：内核参数调整 + 应用层优化
C 复盘：监控和预防

大量 TIME_WAIT 说明服务在频繁建立短连接，主动关闭方进入 60 秒等待期，端口耗尽后新连接无法建立。

用 netstat -an | grep TIME_WAIT | wc -l 确认数量，ss -s 看端口使用总览。

短期：调内核参数——tcp_tw_reuse=1 允许复用，ip_local_port_range 扩到 1024-65535，tcp_fin_timeout 改 30 秒。

长期：应用层改用连接池，避免短连接频繁建立，这才是根治。

复盘：对 TIME_WAIT 超 2 万条配告警，同时检查所有服务是否开启 HTTP Keep-Alive。

1
2
3
4
5
6
7
8
9

# 线上服务突然出现大量 502 错误，如何排查？

这是故障排查类题目，用 SARC 框架 回答：

S 状况：一句话定性 502 的本质和影响范围
A 分析：从网关到后端逐层排查，具体命令
R 解决：针对不同根因的处理
C 复盘：监控和预防

502 是网关无法连通上游服务，先判断是刚发布导致还是突发故障。

看 Ingress 日志确认错误类型——connection refused 是 Pod 没起来，upstream timeout 是 Pod 响应慢；kubectl get endpoints 确认后端是否有健康实例。

有最近发布立即 kubectl rollout undo 回滚；Pod 全崩就看 kubectl describe pod 找原因；连接数打满就临时扩容。

复盘：对 502 错误率超 1% 配告警，Readiness Probe 加严保证不健康 Pod 不接流量。

1
2
3
4
5
6
7

# 服务器某个端口不通，如何排查是防火墙、进程、还是网络问题？

端口不通先分层：进程层、防火墙层、网络层逐一排除。

先跑 ss -tlnp | grep <port> 确认进程是否监听——监听在 127.0.0.1 就改成 0.0.0.0；端口不存在就查应用日志。

进程正常就查防火墙：iptables -L -n | grep <port>，规则没放行就加规则。

还不通就到网络层：tcpdump 抓包确认流量是否到达，排查云平台安全组或路由问题。

我遇到的是监听地址是 127.0.0.1，改成 0.0.0.0 后远程访问正常。

复盘：核心端口加拨测监控，30 秒探测一次。

1
2
3
4
5
6
7
8
9
10
11

# Linux 系统中某个进程 CPU 占用 100%，如何定位是哪段代码造成的？

单进程 CPU 100%，说明有线程陷入死循环或大量计算，需要定位到具体代码行。

先 top 找到 PID，再 top -H -p <pid> 找 CPU 最高的线程 TID，printf "%x" 转十六进制，最后 jstack <pid> | grep <hex> 找到堆栈——定位到是定时任务里一个递归调用没有终止条件。

修复递归逻辑加上终止条件，重新发布后 CPU 恢复正常。

复盘：对 CPU 持续超 80% 配告警，定时任务加超时熔断。

1
2
3
4
5
6
7

# DNS 解析故障，服务之间突然无法通过域名访问，如何排查？

服务间域名不通，先区分是内部域名（svc 发现）还是外部域名失败。

内部：kubectl exec 进 Pod 跑 nslookup kubernetes.default，失败说明 CoreDNS 有问题；查 CoreDNS Pod 状态和日志，检查 NetworkPolicy 是否放行了 53 端口。

外部：cat /etc/resolv.conf 确认 DNS 服务器配置，dig @8.8.8.8 domain 绕过本地 DNS 测试连通性。

我遇到的是 NetworkPolicy 没放行 53 端口导致 CoreDNS 不可达，加规则后立即恢复。

复盘：CoreDNS Pod 加健康监控，NetworkPolicy 模板默认放行 53 端口。

1
2
3
4
5
6
7
8
9

# 你们是如何做线上变更管控的？发布上线前有哪些卡点？

我们变更管控分三层：流水线自动卡点、人工审批、发布后验证。

自动卡点：代码扫描 + 单测覆盖率 > 80% + 镜像无 Critical 漏洞；人工卡点：测试验收通过 + 技术负责人审批 + 确认回滚方案；发布采用灰度，先放 10% 流量观察 5 分钟，无异常再全量。

卡点拦截过真实问题：权限 SQL 漏提交导致功能按钮消失，测试环节发现后补上才上线。

踩过的坑：发布后没有盯监控，问题 10 分钟后才发现，现在要求发布后必须观察 15 分钟再离岗。

1
2
3
4
5
6
7

# 什么是蓝绿部署和金丝雀发布？有什么区别？你们用的哪种？

蓝绿发布需要准备两套环境，金丝雀发布期间新旧版本同时运行，只是新版本只接少量流量——本质上还是两个版本并存，只是不需要像蓝绿那样完全独立的两套基础设施。
。
蓝绿发布是全量切换流量，金丝雀是局部或者某个地区先试运行一段时间再全部切换流量。
蓝绿发布后发布中断从平均 3 分钟降到 0，但资源成本翻倍，后来核心服务用蓝绿，普通服务改金丝雀节省成本。
在切换流量过程中应该核对清楚每套环境对外的网关ip，防止切换失误。

1
2
3
4
5