Linux 运维工程师面试题整理

整理日期：2026-10-24
共 32 题，覆盖：Linux 基础、网络、Nginx、Docker、监控自动化、故障排查、架构存储、HR 综合
标注说明：⭐ 掌握较好 ｜ ⚠️ 薄弱需重点复习 ｜ ❌ 易错点（已纠正）

一、网络与协议

1. 正向代理 vs 反向代理 ⭐

  • 正向代理：替客户端去访问外网资源，服务端不知道真实客户端是谁，如科学上网代理。
  • 反向代理：替后端服务接收用户请求，用户不知道背后真实的后端服务，由代理分发请求。
  • 项目例子：Nginx Proxy Manager 就是反向代理，用户访问域名，不知道后面跑的是哪个容器。

2. TCP 三次握手 ⭐

  1. 第一次：客户端发送 SYN 报文，请求建立连接；
  2. 第二次：服务端收到，回复 SYN+ACK，同意连接并确认收到客户端请求；
  3. 第三次：客户端收到后回复 ACK，确认收到服务端报文，连接建立。
    - 目的：同步双方序列号，保证双向收发正常（TCP 是全双工协议）。
    - ❌ 易错点：不要说成浏览器专属，TCP 是传输层协议，不只是浏览器在用。

3. iptables filter 表的三个链 ⭐

  • INPUT：处理进入本机的数据包（别人访问这台服务器）。
  • OUTPUT：处理从本机发出去的数据包（服务器向外发起请求）。
  • FORWARD：处理经过本机转发的数据包（本机既不是源也不是目标，只是转发，如服务器当路由器、容器跨主机转发）。
  • 口诀：进本机、出本机、路过本机。

二、Linux 基础

4. $? 是什么 ⭐

  • 代表上一条命令的退出状态码（不是输出内容）。
  • 0 表示执行成功，非 0 表示失败。
  • 用途：脚本里通过它判断命令是否正常，再决定是否输出告警。

5. 进程与线程 ⭐

  • 进程：程序运行起来后的独立实例，拥有独立的内存空间、文件描述符等资源，进程间相互隔离。
  • 线程：进程内部的执行单元，同一进程内多个线程共享进程资源（内存、文件句柄），线程本身只有少量栈资源。
  • 结论：进程是资源分配的最小单位，线程是 CPU 调度的最小单位。

6. 软链接与硬链接 ⭐

  • 硬链接：多个文件名对应同一个 inode，指向磁盘上同一份数据。删除源文件只是链接计数减一，只要还有硬链接，数据不丢失；不能跨分区、不能链接目录。
  • 软链接（符号链接）：是独立文件，里面存的是源文件路径。删除源文件后软链接失效（坏链接）；支持跨分区、可链接目录。

7. 后台运行：& 与 nohup ⭐

  • 后台运行：进程脱离当前终端的前台控制，在后端继续执行，终端可继续输入其他命令。
  • &：把进程放到后台，但仍与当前 shell 关联，关闭终端时进程被 SIGHUP 信号终止。
  • nohup：忽略 SIGHUP 信号，配合 & 使用（nohup 命令 &），关闭终端后进程仍运行，日志默认输出到 nohup.out。
  • 进阶：更可靠可用 setsid 或 systemd 管理。

8. swap 是什么 ⭐

  • swap 是磁盘上划分出来的一块空间，当作虚拟内存。
  • 物理内存不足时，系统把暂时不用的内存数据换到 swap，腾出物理内存给正在运行的程序。
  • 缺点：基于磁盘，速度远慢于物理内存，大量使用会导致系统卡顿、IO 飙升。
  • 定位：swap 只是应急缓冲，不能当物理内存用。

9. Linux 开机流程 ⚠️

  1. BIOS/UEFI 自检（POST）：检查 CPU、内存、硬盘等基本硬件，按启动顺序找启动设备；
  2. 加载引导程序 GRUB：显示菜单，加载内核镜像 vmlinuz 和 initramfs；
  3. 内核启动：接管系统，初始化硬件驱动，挂载根文件系统（/），启动 1 号进程 init；
  4. systemd 接管：按 target 启动各项系统服务和依赖（网络、日志、挂载）；
  5. 进入登录界面：服务启动完毕，用户可登录。
    - 口诀：BIOS 自检 → GRUB 引导 → 内核加载 → systemd 启动服务 → 登录界面。

10. 查看日志常用命令 ⭐

  • dmesg：查看内核日志，OOM、硬件、磁盘异常等内核问题优先看它；
  • journalctl -u 服务名：查看 systemd 托管服务的日志；
  • tail -f：实时跟踪日志；
  • less：分页翻看，搭配 grep 过滤；
  • grep：筛选异常关键字（error、fail）。

11. logrotate 日志轮转 ⭐

  • Linux 自带的日志轮转工具，防止日志持续写占满磁盘。
  • 可按大小或时间（天/周）配置，自动分割、重命名、压缩旧日志，设置保留份数，超出自动删除。
  • 轮转后可通知应用重新加载日志，保证正常输出。
  • ❌ 易错点：防的是磁盘被占满，不是内存。

12. awk 与 sed 的区别 ⭐

  • awk：按列处理文本，擅长字段提取、统计（打印某几列、求和、计数）。
  • sed：按行处理，最常用行内字符串替换，也可做删除、新增、筛选。
  • 口诀：awk 管列和统计，sed 管行和替换。

13. 服务器负载：负载高一定 CPU 繁忙吗 ⭐

  • 负载：排队等待 CPU 调度的进程数量，包含正在运行和等待资源的进程。
  • 负载高 ≠ CPU 繁忙。负载统计还包含等待 IO（磁盘读写）的进程。
  • 典型场景：磁盘 IO 瓶颈，进程卡在等磁盘，us、sy 不高，但 wa（IO 等待）很高，负载数字飙升。
  • 结论：看负载要结合 top 里的 us、sy、wa 一起判断。

14. Linux 安全加固 ⚠️

核心原则：最小权限、最小暴露。
1. 账号权限：日常用普通用户，必要时 sudo；限制 root 直接远程登录；
2. SSH 加固：禁用密码登录改用密钥，改默认 22 端口，限制可登录用户和来源 IP；
3. 端口与防火墙：只开放必需端口，firewalld/iptables 限制访问，关闭无用服务；
4. 系统更新：及时打安全补丁；
5. 访问控制：敏感服务（如数据库）不监听公网，只允许内网访问；
6. 审计监控：登录日志、操作审计，监控异常登录。
- ❌ 易错点：「删除文件前先查看」属于操作习惯，不算加固，应归到「操作前备份、避免误操作」的变更安全意识。

三、Nginx

15. Nginx 403 的原因 ⭐

403 Forbidden：服务器收到请求但拒绝提供访问。
1. 文件/目录权限不足，nginx 运行用户没有读权限；
2. 目录下没有默认首页文件，且配置了禁止目录浏览；
3. 配置里写了 IP 访问控制，当前 IP 被拉黑；
4. SELinux 开启，阻止 nginx 读取网站目录；
5. 防盗链配置拦截了请求。

16. Nginx worker 进程模型，为什么性能好 ⚠️

  • master-worker 架构：master 负责读配置、管理 worker，不处理业务；worker 才真正处理请求。
  • 每个 worker 是单线程，但基于事件驱动、非阻塞 I/O（epoll），一个 worker 可同时监听成千上万连接，靠事件循环异步处理，而不是每连接开一个线程。
  • 高性能原因：多进程充分利用多核 + 单进程内异步非阻塞处理海量连接，对比 Apache 每连接一进程/线程，内存占用和上下文切换开销小得多。
  • 三个关键词：master-worker、epoll、异步非阻塞。

17. 热加载：为什么用 reload 而不是 restart ⭐

  • reload 是平滑重载：master 不重启，重新读配置，启动新 worker 处理新连接；旧 worker 处理完存量连接后优雅退出。整个过程服务不中断、用户无感知。
  • restart 是彻底关闭再启动，会造成短暂服务中断，线上业务不可接受。
  • 结论：reload 优雅重载、连接不断；restart 重启进程、服务中断，线上改配置优先 reload。

四、Docker 与容器

18. 容器启动后立刻退出，排查思路 ⚠️

  1. 优先看容器日志 docker logs 容器名，日志通常直接报程序报错；
  2. 检查启动命令、compose 配置，command、环境变量、挂载路径是否写错；
  3. 确认主进程是否前台运行（前台进程一结束容器就退出）；
  4. 检查权限：挂载目录权限不足、SELinux 限制；
  5. 看服务器资源：内存不够被 OOM 杀掉；
  6. 用 docker run 单独手动启动，脱离 compose 复现问题。
    - 一句话重点：优先看 logs。

19. 镜像与容器的区别 ⭐

  • 镜像：静态模板，打包了程序、依赖、配置、运行环境，只读，不能直接运行。
  • 容器：镜像启动后产生的运行实例，有独立的读写层，是正在运行的进程。
  • 同一个镜像可启动多个独立容器。

20. Docker 镜像分层的好处 ⚠️

  • 镜像是分层存储，每条 Dockerfile 指令生成一层只读层。
  • 好处：
    1. 复用：多个镜像的相同基础层（如 centos/ubuntu）宿主机只存一份，节省磁盘；
    2. 增量拉取：已存在的层不重复下载，提升拉取速度；
    3. 只读安全：镜像本身不可修改，改动只能在容器上层加读写层。
  • 口诀：复用、增量下载、镜像只读安全。

五、监控与自动化

21. Prometheus 监控体系架构 ⭐

  • 核心是 Prometheus Server，通过 pull 模型主动抓取各监控目标暴露的指标，存入自带的时序数据库（TSDB），用 PromQL 查询分析。
  • 组件：
    1. Exporter：被监控端采集器（node_exporter 采主机、mysqld_exporter 采数据库），暴露 /metrics 接口；
    2. Prometheus Server：定时抓取、存储、PromQL 查询；
    3. Alertmanager：触发告警，分组、去重、静默，发送到邮件/钉钉；
    4. Grafana：可视化大盘；
    5. Pushgateway：短任务主动推送指标。
  • 链路：Exporter 采集 → Server 拉取存储 → PromQL 查询 → Alertmanager 告警 → Grafana 展示。
  • 项目：Prometheus + node_exporter + Grafana，采集主机 CPU/内存/磁盘并配告警。

22. 对运维自动化的理解 ⭐

  • 把大量重复、标准化的操作交给脚本或工具执行（巡检、备份、状态检查）。
  • 人工重复操作耗时、易漏检、易误操作。
  • 自动化价值：降低人为失误、提升效率、标准化（多台机器保持一致）。
  • 项目例子：自己写的主机巡检脚本就是自动化的落地实践。

23. Ansible vs Shell 脚本 ⚠️

  • Ansible 是自动化运维工具，无 Agent 架构，通过 SSH 管理多台机器，被控端无需装软件。
  • 与 Shell 的区别：
    1. 幂等性：模块先判断目标状态，已满足就不重复执行；Shell 重复执行易出错；
    2. 标准化模块：装包、改配置、起服务有现成模块，可读性强；
    3. 清单管理：inventory 主机清单分组，YAML 写 playbook，可版本化、复用。
  • ❌ 易错点：Shell 不是只能管理本机，也能通过 SSH 批量执行，但要自己写循环、处理认证和错误，繁琐。

24. 什么是幂等性 ⭐

  • 同一操作执行一次或多次，最终结果相同，不会产生重复数据、重复启动或报错。
  • 系统已是目标状态 → 执行后不变；不是目标状态 → 执行一次就变成目标状态。
  • 例子：useradd tom 非幂等（重复执行报"用户已存在"）；幂等写法先判断再创建。
  • 重要性：自动化任务常失败重试、重复执行，幂等保证重复执行安全、多机状态一致、异常重跑不搞坏系统。

六、故障排查

25. 拿到陌生业务服务器第一步 ⭐

  • 不直接修改任何配置。
  • 先摸清现状：系统版本、内核、CPU/内存/磁盘资源；ss 看监听端口、确认跑了哪些服务；看系统日志、确认备份策略。
  • 优先找运维交接文档，梳理业务链路，搞清服务器用途。
  • 未确认业务影响、未备份前，不做任何变更。

26. 磁盘满了怎么排查 ⭐

  1. df -h 查看磁盘空间使用率，定位哪个分区满；
  2. df -i 看 inode 是否耗尽（空间还有但 inode 用完也无法新建文件）；
  3. du -sh /* 逐级查找大目录，定位日志/备份包/容器数据；
  4. 找到大文件后用 lsof 确认是否仍被进程占用（避免直接删日志但空间不释放）；
  5. 处理：不重要日志清理，重要日志先备份再转移，配置 logrotate 防止再满。

27. CPU 使用率高，如何定位进程 ⚠️

  1. uptime 看负载，判断突发还是持续；
  2. top 看 CPU 构成：us 高查用户进程、sy 高查内核态、wa 高查磁盘 IO；
  3. top 按 P 按 CPU 排序、按 M 按内存排序，定位高占用进程；
  4. top -Hp 进程PID 定位具体哪个线程；
  5. wa 高时 iostat -x 确认磁盘 %util，iotop/pidstat -d 定位高 IO 进程；
  6. 结合应用日志判断进程在做什么（死循环、异常计算、任务堆积）。
    - ❌ 易错点：找磁盘读写用 iostat -x / iotop，不是 df -h（df 看空间占用）。

28. MySQL 突然变慢怎么排查 ⚠️

  1. 系统层：CPU、内存、磁盘 IO（iostat 看 wa）、swap，排除资源瓶颈；
  2. 慢查询日志：开启 slow_query_log，找耗时长的 SQL，看是否没走索引、全表扫描；
  3. 连接与锁：show processlist 看连接堆积、锁等待、死锁；
  4. 缓存与内存：缓存命中率、buffer pool 配置是否合理；
  5. 大事务、主从延迟、binlog 写入压力。
    - 顺序：系统资源 → 慢 SQL → 连接与锁 → 配置参数。

七、架构与存储

29. 什么是高可用，核心服务怎么做高可用 ⚠️

  • 高可用（HA）：通过冗余和自动切换，保证故障时服务依然可用，目标是提升可用性（如 99.9%）。
  • 分层设计：
    1. 应用层：多实例部署 + 负载均衡（Nginx/LVS），一台挂了流量自动切走；
    2. 数据层：数据库主从复制，主库故障自动切换（MHA、MGR），定期备份和灾备；
    3. 监控告警：Prometheus + 告警，健康检查自动剔除故障节点；
    4. 故障演练：定期模拟故障验证切换流程。
  • 核心：消除单点 + 自动切换 + 可监控。

30. RAID 0 / 1 / 5 区别 ⚠️

RAID（磁盘阵列）：把多块硬盘组合成一块逻辑盘，目的是提速或冗余。

类型 原理 优点 缺点
RAID 0 数据条带化，分散写多块盘 读写性能高，容量全用 无冗余，坏一块全丢
RAID 1 两块盘互为镜像，写两份 冗余强，坏一块数据还在 容量减半，成本高
RAID 5 条带 + 分布式校验（至少 3 块盘） 性能与冗余兼顾 坏盘重建期间风险高
  • 选择逻辑：安全优先选 1，性能优先选 0，两者兼顾选 5。

八、HR / 综合类

31. 为什么从 ERP 实施转 Linux 运维 ⭐

  • 做 ERP 驻场实施时经常对接服务器部署、排查系统故障，因此接触到 Linux。
  • 实施更多是固定业务流程，可发挥的技术空间有限；自己对服务器、自动化、故障排查更感兴趣。
  • 后续系统学习 Linux 运维，在云服务器落地了整套容器和监控项目，打算长期深耕。
  • 要点：不是贬低 ERP，而是发现兴趣在系统技术侧，主动选择运维。

32. 项目只是个人实验环境，和生产差距大怎么回答 ⚠️

  1. 承认差距：单台云服务器实验环境，生产有多节点、高可用、安全规范、备份校验、告警收敛、变更流程，这些暂时没实战机会；
  2. 证明可迁移：底层技术原理、排查思路、工具使用是一样的（OOM 排查、Nginx 反代、容器排错、监控采集）；
  3. 体现安全意识：入职后严格遵守变更流程，先备份、先看文档、小范围验证，不随意改线上，跟着团队学习生产规范。
    - 逻辑：承认差距 + 底层能力可迁移 + 体现运维安全意识。

复习优先级（薄弱点）

🔴 重点补：答不上来 / 不完整

  • [ ] 高可用设计（第 29 题）
  • [ ] Linux 开机流程（第 9 题）
  • [ ] RAID 0/1/5（第 30 题）
  • [ ] Docker 镜像分层（第 20 题）

🟡 纠正认知：有小错误

  • [ ] 磁盘 IO 用 iostat -x / iotop，不是 df -h（第 27 题）
  • [ ] MySQL 慢排查顺序：系统资源 → 慢 SQL → 连接锁 → 配置（第 28 题）
  • [ ] 容器启动退出：第一优先 docker logs（第 18 题）
  • [ ] 安全加固：最小权限 / SSH 密钥 / 最小端口 / 补丁 / 监控（第 14 题）
  • [ ] Ansible 是「无 Agent」，Shell 也能通过 SSH 批量（第 23 题）
  • [ ] logrotate 防的是磁盘占满，不是内存（第 11 题）

🟢 已掌握，保持

幂等性、软硬链接、awk/sed、镜像与容器、负载 wa、swap、进程线程、nohup、Prometheus pull、TCP 握手、iptables 三链。