第4章：Linux基础运维高频问题
本章聚焦面试中最高频的Linux基础运维三大考点：文件权限管理、用户管理、进程管理，以及贯穿系统全生命周期的启动流程。以下结构化面试问答直接对应大厂面试常考方向。
加分心法：面试官不只看命令记忆，更关注你是否理解权限与用户的关系、进程与系统资源的交互、启动流程在故障排查中的应用。回答时尽量用“场景→原理→操作”三段式。
面试问答卡片
📌 问题1：如何解释 Linux 文件的三类权限（读/写/执行）？如果一个文件权限为 755，表示什么？
| 面试官考察点 | 是否真正理解权限位含义；能否结合数字和符号表示；是否了解特殊权限位 setuid/sticky bit。 |
| 回答框架 | 先描述权限的分类（用户/组/其他），再解释 rwx 数字对应关系，最后举例说明 755 → 所有者rwx+组rx+其他rx。可引申目录权限对 ls 的影响。 |
| 示例回答 | Linux权限分所有者、所属组、其他三类，分别用r/w/x标识。755二进制表示为111 101 101，即所有者读写执行，组和其他只读执行。特殊位如chmod u+s可让执行者临时获得所有者权限，常见于/usr/bin/su。 |
| 可能追问 | 1. setuid 和 sticky bit 分别在什么场景使用？2. 如果目录权限是644，能否进入该目录？3. umask 如何影响新文件权限？ |
| 避坑提醒 | 别只说数字对应关系，要强调权限对目录生效时要求执行位才能 cd/ls。忘记 sticky bit（/tmp 目录）会被追问。 |
📌 问题2：如何创建一个新用户并设置它只能使用 sftp 登录，不能使用 shell？
| 面试官考察点 | 是否掌握 useradd/usermod 配合 shell 更改；是否了解 sshd_config 中的 Subsystem sftp 与 Match Group 限制；安全加固意识。 |
| 回答框架 | 先创建用户并指定 shell 为 /sbin/nologin，再配置 sshd 限制该用户只能 sftp，最后验证。 |
| 示例回答 | 执行 useradd -s /sbin/nologin sftpuser，然后编辑 /etc/ssh/sshd_config，在 Match User sftpuser 下添加 ForceCommand internal-sftp 和 ChrootDirectory %h。重启 sshd，用户登录后只能 sftp 上传下载，无法打开 shell。 |
| 可能追问 | 1. 如何限制用户只能访问特定目录？2. 多个 sftp 用户如何分组管理？3. 如何记录 sftp 操作日志？ |
| 避坑提醒 | 忘记重启 sshd 导致配置不生效；ChrootDirectory 必须属主为 root 且权限 755 以下，否则报错；别混淆 internal-sftp 与 sftp-server 的区别。 |
📌 问题3：服务器 CPU 飙升到 100%，你如何定位是哪个进程引起的？请描述排查步骤。
| 面试官考察点 | 故障排查思维（先确认现象→工具定位→分析根因）；是否熟悉 top/htop/ps/pstree；是否了解 /proc 文件系统；能否区分用户态/内核态占用。 |
| 回答框架 | 先 top 看进程 PID 和 CPU 使用率 → 再用 ps -eo pid,comm,%cpu --sort=-%cpu 排序 → 查 /proc/PID/status 和 /proc/PID/exe 确认 → 用 strace -p PID 看系统调用 → 最后根据进程归属决定处理方案。 |
| 示例回答 | 先 top 按大写 P 排序，看到 PID 1234 占用 99% CPU。然后 ps -p 1234 -o comm,lstart,etime 确认是 java 进程。再用 strace -p 1234 -c -f 统计系统调用，发现每秒百万次 getpid，推测是死循环或无限 fork。最后 kill -3 1234 生成线程 dump 或直接 kill -9 终止。 |
| 可能追问 | 1. 如何查看进程的磁盘 I/O 或网络 I/O？2. 僵尸进程如何产生与处理？3. 系统启动过程中如果 grub 损坏如何修复？ |
| 避坑提醒 | 不推荐一上来就 kill，先保留现场；排查时注意区分用户态和内核态占用；忘记查看进程启动时间和服务归属会导致误判正常进程。 |
项目案例模板：Linux 服务器巡检与故障排查项目
| 项目名称 | Linux 生产服务器日常巡检与异常排查体系 |
| 业务背景 | 200+ 台 Linux 混合架构服务器，运行电商核心服务，要求 99.95% 可用性。原有巡检靠人手工执行，经常遗漏隐患，且排查故障时间长。 |
| 规模指标 | 200 台物理机 + 虚拟机，日均 PV 5000 万，峰值 CPU 负载 70% 以上，日志量日均 80GB。 |
| 技术栈 | CentOS 7/8, Ansible, Shell/Python, systemd, journalctl, sar, iostat, nmon, Zabbix |
| 核心难点 | 1. 权限混乱导致根目录被写满；2. 僵尸进程堆积引发 OOM；3. 系统启动阶段 network 服务启动慢影响业务恢复。 |
| 面试高频追问 | 1. 如何用 Ansible 批量修复文件权限？2. 如何编写脚本自动清理 30 天前的日志并保留权限？3. 启动流程中 systemd 依赖关系如何优化？4. 如何排查僵尸进程的父进程？5. 你如何监控进程的 RSS 和 VSZ 防止内存泄漏？ |
| 可迁移回答话术 | “我在项目中曾遇到因用户组权限错误导致 Nginx 无法读取 SSL 证书的错误，通过统计 find /etc -perm -o+w -type f 发现问题，然后利用 getfacl/setfacl 按模板批量修复 ACL。这个思路同样适用于排查其他服务权限问题——先列出异常权限文件，再根据基线修复。” |
面试话术延伸： 回答“如何排查启动慢”时，可使用 systemd-analyze blame 直接定位耗时最长的单元，结合 critical-chain 分析依赖瓶颈。这是大厂面试加分点。
避坑提醒： 项目描述中不要只说“我做了巡检”，要突出流程化、自动化、指标量化。例如：巡检脚本覆盖 CPU/内存/磁盘/进程/日志/防火墙状态共 12 项检查，输出 JSON 格式报告并推送到统一监控平台。