京东2019校招运维工程师笔试我当年也参加过类似的场次。说实话这类大厂校招笔试题在圈内流传度一直很高尤其在运维这个方向很多同学拿到卷子第一反应是“这考的也太杂了”。但如果你真把题目拆开看会发现它并不是单纯考知识点的死记硬背而是在模拟一个真实运维工作日里你会遇到的各种问题。这篇文章不打算给你贴任何所谓的原题答案因为大厂题库每年都在变刷题没有终局。我会结合京东2019这次笔试的题目结构以及我这些年做运维、带校招生的经验把这类笔试背后的考察逻辑、核心知识点、答题思路和备考路径完整拆一遍。内容比较长但每一节都能直接拿来当复习大纲用。1. 笔试整体设计与考点分布京东到底想招什么样的运维先说一个很多人容易误解的事情大厂校招笔试不是期末考试它不追求“满分”追求的是在有限时间内判断你的“运维思维”是否成型。京东这种体量的互联网公司笔试题目设计通常会分为几个固定模块计算机基础、Linux与操作系统、网络基础、脚本与自动化、数据库、监控与故障排查以及最后的大题——通常是场景设计或故障复盘。这个结构非常典型。它对应的不是某个具体岗位的技能清单而是一个互联网业务每天都会经历的链路请求从客户端发出经过DNS解析、负载均衡、Web服务、应用逻辑、缓存、数据库最后落盘。任何一个环节出问题运维都要能接得住。所以笔试考点分布基本就是按这个链路铺开的。1.1 题型分布与分值逻辑从2019年那批题目来看整体分成三大部分单选题和多选题覆盖Linux命令、网络协议、数据库基础、文件系统、进程管理等大概占40分。这部分拼的是底子牢不牢基本概念清不清楚。填空题和简答题比如“Linux中如何查看端口被哪个进程占用”“写出iptables的常用命令”“解释一下软链接和硬链接的区别”这类题目占30分左右。它考的不是会不会用而是你能不能把原理说清楚。综合题与场景题这部分分值看似只有30分但往往是决定你能不能进面试的分水岭。题目通常会给你一个场景比如“线上接口突然超时请写出排查思路”或“设计一套支撑双11大促的监控告警方案”。很多同学容易犯的毛病是在选择题上死磕时间结果最后的大题草草写几句话就交卷。但实际上大厂笔试阅卷时综合题的分数权重远高于前面客观题。因为客观题只能筛掉完全不会的人而场景题才能看出你有没有真正的运维思维。1.2 大厂运维笔试背后的选人标准我在参与校招面试时经常听到面试官这样评价一份笔试答卷“这人的题都答对了但感觉就是个做题的。”这句话的潜台词是你虽然能把知识点背出来但缺乏把知识串联起来解决实际问题的能力。京东2019那批笔试题目里有个很典型的例子选择题考了“TCP的三次握手和四次挥手”简答题又考了“TIME_WAIT状态过多时如何排查”。如果你只把三次握手背得滚瓜烂熟看到TIME_WAIT那题基本会懵。但如果你平时真正排过线上问题就会知道TIME_WAIT过多通常出现在高并发的短连接场景排查时会用netstat或ss统计连接状态优化方向则是调整内核参数或改为长连接。这就是笔试设计的真正用意知识点只是载体判断你是否具备“从现象到根因”的排查思维才是核心目标。所以你在复习时不能只看单个命令的用法要把命令放到故障场景里去理解它为什么存在。2. 核心题型深度拆解每一类都靠什么拿分这里我按模块把高频考点和答题思路展开讲。每一个模块我都会给出考察意图、难点在哪里、以及我当时总结下来的答题话术。2.1 Linux命令与文件系统送分题里的陷阱Linux是运维的基本盘笔试里这块占比最高。但越基础的东西越容易出陷阱题。比如软链接和硬链接的区别这道题几乎年年有。常规答案是硬链接指向同一个inode软链接指向的是路径。但这只答对了一半。笔试如果想拿高分要补充答出硬链接不能跨文件系统创建、不能对目录创建除非是特殊场景如mount bind硬链接的link count会随链接数增加而软链接是一个独立的文件有自己的inode原始文件被删除后软链接就失效了硬链接却不受影响。还有一道经典题是“Linux系统里rm掉一个正在被进程打开的文件会发生什么”。很多新人会答“文件被删除了”但实际上文件仍然存在于磁盘上inode没有被释放只是目录项被删除了直到那个进程关闭文件句柄空间才会真正释放。这个知识点在日志文件清理场景里特别重要——如果你直接rm正在写入的日志文件磁盘空间往往不会立刻释放因为进程还握着文件句柄。再比如inode耗尽的问题。笔试经常给一个场景“df -h 显示磁盘还有50G空间但就是无法创建新文件为什么”答案就是inode耗尽了。排查命令是df -i处理方式通常是删除大量小文件或者查找哪个目录堆积了海量碎片文件。这类题目看起来是考命令其实考的是文件系统的整体运作机制。2.2 网络基础与排查命令必考的排障思维网络模块是笔试的另一大重心而且出题方式往往很“实战化”。基础题会考TCP/UDP的区别、OSI七层模型、DNS解析流程进阶题就会直接给一个故障场景让你排查。DNS解析流程是高频题比如“用户在浏览器输入一个域名到页面出现中间经历了什么”。完整链路是浏览器缓存、操作系统hosts和系统缓存、本地DNS服务器LDNS、根DNS服务器、顶级域TLD服务器、权威DNS服务器然后递归返回IP。答题时最好按这个顺序写清楚并补充说明DNS使用UDP 53端口但区域传送使用TCP 53。这些细节才体现出你真正理解原理。还有一类高频题是“端口排查”。场景化命题常是“线上服务报错连接超时如何排查端口连通性”基础命令有telnet、nc、ss、netstat进阶的会用tcpdump抓包确认TCP三次握手是否完成。如果再深入一点可能会问“为什么SYN_SENT状态一直存在”。原因可能是防火墙丢包、目标端口未监听、网络路由问题这时候要用ping验证连通性、telnet测试端口、tcpdump抓包看SYN包是否有回应层层排查。TIME_WAIT相关我也提一下这基本是网络模块的压轴题。答这道题要分三步先说清楚TIME_WAIT发生在四次挥手的哪个阶段、为什么主动关闭方要维持TIME_WAIT保证最后一个ACK能够被收到、让旧数据包过期失效再给出排查命令netstat -n | awk /^tcp/ {print $6} | sort | uniq -c | sort -rn最后说优化方案开启tcp_tw_reuse和tcp_tw_recycle注意后者要慎用、调整tcp_fin_timeout、或者把短连接改成长连接。能答到这个层次这道题的分数基本就拿到了。2.3 Shell脚本与自动化笔试里的拉分项Shell脚本在笔试中占的分值可能不高但却是真正拉开差距的地方。常考题型有几种统计日志里某个关键字出现的次数、批量修改文件名、找出大于某个大小的文件并清理、写一个简单的监控脚本。给你一道典型的真题模式“写一个脚本统计nginx访问日志中访问量前10的IP并输出访问次数。”核心命令复杂度并不算高就是一个awk加sort加uniq加head的管道awk {print $1} access.log | sort | uniq -c | sort -rn | head -10但笔试往往不满足于此它会在旁边加一问“如果日志文件非常大比如几十GB上面的命令会出现什么问题怎么优化”这就在考察你是否考虑到CPU和内存开销、磁盘Io瓶颈。优化方向可以是分批统计再用awk合并或者是用大数据路线走离线分析甚至是不落盘直接做流式处理。还有一类常考的是“找出当前目录下大于100M的文件并清理7天前的旧文件”find /data/logs -type f -size 100M -mtime 7 -exec rm -f {} \;很多人在笔试里只写find命令本身但加一个-print或-exec的处理会让答案完整很多。另外我在实际批改时发现很多人写脚本完全不考虑变量加引号的问题比如rm -rf $dir如果我手动执行那可能没事但放到脚本里一旦变量为空这行就变成rm -rf后果不堪设想。笔试里如果你能在脚本中加入判断变量是否为空的保护逻辑会让面试官觉得你有生产安全意识。2.4 MySQL数据库必问的索引与锁数据库在运维笔试里主要集中在MySQL。原因很简单互联网业务最常用的关系型数据库就是MySQL而且运维日常要处理慢查询、主从延迟、备份恢复这些都会涉及。高频考点第一个是索引失效原理。最经典的一句话是“在索引列上使用函数或隐式类型转换会导致索引失效”。笔试会给你一个SQL比如SELECT * FROM user WHERE phone 13800138000如果phone字段是varchar类型但条件值写成了数字类型MySQL会做隐式类型转换导致索引失效。还有“最左前缀原则”复合索引(a, b, c)能匹配(a)、(a,b)、(a,b,c)但跳过了a直接查b或c就用不上索引。第二个高频考点是MyISAM和InnoDB的区别重点必须答出InnoDB支持事务、行级锁、外键MyISAM不支持事务、只支持表级锁。在互联网高并发写入场景下MyISAM因为有锁竞争问题基本已经被淘汰了而InnoDB的行级锁能支持高并发。笔试里经常给你一个场景判断应该选哪种存储引擎这类题要结合业务场景来答。第三个是主从同步。京东这类大厂的MySQL高可用方案少不了主从复制。考察方式通常是“MySQL主从延迟过高可能是什么原因如何排查”原因有几种主库写入并发过高、从库机器性能差、大事务未及时提交、从库上有慢查询抢占资源、网络延迟。排查要从show slave status\G里的Seconds_Behind_Master字段看起再结合监控去定位瓶颈。答出链路排查的思路比单纯背一堆参数更有用。2.5 监控与告警看似简单但综合性强监控这个模块在2019年的笔试里已经有明显比重了。因为运维的核心职能之一就是“提前发现问题”而不是等用户投诉了才去处理。常见的题目是“如果要监控一台服务器的CPU、内存、磁盘、网络你会用什么工具怎么写采集逻辑”这题看似简单但你可以通过补充细节来得分CPU要看us/sy/wa/idle多维度指标内存要看used/buff/cache/available磁盘要看空间使用率和inode使用率网络要看流量和TCP连接状态。如果只答一个top命令、free命令和df命令那你只能拿基础分因为大家都会写。但如果你补充说明“监控数据要做到采集、存储、告警、展示四个环节”并且提到zabbix或Prometheus这一类工具那就升了一个层次。Prometheus在近几年笔试中越来越常见因为云原生和大规模监控场景下Prometheus生态已经成为事实标准。笔试可能会问“Prometheus的pull模式和传统push模式的差异”你要答出pull模式更适合服务发现、天然适配k8s环境、便于集中控制采集频率而push模式的zabbix更适合传统虚拟机环境里的主动上报。另外还要掌握指标类型Counter只增不减比如请求总数、Gauge可增可减比如当前连接数、Histogram分位数统计、Summary类似但客户端聚合方式不同这是Prometheus的数据模型基础。2.6 综合场景题考察链路式排查思维最后说压轴大题。这种题一般描述一个线上故障让你写排查思路和解决方案。比如经典的“某天中午12点大量用户反馈商品页面打不开HTTP接口响应超时你作为运维工程师如何排查”这种题没有标准答案但有标准的回答框架。我的建议是永远按“全链路排查”的思路来写先快速定位影响范围确认是所有用户都受影响还是部分地域、部分运营商受影响。再从网络链路逐层排查DNS解析是否正常、机房入口和负载均衡是否过载、后端服务是否存活、数据库连接池是否被打满、缓存是否失效。最后结合监控数据分析根因给出临时缓解措施和长期优化方案。如果笔试考到类似“大促前需要做哪些容量规划”你就可以把整个压测流程写进来确定核心链路、根据历史峰值预估流量、做全链路压测、摸清系统瓶颈、制定限流降级熔断预案、扩容云资源、备份数据和配置、演练应急预案。这一套答下来基本上就是一个合格运维校招生的水平了。3. 答题策略与时间分配笔试这场仗怎么打很多考生笔试失利不是因为不会而是因为时间分配失衡选择题纠结太久最后大题草草收场。从京东2019这批题目的体量来看题量不算小两小时内要完成几十道题加两三个场景大题节奏一定要稳住。我建议的方法是“三轮答题法”第一轮快速扫完全卷把有把握的客观题直接做掉记住不要纠结。单个选择题超过一分半钟还在犹豫就先跳过去做个标记回头再看。第二轮做简答题和场景题。这类题分值大而且只要你能写出清晰的思路即便结论不完美阅卷人也会给分。尤其是场景题一定要写得足够详细把你能想到的排查步骤都列出来宁可多写不可少写。第三轮回头处理标记过的难题此时心态已经平复有时候反而能一眼看穿之前的思维盲区。另外提醒两个小技巧。第一简答题如果实在不会也尽量写一两句相关的理解大厂笔试阅卷不会完全按“错即零分”处理特别是场景题思路清晰比结果正确更重要。第二所有命令题都要带着“排查思路”去写比如让你查磁盘大小不要只写df -h再补一句“如果磁盘使用率超过80%我会进一步用du -sh *逐级定位大目录再结合lsof检查是否有删除但未被释放的文件”这种答案的分数会明显高于单纯列出命令。3.1 高频命令速查考前必背的清单我整理了一份高频命令清单不是让你死记硬背而是考前当天翻一遍保持手感和条件反射。笔试不会常考特别生僻的命令但下面这些出现的频率非常高系统状态top、free -h、df -h、df -i、iostat、vmstat、uptime、sar网络排查ping、telnet、nc、ss -lntp、netstat -lntp、tcpdump、traceroute、curl -v进程管理ps -ef、ps aux、kill、kill -9、pkill、pgrep、nohup、systemctl文件处理find、grep、awk、sed、sort、uniq、wc、tar、rsync、scp性能分析perf、strace、lsof、dmesg、ulimit -a日志排查tail -f、tail -n 200、less、grep结合管道、journalctl注意一个高频陷阱查看端口监听时很多人习惯用netstat新版本系统里netstat可能没装ss才是iproute2自带的工具。笔试如果问到“如何查看某个端口是否被监听”你可以两个都写然后说明ss比netstat更快、信息更全这就是细节分。3.2 主观题怎么写才不像外行遇到主观题比如“请描述一次你解决问题或处理故障的经历”不少应届生写出来的内容是“我重装了系统”或“我重启了服务”。这不能说错但太单薄了没有展现运维思维。好的写法遵循“现象描述 → 初步排查 → 定位根因 → 解决方案 → 优化预防”这五个环节哪怕是一个很简单的场景也要把这五段逻辑写完整。用模型展开就是现象某天下午服务告警群突然报警接口成功率从99.99%掉到80%。初步排查登录跳板机查看监控发现一台后端节点的CPU使用率接近100%再查看进程发现有一个Java进程有异常GC。定位根因通过jstack抓线程栈发现大量线程阻塞在数据库连接获取上进一步查看数据库连接池配置发现最大连接数设置偏低而当天正好有活动流量上涨把连接池打满了。解决方案临时将连接池上限调大、重启问题节点让流量重新分配。优化预防活动前对连接池参数做压测验证并配置连接池利用率的监控告警在打满前提前预警。这套模板不只在笔试里好用在面试讲项目、甚至入职后写故障复盘报告时也都能用。4. 从笔试到面试的衔接提前准备好这些追问笔试只是第一关我个人建议你从笔试结束那一刻起就开始准备面试环节。因为大厂的面试官手里有你的笔试答卷他们会顺着你试卷上答过的内容深挖追问这时候如果你答不出所以然反而比笔试没考好更尴尬。比如你在笔试题里写了“使用tcpdump排查网络问题”面试官大概率会追问“tcpdump抓到的包怎么看三次握手的包特征是什么”这时候你要能回答SYN包的Flags是[S]SYN-ACK包是[S.]ACK包是[.]完整体现一次握手。再比如你写了“用sed替换某个配置项”面试官可能追问“sed的-i参数是什么意思为什么不建议在脚本里直接对线上文件用sed -i”这个问题的核心理念是sed -i直接修改原文件一旦正则写错就会污染全部内容生产环境更稳妥的做法是先输出到临时文件做diff校验再替换原文件sed s/old/new/g config.conf config.conf.new diff config.conf config.conf.new mv config.conf.new config.conf这种追问不是刁难而是在考察你有没有真实的生产环境操作经验而不只是会背命令。另外很多同学容易忽略对项目经历的梳理。面试时如果被问“你在实习或平时项目中做过什么”不要只讲业务功能要讲“你解决了什么问题、遇到了什么坑、怎么度量的结果”。比如你搭过一套监控系统与其说“我用zabbix搭了监控”不如说“我在50台服务器上部署了zabbix监控重点监控了核心接口的可用率设置了阈值告警上线后提前发现了两次磁盘满导致的故障隐患避免了服务不可用”。同样是描述一件事后者明显更有说服力。4.1 校招笔试的备考路线建议如果你距离笔试还有一两周我建议按下面这个节奏安排前3天主攻Linux命令和文件系统确保常用命令手到擒来。这个模块性价比最高突击见效最快。第4到6天过一遍网络核心知识把TCP三次握手/四次挥手、DNS解析流程、HTTP状态码和常用排障命令串成一条线。第7到9天练Shell脚本每天至少手写三到五个脚本重点覆盖日志统计、文件批量处理、进程监控、定时任务。第10到11天啃一遍MySQL索引和锁、主从同步再整理一份“慢查询排查”的完整思路。最后两天刷场景题和主观题把前面提到的“现象-排查-根因-解决-预防”的结构套到至少五道题上练到条件反射为止。这套路线不保证你能拿满分但至少能保证你在笔试时面对大部分题目不会慌。如果时间更充裕建议补一下容器和kubernetes的基础概念近几年校招笔试里Docker和k8s相关的基础题出现频率越来越高至少要知道镜像与容器的区别、Pod的调度单元、deployment与service的作用。即使考得深也不会太离谱能把基础概念说清楚就能拿分。4.2 关于心态的一点建议最后说点题外的。我见过太多同学在笔试前疯狂刷题把面试题库翻了个底朝天结果一看到没见过的题就慌了。其实你可以反过来想校招笔试的目标不是筛选“所有题都会的人”因为这样的人基本不存在。它的目标是筛掉那些基础不扎实、逻辑不清晰、不具备排障思维的人。你只要把基础题稳稳拿住综合题展现出清晰的思路就已经超过大部分竞争者了。遇到没见过的题目不要空着不写。运维这行最忌讳的就是面对问题毫无思路哪怕是不知道确切答案你也可以写“我会先用xxx工具查看xxx再根据结果进一步分析”。在阅卷人看来这反映的是你在真实故障面前的第一反应而这种反应恰恰是运维工程师最重要的软素质之一。从我自己这些年的经验来看笔试和面试都不只是在考你会什么也在考你遇到不会的东西时怎么应对。保持冷静、按链路拆解、能说一步是一步这三条原则放在运维工程师的整个职业生涯里都适用。