我把自己当年刷京东2018秋招技术运维工程师笔试题的经历整理了一遍同时也把市面上能搜到的同批次回忆版题目做了交叉比对。结论是这套题虽然时间过去好几年但它的考点框架放到今天依然不过时。无论你是在准备运维岗笔试还是想系统梳理自己的Linux、网络、数据库、容器、监控知识这篇文章都值得你花半小时看完。我不会去逐字复述原题而是把题目背后真正想考察的能力拆开讲清楚顺便把那些“看起来会、一写就错”的坑也一并填上。1. 打开真题之前先看清京东到底要什么样的人1.1 一场笔试背后的岗位画像2018年的京东正处于向技术转型的关键期彼时“技术运维工程师”这个岗位的目标非常明确既要能扛住大促流量下的系统稳定性也要能推动运维自动化、平台化建设。所以笔试不是单纯考命令背没背熟而是通过一套题去筛三类能力基础功底扎不扎实、故障排查有没有章法、对运维发展趋势有没有判断。笔试题目一般分成几块选择题覆盖Linux、网络、数据库、数据结构基础简答题考命令输出、配置文件含义、故障处理思路最后往往有一两道综合设计题比如“设计一个支撑百万并发的Web架构”“线上CPU飙高怎么排查”。如果你以为运维就是敲敲命令、看看监控那这套题会让你清醒过来。1.2 2018年秋招的技术背景为什么今天仍然值得刷2018年正值容器和编排系统大规模落地的前夜很多公司还在用虚拟机和传统发布方式但Docker已经开始进入生产环境Kubernetes也从小范围试点走向主流。京东内部自研的容器平台已经承担了大量核心业务所以笔试题里出现容器相关内容并不奇怪。刷这套题的价值不在于题目本身而在于它能帮你建立一个完整的运维知识坐标系。2018年的考点是Linux网络数据库容器的交叉现在绝大多数公司运维工程师笔试还在考同一套底层的东西无非是增加了云原生、DevOps、智能运维等新词。把老题吃透你相当于把一个运维工程师最核心的能力底盘练了一遍。2. Linux与操作系统考点拆解从命令到内核2.1 高频命令与文件系统题选择题里最常见的是给一条命令让你选输出结果。当年考过top、ps、netstat、df、du、find、grep、awk、sed的混合用法其中awk和sed是重灾区。很多人能用awk取列但一到“按条件筛选之后再做统计”就卡壳。我建议把下面这组套路练到形成肌肉记忆用ps aux查进程CPU和内存占用配合sort -k3 -rn按CPU排序sort -k4 -rn按内存排序。用netstat -tunlp看端口监听状态注意-t必须带上否则看不到TCP连接信息。用df -h看磁盘容量iostat -x 1看磁盘IOdstat看整体性能。用find /var/log -name *.log -mtime 7 -exec rm {} \;做日志清理注意-exec后面必须以\;结尾。文件系统考点里inode耗尽是一个经典陷阱。很多人只知道磁盘满了却不知道df -h显示有空间但应用报错“No space left on device”时要用df -i查看inode是否用完。当年题目里就有一道场景小文件过多导致inode占满问怎么定位和解决。正确思路是先df -i确认再find / -xdev -printf %h\n | sort | uniq -c | sort -k1 -rn找出小文件集中的目录最后清理或调整文件系统。2.2 进程、内存、负载的排查套路选择题经常考load average的含义。很多人误以为负载高就代表CPU忙实际上它是进程状态的一个综合指标。top里显示的load average分别对应1分钟、5分钟、15分钟的均值它统计的是处于运行状态和不可中断睡眠状态的进程数。如果机器负载很高但CPU使用率不高优先检查是不是有大量进程处于D状态不可中断睡眠。这种状态一般和磁盘IO有关比如NFS挂载卡住、磁盘硬件故障、IO调度慢。排查命令是top后按D键看D状态进程或者直接用ps -eo stat,pid,cmd | grep ^D。配套考的是内存分析。free -m输出中很多人分不清used和available。在较新的内核版本里available是真正可被新进程使用的内存它包含了可回收的page cache。而used并不等于“实际占用”因为buff/cache占用的内存可以在需要时释放。当年有道题是“系统内存显示用了80%要不要扩容”正确答案是先看available而不是used。2.3 系统启动与初始化排查Linux启动流程也是常客一般会考BIOS - BootLoader - kernel - init/systemd - 用户态服务这条链。2018年很多公司还在用CentOS 6所以SysVinit和systemd并存是个考点。现在基本都切systemd了但启动流程的原理依然要理解。结合故障场景的题目更实用服务器重启后某个服务没起来怎么排查我的标准路径是systemctl status service看服务状态和报错信息。journalctl -u service -n 100查日志。如果服务没设置开机自启用systemctl enable service。如果服务依赖网络、数据库等外部资源检查启动顺序是否配置了After依赖。这类题目说到底是考定位能力不是单纯考命令。我之前在文章里也分享过处理“重启后服务起不来”最忌讳的是反复重启服务试运气一定要先看journal日志和配置依赖。3. 网络考点拆解TCP、HTTP、DNS和故障排查3.1 TCP三次握手与time_wait网络部分选择题浓度很高而且喜欢围绕TCP展开。三次握手、四次挥手的流程是送分题但要拿分必须把状态流转背清楚。考场里更容易错的是TIME_WAIT相关题因为涉及细节比较多。TIME_WAIT出现在主动关闭连接的一方作用是确保最后的ACK能让对方收到同时防止旧连接的报文干扰新连接。高并发短连接场景下TIME_WAIT会大量堆积导致端口耗尽典型优化手段是开启net.ipv4.tcp_tw_reuse并配合tcp_timestamps。不过有个坑要提醒tcp_tw_recycle在NAT环境下会引发严重问题因为它依赖时间戳而NAT后面的多台机器时间戳可能不递增导致丢包。2018年面试官喜欢追问这个点能从“为什么不能随便开tcp_tw_recycle”说到“NAT环境下可能会丢包”的候选人基本能拿高分。3.2 HTTP状态码与常见场景HTTP状态码属于必考。1xx、2xx、3xx、4xx、5xx的大类要清楚几个高频状态码必须记住301永久重定向、302临时重定向注意301会缓存302不会。403权限不足404不存在499是客户端主动断开Nginx特有500服务端内部错误502网关收到无效响应503服务不可用504网关超时。429请求过多在限流场景下经常出现。京东这类大流量业务尤其看重502/504的排查。题目可能这样出Nginx返回502后端PHP-FPM日志没有报错怎么排查思路是先确认后端进程是否存活再确认端口和Unix Socket是否可访问接着看PHP-FPM的request_terminate_timeout和慢日志最后检查Nginx和后端之间的keepalive配置。做题时不能只写答案要把排查顺序写清楚。3.3 DNS解析问题定位DNS的问题年年出现因为它直接影响用户访问。常见考点包括查看解析用的命令是nslookup、dig、host其中dig信息最全。/etc/resolv.conf里search和ndots参数会影响域名解析行为这在Kubernetes里尤其重要。DNS缓存导致解析不生效刷新缓存的方法因系统而异CentOS 6用service nscd restartsystemd系统用systemd-resolve --flush-caches。笔试题里典型场景是“用户反馈域名解析到了错误的IP但是本地dig 114.114.114.114结果正确怎么排”答案要先判断是不是使用了本地DNS服务器再查hosts文件、DNS缓存、DNS服务器的解析记录。注意/etc/hosts优先级高于DNS很多人排查半天最后发现是hosts里写了一个旧IP。3.4 负载均衡与LVS、Nginx2018年笔试题对负载均衡的热情非常高京东作为电商平台负载均衡是核心基础设施。选择题可能考LVS的三种工作模式DR模式、NAT模式、TUN模式。其中DR模式和NAT模式的区别是高频考点要记住NAT模式请求和响应都经过LVSLVS修改目标IP和端口回包要改源IP性能受限。DR模式请求经过LVS响应直接回给客户端LVS只改目标MAC地址性能最好但要求后端和LVS在同一二层网络。TUN模式通过隧道封装跨网段场景用但复杂度高。Nginx作为七层负载均衡也要掌握。题目常问“Nginx和LVS有什么区别”标准回答是LVS工作在四层、基于内核转发、性能高Nginx工作在七层支持HTTP协议级别的路由、rewrite、缓存但性能上限不如LVS。实际架构里经常是LVS在前面做流量入口Nginx在后端做应用路由。4. 数据库与中间件考点MySQL、Redis、消息队列4.1 MySQL索引与慢查询数据库这块MySQL是绝对主力。选择题爱考索引失效场景简答题爱考慢查询优化。基础必须过关的内容包括B树索引结构、聚簇索引与非聚簇索引的区别。最左前缀原则联合索引(a,b,c)能用上a、ab、abc但不能直接用b或c。回表查询和覆盖索引。覆盖索引是优化利器查询字段都在索引里就能避免回表减少IO。慢查询日志开启方法set global slow_query_log ON;配合long_query_time 1然后用mysqldumpslow分析。真题里有一道我印象很深select * from t where age 18 order by id desc limit 10数据量很大问怎么优化。除了给age加索引还要考虑order by和limit的组合。如果单纯加索引还不够可以进一步利用覆盖索引或者在业务上改成从游标位置翻页避免深分页。4.2 Redis缓存雪崩、穿透、击穿Redis作为高频考点每年都会出现。2018年考的是缓存三兄弟现在依然考只不过场景更新了。缓存穿透查询一个不存在的key每次打到数据库。解决方法是布隆过滤器或者缓存空值并设置较短过期时间。缓存击穿一个热点key过期瞬间大量请求打到数据库。解决方法是互斥锁重建缓存或者让热点key不设置过期时间改为逻辑过期。缓存雪崩大量key同时过期导致数据库压力暴增。解决方法是过期时间加随机值或者采用多级缓存、集群部署。答题时不要只写方案名称要把原理讲透。比如互斥锁其实用的是Redis的setnx加锁重建缓存后释放锁但要注意锁的过期时间防止线程异常导致死锁。能够把“为什么”讲清楚阅卷人一眼就能看出你做过实际项目。4.3 消息队列选型与可靠性消息队列在2018年时主流选择是Kafka、RabbitMQ、RocketMQ。选择题会问适用场景比如Kafka高吞吐、适合日志收集和流处理但会有消息重复和乱序需要业务侧做幂等。RabbitMQ适合复杂路由、可靠性要求高的业务但吞吐量相对低。RocketMQ在电商场景里表现均衡京东内部大量使用。可靠性的考点集中在消息丢失和重复消费。生产者端要确认机制Broker端要刷盘策略和副本机制消费者端要手动提交offset。笔试题常问“怎么保证消息不丢失”答案必须分层说。如果只说“开启确认”没有把三层都覆盖到会扣掉大部分分。5. 容器、虚拟化与云计算运维5.1 2018年容器化处在哪个阶段2018年是一个有趣的节点Docker已经火了两三年Kubernetes开始在社区里占据主导但很多运维还没真正在生产环境大规模使用。京东属于走得比较早的我记得当时的容器平台已经在支撑核心交易链路所以笔试把容器作为一个加分项来考。今天的你看到这道题可能觉得简单但站在当时的环境里“容器和虚拟机的区别”“Docker镜像和容器的关系”“容器如何做网络隔离”这些内容已经能筛掉一批只会传统运维的人。5.2 Docker核心原理题Docker考点集中在镜像、容器、网络、存储。大题可能会让你画一下docker run之后发生了什么或者让解释overlayfs。知识点清单镜像层是只读的容器加了一层可写层。修改文件采用写时复制所以容器内改文件不会影响镜像。容器网络模式bridge、host、none、container。如果题目问“容器里访问宿主机服务用什么地址”答案是host.docker.internal或者在Linux下用网关IP。数据卷用-v挂载注意容器删除后数据是否保留取决于挂载方式。还有一道经典题容器内PID 1进程是什么角色为什么容器里不推荐运行多个进程因为PID 1在容器里承担信号转发和僵尸进程回收职责如果PID 1不是init类进程子进程变为僵尸后无法被回收时间久了可能出问题。这题虽然偏原理但能看出你有没有真在生产环境见过容器“僵死”。5.3 Kubernetes调度与Pod生命周期虽然2018年笔试不一定深入Kubernetes但如果你简历上写了容器编排面试官一定会追着问。核心概念必须搞清楚Pod是最小调度单元一个Pod里的容器共享网络命名空间和存储卷。kubelet负责Pod生命周期管理容器崩溃后根据restartPolicy决定是否重启。调度器根据资源请求、节点标签、亲和性等条件把Pod分配到合适节点。Deployment控制副本数滚动更新时默认maxSurge和maxUnavailable都默认25%。当前云原生环境下“从原理到实体调用”经常被问kubectl apply之后kube-apiserver如何把Pod写入etcdkube-scheduler如何选择节点kubelet如何通过CRI调用containerd最终通过runc启动容器。建议把这个调用链画一遍比死背Pod的阶段名字有用得多。5.4 私有云、混合云下的运维思维转变京东的运维体系早已不是传统机房的模式笔试中的设计题经常会把场景设定在私有云或混合云里。要体现思维转变至少要能谈两点从“管理单台机器”到“管理资源池”。机器故障不再是每天手工处理而是通过平台自动替换。运维要写的是调度策略、健康检查、自愈脚本。从“稳态”到“敏态”。传统运维以稳定为最高目标云原生下的运维要兼顾快速交付。不可变基础设施理念下修复不是改配置而是重新发布版本。这类题目没有标准答案但踩分点在于你有没有表达出“人工操作不可扩展必须自动化”这个核心认知。6. 监控、自动化与故障排查综合题6.1 监控体系怎么设计监控设计题几乎是秋招综合题的保留项目。题干一般是这样“线上有几百台机器业务包括Nginx、应用、MySQL、Redis请你设计一套监控方案。”答题框架建议按“指标采集-数据存储-告警通知-可视化”展开采集层Zabbix、Prometheus、Node Exporter注意区分系统指标和业务指标。存储层时序数据库Prometheus适合容器环境Graphite、InfluxDB在传统环境用得多。告警层阈值告警、趋势告警、智能告警。告警规则不能只是简单的多指标拼凑要有依赖关系避免海量告警轰炸。可视化Grafana配Prometheus或者Zabbix自带图表。“智能运维”热词现在很流行但笔试里不用堆概念。你要说明白“告警降噪”“根因定位”“故障预测”是怎么用数据实现的。例如把分钟级指标按时间序列存下来用波动检测去发现异常而不是单纯设一个固定阈值。6.2 Shell、Python自动化脚本考点笔试题里经常出现“写一个Shell脚本统计日志中某个接口的平均响应时间”之类题目。这种题回答时要注意风格不是让你在IDE里写完整项目而是考察你能否快速用管道实现需求。经典答案是grep GET /api/order access.log | awk {print $NF} | awk {sum$1; count} END {print sum/count}如果日志字段更复杂可以用awk直接匹配awk /GET \/api\/order/ {sum$NF; count} END {if (count0) print sum/count} access.logPython自动化题则更偏向场景比如“给出一份主机清单写一个脚本批量执行命令并把结果汇总”。往paramiko或fabric方向答即可重点写清楚异常处理和结果收集生产环境没人愿意看裸的subprocess循环。6.3 经典故障定位案例故障类题目最考验综合能力。举一个高频案例线上接口突然变慢CPU使用率100%你怎么排查我的排查顺序是先用top -H -p pid定位哪个线程占用CPU高。用printf 0x%x\n pid把线程PID转成十六进制或者用jstack pid | grep -A 20 nidJava应用场景。如果是Java应用jstack看线程栈定位到业务代码。如果不是Java用perf top看热点函数。这种题的精髓不在于某个命令多高级而在于排查路径清晰。你答的时候要边讲步骤边解释为什么比如“先用top -H是因为CPU高是线程级别的现象光看进程PID不够细”这种表达会让阅卷人觉得你真的处理过线上事故。6.4 笔试题里的算法和数据结构很多运维候选人会忽略笔试中的编程题但京东这类公司不会因为你面的是运维就不考算法。一般来说会有1到2道手写代码题难度在LeetCode简单到中等之间比如字符串处理、数组遍历、实现一个栈。运维岗的算法题更偏实用。当年出现过“统计日志里IP出现次数并排序”的题本质就是Hashmap计数排序但要用脚本处理。如果你能写出性能可观的版本再补一句“如果日志量大用外部排序或者把统计逻辑直接下推到流处理平台”会显得你更有全局视野。7. 常见的问答题库与避坑经验7.1 容易答错的细节题我把当年考试和后来复盘时最容易踩的细节坑整理成一张表大家可以对照自查考点易错点正确理解df -h和df -i只看容量不考虑inode小文件场景必须看inodetcp_tw_recycle以为开启就能解决TIME_WAITNAT环境开启会丢包不推荐软链接和硬链接以为支持目录和跨文件系统硬链接不支持目录不能跨文件系统缓冲区和缓存以为buff/cache是“正在用”的内存可回收内存内核需要时会释放HTTP 301和302忽略缓存差异301会被浏览器缓存302不会索引最左前缀忽略联合索引的顺序查询条件要能匹配最左列才能用索引Docker镜像层以为容器启动后镜像不变容器层写时复制镜像本身不会变负载均衡四层和七层混淆LVS和Nginx定位LVS四层转发能力强Nginx七层功能丰富7.2 做题顺序和拿分技巧笔试时间有限我的建议是“先扫全卷先易后难”。运维笔试很多知识是“看一眼就知道会不会”的选择题答得快简答题写得多。遇到设计题不要留白把你想到的架构分层写出来哪怕只有一张图配文字说明也会比空白多拿分。具体策略选择题控制在2分钟内一道拿不准的先标记不要恋战。简答题先列点再展开。尤其“排查思路”类的题每个步骤写一行有思路分。设计题先画结构框架再写模块说明。一个完整的“负载均衡层-应用层-缓存层-存储层-监控层”分层结构能覆盖大部分踩分点。代码题先写自己能通过的简单版本再优化。不要因为想写出最优解而卡壳空着是最亏的。7.3 从真题延伸到面试现场笔试过了还有面试所以做完题不要急着对答案就完事要把错题整理成知识点尤其是那些“好像理解、实际没懂”的判断。面试官大概率会拿笔试里的一道题做切入点深挖下去。比如笔试题考了LVS的DR模式面试可能会追问DR模式为什么后端要配置lo上的VIP响应包为什么能直接回给客户端隐藏的arp问题怎么解决这些连问的目的就是测试你是不是真的理解原理而不是背过概念。我的建议是每一道错题都给自己准备一个“为什么”和一个“如果场景变化怎么处理”比如“如果后端和LVS跨网段怎么办”这类追问。笔试只是起点把追问都考虑清楚面试才真正稳。我个人刷这套题的最大体会是运维岗位考察的核心从来不是“某个工具会不会用”而是“遇到问题是否有清晰的分析路径”。Docker、K8s、Zabbix、Prometheus这些工具会一代代更替但网络抓包分析的思路、性能排查的层次感、数据库索引设计的原则这些底层方法论是长期有效的。所以如果你现在正准备运维岗笔试别只顾着刷最新热词把Linux、网络、数据库和故障排查的底子打牢比什么都有用。最后再分享一个习惯每刷完一套题把错题按“原理缺失”和“场景经验不足”分类原理缺失去补书场景经验不足去搭虚拟机复现。坚持一个招聘季下来你的运维体系会比刷题前扎实一大截。