运维工程师笔试实战解析：从Linux命令到故障排查的京东真题复盘

1. 当年这套笔试题的“脾气”京东运维工程师笔试长什么样先说个背景。我在2018年那阵子正好在准备跳槽投了京东的运维工程师岗位秋招笔试也参加了。那会儿互联网大厂运维岗的笔试还没完全标准化各家出题风格差异很大。腾讯爱考网络和C基础阿里偏向场景题而京东这套题给我最深的印象是不偏不怪但覆盖面极广所有题目都贴着日常工作“能用到的东西”出几乎没有那种纯背书才能答上来的冷门题。整套笔试题型大概分三块选择题单选加多选、简答题、场景题。选择题占大头大概40到50道覆盖Linux命令、Shell脚本、网络协议、数据库、中间件、监控体系简答题一般是3到4道考的是“你如何设计一个高可用架构”“某个服务故障怎么排查”这类场景题更像一个小的案例分析给一段线上故障描述让你逐步分析原因并给出处理方案。整体答题时间是120分钟题量不算小前面选择题如果犹豫太多后面简答题基本写不完。我拿到卷子之后的第一感受是这套题的出题人大概率就是一线运维主管因为每一道题都能对应到实际工作里的某个具体场景。比如选择题里考了awk和sed的用法这几乎是每个运维每天都会碰到的文本处理工具考了TCP三次握手和四次挥手的状态变化也是排查连接问题的基础。所以这套题的“脾气”就是它不考你的知识面有多宽而考你平时干活时有没有真的把每个命令、每个原理搞明白。我当时答卷的策略是选择题快速过遇到拿不准的先标记把时间留给后面的简答和场景题。因为选择题的分值是固定的但简答题和场景题是踩点给分写得多、写得有逻辑分自然高。实际下来这个策略是有效的后面我会详细说每类题的具体作答思路。2. Linux基础题最容易被“熟练”骗过去的考点京东这套题里Linux基础占了大概30%的分值可以说是绝对的C位。但这里说的“基础”不是让你背ls、cd这种入门命令而是那些你每天在用、但真到笔试题里容易被细节卡住的东西。2.1 命令类题目复盘find、awk、sed的“标准答案”选择题里有一道我印象很深找出/var/log下最近7天内被修改过的所有.log文件并要求在删除前先统计数量。选项里给了好几种写法正确答案是find /var/log -name *.log -type f -mtime -7 | wc -l这里有两个坑。一是-mtime -7和-mtime 7的区别前者是7天以内修改过的后者是恰好7天前修改过一次的一字之差结果完全不一样。二是-name *.log必须加引号如果不加Shell会在 find 执行前就把当前目录下的.log文件展开进去导致结果是错的。这个细节在选择题里很喜欢考。还有一个考试里反复出现的命令是awk。它考的不是awk {print $1}这种基础用法而是更贴近实际日志分析的场景。比如给出一个访问日志格式是192.168.1.10 - - [20/Sep/2018:14:30:25 0800] GET /index.html HTTP/1.1 200 1024题目要求统计每个IP的访问次数并按降序排列。标准答案是awk {print $1} access.log | sort | uniq -c | sort -rn这里要理解awk默认按空格分割$1就是IP地址uniq -c统计次数sort -rn按数值降序排列。这套组合拳运维天天用但笔试里会故意把sort -rn写成sort -n或者sort -r问你哪个能正确实现“次数从高到低”。如果不清楚-r是反向排序、-n是按数值排序很容易选错。sed也是必考。最常见的考法是替换文件中的某个字符串并且要求直接修改文件。正确答案是sed -i s/old/new/g file.txt但考点通常会放在-i参数上。很多人知道sed s/old/new/g能替换但忘了加-i就不会真正写入文件只在屏幕上输出结果。笔试题目会故意给出不加-i的版本作为干扰项。还有一个进阶问法如何只替换第3行到第5行之间的内容sed -i 3,5s/old/new/g file.txt这类命令题本身不难难的是在紧张状态下粗心选错。我的经验是平时写命令时就要有“这命令在生产环境跑一遍会有什么后果”的意识笔试里其实就是在考察这个意识。2.2 权限、inode与文件系统细节题京东这套题里还考了文件权限的特殊位。有一道题问的是一个文件权限为-rwsr-xr-x请问s位的作用是什么答案是SetUID即普通用户执行该文件时会临时获得文件属主的权限。典型例子是/usr/bin/passwd它需要root权限去修改/etc/shadow所以这个文件上就有SUID位。这里更深一层的考点是为什么运维在配置服务时不建议随便给执行文件加SUID位因为如果某个脚本或程序被提权攻击者利用SUID位就能以root身份执行任意命令这属于严重的安全隐患。考题里有时候不会直接问但在场景题里会作为“安全加固”的采分点出现。inode相关的考点也有。题目回忆大概是磁盘执行df -h看剩余空间还有20G但创建文件时报错No space left on device可能的原因是什么这就是典型的inode耗尽问题。df -h看的是磁盘块的使用量df -i看的是inode的使用量。文件系统里每个文件或目录都要占用一个inode如果小文件特别多就会发生inode先被耗尽但磁盘空间还很充足的状况。排查命令也常考df -i find /data -xdev -type f | wc -l生产环境里跑定时任务没清理临时文件、或者日志切分产生的碎文件太多都会触发这个问题。笔试里如果只看过df -h而没关注过df -i这道题就很容易蒙。2.3 进程与systemd的排查思维进程管理是运维最基础的能力这套题也绝不会放过。有一道选择题大概是线上某个Java进程CPU持续100%如何定位是哪段代码导致的正确的排查链路是top # 找到高CPU的进程PID top -Hp PID # 找到进程内高CPU的线程TID printf %x\n TID # 将线程ID转换为十六进制 jstack PID | grep -A 20 0x十六进制TID # 查看线程堆栈这个链路里的考点是很多人知道用top看进程但不知道top -Hp能看线程知道jstack能打印线程堆栈但不知道线程ID要转成十六进制才能在堆栈里找到对应线程。这套题的难度不在于某个步骤多高深而在于你能不能把整条链路串起来。systemd相关也有一两道题。比如如何让一个服务开机自启并立即启动systemctl enable --now nginx这里的考点是--now这个参数它表示 enable 的同时立刻启动服务。很多人只记得systemctl enable忘了--now或者只知道systemctl start把enable和start分开执行。这种细节在笔试里很吃香因为出题人默认你“会”systemd但要看你是不是真的“熟”。3. Shell脚本题必背模板与当年真题还原Shell脚本在京东这套题里的比重出乎我意料地高。选择题有简答题也有一道后来我进了面试环节面试官还追问了笔试里那道Shell脚本题的思路。所以这部分我得好好拆一拆。3.1 日志统计与文本处理题的通用解法我回忆里有一道简答题是这样的写一个Shell脚本统计某网站访问日志中状态码为502和504的次数输出到告警文件如果超过100次则触发告警。这道题实际上是在模拟一线运维每天做的基础工作。我的答案分了三步#!/bin/bash LOG_FILE/var/log/nginx/access.log ALARM_FILE/tmp/http_alarm.txt count_502$(grep -c 502 $LOG_FILE) count_504$(grep -c 504 $LOG_FILE) echo $(date %F %T) 502_count$count_502 504_count$count_504 $ALARM_FILE if [ $count_502 -gt 100 ] || [ $count_504 -gt 100 ]; then echo HTTP error count over threshold | mail -s HTTP Status Alarm opsexample.com fi这道题的关键点有三个。一是grep -c统计行数时如果希望统计多个状态码可以写grep -cE (502|504) 这样一行统计更优雅二是告警阈值判断要用-gt而不是因为是Shell里的重定向符号写错会导致脚本行为异常三是生产环境的脚本里告警操作不能只写echo一般会调用告警接口或者写日志到专门的采集端但笔试阶段能给出mail或者curl告警的雏形就够了。这道题后来面试官追问的是如果日志文件非常大比如几百GB你的脚本怎么优化我当时答的是用tail -F配合grep只处理增量数据或者用awk边读边统计而不是反复grep整个文件。面试官点了点头说明这个追问是故意设置的前面那个朴素脚本只能拿基础分后面的优化思路才是加分项。3.2 进程监控与自动重启脚本的坑还有一道Shell脚本题考的是进程监控写一个脚本每分钟检查一次某个Java服务是否存活如果死了就重启并记录重启日志。#!/bin/bash SERVICE_NAMEuser-service.jar PROCESS_CHECK$(ps -ef | grep $SERVICE_NAME | grep -v grep | wc -l) if [ $PROCESS_CHECK -eq 0 ]; then echo $(date %F %T) service down, restarting... /var/log/service_restart.log nohup java -jar /opt/apps/$SERVICE_NAME /dev/null 21 fi这个脚本有太多可以挖的坑了笔试里会把这些坑拆成不同的选择题来考。第一grep -v grep是必须的因为ps -ef本身这条命令在执行时是匹配不到自己这条grep进程的不对实际上它是能匹配到的因为ps -ef输出的命令行里就包含了grep关键字。如果不加grep -v grep这个脚本永远会认为服务还活着。第二用nohup启动后台进程时一定要把标准输出和错误输出重定向到文件或者/dev/null否则脚本执行完后不会退出会被卡在后台。第三这个脚本在笔试简答题里只要给了上面这个基础版本就能得大部分分了但如果能补充一句“实际生产环境建议用systemd或者supervisor托管服务而不是用shell脚本硬拉起”会显得你对生产实践有更完整的认知。3.3 脚本中“语义正确但结果错误”的陷阱京东这套笔试题里有一个特点就是选择题里的Shell脚本选项写得很接近都是“看起来能跑但实际上有微妙问题”。我给你还原一道下面哪个脚本片段可以统计access.log中request_time超过3秒的请求数假设第10列是request_timeA:awk $10 3 access.log | wc -lB:awk {if ($103) print $0} access.log | wc -lC:awk $10 3 access.log | wc -lD:awk $10 3.0 access.log | wc -l看起来A、B、D都差不多对不对实际上D是对的。A和B的问题在于如果request_time是浮点数比如3.5那么$10 3在awk里也是成立的因为awk会把字符串自动转成数值比较。但如果request_time字段恰好是字符串格式比如3.5sA和B的比较行为就变得不可预测了。而D里的3.0明确是浮点数awk会比较精确地做数值比较。这道题的陷阱在于它考的不是“能不能写对”而是“有没有踩过因为格式不统一导致的比较结果错误”的坑。从这个细节可以看出这套题出得很“老炮儿”——它默认你懂基础语法所以要考的是你在真实环境里踩过的那些边角坑。4. 网络与Web服务题真正拉开分差的地方网络题在整套卷子里不算最多但每道题都很有嚼头。因为运维工程师的日常就是在网络、系统、应用三层之间来回穿梭网络基础不扎实后面排查问题根本无从下手。4.1 TCP握手与状态码不是背就完了有一道选择题是TCP建立连接时第三次握手失败服务端处于什么状态我记得当时选项里给了SYN_RECV、ESTABLISHED、LISTEN、CLOSE_WAIT。正确是SYN_RECV。因为服务端收到客户端的SYN后进入SYN_RECV状态并回复SYNACK如果客户端没有回应第三次ACK服务端就会一直停留在SYN_RECV直到超时重传或者连接被清理。这道题背后真正的考点是如何排查SYN_RECV堆积问题。用netstat -anpt | grep SYN_RECV | wc -l能快速看到堆积数量如果这个数值持续很高一般可能是客户端异常、网络丢包、或者服务端半连接队列太小。再往下挖就是调整内核参数net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_syncookies京东这套题里不考你背内核参数的具体数值但会考“出现SYN_RECV堆积时首先该看什么”这就要理解半连接队列的工作机制。我当时答这道题的时候脑子里浮现的是生产环境一次被SYN Flood打的经历这就是做题时“有画面”和“没画面”的区别。HTTP状态码也是常客。有一道多选题问以下哪些状态码表示客户端错误选项里有400、401、403、404、500、502。很多人一看403、404就选了但容易漏掉400请求语法错误和401未认证。而500、502是服务端错误不能选。这种题不难难的是在快速答题时不手滑。4.2 Nginx配置与负载均衡真题拆解Nginx题在这套卷子里的存在感很强毕竟京东的流量规模摆在那里Nginx是接入层最常见的一环。我记得有一道简答题用Nginx配置一个负载均衡将请求转发到后端两台Web服务器192.168.1.11和192.168.1.12权重比例为2:1并且开启健康检查。基础配置是upstream backend { server 192.168.1.11 weight2; server 192.168.1.12 weight1; check interval3000 rise2 fall3 timeout1000; } server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这道题里需要说清楚几个点。第一weight2和weight1意味着轮询时每3次里有2次打到第一台、1次打到第二台这理解起来不难。第二健康检查那段如果没有用开源的nginx_upstream_check_module标准Nginx是不支持check这个指令的更常见的做法是结合proxy_next_upstream来自动跳过故障节点upstream backend { server 192.168.1.11 weight2 max_fails2 fail_timeout10s; server 192.168.1.12 weight1 max_fails2 fail_timeout10s; }这个细节我在笔试里写了因为选择里有一个选项就是max_fails2 fail_timeout10s。它能实现的效果是某台后端在10秒内失败2次就摘除10秒后重新放回。这套参数在真实生产环境里是用了很多年的经典组合。第三好多人在写Nginx配置题时都会忘了proxy_set_header这两行。如果做反代时不传Host头后端的Web服务就不知道怎么处理域名路由可能导致虚拟主机站点配置不生效。这个点大概率会被出题人作为采分点。4.3 DNS和CDN在大厂笔试里为什么总出现为什么京东会考DNS因为大厂的用户分布在全国甚至全球DNS的解析速度和正确性直接影响用户体验。有一道题是用户反馈访问某个域名偶尔打不开排查时发现不同机器解析出来的IP不一样这是什么原因答案方向有两个一是DNS轮询同一个域名配置了多个A记录不同请求会返回不同IP二是DNS缓存不一致不同地区的Local DNS缓存了不同时间点的解析结果。进一步排查要用的命令是dig 114.114.114.114 example.com nslookup example.com这个题在笔试里不算难但它为后面的场景题铺垫了一个思想排查域名问题时先用公网DNS解析一遍再查本机缓存再查后端服务分层排查。CDN相关的题也是围绕这个思路问CNAME记录的作用、回源机制、缓存命中率等等。我当时的答案是CDN的核心思想是把内容分发到离用户最近的节点上CNAME就是把你的域名指向CDN厂商的调度域名由调度系统返回最优节点IP。这道题的回答只要逻辑清晰不需要写太多技术细节就能拿到大部分分数。5. 数据库与中间件MySQL和Redis的高频考法运维面试里数据库和中间件是绕不开的京东的卷子在这方面分配了不小的比例主要聚焦在MySQL和Redis跟实际业务结合得非常紧。5.1 MySQL索引、死锁与主从延迟问题MySQL的选择题里有一道是考索引的有一条SQL执行得很慢explain显示typeALL说明什么答案是全表扫描。进一步的问题是应该如何优化答案不是无脑加索引而是先看WHERE条件和JOIN字段上有没有合适的索引用explain确认有没有走到索引如果已经有索引但没被用到可能就要考虑函数或隐式类型转换导致索引失效。京东这道选择题挖的坑是选项里有一个“没有走索引就一定是因为没建索引”这个说法是错的——有时候建了索引但因为WHERE条件里对字段做了计算比如WHERE DATE(create_time) 2018-09-01索引就失效了。主从延迟也是一道印象深刻的题。题目大概描述线上MySQL主从架构主库写入压力大从库查询数据落后主库好几秒应该怎么处理我给的分层回答是先看从库的Seconds_Behind_Master确认延迟量。用SHOW PROCESSLIST看从库是不是有慢查询在占用IO。如果延迟是单线程复制造成的历史遗留问题考虑升级版本开启多线程复制。如果业务允许把查延迟敏感数据的请求切到主库。这个回答在笔试的简答题格式里算是“标准答题模板”每一行都是一个采分点。出题人想看到的是你遇到主从延迟时不是直接说“升级机器”或者“换架构”而是能按从现象到原因的路径去排查。死锁的题也有但不会像DBA笔试题那样往深了考。它给了一个现象多个事务并发更新同一行数据发生了死锁该如何避免答案方向是保证多个事务以相同顺序加锁、减少事务持有锁的时间、控制并发量。踩分点在于“相同顺序加锁”和“事务尽量短”这两个点答出来这题就差不多稳了。5.2 Redis缓存穿透、击穿、雪崩三兄弟别看Redis现在烂大街了在2018年这套笔试题里它已经是重点了。考法也非常典型一道题把三个概念全部揉在一起让你区分。缓存穿透查询一个数据库里根本不存在的数据缓存里也没有导致每次请求都打到数据库。缓存击穿某一个热点key的缓存过了期大量并发请求同时打到数据库。缓存雪崩大量key在同一时间段集中过期或者缓存节点挂了导致所有请求打到数据库。对应的解法我当时写的是穿透布隆过滤器拦截或者缓存空值。击穿互斥锁重建缓存或者热点key逻辑过期。雪崩过期时间加随机值避免同一时刻集体失效多级缓存兜底。这个题属于“背了就会、不背就编”的类型。但京东出题刁钻的地方在于它问的往往不是“什么是击穿”而是给你一段业务场景描述让你判断是击穿还是穿透。比如某商品的详情页接口突然变慢发现QPS比以前高很多并且所有请求都打到MySQL上了查了一下缓存里压根没有这个key对应的数据问是什么问题。如果只看到“缓存里没有”就选穿透就可能中招因为这道题的场景是缓存过期时间到了大量并发请求同一时刻涌进来所以准确说是击穿。这就提示我们概念不仅要能背出来还要能从现象描述中准确识别出特征。5.3 高可用架构题的一般作答框架每年大厂笔试都会有一道高可用架构题京东2018年这道我按照记忆还原一下设计一套电商系统的核心链路高可用方案包括应用层、缓存层、数据库层。应用层Nginx做负载均衡与故障转移后端多个应用实例横向扩展配合健康检查自动剔除故障节点使用Hystrix或类似组件做服务熔断降级防止故障放大。缓存层Redis采用哨兵或者Cluster模式保证主节点故障能自动切换缓存数据实时写入主节点从节点负责读流量分流给key设置过期时间时增加随机范围防止雪崩。数据库层MySQL主从复制加读写分离双主模式配合VIP漂移用Keepalived或者MMM当时的思路做高可用切换定时备份并做演练保证切换后数据不丢。这套回答的框架是“分层防御”一层出问题下一层兜底。面试官或者阅卷人看重的不是你用了哪个开源组件而是你有没有全链路高可用的意识。我当时把每个层次可能发生的故障和对应的降级策略都写了一句这样阅卷人一眼就能看出我平时是做过整套方案设计的。6. 故障排查场景题没有标准答案但有标准思路场景题是压轴题也是京东这套题里最容易拉开差距的部分。它不像选择题有唯一答案而是给你一段线上的故障描述让你以一名值班运维的身份去分析、排查、处理。我印象里有两道一道是“用户反馈网站变慢”一道是“磁盘满了导致服务不可用”两道都不难但想拿高分需要掌握完整的排查链路。6.1 经典场景用户反馈线上接口变慢你怎么办先说第一道题目描述大概是多个用户反馈商城首页打开很慢运维值班群也出现告警请描述你的排查思路。我的答题框架分五步第一步确认影响范围。先看监控大盘确认是整体变慢还是部分用户变慢是所有入口都慢还是只有首页慢是移动端慢还是PC端慢。这一步的目的是快速定位问题边界避免无头苍蝇式排查。第二步看流量和资源水位。登录跳板机用top、free、df -h看CPU、内存、磁盘是否有异常用vmstat、sar看系统负载和IO情况。这一步能排除掉机器层面的问题。很多新手上来就查应用日志其实应该先确认底层资源是否还够用。第三步查中间件和数据库。如果应用层没毛病就看Nginx的upstream_response_time确认是连接后端慢还是后端处理慢查MySQL的慢查询日志看是不是有SQL拖慢了整个链路用redis-cli -h host -p port info确认缓存命中率看是不是缓存雪崩导致数据库被打爆。第四步查应用日志。确认了大概方向后登录故障机器用tail -f或者grep到关键词比如TimeoutException、Connection refused、OutOfMemoryError找到根因。第五步处理与复盘。先止损比如重启异常进程、摘除故障节点、扩缩容再定位根因最后写复盘报告。我当时把每步的关键命令都写上了比如top、free -h、df -h、ss -lnt、tail -f /var/log/nginx/access.log这种。这个答题思路的好处是阅卷人看不出你“会不会答案”但能看出你有没有真实的值班经验因为你写出了只有做过故障响应的人才会写出来的步骤顺序。6.2 CPU、磁盘、内存问题的完整排查链路第二道场景题我记得是关于磁盘的一台服务器磁盘快满了df -h看/分区使用率95%如何处理这个题太经典了经典到几乎每家公司的运维面试都会问。我当时的答案是分两支一支是临时处理另一支是根因治理。临时处理就是找出大文件并清理df -h du -sh /* 2/dev/null | sort -h du -sh /var/* 2/dev/null | sort -h find / -xdev -size 500M -exec ls -lh {} \;sort -h是人性化排序可以从小到大显示目录占用的空间。这样一级一级往深处追找到大文件。如果大文件是日志可以确认后清空或者滚动 /var/log/nginx/access.log直接用重定向清空而不是rm再新建因为正在被进程占用的文件删除后空间不会释放这种坑笔试里也出现过。根因治理则是把这些写进答案日志定期轮转、配置logrotate、对历史日志做归档压缩、定期清理临时文件、做容量监控报警。我当时写的时候每个动作都对应一个为什么会发生这种问题的原因比如“临时文件没有清理机制”就是根因“删掉大文件”只是治标。这套回答的核心逻辑是“先止血、再还血、再造血”这个表述虽然有点老套但对于阅卷人来说它体现了一个运维最基本的素养故障处理不是把眼前的坑填上就完事了而是要找到让坑变多的原因从机制上解决。6.3 大厂笔试偏好的“分层排查”表述京东这套场景题的采分点和大家平时背的面试题答案最大的区别在于它特别看重“先哪一步、后哪一步”的逻辑顺序。同样是知道要查top、要看日志、要看数据库如果你的步骤是“先看应用日志”那和“先看整体流量和资源水位”相比在阅卷人眼里差距很大。我当时总结了一套自己的表述模板基本可以套用在所有故障排查场景题里第一段写“先确认影响范围和现象”。第二段写“从网络层、系统层、应用层、数据层逐层向下排查”。第三段写“找到根因后进行止损和恢复”。第四段写“长期优化和预防措施”。这个模板的好处是层次分明阅卷人一看就知道你心里有谱。但要注意它只是一个框架分数还是看你在每一层里能不能写出具体的命令和判断逻辑。如果只是写“查一下CPU”“查一下日志”没有具体到命令和可能的结果那分数也高不到哪去。7. 备考心得过了笔试之后回头看哪些准备是真正有效的笔试通过之后后面还有一轮轮的面试但那又是另一个话题了。今天只聊针对京东这套笔试题什么样的复习方式是最有效率的。毕竟我也不是裸考过的中间还是有一些方法可以说说。7.1 实验比背题重要很多人在准备这种笔试时习惯去找题背。但京东这套题给我的感觉是你光背题是没有用的因为它的干扰项设置得非常“实战”如果你没有真正在命令行里跑过awk、sed、find这些命令你就很难判断某个命令输出到底长什么样、某个参数加了和没加到底有什么区别。我当时备考的时候特意把题目里涉及到的命令全部在虚拟机里实际操作了一遍。比如find的-mtime参数就在/tmp下造了几个不同修改时间的文件看看-mtime -7和-mtime 7的输出有什么不同。这比死记硬背印象深得多做题遇到相关选项时基本秒选。还有人会说我光看题不就行了吗不行。因为这套题里很多东西是“手熟”带来的比如你写过百八十个Shell脚本之后看到一道脚本题你能立刻判断出哪个选项里少了重定向、哪个选项会把脚本卡死、哪个选项在语法上合法但逻辑上错得很隐蔽。这种能力和语感一样只有靠实践积累没有捷径。7.2 简历上没有的项目笔试里全暴露了这句话是我后来总结出来的。很多同学在简历上写“精通Linux运维”“熟练使用Shell脚本”“掌握Nginx和Redis”但到了京东这套笔试题里你会发现自己简历上写的东西和实际会的东西存在一个巨大的鸿沟。比如简历上写“掌握Shell”但笔试里问的是“如何避免ps -ef | grep xxx匹配到自身”“如何统计日志中某个状态码的出现次数并触发告警”“如何判断一个浮点数比较是否可靠”。这些东西每一个都是基础但每一个都默认你有大量的实操经验。所以如果你准备投类似的岗位不要只在简历上堆技术名词多问问自己如果笔试里让我写一段脚本监控Nginx进程我能不看参考就完整写出来吗我当时就因为这道题吃了点小亏。我平时写脚本都在公司的一台测试机上改来改去但没有在纸上手写过完整脚本。笔试里要求手写虽然没有语法严格要求跟机器上跑完全一样但逻辑上的缺失会导致扣分。那次之后我养成了一个习惯写完脚本先在心里跑一遍或者有条件就在本地快速验证确认没有语法问题或者逻辑遗漏。7.3 时间管理和答案呈现技巧最后说一个老生常谈但确实有用的话题答题顺序和时间分配。京东这套题的题量不算小我前面说过选择题大概40到50道后面还有简答和场景题。如果前面选择题卡壳太久后面能拿大分的题就写快了总分反而不高。我的策略是选择题不会的做个标记直接跳过等后面的题写完了再回头来啃简答题和场景题先列关键点尽量用“先…再…然后…”的结构把逻辑写清楚不要想到什么写什么。还有一个很实用的小技巧场景题和简答题写在答题框里的内容不要用作文题那种整个段落怼上去要分条目、分层次一句话一个点。阅卷人看这种卷子的时候速度很快分条列点的答案他一眼扫过去就能抓到采分点写成大段落反而容易漏掉关键信息。另外如果题目要求“给出排查思路”不要只写结论比如“重启服务”“增加机器”要有推理过程。比如“先用top -Hp找到高CPU线程再用jstack查看线程堆栈确认是不是GC线程频繁执行如果是进一步看堆内存配置是否合理”。每一步都有依据而不是上来就下结论。这种思维方式既是笔试考察的核心也是实际运维工作里最需要的能力。好了关于京东2018秋招技术运维工程师笔试题我能回忆起来的内容就是这些。这套题虽然过去好几年了但它的出题思路和考点范围在今天依然有很强的参考意义——Linux命令的细节、Shell脚本的坑、网络协议的底层逻辑、故障排查的分层方法论这些永远都是运维岗的看家本事。不管你是准备笔试还是面试或者只是想系统地补一补运维基础沿着这个框架去梳理应该会比盲目刷题高效得多。