又到了春招季最近好几个搞运维的兄弟私信我问搜狐畅游这类游戏公司的运维开发岗笔试到底怎么准备。我自己去年也参加过类似的笔试也帮人改过简历、做过模拟面试算是踩过不少坑。今天就把这些经验整理出来重点聊聊运维开发这个岗位在笔试里到底考什么、为什么考、怎么答才能拿到分。这篇内容不针对某个具体公司泄题而是从岗位底层逻辑出发给你一套能复用的备考框架。运维开发这个词听起来挺杂的既要懂运维又要会开发。很多同学第一反应是“这不就是既要当运维又要当开发吗”其实不完全对。在游戏公司、互联网公司里运维开发的核心任务是用代码解决运维问题而不是把运维和开发两摊子活都干。笔试考的内容也是围绕这个核心来设计的操作系统、网络、脚本语言、自动化工具、常见故障排查思路。这些不是死记硬背的知识点而是你日常处理服务器、部署、监控、告警时真正要用的能力。下面我把整个备考思路拆开讲从岗位画像到具体题型再到答题技巧和避坑经验一次性说清楚。1. 岗位画像运维开发到底在招什么样的人1.1 笔试背后的岗位需求逻辑很多同学复习笔试时容易陷入“刷题陷阱”觉得把网上常见的运维面试题背熟就行。但公司出笔试题目不是因为无聊而是为了筛选出符合岗位真实需求的人。搜狐畅游这类游戏公司服务器规模大、业务实时性要求高运维团队要保证游戏稳定上线、版本快速迭代、故障及时恢复。所以运维开发工程师不是传统意义的“机房管理员”而是要通过开发手段提升运维效率、降低人工成本。笔试题目一般分为几大块基础技术题Linux、网络、数据库、编程题Shell/Python/Go、场景设计题监控、告警、日志收集、开放题故障排查思路、架构理解。这些题目背后对应的是三种能力第一能不能稳稳当当地管好服务器第二能不能用代码把重复工作自动化第三遇到问题能不能快速定位、合理决策。1.2 运维开发与传统运维的核心区别我在跟一些同学聊天时发现很多人还是用传统运维的思路准备笔试过度关注“命令背没背熟”“服务配置对不对”却忽略了代码能力。实际上运维开发岗位笔试里手写脚本或代码的比重越来越高。因为游戏公司每天要处理海量日志、配置成百上千台服务器如果全靠手动敲命令效率太低。公司需要的人是能写工具、能搭平台、能优化流程的工程师。所以说笔试复习必须“两手抓”一手抓基础运维知识保证不丢分一手抓编程能力保证拉开差距。单会Shell还不够Python至少得能写点实用的脚本懂基本的类、异常处理、文件操作。如果有余力了解一点Go更好毕竟很多云原生组件都是Go写的。1.3 “游戏公司”运维的特殊性游戏业务的运维和普通互联网业务还有点不一样。游戏有版本更新、开服合服、跨服战、活动大促这些特殊场景对服务器资源调度、数据一致性、玩家体验保障都有更高要求。笔试中可能会出现类似“游戏开服前需要做哪些检查”“服务器CPU飙高怎么排查”“玩家反馈卡顿你从哪些维度分析”这类问题。这些题目考察的不是死知识而是你对游戏运维场景的理解。所以备考时别只盯着纯技术还要主动去了解一下游戏运维的日常什么是接入层、逻辑服、DB服什么是热更、滚服运营活动对服务器的压力是怎样的。有了这个场景感答题时才能说到点子上。2. 核心笔试内容拆解系统、网络、脚本与自动化2.1 Linux系统与文件系统是一切的底座Linux在运维笔试中的地位永远是第一位的。因为绝大多数服务器都是Linux你所有的运维工作都是在这上面展开的。常见的考察点包括进程管理ps、top、htop、pidof、文件权限chmod、chown、umask、ACL、磁盘管理df、du、fdisk、lvm、inode、系统启动流程、systemd服务管理、crontab定时任务等。很多同学觉得这些命令背一背就行其实笔试出题更喜欢“场景化”。比如给你一串输出让你判断系统哪里有问题或者给你一个报错让你说出排查步骤。比如“磁盘空间满了但df显示还有空间怎么排查”这就涉及inode耗尽的问题。又比如“服务器负载很高但CPU使用率却很低”这可能是IO等待太多需要用iostat、vmstat、pidstat这些工具去看。光靠背命令是答不好的得真正理解系统的工作原理。我建议复习的时候每学一个命令就反问自己三个问题这个命令解决什么问题它的输出里关键字段是什么如果数值异常下一步该看什么把这三个问题想明白比刷一百道题目有效得多。我在实际笔试中遇到过一道题给出top输出问哪一列判断CPU瓶颈、哪一列判断内存瓶颈、LOAD平均值怎么理解。看起来基础但很多人在LOAD含义上答不完整没有说清楚“R进程数D不可中断进程数”才是它真正的含义。2.2 网络基础从TCP三次握手到HTTP状态码网络部分也是笔试重头戏尤其是TCP/IP协议。经常考的有TCP三次握手和四次挥手的状态变化SYN_SENT、ESTABLISHED、FIN_WAIT_2、TIME_WAIT等、TIME_WAIT大量出现的原因和处理方式、TCP粘包与拆包、HTTP/HTTPS区别、常见状态码含义200、301、302、403、404、500、502、503、504、DNS解析流程、负载均衡原理LVS、Nginx、HAProxy。如果你搜过2023年的运维笔试经验帖很多人都会提到一道经典题用户在浏览器输入一个网址到看到页面的完整过程。这题看起来简单但能拉开层次。基础答案DNS解析、TCP连接、发送HTTP请求、服务器响应、浏览器渲染。深入答案DNS缓存查找顺序、HTTP协议版本差异、是否走CDN、后端有没有负载均衡、数据库查询耗时、页面静态资源优化。在笔试中这种开放性题目是展示你知识广度和思考深度的好机会一定要分层作答不要只写三行。网络排查工具也要熟悉ping、telnet、nc、traceroute、curl、ss、netstat、tcpdump。尤其是tcpdump笔试可能给你一段抓包结果让你分析异常。我见过一道题抓包发现大量TCP重传让你说可能的原因和排查方案。答这种题要从网络丢包、带宽拥塞、接收方处理能力不足、网卡故障、防火墙丢包等角度展开而不是只回答一句“网络不好”。2.3 脚本与编程用代码解决重复劳动运维开发笔试里编程题的分值往往很高。Shell脚本是基本功常考的有用shell实现日志切割、统计访问量Top N、批量修改文件名、检查进程是否存在并拉起、定时清理过期文件等。Python脚本则更偏向复杂逻辑解析日志文件、调用API采集数据、写一个小监控脚本、处理JSON/CSV、异常日志告警推送等。脚本题主要考的不是算法而是你能否用代码高效处理运维问题。所以准备时要多练习字符串处理、文件读写、正则匹配、循环和函数封装。我见过一道Shell题给定一个nginx日志文件要求统计每个IP的访问次数并按降序输出。这题用awk加sort就能解决但很多人写得很啰嗦甚至用循环逐行读效率低还容易错。标准答案一般是awk {print $1} access.log | sort | uniq -c | sort -rn类似这种题考的就是你对文本处理工具的熟练度。但需要提醒的是笔试环境不一定能联网查资料所以常用命令的语法一定要手写熟练。如果你平时写脚本全靠复制粘贴建议考前突击练习一下确保能默写出来。Python方面至少要掌握文件的读写with open、正则模块re、requests库基本用法、argparse解析命令行参数、logging模块、subprocess调用系统命令。比如让你写一个“监控磁盘使用率超过80%发告警”的脚本你要能在15分钟内写出结构清晰、带异常处理的版本。而不是写一大堆无脑逻辑。2.4 自动化运维与CI/CD了解工具背后的思想游戏公司也在全面拥抱DevOps和容器化所以笔试也会涉及自动化工具和持续集成。比如Jenkins、GitLab CI、Ansible、SaltStack、Terraform、Docker、Kubernetes。有些同学担心自己没实际用过这些工具看到题目就慌。其实笔试对工具的考察更多是“概念使用场景核心原理”不会让你写出完整的K8s编排文件。比如Ansible可能会问它和SaltStack的区别、它的执行流程是什么、有没有agent。Docker可能会问镜像和容器的区别、Dockerfile常用指令FROM、RUN、CMD、ENTRYPOINT、COPY、ADD、容器和虚拟机隔离差异。K8s可能会问Pod和Deployment的关系、Service的作用、ConfigMap和Secret的区别、PV和PVC是干什么的。我的备考建议是对每一种工具不要纠结版本号和零碎参数而是先弄清楚三个问题它解决了什么痛点它的核心组件有哪些它的工作流程是怎样的比如Docker解决了“环境一致性和交付标准化”的问题核心是镜像分层和容器隔离。K8s解决了“大规模容器编排调度”的问题核心是声明式API、控制循环、etcd存储。这些思想层面的理解比硬背命令值钱得多。3. 实战经验从经典笔试题到标准答题思路3.1 系统类题目CPU飙高的排查过程说实话这类题目几乎每次笔试都会出现值得单独拿出来讲。题目一般是“线上服务器CPU使用率突然飙高到90%你如何排查”很多人上来就答“用top查看进程”这没错但太浅了。面试官想听的是你完整且有条理的思路。我的标准答题框架是四步先用top/htop定位消耗CPU的具体进程PID再用ps -Lp 查看该进程下具体线程或用top -H -p 找到消耗最高的线程ID接着把线程ID转成十六进制用jstackJava应用或pstack、gdbC/C应用看线程栈最后根据栈信息定位到具体代码逻辑比如是否出现死循环、频繁GC、正则回溯等。除了进程内部视角还要考虑外部视角是不是业务流量突增是不是定时任务集中执行是不是数据库慢查询导致的连接池膨胀这些都需要通过监控曲线来判断。答题时如果能提到“结合监控系统看CPU、负载、QPS、GC曲线排查是突然飙升还是缓慢增长”会显得你更有实战经验。如果题目还问怎么解决你要分情况说如果是代码问题优化逻辑如果是容量问题扩容或限流如果是定时任务冲突调整执行时间。3.2 网络类题目数据库连接池连接耗尽的处理还有一种很常见的场景题应用报错“无法获取数据库连接”或“连接池耗尽”让你排查。这个题考的是你对网络和连接管理的理解。我的思路分为几步先看应用日志确认报错内容和发生时间再检查数据库服务器当前连接数、是否达到max_connections上限再检查应用侧连接池配置初始大小、最大大小、获取超时时间还要看网络层有没有异常比如防火墙、NAT、负载均衡会话保持策略。其实这个问题的根因有很多数据库慢查询或锁等待导致连接被长时间占用、连接池泄漏取连接后没归还、突发流量导致连接数不够、数据库本身hang住或拒绝连接。回答时如果能主动列出这些可能性然后说明“根据时间点和监控逐一排除”就能体现你的排查思维。很多同学喜欢一上来就“重启数据库”这个答案在笔试里基本拿不到分因为太粗暴且风险极高。3.3 脚本编程题一个完整的日志处理需求笔试编程题不会太复杂但会考察你的工程意识。比如有一个多行日志文件每行包含IP、时间、URL、状态码、请求耗时要求统计出“接口平均响应时间Top 10的URL”并输出到文件中。这道题Shell和Python都能写但得分点不同。用Shell写重点在于命令组合和效率awk {time[$3]$5; count[$3]} END {for (url in time) print url, time[url]/count[url]} test.log | sort -k2 -rn | head -10 top10.txt这里假设第3列是URL第5列是耗时。Shell版胜在简洁但可读性和异常处理较弱。用Python写更能体现工程能力import re from collections import defaultdict time_cost defaultdict(lambda: [0, 0]) # url - [总耗时, 次数] pattern re.compile(r(\S) (\S) (\S) (\S) (\S)) with open(test.log, r) as f: for line in f: m pattern.match(line) if not m: continue ip, time_str, url, status, cost m.groups() time_cost[url][0] float(cost) time_cost[url][1] 1 result [(url, round(total/count, 2)) for url, (total, count) in time_cost.items()] result.sort(keylambda x: x[1], reverseTrue) with open(top10.txt, w) as f: for url, avg in result[:10]: f.write(f{url} {avg}\n)这份代码胜在结构清晰、有正则和容错、有数据结构的合理使用。笔试时如果时间允许我推荐写Python版本并在注释里简单说明思路。要注意变量命名、边界条件比如空文件、正则匹配失败。这都能给阅卷人留下好印象。我自己当年笔试时光是脚本题就占了三大题所以这部分的熟练度直接影响能不能进面试。3.4 监控与告警笔试必考的开放性设计题监控设计题是运维开发笔试的常客。常见问法“如果让你设计一个服务器监控系统你怎么设计”或者“线上服务出现异常但你不知道具体哪台机器有问题如何通过监控快速发现”这类题没有标准答案但需要覆盖几个关键点数据采集、数据存储、告警规则、展示可视化。采集层面要说明用什么方式采集指标比如Node Exporter、Telegraf、Agent数据存储可以用Prometheus时序数据库或者InfluxDB、VictoriaMetrics告警要说明阈值设定和通知渠道企业微信、钉钉、邮件、短信可视化通常用Grafana。此外还要考虑监控对象分维度主机CPU、内存、磁盘、网络、中间件Nginx、Redis、MySQL、应用层QPS、错误率、响应时间。如果能设计出“分层监控、逐层定位”的体系比如先看整体大盘再下钻到集群、单机、进程就能体现你的架构意识。游戏公司还可能问带有业务属性的监控比如“某个区服玩家登录失败率升高你怎么定位”。回答时要拆成几步判断是全区服还是单区服、是网络问题还是登录服务问题、是数据库慢还是负载均衡异常、是版本更新引入的Bug还是配置错误。这种题看的就是分析思路所以平时要养成“假设-验证”的思考习惯。4. 春招笔试避坑指南与个人心得4.1 高频易错点答完不一定得分第一坑题目要求的是“输出结果的命令”你却只写出了思路没有具体命令。很多笔试是线上OJ或人工阅卷他们看重可执行性。比如问“如何查看端口8080是否被占用”至少应该写出netstat -tlnp | grep 8080 ss -tlnp | grep 8080 lsof -i:8080最好把几种方式都写出来然后说明哪种更优。第二坑回答问题时只写结论不写依据。比如问“为什么大量TIME_WAIT”如果你只写“因为有大量短连接”就太薄了。应该补充完整机制TIME_WAIT是TCP主动关闭连接的一方进入的状态作用是保证最后的ACK能可靠到达、防止旧连接数据包干扰新连接。然后再说如何处理开启tcp_tw_reuse和tcp_tw_recycle、调整keepalive、使用长连接、让负载均衡和反向代理来消化短连接。这样“现象-原理-解决”才完整。第三坑编程题里遇到不会的直接空着。我理解考场上遇到不会写的代码很慌但哪怕写个伪代码或分步注释也可能得一点思路分。尤其是运维开发的编程题阅卷人更看重你的思路是否可行完全不写等于放弃。第四坑题目问“你的项目经历或你做过最复杂的运维工作”时回答得过于平淡。笔试中有些开放题其实是想了解你的深度你可以提前准备一两个自己做过的小项目比如“我写了一个自动备份脚本解决当时日志丢失问题”讲清楚背景、方案、效果和反思会非常有说服力。4.2 时间分配与答题顺序如果笔试时间是一小时到两小时时间分配很关键。我的建议是先花3到5分钟扫一遍全部题目判断哪些是自己熟悉的、哪些是陌生的。优先做基础题和会做的编程题保证拿分把开放性题目放在中间段留足时间组织语言最后再做不确定的题哪怕猜也要写满。我遇到过不少同学在选择题或填空题上反复纠结浪费了大量时间导致后面的编程题没时间写。运维开发的笔试编程题分值往往很高一道大题可能抵得上十道选择题。所以在时间分配上一定要把编程题当作“必拿分”项。如果前面有一道题卡住超过5分钟先标记跳过做完后面的再回头看。4.3 复盘与后续准备建议笔试结束不等于求职结束。不管答得好不好我建议你当天晚上就把题目回忆一遍记录下来考了哪些知识点、哪些题没答好、哪些是明明会但没时间写的。这个复盘价值非常大因为春招的笔试往往是连续的你今天踩过的坑明天很可能在其他公司还会遇到。我当年就是这么做的把各家的笔试题目汇总成自己的题库文档后面复习效率提升了很多。如果你笔试通过进入面试也要提前准备自我介绍和项目经历。面试官可能会针对笔试中的某个题目深挖比如问“你写的那个脚本在真实环境跑过吗有没有遇到什么问题”所以笔试中写过的代码绝对不能是凭空捏造的最好能是你真正做过或练过的东西。哪怕只是一个简单的磁盘告警脚本你也要能讲清楚它的逻辑、适用场景和不足之处。关于备考资料我的建议是不要贪多。网上有大把题库但很多都是零散的遇到比较好的、讲得透彻的文章可以收藏起来然后结合书本查漏补缺。操作系统就看《鸟哥的Linux私房菜》基础篇网络就抓TCP/IP协议详解脚本就看官方文档加多写多练。工具类不求精通但Jenkins、Ansible、Docker、K8s、Prometheus这些主流组件的基本概念和使用场景必须知道平时有条件的话搭个虚拟机或小集群练一练哪怕只是在本地用Docker跑几个容器也会让你的理解上一个台阶。最后再分享一个我自己的小经验笔试前可以专门花半小时在脑子里过一遍“服务器从开机到提供服务”的全流程从加电、BIOS、引导加载、内核初始化、systemd启动服务到网络配置、启动Nginx、加载应用代码、建立连接池、接收用户请求。这个全流程里藏着90%的笔试考点你顺着它往下想很容易把零散的知识串成一张网。把这张网织好再去做那些看似零散的题目你会发现很多题的本质都是相通的。