京东2019春招技术运维类试卷这个名字放在今天回看依然是一个很好的研究样本。身边总有人问我大厂技术运维岗笔试到底考什么是不是疯狂背Linux命令就能过我用这套试卷作为切入点把技术运维的考点、出题逻辑和备考思路完整拆一遍。这篇文章适合三类人看准备校招运维岗的应届生、想从传统运维转大厂的同事、以及刚入行想系统梳理技能树的初级运维。看之前先打好一个心理预期运维笔试不是背题比赛而是一场基础知识排障思维的综合测试。1. 重回2019京东春招技术运维岗到底在考什么1.1 一份技术运维类试卷的大致轮廓京东2019春招技术运维类试卷单看这个标题就已经能读出很多东西。当时大厂校招的运维笔试普遍不绕弯子京东这套卷子给我的印象是时间紧、覆盖面广、跟生产环境结合紧。试卷不会只考一个Linux命令的拼写而是混合了单选、多选、判断、简答和场景题。整场下来大概90到120分钟题量不小很多人第一次做会感觉根本写不完。从参加过那轮笔试的同学反馈来看这类试卷大致可以分成四个模块。第一是Linux与系统管理包括常用命令、系统调优、服务管理这类题占的分值通常最高。第二是网络核心是TCP/IP、HTTP、DNS、负载均衡、Nginx这一类不但考概念还会考排查思路。第三是数据库与中间件MySQL和Redis是大头偶有消息队列的题目。第四是脚本与自动化通常会有一道Shell或Python编程题。有的年份还会加一道开放性的场景设计题用生产环境中真实出现过的故障来考察应变能力。这里要说明一下我下面会反复拿京东2019春招技术运维类试卷当例子是因为它代表了那个时期大厂技术运维笔试的典型形态。题目本身或许会过时但考察框架和底层逻辑并没有变现在准备运维岗依然可以照着这个框架去复习。1.2 为什么大厂运维笔试喜欢这样出题先说结论大厂招运维不是招会敲命令的人而是招能扛事的人。笔试之所以这样出题是因为技术运维这个岗位本身就不是单点技能可以覆盖的。服务器崩了你要懂Linux服务访问慢你要排查网络数据出了问题你要知道数据库怎么回事发布一台机器你要会写脚本、懂自动化。所以试卷必须像一张网把各个方向都捞一遍。同时笔试也是一种快速筛人的手段。运维岗投递量非常大很多简历看起来差不多HR很难通过简历区分谁真的动手做过。笔试题能较好地暴露一个人对基础知识的掌握程度。比如同一个命令有的人背得出参数有的人知道它在什么场景下能解决问题两种答案在笔试里一眼就能看出来。这也是为什么很多人说大厂运维笔试题不难但面很宽。另外还有一层很少被提到的原因笔试让筛选过程更公平。面了很多人之后你会发现真正有经验的人不一定是简历最漂亮的但一定是基础最扎实的。笔试卷子能把所有人的技能水平拉到同一个坐标系里比较减少简历包装带来的误差。2. 面试官视角看考点技术运维需要掌握的核心知识栈2.1 Linux系统不是会敲命令就行技术运维岗和Linux几乎是绑定的。京东这套试卷的Linux相关题目虽然年份是2019但到今天依然是主流。通常包含进程管理、文件权限、磁盘管理、系统负载、日志分析这几个方向。题目不会直接问你ls的含义是什么而是会给你一个实际场景比如系统负载突然飙到20如何一步步排查。我当时在准备这类题目时会要求自己不仅会敲命令还要能说清原理。比如top和ps看的是procfs里的数据load average是运行队列中可运行和不可中断任务的平均数这个平均值高低跟CPU核心数相关不能只看数字大小。又比如netstat和ss新版系统推荐ss命令它直接读取内核socket信息性能比netstat好很多。这些细节不一定在题干里考出来但在简答题的答题过程中能写出来就会让阅卷人觉得你是真的懂。再举一个容易忽略的点systemd。2019年的时候很多学校还在教service命令但主流大厂已经全面转向systemd。笔试中如果出现开机自启动一个服务这类题你用systemctl enable和用chkconfig写出来的答案专业度完全不一样。还有日志这块journalctl配合systemd是基本操作不要只会翻/var/log/messages。2.2 网络基础TCP/IP、HTTP、DNS一个都不能少网络运维需要掌握什么技术这是很多人问我的问题。参考答案其实很清晰从协议到工具再到排障思路缺一不可。协议层面TCP三次握手、四次挥手、拥塞控制、TIME_WAIT、HTTP状态码、DNS解析过程都是笔试常客。工具层面ping、telnet、nc、traceroute、dig、tcpdump至少要能说清楚各自的应用场景。我见过太多同学把TCP三次握手背得滚瓜烂熟但一遇到为什么服务端有大量TIME_WAIT就懵了。这就是因为只记住了顺序没理解状态迁移背后的原因。笔试里网络题往往不会直接考两次握手行不行而是给你一个现象比如大量CLOSE_WAIT、连接超时、DNS解析慢让你给出排查方向。这类题目没有标准答案但踩分点非常明确你有没有抓住关键命令能不能分层次排查。以大量TIME_WAIT为例你至少要知道它出现在主动关闭连接的一方常见原因是服务端或网关的连接被频繁短连接请求打满需要从连接复用、TCP参数调整、业务侧长连接改造几个方向去考虑。这类分析写到卷子上比单纯写一句用netstat看一下有分量得多。2.3 数据库与中间件笔试里的硬骨头数据库和中间件是拉开分数的模块。以2019年前后的主流技术栈来说MySQL、Redis几乎必考提问方式偏向原理加场景。比如MySQL索引为什么用B树、什么情况下索引失效、如何定位慢查询、主从延迟怎么处理。Redis则会问缓存穿透、缓存击穿、缓存雪崩的区别以及常见解决方案。备考这一块我不推荐直接刷面试题而是建议在本地装一个MySQL和Redis亲手把常见问题复现一遍。比如创建一个几万行的测试表不带索引查询和带索引查询对比执行计划再比如用redis-cli加上info命令查看内存和持久化情况。这些操作看起来基础但能让你在写简答题时更有底气因为你已经见过真实的输出而不是背书。还有一点容易忽略事务和锁。MySQL的隔离级别、Redis的持久化机制RDB和AOF都是大厂笔试的常客。你可以不用背出每一种参数的具体值但要能讲清楚它们要解决什么问题以及各自有什么代价。比如RDB适合做数据快照和备份恢复AOF对数据安全性更友好但文件更大、恢复更慢。这类取舍型问题往往是简答题的加分点。2.4 脚本、自动化与监控运维的省力杠杆技术运维笔试里脚本题往往是最能筛选动手能力的一环。大厂对脚本的要求不复杂但很实际给你一个日志文件统计某个状态码出现的次数或者写一个脚本定期检查磁盘使用率并告警。Shell和Python都是好选择我个人建议至少把Shell的常用三件套grep、awk、sed练熟Python能写简单脚本即可。监控和自动化也在笔试中频出。比如Zabbix、Prometheus、Grafana的作用是什么告警规则如何设计日志采集ELK那套流程是什么。2019年很多大厂已经在向Kubernetes迁移容器化相关的题目开始出现比如镜像与容器的区别、Pod的生命周期。虽然当时考得不深但如果你在简历里写过熟悉Docker那笔试和面试都会往这个方向深挖。脚本题还有一个隐藏考点健壮性。写一个脚本检查磁盘空间不只要会df命令还要考虑如果磁盘路径不存在怎么办、磁盘空间命令执行失败怎么办、告警发不出去怎么办。笔试阅卷人会看你有没有处理边界情况。我给的技巧是脚本里加好set -e、对关键变量做非空判断、输出日志带上时间戳这些细节会明显提升印象分。2.5 运维的边界正在变宽最近行业里有一个新词叫数字孪生连隧道运维管理都有了相关的技术标准要求。这说明技术运维早已不是机房搬机器、盯着告警大屏的岗位而是越来越往数字化、智能化方向走。笔试里的考点永远比行业变化慢半拍但大家在准备时不要只盯着过去两三年的题也要留意新趋势。容器、云平台、可观测性、自动化运维平台这些方向今天已经成了技术运维的基本盘未来还会继续演进。比如现在聊可观测性已经从传统的监控告警延伸到日志、链路追踪、指标三者的统一聊AIOps则是用机器学习帮助人类快速从纷繁的告警中找到真正的问题。准备笔试时可以不用那么深但脑子里要有一根弦所有基础考点最终都是为了在一个复杂的线上环境里快速定位和解决问题。3. 典型题型与答题策略拆解含示例3.1 选择题和判断题易错点里藏着基本功选择题看着简单其实最容易丢分。以Linux为例题目可能这样出查看TCP连接状态推荐使用的命令是选项有netstat、ss、route、iptables。正确答案是ss但很多人会选netstat因为当年习惯用这个。其实从CentOS 7开始netstat已经不算默认安装的核心工具ss才是读取内核信息的推荐方式。这题考点不是你知道netstat能看连接而是你清不清楚工具的演进和适用场景。判断题也类似喜欢抠概念。比如服务器负载高就一定是CPU瓶颈这句话是错误的。负载高可能来自IO等待也可能来自不可中断进程。你要能解释load average的含义才不会被这类题迷惑。还有一道很经典的判断Redis是单线程的所以一台服务器的性能肯定不如多线程数据库。这也是错的Redis的单线程模型避免了锁竞争而且I/O多路复用让它在很多场景下表现极佳。这类题型的应对策略是整理易混淆概念清单。我当年就做了一张表左边写相似概念右边写它们的关键差异。比如ping和telnet的区别HTTP和HTTPS的区别Docker和虚拟机的区别。笔试前翻一遍比临时抱佛脚强得多。3.2 简答题把踩分点拆清楚简答题是笔试的得分大户也是阅卷老师拉开差距的地方。比如服务出现大量502 Bad Gateway如何排查这种题答题结构比最终结论更重要。我习惯按现象确认-链路拆解-逐步排除-定位根因四个步骤来写。先确认是全部机器502还是部分机器502。如果部分机器就找那一台和后端服务的连接问题如果全部优先看负载均衡和后端整体健康状态。接着从上到下查客户端到LB的网络通不通、LB到后端健康检查是否通过、后端进程是否存活、日志里有没有报错。每一步都用命令和输出佐证比如用curl -I看返回头用telnet测端口连通性用nginx的error.log定位是上游连接失败还是超时。这样写出来的答案即便没找到最终原因阅卷人也知道你具备完整的排查思路。反过来如果你只写一句重启一下服务就好了哪怕答案碰巧对了分数也不会高。运维这个岗位天然就是一边输出文字一边输出思考过程的工作简答题考察的其实就是你能不能把排障过程讲清楚。3.3 场景题考察的不是答案而是排查思路场景题是京东2019春招技术运维类试卷里最有含金量的部分通常给一个故障问你怎么处理。常见的有CPU飙高到100%、磁盘inode耗尽、内存溢出、Redis缓存雪崩、MySQL主从不同步。这些场景没有标准答案但有高分框架。以CPU飙高为例你可以用top看CPU占用最高的进程再配合ps -Lf和perf top定位线程热点。如果发现是Java应用还要用jstack把线程栈dump出来看是不是有死循环或锁竞争。整个过程的核心是一层层缩小范围从进程到线程再到代码级别。这种分层排障的思维方式才是场景题真正想看到的。再比如磁盘inode耗尽。很多人第一反应是df -h发现磁盘还有几十G就怀疑是错觉。其实这时候应该用df -i查看inode使用率。大量小文件会迅速耗尽inode导致文件系统报No space left on device即使free空间还很多。这类场景题的价值就在于它逼着你跳出常规思维去注意那些平时容易忽略的指标。4. 从笔试到面试一份可执行的备考路线图4.1 用一套自测清单评估自己想备战大厂技术运维岗先别急着刷题先用清单摸个底。我把常见的技能点整理成了一张自查表你可以对照着划勾。技能方向自测问题达标标准Linux能解释load average和CPU使用率的区别吗能说清两者含义并能举例说明什么情况会让load升高但CPU不高Linux能不看man页面说出find、grep、awk、sed的常用参数吗能准确说出至少5个常用参数并知道各自适用场景网络能画清TCP四次挥手吗能画出状态迁移图并说明TIME_WAIT和CLOSE_WAIT的区别网络能说清502、504、304的区别吗能说出状态码含义并给出最简单排查方向数据库知道什么是最左前缀原则吗能结合一条SQL语句说明索引为什么失效数据库能设计一个简单的Redis缓存方案吗能说明缓存和数据库的一致性处理思路脚本能不看参考写一个Shell脚本统计指定日志的错误数吗脚本能运行能处理文件不存在的情况监控能说清Zabbix和Prometheus的区别吗能说出拉取模型和推送模型的核心区别这张表不是让你背答案而是帮你发现短板。哪一项不熟就集中补哪一项比漫无目的地刷题高效很多。4.2 推荐的小实验与练习方法笔试和面试都喜欢问有没有实际做过。如果没有生产环境自己搭一套实验环境完全够用。我在本地用虚拟机装一个CentOS或Ubuntu利用systemd跑一个Nginx再用MySQL和Redis搭一套简单服务然后故意做错配置练习排查。比如把Nginx的worker_processes设成1然后用ab或wrk压测观察CPU和连接数变化。这样一个实验下来你会真正理解Nginx的进程模型为什么worker数要跟CPU核心数对齐以及压测工具到底在做什么。我身边很多同学做了类似实验之后笔试里关于Nginx的题几乎不会再错。脚本练习也可以从真实需求出发。比如把自己电脑上的历史命令按日期统计出现次数或者写一个脚本每天检查磁盘使用率超过80%就输出告警。练习的关键不是写得多复杂而是贴合实际问题。你写得越多考试时脑子里能调用的模块就越多代码会自然地从指尖流出来。4.3 除了做题还应该准备什么笔试只是门槛后面面试更关注你有没有解决过真实问题。所以简历里不要只写熟悉Linux最好写具体案例。比如某次线上服务频繁重启我通过查看dmesg和journalctl定位到OOM并调整了JVM参数。这类描述比任何证书都管用。另外养成写故障复盘的习惯也很加分。你不需要一开始就在生产环境踩坑完全可以用实验环境中的问题来练手。把现象、排查过程、根因、整改措施记录下来。面试时随口讲一个复盘案例比背一百个题库都更能打动人。我见过一个候选人简历上写熟悉Java和熟悉Linux面试官问他做没做过线上故障处理他直接讲了自己在实验环境里用jstack排查一个死循环问题的完整过程。从报错日志到线程栈再到定位到具体代码行讲得清清楚楚。最后他顺利拿到offer原因不是他技术多深而是他展示出了一种出了问题我能独立搞定的底气。5. 踩坑记录我在辅导同学准备运维岗时的几个教训5.1 死记硬背命令忽略原理我带过不少准备运维岗的同学最大的问题就是爱背命令但不懂原理。比如会背systemctl start nginx但不知道为什么用systemd替代了service会写awk {print $1}但不知道awk是逐行处理文本。笔试阶段可能还能蒙混过关但到面试追问原理时往往一秒露馅。所以我在整理任何考点时都坚持一个命令至少能说出它读取了什么信息、基于什么原理。比如top读的是/proc/stat和/proc/[pid]/statload average来自内核调度器的统计。哪怕只是这种程度的理解也能让你在答题时和其他人拉开差距。记住笔试中写出命令名只算及格写出命令背后的机制才算优秀。5.2 只学Linux忽视网络和脚本另一个常见误区是只刷Linux题。实际上大厂技术运维笔试中网络和脚本的占比非常高。网络题如果做不好几乎不可能通过脚本题如果写不出来基本也告别高分段。尤其是场景题往往需要你同时调用Linux、网络、日志、进程等多方面知识。我给过一个比例建议备考时间按四三三分配。Linux占四成网络占三成数据库和脚本占三成。这样既能保证基础盘又不至于在偏科里翻车。至少要把tcpdump、curl、dig这类工具的常用参数背下来并至少会写一个统计日志的Shell脚本这应该是底线。5.3 不重视日志、压测和故障复盘最后一条是意识层面的教训。很多同学笔试成绩不错但一到面试聊实操就露怯原因在于平时不重视日志查看、压测工具使用和故障复盘。日志不是报错了才去看压测不是性能测试工程师才做。这些习惯决定了你能不能从会做题变成会运维。我通常建议在准备过程中至少完整做一次故障演练故意把一个服务搞挂然后记录自己的排查路径。比如把Nginx的配置改错然后重启服务去翻error.log再用curl验证。走完一次你对系统性排查的理解会上一个台阶。练过和没练过在笔试场景题的答题语气上都能看出来。最后再说一句。技术运维的笔试也好面试也好本质上都在反复验证一件事当故障发生时你能不能在一个相对黑暗的环境里依靠自己掌握的技能快速找到那盏灯。京东2019春招这套试卷只是一个切面背后对技术栈和排障思维的要求到今天依然适用。希望这篇拆解能帮你把复习的方向理清楚少走我当初走过的弯路。