运维开发笔试题核心考点拆解：从Linux到场景设计

运维开发这四个字放在2015年的校园招聘市场上其实是个挺微妙的存在。一方面游戏公司的运维团队早已不是早年那种只负责扛服务器、接网线的角色而是开始要求写代码、搞自动化、做监控平台另一方面大多数应届生对这个岗位的认知还停留在“是不是就是修电脑”的阶段。网易互娱的运维开发岗笔试题当年在圈内流传度很高很重要的一个原因是它把“运维”和“开发”两件事真正揉在一起考而不是简单给你一张Linux命令默写卷。这篇博文就围绕这套笔试题展开讲讲它到底考什么、背后的考察逻辑是什么、哪些题是真正筛人的分水岭。无论你是现在准备校招的应届生还是工作几年后想转岗做运维开发的工程师这份拆解都能给你一个比较清晰的参考坐标系。我会尽量把当年考过的题型方向、解题思路、甚至踩过的坑都写出来有些地方凭记忆补全了细节供你参考。1. 岗位背景与命题逻辑1.1 2015年的网易互娱需要什么样的运维开发要理解这套笔试题先得搞清楚当年网易互娱的业务盘子。2015年前后端游和手游正处于交替期《梦幻西游》《大话西游》这些老IP依旧能打手游市场也开始爆发新游戏上线的节奏明显加快。游戏业务对运维的诉求和普通互联网公司不太一样它有几个非常鲜明的特点。第一是强实时性。游戏服务器出了问题玩家是秒感知的卡顿、掉线、回档任何一项都是事故级的问题而且会直接传导到收入上。第二是强周期性。开服、合服、新版本更新、春节活动、大促运营活动流量曲线是脉冲式的瞬间流量可能是平日的几十倍扩容缩容的节奏必须跟得上。第三是海量服务器和复杂架构。一套游戏可能拆成登录服、网关服、逻辑服、场景服、跨服战服务器每个模块都有自己独立的部署和运维方式纯手工肯定玩不转。这种情况下网易互娱对运维开发岗的定位从一开始就不是“运维操作员”而是“能写代码的运维工程师”。笔试题的设计本质上是想一次性筛选出三类人基础扎实的、逻辑清晰的、动手能力强的。前两类靠选择题和简答题筛第三类靠编程题和场景设计题筛。1.2 笔试的考察目标与整体结构2015年的这套笔试题整体结构可以分成四个板块基础选择填空、简答与概念题、编程题、综合场景设计题。分值比例我记得不大精确大概在3:2:3:2的样子基础题量大但单题分值低编程和场景题题量少但每题都是大头。这里有一个很有意思的设计基础题考察的是“你知道什么”简答题考察的是“你理解得多深”编程题考察的是“你写出来的东西能不能跑”场景设计题考察的是“你面对真实问题时的工程判断力”。四个维度层层递进每一层都在筛人。很多人准备校招笔试只顾着刷算法题结果前面基础题错一半这就是没搞清楚这类岗位笔试的重心在哪里。运维开发岗的笔试算法题不是考你ACM金牌水平而是考你能不能写出一段逻辑正确、健壮够用的代码去解决运维场景里的实际问题。1.3 为什么这类笔试直到今天仍有参考价值虽然这是2015年的题但我觉得它比现在很多公司的笔试题更值得复盘。原因很简单最近几年运维开发的笔试题越来越偏“八股文”背题库就能过而2015年这个阶段行业对运维开发的能力模型还没有形成固定模板出题人更多是凭着实际工作里的痛点来出题。所以题目的实战属性特别强你能明显感觉到出题的人是真在一线扛过故障、处理过日志、写过部署脚本的。后面我拆解具体考点的时候你会看到很多题目放到今天依然不过时比如Linux性能排查、TCP状态分析、日志处理、MySQL索引优化这些东西十年过去了底层的原理并没有变。能把这些题做明白的人放到今天的任何一家公司依然是个合格的运维开发。2. 核心考点逐项拆解2.1 Linux与操作系统基础考的从来不是命令记忆Linux这一块笔试不会直接问你“ls有哪些参数”而是会换着花样考你命令背后的机制。举几个当年的典型方向。文件权限与inode是几乎必考的题。常见考法是给你一个ls -l的输出让你判断某个用户在组内能不能读写某个文件或者问你硬链接和软链接的区别、ln创建硬链接后inode变化情况。这类题想拿分光背命令不行得理解文件系统的结构。硬链接本质上是多个目录项指向同一个inode软链接则是一个独立的文件内容存的是目标路径。理解了这层判断“硬链接能不能跨文件系统”“删除源文件后软链接是否失效”就是顺手的事。进程管理也是重点。我印象里有一道题考了孤儿进程和僵尸进程的区别以及怎么处理僵尸进程。这道题看起来很基础但答好的不多。很多人知道僵尸进程是父进程没调用wait回收但问“为什么不能直接kill僵尸进程”就卡住了。答案在于僵尸进程此时已经释放了所有资源只剩下一个进程表项kill对它无效正确做法是处理它的父进程让父进程回收或者把父进程也干掉让init进程收养。这种细节就是你跟别人拉开差距的地方。还考过内存相关的概念比如虚拟内存和物理内存的关系、swap分区的作用、出现大量swap换入换出时你的排查思路。还有一个高频考点是Linux的启动流程从BIOS到引导加载器到内核初始化再到init进程整个链路要能完整说清楚。这类题看着基础实际上考的是你有没有真正从头到尾用过一台Linux服务器还是只在上面敲过几条命令。2.2 网络基础TCP状态机是永远的主角网络方向的题在运维开发笔试里占的比重相当大。网易互娱的服务端架构基于TCP通信游戏玩家在线状态、房间同步、消息推送全部依赖稳定可靠的连接所以TCP相关的知识点是命题的重灾区。三次握手、四次挥手、TIME_WAIT状态这些基本是必考的。常见考法有几种。一种是给你一个TCP状态转换图问你某个状态是干什么的。另一种是实际场景题比如服务器上出现大量TIME_WAIT连接你如何分析、如何优化。TIME_WAIT这个东西短连接场景下特别常见它的存在是为了保证最后一个ACK能可靠到达同时防止旧连接的报文干扰新连接。优化手段包括调整net.ipv4.tcp_tw_reuse、tcp_tw_recycle参数但当年tcp_tw_recycle因为NAT场景下的问题已经不太建议用了。这种追问方式考的是你不仅知道调参还知道参数背后的副作用。HTTP协议也是重点但考的层次比“GET和POST区别”要深得多。比如会问你HTTP的keep-alive机制、缓存相关的HeaderCache-Control、ETag、Last-Modified或者给你一个线上接口变慢的问题让你从HTTP层开始排查。从HTTP响应码、DNS解析耗时、TCP建连耗时、首字节时间、内容传输时间每个环节怎么用curl或浏览器开发者工具去量化定位这是一套完整的排查思路。DNS也考过。有一道题问的是“用户在浏览器输入一个域名到页面完全展示中间经历了哪些步骤”这道题是典型的送分题但很多人答不全。我推荐的答题框架是DNS解析浏览器缓存-系统缓存-路由器缓存-ISP DNS-根域名服务器、TCP建连、发送HTTP请求、服务器处理、响应传输、浏览器渲染。每一步再稍微展开一下就是一份很好的答案。2.3 脚本编程能力Shell和Python的基本功运维开发之所以叫“开发”就是因为要写代码。2015年的时候Python在运维圈里已经逐渐成为主流Shell则是每个运维工程师的基本功。笔试对编程的考察分两部分。Shell这块考的是实际处理文本和系统管理的能力。最常见的题就是给你一个Nginx或Apache的访问日志让你统计出访问量Top 10的IP、统计某个接口的请求量、计算PV/UV、找出最近5分钟内的错误请求。这些题核心就是考察组合使用awk、sort、uniq、grep这些命令的能力以及管道思维。有一个经典组合到现在我都常跟新人说awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这一条管道下来访问量Top 10的IP就出来了。awk切出第一列也就是IPsort排序让相同IP聚在一起uniq -c去重并计数sort -rn按计数降序head -10取前10行。很多人觉得Shell难学其实难的不是单个命令而是“把多个命令串成一条流水线”的思维方式。Python这块考的题目类型就比较接近通用编程题了。常见的有字符串处理、文件读写、简单算法。我记得有一个方向是让你写一个脚本监控某目录下文件数量超过阈值就报警。这道题看着简单但能看出不少问题有人不会用os模块遍历目录有人不知道如何处理异常有人写出来的脚本只能跑一次不能循环执行。真正的运维开发写脚本要考虑异常处理、日志输出、可配置的参数这些工程习惯从笔试里就能看出一点苗头。算法题也会考但难度不高。我记得考过括号匹配、斐波那契数列、字符串反转这类基础题偶尔会有简单数据结构的考察。本质上就是验证你是不是具备基本的编程逻辑能力。2.4 数据库与中间件索引和缓存是分水岭游戏业务离不开数据库而且游戏场景对数据库的读写压力非常大。笔试中MySQL和Redis的考点基本能看出来一个人是不是真的在业务里用过数据库。MySQL考得最多的是索引。聚簇索引和非聚簇索引的区别、联合索引的最左前缀原则、什么情况下索引会失效、慢查询怎么优化这些是高频中的高频。记得有一道题问“为什么MySQL的InnoDB引擎选择B树作为索引结构而不是B树或哈希表”这道题很能考出深度。答这道题要抓住几个关键点B树的数据都存储在叶子节点并且通过链表串起来范围查询效率高非叶子节点只存索引键单节点能容纳更多索引项树更矮磁盘IO次数更少哈希表虽然单点查询快但没办法做范围查询和排序。能把这几层说清楚就能把大多数人甩开。事务隔离级别也是必考。读未提交、读已提交、可重复读、串行化四个级别要能说出各自的并发问题脏读、不可重复读、幻读还要知道InnoDB默认用的是可重复读以及MVCC和间隙锁是怎么解决幻读的。这个知识点不仅笔试用得上面试也一定逃不掉。Redis的考点集中在数据结构和缓存策略上。数据结构必考的是五种基本类型以及每种类型的底层实现、适用场景。String适合存计数器Hash适合存对象字段List适合消息队列Set适合去重和交并集运算ZSet适合排行榜——这五个场景要能脱口而出。缓存策略方面会考缓存穿透、缓存击穿、缓存雪崩的区别和应对方案。这三个概念很多人背了又忘我提供一个记忆锚点穿透是“缓存和数据库都没有”击穿是“缓存没有但数据库有且热点key过期”雪崩是“大量key同时过期”。应对手段分别是布隆过滤器、互斥锁加逻辑过期、过期时间加随机值。2.5 综合场景设计题真正的压轴题场景设计题是整套卷子里最考验综合能力的部分而且题目通常文字量很大描述一个具体的业务问题让你给出解决方案。这种题没有标准答案考的是你的工程判断力。我记得有一类题是“游戏开服时大量玩家同时涌入服务器压力骤增如何设计一套扩容和降级方案”。答题时要体现几个层次流量入口层可以用负载均衡来分发流量应用层要支持无状态水平扩容这意味着Session要外置到Redis数据库层要做好读写分离或分库分表同时要有缓存层扛热点数据。关键还要考虑降级策略比如排行榜非核心功能可以暂时关闭、全服公告可以延迟发送、非实时性要求高的逻辑可以异步处理先保证核心玩法和登录体验。日志系统也是一类典型题。给你一个场景每天产生几百GB的日志分散在几百台服务器上需要统一收集并进行实时查询问你架构怎么设计。答题框架是采集端用Agent或Logstash收集日志传输层用Kafka做消息队列缓冲削峰消费端用Logstash或Flink做处理写入Elasticsearch供查询再用Kibana做可视化。这个链路就是经典的ELK加Kafka方案2015年的时候已经是行业标配了。还有一类题会考监控告警设计。给你一台服务器CPU飙升、磁盘IO打满要求你设计一套巡检和告警方案。要能说出拓扑数据采集zabbix-agent或自研采集脚本、数据存储时序数据库、告警规则引擎、通知渠道短信、邮件、电话以及告警升级机制。这里面最容易忽略的是“告警去重”和“告警升级”这两个设计处理不好就是告警风暴半夜被无效告警轰炸到崩溃。3. 实操过程与真题解题思路3.1 选择题与填空题快速拿分的关键选择题和填空题是整个卷子的基础分按我的经验这部分的正确率决定了你的下限。因为编程题和场景题主观性比较强给分弹性大选择题则是红就是红、白就是白。所以备考时要确保基础题不丢分。我记得有几种选择题型。一种是纯记忆类比如某个著名端口号对应哪个服务这属于送分题。一种是概念辨析类比如软链接和硬链接的区别、Cookie和Session的区别、同步与异步的区别这类题靠的是理解。还有一种是计算类比如给定IP和子网掩码算网络号、可用主机数给定磁盘容量和块大小算inode数量。我特别想说说子网掩码这道题因为当年好多人在这种题上栽跟头。比如给你一个IP地址192.168.10.129/26问这个IP属于哪个子网、可用主机范围是多少。很多人知道/26掩码是255.255.255.192然后就开始懵。快速算法是把256减去掩码的最后一组非零值也就是256减192等于64所以每个子网大小是64从0开始按64递增0-63、64-127、128-191129落在128-191这个段里网络号是192.168.10.128可用地址是129到190广播地址是191。这套思路理解了同类题十秒钟就能算出来。3.2 简答题怎么组织答案才能拿高分简答题是很多人失分的重灾区不是不会答而是不知道答题的节奏。我在批校招卷的时候有个感受很多人写了一大堆每一点都蜻蜓点水找不出一句能证明“他真懂”的话。简答题的节奏应该是“先定性再展开再举例”。拿“简述Linux下如何排查CPU负载过高问题”这种题来说合格的答案是先说排查方法论先用uptime或top看整体负载用top按CPU占用排序找到进程和线程用vmstat看上下文切换和CPU等待分布再用strace或perf进一步定位热点。然后要说明影响CPU的三个维度用户态计算密集、内核态锁竞争或中断过多、上下文切换频繁。最后要能举一个具体场景比如Java应用的热点线程排查用top找到线程ID转成十六进制再用jstack匹配。这样一套下来考官一看就知道你是真干过活的。再比如“简述TCP三次握手过程为什么不是两次或四次”很多人只把三次握手的状态变化写出来就结束了。但高分答案会额外说明两次握手无法防止历史重复连接请求对服务器的干扰因为服务器收到SYN就会分配资源进入SYN_RECV状态四次握手没必要因为三次已经能在客户端和服务器之间确认双向收发能力第三次握手中的ACK可以顺带携带数据减少一次RTT。3.3 编程题代码能力是这样考察的编程题在整张卷子里占的分数比重不小而且通常是拉开差距的地方。之前说过这类岗位不考特别难的算法但考察代码质量和工程思维。我记得有一个典型的题是“给定一个只包含括号的字符串判断括号是否匹配”。这题考的是栈这个数据结构的应用。回答思路是遇到左括号压栈遇到右括号时看栈顶是不是与之匹配的左括号是则弹出不是则返回不匹配遍历结束后栈为空才算完全匹配。Python实现如下def is_balanced(s: str) - bool: stack [] pairs {): (, ]: [, }: {} for ch in s: if ch in ([{: stack.append(ch) elif ch in )]}: if not stack or stack[-1] ! pairs[ch]: return False stack.pop() return not stack这里有几个细节要注意。判断右括号时先检查栈空不空栈空说明右括号没有对应的左括号直接返回False。这个检查很多人会漏掉写出来的代码遇到“)(”这种情况就会出错。其次是用字典来映射右括号到左括号比多个if-else要清爽得多。最后返回的不是True而是not stack因为如果所有左括号都被匹配弹出了栈才会为空否则就说明存在未闭合的左括号。另一道我印象深的题是“实现一个LRU缓存”限定了容量get和put操作的时间复杂度要求是O(1)。这类题考的是数据结构的组合使用能力。在Python里OrderedDict能保持键的插入顺序move_to_end可以把键移到末尾popitem(lastFalse)可以移除最早插入的键正好对应LRU的淘汰逻辑from collections import OrderedDict class LRUCache: def __init__(self, capacity: int): self.cache OrderedDict() self.capacity capacity def get(self, key: int) - int: if key not in self.cache: return -1 self.cache.move_to_end(key) return self.cache[key] def put(self, key: int, value: int) - None: if key in self.cache: self.cache.move_to_end(key) self.cache[key] value if len(self.cache) self.capacity: self.cache.popitem(lastFalse)这道题有两个关键点。第一get和put的时候都要更新访问顺序这是LRU的核心逻辑。第二淘汰策略用的是“移除最早插入且没有被访问过的键”OrderedDict默认按插入顺序记录move_to_end会把访问过的键重新标记为最新这样popitem(lastFalse)拿到的就是最久没被访问的键。理解了这个机制手写一个基于哈希表和双向链表的版本也不难。3.4 场景设计题从问题到方案的完整答题框架场景设计题很多人不知道从哪里下手我建议用“问题-目标-方案-细节-边界”这个框架来回答。不管题目怎么变把这几步走完答案就会很完整。第一步复述问题并明确目标。比如“设计一个游戏日志收集系统”你要先说出来问题的核心矛盾是什么日志量大、分布广、需要实时检索。目标是什么集中采集、低延迟传输、快速查询。第二步画出整体架构不需要太细但要有数据流的走向。采集端、消息队列、处理端、存储端、查询端一环套一环。第三步针对每一个环节说清楚选型和理由。采集端用Agent为什么不直接用rsync因为rsync是定时同步实时性不够消息队列选Kafka为什么不选RabbitMQ因为Kafka吞吐高、适合日志这种流式数据。第四步补充容错和降级方案。比如Kafka挂了怎么办本地先暂存恢复后重新上报。第五步说说这套方案在极端情况下的表现比如日志量翻十倍需要加哪些节点。我发现很多人答题时直接跳到“我用过XX工具”这一步省略了前面对问题的定义。这样做很吃亏因为阅卷人没法判断你是真的在思考问题还是碰巧背过一套方案。先分析问题再给方案才能体现出你的工程判断力。4. 常见失误与备考建议4.1 笔试里最可惜的几种失误每年都有很多人刷了大量题最后挂在一些很可惜的地方。我总结一下当年常见的失分点这些也是你可以提前避开的坑。第一种是基础题不重视。觉得Linux命令和TCP三板斧太简单花大把时间刷偏题怪题。结果考试时基础题错了五六道后面的大题虽然答得不错总分还是被拉下来了。运维开发岗笔试的特殊性在于基础知识是后面一切内容的地基地基不稳上层建筑再好也白搭。第二种是编程题不写完整。很多人知道思路就只写核心函数输入输出、边界条件、异常处理全都不管。阅卷人看这种代码会很头疼因为根本没法跑。比如写日志分析脚本你至少要考虑到文件不存在、权限不足、空行跳过、编码问题这些情况。哪怕简单写下try-except也能让阅卷人看到你的工程意识。第三种是场景题答得太虚。写了一大堆“要做监控”“要有自动化”“要保证高可用”但没有任何具体的技术选型和数据流描述。这种答案看起来高大上实际等于没说。场景题一定要落到具体你要说出用什么工具、放在架构的哪个环节、数据怎么流转、遇到故障怎么办这些才是阅卷人想看到的东西。第四种是时间分配失衡。有人在选择题上纠结太久导致最后编程题没时间写。我的建议是拿到卷子先把全部题目扫一遍标记出自己确定会的、需要思考的、完全不会的。先做会的再做需要思考的最后硬啃不会的。这样能保证该拿的分一分不少。4.2 从笔试到面试考点如何延续笔试只是第一关通过之后的技术面试你会发现考点是高度延续的。面试官基本会拿着你的笔试答卷找几个薄弱点进行深挖。比如笔试里TCP状态机那道题你答得磕磕巴巴面试时大概率会被追问“TIME_WAIT出现过多怎么解决”“SYN Flood攻击的原理是什么”。所以我的建议是笔试结束后不要立刻把知识点扔掉而是趁热打铁把每道题的答案扩展成一个小专题。我当时就是这么做的笔试考了一道“如何排查MySQL慢查询”回去以后我把慢查询日志、EXPLAIN执行计划、索引失效场景、参数优化全部过了一遍结果面试时真的被问到了类似的问题。笔试和面试的考点地图是重叠的一次认真复盘能同时覆盖两轮考核。面试里还有个常见问题是“你做过什么项目”或者“你平时怎么学习运维相关的技术”。这道题在笔试里无法体现但它决定面试官对你的印象。建议提前准备一个自己折腾过的实验环境比如自己搭过一套监控系统、写过自动化部署脚本、甚至只是在自己的笔记本电脑上虚拟了几台Linux机器模拟过集群都可以展开聊。重点不在于项目规模多大而在于你是否真的动手做过。4.3 面向运维开发岗位的能力模型说回“运维开发”这个词本身。2015年的时候这个岗位还在从传统运维向DevOps转型的过渡期行业里很多人说不清楚它和运维有什么区别。但如果你认真看了这份笔试题目你应该能感受到它的能力模型已经非常清晰了。我用一个简单的分层来总结。第一层是基础设施层包括操作系统、网络、数据库、中间件这是运维的基本功解决的是“系统能跑”的问题。第二层是开发能力层包括Shell、Python、常用框架、算法基础解决的是“重复的事能自动化”的问题。第三层是架构设计层包括高可用架构、监控体系、日志系统、容量规划解决的是“出了事能快速定位、大规模业务能撑住”的问题。第四层是业务理解层理解游戏业务的特点知道什么场景下玩家体验优先什么场景下系统稳定性优先。这套能力模型放到今天依然成立。你能看到很多做运维开发的人分化成两个方向一个偏平台开发专攻CMDB、监控平台、发布系统这类自研工具一个偏SRE专攻稳定性、容量、故障应急。但无论走哪个方向笔试里考察的那些底层能力——Linux、网络、数据库、脚本都是起点。5. 写在最后的一点个人体会说实话2015年那会儿我也经历过类似的校招笔试后来也参与过出题和阅卷的工作。回过头来看这些题目我最深的感受是笔试考的不是你能不能背下所有知识点而是你有没有建立起一套“遇到问题怎么思考”的框架。很多人觉得面经和题库背得足够多就能过笔试但到了实际工作里你会发现每一个线上故障都是没见过的每一次架构调整都是没背过的。真正让你站稳脚跟的是你对基础原理的理解以及你动手排查问题的经验。如果你现在还在准备运维开发方向的校招我的建议很直接把Linux系统管理、TCP/IP协议、MySQL索引、Redis缓存这四块吃透再把Shell和Python练到能流畅表达你的想法你就已经超过了绝大多数候选人。剩下的是在真实环境里多折腾多遇到问题多把问题解决掉。这套老题之所以值得反复品味不是因为它有多难而是因为它清晰地告诉你什么才是一个运维开发真正重要的东西。