1. 从一份真题反推运维笔试到底在筛什么人拿到这份试卷别急着刷题先想一个问题大厂技术运维岗在校招笔试里到底想从几千份简历里筛出什么样的人我的判断是三个能力基础扎实度、问题定位思维、脚本落地能力。这三点对应到试卷上就是操作系统、网络协议、数据库、脚本编程四大板块。很多人复习时喜欢追新框架、新工具但你看这类试卷就会发现出题人压根不跟你玩花活——问的全是底层原理和日常排障中真正会用到的东西。因为运维这个岗位线上出故障时没人给你百度时间基础不牢就是事故。所以这份试卷的价值不在于京东考过什么而在于它代表了大厂运维岗通用的能力评估模型。我基于真题考点结合这些年带新人和面试候选人的经验把考察逻辑、高频考点、备考方法完整拆一遍。无论你目标是头部电商、云厂商还是中型互联网公司这条主线都适用。2. 基础不牢地动山摇操作系统与Linux技能栈的考察核心2.1 进程管理不是背命令而是看你能不能定位问题Linux进程管理是笔试必考区出题方式很少直接问ps有哪些参数而是给一个场景让你判断系统状态。比如这道高频题某服务器响应缓慢执行uptime看到load average为8.32, 5.67, 3.21如何判断是CPU瓶颈还是IO瓶颈很多人只记住load高就是负载高这不够。load average是运行队列中可运行线程和不可中断睡眠线程的平均数三个值分别对应1分钟、5分钟、15分钟。如果1分钟值远高于15分钟值说明负载在上升如果三个值都高说明已经持续繁忙。接下来要区分CPU还是IO就得配合其他命令交叉验证先看top里 %Cpu(s) 行的 us、sy、wa、id。waiowait高说明磁盘IO在拖后腿us高说明用户态程序在密集计算。vmstat 1看r列运行队列和b列阻塞进程b列持续大于0说明有进程在等IO。iostat -x 1看 %util 和 await。%util 接近100%说明磁盘已经饱和await 明显升高说明IO响应延迟变大。pidstat -d 1按进程维度看IO使用能直接定位到是哪个进程在疯狂读写。把这条排查链路写清楚比死记十个命令参数有用得多。我面试时特别喜欢让候选人现场走一遍这个思路能流畅说出来的基本都是真在服务器上处理过问题的。2.2 进程状态与僵尸进程经典但每年都有人答错ps aux输出里的STAT列R、S、D、Z四种状态必须滚瓜烂熟。笔试常考的是D状态和Z状态的区别D是不可中断睡眠通常在做磁盘IO此时进程不能被信号杀死这是内核保证数据一致性的机制Z是僵尸进程表示子进程结束了但父进程还没调用wait()回收它的PCB信息。僵尸进程的考点在于为什么kill不掉因为僵尸进程已经死了kill对它无效真正要处理的是它的父进程。笔试里的标准解法是先ps -ef | grep defunct找到僵尸进程的PID和PPID再决定是重启父进程还是让它回收子进程。但如果父进程是init/systemd这类1号进程它一般会自动回收不用太担心。有一种情况容易翻车如果父进程本身是个长期运行的业务进程且代码有bug不回收子进程僵尸就会越积越多最终占满进程表。我在生产环境遇到过PID耗尽导致无法创建新进程的事故排查一圈最后发现就是某个Java服务没正确配置线程的销毁逻辑。所以真正负责任的处理方式不只是杀掉僵尸而是要推动修复父进程的代码缺陷。2.3 内存管理Swap、OOM Killer与性能评估内存这块笔试出现频率最高的是free命令的输出解读和Swap分区的作用。核心概念要懂buff/cache是内核用空闲内存做的缓存应用需要时可以回收所以free显示used高不等于内存不够。真正要警惕的是Swap使用率。Linux在内存紧张时会触发Swap换入换出而磁盘速度比内存慢几个数量级一旦开始大量swap服务性能会断崖式下降。用vmstat看si、so两列如果持续大于0说明内存在频繁换页必须扩容或优化应用内存占用。OOM Killer的触发逻辑也要了解当系统内存耗尽内核会根据oom_score选择进程杀掉。/var/log/messages或dmesg里会有Out of memory: Kill process记录。很多笔试会问如何避免关键进程被OOM杀掉答案是在systemd服务或/etc/sysctl.conf里设置oom_score_adj给关键服务降低被选中的概率。还有一道我印象深刻的场景题MySQL服务器内存占用持续走高用top发现mysqld的RES接近16G但服务器总内存只有16Gfree显示可用内存还剩2G此时该不该加内存这就是典型的没搞清楚内存统计口径的坑。RES里除了mysqld真实使用的内存还包括共享内存段。MySQL的innodb_buffer_pool_size设置的缓冲池会被算进RES但它是可回收的。所以正确做法是先看实际分配了多少cat /proc/meminfo里的CommitLimit和Committed_AS对比再结合SHOW ENGINE INNODB STATUS看buffer pool的命中率。命中率在99%以上说明缓冲池够用加内存纯属浪费。2.4 磁盘与文件系统从df到inode的完整判断链磁盘相关考点集中在df查空间、inode耗尽、RAID概念、fstab配置这几个方向。比较容易被坑的是inode耗尽——df -h显示还有几十G空间但应用就是报错No space left on device因为Inodes列已经满了。原因是大量小文件撑满了inode表。我在一次日志清理任务里踩过这个坑某个服务的logrotate配置失效日志文件只增不减每天生成几十万个几百字节的小文件一个月就把inode耗光了。所以笔试里问inode问题的本质是考察你有没有处理过小文件风暴这类真实场景。文件系统排查的推荐命令链是df -h看空间使用率。df -i看inode使用率。lsof L1看已删除但仍被进程占用的文件生产环境磁盘空间释放不了多半是这个原因。du -sh * | sort -hr | head -20按目录定位大文件。对于inode满的情况用for i in /data/log/*; do echo $i $(find $i | wc -l); done找出文件数最多的目录清理。RAID题考的是磁盘阵列基本原理RAID0条带化、RAID1镜像、RAID5分布式奇偶校验、RAID10先镜像再条带。笔试常问RAID5最少几块盘最多坏几块答案是至少3块、最多坏1块。如果大厂有存储方向会延伸问RAID5和RAID10的读写性能差异RAID10写性能更好因为写RAID5需要计算和写入校验信息。2.5 Linux启动流程与系统修复笔试里的送命题Linux开机流程是必考项顺序是BIOS/UEFI → GRUB引导 → 内核加载 → systemd(PID 1)启动 → 读取target单元 → 启动系统服务。真题喜欢考系统启动到一半卡住了如何排查这题其实是考你对每个阶段的日志位置熟不熟GRUB阶段引导不了看屏幕输出常见原因是grub.cfg配置错误或内核文件损坏需要进救援模式重装grub。内核阶段崩溃kernel panic看屏幕最后的堆栈常见是驱动不兼容或根文件系统损坏。systemd服务阶段查看执行日志journalctl -b定位是哪个unit启动失败。特别提醒千万别以为笔试只会靠默写启动顺序很多卷子会给你一个journalctl的报错片段让你判断服务起不来的原因。我遇到过一个casenginx起不来journalctl里报bind() to 0.0.0.0:80 failed (98: Address already in use)这就是典型的端口被占要么kill掉占用进程要么改nginx监听端口。这类题目就是考察你能不能从真实日志里快速定位根因不是靠背能解决的。3. 通不通就靠它网络原理与排障能力的实战考察3.1 TCP/IP协议栈三次握手和四次挥手必须倒背如流网络部分TCP三次握手和四次挥手是绝对的重点。但出题角度可能很刁钻比如在TCP连接建立过程中第三次握手失败客户端发出的ACK丢失服务端此时处于什么状态客户端会怎么做答案是服务端处于SYN_RECV状态会重传SYNACK默认最多重传5次。客户端因为已经进入ESTABLISHED状态如果此时发送数据服务端会回复RST客户端才会感知连接异常。这道题考的是对TCP状态机和超时重传机制的理解没有抓包分析过TCP状态变化的人很容易蒙圈。我的建议是复习时不要只看状态迁移图要配合抓包理解。在你自己的服务器上起一个nginx用tcpdump -i eth0 tcp port 80 -nn抓包然后浏览器访问一次你会清晰地看到三次握手的三个包SYN、SYNACK、ACK。四次挥手的FIN包也能看到。这样理解状态变化要比死记硬背深刻得多。高频考点还包括TIME_WAIT过多的问题。ss -ant里大量TIME_WAIT连接是短连接服务尤其是高并发Web的常见现象。解决问题的方式有几个层次最正确的方式是服务端开启SO_REUSEADDR让端口可以快速复用。Nginx、Tomcat都默认支持。如果确实因为短连接请求量太大导致TIME_WAIT堆积可以调整内核参数net.ipv4.tcp_tw_reuse1仅客户端可用、net.ipv4.tcp_fin_timeout30不要直接用tcp_tw_recycle这个参数在NAT环境下会引发严重问题。根本解法是改造应用用长连接减少连接建立和断开的频率。3.2 网络故障排查从ping到traceroute的完整思路笔试里经常出这样的场景题用户反馈无法访问应用服务器请描述你的排查过程。这类题没有标准答案但考察的是排查思路是否清晰。规范化流程应该是先确认物理链路ping目标IP不通则查网卡状态ip link、路由ip route、ARParp -n。链路通但端口不通telnet ip port或nc -vz ip port测试不通则检查防火墙iptables -L、firewall-cmd --list-all以及服务是否监听ss -lntp。从本机访问正常但外部访问异常检查安全组/防火墙白名单再看是否有负载均衡、CDN等中间链路。DNS排查dig或nslookup解析是否正常如果存在多级DNS需要逐级排查。应用层排查用curl加-v参数看完整请求过程看返回的HTTP状态码和耗时。这五步走完90%的连接问题都能定位。实际工作中很多新人一上来就重启服务重启大法有时候能解决但永远找不到根因下一回还会再爆。笔试里能把这套链路写完整的候选人我基本都会给高分。3.3 HTTP协议状态码、缓存与常见业务场景题HTTP协议是运维笔试必考因为Web运维每天都要跟状态码打交道。我整理了一张高频状态码对照表笔试前务必烂熟于心状态码含义常见场景200OK请求成功301Moved Permanently网站域名变更永久跳转302Found临时跳转比如未登录跳转登录页403Forbidden权限拒绝比如目录无索引文件且禁止列目录404Not Found请求资源不存在429Too Many Requests请求频率超过限流阈值500Internal Server Error服务端代码异常502Bad Gateway网关/代理收到上游无效响应比如后端服务挂了503Service Unavailable服务过载或维护中504Gateway Timeout网关请求上游超时面试真题里经常给一道502和504分别是什么原因的对比题。我个人的经验是502主要看后端服务进程是否存活、端口是否监听504则要看Nginx到后端的超时配置proxy_read_timeout是否过短以及后端处理请求是否确实超过预期。有一次线上504事故排查到最后发现是数据库连接池被打满后端服务在等待连接时超过Nginx超时时间。所以遇到504不能只调Nginx超时参数要顺着调用链往下查后端到底卡在哪里。另外Nginx的error.log里会有upstream timed out字样配合upstream_response_time变量能快速判断耗时分布。3.4 负载均衡与高可用从概念到配置的必会题笔试概念题喜欢考负载均衡算法轮询、加权轮询、最少连接、IP哈希、URL哈希。不仅要知道各自原理还要能说出适用场景。比如IP哈希适合需要session粘连的应用但它会带来负载不均因为某个IP段的请求可能特别多。Nginx的题也经常出现比如如何配置Nginx实现前端静态资源和后端动态请求的分离常规配置示例server { listen 80; server_name example.com; location /static/ { alias /data/www/static/; expires 7d; } location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }expires 7d是让浏览器强制缓存静态资源7天配合URL中带版本号的发布策略可以显著降低后端压力。这种常规优化思路笔试写到会加分因为说明你有性能意识。3.5 安全基线从安全组到系统加固的基础方向2019年的试卷里网络安全占比还不算高但近年来比重一直在上升。最基础的几个方向防火墙策略iptables和firewalld的基本使用常用场景是放行指定端口、限制来源IP。SSH安全加固禁用root远程登录PermitRootLogin no、修改默认端口、用密钥登录代替密码登录。最小权限原则给应用分配专用账号目录权限控制在需要的范围内。日志审计/var/log/secure、/var/log/messages定期检查关注异常登录和sudo记录。这部分题目的陷阱在于光会列措施不够还要知道为什么。比如为什么禁用root远程登录——因为root账号是暴力破解的首选目标而且一旦被攻破攻击者直接拿到最高权限。改成普通用户登录再sudo提权即使普通用户密码泄露也还有一层防线。4. 数据库与自动化拉开分差的实战硬功夫4.1 MySQL存储引擎、索引与事务的必考三件套数据库部分MySQL是绝对主角。核心考点集中在存储引擎、索引原理、事务隔离级别三块。存储引擎的题很简单InnoDB支持事务、行级锁、外键MyISAM只支持表级锁、不支持事务。但现在基本都默认InnoDB了MyISAM的考点更多是让你说出两者的区别来验证你用过MySQL。索引这块笔试的经典题是为什么索引能提高查询速度但不宜过多。底层原因是B树结构让查询从全表扫描O(N)变成树查找O(logN)。但索引过多会带来写入变慢、占用磁盘空间、优化器选择困难三个副作用。另一个高频题是索引失效场景对索引列使用函数或计算如WHERE DATE(create_time) 2024-01-01。前导模糊查询LIKE %abc后缀模糊不影响。隐式类型转换字段是varchar但查询条件写数字。联合索引不满足最左前缀原则。使用OR连接非索引列。事务隔离级别是必考中的必考读未提交、读已提交、可重复读、串行化。MySQL默认是可重复读通过MVCC实现快照读。笔试常问可重复读下如何避免幻读答案是InnoDB的间隙锁Gap Lock配合MVCC。但注意间隙锁只在RR级别生效而且对非索引列无法完全阻止幻读。4.2 SQL编写与优化笔试最容易拿分也最容易丢分的部分SQL题看起来简单但丢分点也不少。一份标准运维试卷里通常有两三道SQL编写题比如有一张用户表user(id, name, age, city)统计每个城市的平均年龄并筛选出平均年龄大于30的城市。标准答案SELECT city, AVG(age) AS avg_age FROM user GROUP BY city HAVING avg_age 30;陷阱是有人会写WHERE AVG(age) 30。聚合函数不能出现在WHERE子句里因为WHERE是在分组前过滤行HAVING是在分组后过滤组。这个基础概念不清楚笔试直接扣分。SQL优化的考点也常见这五类避免SELECT *只查需要的列减少网络传输和临时表体积。分页查询用WHERE id last_id ORDER BY id LIMIT 20代替LIMIT 100000, 20避免深分页导致的大量扫描。多表连接优先使用INNER JOIN明确连接条件小表驱动大表。EXPLAIN分析执行计划关注type列system const eq_ref ref range index ALLALL代表全表扫描要警惕。大批量更新/删除时分批处理比如每次5000条并注意在业务低峰期执行或者先记录row_count再操作。4.3 Shell与Python运维自动化的两条腿脚本编程是运维笔试拉开差距的关键板块。Shell脚本考得最基础的是这几种题型循环遍历文件并统计行数。用awk和sed处理日志。判断进程是否存在不存在则拉起。一道经典的真题编写脚本统计nginx访问日志中访问量最高的前10个IP。最简单的答案awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10这个组合看起来简单但考察了awk取列、sort排序、uniq去重计数、管道符串联、head取前N条五个知识点。如果笔试里要求在脚本中加上排除内网IP或者统计某个时间段内就再手动加一层过滤条件。Python在运维笔试里出现的频率逐年增加常见题目包括读取日志文件、正则提取关键字段、生成报告、调用API做自动化操作。一个模板级别的日志处理脚本import re from collections import Counter pattern re.compile(r(\d\.\d\.\d\.\d)) ip_counter Counter() with open(access.log, r) as f: for line in f: match pattern.match(line) if match: ip_counter[match.group(1)] 1 for ip, count in ip_counter.most_common(10): print(f{ip}\t{count})把这段吃透笔试Python题基本能覆盖一半。另一个高频方向是自动化巡检脚本用Python连接服务器跑命令、收集CPU/内存/磁盘数据、超过阈值告警。这其实就是运维自动化的雏形公司里最基础的自研监控系统都是这么起步的。4.4 监控与日志运维的眼睛和记忆监控系统的考点这几年越来越多2019年的试卷还比较基础但趋势已经很明显。常考的概念有监控的四个黄金信号——延迟、流量、错误、饱和度。这套理念来自Google SRE大厂运维岗基本都在用。具体工具层面Zabbix老牌监控适合服务器和网络设备监控有模板化的告警配置。Prometheus云原生时代标配基于pull模型抓取指标配合Grafana做可视化。笔试常问它的数据模型metric名label集合配合PromQL做查询。告警要义告警必须可执行。如果一个告警发出来没人知道怎么处理那它就是噪音。好的告警应该包含明确的问题范围、影响程度、排查入口看哪个面板、查哪条命令。日志这块重点是ELK三件套的基础架构Filebeat采集日志Logstash或Kafka做缓冲和清洗Elasticsearch存储并建立索引Kibana做搜索和可视化。考察点常落在日志写入ES的性能优化上——批量写入比单条写入快几十倍、合理设置分片数和副本数、按时间戳索引并定期删除过期索引。5. 从真题到实战备考策略与现场答题技巧5.1 给不同基础候选人的备考路线基础没打牢的拿一本《鸟哥的Linux私房菜》配合《高性能MySQL》和Wireshark官方文档把命令和原理过一遍这个阶段别追求快要追求每条命令都知道自己在干什么。已经具备基本能力的重点放在场景题训练上。找一台测试服务器故意制造故障把磁盘写满、把端口占用、把Nginx配置写错、把MySQL慢查询打开。然后一个个排查修复。这个过程模拟的是面试的核心考点——故障定位能力。笔试里所有题目本质上都是在纸上模拟你排查线上故障的过程。想冲大厂offer的还要补充SRE知识体系监控体系设计、容量规划、故障应急响应流程、混沌工程。这些虽然是云厂商的考察重点但头部互联网公司近两年也在逐步加码。另外Docker和Kubernetes的普及已经改变了运维的工作方式容器化部署、Pod调度、服务发现这些题出现的概率越来越高。即使笔试不考面试环节基本必问。5.2 答题策略这样写答案更容易拿高分笔试不是玩玄学答题也有方法论。我改过不少校招卷子同样是会做的题目得分差距很大核心差别在表达方式。一条最重要的原则能写命令就写命令能画流程就画流程然后再用文字解释。比如问如何排查服务器负载过高只写使用top查看和写先用uptime看load趋势再用top按CPU排序找出消耗最高的进程再用pidstat确认线程与IO情况最后结合iostat判断是否磁盘瓶颈是完全不同的得分档次。后者展示了完整的排查链路而前者只展示了你会用一个命令。答题还要注意从现象到本质的递进逻辑。比如回答僵尸进程如何产生及如何解决不要只回答父进程没调用wait要展开先描述产生机制子进程结束父进程未回收PCB再给排查命令ps -ef | grep defunct再给解决方案处理父进程、重启服务最后加一句如果父进程是1号进程系统会自动清理不需要人工干预。一个完整的逻辑链比零散的要点更能证明你的系统性思维。5.3 高频易错点复盘我在阅卷时最常看到的翻车之处最后按个人阅卷经验把考生最常踩的坑集中复盘一遍。这些错误在真实生产环境里也容易犯笔试里出现纯粹是基础不牢或审题不清free命令的可用内存算错。有人说free显示used很高说明内存不够。正确理解是used中包含buff/cache而buff/cache可回收。要看真实的可用内存应该看available列在较新的free输出中已经单列。分不清软链接和硬链接。软链接是独立文件存储目标文件的路径硬链接是同一个inode的多个目录项删除任意一个不影响其他。笔试爱考的是删除源文件后软链接失效但硬链接仍可访问——因为硬链接指向的是同一个inode。TCP的TIME_WAIT作用搞错。TIME_WAIT不是为了处理最后一个ACK丢失虽然官方描述里包含这个原因更重要的作用是让旧连接的延迟报文在网络中自然消失防止它们干扰新连接。HTTP 301和302选错。如果是SEO相关的场景题用301做永久迁移、302做临时跳转如果是登录态跳转一般用302。awk和sed分不清。awk擅长列处理sed擅长行处理。很多人在笔试里把awk {print $2}写成sed {print $2}直接扣分。5.4 这份试卷给我的最大启示运维已经不再是会重启就行的岗位把2019年的卷子和现在的招聘要求放一起看能清楚看到一条演进曲线过去的运维岗核心是会装系统、会配网络、会看日志现在的技术运维核心是懂架构、能写代码、会做容量规划、能设计自动化平台。具体到这个行业的技术栈主线我列一下个人认为最重要的清单供参考Linux基础进程、内存、磁盘、网络、权限管理命令只是载体核心是理解内核行为。网络运维TCP/IP协议栈、HTTP、DNS、负载均衡、安全组/防火墙策略。网络不通时能快速定位是哪一层的问题。数据库MySQL索引与事务、SQL调优、备份恢复以及Redis等缓存的常规运维。脚本与自动化Shell Python能独立完成日志分析、自动化巡检、批量操作、故障自愈脚本。监控告警至少熟练使用一个监控系统能自主设计监控项、告警阈值和恢复策略。容器与云原生Docker、Kubernetes、CI/CD流水线。这项现在已从加分项变成必备项。这六条主线覆盖了从基础平台到上层应用的日常运维场景。建议在校生或刚入行的朋友把这六条主线当成一份技能对标表逐项自测缺哪补哪。笔试不过是一次系统性的自我体检真正要长期坚持的是保持对新架构、新工具、新方法论的学习。运维这个行当的好玩之处就在于你永远有学不完的新东西也永远有处理不完的真实事故每一次处理完你都会比昨天更强一点。 大厂运维笔试高频考点解析：从Linux到数据库的备考指南
1. 从一份真题反推运维笔试到底在筛什么人拿到这份试卷别急着刷题先想一个问题大厂技术运维岗在校招笔试里到底想从几千份简历里筛出什么样的人我的判断是三个能力基础扎实度、问题定位思维、脚本落地能力。这三点对应到试卷上就是操作系统、网络协议、数据库、脚本编程四大板块。很多人复习时喜欢追新框架、新工具但你看这类试卷就会发现出题人压根不跟你玩花活——问的全是底层原理和日常排障中真正会用到的东西。因为运维这个岗位线上出故障时没人给你百度时间基础不牢就是事故。所以这份试卷的价值不在于京东考过什么而在于它代表了大厂运维岗通用的能力评估模型。我基于真题考点结合这些年带新人和面试候选人的经验把考察逻辑、高频考点、备考方法完整拆一遍。无论你目标是头部电商、云厂商还是中型互联网公司这条主线都适用。2. 基础不牢地动山摇操作系统与Linux技能栈的考察核心2.1 进程管理不是背命令而是看你能不能定位问题Linux进程管理是笔试必考区出题方式很少直接问ps有哪些参数而是给一个场景让你判断系统状态。比如这道高频题某服务器响应缓慢执行uptime看到load average为8.32, 5.67, 3.21如何判断是CPU瓶颈还是IO瓶颈很多人只记住load高就是负载高这不够。load average是运行队列中可运行线程和不可中断睡眠线程的平均数三个值分别对应1分钟、5分钟、15分钟。如果1分钟值远高于15分钟值说明负载在上升如果三个值都高说明已经持续繁忙。接下来要区分CPU还是IO就得配合其他命令交叉验证先看top里 %Cpu(s) 行的 us、sy、wa、id。waiowait高说明磁盘IO在拖后腿us高说明用户态程序在密集计算。vmstat 1看r列运行队列和b列阻塞进程b列持续大于0说明有进程在等IO。iostat -x 1看 %util 和 await。%util 接近100%说明磁盘已经饱和await 明显升高说明IO响应延迟变大。pidstat -d 1按进程维度看IO使用能直接定位到是哪个进程在疯狂读写。把这条排查链路写清楚比死记十个命令参数有用得多。我面试时特别喜欢让候选人现场走一遍这个思路能流畅说出来的基本都是真在服务器上处理过问题的。2.2 进程状态与僵尸进程经典但每年都有人答错ps aux输出里的STAT列R、S、D、Z四种状态必须滚瓜烂熟。笔试常考的是D状态和Z状态的区别D是不可中断睡眠通常在做磁盘IO此时进程不能被信号杀死这是内核保证数据一致性的机制Z是僵尸进程表示子进程结束了但父进程还没调用wait()回收它的PCB信息。僵尸进程的考点在于为什么kill不掉因为僵尸进程已经死了kill对它无效真正要处理的是它的父进程。笔试里的标准解法是先ps -ef | grep defunct找到僵尸进程的PID和PPID再决定是重启父进程还是让它回收子进程。但如果父进程是init/systemd这类1号进程它一般会自动回收不用太担心。有一种情况容易翻车如果父进程本身是个长期运行的业务进程且代码有bug不回收子进程僵尸就会越积越多最终占满进程表。我在生产环境遇到过PID耗尽导致无法创建新进程的事故排查一圈最后发现就是某个Java服务没正确配置线程的销毁逻辑。所以真正负责任的处理方式不只是杀掉僵尸而是要推动修复父进程的代码缺陷。2.3 内存管理Swap、OOM Killer与性能评估内存这块笔试出现频率最高的是free命令的输出解读和Swap分区的作用。核心概念要懂buff/cache是内核用空闲内存做的缓存应用需要时可以回收所以free显示used高不等于内存不够。真正要警惕的是Swap使用率。Linux在内存紧张时会触发Swap换入换出而磁盘速度比内存慢几个数量级一旦开始大量swap服务性能会断崖式下降。用vmstat看si、so两列如果持续大于0说明内存在频繁换页必须扩容或优化应用内存占用。OOM Killer的触发逻辑也要了解当系统内存耗尽内核会根据oom_score选择进程杀掉。/var/log/messages或dmesg里会有Out of memory: Kill process记录。很多笔试会问如何避免关键进程被OOM杀掉答案是在systemd服务或/etc/sysctl.conf里设置oom_score_adj给关键服务降低被选中的概率。还有一道我印象深刻的场景题MySQL服务器内存占用持续走高用top发现mysqld的RES接近16G但服务器总内存只有16Gfree显示可用内存还剩2G此时该不该加内存这就是典型的没搞清楚内存统计口径的坑。RES里除了mysqld真实使用的内存还包括共享内存段。MySQL的innodb_buffer_pool_size设置的缓冲池会被算进RES但它是可回收的。所以正确做法是先看实际分配了多少cat /proc/meminfo里的CommitLimit和Committed_AS对比再结合SHOW ENGINE INNODB STATUS看buffer pool的命中率。命中率在99%以上说明缓冲池够用加内存纯属浪费。2.4 磁盘与文件系统从df到inode的完整判断链磁盘相关考点集中在df查空间、inode耗尽、RAID概念、fstab配置这几个方向。比较容易被坑的是inode耗尽——df -h显示还有几十G空间但应用就是报错No space left on device因为Inodes列已经满了。原因是大量小文件撑满了inode表。我在一次日志清理任务里踩过这个坑某个服务的logrotate配置失效日志文件只增不减每天生成几十万个几百字节的小文件一个月就把inode耗光了。所以笔试里问inode问题的本质是考察你有没有处理过小文件风暴这类真实场景。文件系统排查的推荐命令链是df -h看空间使用率。df -i看inode使用率。lsof L1看已删除但仍被进程占用的文件生产环境磁盘空间释放不了多半是这个原因。du -sh * | sort -hr | head -20按目录定位大文件。对于inode满的情况用for i in /data/log/*; do echo $i $(find $i | wc -l); done找出文件数最多的目录清理。RAID题考的是磁盘阵列基本原理RAID0条带化、RAID1镜像、RAID5分布式奇偶校验、RAID10先镜像再条带。笔试常问RAID5最少几块盘最多坏几块答案是至少3块、最多坏1块。如果大厂有存储方向会延伸问RAID5和RAID10的读写性能差异RAID10写性能更好因为写RAID5需要计算和写入校验信息。2.5 Linux启动流程与系统修复笔试里的送命题Linux开机流程是必考项顺序是BIOS/UEFI → GRUB引导 → 内核加载 → systemd(PID 1)启动 → 读取target单元 → 启动系统服务。真题喜欢考系统启动到一半卡住了如何排查这题其实是考你对每个阶段的日志位置熟不熟GRUB阶段引导不了看屏幕输出常见原因是grub.cfg配置错误或内核文件损坏需要进救援模式重装grub。内核阶段崩溃kernel panic看屏幕最后的堆栈常见是驱动不兼容或根文件系统损坏。systemd服务阶段查看执行日志journalctl -b定位是哪个unit启动失败。特别提醒千万别以为笔试只会靠默写启动顺序很多卷子会给你一个journalctl的报错片段让你判断服务起不来的原因。我遇到过一个casenginx起不来journalctl里报bind() to 0.0.0.0:80 failed (98: Address already in use)这就是典型的端口被占要么kill掉占用进程要么改nginx监听端口。这类题目就是考察你能不能从真实日志里快速定位根因不是靠背能解决的。3. 通不通就靠它网络原理与排障能力的实战考察3.1 TCP/IP协议栈三次握手和四次挥手必须倒背如流网络部分TCP三次握手和四次挥手是绝对的重点。但出题角度可能很刁钻比如在TCP连接建立过程中第三次握手失败客户端发出的ACK丢失服务端此时处于什么状态客户端会怎么做答案是服务端处于SYN_RECV状态会重传SYNACK默认最多重传5次。客户端因为已经进入ESTABLISHED状态如果此时发送数据服务端会回复RST客户端才会感知连接异常。这道题考的是对TCP状态机和超时重传机制的理解没有抓包分析过TCP状态变化的人很容易蒙圈。我的建议是复习时不要只看状态迁移图要配合抓包理解。在你自己的服务器上起一个nginx用tcpdump -i eth0 tcp port 80 -nn抓包然后浏览器访问一次你会清晰地看到三次握手的三个包SYN、SYNACK、ACK。四次挥手的FIN包也能看到。这样理解状态变化要比死记硬背深刻得多。高频考点还包括TIME_WAIT过多的问题。ss -ant里大量TIME_WAIT连接是短连接服务尤其是高并发Web的常见现象。解决问题的方式有几个层次最正确的方式是服务端开启SO_REUSEADDR让端口可以快速复用。Nginx、Tomcat都默认支持。如果确实因为短连接请求量太大导致TIME_WAIT堆积可以调整内核参数net.ipv4.tcp_tw_reuse1仅客户端可用、net.ipv4.tcp_fin_timeout30不要直接用tcp_tw_recycle这个参数在NAT环境下会引发严重问题。根本解法是改造应用用长连接减少连接建立和断开的频率。3.2 网络故障排查从ping到traceroute的完整思路笔试里经常出这样的场景题用户反馈无法访问应用服务器请描述你的排查过程。这类题没有标准答案但考察的是排查思路是否清晰。规范化流程应该是先确认物理链路ping目标IP不通则查网卡状态ip link、路由ip route、ARParp -n。链路通但端口不通telnet ip port或nc -vz ip port测试不通则检查防火墙iptables -L、firewall-cmd --list-all以及服务是否监听ss -lntp。从本机访问正常但外部访问异常检查安全组/防火墙白名单再看是否有负载均衡、CDN等中间链路。DNS排查dig或nslookup解析是否正常如果存在多级DNS需要逐级排查。应用层排查用curl加-v参数看完整请求过程看返回的HTTP状态码和耗时。这五步走完90%的连接问题都能定位。实际工作中很多新人一上来就重启服务重启大法有时候能解决但永远找不到根因下一回还会再爆。笔试里能把这套链路写完整的候选人我基本都会给高分。3.3 HTTP协议状态码、缓存与常见业务场景题HTTP协议是运维笔试必考因为Web运维每天都要跟状态码打交道。我整理了一张高频状态码对照表笔试前务必烂熟于心状态码含义常见场景200OK请求成功301Moved Permanently网站域名变更永久跳转302Found临时跳转比如未登录跳转登录页403Forbidden权限拒绝比如目录无索引文件且禁止列目录404Not Found请求资源不存在429Too Many Requests请求频率超过限流阈值500Internal Server Error服务端代码异常502Bad Gateway网关/代理收到上游无效响应比如后端服务挂了503Service Unavailable服务过载或维护中504Gateway Timeout网关请求上游超时面试真题里经常给一道502和504分别是什么原因的对比题。我个人的经验是502主要看后端服务进程是否存活、端口是否监听504则要看Nginx到后端的超时配置proxy_read_timeout是否过短以及后端处理请求是否确实超过预期。有一次线上504事故排查到最后发现是数据库连接池被打满后端服务在等待连接时超过Nginx超时时间。所以遇到504不能只调Nginx超时参数要顺着调用链往下查后端到底卡在哪里。另外Nginx的error.log里会有upstream timed out字样配合upstream_response_time变量能快速判断耗时分布。3.4 负载均衡与高可用从概念到配置的必会题笔试概念题喜欢考负载均衡算法轮询、加权轮询、最少连接、IP哈希、URL哈希。不仅要知道各自原理还要能说出适用场景。比如IP哈希适合需要session粘连的应用但它会带来负载不均因为某个IP段的请求可能特别多。Nginx的题也经常出现比如如何配置Nginx实现前端静态资源和后端动态请求的分离常规配置示例server { listen 80; server_name example.com; location /static/ { alias /data/www/static/; expires 7d; } location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }expires 7d是让浏览器强制缓存静态资源7天配合URL中带版本号的发布策略可以显著降低后端压力。这种常规优化思路笔试写到会加分因为说明你有性能意识。3.5 安全基线从安全组到系统加固的基础方向2019年的试卷里网络安全占比还不算高但近年来比重一直在上升。最基础的几个方向防火墙策略iptables和firewalld的基本使用常用场景是放行指定端口、限制来源IP。SSH安全加固禁用root远程登录PermitRootLogin no、修改默认端口、用密钥登录代替密码登录。最小权限原则给应用分配专用账号目录权限控制在需要的范围内。日志审计/var/log/secure、/var/log/messages定期检查关注异常登录和sudo记录。这部分题目的陷阱在于光会列措施不够还要知道为什么。比如为什么禁用root远程登录——因为root账号是暴力破解的首选目标而且一旦被攻破攻击者直接拿到最高权限。改成普通用户登录再sudo提权即使普通用户密码泄露也还有一层防线。4. 数据库与自动化拉开分差的实战硬功夫4.1 MySQL存储引擎、索引与事务的必考三件套数据库部分MySQL是绝对主角。核心考点集中在存储引擎、索引原理、事务隔离级别三块。存储引擎的题很简单InnoDB支持事务、行级锁、外键MyISAM只支持表级锁、不支持事务。但现在基本都默认InnoDB了MyISAM的考点更多是让你说出两者的区别来验证你用过MySQL。索引这块笔试的经典题是为什么索引能提高查询速度但不宜过多。底层原因是B树结构让查询从全表扫描O(N)变成树查找O(logN)。但索引过多会带来写入变慢、占用磁盘空间、优化器选择困难三个副作用。另一个高频题是索引失效场景对索引列使用函数或计算如WHERE DATE(create_time) 2024-01-01。前导模糊查询LIKE %abc后缀模糊不影响。隐式类型转换字段是varchar但查询条件写数字。联合索引不满足最左前缀原则。使用OR连接非索引列。事务隔离级别是必考中的必考读未提交、读已提交、可重复读、串行化。MySQL默认是可重复读通过MVCC实现快照读。笔试常问可重复读下如何避免幻读答案是InnoDB的间隙锁Gap Lock配合MVCC。但注意间隙锁只在RR级别生效而且对非索引列无法完全阻止幻读。4.2 SQL编写与优化笔试最容易拿分也最容易丢分的部分SQL题看起来简单但丢分点也不少。一份标准运维试卷里通常有两三道SQL编写题比如有一张用户表user(id, name, age, city)统计每个城市的平均年龄并筛选出平均年龄大于30的城市。标准答案SELECT city, AVG(age) AS avg_age FROM user GROUP BY city HAVING avg_age 30;陷阱是有人会写WHERE AVG(age) 30。聚合函数不能出现在WHERE子句里因为WHERE是在分组前过滤行HAVING是在分组后过滤组。这个基础概念不清楚笔试直接扣分。SQL优化的考点也常见这五类避免SELECT *只查需要的列减少网络传输和临时表体积。分页查询用WHERE id last_id ORDER BY id LIMIT 20代替LIMIT 100000, 20避免深分页导致的大量扫描。多表连接优先使用INNER JOIN明确连接条件小表驱动大表。EXPLAIN分析执行计划关注type列system const eq_ref ref range index ALLALL代表全表扫描要警惕。大批量更新/删除时分批处理比如每次5000条并注意在业务低峰期执行或者先记录row_count再操作。4.3 Shell与Python运维自动化的两条腿脚本编程是运维笔试拉开差距的关键板块。Shell脚本考得最基础的是这几种题型循环遍历文件并统计行数。用awk和sed处理日志。判断进程是否存在不存在则拉起。一道经典的真题编写脚本统计nginx访问日志中访问量最高的前10个IP。最简单的答案awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10这个组合看起来简单但考察了awk取列、sort排序、uniq去重计数、管道符串联、head取前N条五个知识点。如果笔试里要求在脚本中加上排除内网IP或者统计某个时间段内就再手动加一层过滤条件。Python在运维笔试里出现的频率逐年增加常见题目包括读取日志文件、正则提取关键字段、生成报告、调用API做自动化操作。一个模板级别的日志处理脚本import re from collections import Counter pattern re.compile(r(\d\.\d\.\d\.\d)) ip_counter Counter() with open(access.log, r) as f: for line in f: match pattern.match(line) if match: ip_counter[match.group(1)] 1 for ip, count in ip_counter.most_common(10): print(f{ip}\t{count})把这段吃透笔试Python题基本能覆盖一半。另一个高频方向是自动化巡检脚本用Python连接服务器跑命令、收集CPU/内存/磁盘数据、超过阈值告警。这其实就是运维自动化的雏形公司里最基础的自研监控系统都是这么起步的。4.4 监控与日志运维的眼睛和记忆监控系统的考点这几年越来越多2019年的试卷还比较基础但趋势已经很明显。常考的概念有监控的四个黄金信号——延迟、流量、错误、饱和度。这套理念来自Google SRE大厂运维岗基本都在用。具体工具层面Zabbix老牌监控适合服务器和网络设备监控有模板化的告警配置。Prometheus云原生时代标配基于pull模型抓取指标配合Grafana做可视化。笔试常问它的数据模型metric名label集合配合PromQL做查询。告警要义告警必须可执行。如果一个告警发出来没人知道怎么处理那它就是噪音。好的告警应该包含明确的问题范围、影响程度、排查入口看哪个面板、查哪条命令。日志这块重点是ELK三件套的基础架构Filebeat采集日志Logstash或Kafka做缓冲和清洗Elasticsearch存储并建立索引Kibana做搜索和可视化。考察点常落在日志写入ES的性能优化上——批量写入比单条写入快几十倍、合理设置分片数和副本数、按时间戳索引并定期删除过期索引。5. 从真题到实战备考策略与现场答题技巧5.1 给不同基础候选人的备考路线基础没打牢的拿一本《鸟哥的Linux私房菜》配合《高性能MySQL》和Wireshark官方文档把命令和原理过一遍这个阶段别追求快要追求每条命令都知道自己在干什么。已经具备基本能力的重点放在场景题训练上。找一台测试服务器故意制造故障把磁盘写满、把端口占用、把Nginx配置写错、把MySQL慢查询打开。然后一个个排查修复。这个过程模拟的是面试的核心考点——故障定位能力。笔试里所有题目本质上都是在纸上模拟你排查线上故障的过程。想冲大厂offer的还要补充SRE知识体系监控体系设计、容量规划、故障应急响应流程、混沌工程。这些虽然是云厂商的考察重点但头部互联网公司近两年也在逐步加码。另外Docker和Kubernetes的普及已经改变了运维的工作方式容器化部署、Pod调度、服务发现这些题出现的概率越来越高。即使笔试不考面试环节基本必问。5.2 答题策略这样写答案更容易拿高分笔试不是玩玄学答题也有方法论。我改过不少校招卷子同样是会做的题目得分差距很大核心差别在表达方式。一条最重要的原则能写命令就写命令能画流程就画流程然后再用文字解释。比如问如何排查服务器负载过高只写使用top查看和写先用uptime看load趋势再用top按CPU排序找出消耗最高的进程再用pidstat确认线程与IO情况最后结合iostat判断是否磁盘瓶颈是完全不同的得分档次。后者展示了完整的排查链路而前者只展示了你会用一个命令。答题还要注意从现象到本质的递进逻辑。比如回答僵尸进程如何产生及如何解决不要只回答父进程没调用wait要展开先描述产生机制子进程结束父进程未回收PCB再给排查命令ps -ef | grep defunct再给解决方案处理父进程、重启服务最后加一句如果父进程是1号进程系统会自动清理不需要人工干预。一个完整的逻辑链比零散的要点更能证明你的系统性思维。5.3 高频易错点复盘我在阅卷时最常看到的翻车之处最后按个人阅卷经验把考生最常踩的坑集中复盘一遍。这些错误在真实生产环境里也容易犯笔试里出现纯粹是基础不牢或审题不清free命令的可用内存算错。有人说free显示used很高说明内存不够。正确理解是used中包含buff/cache而buff/cache可回收。要看真实的可用内存应该看available列在较新的free输出中已经单列。分不清软链接和硬链接。软链接是独立文件存储目标文件的路径硬链接是同一个inode的多个目录项删除任意一个不影响其他。笔试爱考的是删除源文件后软链接失效但硬链接仍可访问——因为硬链接指向的是同一个inode。TCP的TIME_WAIT作用搞错。TIME_WAIT不是为了处理最后一个ACK丢失虽然官方描述里包含这个原因更重要的作用是让旧连接的延迟报文在网络中自然消失防止它们干扰新连接。HTTP 301和302选错。如果是SEO相关的场景题用301做永久迁移、302做临时跳转如果是登录态跳转一般用302。awk和sed分不清。awk擅长列处理sed擅长行处理。很多人在笔试里把awk {print $2}写成sed {print $2}直接扣分。5.4 这份试卷给我的最大启示运维已经不再是会重启就行的岗位把2019年的卷子和现在的招聘要求放一起看能清楚看到一条演进曲线过去的运维岗核心是会装系统、会配网络、会看日志现在的技术运维核心是懂架构、能写代码、会做容量规划、能设计自动化平台。具体到这个行业的技术栈主线我列一下个人认为最重要的清单供参考Linux基础进程、内存、磁盘、网络、权限管理命令只是载体核心是理解内核行为。网络运维TCP/IP协议栈、HTTP、DNS、负载均衡、安全组/防火墙策略。网络不通时能快速定位是哪一层的问题。数据库MySQL索引与事务、SQL调优、备份恢复以及Redis等缓存的常规运维。脚本与自动化Shell Python能独立完成日志分析、自动化巡检、批量操作、故障自愈脚本。监控告警至少熟练使用一个监控系统能自主设计监控项、告警阈值和恢复策略。容器与云原生Docker、Kubernetes、CI/CD流水线。这项现在已从加分项变成必备项。这六条主线覆盖了从基础平台到上层应用的日常运维场景。建议在校生或刚入行的朋友把这六条主线当成一份技能对标表逐项自测缺哪补哪。笔试不过是一次系统性的自我体检真正要长期坚持的是保持对新架构、新工具、新方法论的学习。运维这个行当的好玩之处就在于你永远有学不完的新东西也永远有处理不完的真实事故每一次处理完你都会比昨天更强一点。