2019年秋天我坐在某大学的机房参加一场校招笔试拿到卷子翻了翻心里有点凉Linux进程状态、TCP握手、MySQL索引失效、Nginx日志统计、Shell脚本、Python编程……前后几十道题覆盖面之广像是一次“全科体检”。但也就是从那一刻起我意识到运维开发这个岗位要的人本来就不是只会敲命令的“机房管理员”而是能写代码、能排查问题、能理解整个系统链路的人。这篇文章不是去背一份具体的“京东原题清单”而是从一份真实校招卷子的视角拆解运维开发笔试到底在考什么、为什么这么考、做对一道题和真正理解一个知识点之间差多远。无论你现在是大三准备秋招还是已经工作想转岗运维开发这份复盘都能帮你少走不少弯路。1. 为什么运维开发笔试总让人感觉“什么都考”1.1 运维开发不是“运维开发”的简单叠加很多同学一开始会把运维开发理解成“一半运维、一半开发”但实际上这个岗位的核心是用开发的思路解决运维场景里的问题。简单点说运维要做的是保证系统稳定、高效、自动化开发要做的是把重复手工操作变成工具和平台。两者叠加之后需要的能力边界就变得很宽。笔试之所以让人觉得“什么都考”是因为在一线大厂里运维开发工程师真的要同时面对Linux系统、网络、数据库、脚本、CI/CD、容器、监控告警这些方向。你很难预料生产环境下一个故障会出现在哪一层所以笔试题只能尽量覆盖所有基础面先筛掉那些明显没有工程现场感的人。2019年前后正是互联网业务快速扩张的时期服务端规模变得非常大线上变更频繁故障处理压力也随之上升。京东这类公司对运维开发校招生的期待是第一基础扎实能看懂系统现状第二有工程思维知道用工具和代码解决问题而不是全靠手动。所以笔试里出现“超长清单”就一点也不奇怪了。1.2 京东这类大厂校招笔试的出题套路从我当年参加和后来看题库的经验来说运维开发笔试卷一般分四个部分选择题20到30道范围覆盖Linux、网络、数据库、脚本语言基础每题并不深但绝对拉得分。简答题2到3道通常是故障排查、架构分析比如“线上服务变慢了怎么排查”。编程题1到2道Shell或Python任选常和日志分析、文本处理、报警脚本相关。综合题偶尔会有给定一个运维场景要求设计监控方案或自动化流程。整张卷子的时间一般是90分钟到120分钟选择题不能犹豫太久否则编程题根本写不完。出题人不是真想让你背出每一个命令的每一个参数而是把一个场景摆在你面前看你知道用什么工具、按什么顺序查、能不能用代码把重复工作自动化。这种“场景化出题”是校招运维开发笔试最明显的特点。2. 高频考点拆解从Linux到HTTP每一类题背后的真实意图2.1 Linux基础与系统管理不是背命令是看排查思路Linux是运维开发的基本盘笔试里出现频率最高的就是这部分。但别以为只是考“chmod 755是什么意思”现在的大厂更喜欢把命令放在故障场景里。常见考点可以分成几类进程管理ps、top、htop僵尸进程、孤儿进程、进程状态。内存与磁盘free、df、du、iostat内存缓冲、inode耗尽、磁盘IO瓶颈。网络排查netstat、ss、lsof、ping、telnet、curl、traceroute。文本处理grep、awk、sed、sort、uniq从日志里提取信息。文件系统软链接/硬链接、权限、文件描述符。笔试经常出现这类题目查看8080端口是否被占用下列哪个命令可以或者如何找出占用CPU最高的进程这类题并不是单纯考命令拼写而是在考你的排查顺序。比如找CPU最高进程很多人知道top然后按P但也可以用ps aux --sort-%cpu | head -5能写出这种命令说明你对ps的输出字段有理解。再比如系统负载load average是1.5代表什么如果机器是单核这个值说明负载偏高如果是四核说明还在可接受范围。这里考察的是“指标背后的含义”不是背一个数字。2.2 网络与HTTP答对题的关键在于分层思维网络题几乎必考。常见的是TCP三次握手和四次挥手、TIME_WAIT和CLOSE_WAIT的区别、HTTP状态码、GET和POST的区别、DNS解析流程、Nginx反向代理和负载均衡策略。有一道经典题直到现在还在各种笔试卷里出现浏览器输入www.example.com后发生了什么这道题能从DNS解析一路说到TCP建连、HTTP请求、反向代理、应用处理、数据库查询、响应返回相当于把整个网络链路串起来。出题人非常喜欢用这种题判断候选人有没有“全链路思维”。做网络题的时候最重要的是分层思维。发现网站访问慢先判断是客户端问题、DNS问题、网络传输问题还是服务器后端问题。每一层用什么工具查要非常清楚。排查层次常用工具/手段客户端与DNSdig、nslookup、curl -w网络传输ping、traceroute、mtrTCP/HTTP连接telnet、nc、curl、ss接入层/Web层Nginx访问日志、upstream耗时应用与数据层应用日志、慢SQL、Redis延时数据库和Nginx的题也经常出现。Nginx的负载均衡策略有轮询、权重、IP哈希、最少连接笔试会问“某个用户登录后再次请求却被分配到另一台服务器导致session丢失怎么办”答案就是IP哈希或共享Session。这种题没有难度但没接触过生产环境的人容易懵。2.3 数据库与缓存SQL功底和索引意识数据库方向MySQL一定是重点。笔试题很少让你手写特别复杂的SQL更多是考索引、事务、执行计划、慢查询优化。索引失效场景几乎是必考题like %xxx会导致索引失效在索引列上做函数运算会失效隐式类型转换会失效不满足最左前缀原则也会失效。这些知识点不背的话很容易混。事务部分考ACID、隔离级别、脏读、幻读、不可重复读。主从复制也会被问到比如“主库挂了怎么办”“从库延迟怎么处理”。Redis在2019年的运维开发笔试题里已经开始出现常见的是五种数据类型、缓存穿透、击穿、雪崩的区别以及过期删除策略。这些概念需要理解场景比如缓存穿透可以用布隆过滤器解决缓存雪崩可以给过期时间加随机值这些都是可以直接写进答案的实操经验。准备数据库部分不要只看理论最好亲手在MySQL里跑一下EXPLAIN观察type、key、rows这些字段。笔试简答题如果让你分析一条SQL为什么不走索引你能说清楚执行计划分数会高不少。2.4 Shell/Python脚本能力是运维开发的硬通货如果说Linux命令是“手”Shell和Python就是“工具”。笔试里的编程题大概率是日志统计、文件处理、批量操作、监控脚本这些场景官方通常不限定语言但Shell和Python是最稳的选择。Shell考察点包括变量、循环、条件判断、管道、正则、awk、sed。它最适合做文本处理和系统命令组装写起来短适合笔试时间限制。Python考察点更偏向文件读写、os/subprocess/re/logging、requests库等。如果场景涉及复杂数据结构、API调用、多步骤逻辑Python更合适。我见过很多候选人在笔试编程题上翻车不是因为不会写而是没看清楚题目要求。比如题目说“日志文件可能几个GB”你还用read()一次性读进内存就暴露了完全没有大数据量处理意识。正确的做法是逐行读取迭代处理或者用awk流式处理。笔试题不一定要求最优解但你要让阅卷人看到你有工程思维。2.5 容器、监控与CI/CD贴近生产环境的前沿考点2019年前后的校招笔试卷容器和CI/CD还不会像今天这么多但已经零星出现。Docker的常用命令、镜像和容器的区别、端口映射、数据卷这些是基础。稍微考深一点会问Docker与虚拟机的区别、镜像分层原理。Kubernetes在当时的笔试里更多是概念级选择题比如Pod是什么、Deployment和StatefulSet的区别。不过如果你能多写一点“容器编排解决了什么问题”已经能拉开差距。监控监控方面Zabbix和Prometheus是当时的两个主流方案。笔试不一定让你写配置但可能会问“CPU使用率突然飙升你会监控哪些指标”“告警脚本如何避免重复通知”。这些题目背后考的是你是否理解监控不是只收集数据而是要服务于告警和故障定位。CI/CD的考点包括持续集成和持续交付的区别、Jenkins流水线的概念、自动化部署的基本步骤。哪怕没有实际搭建经验也建议把一套最简单的“代码提交→自动构建→自动部署”流程说清楚。3. 三道典型笔试题的完整解析从读题到拿分3.1 选择题Linux进程状态的判定先来看一道很典型的选择题题目Linux系统中下列哪一项不是进程状态A. TASK_RUNNINGB. TASK_INTERRUPTIBLEC. TASK_UNINTERRUPTIBLED. TASK_DEAD很多同学看到A就觉得运行中肯定是进程状态B和C也见过。D是TASK_DEAD看起来也合理容易犹豫。实际Linux内核里的进程状态主要是TASK_RUNNING、TASK_INTERRUPTIBLE、TASK_UNINTERRUPTIBLE、TASK_STOPPED、TASK_TRACED、TASK_ZOMBIE等并没有一个叫TASK_DEAD的正式状态。所以答案应该是D。这道题和ps输出里的R、S、D、T、Z是一一对应的如果你能说出D状态表示不可中断睡眠通常和磁盘IO有关就已经超出“背选项”的层次了。做这类题的建议是用状态机思维去理解进程切换而不是死记字母。什么状态下进程会进入中断睡眠什么情况下会变成僵尸进程理解之后所有类似题目都能顺手做出来。3.2 简答题网站访问慢的排查思路简答题比选择题更吃逻辑比如这道高频题用户反馈Web服务访问很慢请写出你的排查步骤。如果只写“查看服务器CPU、内存”能得一部分分但拿不到高分。一个能体现工程经验的答案应该是分层的确认问题范围是所有用户都慢还是某个地区/某个运营商慢是所有页面慢还是单个接口慢最近是否有发布变更客户端与网络层用curl -w查看连接耗时、首字节时间用dig确认DNS解析是否异常用ping或mtr看网络链路是否丢包、延迟高。接入层看Nginx访问日志找upstream_response_time看是不是后端响应慢观察是否有大量5xx、4xx。应用层查看应用日志、慢请求日志、GC日志检查线程池和连接池是否被打满。系统层top看CPU和负载free看内存iostat看磁盘IOdmesg看内核日志。数据层查MySQL慢查询日志看是否存在慢SQLRedis是否命中率下降、有大key阻塞。这类题没有唯一标准答案阅卷人看的是你有没有“分层排查”的意识。答题时尽量写步骤加理由比如“先确认范围是为了避免盲目查服务端把问题扩大化”。3.3 编程题写一个日志文件按小时统计的脚本有一类编程题出现频率非常高给定一个访问日志要求统计某个维度并输出Top N。例如统计Nginx access.log中访问次数最多的前10个IP。Shell的解法很直接awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这条命令的思路是取第一列IP排序后统计出现次数再按次数降序排列最后取前10。注意排序和去重的顺序不能反必须先sort再uniq -c。Python的解法可以写得更有工程感from collections import Counter ip_counter Counter() with open(access.log, r, encodingutf-8) as f: for line in f: ip line.split()[0] ip_counter[ip] 1 for ip, count in ip_counter.most_common(10): print(f{ip}\t{count})这个版本做了两件对笔试加分的事用with open逐行读取避免大日志一次性载入内存用Counter统计代码简洁可读。如果题目特意强调“日志文件有几十GB”你可以在Python解法后面补一句“如果文件超过单机内存可以分片处理或多进程并行”这会让阅卷人觉得你有真实处理经验。这道题的易错点有三个一是忽略日志格式假设IP一定在第一列二是忘记先去重直接数三是不处理空行或格式异常的行。答题时写清输入输出能处理异常更好这些都是工程素养的体现。3.4 分析题数据库慢查询优化最后一类典型题是SQL优化。比如这样的描述订单表orders数据量很大字段包括id、user_id、goods_id、status、created_at。执行SELECT * FROM orders WHERE status 0 AND created_at 2019-01-01 ORDER BY created_at DESC; 发现非常慢如何优化我的答题思路可以分四步先看执行计划。用EXPLAIN判断当前是否全表扫描关注type、key、rows字段。如果看到typeALL说明没走索引这是首要问题。分析过滤条件。status字段区分度可能很低created_at区分度高。如果业务上status0的数据量很小可以建联合索引(status, created_at)如果status0占比很大索引帮助有限需要考虑分区表或改成其他查询方式。避免SELECT *。只查需要的字段最好做成覆盖索引让查询不用回表。关注排序。ORDER BY created_at如果已经在联合索引里可以避免filesort效果更加明显。答案里最忌讳的是只写一句“加索引”。加在哪个字段上、为什么加、会带来什么副作用这些才是笔试真正想看到的。你还能提一句“实际优化后需要在测试环境用真实数据量压测验证”说明你不是只会背步骤而是真知道线上环境的不确定性。4. 笔试之后简历项目和知识体系如何被面试官追问4.1 简历项目不是越多越好而是要有“排查链路”笔试考的是知识面面试考的是你能不能把知识串起来。很多人简历上写“搭建了Zabbix监控系统”这种描述太薄了面试官一句话就能问到底监控了哪些指标告警阈值怎么定的收到告警之后你做了什么同样一个项目如果换成这样写会好很多搭建Zabbix监控系统负责CPU、内存、磁盘、核心接口耗时的监控设置分级告警解决了一次因磁盘inode耗尽导致服务无响应的问题事后输出故障复盘文档并编写脚本自动清理过期临时文件。这里的关键是“排查链路”发现问题、定位原因、解决手段、最终结果。面试官一听到你能把故障前因后果讲清楚就会默认你是真的做过而不是背了名词。4.2 面试官如何从笔试答案推断你的排错能力我后来参与过一些面试看到笔试答卷时会重点看两类信息。一类是简答题的“分点”能力。能写“第一步、第二步、第三步”的人通常做事的结构化程度也高只写几个碎片命令的人可能连故障处理顺序都没想明白。另一类是编程题的“边界处理”。代码里有没有考虑文件不存在、日志格式变化、数据量过大这些细节决定了你是“写demo”还是“写工具”。哪怕笔试时间不够在注释里写一句“生产环境需要补充异常处理”也会让阅卷人看到你的工程意识。4.3 运维开发工程师的软技能沟通、文档和复盘很多人觉得运维开发只要能搞定技术就行但实际工作中你需要跟开发同学确认业务逻辑跟DBA商量数据库索引方案跟产品解释故障原因。笔试里偶尔会出现“你收到告警后先通知谁、再处理什么”这类题目本质上就是在考沟通顺序和优先级。我的建议是平时多做复盘记录。每次解决一个问题就用“现象、定位、原因、处理、改进”五个段落记下来。这既锻炼书面表达也能帮你在面试时讲出完整故事。笔试并不直接考写文档但这种复盘习惯会体现在你答题的条理里。5. 备考路线图如果回到2019年我会这样准备5.1 基础期两周补齐Linux、网络、数据库硬知识如果准备时间只有一个月前两周一定要把基础打牢。第一周主打Linux每天练习高频命令。不用刻意背重点放在“命令能解决什么问题”上。比如今天学top和ps就自己模拟一个CPU升高的场景再想办法找到占用高的进程。今天学awk和sed就拿一个真实日志文件反复清洗字段。第二周主攻网络和数据库。TCP握手、HTTP状态码、DNS这些必须理解到能讲清楚MySQL重点看索引和EXPLAIN把联合索引最左前缀“索引失效的常见原因”在本地数据库里验证一遍。参考书不用贪多《鸟哥的Linux私房菜》基础篇、《图解HTTP》、《高性能MySQL》里的索引章节就够用了。关键是每个知识点都要亲手做实验眼过千遍不如手过一遍。5.2 脚本期每天一个真实场景的Shell/Python练习第三周开始每天至少完成一个脚本题。不需要题目多难但要贴近真实场景。我总结过一份练习清单统计access.log中Top 10的IP找出/tmp目录下7天没被访问的文件并删除批量备份多台服务器的指定目录检查Nginx进程是否存在不存在则自动拉起并发送告警用Python调用一个API接口解析返回的JSON并输出关键字段定时清理超过1GB的日志文件写一个MySQL自动备份脚本保留最近7天按照进程名获取PID并统计内存占用解析URL中的参数并转换成字典编写一个磁盘使用率监控脚本超过阈值时告警先尝试用Shell做卡住了再换Python最后对比两种方案的优缺点。这个过程中积累的“为什么有时候用Shell更合适有时候用Python更稳”的体会是任何教程都给不了你的。5.3 项目期把课程设计包装成有数据、有结论的运维项目第四周建议集中把简历里的项目打磨一下。很多同学觉得没有运维项目可写其实课程设计完全可以改造。比如你在学校做过一个信息管理系统就可以把它部署到一台云服务器上用Nginx做反向代理后端接MySQL然后写一个脚本每分钟检查服务健康状态宕机自动重启。整个过程做完你能说清楚服务是怎么跑起来的也能说清楚监控和自愈是怎么做的这就是一个不错的运维开发项目。写项目描述时别只说“实现了什么功能”要贴上可量化的数据。比如接口响应从2秒降到300毫秒日志扫描从原来的10分钟降到30秒这些数字比形容词有说服力得多。5.4 冲刺期真题节奏与错题本考前最后两周进入刷题模式。每天一套题严格按考试时间完成。刷题的目的不是背答案而是训练自己的时间分配选择题遇到不确定的先标记不要死磕编程题至少留出30分钟。准备一个错题本但不要抄题目只记录错题背后的知识点。比如“这道题考了TIME_WAIT我原来理解错了”然后用自己的话写一遍正确解释。复习的时候只看错题本效率会非常高。5.5 关于真题来源和资料选择的一些建议刷题可以去牛客网找历年校招题也可以看一些大厂面试经验帖但不要迷信“押题”和“原题”。运维开发笔试变化并不快核心知识就那些关键是把基础吃透。还有一个建议多查官方文档和man page。很多人遇到不会的命令直接搜博客但最准确的永远是man page。看完man page再结合场景实验记忆深刻得多。6. 写在最后笔试不是终点而是一面镜子回头看2019年那场考试真正让我收获的不是“我拿到了Offer”而是它逼着我把碎片化的知识串成了体系。我后来发现能通过运维开发笔试的人往往不是刷得最多的人而是那些愿意动手实践、能把命令、脚本、网络原理连成一条线的人。如果你正在准备校招别急着收藏一堆资料先打开终端把这篇里提到的场景亲手敲一遍。做错几道题没有关系把错题后面的知识块补齐比多看十套卷子都管用。祝你在下一次笔试里遇到的不只是会做的题更是你真的理解过的系统。 运维开发笔试高频考点全拆解：从Linux到MySQL索引的实战复盘
2019年秋天我坐在某大学的机房参加一场校招笔试拿到卷子翻了翻心里有点凉Linux进程状态、TCP握手、MySQL索引失效、Nginx日志统计、Shell脚本、Python编程……前后几十道题覆盖面之广像是一次“全科体检”。但也就是从那一刻起我意识到运维开发这个岗位要的人本来就不是只会敲命令的“机房管理员”而是能写代码、能排查问题、能理解整个系统链路的人。这篇文章不是去背一份具体的“京东原题清单”而是从一份真实校招卷子的视角拆解运维开发笔试到底在考什么、为什么这么考、做对一道题和真正理解一个知识点之间差多远。无论你现在是大三准备秋招还是已经工作想转岗运维开发这份复盘都能帮你少走不少弯路。1. 为什么运维开发笔试总让人感觉“什么都考”1.1 运维开发不是“运维开发”的简单叠加很多同学一开始会把运维开发理解成“一半运维、一半开发”但实际上这个岗位的核心是用开发的思路解决运维场景里的问题。简单点说运维要做的是保证系统稳定、高效、自动化开发要做的是把重复手工操作变成工具和平台。两者叠加之后需要的能力边界就变得很宽。笔试之所以让人觉得“什么都考”是因为在一线大厂里运维开发工程师真的要同时面对Linux系统、网络、数据库、脚本、CI/CD、容器、监控告警这些方向。你很难预料生产环境下一个故障会出现在哪一层所以笔试题只能尽量覆盖所有基础面先筛掉那些明显没有工程现场感的人。2019年前后正是互联网业务快速扩张的时期服务端规模变得非常大线上变更频繁故障处理压力也随之上升。京东这类公司对运维开发校招生的期待是第一基础扎实能看懂系统现状第二有工程思维知道用工具和代码解决问题而不是全靠手动。所以笔试里出现“超长清单”就一点也不奇怪了。1.2 京东这类大厂校招笔试的出题套路从我当年参加和后来看题库的经验来说运维开发笔试卷一般分四个部分选择题20到30道范围覆盖Linux、网络、数据库、脚本语言基础每题并不深但绝对拉得分。简答题2到3道通常是故障排查、架构分析比如“线上服务变慢了怎么排查”。编程题1到2道Shell或Python任选常和日志分析、文本处理、报警脚本相关。综合题偶尔会有给定一个运维场景要求设计监控方案或自动化流程。整张卷子的时间一般是90分钟到120分钟选择题不能犹豫太久否则编程题根本写不完。出题人不是真想让你背出每一个命令的每一个参数而是把一个场景摆在你面前看你知道用什么工具、按什么顺序查、能不能用代码把重复工作自动化。这种“场景化出题”是校招运维开发笔试最明显的特点。2. 高频考点拆解从Linux到HTTP每一类题背后的真实意图2.1 Linux基础与系统管理不是背命令是看排查思路Linux是运维开发的基本盘笔试里出现频率最高的就是这部分。但别以为只是考“chmod 755是什么意思”现在的大厂更喜欢把命令放在故障场景里。常见考点可以分成几类进程管理ps、top、htop僵尸进程、孤儿进程、进程状态。内存与磁盘free、df、du、iostat内存缓冲、inode耗尽、磁盘IO瓶颈。网络排查netstat、ss、lsof、ping、telnet、curl、traceroute。文本处理grep、awk、sed、sort、uniq从日志里提取信息。文件系统软链接/硬链接、权限、文件描述符。笔试经常出现这类题目查看8080端口是否被占用下列哪个命令可以或者如何找出占用CPU最高的进程这类题并不是单纯考命令拼写而是在考你的排查顺序。比如找CPU最高进程很多人知道top然后按P但也可以用ps aux --sort-%cpu | head -5能写出这种命令说明你对ps的输出字段有理解。再比如系统负载load average是1.5代表什么如果机器是单核这个值说明负载偏高如果是四核说明还在可接受范围。这里考察的是“指标背后的含义”不是背一个数字。2.2 网络与HTTP答对题的关键在于分层思维网络题几乎必考。常见的是TCP三次握手和四次挥手、TIME_WAIT和CLOSE_WAIT的区别、HTTP状态码、GET和POST的区别、DNS解析流程、Nginx反向代理和负载均衡策略。有一道经典题直到现在还在各种笔试卷里出现浏览器输入www.example.com后发生了什么这道题能从DNS解析一路说到TCP建连、HTTP请求、反向代理、应用处理、数据库查询、响应返回相当于把整个网络链路串起来。出题人非常喜欢用这种题判断候选人有没有“全链路思维”。做网络题的时候最重要的是分层思维。发现网站访问慢先判断是客户端问题、DNS问题、网络传输问题还是服务器后端问题。每一层用什么工具查要非常清楚。排查层次常用工具/手段客户端与DNSdig、nslookup、curl -w网络传输ping、traceroute、mtrTCP/HTTP连接telnet、nc、curl、ss接入层/Web层Nginx访问日志、upstream耗时应用与数据层应用日志、慢SQL、Redis延时数据库和Nginx的题也经常出现。Nginx的负载均衡策略有轮询、权重、IP哈希、最少连接笔试会问“某个用户登录后再次请求却被分配到另一台服务器导致session丢失怎么办”答案就是IP哈希或共享Session。这种题没有难度但没接触过生产环境的人容易懵。2.3 数据库与缓存SQL功底和索引意识数据库方向MySQL一定是重点。笔试题很少让你手写特别复杂的SQL更多是考索引、事务、执行计划、慢查询优化。索引失效场景几乎是必考题like %xxx会导致索引失效在索引列上做函数运算会失效隐式类型转换会失效不满足最左前缀原则也会失效。这些知识点不背的话很容易混。事务部分考ACID、隔离级别、脏读、幻读、不可重复读。主从复制也会被问到比如“主库挂了怎么办”“从库延迟怎么处理”。Redis在2019年的运维开发笔试题里已经开始出现常见的是五种数据类型、缓存穿透、击穿、雪崩的区别以及过期删除策略。这些概念需要理解场景比如缓存穿透可以用布隆过滤器解决缓存雪崩可以给过期时间加随机值这些都是可以直接写进答案的实操经验。准备数据库部分不要只看理论最好亲手在MySQL里跑一下EXPLAIN观察type、key、rows这些字段。笔试简答题如果让你分析一条SQL为什么不走索引你能说清楚执行计划分数会高不少。2.4 Shell/Python脚本能力是运维开发的硬通货如果说Linux命令是“手”Shell和Python就是“工具”。笔试里的编程题大概率是日志统计、文件处理、批量操作、监控脚本这些场景官方通常不限定语言但Shell和Python是最稳的选择。Shell考察点包括变量、循环、条件判断、管道、正则、awk、sed。它最适合做文本处理和系统命令组装写起来短适合笔试时间限制。Python考察点更偏向文件读写、os/subprocess/re/logging、requests库等。如果场景涉及复杂数据结构、API调用、多步骤逻辑Python更合适。我见过很多候选人在笔试编程题上翻车不是因为不会写而是没看清楚题目要求。比如题目说“日志文件可能几个GB”你还用read()一次性读进内存就暴露了完全没有大数据量处理意识。正确的做法是逐行读取迭代处理或者用awk流式处理。笔试题不一定要求最优解但你要让阅卷人看到你有工程思维。2.5 容器、监控与CI/CD贴近生产环境的前沿考点2019年前后的校招笔试卷容器和CI/CD还不会像今天这么多但已经零星出现。Docker的常用命令、镜像和容器的区别、端口映射、数据卷这些是基础。稍微考深一点会问Docker与虚拟机的区别、镜像分层原理。Kubernetes在当时的笔试里更多是概念级选择题比如Pod是什么、Deployment和StatefulSet的区别。不过如果你能多写一点“容器编排解决了什么问题”已经能拉开差距。监控监控方面Zabbix和Prometheus是当时的两个主流方案。笔试不一定让你写配置但可能会问“CPU使用率突然飙升你会监控哪些指标”“告警脚本如何避免重复通知”。这些题目背后考的是你是否理解监控不是只收集数据而是要服务于告警和故障定位。CI/CD的考点包括持续集成和持续交付的区别、Jenkins流水线的概念、自动化部署的基本步骤。哪怕没有实际搭建经验也建议把一套最简单的“代码提交→自动构建→自动部署”流程说清楚。3. 三道典型笔试题的完整解析从读题到拿分3.1 选择题Linux进程状态的判定先来看一道很典型的选择题题目Linux系统中下列哪一项不是进程状态A. TASK_RUNNINGB. TASK_INTERRUPTIBLEC. TASK_UNINTERRUPTIBLED. TASK_DEAD很多同学看到A就觉得运行中肯定是进程状态B和C也见过。D是TASK_DEAD看起来也合理容易犹豫。实际Linux内核里的进程状态主要是TASK_RUNNING、TASK_INTERRUPTIBLE、TASK_UNINTERRUPTIBLE、TASK_STOPPED、TASK_TRACED、TASK_ZOMBIE等并没有一个叫TASK_DEAD的正式状态。所以答案应该是D。这道题和ps输出里的R、S、D、T、Z是一一对应的如果你能说出D状态表示不可中断睡眠通常和磁盘IO有关就已经超出“背选项”的层次了。做这类题的建议是用状态机思维去理解进程切换而不是死记字母。什么状态下进程会进入中断睡眠什么情况下会变成僵尸进程理解之后所有类似题目都能顺手做出来。3.2 简答题网站访问慢的排查思路简答题比选择题更吃逻辑比如这道高频题用户反馈Web服务访问很慢请写出你的排查步骤。如果只写“查看服务器CPU、内存”能得一部分分但拿不到高分。一个能体现工程经验的答案应该是分层的确认问题范围是所有用户都慢还是某个地区/某个运营商慢是所有页面慢还是单个接口慢最近是否有发布变更客户端与网络层用curl -w查看连接耗时、首字节时间用dig确认DNS解析是否异常用ping或mtr看网络链路是否丢包、延迟高。接入层看Nginx访问日志找upstream_response_time看是不是后端响应慢观察是否有大量5xx、4xx。应用层查看应用日志、慢请求日志、GC日志检查线程池和连接池是否被打满。系统层top看CPU和负载free看内存iostat看磁盘IOdmesg看内核日志。数据层查MySQL慢查询日志看是否存在慢SQLRedis是否命中率下降、有大key阻塞。这类题没有唯一标准答案阅卷人看的是你有没有“分层排查”的意识。答题时尽量写步骤加理由比如“先确认范围是为了避免盲目查服务端把问题扩大化”。3.3 编程题写一个日志文件按小时统计的脚本有一类编程题出现频率非常高给定一个访问日志要求统计某个维度并输出Top N。例如统计Nginx access.log中访问次数最多的前10个IP。Shell的解法很直接awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这条命令的思路是取第一列IP排序后统计出现次数再按次数降序排列最后取前10。注意排序和去重的顺序不能反必须先sort再uniq -c。Python的解法可以写得更有工程感from collections import Counter ip_counter Counter() with open(access.log, r, encodingutf-8) as f: for line in f: ip line.split()[0] ip_counter[ip] 1 for ip, count in ip_counter.most_common(10): print(f{ip}\t{count})这个版本做了两件对笔试加分的事用with open逐行读取避免大日志一次性载入内存用Counter统计代码简洁可读。如果题目特意强调“日志文件有几十GB”你可以在Python解法后面补一句“如果文件超过单机内存可以分片处理或多进程并行”这会让阅卷人觉得你有真实处理经验。这道题的易错点有三个一是忽略日志格式假设IP一定在第一列二是忘记先去重直接数三是不处理空行或格式异常的行。答题时写清输入输出能处理异常更好这些都是工程素养的体现。3.4 分析题数据库慢查询优化最后一类典型题是SQL优化。比如这样的描述订单表orders数据量很大字段包括id、user_id、goods_id、status、created_at。执行SELECT * FROM orders WHERE status 0 AND created_at 2019-01-01 ORDER BY created_at DESC; 发现非常慢如何优化我的答题思路可以分四步先看执行计划。用EXPLAIN判断当前是否全表扫描关注type、key、rows字段。如果看到typeALL说明没走索引这是首要问题。分析过滤条件。status字段区分度可能很低created_at区分度高。如果业务上status0的数据量很小可以建联合索引(status, created_at)如果status0占比很大索引帮助有限需要考虑分区表或改成其他查询方式。避免SELECT *。只查需要的字段最好做成覆盖索引让查询不用回表。关注排序。ORDER BY created_at如果已经在联合索引里可以避免filesort效果更加明显。答案里最忌讳的是只写一句“加索引”。加在哪个字段上、为什么加、会带来什么副作用这些才是笔试真正想看到的。你还能提一句“实际优化后需要在测试环境用真实数据量压测验证”说明你不是只会背步骤而是真知道线上环境的不确定性。4. 笔试之后简历项目和知识体系如何被面试官追问4.1 简历项目不是越多越好而是要有“排查链路”笔试考的是知识面面试考的是你能不能把知识串起来。很多人简历上写“搭建了Zabbix监控系统”这种描述太薄了面试官一句话就能问到底监控了哪些指标告警阈值怎么定的收到告警之后你做了什么同样一个项目如果换成这样写会好很多搭建Zabbix监控系统负责CPU、内存、磁盘、核心接口耗时的监控设置分级告警解决了一次因磁盘inode耗尽导致服务无响应的问题事后输出故障复盘文档并编写脚本自动清理过期临时文件。这里的关键是“排查链路”发现问题、定位原因、解决手段、最终结果。面试官一听到你能把故障前因后果讲清楚就会默认你是真的做过而不是背了名词。4.2 面试官如何从笔试答案推断你的排错能力我后来参与过一些面试看到笔试答卷时会重点看两类信息。一类是简答题的“分点”能力。能写“第一步、第二步、第三步”的人通常做事的结构化程度也高只写几个碎片命令的人可能连故障处理顺序都没想明白。另一类是编程题的“边界处理”。代码里有没有考虑文件不存在、日志格式变化、数据量过大这些细节决定了你是“写demo”还是“写工具”。哪怕笔试时间不够在注释里写一句“生产环境需要补充异常处理”也会让阅卷人看到你的工程意识。4.3 运维开发工程师的软技能沟通、文档和复盘很多人觉得运维开发只要能搞定技术就行但实际工作中你需要跟开发同学确认业务逻辑跟DBA商量数据库索引方案跟产品解释故障原因。笔试里偶尔会出现“你收到告警后先通知谁、再处理什么”这类题目本质上就是在考沟通顺序和优先级。我的建议是平时多做复盘记录。每次解决一个问题就用“现象、定位、原因、处理、改进”五个段落记下来。这既锻炼书面表达也能帮你在面试时讲出完整故事。笔试并不直接考写文档但这种复盘习惯会体现在你答题的条理里。5. 备考路线图如果回到2019年我会这样准备5.1 基础期两周补齐Linux、网络、数据库硬知识如果准备时间只有一个月前两周一定要把基础打牢。第一周主打Linux每天练习高频命令。不用刻意背重点放在“命令能解决什么问题”上。比如今天学top和ps就自己模拟一个CPU升高的场景再想办法找到占用高的进程。今天学awk和sed就拿一个真实日志文件反复清洗字段。第二周主攻网络和数据库。TCP握手、HTTP状态码、DNS这些必须理解到能讲清楚MySQL重点看索引和EXPLAIN把联合索引最左前缀“索引失效的常见原因”在本地数据库里验证一遍。参考书不用贪多《鸟哥的Linux私房菜》基础篇、《图解HTTP》、《高性能MySQL》里的索引章节就够用了。关键是每个知识点都要亲手做实验眼过千遍不如手过一遍。5.2 脚本期每天一个真实场景的Shell/Python练习第三周开始每天至少完成一个脚本题。不需要题目多难但要贴近真实场景。我总结过一份练习清单统计access.log中Top 10的IP找出/tmp目录下7天没被访问的文件并删除批量备份多台服务器的指定目录检查Nginx进程是否存在不存在则自动拉起并发送告警用Python调用一个API接口解析返回的JSON并输出关键字段定时清理超过1GB的日志文件写一个MySQL自动备份脚本保留最近7天按照进程名获取PID并统计内存占用解析URL中的参数并转换成字典编写一个磁盘使用率监控脚本超过阈值时告警先尝试用Shell做卡住了再换Python最后对比两种方案的优缺点。这个过程中积累的“为什么有时候用Shell更合适有时候用Python更稳”的体会是任何教程都给不了你的。5.3 项目期把课程设计包装成有数据、有结论的运维项目第四周建议集中把简历里的项目打磨一下。很多同学觉得没有运维项目可写其实课程设计完全可以改造。比如你在学校做过一个信息管理系统就可以把它部署到一台云服务器上用Nginx做反向代理后端接MySQL然后写一个脚本每分钟检查服务健康状态宕机自动重启。整个过程做完你能说清楚服务是怎么跑起来的也能说清楚监控和自愈是怎么做的这就是一个不错的运维开发项目。写项目描述时别只说“实现了什么功能”要贴上可量化的数据。比如接口响应从2秒降到300毫秒日志扫描从原来的10分钟降到30秒这些数字比形容词有说服力得多。5.4 冲刺期真题节奏与错题本考前最后两周进入刷题模式。每天一套题严格按考试时间完成。刷题的目的不是背答案而是训练自己的时间分配选择题遇到不确定的先标记不要死磕编程题至少留出30分钟。准备一个错题本但不要抄题目只记录错题背后的知识点。比如“这道题考了TIME_WAIT我原来理解错了”然后用自己的话写一遍正确解释。复习的时候只看错题本效率会非常高。5.5 关于真题来源和资料选择的一些建议刷题可以去牛客网找历年校招题也可以看一些大厂面试经验帖但不要迷信“押题”和“原题”。运维开发笔试变化并不快核心知识就那些关键是把基础吃透。还有一个建议多查官方文档和man page。很多人遇到不会的命令直接搜博客但最准确的永远是man page。看完man page再结合场景实验记忆深刻得多。6. 写在最后笔试不是终点而是一面镜子回头看2019年那场考试真正让我收获的不是“我拿到了Offer”而是它逼着我把碎片化的知识串成了体系。我后来发现能通过运维开发笔试的人往往不是刷得最多的人而是那些愿意动手实践、能把命令、脚本、网络原理连成一条线的人。如果你正在准备校招别急着收藏一堆资料先打开终端把这篇里提到的场景亲手敲一遍。做错几道题没有关系把错题后面的知识块补齐比多看十套卷子都管用。祝你在下一次笔试里遇到的不只是会做的题更是你真的理解过的系统。