1. 笔试卷整体观察先看清网易在考谁先交代个背景我是经历过那个年代校招的人。2018年前后正好是互联网运维岗位从“会装系统会重启”往“懂开发、懂架构、懂自动化”转型的节点。网易当年那套校招运维笔试卷放在今天看依然有很强的代表性——它考的其实不是知识点的堆砌而是一个人对“稳定”这两个字有没有本能的敏感。整套试卷的题型大概分四块单选题、多选题、简答题、编程题有的场次还会加几道场景排查题。单选题倒不稀奇稀奇的是它会把一些日常命令挖得很深比如问你top命令里load average三个值分别代表什么用netstat还是ss能更快拿到连接状态ulimit -n修改的是哪个层面的限制。这些题目单独拎出来都不难但组合在一起就能筛掉一大半“只背过面试题但没真上过机器”的人。为什么网易要这么出有个很现实的原因校招进来的运维应届生前半年基本都在填坑——服务器宕机了要能快速定位日志刷爆了要能第一时间处理线上出故障了要能从监控图里看出异常。笔试不考架构设计、不考K8s原理是因为他们很清楚这些可以后面慢慢学但基础是否扎实、排查思路是否清晰、遇到问题是否手忙脚乱这三点很难在短期内速成。所以整张卷子表面在考知识点实际在考三件事基本功、工程习惯、逻辑链路。如果你准备的是这类大厂的运维笔试第一件事不是疯狂刷八股文而是先弄清它在筛选什么样的候选人。我在后面几个章节里会按模块把这套试卷涉及的考点、解题思路和备考方法完整拆开讲每一步都配上当年实际操作的复盘记录希望能给你省掉一些摸索的时间。2. 核心考点拆解Linux、网络、数据库一个都不少2.1 Linux基础不只考命令还考你对系统的理解Linux基础题在这套试卷里占的比例最大而且陷阱最多。比如有道题是问/proc目录的作用很多人会答“存放进程信息”这不能说错但只拿一半分。完整的答案是/proc是一个虚拟文件系统内核运行时把进程、内存、设备、网络等运行时信息以文件和目录的形式暴露出来cat /proc/cpuinfo能看CPU信息cat /proc/meminfo能看内存详情/proc/sys下的文件还能直接修改内核参数。这里考的是你有没有真正理解Linux“一切皆文件”这个设计哲学而不只是背过几个目录。还有一个高频考点是文件描述符和进程限制。题目会这样出线上服务报too many open files错误你会怎么排查先后顺序是什么标准做法是先用ulimit -n看当前shell的进程级限制再用cat /proc/{pid}/limits看具体进程的限制最后用lsof -p {pid} | wc -l统计进程实际打开的文件句柄数。需要注意的是ulimit -n修改的是当前shell及其子进程的限制对已经运行的进程不生效修改系统级配置要改/etc/security/limits.conf并重新登录。如果进程是systemd管理的还得在service文件里配LimitNOFILE。这道题能完整答出来的候选人通常比较少因为它层层递进考的不只是命令而是你对问题定位的完整链路。系统启动流程也是常客。BIOS → 引导程序 → 内核 → init/systemd → 运行级别/目标单元 → shell或图形界面这个流程要熟悉到能说出每一步出问题时的典型现象。比如内核解压阶段挂了会直接卡住或报Kernel Panic而/etc/fstab配错则会进入emergency模式。试卷里给一个“重启后无法进入系统卡在光标闪烁”的场景很多人第一反应是重装系统但真正的问题是挂载点写错了。做运维最忌讳一上来就想重装先判断是引导问题还是挂载问题还是服务问题这决定了你的排查效率。另外grep、awk、sed这三件套基本是必考的但考法很灵活。不是让你写复杂的正则而是给一个日志文件要求提取某个时间段内访问量最高的IP。这道题考的是组合用法用grep过滤时间段再用awk {print $1}提取IP列sort排序uniq -c去重计数最后sort -rn | head -n 10取前十个。看起来简单但真动手写的时候很多人会把uniq放到sort前面导致结果错误——uniq只能去除连续重复的行必须先排序才能正确统计。这种细节是笔试中最容易踩的坑我在实际面试候选人的时候也经常拿这道题做试金石。2.2 网络协议三握手、四次挥手是底线但不止于此网络题在这套试卷里属于“送分与送命并存”。送分的是HTTP状态码分类2xx成功、3xx重定向、4xx客户端错误、5xx服务端错误这个初中级开发者都懂。送命的是各种边缘场景比如状态码499代表什么——Nginx定义的一个非标准状态码表示客户端在服务端还没返回响应时就主动断开了连接。这道题能答上来的人不多但它考的是实际排查经验当你看到监控里突然出现大量499第一反应应该是查客户端超时设置和上游响应耗时而不是盯着Nginx的错误日志死磕。三次握手和四次挥手几乎是必考题但网易的考法比较进阶。它会问如果服务端处于SYN_RECV状态的连接特别多可能是什么原因答案方向有四个客户端发完SYN后没有收到SYN-ACK可能是服务端并发连接数满了服务端somaxconn和backlog配得太小握手队列溢出防火墙丢包SYN攻击。这里考的是你对协议状态机的理解——并不需要死记硬背参数但要能根据状态反推问题。反过来如果TIME_WAIT过多原因通常是服务端主动关闭连接比较多或者客户端没有开启keep-alive导致大量短连接。调整net.ipv4.tcp_tw_reuse和tcp_fin_timeout可以缓解但tcp_tw_recycle这个参数在NAT环境下容易出问题不建议启用。我把这些考点整理成了一个速查表方便你对照复习问题现象可能原因排查命令/工具处理建议SYN_RECV堆积握手队列满、防火墙丢包、SYN攻击netstat -s/ss -lnt/ tcpdump调大somaxconn和backlog检查防火墙规则TIME_WAIT过多短连接过多、服务端主动关闭netstat -ant开启keep-alive按需调整tcp_tw_reuse大量499客户端提前断开、上游响应慢Nginx access log / 链路追踪排查后端接口耗时和客户端超时时间丢包严重带宽打满、网卡故障、防火墙拦截sar -n DEV/ethtool -S检查带宽监控联系网络团队DNS解析流程也是那个年代笔试卷里的常客。从浏览器缓存、操作系统缓存、本地hosts、本地DNS服务器、根服务器到权威服务器的完整链路笔试会问“修改了DNS解析记录但客户端访问还是旧IP为什么”答案方向包括本地DNS缓存没刷新、浏览器有预解析缓存、HTTP keep-alive连接保持旧IP、CDN节点缓存等。这道题考的是你对整个链路的理解深度能在答案里答出“不仅要检查运营商DNS还要检查HTTP连接层和客户端层”的人基本都能过。2.3 数据库与缓存MySQL基本操作是运维的必修课数据库题在运维笔试卷里通常不会太深但MySQL的基本操作和概念是避不开的。网易的卷子考过一道题一张用户表有user_id、login_time两个字段要统计每天活跃用户数SQL怎么写这题考GROUP BY和DATE_FORMAT的组合使用SELECT DATE_FORMAT(login_time, %Y-%m-%d) AS day, COUNT(DISTINCT user_id) FROM user_logs GROUP BY day;。很多人会漏掉DISTINCT或者把COUNT(DISTINCT user_id)写成COUNT(*)导致一个用户多次登录被重复统计。这种细节就是运维和开发的差异——开发关心功能是否实现运维关心数据是否准确。还有一道经典题MySQL的四种隔离级别分别是什么分别解决什么问题读未提交、读已提交、可重复读、串行化。其中Read Uncommitted可能产生脏读Read Committed解决脏读但可能不可重复读Repeatable Read是MySQL默认级别解决不可重复读但仍可能幻读Serializable则完全串行但性能最差。这里需要额外补充一个实操知识binlog的三种格式statement、row、mixed以及主从复制延迟的常见原因——大事务执行时间长、从库单线程复制跟不上主库写入速度、表上没有主键导致全表扫描这些在笔试试卷里不会直接考但面试环节很容易被追问。缓存方面Redis的考点集中在缓存穿透、缓存击穿、缓存雪崩三个概念的区别与应对策略。穿透是指查询一个不存在的key请求直接打到数据库击穿是指某个热点key过期瞬间大量请求打到数据库雪崩是指大量key在同一时间过期或Redis宕机。解决手段分别是布隆过滤器、互斥锁或逻辑过期、过期时间加随机值或使用集群高可用。这几个概念虽然常见但试卷会把这几个场景混在一起让你判断属于哪种情况所以概念一定要区分清楚。我见过不少人把穿透和击穿搞反笔试丢分很可惜。3. 实战环节Shell脚本和场景排查题是真正的分水岭3.1 一道典型Shell脚本题日志清理的需求要怎么做才规范校招笔试卷里几乎必有一道Shell编程题。网易有一年的题目是写一个脚本定期清理Nginx日志目录下超过7天的日志文件并保留每周日的日志做备份。这个需求的坑在于“保留每周日的日志”这个条件。如果只是简单find /var/log/nginx -mtime 7 -exec rm -f {} \;会把所有超过7天的文件都删掉周日备份也就没了。正确做法是先判断文件的时间属性再结合date -d判断是否为周日或者用文件名中的日期去匹配。这里我给出一个完整可用的版本这个方案也适用于生产环境#!/bin/bash # 日志清理脚本删除7天前的日志保留每周日 LOG_DIR/var/log/nginx RETENTION_DAYS7 CURRENT_DATE$(date %Y%m%d) # 遍历所有日志文件 find $LOG_DIR -type f -name *.log | while read file; do # 获取文件的修改日期格式YYYYMMDD file_date$(date -r $file %Y%m%d) # 计算文件距今的天数 diff_days$(( ( $(date -d $CURRENT_DATE %s) - $(date -d $file_date %s) ) / 86400 )) # 超过保留天数且不是周日 weekday$(date -d $file_date %u) # 1-77表示周日 if [ $diff_days -gt $RETENTION_DAYS ] [ $weekday -ne 7 ]; then rm -f $file echo $(date %Y-%m-%d %H:%M:%S) deleted $file fi done这段脚本的核心在于先拿到每个文件的修改日期再用date %u判断是星期几只有同时满足“超过7天”和“不是周日”两个条件才删除。日期计算用了date -d转成时间戳做差可以避免跨月时用字符串比较导致的误判。脚本里加了日志输出方便追溯哪些文件被清理过这在生产环境里很重要——千万不能删完就完事出了问题你连查的依据都没有。这道题考察的真实能力不是会写脚本而是有没有足够的边界思维。比如空目录判断、文件名包含空格、find遍历遇到权限不足的目录时会不会中断这些都是加分项。如果你在笔试时能主动想到这些边界条件并写进注释里面试官会认为你有工程化意识这在应届生里是稀缺特质。3.2 场景排查题用“假设-验证-定位”的闭环拿下高分还有一类题目是纯场景题不给代码环境只给一段故障描述让你写出排查思路。网易的试卷有过这样一道题用户反馈线上服务突然变慢从监控看CPU使用率接近100%你如何排查多数人的答案是“用top查看是哪个进程占用CPU高”这不够。完整的答题思路应该是分层递进第一步查看现象确定范围top先看整体负载再看具体是哪个进程。如果是Java应用top -Hp {pid}可以精确到线程再用jstack {pid} thread_dump.txt导出线程栈搜索这个线程的十六进制ID定位到具体业务代码。第二步分析是计算密集还是锁竞争如果是计算密集可能是业务代码死循环、大量正则匹配、频繁GC如果是锁竞争线程dump里会看到大量线程处于BLOCKED状态。分别对应不同的解决路径前者要优化代码或扩容后者要排查锁粒度、热点资源。第三步检查外部依赖是否拖慢主线程数据库连接池被打满、Redis慢查询、下游接口响应慢都会表现为CPU升高因为CPU都在等I/O实际是I/O等待被计算进了负载。这时要配合pidstat -d查看进程I/O等待iostat -x看磁盘利用率ss -lnt看连接数是否异常。第四步回溯变更这个服务在故障发生前后有没有发过版本有没有改过配置有没有扩缩容线上很多问题都是变更引起的先自查变更能避免在错误的方向上浪费大量时间。这里有个关键技巧排查问题时先看变更再看资源最后看代码。很多人一上来就埋头分析代码结果发现是上游接口超时拖垮了整个调用链分析代码纯属浪费时间。做题时把你的思路按这个层次写出来即使不知道具体命令也不会丢太多分因为面试官更看重的是排查思路是否成体系。还有一个容易忽略的细节监控指标的选取。CPU使用率升高不要只盯着%cpu要看是用户态时间(%us)高还是系统态时间(%sy)高。用户态高通常是业务代码问题系统态高可能是系统调用频繁或内核bug这个判断方向完全不同。vmstat里的wa列如果很高说明I/O才是瓶颈这时给CPU加配置毫无意义。能在笔试卷里写出这层区分说明你真的在线上处理过问题而不是纯背概念。3.3 编程题的常见变形Python和Go在运维场景中的应用2018年那会儿Python在运维领域已经比较普及了试卷里偶尔会出现一道Python题。比如写一个脚本监控某端口是否存活如果挂了就重启服务并发送告警。这个需求里藏着三个考点端口检测的方法、重启服务的幂等性、告警通知的实现。我当年给出的参考解答是这样的#!/usr/bin/env python3 import socket import subprocess import time def check_port(host, port): 检测端口是否可连接 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) try: sock.connect((host, port)) return True except socket.error: return False finally: sock.close() def restart_service(): 重启服务幂等操作 subprocess.run([systemctl, restart, nginx], checkTrue) def send_alert(): 发送告警可以对接钉钉/邮件/短信 print(Service down, restarted!) if __name__ __main__: while True: if not check_port(127.0.0.1, 80): restart_service() send_alert() time.sleep(30)这段代码的核心价值不在语法多高级而在于它体现了三个做监控脚本的原则一次只做一件事、检查动作要设置超时、重启服务要幂等可重复。往深了说还有一点生产环境的脚本一定要有日志和异常捕获不能挂了就静默。我后来在团队里定过一个规矩——凡是没有日志的自动化脚本一律不允许上生产这个观念在校招笔试里提前建立起来会是一个不小的优势。4. 易错点整理这些坑每年都有大批人踩4.1 基础命令的边界条件和默认值很多看似简单的命令考的是你有没有真正用过。比如crontab的环境变量问题脚本里写的命令在终端能执行但cron跑不起来原因通常是cron环境变量里没有PATH脚本里的python、java等命令找不到。解决方案是在脚本开头显式声明环境变量或使用绝对路径。这类题在笔试里不会直接给答案而是让你排查“为什么cron执行失败”能把环境变量差异这个点答出来基本就稳了。另一个高频易错点是df和du的区别。df看的是文件系统的磁盘空间分配情况du看的是目录或文件实际占用的块大小。有时候df显示磁盘满了但du -sh /统计下来没占多少很可能是某个大文件被删除但进程还持有文件句柄空间没释放。排查方法是lsof | grep deleted找到持有已删除文件的进程重启或让进程重新打开文件空间才会释放。这个场景我在写题时经常拿来做陷阱选项能绕开的人不多。4.2 网络排查里最容易忽略的代理和防火墙层本地网络正常、服务正常但外网访问不了这类题的排查方向通常指向防火墙和代理。试卷里给过这样一个场景服务器上curl http://127.0.0.1:8080能返回正常内容但通过公网IP访问超时可能是什么原因标准答案包括云安全组/防火墙规则没放行8080端口、Nginx/SLB监听配置绑定了内网IP没绑公网IP、系统防火墙iptables或firewalld拦截、路由或NAT配置问题。这几层要一层一层剥开先查监听地址ss -lntp确认服务绑定的是0.0.0.0还是127.0.0.1再查安全组规则和系统防火墙最后用telnet或nc从外部测试端口连通性。很多人在这一步会卡住因为习惯性认为是服务本身的问题忘记了外部链路和防火墙这层。笔试卷里出现这种题的目的就是考察你有没有由内到外、由近及远的排查习惯。4.3 Shell语法陷阱空格、变量、引号Shell脚本的语法细节在笔试里特别容易被设置成陷阱。一个经典题目是三个变量赋值哪一个是正确写法# 错误 - 等号两边不能有空格 name test # 正确 nametest这类题目看着简单但每年都有不少人在上面翻车。还有if [ $var yes ]和if [ $var yes ]的区别后者多了双引号可以避免变量为空时语法报错。再比如在for循环里遍历文件名带空格的文件如果没有正确处理引号就会分词导致循环次数不对。这些细节不是死抠字眼——脚本一旦放到生产环境任何一个字符的错误都可能导致服务重启失败所以大厂笔试试卷特别爱考这些。为了方便你复习我把校招笔试里最容易混淆的知识点整理成了一张速查表易混知识点正确理解常见错误软链接/硬链接软链接是独立文件指向目标路径硬链接是指向文件inode的目录项混为一谈以为硬链接可以跨文件系统NAT/桥接模式NAT模式下宿主机和虚拟机在不同网段桥接模式下在同一网段分不清ping不通的原因iptables chainINPUT用于进入本机的包FORWARD用于本机转发的包OUTPUT用于本机发出的包不清楚为什么要区分链僵尸进程父进程未调用wait()回收的子进程残留以为僵尸进程可以被kill杀掉TCP与UDPTCP可靠有序UDP不可靠但开销小以为UDP没有连接概念就完全不可用5. 备考策略一套可持续复用的方法论5.1 分模块建立知识体系而不是零散背题运维笔试覆盖的面很广如果按官网上列出的考点一个个背效率很低还容易遗忘。我的建议是按“操作系统、网络、数据库、中间件、脚本编程、监控告警、CI/CD”这几个大模块建立自己的知识树。每个模块下只保留最核心的50个知识点然后反复自测。比如操作系统模块重点不是背命令参数而是搞清楚“进程管理、内存管理、文件系统、权限模型、日志系统”这几条主线。我当年复习时用过一个笨但有效的方法把每个模块的知识点做成一道“自问自答题”每题都用“现象 → 原因 → 排查 → 解决”的格式写满一页纸。比如“为什么磁盘空间显示满了但删除文件后空间没释放”从df看到那个文件系统到lsof | grep deleted找到持有的进程再到重启进程释放空间整个链路写一遍印象比刷十道选择题都深。这个方法后期帮我建立起了一套排错直觉让我在笔试和面试中都能快速定位问题的关键环节。5.2 动手实验是唯一的捷径笔试里有一类题很吃亏就是“看起来知道但一写就错”。比如iptables -A INPUT -p tcp --dport 80 -j ACCEPT光看这个命令不难理解但让你写一条“只允许192.168.1.0/24访问3306端口其他全部拒绝”的规则时很多人会漏掉顺序问题——iptables规则是自上而下匹配的DROP规则如果放在ACCEPT前面后面的允许规则永远不生效。这类细节只有亲手在虚拟机里搭环境才能体会到。建议至少在一台2核4G的虚拟机里搭一个最小环境安装Nginx、MySQL、Redis自己写脚本做日志切割、服务守护、报警通知再故意搞坏几个配置来观察报错现象。这个过程花不了多少时间但会让你对命令的实际行为有真实记忆而不是纸面上的想象。我在实际操作中发现凡是亲手踩过的坑笔试时遇到同类型题基本都能下意识选出正确答案这种肌肉记忆是背题无法替代的。5.3 面试环节的衔接笔试试卷之外还会问什么笔试只是第一轮筛选后续面试通常只会比笔试更深入。网易的面试环节里我见过面试官拿着笔试卷上的某道简答题继续追问比如问“你用ss还是netstat看连接数”答完会接着问“ss比netstat快在哪里”再追问“/proc/net/tcp里每个字段的含义”。这种连环题的逻辑是考察你到底理解到哪一层是否有真实上手经验。所以复习笔试题目时不要只准备到“答对”为止要养成追问的习惯。每背一个命令问自己三个问题它是什么原理它和类似工具的区别是什么生产环境什么时候用它、什么时候不用它比如curl -I和curl -X HEAD的区别、telnet和nc的适用场景、dig和nslookup的差异这些都是面试官非常喜欢拿来深挖的点。当你把这三个问题都能答上来笔试通过率会大幅提升面试时也不会被问得哑口无言。6. 从一场笔试看懂运维岗位的成长路径回顾这套试卷它真正想选拔的是具备“系统化思维”的候选人。运维这个岗位的日常就是跟不确定性打交道——不确定什么时候会宕机、不确定日志里藏着什么异常、不确定下一次变更会引入什么新问题。笔试里的所有题目本质上都在模拟这种不确定性你能否在信息不完整的情况下快速定位问题能否用工具精准验证假设能否把解决思路清晰地表达出来。有些人在准备校招笔试时会陷入一个误区觉得运维就是背命令、会装环境、能写脚本把这些做好了就万事大吉。但2018年那套试卷已经在传递一个信号运维正在从“配置管理”走向“稳定性工程”。后来的几年里SRE概念在国内互联网公司普及监控告警、容量规划、故障演练、混沌工程这些能力逐渐成为运维工程师的核心竞争力。如果你是为了长期在这个行业发展而参加笔试眼光要放远一些——笔试只是起点真正的挑战是后续你能不能在复杂的分布式系统里稳住局面。我个人在做这套试卷复盘时的体会是单纯刷题不如动手搭一套完整的服务环境再自己折腾一遍故障排查。这种方法的收益远超预期——你不仅掌握了命令的用法还理解了它们为什么被设计成这样以后遇到任何新工具都能快速上手。7. 一些小建议与拿分技巧最后说几个在真实笔试场景中很有用的技巧先把会做的题全部做完再回头啃难题。运维笔试卷的题量通常不小单选题和判断题的分数也很好拿不要在个别题目上卡太久。我见过很多人在一道网络题上纠结了十分钟导致后面的Shell脚本题没时间写得不偿失。简答题和编程题答案要写清楚注释和思路。阅卷的人通常不会一行行执行你的代码而是看你的逻辑是否完整、边界是否考虑周全。所以哪怕代码不能完整跑通也要把注释写清楚把“我接下来会怎么做”写在末尾。比如写Shell题时可以在开头加一句“这个脚本只清理按天滚动的日志文件如果日志命名格式不同需要调整正则匹配”这种句子不会扣分反而会让阅卷人觉得你想问题全面。拼写和格式要干净。命令少写一两个字母、循环少个done、Python缩进不对这类低级错误在笔试中属于冤屈分尽量别丢。我在模拟阅卷时见过不少代码逻辑完全正确但语法细节写错的答卷真的很可惜。平时用英文资料做题考试时遇到英文题目不紧张。大厂笔试试卷偶尔会出现英文题干虽然句子结构不难但如果不适应英文表达还是会影响阅读速度。建议平时看官方文档时不要只看中文翻译直接读英文原文考试时对专业术语能一眼反应过来省下更多时间集中在解题上。不要忽略“附加题”和开放性问题。网易的试卷里偶尔会有一道没有标准答案的设计题比如“如果让你设计一个监控系统你会考虑哪些指标”这种题没有对错但非常考验你日常思考的深度。答题时不要罗列堆砌而是分层次展开先基础设施层CPU、内存、磁盘、网络再中间件层连接数、慢查询、GC再业务层接口耗时、错误率、QPS每一层之间用“数据如何上报、如何存储、如何展示”串起来这样整体结构就非常完整了。这类题答好了往往能把前面丢的分补回来。以上这些经验都是我从实际复习和参与阅卷的过程里慢慢总结出来的。道理不复杂关键是动手去做——找一台虚拟机把Nginx、MySQL、Redis这些服务都搭一遍再模拟各种故障去排查这套功夫下了再回来看笔试试卷你会发现自己已经站在了另一个高度。 网易校招运维笔试全解析：Linux、网络与Shell脚本核心考点
1. 笔试卷整体观察先看清网易在考谁先交代个背景我是经历过那个年代校招的人。2018年前后正好是互联网运维岗位从“会装系统会重启”往“懂开发、懂架构、懂自动化”转型的节点。网易当年那套校招运维笔试卷放在今天看依然有很强的代表性——它考的其实不是知识点的堆砌而是一个人对“稳定”这两个字有没有本能的敏感。整套试卷的题型大概分四块单选题、多选题、简答题、编程题有的场次还会加几道场景排查题。单选题倒不稀奇稀奇的是它会把一些日常命令挖得很深比如问你top命令里load average三个值分别代表什么用netstat还是ss能更快拿到连接状态ulimit -n修改的是哪个层面的限制。这些题目单独拎出来都不难但组合在一起就能筛掉一大半“只背过面试题但没真上过机器”的人。为什么网易要这么出有个很现实的原因校招进来的运维应届生前半年基本都在填坑——服务器宕机了要能快速定位日志刷爆了要能第一时间处理线上出故障了要能从监控图里看出异常。笔试不考架构设计、不考K8s原理是因为他们很清楚这些可以后面慢慢学但基础是否扎实、排查思路是否清晰、遇到问题是否手忙脚乱这三点很难在短期内速成。所以整张卷子表面在考知识点实际在考三件事基本功、工程习惯、逻辑链路。如果你准备的是这类大厂的运维笔试第一件事不是疯狂刷八股文而是先弄清它在筛选什么样的候选人。我在后面几个章节里会按模块把这套试卷涉及的考点、解题思路和备考方法完整拆开讲每一步都配上当年实际操作的复盘记录希望能给你省掉一些摸索的时间。2. 核心考点拆解Linux、网络、数据库一个都不少2.1 Linux基础不只考命令还考你对系统的理解Linux基础题在这套试卷里占的比例最大而且陷阱最多。比如有道题是问/proc目录的作用很多人会答“存放进程信息”这不能说错但只拿一半分。完整的答案是/proc是一个虚拟文件系统内核运行时把进程、内存、设备、网络等运行时信息以文件和目录的形式暴露出来cat /proc/cpuinfo能看CPU信息cat /proc/meminfo能看内存详情/proc/sys下的文件还能直接修改内核参数。这里考的是你有没有真正理解Linux“一切皆文件”这个设计哲学而不只是背过几个目录。还有一个高频考点是文件描述符和进程限制。题目会这样出线上服务报too many open files错误你会怎么排查先后顺序是什么标准做法是先用ulimit -n看当前shell的进程级限制再用cat /proc/{pid}/limits看具体进程的限制最后用lsof -p {pid} | wc -l统计进程实际打开的文件句柄数。需要注意的是ulimit -n修改的是当前shell及其子进程的限制对已经运行的进程不生效修改系统级配置要改/etc/security/limits.conf并重新登录。如果进程是systemd管理的还得在service文件里配LimitNOFILE。这道题能完整答出来的候选人通常比较少因为它层层递进考的不只是命令而是你对问题定位的完整链路。系统启动流程也是常客。BIOS → 引导程序 → 内核 → init/systemd → 运行级别/目标单元 → shell或图形界面这个流程要熟悉到能说出每一步出问题时的典型现象。比如内核解压阶段挂了会直接卡住或报Kernel Panic而/etc/fstab配错则会进入emergency模式。试卷里给一个“重启后无法进入系统卡在光标闪烁”的场景很多人第一反应是重装系统但真正的问题是挂载点写错了。做运维最忌讳一上来就想重装先判断是引导问题还是挂载问题还是服务问题这决定了你的排查效率。另外grep、awk、sed这三件套基本是必考的但考法很灵活。不是让你写复杂的正则而是给一个日志文件要求提取某个时间段内访问量最高的IP。这道题考的是组合用法用grep过滤时间段再用awk {print $1}提取IP列sort排序uniq -c去重计数最后sort -rn | head -n 10取前十个。看起来简单但真动手写的时候很多人会把uniq放到sort前面导致结果错误——uniq只能去除连续重复的行必须先排序才能正确统计。这种细节是笔试中最容易踩的坑我在实际面试候选人的时候也经常拿这道题做试金石。2.2 网络协议三握手、四次挥手是底线但不止于此网络题在这套试卷里属于“送分与送命并存”。送分的是HTTP状态码分类2xx成功、3xx重定向、4xx客户端错误、5xx服务端错误这个初中级开发者都懂。送命的是各种边缘场景比如状态码499代表什么——Nginx定义的一个非标准状态码表示客户端在服务端还没返回响应时就主动断开了连接。这道题能答上来的人不多但它考的是实际排查经验当你看到监控里突然出现大量499第一反应应该是查客户端超时设置和上游响应耗时而不是盯着Nginx的错误日志死磕。三次握手和四次挥手几乎是必考题但网易的考法比较进阶。它会问如果服务端处于SYN_RECV状态的连接特别多可能是什么原因答案方向有四个客户端发完SYN后没有收到SYN-ACK可能是服务端并发连接数满了服务端somaxconn和backlog配得太小握手队列溢出防火墙丢包SYN攻击。这里考的是你对协议状态机的理解——并不需要死记硬背参数但要能根据状态反推问题。反过来如果TIME_WAIT过多原因通常是服务端主动关闭连接比较多或者客户端没有开启keep-alive导致大量短连接。调整net.ipv4.tcp_tw_reuse和tcp_fin_timeout可以缓解但tcp_tw_recycle这个参数在NAT环境下容易出问题不建议启用。我把这些考点整理成了一个速查表方便你对照复习问题现象可能原因排查命令/工具处理建议SYN_RECV堆积握手队列满、防火墙丢包、SYN攻击netstat -s/ss -lnt/ tcpdump调大somaxconn和backlog检查防火墙规则TIME_WAIT过多短连接过多、服务端主动关闭netstat -ant开启keep-alive按需调整tcp_tw_reuse大量499客户端提前断开、上游响应慢Nginx access log / 链路追踪排查后端接口耗时和客户端超时时间丢包严重带宽打满、网卡故障、防火墙拦截sar -n DEV/ethtool -S检查带宽监控联系网络团队DNS解析流程也是那个年代笔试卷里的常客。从浏览器缓存、操作系统缓存、本地hosts、本地DNS服务器、根服务器到权威服务器的完整链路笔试会问“修改了DNS解析记录但客户端访问还是旧IP为什么”答案方向包括本地DNS缓存没刷新、浏览器有预解析缓存、HTTP keep-alive连接保持旧IP、CDN节点缓存等。这道题考的是你对整个链路的理解深度能在答案里答出“不仅要检查运营商DNS还要检查HTTP连接层和客户端层”的人基本都能过。2.3 数据库与缓存MySQL基本操作是运维的必修课数据库题在运维笔试卷里通常不会太深但MySQL的基本操作和概念是避不开的。网易的卷子考过一道题一张用户表有user_id、login_time两个字段要统计每天活跃用户数SQL怎么写这题考GROUP BY和DATE_FORMAT的组合使用SELECT DATE_FORMAT(login_time, %Y-%m-%d) AS day, COUNT(DISTINCT user_id) FROM user_logs GROUP BY day;。很多人会漏掉DISTINCT或者把COUNT(DISTINCT user_id)写成COUNT(*)导致一个用户多次登录被重复统计。这种细节就是运维和开发的差异——开发关心功能是否实现运维关心数据是否准确。还有一道经典题MySQL的四种隔离级别分别是什么分别解决什么问题读未提交、读已提交、可重复读、串行化。其中Read Uncommitted可能产生脏读Read Committed解决脏读但可能不可重复读Repeatable Read是MySQL默认级别解决不可重复读但仍可能幻读Serializable则完全串行但性能最差。这里需要额外补充一个实操知识binlog的三种格式statement、row、mixed以及主从复制延迟的常见原因——大事务执行时间长、从库单线程复制跟不上主库写入速度、表上没有主键导致全表扫描这些在笔试试卷里不会直接考但面试环节很容易被追问。缓存方面Redis的考点集中在缓存穿透、缓存击穿、缓存雪崩三个概念的区别与应对策略。穿透是指查询一个不存在的key请求直接打到数据库击穿是指某个热点key过期瞬间大量请求打到数据库雪崩是指大量key在同一时间过期或Redis宕机。解决手段分别是布隆过滤器、互斥锁或逻辑过期、过期时间加随机值或使用集群高可用。这几个概念虽然常见但试卷会把这几个场景混在一起让你判断属于哪种情况所以概念一定要区分清楚。我见过不少人把穿透和击穿搞反笔试丢分很可惜。3. 实战环节Shell脚本和场景排查题是真正的分水岭3.1 一道典型Shell脚本题日志清理的需求要怎么做才规范校招笔试卷里几乎必有一道Shell编程题。网易有一年的题目是写一个脚本定期清理Nginx日志目录下超过7天的日志文件并保留每周日的日志做备份。这个需求的坑在于“保留每周日的日志”这个条件。如果只是简单find /var/log/nginx -mtime 7 -exec rm -f {} \;会把所有超过7天的文件都删掉周日备份也就没了。正确做法是先判断文件的时间属性再结合date -d判断是否为周日或者用文件名中的日期去匹配。这里我给出一个完整可用的版本这个方案也适用于生产环境#!/bin/bash # 日志清理脚本删除7天前的日志保留每周日 LOG_DIR/var/log/nginx RETENTION_DAYS7 CURRENT_DATE$(date %Y%m%d) # 遍历所有日志文件 find $LOG_DIR -type f -name *.log | while read file; do # 获取文件的修改日期格式YYYYMMDD file_date$(date -r $file %Y%m%d) # 计算文件距今的天数 diff_days$(( ( $(date -d $CURRENT_DATE %s) - $(date -d $file_date %s) ) / 86400 )) # 超过保留天数且不是周日 weekday$(date -d $file_date %u) # 1-77表示周日 if [ $diff_days -gt $RETENTION_DAYS ] [ $weekday -ne 7 ]; then rm -f $file echo $(date %Y-%m-%d %H:%M:%S) deleted $file fi done这段脚本的核心在于先拿到每个文件的修改日期再用date %u判断是星期几只有同时满足“超过7天”和“不是周日”两个条件才删除。日期计算用了date -d转成时间戳做差可以避免跨月时用字符串比较导致的误判。脚本里加了日志输出方便追溯哪些文件被清理过这在生产环境里很重要——千万不能删完就完事出了问题你连查的依据都没有。这道题考察的真实能力不是会写脚本而是有没有足够的边界思维。比如空目录判断、文件名包含空格、find遍历遇到权限不足的目录时会不会中断这些都是加分项。如果你在笔试时能主动想到这些边界条件并写进注释里面试官会认为你有工程化意识这在应届生里是稀缺特质。3.2 场景排查题用“假设-验证-定位”的闭环拿下高分还有一类题目是纯场景题不给代码环境只给一段故障描述让你写出排查思路。网易的试卷有过这样一道题用户反馈线上服务突然变慢从监控看CPU使用率接近100%你如何排查多数人的答案是“用top查看是哪个进程占用CPU高”这不够。完整的答题思路应该是分层递进第一步查看现象确定范围top先看整体负载再看具体是哪个进程。如果是Java应用top -Hp {pid}可以精确到线程再用jstack {pid} thread_dump.txt导出线程栈搜索这个线程的十六进制ID定位到具体业务代码。第二步分析是计算密集还是锁竞争如果是计算密集可能是业务代码死循环、大量正则匹配、频繁GC如果是锁竞争线程dump里会看到大量线程处于BLOCKED状态。分别对应不同的解决路径前者要优化代码或扩容后者要排查锁粒度、热点资源。第三步检查外部依赖是否拖慢主线程数据库连接池被打满、Redis慢查询、下游接口响应慢都会表现为CPU升高因为CPU都在等I/O实际是I/O等待被计算进了负载。这时要配合pidstat -d查看进程I/O等待iostat -x看磁盘利用率ss -lnt看连接数是否异常。第四步回溯变更这个服务在故障发生前后有没有发过版本有没有改过配置有没有扩缩容线上很多问题都是变更引起的先自查变更能避免在错误的方向上浪费大量时间。这里有个关键技巧排查问题时先看变更再看资源最后看代码。很多人一上来就埋头分析代码结果发现是上游接口超时拖垮了整个调用链分析代码纯属浪费时间。做题时把你的思路按这个层次写出来即使不知道具体命令也不会丢太多分因为面试官更看重的是排查思路是否成体系。还有一个容易忽略的细节监控指标的选取。CPU使用率升高不要只盯着%cpu要看是用户态时间(%us)高还是系统态时间(%sy)高。用户态高通常是业务代码问题系统态高可能是系统调用频繁或内核bug这个判断方向完全不同。vmstat里的wa列如果很高说明I/O才是瓶颈这时给CPU加配置毫无意义。能在笔试卷里写出这层区分说明你真的在线上处理过问题而不是纯背概念。3.3 编程题的常见变形Python和Go在运维场景中的应用2018年那会儿Python在运维领域已经比较普及了试卷里偶尔会出现一道Python题。比如写一个脚本监控某端口是否存活如果挂了就重启服务并发送告警。这个需求里藏着三个考点端口检测的方法、重启服务的幂等性、告警通知的实现。我当年给出的参考解答是这样的#!/usr/bin/env python3 import socket import subprocess import time def check_port(host, port): 检测端口是否可连接 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) try: sock.connect((host, port)) return True except socket.error: return False finally: sock.close() def restart_service(): 重启服务幂等操作 subprocess.run([systemctl, restart, nginx], checkTrue) def send_alert(): 发送告警可以对接钉钉/邮件/短信 print(Service down, restarted!) if __name__ __main__: while True: if not check_port(127.0.0.1, 80): restart_service() send_alert() time.sleep(30)这段代码的核心价值不在语法多高级而在于它体现了三个做监控脚本的原则一次只做一件事、检查动作要设置超时、重启服务要幂等可重复。往深了说还有一点生产环境的脚本一定要有日志和异常捕获不能挂了就静默。我后来在团队里定过一个规矩——凡是没有日志的自动化脚本一律不允许上生产这个观念在校招笔试里提前建立起来会是一个不小的优势。4. 易错点整理这些坑每年都有大批人踩4.1 基础命令的边界条件和默认值很多看似简单的命令考的是你有没有真正用过。比如crontab的环境变量问题脚本里写的命令在终端能执行但cron跑不起来原因通常是cron环境变量里没有PATH脚本里的python、java等命令找不到。解决方案是在脚本开头显式声明环境变量或使用绝对路径。这类题在笔试里不会直接给答案而是让你排查“为什么cron执行失败”能把环境变量差异这个点答出来基本就稳了。另一个高频易错点是df和du的区别。df看的是文件系统的磁盘空间分配情况du看的是目录或文件实际占用的块大小。有时候df显示磁盘满了但du -sh /统计下来没占多少很可能是某个大文件被删除但进程还持有文件句柄空间没释放。排查方法是lsof | grep deleted找到持有已删除文件的进程重启或让进程重新打开文件空间才会释放。这个场景我在写题时经常拿来做陷阱选项能绕开的人不多。4.2 网络排查里最容易忽略的代理和防火墙层本地网络正常、服务正常但外网访问不了这类题的排查方向通常指向防火墙和代理。试卷里给过这样一个场景服务器上curl http://127.0.0.1:8080能返回正常内容但通过公网IP访问超时可能是什么原因标准答案包括云安全组/防火墙规则没放行8080端口、Nginx/SLB监听配置绑定了内网IP没绑公网IP、系统防火墙iptables或firewalld拦截、路由或NAT配置问题。这几层要一层一层剥开先查监听地址ss -lntp确认服务绑定的是0.0.0.0还是127.0.0.1再查安全组规则和系统防火墙最后用telnet或nc从外部测试端口连通性。很多人在这一步会卡住因为习惯性认为是服务本身的问题忘记了外部链路和防火墙这层。笔试卷里出现这种题的目的就是考察你有没有由内到外、由近及远的排查习惯。4.3 Shell语法陷阱空格、变量、引号Shell脚本的语法细节在笔试里特别容易被设置成陷阱。一个经典题目是三个变量赋值哪一个是正确写法# 错误 - 等号两边不能有空格 name test # 正确 nametest这类题目看着简单但每年都有不少人在上面翻车。还有if [ $var yes ]和if [ $var yes ]的区别后者多了双引号可以避免变量为空时语法报错。再比如在for循环里遍历文件名带空格的文件如果没有正确处理引号就会分词导致循环次数不对。这些细节不是死抠字眼——脚本一旦放到生产环境任何一个字符的错误都可能导致服务重启失败所以大厂笔试试卷特别爱考这些。为了方便你复习我把校招笔试里最容易混淆的知识点整理成了一张速查表易混知识点正确理解常见错误软链接/硬链接软链接是独立文件指向目标路径硬链接是指向文件inode的目录项混为一谈以为硬链接可以跨文件系统NAT/桥接模式NAT模式下宿主机和虚拟机在不同网段桥接模式下在同一网段分不清ping不通的原因iptables chainINPUT用于进入本机的包FORWARD用于本机转发的包OUTPUT用于本机发出的包不清楚为什么要区分链僵尸进程父进程未调用wait()回收的子进程残留以为僵尸进程可以被kill杀掉TCP与UDPTCP可靠有序UDP不可靠但开销小以为UDP没有连接概念就完全不可用5. 备考策略一套可持续复用的方法论5.1 分模块建立知识体系而不是零散背题运维笔试覆盖的面很广如果按官网上列出的考点一个个背效率很低还容易遗忘。我的建议是按“操作系统、网络、数据库、中间件、脚本编程、监控告警、CI/CD”这几个大模块建立自己的知识树。每个模块下只保留最核心的50个知识点然后反复自测。比如操作系统模块重点不是背命令参数而是搞清楚“进程管理、内存管理、文件系统、权限模型、日志系统”这几条主线。我当年复习时用过一个笨但有效的方法把每个模块的知识点做成一道“自问自答题”每题都用“现象 → 原因 → 排查 → 解决”的格式写满一页纸。比如“为什么磁盘空间显示满了但删除文件后空间没释放”从df看到那个文件系统到lsof | grep deleted找到持有的进程再到重启进程释放空间整个链路写一遍印象比刷十道选择题都深。这个方法后期帮我建立起了一套排错直觉让我在笔试和面试中都能快速定位问题的关键环节。5.2 动手实验是唯一的捷径笔试里有一类题很吃亏就是“看起来知道但一写就错”。比如iptables -A INPUT -p tcp --dport 80 -j ACCEPT光看这个命令不难理解但让你写一条“只允许192.168.1.0/24访问3306端口其他全部拒绝”的规则时很多人会漏掉顺序问题——iptables规则是自上而下匹配的DROP规则如果放在ACCEPT前面后面的允许规则永远不生效。这类细节只有亲手在虚拟机里搭环境才能体会到。建议至少在一台2核4G的虚拟机里搭一个最小环境安装Nginx、MySQL、Redis自己写脚本做日志切割、服务守护、报警通知再故意搞坏几个配置来观察报错现象。这个过程花不了多少时间但会让你对命令的实际行为有真实记忆而不是纸面上的想象。我在实际操作中发现凡是亲手踩过的坑笔试时遇到同类型题基本都能下意识选出正确答案这种肌肉记忆是背题无法替代的。5.3 面试环节的衔接笔试试卷之外还会问什么笔试只是第一轮筛选后续面试通常只会比笔试更深入。网易的面试环节里我见过面试官拿着笔试卷上的某道简答题继续追问比如问“你用ss还是netstat看连接数”答完会接着问“ss比netstat快在哪里”再追问“/proc/net/tcp里每个字段的含义”。这种连环题的逻辑是考察你到底理解到哪一层是否有真实上手经验。所以复习笔试题目时不要只准备到“答对”为止要养成追问的习惯。每背一个命令问自己三个问题它是什么原理它和类似工具的区别是什么生产环境什么时候用它、什么时候不用它比如curl -I和curl -X HEAD的区别、telnet和nc的适用场景、dig和nslookup的差异这些都是面试官非常喜欢拿来深挖的点。当你把这三个问题都能答上来笔试通过率会大幅提升面试时也不会被问得哑口无言。6. 从一场笔试看懂运维岗位的成长路径回顾这套试卷它真正想选拔的是具备“系统化思维”的候选人。运维这个岗位的日常就是跟不确定性打交道——不确定什么时候会宕机、不确定日志里藏着什么异常、不确定下一次变更会引入什么新问题。笔试里的所有题目本质上都在模拟这种不确定性你能否在信息不完整的情况下快速定位问题能否用工具精准验证假设能否把解决思路清晰地表达出来。有些人在准备校招笔试时会陷入一个误区觉得运维就是背命令、会装环境、能写脚本把这些做好了就万事大吉。但2018年那套试卷已经在传递一个信号运维正在从“配置管理”走向“稳定性工程”。后来的几年里SRE概念在国内互联网公司普及监控告警、容量规划、故障演练、混沌工程这些能力逐渐成为运维工程师的核心竞争力。如果你是为了长期在这个行业发展而参加笔试眼光要放远一些——笔试只是起点真正的挑战是后续你能不能在复杂的分布式系统里稳住局面。我个人在做这套试卷复盘时的体会是单纯刷题不如动手搭一套完整的服务环境再自己折腾一遍故障排查。这种方法的收益远超预期——你不仅掌握了命令的用法还理解了它们为什么被设计成这样以后遇到任何新工具都能快速上手。7. 一些小建议与拿分技巧最后说几个在真实笔试场景中很有用的技巧先把会做的题全部做完再回头啃难题。运维笔试卷的题量通常不小单选题和判断题的分数也很好拿不要在个别题目上卡太久。我见过很多人在一道网络题上纠结了十分钟导致后面的Shell脚本题没时间写得不偿失。简答题和编程题答案要写清楚注释和思路。阅卷的人通常不会一行行执行你的代码而是看你的逻辑是否完整、边界是否考虑周全。所以哪怕代码不能完整跑通也要把注释写清楚把“我接下来会怎么做”写在末尾。比如写Shell题时可以在开头加一句“这个脚本只清理按天滚动的日志文件如果日志命名格式不同需要调整正则匹配”这种句子不会扣分反而会让阅卷人觉得你想问题全面。拼写和格式要干净。命令少写一两个字母、循环少个done、Python缩进不对这类低级错误在笔试中属于冤屈分尽量别丢。我在模拟阅卷时见过不少代码逻辑完全正确但语法细节写错的答卷真的很可惜。平时用英文资料做题考试时遇到英文题目不紧张。大厂笔试试卷偶尔会出现英文题干虽然句子结构不难但如果不适应英文表达还是会影响阅读速度。建议平时看官方文档时不要只看中文翻译直接读英文原文考试时对专业术语能一眼反应过来省下更多时间集中在解题上。不要忽略“附加题”和开放性问题。网易的试卷里偶尔会有一道没有标准答案的设计题比如“如果让你设计一个监控系统你会考虑哪些指标”这种题没有对错但非常考验你日常思考的深度。答题时不要罗列堆砌而是分层次展开先基础设施层CPU、内存、磁盘、网络再中间件层连接数、慢查询、GC再业务层接口耗时、错误率、QPS每一层之间用“数据如何上报、如何存储、如何展示”串起来这样整体结构就非常完整了。这类题答好了往往能把前面丢的分补回来。以上这些经验都是我从实际复习和参与阅卷的过程里慢慢总结出来的。道理不复杂关键是动手去做——找一台虚拟机把Nginx、MySQL、Redis这些服务都搭一遍再模拟各种故障去排查这套功夫下了再回来看笔试试卷你会发现自己已经站在了另一个高度。