开始前先说个背景运维开发工程师这几年在游戏行业校招里一直是香饽饽。搜狐畅游2019年校招笔试题我当年拿到手的时候第一感觉是题目看着不吓人但覆盖面特别广Linux、网络、Python、数据库、场景设计一锅端而且越做越能察觉到出题人在试探你的自动化思维和业务理解能力。这篇文章就把这套典型笔试的考点拆开揉碎从答题者的视角讲讲每类题背后想考什么、怎么准备最稳也顺便聊聊这类笔试题对后续面试和实际工作的参考意义。不管是准备校招的应届生还是想转岗运维开发的老人都能从里面找到能直接用的东西。1. 笔试整体设计与考察逻辑1.1 游戏公司为什么专门考运维开发很多同学第一次看到“运维开发工程师”这个岗位名会愣一下运维就运维为什么后面还要挂“开发”两个字这个岗位在游戏公司里其实非常具体——运营的游戏区服动辄几十上百组服务器数量多、变更频繁、监控告警、日志采集、发布排期全部靠手工敲命令根本不现实所以必须有人把这些重复性工作做成平台、做成工具。这个角色既要懂系统、网络、数据库这些运维基本功又要能写代码把流程自动化这就是“运维开发”的由来。搜狐畅游这种体量的游戏公司业务特点决定了它对运维开发有明确要求游戏版本更新频繁合服、开服、滚服是日常操作线上流量有明显波峰波谷节假日活动期间短时压力极大玩家数据分散在多个数据库实例里出了问题要能快速定位。这些场景决定了笔试不会只考死记硬背的命令参数而是考你能不能理解业务能不能用代码和脚本解决问题。我后来也参与过类似规模的校招笔试命题出题人脑子里其实就一条逻辑线先确认你有没有基础功底再确认你有没有开发能力最后看你面对真实运维场景时有没有解决问题的思路。所以整套卷子并不是为了难倒你而是想通过有限的时间快速判断一个人能不能在入职后独立上手。这也解释了为什么题目看起来杂但每道题背后都有明确的考察目标。1.2 考点分布与题型拆解从这类笔试的常见安排来看考点分布大概有这样一个规律Linux 基础占两到三成网络基础占一成半左右Python 和 Shell 脚本能力能占到三成以上数据库和中间件基础知识占一到两成最后一定有一道开放性的场景设计题。选择题、简答题、编程题、设计题四种形式基本都会出现选择题考广度简答题考理解深度编程题考代码熟练度设计题考系统思维。这里我先给一个大概的题型和占比参考方便你做复习规划考察模块常见题型大致占比核心目标Linux 基础与命令选择、简答20% - 25%排查问题的基本能力网络协议与排障选择、简答10% - 15%理解连接与故障链路Python / Shell 编程编程题30% - 35%自动化落地能力数据库与中间件简答、选择10% - 15%数据存储与缓存意识监控、发布等场景设计题10% - 15%全局架构与运维思维时间分配上我的建议是选择题遇到没把握的不要死磕先标记整个选择题区块控制在25到30分钟之间简答题分点作答每题控制在10分钟以内编程题是分值大户建议留出充足时间先写思路再写代码别一上来就翻小抄式地硬写最后那道场景设计题一定要写满哪怕方案不是最优也要让阅卷人看到你有完整的思考过程。时间管理本身就是这类笔试考察的一部分一个能在有限时间内合理分配精力的人通常也是工作中更靠谱的人。2. 操作系统与网络基础的关键考点2.1 Linux 高频命令与系统排查思路Linux 命令这块笔试很少直接考“top 用来看什么”更多是给一个故障场景让你选排查命令。比如“一台服务器 CPU 负载飙升到 20你第一步怎么做”这种题表面上考命令实际上考排查思路。正确的顺序一般是先用 top 看进程级别的 CPU 占用再配合 ps 看具体进程启动时间、运行状态必要时用 strace 追踪系统调用。top 的交互命令也要熟按 P 按 CPU 排序、按 M 按内存排序、按 C 显示完整命令行这些细节都会在场景题里派上用场。内存和磁盘的排查也经常出现。free -h 看内存总量和缓存占比注意区分真正的内存瓶颈和 page cache 占用——后者通常是正常的文件缓存可回收不要误判df -h 看分区使用率df -i 看 inode 是否耗尽这是经常被忽略的坑文件没删多少但 df 报满很多时候是 inode 用完了。再往下就是 iostat重点是 %util 和 await如果 %util 很高但 await 还好说明设备利用率充分如果 await 很高但 %util 不高可能是有 IO 队列竞争或者磁盘本身有问题。这里给你一个排查负载高问题的标准路径先 top 看 CPU再看 load average然后区分是 CPU 密集还是 IO 密集。CPU 密集就看哪个进程占资源IO 密集就用 iostat 看磁盘状态同时用 vmstat 看 r 列运行队列和 b 列不可中断睡眠进程。我在实际操作中发现很多新手一看到 load 高就慌其实只要按这个链路拆下去十分钟内基本能定位到根因。笔试里如果遇到这种场景题把你脑海中完整的排查链路写出来哪怕不完美也比只写一两条命令强得多。2.2 网络协议、连接状态与常见故障网络这块TCP 连接状态是笔试和面试都绕不开的点。TIME_WAIT 应该是出镜率最高的词比如“线上大量 TIME_WAIT 怎么办”。先说原理主动关闭连接的一方在收到对方的 FIN 后会进入 TIME_WAIT 状态并等待 2MSLMaximum Segment Lifetime超时后才会完全释放连接。这个机制是为了保证最后一个 ACK 能可靠到达对方同时让旧连接的报文在网络中彻底消失避免污染新连接。大量 TIME_WAIT 本身不一定代表系统有问题关键看端口资源有没有耗尽如果客户端端口不够用了才会表现成连接建立失败。针对 TIME_WAIT 的处理我建议先做合理调优再考虑绕过。内核参数方面可以调整 net.ipv4.tcp_fin_timeout 缩短 FIN-WAIT-2 的等待时间也可以让长连接复用但我不建议直接粗暴开启某些快速回收参数因为可能带来报文乱序识别问题尤其在 NAT 环境下容易误伤正常连接。更稳的方案是改应用层连接池复用、减少频繁的短连接、使用 HTTP 长连接这些都是治本的办法。笔试和面试里你能把“为什么会有 TIME_WAIT”“什么时候才需要担心”“治本方案是什么”一条线说清楚已经很加分了。端口连通性排查也是网络部分的常客。我给你一个通用排查链路先 ping 看网络层通不通再 telnet 或 nc 看端口通不通然后 curl 或查看应用日志看服务本身有没有正常响应。很多同学一个问题直接拿 curl 去试如果应用层没起来curl 报错也无法判断是网络问题还是服务问题。正确做法是逐层排查每一层都有明确的结论。比如 curl 超时先 telnet 一下端口如果端口是通的说明 TCP 层面没问题问题出在 HTTP 响应慢这时候再考虑是应用处理慢还是后端依赖慢。笔试里的网络题这种分层排查的思路比单纯背命令值钱得多。3. 编程能力与自动化脚本考点3.1 Python 编程题的典型解法Python 编程题通常都不会太难重点集中在文件读取、日志分析、字符串处理、基本数据结构这几个方向。有一类非常经典的题给一个 Nginx 访问日志文件统计访问次数最多的 IP 前十个。这题在考试里出现频率极高因为它能一次性验证 Python 基础、文件操作和数据聚合能力。我给出一个参考答案你可以对照着自己的写法看差距from collections import Counter ip_counter Counter() with open(/var/log/nginx/access.log, r) as f: for line in f: # 按空格切分访问日志第一列是 IP ip line.split( , 1)[0] ip_counter[ip] 1 # 取出访问次数最多的 10 个 IP top10 ip_counter.most_common(10) for ip, count in top10: print(ip, count)这段代码里有几个细节值得注意。第一用 with 打开文件文件用完之后自动关闭不会出现句柄泄漏第二用 for line in f 而不是先 f.readlines() 后遍历前者是逐行读取文件很大时内存占用恒定后者会一次性加载全部内容到内存日志量大的时候直接打爆第三用 Counter 类干计数和排序的活比手写字典再排序优雅得多。这些细节在阅卷时都是加分项说明你有真实的大数据处理意识而不是只会写练习题。如果题目要求更高一点让你处理一个超大文件比如几个 GB 级别的日志这时候逐行扫描虽然能跑但速度可能不够理想。更进阶的做法是用生成器分批处理配合多进程或者 awk 先做预聚合。笔试时如果遇到这种题我建议在代码里先用注释写出你的思路比如“先分片读取再按 IP 哈希分发到多个 worker 进程聚合最后合并结果”即使不写完整代码阅卷人也能看出你有性能意识。毕竟笔试时间有限把思路写清楚比盲目敲出一堆跑不起来的代码更有意义。3.2 Shell 脚本与文本处理三剑客Shell 脚本同样是运维开发的基本功。笔试中常见的 Shell 题包括写一个清理过期日志的脚本、写一个批量修改配置文件的脚本、用 awk 从某个命令输出里提取指定字段等。grep、sed、awk 这“三剑客”一定要熟练到条件反射级别。grep 负责行匹配过滤sed 负责行内替换编辑awk 负责字段提取和格式化输出。这三者的分工基本覆盖了文本处理里 90% 的需求。以清理日志脚本为例很多服务会按天分目录存放日志比如 /data/logs/app/2025-01-01.log需求是删除 7 天前的日志文件。我见过不少人第一反应就是写一堆循环加判断实际上 find 一行就能搞定#!/bin/bash BASE_DIR/data/logs/app KEEP_DAYS7 find $BASE_DIR -name *.log -type f -mtime $KEEP_DAYS -exec rm {} \;这段脚本的关键知识点在 find 的参数-type f 限定只删除文件避免误删目录-mtime 7 表示修改时间在 7 天之前-exec rm {} ; 是对匹配到的每个文件执行删除。有些同学会问为什么不用管 crontab实际上生产环境中这个脚本就是配合 crontab 每天跑一次的一般会在凌晨低峰期执行。笔试如果只让你写脚本你就把脚本本身写清楚如果还问你怎么定时执行那就补一句 crontab -e 加上“0 3 * * * /opt/scripts/clean_logs.sh 21”这种定时配置。这里有一个我在实际生产环境中踩过的坑用 find 删除文件千万不要用 rm -rf 直接拼接路径因为如果路径变量读出来是空的整条命令就变成了“rm -rf /”后果不堪设想。安全做法是先用 find 列出匹配到的文件确认一遍再删或者用 -exec 时严格限定路径和文件名条件。另外脚本里建议加上 set -u 防止未定义变量加 set -e 或对关键命令做返回值判断。笔试时写上这些防御性写法马上就能拉开和大多数考生的差距。我甚至在批改卷子的时候遇到过脚本逻辑完全正确的一个人因为没考虑变量为空的问题被我在评语里点名提醒。这些小细节平时多注意考试不吃亏。4. 数据库与中间件基础考点4.1 MySQL 索引与慢查询优化游戏公司的业务天生依赖数据库所以 MySQL 在运维开发笔试里几乎是必考的。考点集中在索引原理、慢查询分析、基本优化手段上。关于索引我建议一定先把原理理解透MySQL 的 InnoDB 引擎底层是 B 树结构索引就是一颗排好序的树通过它能够快速定位到目标数据避免全表扫描。但是索引不是越多越好每多一个索引写入和更新都要同步维护反而拖慢写性能。笔试里常见的索引题是一张玩家信息表有 player_id、server_id、level、login_time 等字段查询条件经常是“WHERE server_id ? AND player_id ?”问你索引怎么建。这种题考察的是“最左前缀原则”也就是联合索引里查询条件必须从最左侧的字段开始匹配索引才会生效。所以索引应该建在 (server_id, player_id) 上而不是反过来因为反过来 player_id 单独过滤性虽然强但无法满足 server_id 作为第一个查询条件的场景。当然具体还要看哪个字段枚举值更少、哪个更常用笔试里把最左前缀原则写清楚再结合实际查询条件给出建议基本就能拿高分。慢查询这块运维开发工程师至少要知道怎么定位慢 SQL。第一步是确保慢查询日志打开并设置合理阈值在 MySQL 配置中有两个关键参数slow_query_log 设为 ON 开启日志long_query_time 设置为 1 秒线上我一般建议 1 到 2 秒太短会把日志刷爆太长又发现不了问题。然后定期用 mysqldumpslow 工具汇总慢查询日志找出那些累计执行次数多、总耗时长的 SQL。定位到之后用 EXPLAIN 查看执行计划重点看 type 列是不是 ALL全表扫描、key 列有没有用上索引、rows 列预估扫描了多少行。这三个字段几乎是慢查询分析的“三板斧”笔试和面试都会问到。4.2 Redis 与消息队列的基本认知中间件部分Redis 是出镜率最高的。Redis 的核心考点是缓存穿透、缓存击穿、缓存雪崩以及常用的数据结构。缓存穿透指查询一个必然不存在的数据请求直接打到数据库缓存的 key 都没对应但 database 也没有于是缓存形同虚设大量请求穿透到数据库。解决方案是布隆过滤器前置过滤或者把空值也缓存起来设置较短过期时间。缓存雪崩指大量 key 在同一时间失效导致请求全部落到数据库上解决思路是把过期时间分散加随机值。缓存击穿指一个热 key 在失效瞬间有大量并发请求同时打过来这时候可以用互斥锁或逻辑过期来解决。数据结构方面游戏排行榜是一个经典场景玩家积分实时变化需要快速获取前 100 名。这种需求用 Sorted Set有序集合就非常合适key 是排行榜名称member 是玩家 IDscore 是积分。ZADD 更新积分ZREVRANGE 取分数从高到低的排行榜ZSCORE 查单个人分数复杂度都是 log(N)性能很好。这个问题几乎是游戏公司笔试里的常客我强烈建议你背熟这几个命令并理解为什么用 Sorted Set 而不是 List 或者普通 Set。消息队列在运维开发里更多是作为应用架构的组件出现。考题一般会问“为什么需要消息队列”答案核心是解耦、削峰、异步。游戏服务器在高并发活动时玩家行为日志、跨服消息等如果全部同步处理后端压力会非常大引入消息队列可以先写队列再消费让系统平滑扛住峰值。笔试遇到这种题把“削峰填谷、异步解耦”这八个字展开再结合一个具体业务场景说明就够了。至于 RocketMQ、Kafka、RabbitMQ 各自的优劣属于进阶内容有时间可以了解但不是笔试重点。5. 运维开发场景实操从笔试到落地5.1 监控告警系统设计笔试最后一道场景设计题通常会给一个业务场景让你设计一套监控告警系统或者设计一个自动化发布流程。这种题没有唯一标准答案考察的是全局架构能力。以监控系统为例我建议你按“采集 - 存储 - 展示 - 告警”四个层次来回答这是最不容易漏点、也最容易让阅卷人捕捉到你的结构感的方式。第一层是数据采集。需要明确采集哪些指标一般分三类机器指标如 CPU、内存、磁盘、网络流量业务指标如每分钟请求量、错误率、响应时间 P99日志指标如错误日志条数、慢查询条数。采集周期也要注意机器指标一般 15 到 30 秒一次业务指标根据重要程度可以做到秒级。这里可以列一个表格帮助表达指标类型典型指标采集周期告警示例机器指标CPU、内存、磁盘、IO15 - 30sCPU 持续 5 分钟超过 85%业务指标QPS、错误率、响应时间5 - 10s错误率超过 1% 持续 2 分钟日志指标ERROR 日志数、慢查询数1minERROR 日志数突增 3 倍第二层是存储。时序数据要选择合适的时序数据库像 Prometheus 搭配 Thanos 或 VictoriaMetrics。这一层重点说明数据保留策略比如原始数据保留 15 天、降精度数据保留 6 个月避免存储无限增长。第三层是展示。Grafana 是常规选择需要规划好面板结构不能所有指标堆在一个大屏上而是按业务维度分面板比如“游戏服状态总览”“数据库性能”“网络层状态”。展示层有一个容易被忽略的点指标要有对比视图比如今天的数据跟昨天同时段对比、跟上周同时段对比这样异常更容易暴露出来。第四层是告警。告警要分级比如 P0 表示核心功能不可用需要立即通知接入电话P1 表示服务质量下降告警到值班群P2 表示资源趋势性紧张记录到日报即可。关键一点是告警一定要避免“狼来了”效应阈值设得太敏感受众会麻木设得太松又起不到预警作用。我在实际设计告警阈值时的经验是先观察一周基线数据再基于波动幅度设定阈值并且每条告警都要有对应的处理预案。笔试时你把“分级”和“避免告警疲劳”这两点写出来阅卷人基本能判断出你有实战经验。5.2 自动化发布与故障排查自动化发布流程是另一个高频设计题。游戏公司上线新版本非常频繁如果每次靠手动登录所有机器传包、重启进程效率低且容易出错。所以设计题一般会让你描述一个完整的发布流程。我建议分成前置检查、构建打包、分发部署、验证回滚四个阶段来答。前置检查阶段要做的是确认代码分支和版本号正确跑一遍自动化测试检查服务器磁盘空间和端口占用避免发到一半发现空间不够。构建打包阶段如果是 Python 项目可能就是安装依赖打 tar 包如果是 C 游戏服务端则是编译并收集产物。分发部署阶段可以设计先发布一台灰度服务器确认启动日志无异常再批量推送批量推送时最好分批进行比如一次 20 台观察监控指标稳定后再推下一批避免一次推完导致问题面过大。验证阶段除了检查进程存活和端口监听还要看关键业务指标比如客户端心跳数、登录成功率。回滚策略也必须提前想好最常见的就是保留上一版本的完整目录发布失败时快速切换软链接回滚。故障排查题在笔试里更多以简答题或者选择题出现但设计题里也会要求你附带说明某种故障的处理思路。比如线上出现大量 502 错误怎么排查正确链路是先确认是网关问题还是后端服务问题。看 Nginx 错误日志确认后端连接被拒还是超时再 telnet 后端服务端口确认端口有没有监听接着看后端进程 CPU 和内存用 top 看是否资源耗尽最后看数据库连接池是否被打满。排查的过程中每一步都要有结论排查完要有恢复动作比如临时扩容、重启故障节点、限流保护。这种分步排查的描述方式在笔试里特别能拿分因为它展示的不只是知识点而是解决问题的能力。6. 笔试实战经验与常见陷阱6.1 答题顺序与时间管理这类笔试的时间通常是 90 到 120 分钟题量不算小如果没有章法很容易在选择题上耗太久导致后面大片空白。我建议拿到卷子先花两三分钟完整浏览一遍对难度和分值心里有数。然后做题顺序坚持“先易后难、先分多后分少”的原则选择题虽然多但分值小40 道选择题做 25 分钟左右就该收手遇到犹豫的直接标记跳过简答题控制在 35 分钟内每道题先列点再展开编程题哪怕只写核心函数也要写注意先写思路注释再码代码不会的题目把算法过程描述清楚也能拿到部分分最后的设计题至少留 20 分钟这种题分值高、能写的内容多千万不要留白。时间分配上还可以用一个小技巧每做完一个板块在草稿纸上记录一下实际用时超时太多就强制收尾。我当年考试的时候就是这样做的选择题有一道网络题拿不准果断放弃后把时间留给了后面的 Shell 脚本题最后那道脚本题拿了满分弥补了前面的小失误。笔试考的是综合得分率不是单题正确率这个思路一定要建立起来。另外编程题如果环境允许先本地跑一遍再提交很多笔试题的代码要在浏览器里现场运行语法错误都能立刻发现这时候多花一分钟检查代码规范比多写一行注释更值得。6.2 阅卷视角面试官看重什么这里我从阅卷人的角度给你交个底。批改这类笔试题的时候我最先看的是编程题。代码逻辑是不是完整、有没有考虑空值和异常分支、变量命名是否清晰、有没有关键注释这些都能在几十秒内看个大概。很多人容易犯的毛病是题目要求统计日志中访问量前 10 的 IP代码只写了统计没有排序输出或者输出了但没限制前 10这些都是扣分点。另一个常见问题是只写了主流程完全没有异常处理比如打开文件可能会失败、字段可能格式不对这些边界条件是阅卷人非常关注的因为运维开发工程师写出的脚本是要在真实服务器上长期跑的不可能永远拿到格式完美的数据。简答题里我比较反感只写结论不写理由的答案。比如问“为什么用缓存”只写“为了性能”跟没答一样但如果能写出“降低数据库压力、减少响应时间、扛住峰值流量”再补一句“同时要注意缓存一致性问题”那这个答案的层次就完全不同了。我建议你答题时分点每一点都是“现象 原因 解决思路”的完整结构这样阅卷人一眼能看到你的逻辑链。最后是设计题。设计题没有标准答案但阅卷人很容易看出一个人是真做过还是背模板。真做过的人会在方案里自然地提到灰度发布、回滚策略、告警阈值、指标对比这些细节背模板的人只会写“高可用、扩展性、稳定性”这些无效词汇。所以我给备考同学的建议是考前至少亲手搭一套简单的监控系统或者自动化部署脚本哪怕是测试环境也能帮你在答题时写出有血有肉的方案。6.3 一次完整的备考路线参考说到备考我结合自己带新人和参与校招的经验给出一套三个月左右的路线参考适合笔试前系统准备。第一个月主攻基础Linux 命令每天练一小时重点把 top、free、df、netstat、ss、lsof、grep、sed、awk 这九个命令用熟能用它们完成日常的进程查看、端口排查、日志提取同时每天刷 20 道 Python 基础题从列表、字典、字符串到文件操作、异常处理把基本功打好。第三个月开始加强度每天至少写两个小脚本比如清理临时文件、批量重命名、自动备份同时做几套真题和模拟题总结错题和高频考点把之前的基础知识串联起来。第二个月进入经验积累阶段主要可以看《鸟哥的 Linux 私房菜》基础篇、Python 相关的核心编程配合 “高性能 MySQL” 理解索引和查询优化。同时可以开始接触真实运维场景找一台云服务器把日志采集、进程守护、定时任务、简单监控手动搭一遍。这个阶段你会发现很多笔试里的题目在真实环境里操作一遍之后印象会深很多比如你在服务器上真的经历过一次磁盘满、TCP 连接数过多的问题以后再遇到相关题目时不需要死记硬背。三个月下来你不仅能应付这类笔试题日常工作中很多基础问题也能独立处理了。备考的核心从来不是刷题库而是建立“看到问题 - 定位原因 - 用代码或命令解决”这个闭环。笔试只是这个能力的一小次检验真正让你走得远的是养成的工程习惯。写在最后这些年看过的校招笔试和面试有不少个人最大的体会是运维开发工程师的笔试题变化不大但要求越来越高。2019 年那会儿会写 Python 脚本就算亮点现在很多应届生已经能交出带单元测试的完整工具代码了。基本功永远是最值钱的Linux、网络、数据库、脚本这四板斧走到哪里都不过时。如果你现在还在准备笔试题建议别只盯着一两套卷子刷而是把每个考点背后“为什么这样考”想明白。我面试过不少笔试高分但一问项目就露馅的候选人也见过笔试马马虎虎但聊到真实故障能滔滔不绝的选手后者在实际工作中往往走得更远。祝愿你在秋招季能碰到一套让自己答得痛快的题也早点找到适合自己成长节奏的团队。