2026/9/1 22:18:58
FEATURED · 精选文章 
1. 这场笔试到底在筛什么样的人先说结论奇安信秋招运维方向的笔试卷核心不是考你背了多少命令而是考你在真实生产环境里踩过多少坑。我当年拿到这份卷子的时候第一反应是怎么全是场景题。后来跟几个上岸的同事聊了一圈发现几乎所有运维岗的校招笔试都这个套路——给你一堆看似零散的问题实际上是在模拟一个运维工程师日常会遇到的十分钟片段某个服务挂了、某个磁盘满了、某个端口不通了、某条命令不敢敲了。你平时有没有真正处理过这些问题一测就露馅。这篇文章不是给你押题而是把我对这份试卷背后考点的理解拆开讲清楚。试卷本身不会一模一样复现但考点就那么几个方向Linux基础与命令实操、网络排查思路、服务部署与故障恢复、自动化与脚本能力、安全运维意识、还有一部分企业级工具的理解奇安信这类安全厂商尤其看重最后一点。我会按照这些方向把每类题背后的为什么这么考和该怎么答讲透。不管你是正在准备秋招的应届生还是想转运维的开发者这篇文章的核心价值在于让你知道面试官出这道题时脑子里在想什么以及你平时应该怎么积累才能不靠背题也能稳过。2. Linux命令题不是背选项是背场景2.1 文件与权限操作里藏着的坑运维笔试里几乎必考文件操作但真正的坑不在命令本身而在你对权限模型的理解深度。比如一道很典型的题/tmp目录下有个脚本普通用户执行时报Permission denied问你怎么办。大多数人第一反应是chmod 777但这在真实生产环境里是绝对不能接受的答案。正确的排查链路应该是先ls -l看文件属主和权限位确认是不是执行权限缺失x位getfacl看有没有ACL特殊权限确认挂载选项mount | grep /tmp看是不是noexec很多安全加固过的服务器会把/tmp挂成 noexec这时候就算有x位也执行不了检查 SELinux 上下文ls -Z有时候是 SELinux 拦截而不是权限位问题这才是真正的解题思路。普通用户、root、sudoer 三种身份下我看到的问题完全不同笔试考的就是你在权限报错时的第一反应是不是那三板斧。另外一个高频点是chmod和chown配合使用的场景。比如你解压了一个 tar 包发现所有文件属于uid 1000的未知用户这时直接chown -R到目标用户。笔试可能会绕个弯如果这个目录里有几千个文件chown -R会不会太慢这时候可以用tar --ownerroot --grouproot重新打包解压或者用rsync -a --chown来带权限拷贝。这类处理大量文件时如何避免逐条操作的思想才是阅卷人想看到的。2.2 磁盘与日志排查df、du、inode 的三重门磁盘满是个经典场景但笔试通常会升级难度df -h显示磁盘还有空间可应用就是报no space left on device问你怎么排查。这里考的是inode 耗尽的概念。df -i一看如果 Inodes 使用率100%那问题就变成了找出哪个目录下全是小文件# 统计各目录下文件数量定位 inode 占用大户 for dir in /var/log /tmp /home /data; do echo $dir: $(find $dir -type f 2/dev/null | wc -l) done定位之后再按时间批量清理比如某天之前的日志全删find /var/log/myapp/ -type f -name *.log -mtime 7 -delete还有一种情况是文件被删除但空间没释放。lsof | grep deleted看一下是哪个进程还握着已删除文件的句柄重启该进程或优雅重载即可。这个考点在服务类题目里特别常见因为它涉及 Linux 文件系统底层机制文件句柄与磁盘空间的关联不是背命令能答出来的。2.3 进程与系统状态你用什么看 CPU 和负载top、htop、mpstat、pidstat这些工具几乎是必考。但笔试真正想考的是你会不会从上到下定位问题先uptime看 load average判断系统整体压力再top -o %CPU按 CPU 排序看是哪个进程在烧然后pidstat -p PID 1持续观察该进程的 CPU 和上下文切换如果是多线程应用top -Hp PID看到线程级消耗这里有个很多人不知道的小技巧load average 高并不一定是 CPU 不够也可能是不可中断睡眠D状态的进程太多比如 NFS 挂死、磁盘 IO 卡住。这时候top里一堆 D 状态的进程真正的问题出在磁盘阵列或网络存储上而不是 CPU。答这类题的时候如果能主动提到 先看vmstat的wa列来判断是否有 IO 瓶颈分数会明显不一样。因为这说明你不是只会按一个键看 top而是有完整的性能排查思路。3. 网络排查从 ping 不通到 DNS 解析异常的完整链路3.1 分层排查的思维方式网络题是运维笔试的送分题也是送命题。送分是因为只要你有分层排查的思路基本不会跑偏送命是因为很多人一上来就pingping 不通就慌了乱试一通。正确的思路永远是从 OSI 模型从下往上走链路层ip link看网卡状态是不是 UPethtool eth0看协商速率网络层ip addr确认 IP 配置ping 网关判断是不是本网段通不了传输层telnet IP 端口或nc -zv IP 端口判断目标端口是否开放应用层curl -v或dig判断 HTTP、DNS 服务是否正常笔试最容易考的是这个场景内网服务器能 ping 通外网 IP但域名解析不了。典型答案是 DNS 配置问题。cat /etc/resolv.conf看 nameserverdig 8.8.8.8 domain.com手动指定 DNS 服务器测试。常见的坑是resolv.conf被 NetworkManager 覆盖或者 DNS 配置了不可达的内网地址。3.2 TCP 连接问题的深入排查如果笔试再进阶一点会问 TCP 连接数过多怎么办。这不是考netstat那两条命令而是考你对TCP 状态机的理解。ss -s可以看到当前系统各种 TCP 状态的数量。如果TIME_WAIT特别多多半是短连接场景下没有开启连接复用# 查看当前 TCP 状态统计 ss -s # 内核参数调整按需使用 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 15如果SYN_SENT很多说明外联失败可能是防火墙丢包也可能是对方服务没起来。如果ESTABLISHED爆满但 CPU 不高那可能是连接数限制或应用层漏配了ulimit -n。这里特别想分享一个真实案例有次某个服务频繁超时所有人都在查网络最后发现是文件描述符到了上限新连接根本 accepted 不进来。ss -lnt看 Listen 队列溢出ss -lnt | grep Recv-Q里 Recv-Q 数值异常大说明 accept 队列已满。这类问题在笔试里不会直接告诉你是 fd 不够但你要能从状态数据里反推。3.3 HTTP 层排障的技巧现在的业务基本都是 HTTP 协议所以 curl 系列命令也常考。除了基础的curl -I看响应头我认为这几个点才是高分关键curl -w自定义输出看 DNS 解析时间、TCP 连接时间、TTFB时间定位耗时瓶颈在网络还是后端curl -x走代理测试判断是不是代理链路问题curl --resolve绕过 DNS 直接指定解析结果适合测试域名切流场景# 分阶段计时定位 HTTP 请求耗时环节 curl -o /dev/null -s -w DNS解析:%{time_namelookup}s TCP连接:%{time_connect}s TTFB:%{time_starttransfer}s 总耗时:%{time_total}s\n https://example.com考这个不是为了让你背参数而是考察你面对页面打不开/打开慢这类模糊问题时有没有一套自己的定位顺序。4. 服务部署与高可用从 systemd 到负载均衡4.1 systemd 管理的考察点现在是个人都会systemctl start nginx所以笔试早就不考这个了。它考的是你对 systemd 工作机制的理解。比如为什么服务启动失败但journalctl -u里看不到任何日志可能的原因有三个你得按顺序排查Typeforking配错了——主进程 fork 出去后systemd 认为该 PID 不是预期的主进程PID判定启动失败ExecStart里的命令失败但没输出到 journald直接退出日志打到了应用自己的文件里SELinux 拦截进程直接被杀/var/log/audit/audit.log里能看到avc: denied记录写 service 文件的时候我建议严格按这个模板来[Unit] DescriptionMy Custom Service Afternetwork.target Wantsnetwork-online.target [Service] Typesimple Usermyapp Groupmyapp WorkingDirectory/opt/myapp ExecStart/usr/bin/python3 /opt/myapp/main.py Restartalways RestartSec3 LimitNOFILE65535 PrivateTmptrue [Install] WantedBymulti-user.target笔试如果问为什么要把 Restart 设成 always你要答出两层一是进程崩溃能自动拉起缩短故障时间二是要配合RestartSec防止频繁重启打爆系统日志。而LimitNOFILE配合高并发场景是必须调的这个很多人会漏。4.2 Nginx 与负载均衡的基础题奇安信这类安全厂商笔试里Nginx 考的不会很深但基础配置必须会。比如你如何给后端服务配置反向代理并且做到 IP 哈希会话保持upstream backend_cluster { ip_hash; server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; } server { listen 80; server_name ops.example.com; location /api/ { proxy_pass http://backend_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }考ip_hash就意味着你知道轮询会导致用户的 session 在后端多个实例间跳来跳去这个痛点。如果能顺手提一句生产环境更推荐用 Redis 做 session 共享而不是靠负载均衡绑定 IP说明你不是只会抄配置的人。4.3 数据备份与恢复校招中最容易被低估的考点运维笔试里如果出现数据库相关题大概率是备份策略设计。比如一台 MySQL 服务器数据量 200G要求 RPO 在 10 分钟内RTO 在 1 小时内你会怎么设计备份方案比较稳妥的答案是每天凌晨全量备份mysqldump或xtrabackup每5分钟拉一次 binlog 增量日志存到异机。这样故障时先恢复最近的全量备份再按时间点重放 binlogRPO 就能控制在几分钟内。如果预算允许再加一个从库做实时同步主库挂了直接提升从库。这里有个答题加分项主动提备份数据要定期做恢复演练。光有备份但没验证过能不能恢复等于没有备份。笔试里能写出这句话的人大概率是真实做过运维的。5. 自动化与脚本Shell 和 Python 考察的潜台词5.1 Shell 脚本里的高频考点几乎所有运维笔试都有 Shell 脚本题最常见的就是写一个脚本批量处理日志文件。这里考的其实不是语法而是边界处理能力。比如这个需求写脚本清理/var/log/myapp下 7 天前的.log文件保留最新 3 个文件并要求输出每次删除的文件名。一个完整答案应该是#!/bin/bash LOG_DIR/var/log/myapp KEEP_DAYS7 KEEP_COUNT3 # 清理 7 天前的日志文件 find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS -print -delete # 确保保留最新 3 个日志文件 cd $LOG_DIR || exit 1 ls -lt *.log 2/dev/null | tail -n 4 | awk {print $9} | while read -r f; do rm -f $f echo 已删除旧日志: $f done能写出set -e出错即停、能判断目录是否存在、能用-print确认删除内容这在阅卷人眼里就是干过活的信号。还有一点脚本里千万别用rm -rf去拼接变量比如rm -rf $DIR/这种DIR 为空时会删根目录这是高危动作。这类题也是在考察安全意识。5.2 Python 脚本题的隐藏考点如果笔试出现 Python 题一般不是让你实现算法而是给你一段脚本让你找问题。比如下面这段import os import subprocess def get_cpu_usage(): result subprocess.run([top, -bn1], capture_outputTrue, textTrue) # 这样写有什么问题 return result.stdout问题在哪一是用top抓数据不是好办法应该直接用psutil或读/proc/stat二是top -bn1第一次执行的数据可能不准最好取两次间隔的值三是如果脚本以普通用户跑某些环境变量、PATH 可能有问题导致命令找不到。笔试想看到的答案是用/proc文件系统或psutil库去采集指标并且考虑异常处理import psutil def get_cpu_percent(): # 间隔 1 秒采样两次取平均 return psutil.cpu_percent(interval1)这种会用合适的工具做合适的事的意识比背标准库函数重要得多。5.3 定时任务的细节坑编写 crontab 时最容易踩的坑是环境变量问题。cron 执行脚本时的 PATH 很精简和你在终端里敲命令时不一样。所以脚本里要写全路径或者强制指定 PATH#!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin另外%在 crontab 里有特殊含义表示换行如果命令里需要date %Y%m%d这类带百分号的写法必须转义成\%Y\%m\%d否则任务会出错或行为异常。笔试里如果有给 cron 排错的题这几乎必考。6. 安全运维意识安全厂商笔试的隐藏重头戏6.1 账号安全与权限管控奇安信是安全公司所以安全类题目占的比重会比一般互联网公司高。最常见的一类题是一台 Linux 服务器被扫描到存在弱口令风险你如何整改正规流程分几步修改所有用户密码强制使用强密码策略禁用 root 远程登录/etc/ssh/sshd_config里设PermitRootLogin no配置密钥登录禁用密码登录PasswordAuthentication no设置失败锁定策略比如fail2ban或 PAM 的pam_tally2排查/etc/passwd里是否有 uid0 的异常账号以及空密码账号还有一个容易被忽略的点sudoers 配置。如果visudo里给了某个用户ALL(ALL) NOPASSWD: ALL这等于裸奔。笔试可能会给你一段 sudoers 配置让你找出风险你要能指出普通用户不应该有免密 root 权限。6.2 进程与启动项排查思路描述一个安全事件场景服务器 CPU 突然飙高top 里看到一个不认识的进程叫 kworker-xyz伪装内核线程名你判断这是什么这种题考察两个层面一是你能不能识别异常进程名字像内核线程但实际是伪造的二是你能不能找到异常的持久化方式。排查链路ls -l /proc/PID/exe看执行的二进制真实路径cat /proc/PID/cmdline看完整命令行lsof -p PID看进程打开了什么文件、连接了哪些 IPsystemctl list-units --typeservice查异常服务检查/etc/rc.local、/etc/systemd/system/下的可疑 unit 文件crontab -l查定时任务里有没有异常下载指令如果文件的exe路径是/tmp/xxx甚至exe后面标注(deleted)那基本可以确认是异常进程——攻击者通常会先删掉原始文件再运行进程。这个细节笔试如果问到答出来就是加分项。6.3 日志审计与溯源安全运维里日志审计是基础能力。考察方式通常是给你一段secure日志或auth.log让你找出异常登录。比如lastb显示同一 IP 在短时间内大量尝试 root 登录失败你会怎么处理lastb | awk {print $3} | sort | uniq -c | sort -rn统计失败尝试来源 IP用iptables或firewalld封禁该 IP如果暴力破解来源是动态 IP 池手动封不现实部署fail2ban自动封禁检查该 IP 是否已经有过成功登录记录grep Accepted /var/log/secure | grep IP地址还有一类题是给你日志文件路径让你按时间、用户、事件类型做筛选。会灵活用grep、awk、sed、journalctl --since这几个命令的人基本能过关。我见过不少人在笔试时写复杂的 Python 去筛日志其实用 awk 三行就搞定了这也反映出对文本处理工具的熟练度差距。7. 企业级运维工具与奇安信特色考点7.1 运维监控工具的选型逻辑奇安信笔试可能会问监控系统设计。这里不是让你写 Prometheus 配置而是考你对监控体系分层的理解基础层CPU、内存、磁盘、网络node_exporter即可应用层接口延迟、QPS、错误率需要业务埋点或 APM日志层ELK/Loki 聚合系统日志用于排障和分析告警层Alertmanager 负责告警路由和静默回答这类题的时候如果能结合监控数据要设定合理阈值并定期调整会显得你确实规划过生产监控。比如磁盘阈值设多少合理?不能等满到100%才告警常规是80%就 warning、90% 就 critical。但如果日志盘本来就是大盘且定期清理可以放宽到85%再告警。这种工程判断比背工具名重要得多。7.2 安全产品理解EDR、堡垒机、漏扫作为安全厂商奇安信笔试里出现安全产品相关问题也不意外。主要涉及几个方向EDR终端检测与响应你需要理解它的作用是检测终端上的异常行为和入侵痕迹而不是简单的杀毒软件。像奇安信天擎这类产品在运维的日常工作中会涉及安全策略下发、病毒查杀、终端合规检查。堡垒机运维审计系统核心价值是让所有运维操作都有迹可循——统一账号管理、操作录像、命令审批。漏扫漏洞扫描用于定期发现系统与 Web 应用的漏洞形成闭环扫描-验证-修复-复扫。如果笔试问为什么企业需要堡垒机你要答出的核心是运维人员对生产服务器的操作需要可管可控可审计避免误操作或恶意操作导致故障且无法追责。这不是技术问题而是管理合规问题。7.3 云计算与容器化的基础认知现在的运维已经从服务器物理机运维扩展到云原生环境运维所以笔试里出现 Docker/Kubernetes 基础题也很常见。常考的点Docker 和虚拟机的区别——共享宿主机内核 vs 独立内核容器为什么不适合跑有状态应用——数据在容器销毁后丢失除非挂载卷Kubernetes 中 Pod 是调度最小单位容器是运行最小单位kubectl logs、kubectl exec、kubectl get events这类排障命令这里有个安全方向的问题也常被问到容器以 root 运行时有什么风险答案是内核逃逸后攻击者直接获得宿主机 root 权限所以生产环境必须配置runAsNonRoot: true并使用只读根文件系统。奇安信这类安全公司对这个点会特别敏感。8. 笔试题背后的复习建议与实战心态8.1 校招运维考题的共性规律把所有考点串起来看我总结出三个共性第一考察最短路径解决问题的能力。比如服务被 kill 了是先查内存还是先看日志有经验的运维会先dmesg | tail看是不是 OOM Killer 干的而不是漫无目的地翻应用日志。这种故障排除的顺序感笔试通过场景题传达得很明显。第二考察安全底线意识。所有操作题只要涉及删除、权限变更、防火墙重启都要思考安全影响。比如清理解析日志时你做的第一件事不是删而是备份。哪怕笔试没问备份你在答案里加上操作前先备份这句话就赢了很多人。第三考察知识面的广度。从 Linux 命令到网络原理从 Shell 脚本到安全基线一道题可能横跨多个知识域。比如某个端口突然不通这个问题涉及防火墙规则、SELinux、iptables、路由、端口监听状态、云平台安全组等。你能说出几个层级面试官就能判断你的经验深度。8.2 我从这份卷子反推的复习路线如果你准备时间有限我建议按优先级做这几件事把 Linux 基础命令过一遍但不要只看命令要看使用场景。没条件搭真实服务器就用虚拟机或云服务器把服务部署、日志排查、权限管理完整走一遍。自己手动搭建一个 Web 服务Nginx MySQL 后端代码然后故意把它搞坏再修好。比如手动把权限改成 000、把端口占用、把磁盘写满、把 iptables 规则删掉再去定位问题。这个过程比看十遍教程都管用。练熟 Shell 和 Python 的文本处理。给你一份中文访问日志你能在 10 分钟内统计出 TOP 10 访问 IP、TOP 10 请求 URL、404 状态码总量。这几乎是笔试必考也是日常运维的高频技能。多读安全公告和运维事故复盘文章。理解真实世界的故障是怎么发生、怎么恢复的这比背大量面试题库收益高得多。看的时候问自己如果我在值班能不能发现这个问题。8.3 考场上的答法技巧笔试不只要会还得会写。我的几个建议能写命令就写命令比如回答排查思路时不写我需要查看磁盘使用情况而是直接写df -h、df -i、du -sh *。这会让阅卷人一眼确认你是真做过。答案要有顺序按排查链路来不要想到哪写到哪。比如先确认服务状态systemctl status xxx再查看日志journalctl -u xxx再检查端口ss -lntp这就是一个可执行的排障步骤而不是零散的知识点。不确定的答案不要只给一个。如果这道题有多种可能原因把可能性都列出来并说明你如何验证阅卷人会认为你考虑周全。涉及高危操作时务必列出安全措施。比如封禁 IP 时先确认不要误封自己的跳板机清理数据前先备份改防火墙前先评估影响面。这是最容易被忽视但最加分的地方。我当年面奇安信的时候笔试里有一道服务起不来的题我答了先看 systemd 状态再看 journalctl 日志然后还原故障现场的完整链路。后来面试官告诉我那道题其实最想看到的就是先确认服务是否在跑、再逐层查日志的排障顺序而不是直接甩一个命令。所以答题时别急把思路写得跟你在真实环境里一步步操作时一样清楚。8.4 最后说点实在的运维这个岗位的门槛是会命令天花板是能判断。笔试只是检验你日常积累的片段真正的功夫在每次排障中学到的链路和判断。准备的时候别纠结押题把基础打扎实遇到没见过的场景你也能靠通用的排查思路拉出答案。另外如果现在还有时间强烈建议你亲手搭一套实验环境一台 Linux 虚拟机装好 Nginx再用 Python 写一个简单的业务接口然后模拟一次从用户报障到定位根因的完整过程。这个过程走一遍你再看任何笔试场景题都不会慌了。一份试卷改变不了你的真实水平但它能告诉你接下来该往哪个方向补。希望这篇文章能帮你把复习的重心从背命令挪到建链路上——那才是运维工程师真正吃饭的本事。
奇安信运维秋招笔试深度解析：从Linux命令到安全运维排查
1. 这场笔试到底在筛什么样的人先说结论奇安信秋招运维方向的笔试卷核心不是考你背了多少命令而是考你在真实生产环境里踩过多少坑。我当年拿到这份卷子的时候第一反应是怎么全是场景题。后来跟几个上岸的同事聊了一圈发现几乎所有运维岗的校招笔试都这个套路——给你一堆看似零散的问题实际上是在模拟一个运维工程师日常会遇到的十分钟片段某个服务挂了、某个磁盘满了、某个端口不通了、某条命令不敢敲了。你平时有没有真正处理过这些问题一测就露馅。这篇文章不是给你押题而是把我对这份试卷背后考点的理解拆开讲清楚。试卷本身不会一模一样复现但考点就那么几个方向Linux基础与命令实操、网络排查思路、服务部署与故障恢复、自动化与脚本能力、安全运维意识、还有一部分企业级工具的理解奇安信这类安全厂商尤其看重最后一点。我会按照这些方向把每类题背后的为什么这么考和该怎么答讲透。不管你是正在准备秋招的应届生还是想转运维的开发者这篇文章的核心价值在于让你知道面试官出这道题时脑子里在想什么以及你平时应该怎么积累才能不靠背题也能稳过。2. Linux命令题不是背选项是背场景2.1 文件与权限操作里藏着的坑运维笔试里几乎必考文件操作但真正的坑不在命令本身而在你对权限模型的理解深度。比如一道很典型的题/tmp目录下有个脚本普通用户执行时报Permission denied问你怎么办。大多数人第一反应是chmod 777但这在真实生产环境里是绝对不能接受的答案。正确的排查链路应该是先ls -l看文件属主和权限位确认是不是执行权限缺失x位getfacl看有没有ACL特殊权限确认挂载选项mount | grep /tmp看是不是noexec很多安全加固过的服务器会把/tmp挂成 noexec这时候就算有x位也执行不了检查 SELinux 上下文ls -Z有时候是 SELinux 拦截而不是权限位问题这才是真正的解题思路。普通用户、root、sudoer 三种身份下我看到的问题完全不同笔试考的就是你在权限报错时的第一反应是不是那三板斧。另外一个高频点是chmod和chown配合使用的场景。比如你解压了一个 tar 包发现所有文件属于uid 1000的未知用户这时直接chown -R到目标用户。笔试可能会绕个弯如果这个目录里有几千个文件chown -R会不会太慢这时候可以用tar --ownerroot --grouproot重新打包解压或者用rsync -a --chown来带权限拷贝。这类处理大量文件时如何避免逐条操作的思想才是阅卷人想看到的。2.2 磁盘与日志排查df、du、inode 的三重门磁盘满是个经典场景但笔试通常会升级难度df -h显示磁盘还有空间可应用就是报no space left on device问你怎么排查。这里考的是inode 耗尽的概念。df -i一看如果 Inodes 使用率100%那问题就变成了找出哪个目录下全是小文件# 统计各目录下文件数量定位 inode 占用大户 for dir in /var/log /tmp /home /data; do echo $dir: $(find $dir -type f 2/dev/null | wc -l) done定位之后再按时间批量清理比如某天之前的日志全删find /var/log/myapp/ -type f -name *.log -mtime 7 -delete还有一种情况是文件被删除但空间没释放。lsof | grep deleted看一下是哪个进程还握着已删除文件的句柄重启该进程或优雅重载即可。这个考点在服务类题目里特别常见因为它涉及 Linux 文件系统底层机制文件句柄与磁盘空间的关联不是背命令能答出来的。2.3 进程与系统状态你用什么看 CPU 和负载top、htop、mpstat、pidstat这些工具几乎是必考。但笔试真正想考的是你会不会从上到下定位问题先uptime看 load average判断系统整体压力再top -o %CPU按 CPU 排序看是哪个进程在烧然后pidstat -p PID 1持续观察该进程的 CPU 和上下文切换如果是多线程应用top -Hp PID看到线程级消耗这里有个很多人不知道的小技巧load average 高并不一定是 CPU 不够也可能是不可中断睡眠D状态的进程太多比如 NFS 挂死、磁盘 IO 卡住。这时候top里一堆 D 状态的进程真正的问题出在磁盘阵列或网络存储上而不是 CPU。答这类题的时候如果能主动提到 先看vmstat的wa列来判断是否有 IO 瓶颈分数会明显不一样。因为这说明你不是只会按一个键看 top而是有完整的性能排查思路。3. 网络排查从 ping 不通到 DNS 解析异常的完整链路3.1 分层排查的思维方式网络题是运维笔试的送分题也是送命题。送分是因为只要你有分层排查的思路基本不会跑偏送命是因为很多人一上来就pingping 不通就慌了乱试一通。正确的思路永远是从 OSI 模型从下往上走链路层ip link看网卡状态是不是 UPethtool eth0看协商速率网络层ip addr确认 IP 配置ping 网关判断是不是本网段通不了传输层telnet IP 端口或nc -zv IP 端口判断目标端口是否开放应用层curl -v或dig判断 HTTP、DNS 服务是否正常笔试最容易考的是这个场景内网服务器能 ping 通外网 IP但域名解析不了。典型答案是 DNS 配置问题。cat /etc/resolv.conf看 nameserverdig 8.8.8.8 domain.com手动指定 DNS 服务器测试。常见的坑是resolv.conf被 NetworkManager 覆盖或者 DNS 配置了不可达的内网地址。3.2 TCP 连接问题的深入排查如果笔试再进阶一点会问 TCP 连接数过多怎么办。这不是考netstat那两条命令而是考你对TCP 状态机的理解。ss -s可以看到当前系统各种 TCP 状态的数量。如果TIME_WAIT特别多多半是短连接场景下没有开启连接复用# 查看当前 TCP 状态统计 ss -s # 内核参数调整按需使用 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 15如果SYN_SENT很多说明外联失败可能是防火墙丢包也可能是对方服务没起来。如果ESTABLISHED爆满但 CPU 不高那可能是连接数限制或应用层漏配了ulimit -n。这里特别想分享一个真实案例有次某个服务频繁超时所有人都在查网络最后发现是文件描述符到了上限新连接根本 accepted 不进来。ss -lnt看 Listen 队列溢出ss -lnt | grep Recv-Q里 Recv-Q 数值异常大说明 accept 队列已满。这类问题在笔试里不会直接告诉你是 fd 不够但你要能从状态数据里反推。3.3 HTTP 层排障的技巧现在的业务基本都是 HTTP 协议所以 curl 系列命令也常考。除了基础的curl -I看响应头我认为这几个点才是高分关键curl -w自定义输出看 DNS 解析时间、TCP 连接时间、TTFB时间定位耗时瓶颈在网络还是后端curl -x走代理测试判断是不是代理链路问题curl --resolve绕过 DNS 直接指定解析结果适合测试域名切流场景# 分阶段计时定位 HTTP 请求耗时环节 curl -o /dev/null -s -w DNS解析:%{time_namelookup}s TCP连接:%{time_connect}s TTFB:%{time_starttransfer}s 总耗时:%{time_total}s\n https://example.com考这个不是为了让你背参数而是考察你面对页面打不开/打开慢这类模糊问题时有没有一套自己的定位顺序。4. 服务部署与高可用从 systemd 到负载均衡4.1 systemd 管理的考察点现在是个人都会systemctl start nginx所以笔试早就不考这个了。它考的是你对 systemd 工作机制的理解。比如为什么服务启动失败但journalctl -u里看不到任何日志可能的原因有三个你得按顺序排查Typeforking配错了——主进程 fork 出去后systemd 认为该 PID 不是预期的主进程PID判定启动失败ExecStart里的命令失败但没输出到 journald直接退出日志打到了应用自己的文件里SELinux 拦截进程直接被杀/var/log/audit/audit.log里能看到avc: denied记录写 service 文件的时候我建议严格按这个模板来[Unit] DescriptionMy Custom Service Afternetwork.target Wantsnetwork-online.target [Service] Typesimple Usermyapp Groupmyapp WorkingDirectory/opt/myapp ExecStart/usr/bin/python3 /opt/myapp/main.py Restartalways RestartSec3 LimitNOFILE65535 PrivateTmptrue [Install] WantedBymulti-user.target笔试如果问为什么要把 Restart 设成 always你要答出两层一是进程崩溃能自动拉起缩短故障时间二是要配合RestartSec防止频繁重启打爆系统日志。而LimitNOFILE配合高并发场景是必须调的这个很多人会漏。4.2 Nginx 与负载均衡的基础题奇安信这类安全厂商笔试里Nginx 考的不会很深但基础配置必须会。比如你如何给后端服务配置反向代理并且做到 IP 哈希会话保持upstream backend_cluster { ip_hash; server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; } server { listen 80; server_name ops.example.com; location /api/ { proxy_pass http://backend_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }考ip_hash就意味着你知道轮询会导致用户的 session 在后端多个实例间跳来跳去这个痛点。如果能顺手提一句生产环境更推荐用 Redis 做 session 共享而不是靠负载均衡绑定 IP说明你不是只会抄配置的人。4.3 数据备份与恢复校招中最容易被低估的考点运维笔试里如果出现数据库相关题大概率是备份策略设计。比如一台 MySQL 服务器数据量 200G要求 RPO 在 10 分钟内RTO 在 1 小时内你会怎么设计备份方案比较稳妥的答案是每天凌晨全量备份mysqldump或xtrabackup每5分钟拉一次 binlog 增量日志存到异机。这样故障时先恢复最近的全量备份再按时间点重放 binlogRPO 就能控制在几分钟内。如果预算允许再加一个从库做实时同步主库挂了直接提升从库。这里有个答题加分项主动提备份数据要定期做恢复演练。光有备份但没验证过能不能恢复等于没有备份。笔试里能写出这句话的人大概率是真实做过运维的。5. 自动化与脚本Shell 和 Python 考察的潜台词5.1 Shell 脚本里的高频考点几乎所有运维笔试都有 Shell 脚本题最常见的就是写一个脚本批量处理日志文件。这里考的其实不是语法而是边界处理能力。比如这个需求写脚本清理/var/log/myapp下 7 天前的.log文件保留最新 3 个文件并要求输出每次删除的文件名。一个完整答案应该是#!/bin/bash LOG_DIR/var/log/myapp KEEP_DAYS7 KEEP_COUNT3 # 清理 7 天前的日志文件 find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS -print -delete # 确保保留最新 3 个日志文件 cd $LOG_DIR || exit 1 ls -lt *.log 2/dev/null | tail -n 4 | awk {print $9} | while read -r f; do rm -f $f echo 已删除旧日志: $f done能写出set -e出错即停、能判断目录是否存在、能用-print确认删除内容这在阅卷人眼里就是干过活的信号。还有一点脚本里千万别用rm -rf去拼接变量比如rm -rf $DIR/这种DIR 为空时会删根目录这是高危动作。这类题也是在考察安全意识。5.2 Python 脚本题的隐藏考点如果笔试出现 Python 题一般不是让你实现算法而是给你一段脚本让你找问题。比如下面这段import os import subprocess def get_cpu_usage(): result subprocess.run([top, -bn1], capture_outputTrue, textTrue) # 这样写有什么问题 return result.stdout问题在哪一是用top抓数据不是好办法应该直接用psutil或读/proc/stat二是top -bn1第一次执行的数据可能不准最好取两次间隔的值三是如果脚本以普通用户跑某些环境变量、PATH 可能有问题导致命令找不到。笔试想看到的答案是用/proc文件系统或psutil库去采集指标并且考虑异常处理import psutil def get_cpu_percent(): # 间隔 1 秒采样两次取平均 return psutil.cpu_percent(interval1)这种会用合适的工具做合适的事的意识比背标准库函数重要得多。5.3 定时任务的细节坑编写 crontab 时最容易踩的坑是环境变量问题。cron 执行脚本时的 PATH 很精简和你在终端里敲命令时不一样。所以脚本里要写全路径或者强制指定 PATH#!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin另外%在 crontab 里有特殊含义表示换行如果命令里需要date %Y%m%d这类带百分号的写法必须转义成\%Y\%m\%d否则任务会出错或行为异常。笔试里如果有给 cron 排错的题这几乎必考。6. 安全运维意识安全厂商笔试的隐藏重头戏6.1 账号安全与权限管控奇安信是安全公司所以安全类题目占的比重会比一般互联网公司高。最常见的一类题是一台 Linux 服务器被扫描到存在弱口令风险你如何整改正规流程分几步修改所有用户密码强制使用强密码策略禁用 root 远程登录/etc/ssh/sshd_config里设PermitRootLogin no配置密钥登录禁用密码登录PasswordAuthentication no设置失败锁定策略比如fail2ban或 PAM 的pam_tally2排查/etc/passwd里是否有 uid0 的异常账号以及空密码账号还有一个容易被忽略的点sudoers 配置。如果visudo里给了某个用户ALL(ALL) NOPASSWD: ALL这等于裸奔。笔试可能会给你一段 sudoers 配置让你找出风险你要能指出普通用户不应该有免密 root 权限。6.2 进程与启动项排查思路描述一个安全事件场景服务器 CPU 突然飙高top 里看到一个不认识的进程叫 kworker-xyz伪装内核线程名你判断这是什么这种题考察两个层面一是你能不能识别异常进程名字像内核线程但实际是伪造的二是你能不能找到异常的持久化方式。排查链路ls -l /proc/PID/exe看执行的二进制真实路径cat /proc/PID/cmdline看完整命令行lsof -p PID看进程打开了什么文件、连接了哪些 IPsystemctl list-units --typeservice查异常服务检查/etc/rc.local、/etc/systemd/system/下的可疑 unit 文件crontab -l查定时任务里有没有异常下载指令如果文件的exe路径是/tmp/xxx甚至exe后面标注(deleted)那基本可以确认是异常进程——攻击者通常会先删掉原始文件再运行进程。这个细节笔试如果问到答出来就是加分项。6.3 日志审计与溯源安全运维里日志审计是基础能力。考察方式通常是给你一段secure日志或auth.log让你找出异常登录。比如lastb显示同一 IP 在短时间内大量尝试 root 登录失败你会怎么处理lastb | awk {print $3} | sort | uniq -c | sort -rn统计失败尝试来源 IP用iptables或firewalld封禁该 IP如果暴力破解来源是动态 IP 池手动封不现实部署fail2ban自动封禁检查该 IP 是否已经有过成功登录记录grep Accepted /var/log/secure | grep IP地址还有一类题是给你日志文件路径让你按时间、用户、事件类型做筛选。会灵活用grep、awk、sed、journalctl --since这几个命令的人基本能过关。我见过不少人在笔试时写复杂的 Python 去筛日志其实用 awk 三行就搞定了这也反映出对文本处理工具的熟练度差距。7. 企业级运维工具与奇安信特色考点7.1 运维监控工具的选型逻辑奇安信笔试可能会问监控系统设计。这里不是让你写 Prometheus 配置而是考你对监控体系分层的理解基础层CPU、内存、磁盘、网络node_exporter即可应用层接口延迟、QPS、错误率需要业务埋点或 APM日志层ELK/Loki 聚合系统日志用于排障和分析告警层Alertmanager 负责告警路由和静默回答这类题的时候如果能结合监控数据要设定合理阈值并定期调整会显得你确实规划过生产监控。比如磁盘阈值设多少合理?不能等满到100%才告警常规是80%就 warning、90% 就 critical。但如果日志盘本来就是大盘且定期清理可以放宽到85%再告警。这种工程判断比背工具名重要得多。7.2 安全产品理解EDR、堡垒机、漏扫作为安全厂商奇安信笔试里出现安全产品相关问题也不意外。主要涉及几个方向EDR终端检测与响应你需要理解它的作用是检测终端上的异常行为和入侵痕迹而不是简单的杀毒软件。像奇安信天擎这类产品在运维的日常工作中会涉及安全策略下发、病毒查杀、终端合规检查。堡垒机运维审计系统核心价值是让所有运维操作都有迹可循——统一账号管理、操作录像、命令审批。漏扫漏洞扫描用于定期发现系统与 Web 应用的漏洞形成闭环扫描-验证-修复-复扫。如果笔试问为什么企业需要堡垒机你要答出的核心是运维人员对生产服务器的操作需要可管可控可审计避免误操作或恶意操作导致故障且无法追责。这不是技术问题而是管理合规问题。7.3 云计算与容器化的基础认知现在的运维已经从服务器物理机运维扩展到云原生环境运维所以笔试里出现 Docker/Kubernetes 基础题也很常见。常考的点Docker 和虚拟机的区别——共享宿主机内核 vs 独立内核容器为什么不适合跑有状态应用——数据在容器销毁后丢失除非挂载卷Kubernetes 中 Pod 是调度最小单位容器是运行最小单位kubectl logs、kubectl exec、kubectl get events这类排障命令这里有个安全方向的问题也常被问到容器以 root 运行时有什么风险答案是内核逃逸后攻击者直接获得宿主机 root 权限所以生产环境必须配置runAsNonRoot: true并使用只读根文件系统。奇安信这类安全公司对这个点会特别敏感。8. 笔试题背后的复习建议与实战心态8.1 校招运维考题的共性规律把所有考点串起来看我总结出三个共性第一考察最短路径解决问题的能力。比如服务被 kill 了是先查内存还是先看日志有经验的运维会先dmesg | tail看是不是 OOM Killer 干的而不是漫无目的地翻应用日志。这种故障排除的顺序感笔试通过场景题传达得很明显。第二考察安全底线意识。所有操作题只要涉及删除、权限变更、防火墙重启都要思考安全影响。比如清理解析日志时你做的第一件事不是删而是备份。哪怕笔试没问备份你在答案里加上操作前先备份这句话就赢了很多人。第三考察知识面的广度。从 Linux 命令到网络原理从 Shell 脚本到安全基线一道题可能横跨多个知识域。比如某个端口突然不通这个问题涉及防火墙规则、SELinux、iptables、路由、端口监听状态、云平台安全组等。你能说出几个层级面试官就能判断你的经验深度。8.2 我从这份卷子反推的复习路线如果你准备时间有限我建议按优先级做这几件事把 Linux 基础命令过一遍但不要只看命令要看使用场景。没条件搭真实服务器就用虚拟机或云服务器把服务部署、日志排查、权限管理完整走一遍。自己手动搭建一个 Web 服务Nginx MySQL 后端代码然后故意把它搞坏再修好。比如手动把权限改成 000、把端口占用、把磁盘写满、把 iptables 规则删掉再去定位问题。这个过程比看十遍教程都管用。练熟 Shell 和 Python 的文本处理。给你一份中文访问日志你能在 10 分钟内统计出 TOP 10 访问 IP、TOP 10 请求 URL、404 状态码总量。这几乎是笔试必考也是日常运维的高频技能。多读安全公告和运维事故复盘文章。理解真实世界的故障是怎么发生、怎么恢复的这比背大量面试题库收益高得多。看的时候问自己如果我在值班能不能发现这个问题。8.3 考场上的答法技巧笔试不只要会还得会写。我的几个建议能写命令就写命令比如回答排查思路时不写我需要查看磁盘使用情况而是直接写df -h、df -i、du -sh *。这会让阅卷人一眼确认你是真做过。答案要有顺序按排查链路来不要想到哪写到哪。比如先确认服务状态systemctl status xxx再查看日志journalctl -u xxx再检查端口ss -lntp这就是一个可执行的排障步骤而不是零散的知识点。不确定的答案不要只给一个。如果这道题有多种可能原因把可能性都列出来并说明你如何验证阅卷人会认为你考虑周全。涉及高危操作时务必列出安全措施。比如封禁 IP 时先确认不要误封自己的跳板机清理数据前先备份改防火墙前先评估影响面。这是最容易被忽视但最加分的地方。我当年面奇安信的时候笔试里有一道服务起不来的题我答了先看 systemd 状态再看 journalctl 日志然后还原故障现场的完整链路。后来面试官告诉我那道题其实最想看到的就是先确认服务是否在跑、再逐层查日志的排障顺序而不是直接甩一个命令。所以答题时别急把思路写得跟你在真实环境里一步步操作时一样清楚。8.4 最后说点实在的运维这个岗位的门槛是会命令天花板是能判断。笔试只是检验你日常积累的片段真正的功夫在每次排障中学到的链路和判断。准备的时候别纠结押题把基础打扎实遇到没见过的场景你也能靠通用的排查思路拉出答案。另外如果现在还有时间强烈建议你亲手搭一套实验环境一台 Linux 虚拟机装好 Nginx再用 Python 写一个简单的业务接口然后模拟一次从用户报障到定位根因的完整过程。这个过程走一遍你再看任何笔试场景题都不会慌了。一份试卷改变不了你的真实水平但它能告诉你接下来该往哪个方向补。希望这篇文章能帮你把复习的重心从背命令挪到建链路上——那才是运维工程师真正吃饭的本事。 
