运维面试高频10题

Q01

Linux 系统负载高，如何排查？

Linux性能

+

排查步骤

# 第一步：看整体负载和 CPU 使用率
top -bn1 | head -20

# 第二步：看是 CPU 密集还是 IO 密集
# us 高 → CPU 密集；wa 高 → IO 等待
iostat -x 1 3

# 第三步：找出占用最高的进程
ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10

# 第四步：定位具体线程（拿到 pid 后）
top -Hp <pid>         # 看线程级别
strace -p <pid>       # 看系统调用

# 第五步：查磁盘 IO
iotop -o              # 找 IO 高的进程
df -h && du -sh /*    # 看磁盘空间

面试结论

      load average 超过 CPU 核数说明有排队。wa% 高 → IO 瓶颈，先看 iotop；us% 高 → CPU 密集，先看 top/ps。记住这个判断分支，面试官最爱问。
    

Q02

TCP 三次握手 / 四次挥手，TIME_WAIT 为什么要等 2MSL？

网络TCP

+

核心流程

三次握手：Client SYN → Server SYN+ACK → Client ACK（建立连接）
四次挥手：Client FIN → Server ACK → Server FIN → Client ACK（断开连接）

TIME_WAIT 等 2MSL 的原因

原因1：确保最后一个 ACK 被对端收到。若 ACK 丢失，Server 会重发 FIN，Client 需要在 2MSL 内还能响应。
原因2：让旧连接的报文在网络中彻底消亡，防止新连接收到上一个连接的"幽灵包"。

运维场景

# 查看大量 TIME_WAIT（高并发短连接场景常见）
ss -ant | awk '{print $1}' | sort | uniq -c

# 调整内核参数加速复用（生产谨慎）
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle  # 不推荐，NAT 环境有坑

Q03

Docker 容器和虚拟机的区别？Docker 的隔离原理？

Docker容器

+

核心区别

VM：有独立 OS 内核，靠 Hypervisor 隔离，重量级（GB 级镜像，秒级启动）
容器：共享宿主机内核，靠 Namespace + Cgroup 隔离，轻量（MB 级，毫秒级启动）

Docker 隔离原理（两个核心）

Namespace：隔离视图。pid/net/mnt/uts/ipc/user 六种 namespace，让容器"看不见"其他容器的进程、网络、文件系统。
Cgroup：限制资源。CPU、内存、IO 用量上限，防止一个容器把宿主机资源耗尽。

文件系统

# OverlayFS 分层：镜像层只读，容器层可写
# 查看挂载
mount | grep overlay

# 容器里的改动只在 upperdir，不影响镜像
ls /var/lib/docker/overlay2/

Q04

Nginx 502 和 504 的区别，各自如何排查？

Nginx排错

+

本质区别

502 Bad Gateway：后端返回了响应，但响应无效（后端挂了/崩了/返回非法内容）
504 Gateway Timeout：后端没在规定时间内返回（超时，后端慢或卡死）

排查命令

# 看 Nginx 错误日志（最直接）
tail -f /var/log/nginx/error.log

# 502 排查：后端服务是否存活
systemctl status php-fpm          # PHP 场景
curl -I http://127.0.0.1:9000     # 直接测后端端口

# 504 排查：调大超时参数（临时验证）
# nginx.conf 里加：
proxy_read_timeout 120s;          # 等待后端响应的超时
proxy_connect_timeout 10s;        # 连接后端的超时

      口诀：502 是后端死了，504 是后端太慢。先看日志，再看后端进程，最后看超时配置。
    

Q05

MySQL 主从复制原理，以及主从延迟如何排查和解决？

MySQL主从

+

复制原理（3个线程）

主库：binlog dump 线程 → 读 binlog 发给从库
从库：IO 线程 → 接收 binlog 写入 relay log
从库：SQL 线程 → 重放 relay log 执行 SQL

排查延迟

-- 在从库执行，看关键字段
SHOW SLAVE STATUS\G

-- 重点看：
-- Seconds_Behind_Master: 42   ← 延迟秒数，0 为正常
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Last_Error: 有报错说明 SQL 线程卡了

解决方案

短期延迟：从库机器 IO/CPU 资源不足，升配或减少从库压力
大事务：主库避免大批量操作，拆小事务
根本解法：开启并行复制（MySQL 5.7+ 默认支持）

# my.cnf 开启并行复制
slave_parallel_workers = 4        # 4个并行线程
slave_parallel_type = LOGICAL_CLOCK

Q06

Redis 缓存穿透、缓存击穿、缓存雪崩的区别和解决方案？

Redis缓存

+

三者区别

穿透：查询根本不存在的 key（如 id=-1），缓存和DB都没有，每次都打到DB
击穿：某个热点 key 过期的瞬间，大量并发同时打到 DB
雪崩：大批 key 同时过期，或 Redis 宕机，流量全部涌入 DB

解决方案

穿透：① 布隆过滤器（不存在的直接拦截）；② 查到空值也缓存（ttl 设短，如60s）
击穿：① 互斥锁（只让一个请求回源，其他等待）；② 热点key不设过期（手动更新）
雪崩：① 过期时间加随机值（base_ttl + random(300)）；② Redis 集群保高可用；③ 限流降级

      记忆口诀：穿透查不到、击穿一个key、雪崩大批key。面试必考，三个场景要能清晰区分。
    

Q07

Kubernetes Pod 一直处于 Pending 状态，如何排查？

Kubernetes排错

+

排查套路

# 第一步：看 Events（最重要）
kubectl describe pod <pod-name> -n <ns>
# 重点看最下面的 Events 段

# 第二步：常见 Pending 原因分类
# 1. 资源不足
#    Events: 0/3 nodes are available: 3 Insufficient cpu
kubectl top nodes

# 2. 节点有污点，Pod 没有容忍
#    Events: node(s) had untolerated taint
kubectl describe nodes | grep Taints

# 3. PVC 未绑定，等待存储
kubectl get pvc -n <ns>

# 4. 镜像拉取问题（会从 Pending 变 ImagePullBackOff）
kubectl get events --sort-by='.lastTimestamp'

快速定位

看 describe pod 的 Events → 找 FailedScheduling
看 Reason 字段：资源不足 / 亲和性冲突 / 污点不容忍 / PVC 未绑定

Q08

CI/CD 流程是怎样的？Jenkins Pipeline 核心阶段？

JenkinsCI/CD

+

标准流程

代码提交 → 触发构建 → 代码检查 → 单元测试 → 构建镜像 → 推送镜像仓库 → 部署到 K8s → 通知结果

Jenkinsfile 示例结构

pipeline {
  agent any
  stages {
    stage('拉代码') {
      steps { git url: 'git@github.com:...', branch: 'main' }
    }
    stage('构建镜像') {
      steps {
        sh 'docker build -t harbor.xx.com/app:${BUILD_NUMBER} .'
        sh 'docker push harbor.xx.com/app:${BUILD_NUMBER}'
      }
    }
    stage('部署 K8s') {
      steps {
        // 替换 yaml 里的镜像 tag 再 apply
        sh 'sed -i "s/IMAGE_TAG/${BUILD_NUMBER}/" deploy.yaml'
        sh 'kubectl apply -f deploy.yaml'
      }
    }
  }
  post {
    failure { sh '发送钉钉告警' }
  }
}

      面试加分：说出你实际遇到的问题，比如 imagePullSecrets 配置、Harbor 证书信任、no_proxy 导致 kubectl 失败等具体案例。
    

Q09

Prometheus 监控体系是怎样设计的？告警如何配置？

Prometheus监控

+

整体架构

采集层：node_exporter（主机）/ cAdvisor（容器）/ mysqld_exporter / 自定义 exporter
存储层：Prometheus Server（本地TSDB）
告警层：Alertmanager（分组、抑制、路由到钉钉/邮件）
展示层：Grafana（导入社区 Dashboard）

告警规则示例

# rules/node_alert.yml
groups:
- name: node_alerts
  rules:
  - alert: HighCpuUsage
    # CPU 使用率超过 80% 持续 2 分钟触发
    expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{ $labels.instance }} CPU 使用率过高"
      description: "当前值: {{ $value }}%"

Alertmanager 路由

# 按 severity 路由到不同接收器
route:
  receiver: 'default'
  routes:
  - match:
      severity: critical
    receiver: 'oncall-dingtalk'  # 紧急告警打钉钉

Q10

线上服务内存泄漏，如何定位并处理？

Linux故障处理

+

判断是否内存泄漏

# 观察内存随时间持续增长（不回落）
watch -n 5 'free -h && ps aux --sort=-%mem | head -5'

# 查看具体进程内存变化
pidstat -r -p <pid> 5   # 每5秒输出一次

定位步骤

① 确认是哪个进程持续增长内存（top 按 M 排序）
② Java 程序：jmap -heap <pid> 看堆内存；jstat -gcutil <pid> 看 GC
③ C/C++ 程序：valgrind 或 tcmalloc heap profiler
④ 容器场景：看 OOMKilled 事件 → kubectl describe pod

紧急处理

# 线上紧急：重启服务（先保留现场）
# 先 dump 内存快照（Java）
jmap -dump:format=b,file=/tmp/heap.hprof <pid>

# 然后重启，恢复服务
systemctl restart <service>
# 或 K8s 场景
kubectl rollout restart deployment/<name>

# 长期方案：设置容器内存 limit + request，OOM 自动重启
# resources.limits.memory: 512Mi

      面试要点：说"先保留现场再重启"体现专业性。dump → 重启 → 事后分析，这个顺序要答出来。
    

运维面试 高频10题

运维面试高频10题