前阵子有学弟问我游卡2024春招的运维开发笔试该怎么准备。他本身是计算机科班出身Linux、网络、数据库都学过但看到往年真题时还是有点没底——不知道游戏公司的运维开发笔试到底考什么、和互联网大厂的运维/后端笔试题有什么差别。这个问题挺有代表性的因为运维开发这个岗位在校招里属于“看上去谁都能投实际很挑人”的类型既要懂系统、网络这些传统运维底盘又要有写工具、做平台的研发能力笔试里的每一类题都在筛选这两种素质。这篇文我就结合游卡这个具体方向把运维开发校招笔试的题型、考点、答题思路和刷题方向完整拆一遍适合正在准备游戏公司运维开发/DevOps/SRE校招的同学参考也适合那种“还分不清运维开发和纯运维有什么区别先来看看适不适合自己”的人。1. 投递前先想清楚游戏公司要的运维开发到底考的是什么1.1 岗位画像拆解运维开发不是“会敲命令的运维”先说个很多人搞混的概念。运维开发英文对应通常是 DevOps Engineer 或者 SRESite Reliability Engineer偏开发方向的岗位和传统运维最大的区别在于传统运维的核心交付是“把系统用好”而运维开发的核心交付是“把运维能力做成工具和平台”。笔试时这两类岗位的考察重点完全不一样——纯运维岗可能大量考命令、考配置、考排查套路而运维开发岗会明显偏向脚本编写、代码逻辑、自动化设计还要看你有没有能力把一个重复性操作固化成可以复用的东西。做个对比就知道了能力维度传统运维笔试重点运维开发笔试重点Linux基础命令记忆、文件权限、系统管理命令背后的原理以及怎么在脚本里批量操作编程能力一般不考最多考ShellShell/Python二选一或都考常写完整小工具网络TCP/IP、常见故障排查TCP/IP HTTP协议细节能说出排查链路数据库SQL增删改查、备份恢复SQL 索引优化 常见数据库运维操作自动化和平台很少涉及CI/CD、监控告警、容器、配置管理等高频出现业务理解一般会结合游戏业务场景出题游卡本身的业务特点决定了它的运维开发岗位会更看重什么。游卡以《三国杀》系列和线上桌游业务为主这类产品的特点是玩家在线时长不短、实时交互要求高、运营活动频繁、开服合服操作多而且区服架构很重。游戏公司对运维开发的诉求通常集中在几件事上版本发布流程自动化、海量日志处理、监控告警体系搭建、容量评估、故障快速定位。笔试题目看起来零散实际都是围绕这些业务场景来做文章。1.2 从业务反推考点游戏厂商的笔试侧重点我不建议拿到笔试通知再临时抱佛脚而是建议在投递之前就做一个“考点预判”。方法不复杂把这家公司的业务形态列出来再反推“如果我是运维负责人我最怕线上出什么事我最希望校招生会什么”考点就八九不离十了。拿游卡这类游戏公司举例游戏有大量区服服务器割接、开服合服是日常操作所以要考 Linux 基础、脚本批量执行、配置管理。玩家会集中在晚上和活动期间登录流量波峰明显所以要考负载均衡、系统性能分析、容量评估思路。游戏日志又大又杂充值日志、战斗日志、登录日志、异常日志混在一起所以要考文本处理三剑客、日志分析脚本。线上出现故障时影响面大可能要快速回滚或切流量所以要考故障排查思路、发布策略。运营活动频繁每周可能发几次版本所以要考 CI/CD 概念、打包构建流程、自动化部署的基本原理。基于这个推演你就能理解为什么这类笔试总爱考“CPU飙高怎么排查”“日志怎么统计”“写个脚本监控服务”这类题了——不是因为出题人偷懒而是这些就是游戏运维日常里最高频、最核心的场景。1.3 备考资料与时间安排如果你还有两三周准备时间我建议按下面这个节奏来第一周基础扫盲 命令实操。过一遍 Linux 常用命令重点不是背参数而是理解每个命令的输出字段是什么意思。比如top里的 load average、free里的 buff/cache、df里的 Use%这些都可能变成笔试选择题的考点。网络和数据库基础同步进行《图解HTTP》加一本 MySQL 基础就够。第二周脚本强化。每天写一到两个小脚本覆盖日志统计、文件备份、批量检查、健康检查这几类常见场景。要求自己不用查文档就能写出来因为笔试现场经常是纯记事本环境没有补全、没有调试器写不写得出来很考验熟练度。第三周刷题 复盘。找各家公司运维开发岗的往年笔试回忆题按题型分类刷刷完一定要整理错题尤其要把“当时没想到的那个点”记下来。同时把常见的故障排查题答案整理成固定模板考试时直接套框架比自己边想边写要稳得多。2. 笔试题型全拆解基础题、脚本题、架构题各占多少比重2.1 基础题Linux、网络、数据库的“送分题”和“陷阱题”基础题一般占三成左右主要以选择题、判断题、填空题形式出现。这部分题目本身不难但特别喜欢在细节上挖坑。Linux 方向常考的点进程管理ps、kill、僵尸进程、文件权限rwx 数值计算、umask、系统负载top、uptime、load average 含义、磁盘管理df、du、inode 耗尽、服务管理systemd 基本操作。这里最容易被坑的是那种“看上去很简单实际考的是概念”的题比如“系统 load average 升高到 10但 CPU 使用率很低可能是什么原因”正确答案通常和 I/O 等待、进程阻塞有关而不是 CPU 本身。“某文件权限是 644属主是 root普通用户能否修改”这种题考的是权限判断逻辑不是单纯背数字。“du -sh和df -h看到的大小不一致是什么原因”涉及到已删除但未释放的文件句柄这种就属于典型的“平时没遇到就写不出来”的考点。网络方向常考的点TCP 三次握手和四次挥手包括为什么需要 TIME_WAIT、HTTP 状态码含义、DNS 解析过程、常见端口号。数据库方向常考的点索引原理、SQL 执行顺序、事务隔离级别、慢查询原因。基础题是整张卷子的兜底分正常复习过的同学应该能拿到七成以上。这里我特别想提醒一句基础题里如果出现那种“哪个命令可以查端口占用”之类的题优先答netstat和ss不要只写netstat一个。ss是netstat的替代品很多公司内部已经把netstat换掉了笔试里能主动提到ss会显得你有实际操作经验。2.2 脚本题Shell 与 Python至少要熟练掌握一个脚本题是运维开发笔试和纯运维笔试最大的分水岭通常占三到四成而且往往是拉分关键。出题形式一般是给一个实际场景让你写脚本或者补全脚本常见的场景有这么几类一是日志处理类。比如给一个 access.log 的样例让你统计访问量 Top10 的 IP。这种题用 Shell 就是经典的awk sort uniq组合用 Python 就是读文件 字典统计 排序输出。二是监控检查类。比如写一个脚本定时检查某个服务是否存活如果挂了就重启并发送告警。这种题考察的是进程管理、系统命令调用、异常处理、日志输出这些综合能力。三是批量操作类。比如有 100 台服务器需要批量执行某个命令或者批量分发文件让你写一个脚本实现。这种题本质上是考察循环、并发、连接复用这些编程基础用 Shell 的for循环或者 Python 的paramiko库都能做。四是数据处理类。比如从一个 CSV 文件里提取某个字段做聚合统计或者把多行日志按时间窗口切分。这种题的核心是字符串处理和数据结构的使用。笔试环境里写脚本和平时开发最大的不同是没有 IDE、不能联网查资料、很多时候甚至没有真实环境可以运行只能靠“裸写”。所以我强烈建议备考时用纯文本编辑器练写完再跑到终端里验证。练到一看到题目描述脑子里就能浮现出大致代码框架的程度才算过关。2.3 简答/设计题故障排查和架构设计的思路比答案重要简答题或设计题通常占两到三成这是笔试里最考验经验的部分也是很多同学最头疼的部分。这类题没有标准答案但阅卷时会看你有没有一套清晰的排查思路。常见题型包括“线上某台服务器 CPU 使用率达到 100%如何排查”“游戏开服当天玩家大量涌入登录服务响应缓慢怎么分析”“如何设计一套监控告警系统”“发布新版本后线上出现大量报错你如何快速定位和处置”这类题答题的核心是结构化。我建议所有同学至少准备一套自己的“故障排查模板”发现问题 → 影响评估 → 定位根因 → 应急止血 → 彻底解决 → 复盘总结。不管什么题往这个框架里填内容就能避免答得东一句西一句。设计类题目除了结构还要体现“可落地”不能天天嘴里挂着微服务、容器化、K8s 这些大词却说不清楚具体怎么监控、怎么发现故障、怎么扩容。校招笔试里能写清楚“一台服务器从接入到上线需要经历哪几步”这种小问题比空谈架构要实用得多。2.4 开放题游戏场景下的“送命题”与“加分题”不少游戏公司会在笔试最后放一两道开放性题目可能是商业场景分析题也可能是价值观 / 场景应对题。比如“如果凌晨三点游戏线上出故障你会怎么处理”“如何评估一次游戏活动的服务器容量”“某个玩家反馈游戏登录不上你会从哪些角度排查”这类题没有标准答案考察的是你面对真实工作场景时有没有基本的判断力。答题时不要只站在技术角度要把玩家体验、业务影响、沟通成本都考虑进去。比如凌晨三点故障那道题你除了说技术排查还要说“先判断影响范围影响大就立刻启动应急预案、通知相关同事不要一个人闷头查”这种回答会明显更成熟。3. 几类最容易拉开差距的经典题手把手拆解3.1 日志分析题awk、sort、uniq 的组合拳日志统计应该是运维开发笔试里出现频率最高的编程题之一因为它在真实工作中太常用了。我先说最常见的场景给一个 access.log里面每行包含 IP、时间、请求路径、状态码等字段要求统计访问次数最多的前 10 个 IP。用 Shell 写几乎有固定套路awk {print $1} access.log | sort | uniq -c | sort -rn | head -10一行命令就搞定了。但要注意几个细节awk {print $1}取的是第一个字段前提是日志格式里 IP 在第一列如果不在第一列就要用$NF或按分隔符指定。uniq -c统计前必须先sort因为uniq只能统计相邻的重复行这是非常经典的丢分点。sort -rn是数字排序并且倒序很多人只写了sort结果字典序排序导致 10 排在 9 前面看起来就很不专业。Python 版本也很容易from collections import Counter with open(access.log, r, encodingutf-8) as f: ip_list [line.split()[0] for line in f] for ip, count in Counter(ip_list).most_common(10): print(f{count}\t{ip})这段代码思路清晰但笔试时我建议再补一个异常处理因为文件可能很大而且某行可能格式不规范from collections import Counter counter Counter() with open(access.log, r, encodingutf-8) as f: for line in f: parts line.split() if parts: counter[parts[0]] 1 for ip, count in counter.most_common(10): print(f{count}\t{ip})之所以强调异常处理是因为笔试阅卷时代码边界处理往往是区分“会写”和“写得好”的关键。3.2 健康检查脚本从零写一个可用的监控工具另外一个高频编程题是“写一个脚本定期检查某个 HTTP 服务是否正常异常时重启服务并告警”。这个题很典型因为它把一个真实的运维需求压缩到了最小规模。我用 Python 写一个简化版本import subprocess import time import requests SERVICE_URL http://127.0.0.1:8080/healthz RESTART_CMD [systemctl, restart, mygame-server] ALERT_CMD [python3, /opt/scripts/send_alert.py, game-server down] def check_health(): try: resp requests.get(SERVICE_URL, timeout5) return resp.status_code 200 except Exception: return False def main(): while True: if not check_health(): subprocess.run(RESTART_CMD) subprocess.run(ALERT_CMD) time.sleep(30) time.sleep(5) if __name__ __main__: main()这道题有几个关键点一定要在代码里体现超时控制。requests.get如果不带timeout可能一直卡住这个在真实环境是致命的。异常捕获。服务可能直接连不上也可能返回 500两种情况都要算“不健康”。重启后的冷却时间。重启完立刻下一次探测大概率还是失败要sleep一段时间。告警动作和重启动作分离。很多同学写出来只有重启没有告警这在笔试里会扣分因为真实的运维体系要求任何变更必须有通知。如果要求用 Shell 写也完全可以#!/bin/bash URLhttp://127.0.0.1:8080/healthz if curl -s -m 5 $URL | grep -q ok; then echo service is healthy else systemctl restart mygame-server curl -s -m 10 -X POST http://alert.example.com/send -d msgmygame-server down fi这里curl -m 5是设置了 5 秒超时grep -q ok是检查返回内容里是否包含健康关键字。很多真实的健康检查不是只看状态码而是会约一个约定的响应体所以要学会这种检查方式。3.3 故障排查题从现象到根因的回答模板简答题里的故障排查最容易出现的问题就是“想到哪写到哪”。比如问“CPU 飙高怎么排查”很多人就写“用 top 看看哪个进程占用高kill 掉”这显然不够。我整理了一个能拿分的标准作答思路第一步先确认问题的真实性和影响范围。用uptime看负载用top看 CPU 使用率确认是 CPU 型负载高还是 I/O 等待型负载高同时确认受影响的机器范围是个例还是集群性问题。第二步定位到具体进程和线程。top -Hp pid查看进程内哪个线程占 CPU如果用了 Java还要用jstack看一下线程栈如果是 Python可以用py-spy dump之类的工具。这一步的产出是“哪个业务逻辑在消耗 CPU”。第三步分析为什么这个逻辑会消耗这么多 CPU。可能是死循环、可能是锁竞争、可能是 GC 频繁、也可能是流量确实涨了。结合代码和最近变更来分析最近有没有发过版本、有没有调整过配置、有没有活动流量进来。第四步止血和恢复。如果是流量涨了考虑扩容或限流如果是代码 bug考虑回滚或者热修复如果是死循环可能要先重启进程临时恢复。第五步复盘和长期优化。比如加监控、加告警、优化代码、做压测。这一步校招生写到“补充监控指标”其实就很加分了。写到卷面上时最好用”1-2-3-4-5“这种分层结构每个层级下面跟一句具体命令或具体措施。阅卷人一眼就能看到你的条理比你写一大段话效果好得多。3.4 安全与配置题给一段配置找隐患很多同学容易忽略一个题型给一段系统配置、脚本或者数据库配置让你找风险点。这种题本质上是考运维经验和安全意识。举个例子给一段 Nginx 配置或者一个数据库账号创建语句让你指出存在的问题。常见的得分点包括权限过大的隐患。比如数据库账号用了root%这种写法等于所有主机都能连还给了所有权限。密码管理问题。比如密码明文写在配置文件里或者使用弱口令。端口暴露问题。比如监听0.0.0.0而不限制来源 IP。日志缺失。没有打开访问日志或错误日志给事后排查带来困难。安全协议弱。比如还在用 TLS 1.0 或者没有开启严格加密传输。这类题考察的不是偏门知识而是你在实际部署时有没有想过“别人会怎么搞坏我的系统”。平时练习时多问问自己如果我拿到这台服务器第一步做什么这个配置有哪些地方会让我找到漏洞坚持这种思维方式写答案就会自然很多。4. 笔试中的高频失分点与应试技巧4.1 书写规范不要在小细节上翻车我复盘过不少同学的笔试答卷发现很多丢分不是因为不会而是因为书写不规范。尤其是代码题最容易出现这些问题缩进混乱。Python 的缩进就是语法的一部分笔试用记事本写缩进一乱代码直接无法运行。变量命名随便。全篇都是a、b、c阅卷人看半天不知道你在干嘛。稍微用ip、count、healthy这种有意义的名字印象分会好很多。没用with打开文件或者打开了不关闭。在真实代码里是资源泄漏在笔试里是经验不足的表现。Shell 脚本开头没写#!/bin/bash或者关键命令没有处理可能的失败情况。这些小问题本身不致命但多个叠加在一起会让人觉得“这个人的代码能力还没形成肌肉记忆”。我建议笔试前两周每天手动敲代码二十分钟专门练手感和格式。4.2 时间分配先抢分后攻坚校招笔试题量通常不小而且经常是选择题、编程题、简答题混在一起。我见过不少同学在选择题上过度纠结在一道 2 分的选择题上磨十分钟结果后面的大题没时间写。我的策略是先花五分钟快速浏览全卷标记出哪些题一眼就会、哪些题要想一下、哪些题完全没有头绪。做的时候严格按“先会做 → 再想想 → 最后蒙”的顺序来。选择题拿不准的先选一个并做个标记不要恋战编程题只要能写出整体框架哪怕有小 bug 也比空白强开放题留十五到二十分钟保证每条思路都能写几句话。还有一个小技巧笔试环境里如果有在线评测代码题提交前一定要检查输入输出格式。很多人逻辑是对的但输出格式多了一个空格或者少了换行评测就判错了这种失分最冤枉。4.3 笔试结束后的复盘把题目变成面试弹药笔试结束不代表任务完成我个人认为复盘才是笔试真正的价值所在。校招的笔试题目往往高度相似你今天在游卡的笔试题里卡住的知识点很可能是两周后另一家公司的原题。所以考完一定要趁记忆还热把题目尽量还原出来然后逐个查漏补缺。复盘时重点做三件事第一整理题目类型分布。看看自己哪类题耗时最多、错误率最高如果发现网络题老是丢分那就集中突击网络如果发现 Shell 题写不顺就专门练脚本。第二把每一道做错的题重新写一遍完整答案。不要只看解析一定要自己重新写一遍写到能默写的程度。第三把印象深刻的题记录下来作为“面试素材”。笔试中出现的基础概念和场景很可能在面试里被追问这时候你如果在复盘时已经深入研究过面试时就等于开了挂。4.4 心态与临场把笔试当一次正常的故障演练最后聊点临场的东西。运维开发笔试有一个特点就是很多题目没有绝对的标准答案特别是设计题和开放题写出来的内容是否贴合真实运维场景阅卷人是能看出来的。所以心态上不要追求“每道题都完美”而是追求“把我会的都展示出来”。遇到完全不会的题不要直接放弃尽量写一点与之相关的理解。比如不会写完整的 K8s 部署流程但你知道 deployment、service、pod 这些概念就把这些概念写上去至少体现你知道这个领域里有哪些东西。校招笔试的容错率其实不低你要做的是尽可能多地让阅卷人看到你的“可培养空间”而不是证明自己已经无所不知。5. 笔试之外的长期主义这场考试只是运维开发路上的第一关5.1 简历上的运维开发项目怎么包装才不虚如果笔试通过了下一步一定是面试。面试里最常问的就是“你做过什么项目”。很多同学的简历上写的是“搭建了个人博客”或者“写了一个校园二手交易系统”不是说这些项目不好而是和运维开发的岗位匹配度太低。招运维开发的人想看到什么想看到你在“让系统更稳定、更自动化”这件事上有过思考和实践。哪怕项目很小比如你给宿舍的同学搭了一个共享 NAS你写了脚本每天自动备份还能监控磁盘剩余空间超过阈值就发邮件提醒——这个项目虽然简单但它完整地体现了一个运维开发者的工作方式发现问题、写工具、自动化、监控告警。面试官完全可以通过这个小项目问出很多东西比如备份策略怎么设计、磁盘监控怎么做、脚本异常怎么处理而这些你只要真的做过就肯定答得出来。5.2 工具链清单每样东西熟练到什么程度才算够我见过一份比较靠谱的校招运维开发工具清单分享给你参考Linux 系统操作熟练能不看文档完成日常运维命令操作。Shell / Python 脚本熟练能独立编写 50 行以上的工具脚本。常用服务Nginx、MySQL、Redis至少知道它们的核心配置项和常见故障。CI/CD了解 GitLab CI 或者 GitHub Actions 的基本流程。监控了解 Prometheus Grafana 的基本概念会写简单的告警规则。容器了解 Docker 基本操作Dockerfile怎么写镜像和容器的关系是什么。云平台如果用过云服务器知道安全组、弹性 IP 的概念。不需要样样精通但你得在笔试和面试里让人相信给你一台服务器和一个需求你能自己想办法搞定。5.3 从校招视角看运维开发的成长路径很多人担心运维开发这个岗位天花板低。说说我自己的看法运维开发成长路径其实很清晰前期是“工具人”写脚本、搭监控、处理故障核心是把自己的手工作业自动化中期是“平台建设者”开始做 CI/CD 平台、日志平台、监控平台、配置中心让整个研发团队的交付效率提升后期是“稳定性负责人”关注 SLO、容量规划、成本控制、风险治理这时候已经不只是技术问题而是业务和管理的交叉了。游戏公司里这个岗位的成长尤其快因为业务场景复杂、故障刺激、对实时性要求高你会在一次次活动高峰和上线发布中快速积累经验。笔试只是这一整个链路的第一关而已。备考时把基础打扎实、把脚本练熟、把排查思路理清楚剩下的就是心态和临场发挥了。最后说点个人体会。我准备这类笔试时最担心的其实是开放题总怕自己“没经历过大规模线上故障”写不出深度。后来发现阅卷人根本不会期待一个校招生有十年经验他们看的是你有没有成熟的思考框架。你能把自己知道的有限经验组织得有条有理就已经赢了大多数人。把每一道题当成一次真实的故障演练来回答别怕写得朴素怕的是没有逻辑。这套思路我自己用了很久考场上也非常管用希望能给你也带来一点帮助。