1. 笔试整体情况与备考思路1.1 从笔试安排看网易的考察逻辑先说结论网易2023校招的运维工程师笔试正式第二批整体风格偏重基础扎实度和问题排查思路而不是单纯考你背了多少命令。我是在正式第二批参加考试的整个笔试大约90分钟题型覆盖单选、多选、填空、简答和两道编程题内容横跨Linux系统、网络原理、MySQL、Shell/Python脚本、监控告警和故障场景分析。和互联网大厂其他岗位的校招笔试比起来运维工程师的卷子风格很务实——没有太多脑筋急转弯更多是模拟你入职后真实会遇到的场景。比如给你一段线上日志问你怎么定位问题给你一个CPU飙升的告警问你的处理思路给你一张表问你慢查询该怎么优化。这些题目如果只是考前突击背一背很容易翻车因为它考察的是你平时积累的排障嗅觉。我自己备考时把这套卷子的考点拆成了三大块Linux与操作系统基础、网络与数据库原理、脚本与自动化能力。后面的复盘也基本按这个逻辑展开。对于目标是大厂运维岗的同学来说这三块是绕不开的基本盘无论笔试还是面试都会反复出现。1.2 题型分布与分值策略我记得很清楚整套题里选择题占了大概45%的分值简答和场景题占35%编程题占20%。这个比例其实透露了一个关键信息大厂运维笔试不只是看你知不知道更看你能不能把知道的讲清楚。选择题还能蒙一蒙简答题如果思路混乱阅卷人一眼就能看出来你的真实水平。我的做题策略是选择题控制在25分钟内解决拿不准的先标记跳过不恋战简答和场景题留足50分钟因为这类题要写清楚排查思路和命令非常耗费时间最后15分钟做两道编程题优先保证第一道的完整性和正确性。这个节奏帮我稳住了整体得分第一道编程题得了满分第二道只写了一半但前面简答题答得比较充分最终顺利进入面试环节。注意笔试里最忌讳的是在选择题上反复纠结。一道题两分钟做不出来直接凭第一感觉选一个并标记后面有时间再回来看。运维笔试的简答和场景题往往一道就顶好几道选择题的分值绝对不能在前面丢了西瓜捡芝麻。2. 基础考点复盘Linux与操作系统2.1 命令类题目不能只会背要懂原理Linux命令是运维笔试的绝对主力网易这次考了不少比较基础的命令题比如查看端口占用、查看进程、查找大文件、查看系统负载但真正的区分点在于你知不知道为什么用这个参数。比如有一道题问如何查看某个进程监听的端口表面上答案是ss -lntp或者netstat -lntp | grep 进程名但如果你能说明白ss比netstat快是因为它直接读取内核的socket哈希表而不是遍历/proc下的文件这道题的高分就属于你了。还有一道关于find的命令题要求找出/var/log下7天前修改且大于100MB的日志文件正确命令是find /var/log -type f -mtime 7 -size 100M。这里有几个容易被忽略的点-type f必须写否则会匹配到目录-mtime 7表示修改时间超过7天-mtime 7表示正好第7天这两个语义差别经常被搞混-size 100M的M必须是大写小写m代表的是512字节块。我给准备笔试的同学一个建议每个命令至少想清楚三个问题——这个命令从哪里读取数据、常用参数的含义、它和同类命令相比的优劣。以top为例说明%CPU的计算方式是单核百分比还是整体百分比说明load average的三个数分别代表什么说明在容器环境里top看到的数据和宿主机有什么差异。能把这些问题串起来命令题基本不会丢分。2.2 进程与内存一道题的完整推演这次笔试有一道让我印象深刻的关于进程状态和僵尸进程的题。题干大意是线上机器出现大量僵尸进程问怎么排查和解决。这道题我试着按实际排障的思路来写第一步用top或ps aux查看进程状态确认僵尸进程数量。ps aux里 STAT 列为 Z 的进程就是僵尸进程这个状态表示进程已经终止但父进程还没有调用wait()回收它的退出状态。第二步定位僵尸进程的父进程用ps -o ppid -p 僵尸进程PID查父进程PID或者直接看/proc/僵尸进程PID/status里的 PPid 字段。第三步分析父进程为什么没有回收子进程。这是整道题的核心也是在实际工作中最需要花时间的地方。可能是父进程本身出现了阻塞、异常也可能是父进程的代码逻辑有问题没有正确调用wait()。笔试时我给出了两个方向的处理如果父进程还能正常操作优先重启或修复它让它完成对子进程的回收如果父进程已经不可控只能选择重启父进程甚至重启机器。kill -9杀掉僵尸进程本身是没用的因为它已经死了需要处理的是它的父进程。第四步预判后续的系统影响。大量僵尸进程会占满进程表项导致新进程无法创建表现为 fork: Cannot allocate memory 错误。我当时补充了一个排查命令sysctl kernel.pid_max查看系统最大PID数量以及ps -eLf | wc -l看当前进程线程总数。这类题目最能拉开差距的地方就在第四步大多数人只写了kill僵尸进程但真正有经验的运维会知道僵尸进程是杀不掉的必须处理父进程并且在处理前先评估影响面。这种多想一层的习惯建议在备考阶段就有意识地训练。3. 网络与数据库运维的任督二脉3.1 TCP三次握手与TIME_WAIT的实战理解网络基础在运维笔试里从来都不会缺席。今年网易有道这批题目里三次握手和四次挥手属于必考内容但考察方式比较灵活不是让你默写状态变化而是给场景让你判断问题。比如有一道题问线上出现大量TIME_WAIT连接可能是什么原因怎么处理。我的答题思路是先解释TIME_WAIT的产生机制主动关闭连接的一方在收到对方的FIN后进入TIME_WAIT状态需要等待2MSL最大报文段生存时间才能彻底关闭主要是为了保证最后一个ACK能够到达对方、以及让旧连接中的迟到报文自然消亡。所以出现大量TIME_WAIT说明这台机器上主动关闭了大量连接常见于高并发的短连接场景比如Nginx代理、Redis客户端频繁建连。然后是解决方案。我在笔试中写了三个层级第一层是业务优化让客户端尽量使用连接池复用连接减少频繁建连这是最治本的方式第二层是内核参数调优比如net.ipv4.tcp_tw_reuse仅在客户端场景安全配合tcp_timestamps、net.ipv4.ip_local_port_range扩大端口范围来缓解端口耗尽第三层是在架构层面引入LVS、HAProxy这类负载均衡组件把连接管理下沉到专门的组件里。同时我强调了tcp_tw_recycle这个参数不建议开启因为它会在NAT场景下导致丢包这类我知道这个参数存在但知道它有哪些坑的表达通常能给阅卷人留下更好的印象。3.2 MySQL索引与慢查询优化数据库题是运维笔试的另一座大山。有道这批考了一道典型的慢查询优化题给出一张订单表order_info其中包含user_id、order_status、create_time等字段问针对某个高频查询语句如何建立索引并解释索引失效的场景。我在回答中首先强调了联合索引的最左前缀原则。针对高频查询SELECT * FROM order_info WHERE user_id ? AND order_status ? ORDER BY create_time DESC我会建议建立(user_id, order_status, create_time)的联合索引这样user_id用于等值匹配order_status用于等值匹配create_time用于排序可以直接覆盖索引进行排序避免filesort。如果只建立(user_id)单列索引order_status仍然可以过滤但ORDER BY create_time就可能触发文件排序性能差一个量级。接着我举了几个索引失效的反例对索引字段使用函数运算比如WHERE DATE(create_time) 2023-09-01会导致索引失效隐式类型转换也会失效比如user_id是 varchar 类型却用整数去查最左前缀原则被打破时比如跳过第一个字段直接查order_status联合索引就无法发挥作用。这道题的加分点在于我补充了一个慢查询排查的完整闭环先用SHOW FULL PROCESSLIST抓当前运行的慢SQL再开启慢查询日志slow_query_log和long_query_time用EXPLAIN分析执行计划重点关注type、key、rows三个字段。type如果是ALL或index说明走了全表或全索引扫描大概率需要优化rows预估扫描行数远超实际返回行数时往往是索引选择不当。把排查方法论写进答案比单点背命令更有说服力。4. 脚本与自动化笔试里的送分题怎么拿稳4.1 Shell脚本真题拆解这次笔试的两道编程题里有一道Shell题给定一个Nginx访问日志文件access.log每行格式为IP - - [时间] 请求方法 路径 协议 状态码 响应字节数要求统计访问次数最多的前10个IP并输出对应次数。这道题在运维笔试里属于老朋友级别但每年都有人因为细节丢分。我的标准答案是组合使用awk、sort、uniq和headawk {print $1} access.log | sort | uniq -c | sort -rn | head -10很多同学会在这道题上忽略一个关键问题uniq只能去重连续行所以必须先sort再uniq -c否则统计的数字完全是错的。另一个容易失误的点是sort -rn里的-n必须写如果不写-nsort -r会按照字典序排列结果就是 9 排在 89 前面统计排名完全乱掉。我在这道题的回答里额外写清楚了sort的内存开销问题当日志文件达到几个GB时sort会把所有内容读入内存和临时文件建议用sort -S 1G限制内存使用或者用awk的关联数组先做聚合再对聚合结果排序。例如awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10这个方案在超大日志文件下更稳因为它先聚合再排序排序的数据量只有IP数量级而不是日志行数。我在笔试时把两种方案都写了出来并解释了各自的适用场景这种不仅会写还知道在什么场景下选哪个的表达方式更容易拿高分。4.2 Python与自动化思维的考察第二道编程题是Python题题目大意是有一个进程列表每个进程包含PID、PPID和进程名给定一个PID要求找出该进程及其所有子孙进程的PID集合。这本质上是一道树的遍历题要求熟悉基本的递归或栈操作。我的解法是先用字典构建PPID - [子进程列表]的映射然后用深度优先或广度优先遍历收集所有后代def get_all_subprocesses(processes, target_pid): children {} for pid, ppid in processes: children.setdefault(ppid, []).append(pid) result [target_pid] stack [target_pid] while stack: current stack.pop() for child in children.get(current, []): result.append(child) stack.append(child) return result这道题考察的其实不只是Python语法而是自动化脚本能力。运维日常要写大量脚本来处理日志、巡检服务器、批量执行命令所以大厂笔试里Python题通常围绕列表处理、字典操作、文件读写、简单的数据结构应用这几个方向。备考时不需要刷算法竞赛题把常见场景的脚本练熟就够了。关于自动化思维笔试里的场景题也顺手考察了。比如有一道问如何给100台服务器批量执行磁盘检查命令除了写循环脚本之外我还提到了配置管理工具的思路比如使用Ansible的ansible all -m shell -a df -h或者用pssh这类批量执行工具。虽然这超出了笔试的编程题范围但表现了你对效率工具的敏感度。5. 故障排查与场景题高分与低分的分水岭5.1 CPU飙高的排查链路场景题是运维笔试最贴近真实工作、也最考验综合能力的部分。今年有道这批有一道题是某服务报警CPU使用率持续高于90%你如何排查。我在笔试中按照一个标准排障闭环来写后来复盘下来这类题的答题逻辑其实是完全可以套用的。我的思路第一步是确认现象。先用top或htop查看整体负载和CPU占用最高的进程PID确认到底是用户态CPU高还是内核态CPU高。再用top -Hp PID查看该进程内线程级别的CPU消耗找到具体是哪个线程在消耗CPU。第二步是抓取现场。使用pidstat -t -p PID 1持续观察线程CPU变化再用jstackJava应用或gdbC/C应用导出线程栈把耗CPU最高的线程ID转换为十六进制在线程栈里搜索对应的线程名。如果应用不支持这些工具可以临时用perf top或perf record -g -p PID采集热点函数。第三步是分析原因。CPU飙升通常有几类原因代码死循环或长事务、频繁GCJava应用、大量正则匹配、线程争抢锁导致自旋。我在笔试里特别强调了不能看到CPU高就立刻重启服务那只是掩盖问题。要把线程栈保存下来结合最近的发布记录判断是不是新代码引入了问题必要时保留现场、回滚版本。第四步是临时缓解与根因处理并举。临时缓解是扩容或切流把故障节点从负载均衡摘除根因处理是定位到具体代码逻辑。整个排查链路写下来阅卷人一眼就能看出你有没有真实排障经验。5.2 磁盘满了的正确处理姿势磁盘空间不足是运维最常遇到的故障之一笔试里也考到了。题面是某台服务器根分区使用率100%可能导致服务异常你如何处理。这道题我原本以为大家都会答但实际笔试复盘时发现很多人漏掉了关键步骤。最关键的一个点是先定位是什么文件占满了磁盘而不是直接删文件。我用df -h确认文件系统使用率用du -sh /* 2/dev/null | sort -rh | head -10逐层定位大目录或者用ncdu这种交互式工具快速找到大文件。但这里有个隐蔽的坑如果某个大文件已经被进程打开并删除du是看不到它的磁盘空间却仍然被占用。需要用lsof | grep deleted找出被删除但仍被进程持有的文件句柄然后重启相关进程或释放句柄空间才能真正释放。另一个需要留意的点是inode耗尽。即使df -h显示还有空间如果df -i显示inode使用率100%同样无法创建新文件因为小文件太多了。我遇到过好几次这种场景所以笔试里我也把这条写了进去。这题的作答思路体现了运维的一个核心原则先搞清楚状况再动手处理。处理动作本身不难难的是在紧急情况下保持冷静、按步骤排查。笔试里能把这一层逻辑写出来分数不会低。5.3 业务连续性场景题的答题模板有道这批的简答题里还有一类关于业务连续性的题目大致是数据库主库宕机了怎么恢复服务或服务出现大面积超时如何应对。这类场景题看似没有标准答案但如果答得有条理反而很容易拿高分。我总结了一个四步模板。第一步评估影响范围。确认是单机故障、单机房故障还是全局故障通过监控系统查看错误率、超时率、告警范围尽快判断故障边界。第二步止损优先。如果数据库主库宕机且有高可用架构优先触发主从切换如果是应用层故障考虑重启集群或回滚最近发布如果是依赖的外部服务故障评估是否启用降级方案或限流。止损的目标是先把影响面控制住而不是立刻找到根因。第三步保留现场与排查根因。在止损的同时保存日志、线程栈、监控截图方便后续定位根因。常见根因包括慢SQL打爆数据库、缓存雪崩打垮下游、配置变更引入错误、流量突增超过容量水位等。第四步复盘与治理。恢复服务之后要输出故障报告核心内容包括故障时间线、根因分析、处理过程、改进项和后续计划。笔试里写出这一步会很加分因为很多新人只关注怎么修忽略了故障之后的总结沉淀才是运维工作最重要的部分。6. 笔试现场的踩坑与备考建议6.1 我在笔试中踩过的三个坑第一别在选择题上做学术探讨。有一道Linux命令题我在两个选项之间纠结了很久后来发现题目本身是在问最常用/最便捷而不是唯一正确我在一道两分的题上浪费了七八分钟导致后面简答题时间紧张。复盘下来做选择题时应该按最佳实践去选择而不是钻牛角尖去论证某种极端场景下另一个选项也成立。第二简答题一定要写命令和关键参数不能只描述思路。比如问如何排查内存泄漏如果你只写用工具看内存占用找到增长最快的进程这种朦胧的表述很难拿分。但如果你直接把free -m、top、pidstat -r、pmap -x PID这串工具链写出来并解释如何对比内存增长曲线阅卷人立刻知道你确实动手排查过问题。第三编程题如果时间不够先写伪代码和注释也有分。我第二道Python题其实没完全写完但我把构建子进程列表的核心逻辑用注释写了出来最后代码只差最后一层遍历没写完但思路已经清晰呈现勉强拿到了部分分数。血泪教训是笔试时就算代码写不完也要把思路和关键步骤展示出来。6.2 时间分配与心态管理再展开说一下时间分配。90分钟的笔试我建议按10分钟选择题 15分钟填空题 40分钟简答/场景题 20分钟编程题 5分钟检查来分配。但这不是固定的因为每张卷子的题型分布可能会有调整。最重要的原则是简答和场景题不可压缩。编程题做不出来最多丢20分的部分分数但简答和场景题如果写得潦草丢掉的可能就是40%以上的分数。心态方面运维笔试的题目往往偏工程化没有标准答案的题目占相当比例所以在考场上遇到这题我没背过的情况不要慌。职场上的运维本来就是持续面对未知问题的岗位笔试有时候考察的就是你在不确定环境下组织思路、输出方案的能力。按发现问题 - 定位问题 - 止损 - 根因分析 - 预防的框架答题即使无法答出完美答案也能保证基本盘。6.3 从这次笔试看大厂运维的新要求最后聊聊我考完这套题之后对运维岗位的一些新认识。以前提到运维很多人第一反应是会敲Linux命令、会看监控、会重启服务但近两年大厂运维笔试明显在往开发能力 架构思维 数据敏感度的方向倾斜。这次网易的笔试里编程题占了一定比例场景题也需要你具备系统设计的感觉。比如有一道关于监控系统设计的问题问如果让你为一个高并发服务设计监控指标你会关注哪些这就不是单纯背监控工具能搞定的需要你理解QPS、RT、错误率、可用性、饱和度这些核心指标之间的关系。类似的倾向在互联网大厂运维笔试里越来越明显运维不再是后台的辅助角色而是需要懂业务、懂架构、懂自动化的专项工程师。备考运维的同学建议在扎实掌握Linux、网络、数据库的基础上把Python或Go学好了解至少一种配置管理工具理解CI/CD、容器化和监控链路。这些内容在这次笔试里直接或间接都有涉及。至少从网易这轮的题目来看懂开发的运维确实比只懂命令的运维要吃香得多。我在实际准备和参加这场笔试过程中最大的体会是运维笔试真的不是靠考前突击就能搞定的它更像一面镜子照出你平时积累的厚度。命令可以临时背但排查思路、脚本能力和对系统原理的理解需要长期实践才能沉淀下来。如果你正在准备运维校招不妨从今天开始每天花半小时读一份真实故障记录、写一个小脚本、理清一个系统原理坚持一两个月你会明显感觉到自己和一个月前的差距。