春招那阵子我投了一圈游戏公司游卡网络就是做《三国杀》的那家杭州公司的运维开发校招岗简历过了之后收到一封笔试邀请牛客网线上答题限时90分钟双机位摄像头全程监控。那段时间我刷了挺多运维开发的笔试经验帖但真正坐到电脑前拿到这套卷子的时候还是踩了几个坑。最近整理面试笔记把这场笔试从头到尾复盘了一遍发现它其实是非常典型的一份游戏公司“运维开发”岗位试卷Linux基础、网络、数据库、Shell/Python脚本能力、容器和发布场景全都有涉及而且和普通后端开发的笔试题风格差别很大。这篇复盘我尽量把题目还原清楚连同每道题背后的考察意图和正确解法一起列出来给后面准备运维开发方向校招的同学做个参考。1. 从岗位JD反推笔试题型游卡这场笔试的考察逻辑1.1 游卡运维开发到底是干什么的游卡网络这个名字不混游戏圈的人可能不太熟但一提《三国杀》基本都知道。这家公司以卡牌桌游起家后来扩展到PC端、移动端和页游多个游戏项目并行运营。游戏业务的运维和普通互联网业务运维有个明显区别区服多、版本迭代快、在线人数波动大而且“开服”“合服”“跨服活动”这类操作特别频繁。游卡招聘页面上“运维开发”岗位的描述核心职责大概是这几块负责游戏服务器的部署、变更、容量规划和日常巡检建设监控告警、日志采集、故障定位等自动化运维平台开发持续集成/持续部署相关的工具链支撑研发快速迭代参与运维规范制定和稳定性保障。所以这个岗位本质上不是纯运维而是“运维开发”的复合型岗位既要懂服务器和网络又要能写代码去解决重复性的人工操作。这一点直接决定了笔试题的考察方向——光是背命令不行光是刷算法题也不够两者得结合起来。1.2 笔试平台和考试流程的基本盘我记得是2024年3月中旬收到的邮件通知我3天后参加统一笔试。线上笔试用的牛客网登录之后有防作弊页面要求电脑摄像头打开同时手机扫一个二维码放在斜后方作为第二视角。整个考试时间90分钟系统到时自动交卷中途不能切出页面。这里要提醒一句考试环境一定要提前找个安静的房间我当时调试摄像头就折腾了好几分钟直接压缩了答题时间。从题量上看整张卷子分了四个部分题型题量分值占比我的实际用时单选题20题约30%25分钟多选题10题约20%15分钟编程题2题约30%30分钟简答/场景设计题2题约20%20分钟这个比例对运维开发岗来说非常典型选择题基础覆盖面广编程题考察代码落地能力场景题考察真遇到故障时能不能拿出解决方案。1.3 从考点分布看公司要什么样的人我当时做完第一反应是“怎么这么多命令题”后来复盘才发现每道题背后都有指向性。整理下来考点大概可以分成这样几类考察模块具体知识点对应岗位能力Linux基础文件查找、权限、进程管理、定时任务日常巡检和问题排查网络基础TCP三次握手、HTTP状态码、DNS解析网络故障定位数据库SQL查询、索引、慢查询优化游戏数据查询与报表脚本编程Shell文本处理、Python小工具自动化运维工具开发容器与发布Docker镜像、灰度发布、回滚策略版本发布与稳定性保障算法思维限流、并发控制、TopN统计平台开发中的基础能力可以明显感觉到这套卷子不是隨随便便从算法题库里抽的而是围绕“游戏服务器运维日常工作”来设计的。选择题里大量出现“某命令在什么场景下使用”编程题里直接让你处理游戏日志场景题问的是“某区服出现大面积掉线怎么排查”。所以准备这类笔试光刷LeetCode不够还得把Linux命令和运维场景摸熟。2. 真题逐题复盘选择题、编程题、场景题分别怎么答2.1 单选题看似送分实际全是细节选择题一共20道覆盖范围很广。我印象比较深的有下面几道大意还原一下第一道考的是Linux文件查找命令。题目问需要在 /data/log 目录下递归查找最近7天内被修改过、且以 .log 结尾的文件下面哪条命令可以实现选项里有find /data/log -mtime -7 -name *.log、find /data/log -mtime 7 -name *.log、find /data/log -atime -7 -name *.log、find /data/log -ctime -7 -name *.log。这道题有两个坑一是-mtime和-atime、-ctime的区别。-mtime是文件内容被修改的时间-atime是访问时间-ctime是文件元数据变化的时间。日常排查通常关心“内容什么时间改的”所以选-mtime。二是-7和7的区别-7表示最近7天以内7表示7天以前。所以正确答案是find /data/log -mtime -7 -name *.log。第二道考网络。题目大概意思是客户端和服务器建立TCP连接时客户端收到服务端返回的SYN-ACK但没有再次发出ACK最可能的原因是什么选项有服务端全连接队列满、客户端防火墙丢弃了确认包、网络延迟过高、服务器进程崩溃。这道题考察对TCP三次握手和内核连接队列的理解。三次握手过程中服务端收到SYN后会进入 SYN-ACK 状态如果服务端的全连接队列accept队列已满内核可能丢弃SYN或SYN-ACK但题目说的是“客户端收到了SYN-ACK却没发出ACK”那问题更可能在客户端侧。客户端没发出ACK要么是防火墙把ACK包丢了要么是客户端进程状态异常。结合游戏场景如果玩家大量涌入服务端 accept 队列满了会出现连接建立缓慢的情况但如果“收到SYN-ACK不发ACK”常见诱因是客户端本地出方向丢包或者安全软件拦截。这道题正确选项是“客户端防火墙丢弃了确认包”。第三道是数据库索引相关的。题目问一张游戏玩家充值表查询语句为SELECT uid, SUM(amount) FROM recharge WHERE game_id 3 AND pay_time BETWEEN 2024-03-01 AND 2024-03-31 GROUP BY uid ORDER BY SUM(amount) DESC;最适合建立什么索引选项包括(pay_time)、(game_id, pay_time)、(uid, amount)、(game_id, uid)。这个考点是联合索引的最左前缀原则。WHERE 里先用game_id等值过滤再用pay_time范围过滤所以联合索引应该把等值查询字段放前面范围字段放后面也就是(game_id, pay_time)。如果只建(pay_time)索引game_id的过滤还得回表如果建(uid, amount)索引查询用不上。选(game_id, pay_time)。选择题里面还有不少考命令细节的比如awk默认分隔符是什么空格、grep -E和egrep的关系、crontab表达式*/5 * * * *的含义每5分钟执行一次等等。这类题没有技巧纯粹靠平时积累特别是awk、sed、sort、uniq这些高频命令一定要做到看到语法就能反应出执行结果。2.2 多选题少选漏选都失分规则比内容更重要多选题10道难度明显上来了。我记得有一个题是关于Docker镜像分层的描述正确的有哪些选项里有“镜像是只读的”“容器层保存运行时变更”“不同镜像可以共享相同的基础层”“每次构建都会在基础层上新增一层”。这个题的考点是Docker的联合文件系统UnionFS和镜像分层机制。Docker镜像由多个只读层组成容器在镜像之上加一个可写层所有对容器的修改都发生在可写层不同镜像如果基于同一个基础镜像可以共享下面的只读层所以占用空间更小每次 Dockerfile 指令执行都会生成一个新的层。四个选项描述全对这就是全选。说实话这种题如果对Docker原理只有“会用docker run”的程度很容易漏选“共享基础层”这个点。还有一道是关于HTTP状态码的。题目问以下哪些状态码表示客户端错误选项有 301、400、401、502。这个比较容易400和401是客户端错误301是重定向502是网关错误。多选容易错的地方在于很多人看到401会犹豫是不是“未认证”算服务端问题其实401、403都是客户端类错误不属于服务端。对我个人来说多选策略是“拿不准的不要多选”。因为很多平台多选题的计分规则是全部选对得满分选对但不全得一半分选错一个得零分。所以拿不准的选项宁可不选保住保底分。我当时有一道关于Kubernetes Pod重启策略的题选项里有一个“DaemonSet管理的Pod不能设置restartPolicy: Always”我犹豫了一下没选后来查资料确认这个选项是错的算是躲过一劫。2.3 编程题不是算法题是“用代码解决运维问题”编程题两道都不算传统意义上的算法题更像是实际工作场景中的小工具开发。这一点和纯后端开发的笔试题有本质区别。第一道题大概是写一个Python函数实现一个简单的限流装饰器要求每秒最多允许调用N次超过限制的调用直接拒绝并抛出异常或返回False。第二道题是给定一个 nginx 或游戏服务器的访问日志文件路径写Shell脚本统计访问次数最多的前10个IP并输出IP和次数按次数降序排列。看到这两道题我就明白了游卡想招的人不是“懂运维概念”的人而是“能自己写工具解决运维问题”的人。限流是服务端开发里非常常见的需求尤其是游戏登录、活动领奖、API调用这些场景防止刷接口和雪崩日志统计则是运维日常分析最基础的操作Top IP、Top URL、接口错误率全都要靠这种统计能力。这也就解释了为什么笔试时间90分钟但编程题只有两题。因为题目本身不难难的是在有限时间内写得对、写得规范。下面我会专门写一节把这两道题的完整解答思路展开讲。2.4 简答/场景题不要求唯一答案但一定要有排查链路简答题两道都是开放式的。第一道是跑着的游戏服务出现大量玩家掉线客服反馈“某大区玩家集中掉线”你怎么排查请写出完整的排查思路。第二道是项目组要发一个新版本这个版本涉及玩家背包系统的数据库表结构变更你怎么设计发布和回滚方案这种题没有标准答案但评分点其实非常明确有没有排查顺序、有没有具体命令、有没有考虑到回滚。我当时的回答思路是分层的先确认影响面是单个服务器还是整个区再看网络链路负载均衡节点、带宽、防火墙然后看业务进程CPU、内存、句柄数、日志最后看数据库连接数、慢查询、锁。每一层都给出对应的排查命令比如top、ss -lntp、dmesg、tail -f app.log。虽然不一定全对但至少让面试官看到你有“链路意识”。第二道涉及数据库表结构变更的发布我回答的是“灰度备份脚本化”三件套先把表结构变更写成可重复执行的SQL脚本执行前备份全表然后选一个低峰期的小区做灰度发布观察日志和监控指标确认没问题后逐批扩大到其他区最后如果出问题利用备份做回滚回滚脚本也提前准备好。这里有个游戏行业的特殊性——玩家数据不能丢所以任何涉及数据库变更的操作回滚方案必须在发布前就验证过而不是出事了才想。3. 最值得细说的三道题答案背后的原理拆解3.1 令牌桶限流为什么选它而不是计数器或漏桶限流那题我用的Python装饰器实现可以先看代码import time import threading class TokenBucket: def __init__(self, rate, capacity): self.rate rate # 每秒补充令牌数 self.capacity capacity # 桶容量 self.tokens capacity # 初始装满 self.last_refill time.monotonic() self.lock threading.Lock() def acquire(self): with self.lock: now time.monotonic() elapsed now - self.last_refill self.tokens min(self.capacity, self.tokens elapsed * self.rate) self.last_refill now if self.tokens 1: self.tokens - 1 return True return False def rate_limit(rate, capacityNone): if capacity is None: capacity rate bucket TokenBucket(rate, capacity) def decorator(func): def wrapper(*args, **kwargs): if not bucket.acquire(): raise RuntimeError(rate limit exceeded) return func(*args, **kwargs) return wrapper return decorator # 使用示例每秒最多调用5次 rate_limit(rate5, capacity5) def handle_login(uid): print(fhandle login: {uid})为什么选令牌桶而不是计数器或者漏桶这里有个很重要的区别计数器限流最简单每秒钟重置一次计数。但它的缺点是有“临界突变”问题比如每秒限制100次有人在前一秒最后100ms打满100次后一秒前100ms又打满100次实际200ms内就打了200次服务端还是会被冲击。漏桶算法是匀速出水不管进来多猛处理速度恒定。适合保护下游但缺点是突发流量全部被削平不够灵活。令牌桶算法允许一定程度的突发桶里攒了多少令牌就能一次性消耗多少相当于给业务留了“余量”。游戏场景下单用户登录接口是典型的高并发突发场景平时请求量不高但活动开抢的那一瞬间流量会猛增。如果限流器不允许突发正常玩家的请求也会被误伤允许一定突发就能接住前几秒的峰值流量。所以令牌桶最适合这类场景。代码里我用了time.monotonic()而不是time.time()这也是一个容易被问到的细节。time.time()返回的是墙上时钟如果系统时间被NTP校准或者被手动修改可能出现时间倒退导致限流计算错误time.monotonic()不受系统时间调整的影响只计算单调递增的时间差适合做这种“时长差”的计算。另外有个边界条件容易被忽略多线程环境下令牌桶的计数操作要加锁。我用了threading.Lock保证acquire方法的原子性。如果漏掉锁并发调用时可能出现两个线程同时通过限流导致限流失效。笔试阅卷时这个锁就是区分“能跑”和“写得专业”的关键细节。3.2 日志统计Top IPShell一行流和性能思考第二道编程题是统计日志Top IP我当时写的是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10如果日志格式的第一列是IP这段命令可以一次完成统计。整个管道拆开来看awk {print $1}取出日志每行的第一个字段也就是客户端IPsort把相同的IP排在一起。注意先要排序uniq只能统计相邻的重复行uniq -c统计每行重复出现次数sort -rn按统计次数逆向排序-n是按数字而不是按字典序-r是降序head -10取前10条。这道题真正的坑有两个。第一个是有些人会忘记先sort直接uniq -c结果发现统计出来的全是1因为uniq只合并相邻行。第二个是sort -rn里必须加-n如果不加假设有两条记录分别被访问了9次和100次字典序排列下100会排在9前面最终Top10结果就错了。如果日志文件特别大比如几十GB一行管道命令也能跑但sort是内存外存混合排序速度可能比较慢。更高效的做法是用awk先做分组计数再排序输出。比如awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10awk里用数组做关联计数只遍历一遍文件避免了大文件全局排序带来的额外IO开销。当然如果文件大到连awk数组都放不下那就得考虑用更重的方案比如mapreduce或者把日志按IP哈希分片。笔试题一般不会考到这么大但能写出这个优化点会加分。3.3 数据库表结构变更的发布方案游戏行业的“数据心头肉”这道简答题我答得比较有条理核心思路是任何涉及线上数据变更的操作都必须围绕“可回滚、可灰度、可监控”来设计。具体来说我的方案分成四步。第一步是“备份”正式操作前在变更涉及的数据库实例上做一次逻辑备份或物理备份具体用mysqldump还是其他备份工具看数据量。同时要把变更SQL脚本本身也纳入版本管理保证任何一次操作都能追溯。第二步是“预处理”如果表很大直接ALTER TABLE会锁表导致游戏卡顿甚至停服。常见做法是用pt-online-schema-change这类工具做在线DDL或者手动在备库先执行变更再通过主从切换把流量切过去。第三步是“灰度”先找一个测试区或者人少的旧区执行变更观察监控指标和日志确认没异常后再逐步推进到其他区。游戏公司通常有几十上百个区不能一口气全量变更。第四步是“回滚预案”如果变更后出现了数据异常需要能快速还原到变更前的状态。这时候最理想的情况是变更前已经保留了旧表变更失败时直接改表名切换回来。但要注意回滚操作本身也可能引入新的问题所以回滚脚本要提前测一遍不能发布时才发现回滚脚本是坏的。这个方案里最容易被应届生忽略的是“灰度”和“回滚”之间的配合。很多人答发布方案只会说“备份执行重启”完全没提灰度观察更没提回滚。但面试官和阅卷人最想看到的恰恰就是这两点——因为它们意味着你经历过线上事故脑子里有一根“随时准备出事”的弦。4. 这些笔试中的“隐藏坑”是应届生最容易丢分的地方4.1 在线笔试环境本身就是一个坑牛客的在线IDE其实挺好用但和本地开发环境还是有区别。第一是没有自动补全Python和Shell都不会提示函数签名所以平时写代码不能太依赖IDE尤其是os、sys、re、collections这些标准库的常用函数得记牢。第二是Shell脚本题没有真实的日志文件可以验证只能靠“默写”命令这就要求平时真的在终端里敲过而不是只看过命令的说明。第三是有摄像头监控不能像在家做题那样随意查资料所以基础知识必须当场反应得出来。我建议准备阶段就刻意练习“裸写”能力不用IDE补全直接在一个纯文本编辑器里写Python和Shell然后放到终端跑一遍验证结果。这样做几次之后笔试时的手感和用了IDE是一样的。4.2 命令细节失分不是不会是记岔了我复盘错题的时候发现选择题里丢分最多的往往是那些“看着眼熟但记不精确”的命令参数。比如find的-mtime、-newer、-exec和-ok的区别tar的-z、-J、-v组合grep的-E、-w、-c选项awk的-F指定分隔符等等。这里有个笨办法我觉得很有效把笔试高频命令整理成一张速查表每个命令只记2到3个最常见的用法然后每天在终端里跑一遍。比如find就记查文件、按时间过滤、配合-exec批量操作sed就记替换和按行删除awk就记打印列、条件过滤和分组统计。不需要把每个命令的所有参数都背下来但高频组合一定要形成肌肉记忆。还有一个容易忽略的点Shell脚本题的格式问题。有些线上OJ对Shell脚本的检查方式是“输出与预期一致”如果你的命令输出多了个空格或者空行可能被判错。写完命令后可以在心里模拟一遍每一步产生的输出格式确保没有多余的空白。4.3 多选漏选规则别因小失大前面提到多选计分规则这里再强调一遍。游戏公司校招笔试的多选题往往不确定选错是否倒扣分但大多数是“选错零分、少选按比例得分”。我当时定的策略是5个选项里只要有一个选项“不确认”就只选最确定的两个放弃那些模糊项。事实证明这个策略帮我保住了不少分因为有些多选题本身就有4个正确选项结果我只选了2个但至少没归零。当然这个策略也要分情况。如果题目是那种一眼就知道所有选项都对的比如“关于TCP三次握手的正确描述”那就全选不用犹豫。关键是识别“模糊判断题”——你对某个选项的知识点只记得“好像对”但说不出原理这种就果断放弃。4.4 编程题的时间分配先保一题AC再冲刺第二题我写限流装饰器那题花了差不多20分钟占了编程题的大部分时间。之所以敢这么花是因为我把时间管理的优先级定得很清楚编程题性价比最高先做完选择题因为分值分散后面用剩余时间快速推进。具体到编程题本身我的建议是先保证第一题完全正确再去看第二题。两道题如果都半吊子不如一道题完整AC加一道题写出核心逻辑拿部分分。笔试阅卷通常按测试用例给分部分用例过了也有分所以哪怕时间不够也要把主流程写出来别留在脑子里。我当时的策略是看到限流题先写核心类TokenBucket保证单测场景能过日志题用一行管道命令直接过关。写完再回头补注释和边界条件。这个节奏让我在90分钟内把所有题都覆盖到了没有出现交白卷的部分。5. 笔试之后的复盘从“会做题”到“面试能讲”5.1 我给自己做了一次“错题归因”笔试结束当天晚上我没有直接躺平而是趁热打铁把整张卷子回忆了一遍按照“完全不会”“概念模糊”“粗心失误”“时间不够没做”分了四类。结果发现粗心失误是最多的——不是知识盲区而是考试紧张读题不仔细导致看错了条件。其中最典型的例子是那题find -mtime 7和-mtime -7的选择我第一遍读题觉得是“找7天前的文件”差点选7后来反复读题干才发现写的是“最近7天内”。这种丢分非常可惜因为它不是“不会”而是“没看清”。复盘的意义就是把这些非知识性失分单独拎出来下次考试时强制自己在选项前先复述一遍题目的核心要求再下笔。5.2 笔试题是会“长进”面试题里的游卡笔试通过之后紧接着就是面试。面试官盯着简历问项目经验之外还会顺着笔试题往下问。我最深刻的一个感受是笔试不是考完就完了你写在卷子上的每一个答案都可能成为面试官追问的起点。比如面试官问我“你写的限流装饰器有没有考虑过分布式环境下多个实例怎么办”这个问题其实就是从笔试那道编程题拓展出来的。单机令牌桶用threading.Lock没问题但部署多个游戏服、多个API节点之后每个节点的限流状态是独立的玩家的请求被负载均衡分发到不同节点总流量可能变成N倍。要解决分布式限流要么用Redis的INCR 过期时间做滑动窗口要么用Lua脚本实现令牌桶的原子操作。虽然面试时我答得不算完美但至少笔试里“我写过限流器”这个事实给了面试官一个引子也给了我一个展示思考深度的机会。所以说准备笔试不能只看“能不能做出来”还要想“面试官可能会从这道题延伸出什么”。每做完一道有代表性的题就额外想一想“分布式版本怎么做”“压力再大一倍怎么办”“数据不一致怎么处理”这种延展性思考才是从笔试到面试无缝切换的关键。5.3 给下一届考生的运维开发笔试备战清单如果让我把经验浓缩成几条可执行的动作大概是这样的第一Linux命令每天练半小时。不用背大全重点覆盖文件查找、文本处理、进程管理、网络连接、权限、定时任务这六类。每个命令至少要有一次“自己动手排查真实文件”的经验而不是只在教程里看输出样例。第二Shell和Python二选一练熟。运维开发笔试一定会有脚本题。Shell适合快速处理文本和管道任务Python适合写带逻辑的小工具和算法题。建议Shell做到能写出Top日志统计、批量备份、进程检查这类脚本Python做到能实现限流、并发任务分发、日志解析这类小模块。第三网络和数据库原理要吃透。TCP三次握手、四次挥手、TCP粘包、HTTP状态码、DNS解析流程这些是选择题高发区。数据库则重点掌握索引原理、联合索引最左前缀、慢查询分析、GROUP BY和ORDER BY的执行逻辑。第四场景题要形成自己的“排查SOP”。面试官不看你能背多少命令而是看你能不能形成一套稳定的排查思路。我总结的通用链路是确认影响范围 → 检查网络链路 → 检查系统层资源 → 检查业务进程 → 检查日志 → 检查数据库 → 检查依赖服务。遇到任何故障按照这个顺序走不会乱。第五笔试环境要提前适应。至少完整模拟一次牛客网在线笔试流程限时、无IDE补全、相机开着、只能用手机当草稿。这些客观限制不提前适应考试时会额外消耗很多精力。复盘完这场笔试我最大的感受其实是运维开发这个岗位的笔试筛选的就是那些“既蹲得了机房也写得了代码”的人。命令背得熟说明你肯在日常运维里下功夫代码写得规范说明你有工程化思维场景题答得有层次说明你脑子里装过真实故障。这三样东西没有哪一样是可以靠考前突击三天就速成的都得在日常学习里一点点积累。希望这份复盘能帮后面准备运维开发校招的同学少走一些弯路。
游卡网络运维开发校招笔试复盘：从Linux到容器与场景设计
春招那阵子我投了一圈游戏公司游卡网络就是做《三国杀》的那家杭州公司的运维开发校招岗简历过了之后收到一封笔试邀请牛客网线上答题限时90分钟双机位摄像头全程监控。那段时间我刷了挺多运维开发的笔试经验帖但真正坐到电脑前拿到这套卷子的时候还是踩了几个坑。最近整理面试笔记把这场笔试从头到尾复盘了一遍发现它其实是非常典型的一份游戏公司“运维开发”岗位试卷Linux基础、网络、数据库、Shell/Python脚本能力、容器和发布场景全都有涉及而且和普通后端开发的笔试题风格差别很大。这篇复盘我尽量把题目还原清楚连同每道题背后的考察意图和正确解法一起列出来给后面准备运维开发方向校招的同学做个参考。1. 从岗位JD反推笔试题型游卡这场笔试的考察逻辑1.1 游卡运维开发到底是干什么的游卡网络这个名字不混游戏圈的人可能不太熟但一提《三国杀》基本都知道。这家公司以卡牌桌游起家后来扩展到PC端、移动端和页游多个游戏项目并行运营。游戏业务的运维和普通互联网业务运维有个明显区别区服多、版本迭代快、在线人数波动大而且“开服”“合服”“跨服活动”这类操作特别频繁。游卡招聘页面上“运维开发”岗位的描述核心职责大概是这几块负责游戏服务器的部署、变更、容量规划和日常巡检建设监控告警、日志采集、故障定位等自动化运维平台开发持续集成/持续部署相关的工具链支撑研发快速迭代参与运维规范制定和稳定性保障。所以这个岗位本质上不是纯运维而是“运维开发”的复合型岗位既要懂服务器和网络又要能写代码去解决重复性的人工操作。这一点直接决定了笔试题的考察方向——光是背命令不行光是刷算法题也不够两者得结合起来。1.2 笔试平台和考试流程的基本盘我记得是2024年3月中旬收到的邮件通知我3天后参加统一笔试。线上笔试用的牛客网登录之后有防作弊页面要求电脑摄像头打开同时手机扫一个二维码放在斜后方作为第二视角。整个考试时间90分钟系统到时自动交卷中途不能切出页面。这里要提醒一句考试环境一定要提前找个安静的房间我当时调试摄像头就折腾了好几分钟直接压缩了答题时间。从题量上看整张卷子分了四个部分题型题量分值占比我的实际用时单选题20题约30%25分钟多选题10题约20%15分钟编程题2题约30%30分钟简答/场景设计题2题约20%20分钟这个比例对运维开发岗来说非常典型选择题基础覆盖面广编程题考察代码落地能力场景题考察真遇到故障时能不能拿出解决方案。1.3 从考点分布看公司要什么样的人我当时做完第一反应是“怎么这么多命令题”后来复盘才发现每道题背后都有指向性。整理下来考点大概可以分成这样几类考察模块具体知识点对应岗位能力Linux基础文件查找、权限、进程管理、定时任务日常巡检和问题排查网络基础TCP三次握手、HTTP状态码、DNS解析网络故障定位数据库SQL查询、索引、慢查询优化游戏数据查询与报表脚本编程Shell文本处理、Python小工具自动化运维工具开发容器与发布Docker镜像、灰度发布、回滚策略版本发布与稳定性保障算法思维限流、并发控制、TopN统计平台开发中的基础能力可以明显感觉到这套卷子不是隨随便便从算法题库里抽的而是围绕“游戏服务器运维日常工作”来设计的。选择题里大量出现“某命令在什么场景下使用”编程题里直接让你处理游戏日志场景题问的是“某区服出现大面积掉线怎么排查”。所以准备这类笔试光刷LeetCode不够还得把Linux命令和运维场景摸熟。2. 真题逐题复盘选择题、编程题、场景题分别怎么答2.1 单选题看似送分实际全是细节选择题一共20道覆盖范围很广。我印象比较深的有下面几道大意还原一下第一道考的是Linux文件查找命令。题目问需要在 /data/log 目录下递归查找最近7天内被修改过、且以 .log 结尾的文件下面哪条命令可以实现选项里有find /data/log -mtime -7 -name *.log、find /data/log -mtime 7 -name *.log、find /data/log -atime -7 -name *.log、find /data/log -ctime -7 -name *.log。这道题有两个坑一是-mtime和-atime、-ctime的区别。-mtime是文件内容被修改的时间-atime是访问时间-ctime是文件元数据变化的时间。日常排查通常关心“内容什么时间改的”所以选-mtime。二是-7和7的区别-7表示最近7天以内7表示7天以前。所以正确答案是find /data/log -mtime -7 -name *.log。第二道考网络。题目大概意思是客户端和服务器建立TCP连接时客户端收到服务端返回的SYN-ACK但没有再次发出ACK最可能的原因是什么选项有服务端全连接队列满、客户端防火墙丢弃了确认包、网络延迟过高、服务器进程崩溃。这道题考察对TCP三次握手和内核连接队列的理解。三次握手过程中服务端收到SYN后会进入 SYN-ACK 状态如果服务端的全连接队列accept队列已满内核可能丢弃SYN或SYN-ACK但题目说的是“客户端收到了SYN-ACK却没发出ACK”那问题更可能在客户端侧。客户端没发出ACK要么是防火墙把ACK包丢了要么是客户端进程状态异常。结合游戏场景如果玩家大量涌入服务端 accept 队列满了会出现连接建立缓慢的情况但如果“收到SYN-ACK不发ACK”常见诱因是客户端本地出方向丢包或者安全软件拦截。这道题正确选项是“客户端防火墙丢弃了确认包”。第三道是数据库索引相关的。题目问一张游戏玩家充值表查询语句为SELECT uid, SUM(amount) FROM recharge WHERE game_id 3 AND pay_time BETWEEN 2024-03-01 AND 2024-03-31 GROUP BY uid ORDER BY SUM(amount) DESC;最适合建立什么索引选项包括(pay_time)、(game_id, pay_time)、(uid, amount)、(game_id, uid)。这个考点是联合索引的最左前缀原则。WHERE 里先用game_id等值过滤再用pay_time范围过滤所以联合索引应该把等值查询字段放前面范围字段放后面也就是(game_id, pay_time)。如果只建(pay_time)索引game_id的过滤还得回表如果建(uid, amount)索引查询用不上。选(game_id, pay_time)。选择题里面还有不少考命令细节的比如awk默认分隔符是什么空格、grep -E和egrep的关系、crontab表达式*/5 * * * *的含义每5分钟执行一次等等。这类题没有技巧纯粹靠平时积累特别是awk、sed、sort、uniq这些高频命令一定要做到看到语法就能反应出执行结果。2.2 多选题少选漏选都失分规则比内容更重要多选题10道难度明显上来了。我记得有一个题是关于Docker镜像分层的描述正确的有哪些选项里有“镜像是只读的”“容器层保存运行时变更”“不同镜像可以共享相同的基础层”“每次构建都会在基础层上新增一层”。这个题的考点是Docker的联合文件系统UnionFS和镜像分层机制。Docker镜像由多个只读层组成容器在镜像之上加一个可写层所有对容器的修改都发生在可写层不同镜像如果基于同一个基础镜像可以共享下面的只读层所以占用空间更小每次 Dockerfile 指令执行都会生成一个新的层。四个选项描述全对这就是全选。说实话这种题如果对Docker原理只有“会用docker run”的程度很容易漏选“共享基础层”这个点。还有一道是关于HTTP状态码的。题目问以下哪些状态码表示客户端错误选项有 301、400、401、502。这个比较容易400和401是客户端错误301是重定向502是网关错误。多选容易错的地方在于很多人看到401会犹豫是不是“未认证”算服务端问题其实401、403都是客户端类错误不属于服务端。对我个人来说多选策略是“拿不准的不要多选”。因为很多平台多选题的计分规则是全部选对得满分选对但不全得一半分选错一个得零分。所以拿不准的选项宁可不选保住保底分。我当时有一道关于Kubernetes Pod重启策略的题选项里有一个“DaemonSet管理的Pod不能设置restartPolicy: Always”我犹豫了一下没选后来查资料确认这个选项是错的算是躲过一劫。2.3 编程题不是算法题是“用代码解决运维问题”编程题两道都不算传统意义上的算法题更像是实际工作场景中的小工具开发。这一点和纯后端开发的笔试题有本质区别。第一道题大概是写一个Python函数实现一个简单的限流装饰器要求每秒最多允许调用N次超过限制的调用直接拒绝并抛出异常或返回False。第二道题是给定一个 nginx 或游戏服务器的访问日志文件路径写Shell脚本统计访问次数最多的前10个IP并输出IP和次数按次数降序排列。看到这两道题我就明白了游卡想招的人不是“懂运维概念”的人而是“能自己写工具解决运维问题”的人。限流是服务端开发里非常常见的需求尤其是游戏登录、活动领奖、API调用这些场景防止刷接口和雪崩日志统计则是运维日常分析最基础的操作Top IP、Top URL、接口错误率全都要靠这种统计能力。这也就解释了为什么笔试时间90分钟但编程题只有两题。因为题目本身不难难的是在有限时间内写得对、写得规范。下面我会专门写一节把这两道题的完整解答思路展开讲。2.4 简答/场景题不要求唯一答案但一定要有排查链路简答题两道都是开放式的。第一道是跑着的游戏服务出现大量玩家掉线客服反馈“某大区玩家集中掉线”你怎么排查请写出完整的排查思路。第二道是项目组要发一个新版本这个版本涉及玩家背包系统的数据库表结构变更你怎么设计发布和回滚方案这种题没有标准答案但评分点其实非常明确有没有排查顺序、有没有具体命令、有没有考虑到回滚。我当时的回答思路是分层的先确认影响面是单个服务器还是整个区再看网络链路负载均衡节点、带宽、防火墙然后看业务进程CPU、内存、句柄数、日志最后看数据库连接数、慢查询、锁。每一层都给出对应的排查命令比如top、ss -lntp、dmesg、tail -f app.log。虽然不一定全对但至少让面试官看到你有“链路意识”。第二道涉及数据库表结构变更的发布我回答的是“灰度备份脚本化”三件套先把表结构变更写成可重复执行的SQL脚本执行前备份全表然后选一个低峰期的小区做灰度发布观察日志和监控指标确认没问题后逐批扩大到其他区最后如果出问题利用备份做回滚回滚脚本也提前准备好。这里有个游戏行业的特殊性——玩家数据不能丢所以任何涉及数据库变更的操作回滚方案必须在发布前就验证过而不是出事了才想。3. 最值得细说的三道题答案背后的原理拆解3.1 令牌桶限流为什么选它而不是计数器或漏桶限流那题我用的Python装饰器实现可以先看代码import time import threading class TokenBucket: def __init__(self, rate, capacity): self.rate rate # 每秒补充令牌数 self.capacity capacity # 桶容量 self.tokens capacity # 初始装满 self.last_refill time.monotonic() self.lock threading.Lock() def acquire(self): with self.lock: now time.monotonic() elapsed now - self.last_refill self.tokens min(self.capacity, self.tokens elapsed * self.rate) self.last_refill now if self.tokens 1: self.tokens - 1 return True return False def rate_limit(rate, capacityNone): if capacity is None: capacity rate bucket TokenBucket(rate, capacity) def decorator(func): def wrapper(*args, **kwargs): if not bucket.acquire(): raise RuntimeError(rate limit exceeded) return func(*args, **kwargs) return wrapper return decorator # 使用示例每秒最多调用5次 rate_limit(rate5, capacity5) def handle_login(uid): print(fhandle login: {uid})为什么选令牌桶而不是计数器或者漏桶这里有个很重要的区别计数器限流最简单每秒钟重置一次计数。但它的缺点是有“临界突变”问题比如每秒限制100次有人在前一秒最后100ms打满100次后一秒前100ms又打满100次实际200ms内就打了200次服务端还是会被冲击。漏桶算法是匀速出水不管进来多猛处理速度恒定。适合保护下游但缺点是突发流量全部被削平不够灵活。令牌桶算法允许一定程度的突发桶里攒了多少令牌就能一次性消耗多少相当于给业务留了“余量”。游戏场景下单用户登录接口是典型的高并发突发场景平时请求量不高但活动开抢的那一瞬间流量会猛增。如果限流器不允许突发正常玩家的请求也会被误伤允许一定突发就能接住前几秒的峰值流量。所以令牌桶最适合这类场景。代码里我用了time.monotonic()而不是time.time()这也是一个容易被问到的细节。time.time()返回的是墙上时钟如果系统时间被NTP校准或者被手动修改可能出现时间倒退导致限流计算错误time.monotonic()不受系统时间调整的影响只计算单调递增的时间差适合做这种“时长差”的计算。另外有个边界条件容易被忽略多线程环境下令牌桶的计数操作要加锁。我用了threading.Lock保证acquire方法的原子性。如果漏掉锁并发调用时可能出现两个线程同时通过限流导致限流失效。笔试阅卷时这个锁就是区分“能跑”和“写得专业”的关键细节。3.2 日志统计Top IPShell一行流和性能思考第二道编程题是统计日志Top IP我当时写的是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10如果日志格式的第一列是IP这段命令可以一次完成统计。整个管道拆开来看awk {print $1}取出日志每行的第一个字段也就是客户端IPsort把相同的IP排在一起。注意先要排序uniq只能统计相邻的重复行uniq -c统计每行重复出现次数sort -rn按统计次数逆向排序-n是按数字而不是按字典序-r是降序head -10取前10条。这道题真正的坑有两个。第一个是有些人会忘记先sort直接uniq -c结果发现统计出来的全是1因为uniq只合并相邻行。第二个是sort -rn里必须加-n如果不加假设有两条记录分别被访问了9次和100次字典序排列下100会排在9前面最终Top10结果就错了。如果日志文件特别大比如几十GB一行管道命令也能跑但sort是内存外存混合排序速度可能比较慢。更高效的做法是用awk先做分组计数再排序输出。比如awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10awk里用数组做关联计数只遍历一遍文件避免了大文件全局排序带来的额外IO开销。当然如果文件大到连awk数组都放不下那就得考虑用更重的方案比如mapreduce或者把日志按IP哈希分片。笔试题一般不会考到这么大但能写出这个优化点会加分。3.3 数据库表结构变更的发布方案游戏行业的“数据心头肉”这道简答题我答得比较有条理核心思路是任何涉及线上数据变更的操作都必须围绕“可回滚、可灰度、可监控”来设计。具体来说我的方案分成四步。第一步是“备份”正式操作前在变更涉及的数据库实例上做一次逻辑备份或物理备份具体用mysqldump还是其他备份工具看数据量。同时要把变更SQL脚本本身也纳入版本管理保证任何一次操作都能追溯。第二步是“预处理”如果表很大直接ALTER TABLE会锁表导致游戏卡顿甚至停服。常见做法是用pt-online-schema-change这类工具做在线DDL或者手动在备库先执行变更再通过主从切换把流量切过去。第三步是“灰度”先找一个测试区或者人少的旧区执行变更观察监控指标和日志确认没异常后再逐步推进到其他区。游戏公司通常有几十上百个区不能一口气全量变更。第四步是“回滚预案”如果变更后出现了数据异常需要能快速还原到变更前的状态。这时候最理想的情况是变更前已经保留了旧表变更失败时直接改表名切换回来。但要注意回滚操作本身也可能引入新的问题所以回滚脚本要提前测一遍不能发布时才发现回滚脚本是坏的。这个方案里最容易被应届生忽略的是“灰度”和“回滚”之间的配合。很多人答发布方案只会说“备份执行重启”完全没提灰度观察更没提回滚。但面试官和阅卷人最想看到的恰恰就是这两点——因为它们意味着你经历过线上事故脑子里有一根“随时准备出事”的弦。4. 这些笔试中的“隐藏坑”是应届生最容易丢分的地方4.1 在线笔试环境本身就是一个坑牛客的在线IDE其实挺好用但和本地开发环境还是有区别。第一是没有自动补全Python和Shell都不会提示函数签名所以平时写代码不能太依赖IDE尤其是os、sys、re、collections这些标准库的常用函数得记牢。第二是Shell脚本题没有真实的日志文件可以验证只能靠“默写”命令这就要求平时真的在终端里敲过而不是只看过命令的说明。第三是有摄像头监控不能像在家做题那样随意查资料所以基础知识必须当场反应得出来。我建议准备阶段就刻意练习“裸写”能力不用IDE补全直接在一个纯文本编辑器里写Python和Shell然后放到终端跑一遍验证结果。这样做几次之后笔试时的手感和用了IDE是一样的。4.2 命令细节失分不是不会是记岔了我复盘错题的时候发现选择题里丢分最多的往往是那些“看着眼熟但记不精确”的命令参数。比如find的-mtime、-newer、-exec和-ok的区别tar的-z、-J、-v组合grep的-E、-w、-c选项awk的-F指定分隔符等等。这里有个笨办法我觉得很有效把笔试高频命令整理成一张速查表每个命令只记2到3个最常见的用法然后每天在终端里跑一遍。比如find就记查文件、按时间过滤、配合-exec批量操作sed就记替换和按行删除awk就记打印列、条件过滤和分组统计。不需要把每个命令的所有参数都背下来但高频组合一定要形成肌肉记忆。还有一个容易忽略的点Shell脚本题的格式问题。有些线上OJ对Shell脚本的检查方式是“输出与预期一致”如果你的命令输出多了个空格或者空行可能被判错。写完命令后可以在心里模拟一遍每一步产生的输出格式确保没有多余的空白。4.3 多选漏选规则别因小失大前面提到多选计分规则这里再强调一遍。游戏公司校招笔试的多选题往往不确定选错是否倒扣分但大多数是“选错零分、少选按比例得分”。我当时定的策略是5个选项里只要有一个选项“不确认”就只选最确定的两个放弃那些模糊项。事实证明这个策略帮我保住了不少分因为有些多选题本身就有4个正确选项结果我只选了2个但至少没归零。当然这个策略也要分情况。如果题目是那种一眼就知道所有选项都对的比如“关于TCP三次握手的正确描述”那就全选不用犹豫。关键是识别“模糊判断题”——你对某个选项的知识点只记得“好像对”但说不出原理这种就果断放弃。4.4 编程题的时间分配先保一题AC再冲刺第二题我写限流装饰器那题花了差不多20分钟占了编程题的大部分时间。之所以敢这么花是因为我把时间管理的优先级定得很清楚编程题性价比最高先做完选择题因为分值分散后面用剩余时间快速推进。具体到编程题本身我的建议是先保证第一题完全正确再去看第二题。两道题如果都半吊子不如一道题完整AC加一道题写出核心逻辑拿部分分。笔试阅卷通常按测试用例给分部分用例过了也有分所以哪怕时间不够也要把主流程写出来别留在脑子里。我当时的策略是看到限流题先写核心类TokenBucket保证单测场景能过日志题用一行管道命令直接过关。写完再回头补注释和边界条件。这个节奏让我在90分钟内把所有题都覆盖到了没有出现交白卷的部分。5. 笔试之后的复盘从“会做题”到“面试能讲”5.1 我给自己做了一次“错题归因”笔试结束当天晚上我没有直接躺平而是趁热打铁把整张卷子回忆了一遍按照“完全不会”“概念模糊”“粗心失误”“时间不够没做”分了四类。结果发现粗心失误是最多的——不是知识盲区而是考试紧张读题不仔细导致看错了条件。其中最典型的例子是那题find -mtime 7和-mtime -7的选择我第一遍读题觉得是“找7天前的文件”差点选7后来反复读题干才发现写的是“最近7天内”。这种丢分非常可惜因为它不是“不会”而是“没看清”。复盘的意义就是把这些非知识性失分单独拎出来下次考试时强制自己在选项前先复述一遍题目的核心要求再下笔。5.2 笔试题是会“长进”面试题里的游卡笔试通过之后紧接着就是面试。面试官盯着简历问项目经验之外还会顺着笔试题往下问。我最深刻的一个感受是笔试不是考完就完了你写在卷子上的每一个答案都可能成为面试官追问的起点。比如面试官问我“你写的限流装饰器有没有考虑过分布式环境下多个实例怎么办”这个问题其实就是从笔试那道编程题拓展出来的。单机令牌桶用threading.Lock没问题但部署多个游戏服、多个API节点之后每个节点的限流状态是独立的玩家的请求被负载均衡分发到不同节点总流量可能变成N倍。要解决分布式限流要么用Redis的INCR 过期时间做滑动窗口要么用Lua脚本实现令牌桶的原子操作。虽然面试时我答得不算完美但至少笔试里“我写过限流器”这个事实给了面试官一个引子也给了我一个展示思考深度的机会。所以说准备笔试不能只看“能不能做出来”还要想“面试官可能会从这道题延伸出什么”。每做完一道有代表性的题就额外想一想“分布式版本怎么做”“压力再大一倍怎么办”“数据不一致怎么处理”这种延展性思考才是从笔试到面试无缝切换的关键。5.3 给下一届考生的运维开发笔试备战清单如果让我把经验浓缩成几条可执行的动作大概是这样的第一Linux命令每天练半小时。不用背大全重点覆盖文件查找、文本处理、进程管理、网络连接、权限、定时任务这六类。每个命令至少要有一次“自己动手排查真实文件”的经验而不是只在教程里看输出样例。第二Shell和Python二选一练熟。运维开发笔试一定会有脚本题。Shell适合快速处理文本和管道任务Python适合写带逻辑的小工具和算法题。建议Shell做到能写出Top日志统计、批量备份、进程检查这类脚本Python做到能实现限流、并发任务分发、日志解析这类小模块。第三网络和数据库原理要吃透。TCP三次握手、四次挥手、TCP粘包、HTTP状态码、DNS解析流程这些是选择题高发区。数据库则重点掌握索引原理、联合索引最左前缀、慢查询分析、GROUP BY和ORDER BY的执行逻辑。第四场景题要形成自己的“排查SOP”。面试官不看你能背多少命令而是看你能不能形成一套稳定的排查思路。我总结的通用链路是确认影响范围 → 检查网络链路 → 检查系统层资源 → 检查业务进程 → 检查日志 → 检查数据库 → 检查依赖服务。遇到任何故障按照这个顺序走不会乱。第五笔试环境要提前适应。至少完整模拟一次牛客网在线笔试流程限时、无IDE补全、相机开着、只能用手机当草稿。这些客观限制不提前适应考试时会额外消耗很多精力。复盘完这场笔试我最大的感受其实是运维开发这个岗位的笔试筛选的就是那些“既蹲得了机房也写得了代码”的人。命令背得熟说明你肯在日常运维里下功夫代码写得规范说明你有工程化思维场景题答得有层次说明你脑子里装过真实故障。这三样东西没有哪一样是可以靠考前突击三天就速成的都得在日常学习里一点点积累。希望这份复盘能帮后面准备运维开发校招的同学少走一些弯路。
