网易运维笔试真题拆解：从Linux到场景题的排障思维

每年秋招季总有一批准备投运维岗的同学跑来问我网易的运维笔试到底考什么这个问题我在2018年也问过自己。那份网易2018校园招聘运维工程师有道笔试卷我至今还留着电子版偶尔翻出来看依然觉得它是一份很有代表性的考卷——它考的不光是知识点更多是你在真实运维场景里有没有解决问题的直觉。这篇文章不是让你背答案的。我会把这份试卷背后的出题逻辑拆开从Linux基础、网络排查、数据库中间件、脚本自动化到场景设计题逐层讲清楚每一类题为什么这么出、你怎么答才能踩到分。无论你是准备校招的应届生还是想转行运维的社招候选人这篇文章都能帮你少走弯路。哪怕你不考网易这套拆解方法同样适用于其他大厂的运维笔试。1. 网易有道运维笔试的命题风格与岗位画像1.1 为什么笔试前要先搞清楚有道在做什么网易有道是网易旗下的教育科技公司做词典、翻译、在线教育等产品。运维工程师在这里要扛的是教育业务的稳定性——几百万人同时查词、看课、提交作业服务不能挂数据不能丢。所以笔试的题目设置会明显偏向Web服务运维、数据库和缓存的高可用、以及自动化效率提升而不是纯粹考硬件或网络底层。这和网易其他部门比如游戏运维有区别。游戏的运维笔试会偏向服务器集群、容灾、DDoS防护有道的产品以API服务为主所以更关注服务链路的稳定性和响应速度。你拿到试卷后第一件事不是急着做题而是先想这个岗位的日常痛点是什么题目八九不离十都在围着这些痛点转。1.2 试卷的典型模块与分值分布根据这份笔试卷的回忆整理整体结构大致分五个模块模块考察方向题量占比难度Linux基础与命令文件管理、权限、进程、系统状态20%低网络与系统服务TCP/IP、DNS、HTTP、Nginx25%中数据库与缓存MySQL、Redis20%中Shell/Python脚本日志分析、文本处理、自动化20%中高场景设计题架构、监控、故障排查思路15%高这个比例说明一个很重要的信号这道题不追求把你考倒而是要看你在各个基础层面是否均衡。均衡比偏科重要。很多人Linux命令背得滚瓜烂熟但一问Nginx负载均衡算法就卡壳这种人在笔试里很容易被筛掉因为运维本身就是个知识面要求很杂的岗位。1.3 笔试的核心考察逻辑排障思维大于死记硬背我见过太多人准备笔试是抱着命令手册背结果一上考场就懵。因为网易的考题不直接问ls有哪些参数而是给你一个具体场景服务器负载突然飙高你怎么排查这时候你要写出的是排查路径——先看load average再用top看CPU和内存再用iostat看磁盘IO然后结合dmesg看有没有OOM最后定位到具体进程。这种答题方式考察的不是知识点本身而是知识点的串联能力。你在平时练习时就要有意识地把零散命令组合成一套排查流程形成肌肉记忆。笔试和面试不同面试官不在你对面你只能靠文字把思路完整表达出来所以答题的结构化程度直接决定你的分数。2. Linux基础与常用命令送分题背后的隐藏要求2.1 高频考点不只是会敲要懂为什么Linux基础题是整份试卷里最友好的部分但也是最容易丢分的部分因为很多人只背命令不背原理。比如试卷里出现过一道题如何查看某个端口是否被占用大部分人能写出netstat -tlnp | grep 8080或lsof -i:8080但你要能解释清楚-t、-l、-n、-p各自是什么意思并且补充一句生产环境推荐用ss替代netstat因为ss在连接数多的时候性能更好。这一句话就能拉开差距。再比如进程管理。题目问如何找到CPU占用最高的进程很多人直接写top。但更好的回答是先写top -o %CPU按CPU排序再用ps -eo pid,ppid,%cpu,%mem,comm --sort-%cpu | head精确输出关键字段外加一句如果进程瞬时飙高又降下来要用top -d 1多采样几次避免误判。这种细节才是考官想看到的。2.2 文件系统与权限经典坑位回顾有道笔试卷在文件系统这块考察的是实际排障能力。题目大概是这样磁盘空间满了df -h显示/分区使用率100%但你du -sh /*加起来的实际占用远小于分区总大小这个现象说明什么怎么解决这道题的正确答案是有文件被进程删除但仍然占着空间lsof | grep deleted找到对应进程重启进程或让进程释放文件句柄。这个知识点在真实运维中几乎每周都会碰到尤其是日志文件被rm但服务进程没重启的情况。笔试考这个说明出题人很清楚一线运维的日常工作。权限题也要注意。除了基础的chmod 755、chown user:group file之外有道卷子还考过SUID和SGID。题目问/usr/bin/passwd为什么普通用户也能执行答案就是文件上有SUID位执行时以文件属主root身份运行。你要能写出来怎么设置chmod us /path/to/file并说明SUID的危险性——如果在一个普通用户可写的文件上设置SUID等于给该用户提权这是安全审计的重点检查项。2.3 系统状态查看别只记top要能讲清指标含义系统负载类题目几乎必考。load average三个数字分别代表什么很多人能背出1分钟、5分钟、15分钟的平均负载但题目如果深入问load average 等于 CPU 核数代表什么就有人卡住了。正确的理解是load average 是运行队列中平均活跃进程数包含正在运行的进程和等待CPU的进程不等于CPU使用率。当 load 长期大于 CPU 核数说明系统过载有进程在排队等待。还有个常考点是内存。free -h输出中available和free的区别是什么简单说free是真正没被用的物理内存available是估计的可用于新进程的内存包含可回收的缓存。真实场景里Linux 会把空闲内存用作 page cache 来加速文件读写所以free很小不代表内存不足要看available。这个细节在笔试中写出来会让人觉得你真的管过服务器而不是只刷过面试题。3. 网络与系统服务从TCP握手到Nginx配置3.1 TCP/IP 基础题三次握手和四次挥手的进阶答法有道笔试卷里网络部分的第一道题通常是TCP三次握手但问法有套路。它不会直接问三次握手的过程是什么而是问为什么是三次不是两次——这就要你答出ISN同步和防止历史重复连接初始化。如果你能进一步解释 SYN Flood 的原理攻击者发送大量SYN但不完成握手服务端半连接队列被打满以及 Linux 下的应对参数net.ipv4.tcp_max_syn_backlog、tcp_syncookies这道题的层次就完全不一样了。四次挥手也有进阶考点。TIME_WAIT 状态是运维笔试题的最爱为什么主动关闭方要停留在 TIME_WAIT 状态 2MSL答案有两个要点一是保证最后一个 ACK 能让对方收到如果丢了对端会重发 FIN二是让旧连接的报文在网络中自然消失防止影响新连接。再往下就要说生产环境大量 TIME_WAIT 的优化手段——调整net.ipv4.tcp_tw_reuse注意tcp_tw_recycle在NAT环境下有坑别乱开、减小tcp_fin_timeout或者让应用主动做连接复用。能写到这层说明你真的调过线上问题。3.2 DNS 和 HTTP 状态码看似简单处处有坑DNS 的考点集中在解析流程。题目会给你一个域名让你描述从浏览器输入 URL 到拿到 IP 的完整过程浏览器缓存、系统 hosts 文件、本地DNS解析器、根域名服务器、顶级域服务器、权威服务器。这里面最容易漏掉的是缓存环节以及不同 TTL 对缓存的影响。HTTP 状态码也是高频考点但有道卷子考得比较细。不光是 200、404、500它还会问502 Bad Gateway 和 504 Gateway Timeout 分别是什么问题502 是网关或代理服务器从上游收到了无效响应504 是上游没有在规定时间内返回响应。然后延伸到排查方向502 要查后端服务是否存活、端口是否监听、防火墙是否拦截504 要查后端服务的处理时间、代理超时配置比如 Nginx 的proxy_read_timeout。这种题答好了后面场景题的压力就小很多。3.3 Nginx 配置题反向代理与负载均衡的核心逻辑Nginx 在有道笔试里出现频率很高因为它是有道这类 Web 服务最常见的接入层。最典型的题目是写一个反向代理配置将/api/路径的请求转发到后端服务器并配置负载均衡和健康检查。一个能拿高分的配置示例大概是upstream backend { server 10.0.1.10:8080 weight3 max_fails2 fail_timeout10s; server 10.0.1.11:8080 weight1 max_fails2 fail_timeout10s; keepalive 32; } server { listen 80; server_name api.example.com; location /api/ { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 10s; } }这里面的关键得分点包括weight权重差异、max_fails和fail_timeout的健康检查机制、keepalive对后端连接复用的优化。如果你还能补充一句location 块里若不加/proxy_pass是否带 URI 会导致转发路径不同那就是资深玩家的水准了。4. 数据库与缓存MySQL 和 Redis 的必背内容4.1 MySQL 索引与慢查询笔试最常见的两类问题运维笔试里的 MySQL 题目十有八九围绕索引和慢查询展开。有道卷子有一道题某查询语句很慢你如何排查并优化一个标准的排查链路是先EXPLAIN看执行计划确认是否走索引、type 是什么级别、扫描行数有多少再看索引是否失效——比如对索引列做了函数操作、隐式类型转换、前置模糊匹配%xxx这些都会导致索引失效最后看数据量是否需要分表或增加缓存。索引本身也常考。题目会问unique key和普通索引的区别、联合索引的最左前缀原则。后者是经典中的经典举例来说(a, b, c)联合索引能匹配where a ?、where a ? and b ?但匹配不了where b ?。在笔试卷上这种题必须用实际例子写清楚别只写原则写例子才能证明你真的理解。4.2 Redis 持久化与淘汰策略答出适用场景才加分Redis 的相关题目集中在两个方面持久化方式和内存淘汰策略。持久化方面RDB 和 AOF 的对比是送分题但要答出适用场景RDB 是定期快照恢复快但可能丢数据AOF 是追加日志数据更安全但文件大、恢复慢。进阶答案是生产环境通常 RDB AOF 同时开启AOF 配置appendfsync everysec在性能和安全性之间取平衡。如果你能对比 Redis 4.0 之后的混合持久化AOF 重写时生成 RDB 格式的 base 文件增量用 AOF就更有区分度了。内存淘汰策略的考点是maxmemory-policy的八种策略。至少要知道最常用的allkeys-lru淘汰最久未使用的键volatile-lru只淘汰设置了过期时间的键noeviction不淘汰直接报错。面试官真正想看你有没有在生产环境配过——比如缓存热点数据用allkeys-lru会话数据用noeviction宁可报错也不能丢。4.3 数据库类题的答题套路从背概念转向说场景数据库题最大的误区是把概念背一遍就完事。我在试卷上看到的高分答案普遍是概念 场景 操作三段式。举个例子问为什么要分库分表你要先说概念单库单表数据量大导致写入和查询性能下降再说场景订单表到千万级、写入TPS持续增长最后说操作方案水平分表按订单ID取模垂直分库按业务域拆分同时引入中间件如 ShardingSphere 或 MyCat。这种结构化的答题方式比写一大段没层次的话更容易让阅卷人找到得分点。笔试是文字沟通阅卷人每天要看几十份卷子你的答案一定要结构清晰、要点前置、关键结论加粗或分条别让他从一堆文字里帮你找答案。5. 脚本与自动化Shell/Python 笔试实战拆解5.1 一道日志分析的 Shell 题完整思路有道笔试卷的脚本题非常接地气基本是给你一个日志文件让你统计某个维度。我印象最深的一道题给定一个 Nginx access log统计每个 IP 的访问次数并按从高到低排序输出。一个标准答案awk {print $1} access.log | sort | uniq -c | sort -rn | head -20这行命令看似简单但如果只写这一句分数只能拿一半。因为题目实际问的是统计 Top 20 访问来源 IP你需要补上几个关键点$1是 access log 里默认的客户端 IP 字段uniq -c做次数统计前必须先sort否则相同的 IP 不连续时统计会出错sort -rn是按数字逆序排序。如果你能再加一句如果要统计 Top 20 的同时把 UA 信息也带上可以用awk同时取 IP 和 UA 字段存到数组里再排序说明你真的处理过日志。5.2 Python 脚本的笔试高频考法文本处理和定时任务脚本题的第二道往往是 Python考察点集中在文本处理和系统交互。一道典型题目读取一个 2GB 的日志文件找出所有包含 ERROR 的行统计每个错误码出现的次数输出到新文件。一个高效写法是from collections import Counter counter Counter() with open(app.log, r) as f: for line in f: if ERROR in line: # 假设错误码格式为 [ERROR-1234] try: code line.split([)[1].split(])[0] counter[code] 1 except IndexError: pass with open(error_summary.txt, w) as f: for code, cnt in counter.most_common(): f.write(f{code} {cnt}\n)这道题的考点不在语法而是以下几个方面with open可以安全处理文件句柄逐行读取for line in f避免一次性将 2GB 文件读入内存用Counter做统计比手动字典更简洁。如果你只写一个readlines()再循环虽然逻辑对但在大文件场景下就是明显缺陷阅卷人会看出来你没处理过真实大数据量日志。5.3 背命令不如背模式脚本题的通用解法框架我整理脚本题时发现一个规律无论题目怎么变核心解法就那么几类。日志处理类基本是取字段 聚合统计 排序输出这个模式下 awk 和 Python 的 pandas 是两把利器系统巡检类基本是执行命令 解析输出 阈值判断 告警通知这个模式下 subprocess 和 psutil 是常用的库批量操作类基本是遍历目标 并发执行 结果收集 错误重试并行操作可以上xargs -P或者 Python 的ThreadPoolExecutor。所以备考时不建议一道题一道题地背而是把题目归到几个模式下每个模式练熟一两个通用脚本考场上的题基本就是在这些模式上套壳。这个思路不仅对笔试有用对实际工作也有很大价值运维的日常就是不断把重复的排查动作脚本化。6. 场景设计题如何用运维思维答开放题6.1 从单机到集群容量规划与故障预案怎么写场景题是整份笔试卷里最拉开差距的部分。有道卷子的场景题大致是一个业务模块从单机部署要扩展到集群你会怎么设计部署架构和高可用方案这种题没有唯一答案考官看的是你的思考维度是否全面。一个能拿分的回答框架是分四层展开。接入层Nginx 做同时负载均衡配置健康检查后端服务挂掉后自动摘除节点。应用层服务至少部署两个节点通过 systemd 或者 Supervisor 守护进程配置自动重启策略。数据层数据库做主从复制主库故障时手动或半自动切换到从库Redis 做主从或哨兵模式保证缓存高可用。监控层节点存活、CPU/内存/磁盘、接口时延和错误率全部接入监控设定阈值后触发告警。6.2 故障排查题的答题框架按链路一步步拆另一类常见开放题是给你一个故障现象让你写排查思路。比如线上服务突然大量 502你怎么处理很多人的答案要么特别空泛先看日志要么特别混乱。一个可靠的答题框架是先缩小范围再定位原因。第一步通过监控大屏确认故障范围——是所有节点都挂了还是某个节点异常是某条链路超时还是整体不可用第二步按请求链路逐层排查客户端→DNS→接入层→应用层→数据层。接入层查 Nginx 的 error.log 和 access.log 的 status 分布应用层查应用日志的异常堆栈和其依赖的中间件连接池状态数据层查数据库/Redis 的 QPS 和慢查询确认是否有连接数被打满。第三步给出止血措施最坏情况下先把故障节点摘除、回滚最近上线的变更保障核心链路恢复再慢慢定位根因。6.3 开放题的踩分点少写我认为多写我会这样做场景题最忌讳的写法是我觉得应该做好监控我认为要关注稳定性这类正确但没用的话。阅卷人想看的是具体的操作动词和明确的技术选型。同样表达做好监控高分的写法是部署 Prometheus Grafana 做指标采集和可视化对 node_exporter 采集的系统指标和业务接口的响应时间、错误率都配置告警规则通过 Alertmanager 推送到飞书/钉钉群值班人员在 5 分钟内响应。另外一个容易被忽略的踩分点是故障预案。很多人在场景题里只写了发生故障后怎么排查但没写怎么避免故障发生。如果你能补充发布流程的灰度发布、配置变更前的备份和回滚方案、定期做故障演练比如混沌工程里的随机杀节点这些都是踩分点说明你有全局运维意识而不只是一个会敲命令的操作工。7. 从笔试到面试的备考复盘如何把一套卷子吃透7.1 通过笔试暴露的问题反向定位薄弱项笔试结束后不要对完答案就扔。把错题按模块归类你会很清楚地看到自己的薄弱环节在哪里。我当时的情况是Linux 命令和数据库题做得不错但网络部分的 TCP 状态、Nginx 场景题扣分严重说明我对网络协议怎么落到实际运维场景这一层理解不够深。针对性补了半个月的 Nginx 配置和 tcpdump 抓包分析后面面试聊起类似问题时状态完全不一样。建议你也做一张表列出每个模块的得分率得分率低于 60% 的模块优先补。把每道错题都改写成知识点 实际场景 排查命令的格式背后是错题→查漏→重练的循环。这个循环不只为笔试校招后续的面试环节大概率也是同一个知识体系的延展。7.2 时间分配与刷题建议如果你现在离笔试还有两到三周建议按50% 基础巩固 30% 场景练习 20% 模拟笔试来分配。基础巩固阶段把 Linux 核心命令、TCP/IP 状态流转、MySQL/Redis 核心机制过一遍达到能写出来而不是只能认出来的水平场景练习阶段重点做故障排查题和脚本题练完一定要动手敲加深记忆最后找两三套别的公司的运维真题做模拟严格限时提前适应考试节奏。笔试过程中的时间分配也有技巧。试卷发下来先快速浏览全卷把送分题先做掉给后面的场景题留足时间。遇到卡壳的题先跳过不要在一道题上耗太久。记住一个原则运维笔试题大部分不需要你写出业内最优解而是要你展示出清晰的思路和完整的操作闭环。写满、写完整比写一个完美但残缺的答案得分更高。7.3 从笔试卷看运维岗位的真实工作内容最后说点实际感受。这份 2018 年的笔试卷看上去已经是六七年前的东西了但当年它考的那些能力——Linux 熟练度、网络排查功底、数据库和缓存的基本素养、脚本自动化能力、场景化思维——到今天依然是运维工程师的立身之本。变化的是工具链容器化从 Docker 演进到 Kubernetes 生态监控从 Zabbix 演进到 Prometheus 可观测性体系脚本从 Shell 逐步扩展为 Python/Go 工具。但底层那套定位问题 → 分析原因 → 实施修复 → 复盘沉淀的思维模式从来都没有变过。我在实际招聘中看过很多简历发现一个共性能写好场景题、能给出具体排查路径的候选人入职后上手速度明显更快。因为他们不是背了一堆命令而是真的理解了一个 Web 服务从请求到响应的完整链路。这也是我在带新人时最看重的一点——笔试的成绩只是入场券持续的好奇心和动手能力才是运维这条路能走多远的关键。所以刷完这套笔试卷别急着丢掉它会是你从校招走向一线运维的第一份实战地图。