简介面向系统运维与互联网运维岗位求职者这是一份Linux笔试高频考点整理以完整版题目附答案的方式集中呈现适合备考笔试、面试提问也适合平时作为运维基础快速查阅手册。内容覆盖文件系统与权限管理、软链接与硬链接、权限数值转换、Shell脚本执行权限、内核子系统、用户标识、进程查看、CPU性能判断、交换分区规划、Samba配置、WWW与FTP默认端口、MySQL远程连接与mysqldump备份、tar归档压缩、默认Shell及常用用户管理命令等高频考点并按填空题、选择题两种题型呈现附有答案与要点说明可帮助读者高效识记。资源共1个PDF文档大小约65KB轻量便携手机上即可直接打开答案与题目同在一份文档中复习时可先看题再对照答案便于逐项查漏补缺。目前已有1580人学习该资料适合短时间内速刷考题也能为真实运维工作中的命令使用与配置思路提供参考。1. 系统运维笔试考什么卷面结构其实在测“状态机”阅卷时最可惜的答案不是写错命令而是把解题过程写成一份“命令清单”。系统运维工程师笔试题目答案版这类资料表面上在给标准输出实际上在测你理解到哪一层是记住了df的显示结果还是能解释df和du的统计口径为什么不一致是背下了kill -9还是能说清楚除了僵尸进程之外D 状态进程为什么杀不动。对五六年经验的运维来说准备笔试的性价比最高方式不是反复背题库而是先看卷面设计再按“题目 → 答案 → 可验证”的顺序做复现。本文不评说某一套真题而是把运维笔试中最常出现的四类题目——故障定位、服务管理、监控体系、脚本编写——逐一拉出答题框架和可落地命令并在最后一章给出一组能快速验证答案的最小实验。2. Linux 故障定位类笔试题的答案链路进程、磁盘与 inode2.1 “df 百分之百而 du 没满”的标准排查顺序这道题几乎每份试卷都会出现常见变形有“磁盘满告警但找不到大文件”“删除日志后空间没有释放”。答题的第一步不是堆命令而是先说结论df统计的是文件系统层面已分配的块du统计的是目录树里能遍历到的文件大小两者出现差异最常见的原因是文件已被删除但仍有进程持有文件描述符。对应的排查命令要按“从现象到证据”的顺序给出# 1. 先确认哪个文件系统满了以及挂载点在哪 df -hT # 2. 再确认是否 inode 耗尽导致无法创建文件 df -i # 3. 从挂载点自上而下找到真实的目录占用 du -x --max-depth1 /data | sort -k1 -n -r | head -n 10 # 4. 查找已删除但仍被进程占用的文件 sudo lsof L1 | grep deleted这里有个容易忽略的参数L1表示只列出 link count 小于 1 的文件也就是已经被 unlink 但仍打开的文件。没有这个参数lsof输出会包含大量正常文件反而干扰判断。du -x里的-x很关键它让 du 不跨越文件系统边界否则会把挂载在同一目录下的其他磁盘也算进去导致统计失真。笔试答案里如果再补一句“第 4 步是核心因为生产环境最常见的现象是日志文件被rm掉但写日志的进程没有重启文件句柄一直占着空间”这道题的得分点就齐了。只有df和du的对比没有lsof说明答题人还停留在“找文件”阶段没进入“找进程”阶段。2.2 kill -9 都杀不掉的进程答案要从进程状态入手“某进程重启不了kill -9 也没有响应如何排查”是另一类高频题。正确的答题起点是ps里的进程状态字段而不是直接背kill -9的用法。有一个常见的笔试题陷阱是把“杀不掉”直接等价于“权限不足”但实际上普通用户杀不掉 root 进程会立刻得到Operation not permitted的明确提示真正诡异的是命令执行后没有报错进程却还在。# 找出处于 D 状态不可中断睡眠的进程 ps -eo stat,pid,ppid,wchan:24,comm | awk $1 ~ /^D/ {print} # 连续采样几次确认进程是持续阻塞还是短暂切换 top -b -d 1 -n 3 | head -n 25 # 查看该进程当前等待的内核函数或设备 cat /proc/pid/wchanD状态表示进程在内核态等待某个 I/O 操作完成通常是磁盘、NFS、FUSE 这类设备没有返回。此时进程不响应任何信号因为信号处理本身要等到内核态返回用户态之后才有机会执行。答题时要点出“这属于内核层面等待不是应用层问题所以应该顺着wchan找到阻塞点而不是反复 kill”。如果wchan显示bio或nfs这类关键词就进一步查对应文件是否落在故障盘上# 查看进程打开的文件确认 I/O 是否集中到同一设备 sudo ls -l /proc/pid/fd | head -n 20 sudo cat /proc/pid/io这道题最容易得分的地方在于把“杀不掉”拆成“不能被信号打断的内核等待”和“僵尸状态等待父进程回收”两种情况再分别给排查动作。能做出这种区分说明你对进程状态机的理解是完整的。2.3 僵尸进程的处理与笔试得分点僵尸进程是另一道必背题但多数答案只写了“由父进程调用 wait 回收”没有展开“如果父进程不回收怎么办”。笔试答案应该包含下面三步先确认存在僵尸再定位父进程然后决定是由父进程处理还是让 init 进程接管。# 列出所有僵尸进程及其父进程 PID ps -eo stat,ppid,pid,comm | awk $1 ~ /^Z/ {print} # 查看这些僵尸进程的父进程是什么 ps -p ppid -o pid,ppid,stat,cmd # 如果父进程本身是正常服务重启它即可触发回收 # 如果父进程已经被 kill僵尸进程会被 initPID 1接管并回收有一层容易被忽略的细节僵尸进程消耗的资源已经释放只剩下 PID 和退出状态大量积压的真正危害是占满 PID 上限。答题时补一句“长期存在的僵尸需要查父进程是否有信号处理缺陷而不是简单重启”就能和其他人拉开距离。下面用一张表收拢这道题涉及的状态和信号笔试时写在答卷边上很占便宜状态名称能否被 kill 杀死排查方向Rrunning不能直接收尸看 CPU 占用与运行队列Ssleeping 可中断能看等待的资源是否异常Duninterruptible sleep不能查 wchan、设备 I/O、NFSZzombie本身已死找父进程并触发回收Tstopped可被 kill -9确认是否被调试器挂起3. 网络与服务管理笔试题的参数级答法从 TCP 状态到 systemd 限制3.1 TIME_WAIT 和 CLOSE_WAIT 的判定与调优参数“线上大量 TIME_WAIT 怎么办”是网络类题目里最常出现的。一个容易丢分的答法是一上来就给sysctl调参像是把net.ipv4.tcp_tw_reuse设为 1 就大功告成。实际上在较新的内核版本里TIME_WAIT 快速回收逻辑tcp_tw_recycle早已被移除tcp_tw_reuse也只对主动连接方、且没有 NAT 的场景有条件生效。更稳妥的答题思路是先定性再定量最后才谈调参。# 统计当前连接状态分布 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 单独看 TIME_WAIT 数量 ss -tan state time-wait | wc -l # 单独看 CLOSE_WAIT 并带上进程维度 ss -tanp state close-waitTIME_WAIT 是主动关闭连接的一方留下的 2MSL 等待状态它存在的意义是重传旧连接的迟到报文。答题时要说清楚TIME_WAIT 本身不是故障故障点是连接数过高导致本地端口耗尽或内存被 socket 结构占满。因此匹配的调优顺序是先确认端口范围是否打开到上限再考虑是否让业务复用长连接最后才轮到sysctl。# 查看本机可用于建立连接的临时端口范围 sysctl net.ipv4.ip_local_port_range # 提高端口范围直接生效不改文件则重启后失效 sudo sysctl -w net.ipv4.ip_local_port_range1024 65535CLOSE_WAIT 则是另一个方向的问题。它表示对端已经关闭连接但本端应用程序没有调用close()也就是应用层漏读了连接状态。答题时给出定位链路用ss -tanp拿到这样的连接和对应 PID再去看该进程的日志或线程堆栈基本九成是连接池不够用或业务处理超时导致 socket 长期悬挂。3.2 systemd 服务管理题的七个参数就能拿全分服务管理题里systemd 相关的占比越来越高。较常见的考法是给出一个要求“写一个 systemd unit让 Java 应用开机启动崩溃自动拉起最多使用 1GB 内存文件句柄数不受默认限制。”这道题同时覆盖了 unit 语法、资源限制、重启策略是一个很好的“参数记忆题”。# /etc/systemd/system/demoapp.service [Unit] DescriptionDemo Application Service Afternetwork.target [Service] Typesimple Userdemoapp Groupdemoapp ExecStart/usr/local/bin/demoapp --config /etc/demoapp.toml Restarton-failure RestartSec5 LimitNOFILE65535 LimitNPROC4096 MemoryMax1G CPUQuota200% [Install] WantedBymulti-user.targetRestarton-failure只在退出码非零或收到异常信号时重启always会连正常退出也重启生产环境一般不用always。MemoryMax1G是硬限制超过后内核会上 CGroup 杀掉进程而MemoryHigh是软限制只做回收压力提示。LimitNOFILE替代的是传统ulimit -n的位置写在这里才对整个服务生效。CPUQuota200%表示最多使用两个 CPU 核写百分比而不是整数是很多新手容易出错的地方。写完 unit 后答案还需要带上生效命令sudo systemctl daemon-reload sudo systemctl enable --now demoapp sudo systemctl status demoapp systemctl cat demoapp用systemctl cat验证最终生效的配置这个动作在笔试里是一个小而实用的加分项。3.3 SSH 加固与防火墙策略的惯用写法安全类笔试题中SSH 加固出现频率极高。常见的错误答案是把配置改得很“好看”但缺少配套动作例如把 SSH 端口改成 22022却忘了一起写防火墙放行规则。标准答案要成对给出sshd_config与防火墙策略并说明两者必须同步更新。# /etc/ssh/sshd_config 中建议开启的几项 Port 22022 PermitRootLogin no PasswordAuthentication no MaxAuthTries 3 AllowUsers devops sa # 放行新 SSH 端口同时限制来源网段 sudo iptables -A INPUT -p tcp --dport 22022 -s 10.20.0.0/16 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22022 -j DROP答题时的关键说明是AllowUsers提供了一个白名单入口iptables则限制来源 IP 网段两者是不同层次的隔离。如果业务有标准化的运维网段建议在别处直接-s匹配若只用云安全组则 iptables 规则可以省略但sshd_config的白名单还是留着更安全。4. 监控与智能运维题的答题颗粒度指标、容量与告警降噪4.1 CPU、内存、磁盘、网络的基础监控指标怎么答才完整监控类题目看起来简单实际上差一个层次就得被扣分。以“CPU 高了怎么看”为例初级答案是top看%CPU进阶答案应该先对“高”做定义是用户态高、内核态高还是平均负载高。# 同时看负载和 CPU 使用率 uptime vmstat 1 5 # 按核输出使用率 mpstat -P ALL 1 # 按进程追踪 CPU 占用 pidstat -u 1 5load average是三个时间段内的可运行线程和不可中断线程数CPU 使用率则是时间片占用比例。一个常见现象是四核机器 load average 长期到 8但%Cpu只看得到 80%因为还有进程在等 I/O。答题时先把这对概念讲清楚再给监控命令得分就会不一样。内存题同样有套路别只答free -m要区分buff/cache可回收和Swap使用率的关系。比较标准的答法是“先看可用内存再看 swap page in/out 的频率确认是否发生了持续换页”。4.2 系统运维工具与智能运维题的答题逻辑从指标到降噪这几年系统运维笔试的另一个变化是出现了智能运维和 AIOps 方向的简答题。题目常有“结合你所在团队谈如何建设智能运维体系”或“介绍一款系统运维工具SOT的落地经验”。这类题没有唯一答案但答题人要展示出清晰的演进逻辑先有可观测数据再有异常判断最后是告警收敛。# 一个典型的容量预估思路把磁盘使用率变化记录下来按天计算增量 df -hP /data | awk NR2 {print $5} | tr -d % # 用于连续记录 7 天 for i in $(seq 1 7); do df -hP /data | awk -v d$(date %F) NR2 {print d, $5} sleep 86400 done /var/log/disk_usage_history.log作答时建议按“指标 → 模型 → 动作”三层展开底层是 CPU、内存、磁盘、网络和日志指标模型层是趋势预测和基线异常检测比如磁盘用量按天递增可以简单用线性回归预估剩余天数动作层是告警分级和自动扩缩容。这类知识通常可以从描述智能运维体系构建的技术书籍里整理出通用框架而在笔试现场能写出的核心是“监控不是为了发告警而是为了减少告警”。告警降噪里有一个重要概念叫抑制和聚合。同一条业务线的多个告警应该先合并成一条影响面描述而不是把十几条钉钉消息同时丢给值班人。回答里提到这个就和只说“我用 Zabbix 告警”的人拉开差距了。4.3 日志异常检测题的最小可用答案日志类型的笔试题也常出现比如“如何发现日志里的异常”或“如何统计错误码尖峰”。这类题目不会要求现场写完整的 AI 模型更看重你是否能给出可执行的模式和判断边界。# 按分钟聚合 API 错误码数量 grep ERROR /var/log/app.log | awk {print $1, $2} | cut -d: -f1,2 | uniq -c # 计算今日错误总量与昨日同时间段的差异 today$(grep 2025-01-01 /var/log/app.log | grep -c ERROR) yesterday$(grep 2024-12-31 /var/log/app.log | grep -c ERROR) echo today$today yesterday$yesterday解释答案时要明确提出“基线”和“阈值”两个要素单纯数量高不高没有意义要和同时段历史数据比。笔试答到这里已经把你的工程经验展示出来了。可以顺带说明如果日志量巨大还会先做日志采集层的字段结构化再在检索端做聚合而不是全量灌进脚本。5. Shell 与 Python 脚本题的作答套路边界条件优先于语法5.1 日志统计题的一条高分 awk 管线题目常以“统计访问日志中访问量前十的 IP”出现。最简单的答案是一条管道命令需要把命令写完整并且带着对排序方向的理解。awk {print $1} /var/log/nginx/access.log \ | sort \ | uniq -c \ | sort -rn \ | head -n 10这里有两处值得说明第一uniq -c之前必须有sort因为 uniq 只合并相邻行第二最后的sort -rn负责按计数降序排列如果漏掉head取到的只是文件中出现顺序靠前的 IP而不是数量最多的 IP。能把这个顺序讲清楚说明你不是在背命令。如果日志里某些行格式不规整比如缺少来源 IP可以在 awk 里加一层过滤awk NF 10 {print $1} /var/log/nginx/access.log \ | sort | uniq -c | sort -rn | head -n 10NF 10用于跳过残缺行这是生产环境里常见的形态。笔试加分的地方在于主动说明“为什么不做第二列统计”——因为访问日志的格式约定第一列是客户端 IP除非写过解析规则不要默认所有日志都是同一结构。5.2 脚本健壮性set -euo pipefail 与空格文件名的处理脚本题目里有一个容易挂掉的考点用for循环遍历带空格的文件名。大多数现场写出来的初版脚本会这样写for f in $(find /data -name *.log); do tail -n 5 $f done当文件名包含空格时$(find ...)会把一个文件名拆成多段循环体收到的参数是错误的路径。正确的做法是使用find -print0结合while read -d #!/usr/bin/env bash set -euo pipefail find /data -maxdepth 2 -name *.log -print0 | while IFS read -r -d file; do echo ${file} tail -n 5 ${file} done脚本开头的set -euo pipefail是三个选项的合写-e让脚本在未捕获的错误时退出-u让未定义变量直接报错pipefail让管道中任意一环失败时整条管道返回非零。很多线上脚本事故都源于“某个中间命令失败了但脚本继续往下跑最后操作了一个残留的空文件”。笔试时即使不要求写完整脚本说明用这三件套应对边界问题也让阅卷人知道你有生产经验。5.3 用标准库完成系统信息采集的 Python 题Python 题在系统中也越来越多。常见要求是“写一段脚本检查磁盘使用率并输出告警”。如果服务器没有安装 psutil那就只能用os.statvfs。这道题考查的是对标准库的熟悉度以及输出是否结构化。import os import sys target sys.argv[1] if len(sys.argv) 1 else / st os.statvfs(target) total st.f_blocks * st.f_frsize available st.f_bavail * st.f_frsize used total - available percent int(used / total * 100) print(f{target} used {percent}%)这段脚本注意两个细节一是f_bavail是普通用户可用块数f_bfree包含为 root 预留的块监控场景应该用前者二是脚本尾部的sys.argv参数让脚本可以复用不同路径。笔试阅卷人会关注你是否把“可用空间”和“总空间”的字段选对这与du和df的差异本质上是同一层问题。如果要扩展到多盘检查可以用os.scandir(/)不断加盘符但在笔试中不必把脚本写得过于复杂把核心判定逻辑写对才是关键。6. 让笔试答案可复现的验证动作制造故障、观察状态、还原现场6.1 制造一个“已删除但仍占用”的磁盘故障想确认你在试卷上写的lsof L1真的能解决问题直接在本地实验即可。以下是一条安全且可逆的实验路径建议在任何测试机或容器内操作不要在生产环境模拟。mkdir -p /tmp/fakefill cd /tmp/fakefill dd if/dev/zero ofbigfile bs1M count512 # 用文件描述符 9 持有这个大文件 exec 9bigfile # 删除文件名但描述符仍保持打开 rm -f bigfile # 此时 du 显示目录为空df 显示空间被占 sudo lsof L1 | grep fakefill # 实验结束释放文件描述符并退出 exec 9-执行结果会让你明白证据、日志、最后一步操作的必要性。你自己看到的lsof输出强过背十遍答案。6.2 制造一次僵尸进程并观察回收过程另一个可以在容器内反复验证的操作是制造僵尸进程。这段 C 代码会 fork 出子进程子进程立即退出父进程休眠三十秒形成短暂的僵尸窗口。cat EOF /tmp/zombie.c #include stdio.h #include stdlib.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { exit(0); } sleep(30); return 0; } EOF gcc /tmp/zombie.c -o /tmp/zombie /tmp/zombie ps -eo stat,pid,ppid,comm | awk $1 ~ /^Z/ {print}输出的Z状态会持续存在到父进程退出之后由 PID 1 接管回收。这类实验把“僵尸进程”从概念变成肉眼可见的状态也顺便验证了ps状态过滤的正确写法。6.3 用“先观察、后清场”的方式复盘一份答案系统运维笔试的答案能不能落地最后拼的不是命令背得多熟而是面对一份输出有没有“先看现象、再推原因、最后动手”的惯性。阅读任何一份整理了答案版的 PDF 时我都建议先遮住后半部分按自己的理解写出排查顺序再对照答案检查差异接着用上面的最小实验把关键场景复现一遍。能复现的部分才属于你的经验复现不了的部分只是短期记忆而这个验证习惯会比多背一套题库更能应付上机题和实际故障。本文还有配套的精品资源点击获取 系统运维笔试答题框架：故障定位、服务管理与脚本编写
简介面向系统运维与互联网运维岗位求职者这是一份Linux笔试高频考点整理以完整版题目附答案的方式集中呈现适合备考笔试、面试提问也适合平时作为运维基础快速查阅手册。内容覆盖文件系统与权限管理、软链接与硬链接、权限数值转换、Shell脚本执行权限、内核子系统、用户标识、进程查看、CPU性能判断、交换分区规划、Samba配置、WWW与FTP默认端口、MySQL远程连接与mysqldump备份、tar归档压缩、默认Shell及常用用户管理命令等高频考点并按填空题、选择题两种题型呈现附有答案与要点说明可帮助读者高效识记。资源共1个PDF文档大小约65KB轻量便携手机上即可直接打开答案与题目同在一份文档中复习时可先看题再对照答案便于逐项查漏补缺。目前已有1580人学习该资料适合短时间内速刷考题也能为真实运维工作中的命令使用与配置思路提供参考。1. 系统运维笔试考什么卷面结构其实在测“状态机”阅卷时最可惜的答案不是写错命令而是把解题过程写成一份“命令清单”。系统运维工程师笔试题目答案版这类资料表面上在给标准输出实际上在测你理解到哪一层是记住了df的显示结果还是能解释df和du的统计口径为什么不一致是背下了kill -9还是能说清楚除了僵尸进程之外D 状态进程为什么杀不动。对五六年经验的运维来说准备笔试的性价比最高方式不是反复背题库而是先看卷面设计再按“题目 → 答案 → 可验证”的顺序做复现。本文不评说某一套真题而是把运维笔试中最常出现的四类题目——故障定位、服务管理、监控体系、脚本编写——逐一拉出答题框架和可落地命令并在最后一章给出一组能快速验证答案的最小实验。2. Linux 故障定位类笔试题的答案链路进程、磁盘与 inode2.1 “df 百分之百而 du 没满”的标准排查顺序这道题几乎每份试卷都会出现常见变形有“磁盘满告警但找不到大文件”“删除日志后空间没有释放”。答题的第一步不是堆命令而是先说结论df统计的是文件系统层面已分配的块du统计的是目录树里能遍历到的文件大小两者出现差异最常见的原因是文件已被删除但仍有进程持有文件描述符。对应的排查命令要按“从现象到证据”的顺序给出# 1. 先确认哪个文件系统满了以及挂载点在哪 df -hT # 2. 再确认是否 inode 耗尽导致无法创建文件 df -i # 3. 从挂载点自上而下找到真实的目录占用 du -x --max-depth1 /data | sort -k1 -n -r | head -n 10 # 4. 查找已删除但仍被进程占用的文件 sudo lsof L1 | grep deleted这里有个容易忽略的参数L1表示只列出 link count 小于 1 的文件也就是已经被 unlink 但仍打开的文件。没有这个参数lsof输出会包含大量正常文件反而干扰判断。du -x里的-x很关键它让 du 不跨越文件系统边界否则会把挂载在同一目录下的其他磁盘也算进去导致统计失真。笔试答案里如果再补一句“第 4 步是核心因为生产环境最常见的现象是日志文件被rm掉但写日志的进程没有重启文件句柄一直占着空间”这道题的得分点就齐了。只有df和du的对比没有lsof说明答题人还停留在“找文件”阶段没进入“找进程”阶段。2.2 kill -9 都杀不掉的进程答案要从进程状态入手“某进程重启不了kill -9 也没有响应如何排查”是另一类高频题。正确的答题起点是ps里的进程状态字段而不是直接背kill -9的用法。有一个常见的笔试题陷阱是把“杀不掉”直接等价于“权限不足”但实际上普通用户杀不掉 root 进程会立刻得到Operation not permitted的明确提示真正诡异的是命令执行后没有报错进程却还在。# 找出处于 D 状态不可中断睡眠的进程 ps -eo stat,pid,ppid,wchan:24,comm | awk $1 ~ /^D/ {print} # 连续采样几次确认进程是持续阻塞还是短暂切换 top -b -d 1 -n 3 | head -n 25 # 查看该进程当前等待的内核函数或设备 cat /proc/pid/wchanD状态表示进程在内核态等待某个 I/O 操作完成通常是磁盘、NFS、FUSE 这类设备没有返回。此时进程不响应任何信号因为信号处理本身要等到内核态返回用户态之后才有机会执行。答题时要点出“这属于内核层面等待不是应用层问题所以应该顺着wchan找到阻塞点而不是反复 kill”。如果wchan显示bio或nfs这类关键词就进一步查对应文件是否落在故障盘上# 查看进程打开的文件确认 I/O 是否集中到同一设备 sudo ls -l /proc/pid/fd | head -n 20 sudo cat /proc/pid/io这道题最容易得分的地方在于把“杀不掉”拆成“不能被信号打断的内核等待”和“僵尸状态等待父进程回收”两种情况再分别给排查动作。能做出这种区分说明你对进程状态机的理解是完整的。2.3 僵尸进程的处理与笔试得分点僵尸进程是另一道必背题但多数答案只写了“由父进程调用 wait 回收”没有展开“如果父进程不回收怎么办”。笔试答案应该包含下面三步先确认存在僵尸再定位父进程然后决定是由父进程处理还是让 init 进程接管。# 列出所有僵尸进程及其父进程 PID ps -eo stat,ppid,pid,comm | awk $1 ~ /^Z/ {print} # 查看这些僵尸进程的父进程是什么 ps -p ppid -o pid,ppid,stat,cmd # 如果父进程本身是正常服务重启它即可触发回收 # 如果父进程已经被 kill僵尸进程会被 initPID 1接管并回收有一层容易被忽略的细节僵尸进程消耗的资源已经释放只剩下 PID 和退出状态大量积压的真正危害是占满 PID 上限。答题时补一句“长期存在的僵尸需要查父进程是否有信号处理缺陷而不是简单重启”就能和其他人拉开距离。下面用一张表收拢这道题涉及的状态和信号笔试时写在答卷边上很占便宜状态名称能否被 kill 杀死排查方向Rrunning不能直接收尸看 CPU 占用与运行队列Ssleeping 可中断能看等待的资源是否异常Duninterruptible sleep不能查 wchan、设备 I/O、NFSZzombie本身已死找父进程并触发回收Tstopped可被 kill -9确认是否被调试器挂起3. 网络与服务管理笔试题的参数级答法从 TCP 状态到 systemd 限制3.1 TIME_WAIT 和 CLOSE_WAIT 的判定与调优参数“线上大量 TIME_WAIT 怎么办”是网络类题目里最常出现的。一个容易丢分的答法是一上来就给sysctl调参像是把net.ipv4.tcp_tw_reuse设为 1 就大功告成。实际上在较新的内核版本里TIME_WAIT 快速回收逻辑tcp_tw_recycle早已被移除tcp_tw_reuse也只对主动连接方、且没有 NAT 的场景有条件生效。更稳妥的答题思路是先定性再定量最后才谈调参。# 统计当前连接状态分布 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 单独看 TIME_WAIT 数量 ss -tan state time-wait | wc -l # 单独看 CLOSE_WAIT 并带上进程维度 ss -tanp state close-waitTIME_WAIT 是主动关闭连接的一方留下的 2MSL 等待状态它存在的意义是重传旧连接的迟到报文。答题时要说清楚TIME_WAIT 本身不是故障故障点是连接数过高导致本地端口耗尽或内存被 socket 结构占满。因此匹配的调优顺序是先确认端口范围是否打开到上限再考虑是否让业务复用长连接最后才轮到sysctl。# 查看本机可用于建立连接的临时端口范围 sysctl net.ipv4.ip_local_port_range # 提高端口范围直接生效不改文件则重启后失效 sudo sysctl -w net.ipv4.ip_local_port_range1024 65535CLOSE_WAIT 则是另一个方向的问题。它表示对端已经关闭连接但本端应用程序没有调用close()也就是应用层漏读了连接状态。答题时给出定位链路用ss -tanp拿到这样的连接和对应 PID再去看该进程的日志或线程堆栈基本九成是连接池不够用或业务处理超时导致 socket 长期悬挂。3.2 systemd 服务管理题的七个参数就能拿全分服务管理题里systemd 相关的占比越来越高。较常见的考法是给出一个要求“写一个 systemd unit让 Java 应用开机启动崩溃自动拉起最多使用 1GB 内存文件句柄数不受默认限制。”这道题同时覆盖了 unit 语法、资源限制、重启策略是一个很好的“参数记忆题”。# /etc/systemd/system/demoapp.service [Unit] DescriptionDemo Application Service Afternetwork.target [Service] Typesimple Userdemoapp Groupdemoapp ExecStart/usr/local/bin/demoapp --config /etc/demoapp.toml Restarton-failure RestartSec5 LimitNOFILE65535 LimitNPROC4096 MemoryMax1G CPUQuota200% [Install] WantedBymulti-user.targetRestarton-failure只在退出码非零或收到异常信号时重启always会连正常退出也重启生产环境一般不用always。MemoryMax1G是硬限制超过后内核会上 CGroup 杀掉进程而MemoryHigh是软限制只做回收压力提示。LimitNOFILE替代的是传统ulimit -n的位置写在这里才对整个服务生效。CPUQuota200%表示最多使用两个 CPU 核写百分比而不是整数是很多新手容易出错的地方。写完 unit 后答案还需要带上生效命令sudo systemctl daemon-reload sudo systemctl enable --now demoapp sudo systemctl status demoapp systemctl cat demoapp用systemctl cat验证最终生效的配置这个动作在笔试里是一个小而实用的加分项。3.3 SSH 加固与防火墙策略的惯用写法安全类笔试题中SSH 加固出现频率极高。常见的错误答案是把配置改得很“好看”但缺少配套动作例如把 SSH 端口改成 22022却忘了一起写防火墙放行规则。标准答案要成对给出sshd_config与防火墙策略并说明两者必须同步更新。# /etc/ssh/sshd_config 中建议开启的几项 Port 22022 PermitRootLogin no PasswordAuthentication no MaxAuthTries 3 AllowUsers devops sa # 放行新 SSH 端口同时限制来源网段 sudo iptables -A INPUT -p tcp --dport 22022 -s 10.20.0.0/16 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22022 -j DROP答题时的关键说明是AllowUsers提供了一个白名单入口iptables则限制来源 IP 网段两者是不同层次的隔离。如果业务有标准化的运维网段建议在别处直接-s匹配若只用云安全组则 iptables 规则可以省略但sshd_config的白名单还是留着更安全。4. 监控与智能运维题的答题颗粒度指标、容量与告警降噪4.1 CPU、内存、磁盘、网络的基础监控指标怎么答才完整监控类题目看起来简单实际上差一个层次就得被扣分。以“CPU 高了怎么看”为例初级答案是top看%CPU进阶答案应该先对“高”做定义是用户态高、内核态高还是平均负载高。# 同时看负载和 CPU 使用率 uptime vmstat 1 5 # 按核输出使用率 mpstat -P ALL 1 # 按进程追踪 CPU 占用 pidstat -u 1 5load average是三个时间段内的可运行线程和不可中断线程数CPU 使用率则是时间片占用比例。一个常见现象是四核机器 load average 长期到 8但%Cpu只看得到 80%因为还有进程在等 I/O。答题时先把这对概念讲清楚再给监控命令得分就会不一样。内存题同样有套路别只答free -m要区分buff/cache可回收和Swap使用率的关系。比较标准的答法是“先看可用内存再看 swap page in/out 的频率确认是否发生了持续换页”。4.2 系统运维工具与智能运维题的答题逻辑从指标到降噪这几年系统运维笔试的另一个变化是出现了智能运维和 AIOps 方向的简答题。题目常有“结合你所在团队谈如何建设智能运维体系”或“介绍一款系统运维工具SOT的落地经验”。这类题没有唯一答案但答题人要展示出清晰的演进逻辑先有可观测数据再有异常判断最后是告警收敛。# 一个典型的容量预估思路把磁盘使用率变化记录下来按天计算增量 df -hP /data | awk NR2 {print $5} | tr -d % # 用于连续记录 7 天 for i in $(seq 1 7); do df -hP /data | awk -v d$(date %F) NR2 {print d, $5} sleep 86400 done /var/log/disk_usage_history.log作答时建议按“指标 → 模型 → 动作”三层展开底层是 CPU、内存、磁盘、网络和日志指标模型层是趋势预测和基线异常检测比如磁盘用量按天递增可以简单用线性回归预估剩余天数动作层是告警分级和自动扩缩容。这类知识通常可以从描述智能运维体系构建的技术书籍里整理出通用框架而在笔试现场能写出的核心是“监控不是为了发告警而是为了减少告警”。告警降噪里有一个重要概念叫抑制和聚合。同一条业务线的多个告警应该先合并成一条影响面描述而不是把十几条钉钉消息同时丢给值班人。回答里提到这个就和只说“我用 Zabbix 告警”的人拉开差距了。4.3 日志异常检测题的最小可用答案日志类型的笔试题也常出现比如“如何发现日志里的异常”或“如何统计错误码尖峰”。这类题目不会要求现场写完整的 AI 模型更看重你是否能给出可执行的模式和判断边界。# 按分钟聚合 API 错误码数量 grep ERROR /var/log/app.log | awk {print $1, $2} | cut -d: -f1,2 | uniq -c # 计算今日错误总量与昨日同时间段的差异 today$(grep 2025-01-01 /var/log/app.log | grep -c ERROR) yesterday$(grep 2024-12-31 /var/log/app.log | grep -c ERROR) echo today$today yesterday$yesterday解释答案时要明确提出“基线”和“阈值”两个要素单纯数量高不高没有意义要和同时段历史数据比。笔试答到这里已经把你的工程经验展示出来了。可以顺带说明如果日志量巨大还会先做日志采集层的字段结构化再在检索端做聚合而不是全量灌进脚本。5. Shell 与 Python 脚本题的作答套路边界条件优先于语法5.1 日志统计题的一条高分 awk 管线题目常以“统计访问日志中访问量前十的 IP”出现。最简单的答案是一条管道命令需要把命令写完整并且带着对排序方向的理解。awk {print $1} /var/log/nginx/access.log \ | sort \ | uniq -c \ | sort -rn \ | head -n 10这里有两处值得说明第一uniq -c之前必须有sort因为 uniq 只合并相邻行第二最后的sort -rn负责按计数降序排列如果漏掉head取到的只是文件中出现顺序靠前的 IP而不是数量最多的 IP。能把这个顺序讲清楚说明你不是在背命令。如果日志里某些行格式不规整比如缺少来源 IP可以在 awk 里加一层过滤awk NF 10 {print $1} /var/log/nginx/access.log \ | sort | uniq -c | sort -rn | head -n 10NF 10用于跳过残缺行这是生产环境里常见的形态。笔试加分的地方在于主动说明“为什么不做第二列统计”——因为访问日志的格式约定第一列是客户端 IP除非写过解析规则不要默认所有日志都是同一结构。5.2 脚本健壮性set -euo pipefail 与空格文件名的处理脚本题目里有一个容易挂掉的考点用for循环遍历带空格的文件名。大多数现场写出来的初版脚本会这样写for f in $(find /data -name *.log); do tail -n 5 $f done当文件名包含空格时$(find ...)会把一个文件名拆成多段循环体收到的参数是错误的路径。正确的做法是使用find -print0结合while read -d #!/usr/bin/env bash set -euo pipefail find /data -maxdepth 2 -name *.log -print0 | while IFS read -r -d file; do echo ${file} tail -n 5 ${file} done脚本开头的set -euo pipefail是三个选项的合写-e让脚本在未捕获的错误时退出-u让未定义变量直接报错pipefail让管道中任意一环失败时整条管道返回非零。很多线上脚本事故都源于“某个中间命令失败了但脚本继续往下跑最后操作了一个残留的空文件”。笔试时即使不要求写完整脚本说明用这三件套应对边界问题也让阅卷人知道你有生产经验。5.3 用标准库完成系统信息采集的 Python 题Python 题在系统中也越来越多。常见要求是“写一段脚本检查磁盘使用率并输出告警”。如果服务器没有安装 psutil那就只能用os.statvfs。这道题考查的是对标准库的熟悉度以及输出是否结构化。import os import sys target sys.argv[1] if len(sys.argv) 1 else / st os.statvfs(target) total st.f_blocks * st.f_frsize available st.f_bavail * st.f_frsize used total - available percent int(used / total * 100) print(f{target} used {percent}%)这段脚本注意两个细节一是f_bavail是普通用户可用块数f_bfree包含为 root 预留的块监控场景应该用前者二是脚本尾部的sys.argv参数让脚本可以复用不同路径。笔试阅卷人会关注你是否把“可用空间”和“总空间”的字段选对这与du和df的差异本质上是同一层问题。如果要扩展到多盘检查可以用os.scandir(/)不断加盘符但在笔试中不必把脚本写得过于复杂把核心判定逻辑写对才是关键。6. 让笔试答案可复现的验证动作制造故障、观察状态、还原现场6.1 制造一个“已删除但仍占用”的磁盘故障想确认你在试卷上写的lsof L1真的能解决问题直接在本地实验即可。以下是一条安全且可逆的实验路径建议在任何测试机或容器内操作不要在生产环境模拟。mkdir -p /tmp/fakefill cd /tmp/fakefill dd if/dev/zero ofbigfile bs1M count512 # 用文件描述符 9 持有这个大文件 exec 9bigfile # 删除文件名但描述符仍保持打开 rm -f bigfile # 此时 du 显示目录为空df 显示空间被占 sudo lsof L1 | grep fakefill # 实验结束释放文件描述符并退出 exec 9-执行结果会让你明白证据、日志、最后一步操作的必要性。你自己看到的lsof输出强过背十遍答案。6.2 制造一次僵尸进程并观察回收过程另一个可以在容器内反复验证的操作是制造僵尸进程。这段 C 代码会 fork 出子进程子进程立即退出父进程休眠三十秒形成短暂的僵尸窗口。cat EOF /tmp/zombie.c #include stdio.h #include stdlib.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { exit(0); } sleep(30); return 0; } EOF gcc /tmp/zombie.c -o /tmp/zombie /tmp/zombie ps -eo stat,pid,ppid,comm | awk $1 ~ /^Z/ {print}输出的Z状态会持续存在到父进程退出之后由 PID 1 接管回收。这类实验把“僵尸进程”从概念变成肉眼可见的状态也顺便验证了ps状态过滤的正确写法。6.3 用“先观察、后清场”的方式复盘一份答案系统运维笔试的答案能不能落地最后拼的不是命令背得多熟而是面对一份输出有没有“先看现象、再推原因、最后动手”的惯性。阅读任何一份整理了答案版的 PDF 时我都建议先遮住后半部分按自己的理解写出排查顺序再对照答案检查差异接着用上面的最小实验把关键场景复现一遍。能复现的部分才属于你的经验复现不了的部分只是短期记忆而这个验证习惯会比多背一套题库更能应付上机题和实际故障。本文还有配套的精品资源点击获取