前阵子收拾旧电脑资料翻出一份2015年网易互娱校园招聘运维开发岗的笔试题来回看了几遍越看越有味道。说实话那会儿的题目放在今天技术栈确实变了不少可考察的底层逻辑没怎么过时。运维开发这个岗位在很多人的认知里就是“写脚本的运维”但其实笔试题目能很清楚地告诉你——这岗位要的不是只会敲命令的人而是懂系统、懂网络、懂业务还能用代码把运维工作产品化的人。这篇文章就借着这份题目把当年考察的核心知识点、答题思路和一些实操经验拆开聊聊对现在想走运维开发方向的校招生或者刚入行的朋友应该有点参考价值。1. 这份笔试题的定位与考察逻辑1.1 为什么校招笔试会这么设计2015年的互联网圈子和现在不太一样那时候容器还没大面积普及K8s影子都没看到OpenStack都还算是比较高级的话题。网易互娱作为游戏公司运维团队要管的是成百上千台游戏服务器分布在不同的网络分区随时可能面临玩家大量涌入、游戏合服开服、版本更新发布这些场景。在这种背景下校招笔试题的设计就显得非常“务实”——它不考你那些花哨的概念而是直接考察你到了岗位上能不能干活。我翻完这套题的整体印象是题目覆盖面广但难度并不偏怪全部是运维日常工作中一定会遇到的技术点。Linux基础、网络协议、Shell脚本、数据库、Web服务这几块基本是固定搭配。这么设计的原因其实不难理解游戏运维岗位要处理的问题非常杂你永远不知道下一个故障是磁盘满了、负载高了、连接数爆了还是某个进程悄悄挂了。所以笔试就得筛出那些基础扎实、知识面广、遇到问题能快速定位的人。1.2 运维开发岗笔试的核心知识框架如果给这套题的知识点画个分布图大概是这样的Linux系统管理题目占比最高大约25%重点在文件系统、权限、进程管理、系统性能排查网络基础题目约20%集中在TCP/IP协议栈、HTTP协议、负载均衡和网络故障排查脚本语言和自动化考察约20%Shell和Python都有涉及考察的是实际编码能力数据库和缓存约15%MySQL为主Redis和memcached也都会出现还有约20%是Web服务、Nginx配置、监控报警以及综合性开放题。这个知识框架其实很值得琢磨。你看它排布的顺序先是操作系统再是网络然后是脚本、数据库、Web服务最后是综合题——这其实是按照一个请求从客户端发出到服务器处理再到返回结果这条完整链路来设计的。也就是说笔试在模拟一个真实的运维排查场景用户访问不了游戏了你得能从网络层一路排查到应用层。这个思路放到今天的运维开发面试里依然是核心逻辑。2. Linux系统管理题目基础概念与实战排查并重2.1 文件系统、权限与进程管理的考察方向这套笔试题里Linux相关的题目大都有一个特点看起来在考命令实际在考原理。比如文件系统那部分有一道关于硬链接和软链接的题目表面上是让考生写出ln命令的用法实际上是考察inode的理解。硬链接不能跨文件系统不能对目录创建因为本质上是同一个inode的多个引用软链接可以跨文件系统因为它存的是路径。当时的游戏服务器日志目录经常要做软链到独立的数据盘如果不懂硬链接和软链接的区别操作的时候很容易踩坑。进程管理这部分的题目更有意思。有一道题是给出一个场景服务器负载突然飙升要求写出排查步骤。很多没有实际经验的人一上来就答top命令这当然没错但不完整。完整的思路应该是先top看整体负载和CPU/内存占用再top -H看具体线程再结合ps -ef查看进程启动参数和父子关系还要用strace跟踪进程的系统调用、lsof查看进程打开的文件。这套排查思路其实就是当年笔试想让考生展示的能力——不是背命令而是知道什么情况下用什么命令怎么一步步缩小问题范围。2.2 系统性能排查题型的答题模板当时卷子里有一道典型的性能排查题给了一个场景某台游戏登录服务器CPU使用率持续100%玩家登录延迟明显升高说明你的排查思路。这道题我觉得特别有代表性因为它的答案没有唯一标准评分的核心是看你的排查逻辑是否严密。我自己的答题思路是分层的。第一层先确认是不是CPU密集型进程占用的用top按CPU排序找到具体是哪个进程第二层如果是Java进程需要用jstack看线程栈如果是其他C进程用perf或者pstack第三层如果发现是常规进程再去查是不是出现了死循环或者频繁GC第四层还要检查是不是业务流量异常上涨导致的——比如某个活动引起玩家集中登录。这四层排查顺序就是从“看现象”到“定进程”再到“分析原因”最后“关联业务”的过程。这个答题模板放在现在做线上故障排查一样管用。运维开发岗和纯运维岗的区别在于笔试中如果能在这一层的回答里进一步写出“写一个脚本定时采集CPU数据、留作事后分析”那分数会明显高一个档次因为这就体现了“开发”属性。3. 网络基础与协议栈考点拆解3.1 TCP三次握手与连接状态题目2015年那会儿游戏服务器和后端服务之间的通信TCP仍然是绝对的主流。所以笔试题里网络部分TCP连接状态的相关题目几乎必考。让我印象比较深的一道题是结合netstat输出让考生说明TIME_WAIT状态大量出现的原因以及如何处理。这道题考察的点非常实际。TIME_WAIT是主动关闭连接的一方在收到对端FIN并回复ACK之后进入的状态要持续2MSL时间按默认值大概是2到4分钟。在高并发的短连接场景下比如前端Nginx频繁和后端服务创建连接再断开就会积累大量TIME_WAIT连接。处理办法无非几个方向一是开启tcp_tw_reuse但需要注意这需要同时开启tcp_timestamps二是调整tcp_fin_timeout缩短TIME_WAIT的等待时间三是改造代码使用连接池或者长连接减少连接频繁创建销毁。从长远角度看第三种才是治本的方案。这个知识点的巧妙之处在于它既能看出考生对TCP状态机的理解又能看出是否真正处理过线上连接数问题。我当时回答这道题的时候额外提了一句“tcp_tw_reuse只对客户端出站连接有效对于服务端主动关闭连接的场景效果有限”这种细节很能加分因为它不是课本上会写的而是实践中才能摸到的门道。3.2 HTTP协议与常见监控排查命令HTTP协议相关的题目在笔试题里比较常规但很考验基础是否扎实。比如有一道题专门考察HTTP状态码的含义这题看着简单却容易踩坑。301和302的区别、401和403的区别、500和502、503的区别这些如果只是死记硬背在具体场景下很容易搞混。我当时是这么记住的301是永久重定向浏览器会缓存这个跳转302是临时重定向每次都要重新请求原地址401是未认证服务器知道你是谁不知道你有没有权限403是禁止访问服务器直接拒绝了你的请求502是网关从上游收到了无效响应比如PHP-FPM进程崩了503是服务暂时不可用比如发布期间或者服务过载。游戏运维里最常遇到的就是502和504Nginx代理后端的游戏接口服务如果某个游戏逻辑进程挂了Nginx返回502这时候排查方向应该往后端进程走而不是在Nginx本身上花太多时间。网络排查常用命令这块ping、telnet、traceroute、netstat这些工具的使用题目也很常见。我这里有一个当年踩过的坑traceroute的路径信息受运营商路由策略影响很大同一个IP从不同地区追踪中间跳数可能完全不一样。所以笔试里如果出这类题回答时要提到“跨网络区域路由不可控traceroute只能辅助定位不能作为唯一判断依据”这点很能体现实际经验。4. 脚本语言与自动化能力考察4.1 Shell脚本的经典考察方向运维开发岗的笔试Shell是躲不开的。这套题里Shell部分占了不少分值而且考察方式不是让写一段简单的echo输出而是模拟真实场景。有一道题让我印象很深给定一个Nginx访问日志格式是标准combined格式要求统计出访问量TOP10的IP并输出每个IP的访问次数。这道题其实就是一条awk加sort的命令组合。标准解法是awk {print $1} logfile | sort | uniq -c | sort -rn | head -10。但这里面真正想考察的点不是你会不会用awk而是你懂不懂管道和文本处理的设计思路。sort的字母排序和数字排序区别是这道题的一个坑如果不加-n参数10会排在2前面排序结果就不对。这种细节只有真正在命令行下处理过大量日志的人才会在一次次的教训中记住。Shell部分还有一个特别典型的题目方向就是写一个日志切割的脚本。因为游戏服务器每天会产生大量日志不可能全部堆在一个文件里所以脚本要让运维在每天凌晨对前一天的日志进行归档、压缩并配置删除策略只保留最近N天。这里面要考的知识点包括date命令格式化、gzip调用、find加mtime筛选、crontab配置。回答这类题时有个实操细节可以加分就是给脚本加上防重复执行的锁用flock或者mkdir作为锁标记防止crontab重入导致脚本并发执行这是很多新手写脚本时会忽略的。4.2 Python在运维开发中的考察方向2015年的时候Python在运维圈已经开始流行起来了不过和现在遍地Python不一样当时的笔试对Python的考察不算特别深主要集中在列表推导式、字典操作、文件读写、简单的多线程。有一道题是让用Python统计一个文件里单词的出现频率并且按出现次数降序输出。这道题看起来简单但能考察的标准很多。用defaultdict还是普通dict用sorted的key参数怎么指定排序维度文件的打开方式用with语句还是手动close这些细节都能看出考生的编码习惯。还有一个很有年代感的Python题目方向是模拟写一个简单的端口监控脚本检查本机80端口是否存活如果挂了则执行一个操作命令并发送告警。这道题的考察点是socket库的连接测试、subprocess调用外部命令以及日志记录。我把这套题重做一遍之后的体会是Socket连接测试时connect_ex返回0代表端口通返回其他值代表不通这个返回值必须判断明确如果直接用connect再捕获异常逻辑上也行但代码会冗长很多。运维开发的编码能力和纯开发不一样我们追求的永远是“用最少的代码解决实际问题并且可读性要足够高”。另外Python部分的笔试答案里如果能体现出对异常处理的完整考虑分数会明显有差别。什么叫完整的异常处理端口监控脚本不仅要考虑连接成功和失败两种情况还要考虑socket超时设置否则在目标主机网络不通的时候默认超时时间可能要等很久脚本看起来就像卡死了一样。这些都是运维实战里血泪换来的经验。5. 数据库、缓存与Web服务考点分析5.1 MySQL相关知识点与慢查询优化游戏运维每天打交道最多的软件MySQL肯定排在前列。笔试题中MySQL的知识点分布得很清晰SQL基本语法、事务隔离级别、索引原理、慢查询分析和主从复制。有一道题比较典型给了一条慢查询SQL让分析慢的原因并给出优化方案。这种题目考察的就是看你对数据库底层原理的掌握程度。慢查询的优化思路我一般是从几个维度展开的。首先看sql的执行计划用EXPLAIN看type字段是ALL还是range还是ref如果出现ALL全表扫描那基本就是没有命中索引优化方向是建立合适的复合索引。其次看WHERE条件字段上有没有函数操作比如WHERE DATE(create_time)2024-05-01这种写法会导致索引失效正确的做法是改成范围查询。还有一个非常隐蔽的坑是排序字段和查询字段不一致导致MySQL在内存中做filesort当数据量特别大时就会出现明显的性能瓶颈。当时这道题还有一个加分回答点除了SQL层面的优化还可以从架构层面谈比如在SQL前面加一层缓存、分库分表、读写分离。2015年的时候网易互娱的游戏数据存储已经很早就开始了分库分表的实践如果笔试中能提到按玩家ID做水平切分让单表数据量控制在合理范围这种答案会让阅卷人觉得你有良好的架构意识。5.2 Redis与memcached的踩坑点那年头的笔试正是Redis开始大规模取代memcached的时期。Redis 3.0版本在2015年4月发布开始支持集群功能。所以当时试卷里关于缓存的知识点很爱拿Redis和memcached做对比考察两者的数据结构差异、持久化机制、适用场景。Redis支持String、Hash、List、Set、ZSet五种核心数据类型而memcached只有简单的key-value存储Redis支持RDB和AOF两种持久化方式memcached重启数据直接全丢。如果只答到这些表面区别分数只能算及格。真正能拉开差距的是下面这些细节缓存雪崩和缓存穿透的应对方案。缓存雪崩是大量key同时过期导致请求全部打到数据库上解决思路是给过期时间加一个随机值让失效时间均匀分布缓存穿透是请求了一个不存在的key缓存永远无法命中导致每次都要查数据库解决思路是布隆过滤器或者缓存一个空值但要设置较短的过期时间。这些细节在2015年的面试中出现频率已经很高了因为那个年代的游戏排行榜、玩家会话信息、登录token大量依赖这些缓存组件一旦雪崩或者穿透玩家体验会直接受损。现在的Redis面试题里很多考点其实套路和当年差不多只是换了一层更花哨的外衣。5.3 Nginx配置与常见故障排查Web服务相关的题目Nginx是绝对的主角。2015年的时候网易内部大量业务已经慢慢从Apache迁移到Nginx毕竟在静态文件处理和高并发连接数上Nginx事件驱动的优势太明显了。笔试题里Nginx有一道配置题让写出一个静态资源服务器的关键配置实现给js、css、图片这类文件设置浏览器缓存并开启gzip压缩。这题的核心考点其实就两个地方location匹配规则和缓存头设置。location /static/ 前缀匹配和 location ~* .(js|css|png)$ 正则匹配的区别优先级顺序是什么这是Nginx配置里面最容易出错的问题。正常来说location匹配的优先级是精确匹配 前缀匹配^~ 正则匹配~* 普通前缀匹配 通用匹配如果顺序搞不清楚配置了不生效的情况反复出现。而浏览器缓存这块用expires 30d直接设置相对过期时间或者用add_header Cache-Control max-age2592000设置绝对时间都是面试官希望看到的答案。Nginx相关题目还有一个经典排查题后端服务正常但通过Nginx访问一直报502 Bad Gateway怎么排查。常规思路是先看Nginx错误日志确认upstream连接被拒绝还是超时再确认后端服务监听地址和端口是否正确还要检查Nginx所在服务器到后端服务器之间的防火墙或者安全组策略。我当时额外写了一个常被忽略的排查点后端服务绑定的地址如果后端进程只监听了127.0.0.1而Nginx在另外一台机器上请求自然无法转发过去。这类问题在真实运维中经常遇到能答出来说明你不是纸上谈兵。6. 综合题与开放性问题运维开发的核心竞争力6.1 故障排查类开放题的答题框架这套笔试题的最后一部分设计了几道开放式综合题没有标准答案考察的是分析和表达能力。其中一道题我到现在还记得它给了这样一个场景周五晚上突然接到业务方反馈游戏充值系统部分玩家充值不到账而且不是全部玩家是特定网络运营商的一部分玩家要你说明排查思路。这种题放在真实运维场景里就是典型的网络链路问题。答题可以从几个维度展开一是确认影响范围是所有人都出问题还是部分出问题这决定了排查方向完全不同二是从客户端到服务器的链路逐段排查包括DNS解析、机房入口、负载均衡、后端服务三是重点排查运营商和机房之间的互联互通当年的游戏运维最怕的就是跨运营商网络丢包延迟问题常常出现电信用户访问联通机房很慢联通用户访问电信机房很慢的情况。这类题的答题框架其实是一个通用方法论“影响范围确认、链路分段排查、环境变更排查、数据对比分析”。在包含多个服务的大型系统里面故障点不确定的情况下定位思路一定要分层从用户端开始网络层、系统层、应用层一层层往下剥。这个框架也是我后来带新人时反复强调的能在一张白纸上把排查逻辑画清楚的人面对真正的乱局也不会慌。6.2 架构设计与容量评估类题目的答题思路综合题目里还有一个方向让我印象很深是设计题假设一个游戏新版本上线老板预估次日在线人数会比平时翻一倍要你评估现有服务器集群是否扛得住如果不扛不住需要扩容多少台机器。这种题本质上是容量评估。答这类题的关键是要先拆分指标再估算峰值。第一确认当前集群的总连接数上限、带宽上限、CPU核数、内存总量第二按在线人数翻倍来推算如果1万在线对应需要多少并发连接、多少QPS、多少带宽第三结合游戏业务的特殊性热点活动会导致入口流量突增比值往往不是线性关系比如在线人数翻倍登录接口的QPS可能翻三倍第四留足冗余一般建议水位不要超过峰值的70%。这道题答得好的同学往往会考虑得更细比如加机器解决的是计算和内存的扩展但带宽如果到瓶颈了加机器并不能解决数据库如果是单库扩容了应用服务器数据库反而可能成为新的瓶颈热点玩家集中在同一台服务器上怎么办需不需要提前做负载均衡或分区调度。这些都是在实际做游戏服务器扩容时需要考虑的问题笔试中能把这些考虑到位说明对线上集群架构有全局理解。7. 运开岗位的复盘思考与备考建议重做完整套题之后我最大的感受是2015年的运维开发笔试和现在的面试核心考察点没有本质区别变的只是具体的命令工具和技术栈。当年考的是用netstat看连接状态现在考的是用ss命令当年考的是Nginx配置现在可能会加一个K8s的Ingress当年考的是写Shell脚本现在会更强调Go或者Python的自动化平台开发。但底层的知识体系操作系统、网络、数据库、脚本能力、架构思维这些骨架从来没变过。对现在想投运维开发岗位的校招生我有几点很实际的建议。第一一定不要把精力只花在背命令上命令只是工具理解背后的原理才是核心。第二多动手做一些真实场景的小项目自己搭一个网站然后模拟故障来排查比刷一百道题都有用。第三笔试和面试中遇到没见过的问题不要慌只要你把排查思路讲清楚即使没有找到最终原因面试官也会认可你的逻辑能力。第四坚持写脚本把日常重复的运维操作都写成自动化的程序这是运维开发岗位区别于传统运维最核心的能力。我当年笔试阶段就吃过不小的亏。有一个关于Linux文件权限的题目题目本身很简单但我当时只记得chmod 755这种数字法的用法恰恰忽略掉了SUID、SGID、Sticky Bit这些特殊权限位的含义结果正好考到白白丢了分。后来在真实的运维工作里碰到/tmp目录的Sticky Bit权限、passwd命令的SUID权限时才明白这些东西不是笔试为了难为人而设计的它们就是日常系统管理里的基本盘。所以现在如果有人问我怎么准备运维开发的笔试我的回答永远是把最基础最琐碎的知识点老老实实过一遍别以为简单就不会考也别以为考过就不会再遇到。 运维开发笔试核心考点：从Linux到网络排查的实战解析
前阵子收拾旧电脑资料翻出一份2015年网易互娱校园招聘运维开发岗的笔试题来回看了几遍越看越有味道。说实话那会儿的题目放在今天技术栈确实变了不少可考察的底层逻辑没怎么过时。运维开发这个岗位在很多人的认知里就是“写脚本的运维”但其实笔试题目能很清楚地告诉你——这岗位要的不是只会敲命令的人而是懂系统、懂网络、懂业务还能用代码把运维工作产品化的人。这篇文章就借着这份题目把当年考察的核心知识点、答题思路和一些实操经验拆开聊聊对现在想走运维开发方向的校招生或者刚入行的朋友应该有点参考价值。1. 这份笔试题的定位与考察逻辑1.1 为什么校招笔试会这么设计2015年的互联网圈子和现在不太一样那时候容器还没大面积普及K8s影子都没看到OpenStack都还算是比较高级的话题。网易互娱作为游戏公司运维团队要管的是成百上千台游戏服务器分布在不同的网络分区随时可能面临玩家大量涌入、游戏合服开服、版本更新发布这些场景。在这种背景下校招笔试题的设计就显得非常“务实”——它不考你那些花哨的概念而是直接考察你到了岗位上能不能干活。我翻完这套题的整体印象是题目覆盖面广但难度并不偏怪全部是运维日常工作中一定会遇到的技术点。Linux基础、网络协议、Shell脚本、数据库、Web服务这几块基本是固定搭配。这么设计的原因其实不难理解游戏运维岗位要处理的问题非常杂你永远不知道下一个故障是磁盘满了、负载高了、连接数爆了还是某个进程悄悄挂了。所以笔试就得筛出那些基础扎实、知识面广、遇到问题能快速定位的人。1.2 运维开发岗笔试的核心知识框架如果给这套题的知识点画个分布图大概是这样的Linux系统管理题目占比最高大约25%重点在文件系统、权限、进程管理、系统性能排查网络基础题目约20%集中在TCP/IP协议栈、HTTP协议、负载均衡和网络故障排查脚本语言和自动化考察约20%Shell和Python都有涉及考察的是实际编码能力数据库和缓存约15%MySQL为主Redis和memcached也都会出现还有约20%是Web服务、Nginx配置、监控报警以及综合性开放题。这个知识框架其实很值得琢磨。你看它排布的顺序先是操作系统再是网络然后是脚本、数据库、Web服务最后是综合题——这其实是按照一个请求从客户端发出到服务器处理再到返回结果这条完整链路来设计的。也就是说笔试在模拟一个真实的运维排查场景用户访问不了游戏了你得能从网络层一路排查到应用层。这个思路放到今天的运维开发面试里依然是核心逻辑。2. Linux系统管理题目基础概念与实战排查并重2.1 文件系统、权限与进程管理的考察方向这套笔试题里Linux相关的题目大都有一个特点看起来在考命令实际在考原理。比如文件系统那部分有一道关于硬链接和软链接的题目表面上是让考生写出ln命令的用法实际上是考察inode的理解。硬链接不能跨文件系统不能对目录创建因为本质上是同一个inode的多个引用软链接可以跨文件系统因为它存的是路径。当时的游戏服务器日志目录经常要做软链到独立的数据盘如果不懂硬链接和软链接的区别操作的时候很容易踩坑。进程管理这部分的题目更有意思。有一道题是给出一个场景服务器负载突然飙升要求写出排查步骤。很多没有实际经验的人一上来就答top命令这当然没错但不完整。完整的思路应该是先top看整体负载和CPU/内存占用再top -H看具体线程再结合ps -ef查看进程启动参数和父子关系还要用strace跟踪进程的系统调用、lsof查看进程打开的文件。这套排查思路其实就是当年笔试想让考生展示的能力——不是背命令而是知道什么情况下用什么命令怎么一步步缩小问题范围。2.2 系统性能排查题型的答题模板当时卷子里有一道典型的性能排查题给了一个场景某台游戏登录服务器CPU使用率持续100%玩家登录延迟明显升高说明你的排查思路。这道题我觉得特别有代表性因为它的答案没有唯一标准评分的核心是看你的排查逻辑是否严密。我自己的答题思路是分层的。第一层先确认是不是CPU密集型进程占用的用top按CPU排序找到具体是哪个进程第二层如果是Java进程需要用jstack看线程栈如果是其他C进程用perf或者pstack第三层如果发现是常规进程再去查是不是出现了死循环或者频繁GC第四层还要检查是不是业务流量异常上涨导致的——比如某个活动引起玩家集中登录。这四层排查顺序就是从“看现象”到“定进程”再到“分析原因”最后“关联业务”的过程。这个答题模板放在现在做线上故障排查一样管用。运维开发岗和纯运维岗的区别在于笔试中如果能在这一层的回答里进一步写出“写一个脚本定时采集CPU数据、留作事后分析”那分数会明显高一个档次因为这就体现了“开发”属性。3. 网络基础与协议栈考点拆解3.1 TCP三次握手与连接状态题目2015年那会儿游戏服务器和后端服务之间的通信TCP仍然是绝对的主流。所以笔试题里网络部分TCP连接状态的相关题目几乎必考。让我印象比较深的一道题是结合netstat输出让考生说明TIME_WAIT状态大量出现的原因以及如何处理。这道题考察的点非常实际。TIME_WAIT是主动关闭连接的一方在收到对端FIN并回复ACK之后进入的状态要持续2MSL时间按默认值大概是2到4分钟。在高并发的短连接场景下比如前端Nginx频繁和后端服务创建连接再断开就会积累大量TIME_WAIT连接。处理办法无非几个方向一是开启tcp_tw_reuse但需要注意这需要同时开启tcp_timestamps二是调整tcp_fin_timeout缩短TIME_WAIT的等待时间三是改造代码使用连接池或者长连接减少连接频繁创建销毁。从长远角度看第三种才是治本的方案。这个知识点的巧妙之处在于它既能看出考生对TCP状态机的理解又能看出是否真正处理过线上连接数问题。我当时回答这道题的时候额外提了一句“tcp_tw_reuse只对客户端出站连接有效对于服务端主动关闭连接的场景效果有限”这种细节很能加分因为它不是课本上会写的而是实践中才能摸到的门道。3.2 HTTP协议与常见监控排查命令HTTP协议相关的题目在笔试题里比较常规但很考验基础是否扎实。比如有一道题专门考察HTTP状态码的含义这题看着简单却容易踩坑。301和302的区别、401和403的区别、500和502、503的区别这些如果只是死记硬背在具体场景下很容易搞混。我当时是这么记住的301是永久重定向浏览器会缓存这个跳转302是临时重定向每次都要重新请求原地址401是未认证服务器知道你是谁不知道你有没有权限403是禁止访问服务器直接拒绝了你的请求502是网关从上游收到了无效响应比如PHP-FPM进程崩了503是服务暂时不可用比如发布期间或者服务过载。游戏运维里最常遇到的就是502和504Nginx代理后端的游戏接口服务如果某个游戏逻辑进程挂了Nginx返回502这时候排查方向应该往后端进程走而不是在Nginx本身上花太多时间。网络排查常用命令这块ping、telnet、traceroute、netstat这些工具的使用题目也很常见。我这里有一个当年踩过的坑traceroute的路径信息受运营商路由策略影响很大同一个IP从不同地区追踪中间跳数可能完全不一样。所以笔试里如果出这类题回答时要提到“跨网络区域路由不可控traceroute只能辅助定位不能作为唯一判断依据”这点很能体现实际经验。4. 脚本语言与自动化能力考察4.1 Shell脚本的经典考察方向运维开发岗的笔试Shell是躲不开的。这套题里Shell部分占了不少分值而且考察方式不是让写一段简单的echo输出而是模拟真实场景。有一道题让我印象很深给定一个Nginx访问日志格式是标准combined格式要求统计出访问量TOP10的IP并输出每个IP的访问次数。这道题其实就是一条awk加sort的命令组合。标准解法是awk {print $1} logfile | sort | uniq -c | sort -rn | head -10。但这里面真正想考察的点不是你会不会用awk而是你懂不懂管道和文本处理的设计思路。sort的字母排序和数字排序区别是这道题的一个坑如果不加-n参数10会排在2前面排序结果就不对。这种细节只有真正在命令行下处理过大量日志的人才会在一次次的教训中记住。Shell部分还有一个特别典型的题目方向就是写一个日志切割的脚本。因为游戏服务器每天会产生大量日志不可能全部堆在一个文件里所以脚本要让运维在每天凌晨对前一天的日志进行归档、压缩并配置删除策略只保留最近N天。这里面要考的知识点包括date命令格式化、gzip调用、find加mtime筛选、crontab配置。回答这类题时有个实操细节可以加分就是给脚本加上防重复执行的锁用flock或者mkdir作为锁标记防止crontab重入导致脚本并发执行这是很多新手写脚本时会忽略的。4.2 Python在运维开发中的考察方向2015年的时候Python在运维圈已经开始流行起来了不过和现在遍地Python不一样当时的笔试对Python的考察不算特别深主要集中在列表推导式、字典操作、文件读写、简单的多线程。有一道题是让用Python统计一个文件里单词的出现频率并且按出现次数降序输出。这道题看起来简单但能考察的标准很多。用defaultdict还是普通dict用sorted的key参数怎么指定排序维度文件的打开方式用with语句还是手动close这些细节都能看出考生的编码习惯。还有一个很有年代感的Python题目方向是模拟写一个简单的端口监控脚本检查本机80端口是否存活如果挂了则执行一个操作命令并发送告警。这道题的考察点是socket库的连接测试、subprocess调用外部命令以及日志记录。我把这套题重做一遍之后的体会是Socket连接测试时connect_ex返回0代表端口通返回其他值代表不通这个返回值必须判断明确如果直接用connect再捕获异常逻辑上也行但代码会冗长很多。运维开发的编码能力和纯开发不一样我们追求的永远是“用最少的代码解决实际问题并且可读性要足够高”。另外Python部分的笔试答案里如果能体现出对异常处理的完整考虑分数会明显有差别。什么叫完整的异常处理端口监控脚本不仅要考虑连接成功和失败两种情况还要考虑socket超时设置否则在目标主机网络不通的时候默认超时时间可能要等很久脚本看起来就像卡死了一样。这些都是运维实战里血泪换来的经验。5. 数据库、缓存与Web服务考点分析5.1 MySQL相关知识点与慢查询优化游戏运维每天打交道最多的软件MySQL肯定排在前列。笔试题中MySQL的知识点分布得很清晰SQL基本语法、事务隔离级别、索引原理、慢查询分析和主从复制。有一道题比较典型给了一条慢查询SQL让分析慢的原因并给出优化方案。这种题目考察的就是看你对数据库底层原理的掌握程度。慢查询的优化思路我一般是从几个维度展开的。首先看sql的执行计划用EXPLAIN看type字段是ALL还是range还是ref如果出现ALL全表扫描那基本就是没有命中索引优化方向是建立合适的复合索引。其次看WHERE条件字段上有没有函数操作比如WHERE DATE(create_time)2024-05-01这种写法会导致索引失效正确的做法是改成范围查询。还有一个非常隐蔽的坑是排序字段和查询字段不一致导致MySQL在内存中做filesort当数据量特别大时就会出现明显的性能瓶颈。当时这道题还有一个加分回答点除了SQL层面的优化还可以从架构层面谈比如在SQL前面加一层缓存、分库分表、读写分离。2015年的时候网易互娱的游戏数据存储已经很早就开始了分库分表的实践如果笔试中能提到按玩家ID做水平切分让单表数据量控制在合理范围这种答案会让阅卷人觉得你有良好的架构意识。5.2 Redis与memcached的踩坑点那年头的笔试正是Redis开始大规模取代memcached的时期。Redis 3.0版本在2015年4月发布开始支持集群功能。所以当时试卷里关于缓存的知识点很爱拿Redis和memcached做对比考察两者的数据结构差异、持久化机制、适用场景。Redis支持String、Hash、List、Set、ZSet五种核心数据类型而memcached只有简单的key-value存储Redis支持RDB和AOF两种持久化方式memcached重启数据直接全丢。如果只答到这些表面区别分数只能算及格。真正能拉开差距的是下面这些细节缓存雪崩和缓存穿透的应对方案。缓存雪崩是大量key同时过期导致请求全部打到数据库上解决思路是给过期时间加一个随机值让失效时间均匀分布缓存穿透是请求了一个不存在的key缓存永远无法命中导致每次都要查数据库解决思路是布隆过滤器或者缓存一个空值但要设置较短的过期时间。这些细节在2015年的面试中出现频率已经很高了因为那个年代的游戏排行榜、玩家会话信息、登录token大量依赖这些缓存组件一旦雪崩或者穿透玩家体验会直接受损。现在的Redis面试题里很多考点其实套路和当年差不多只是换了一层更花哨的外衣。5.3 Nginx配置与常见故障排查Web服务相关的题目Nginx是绝对的主角。2015年的时候网易内部大量业务已经慢慢从Apache迁移到Nginx毕竟在静态文件处理和高并发连接数上Nginx事件驱动的优势太明显了。笔试题里Nginx有一道配置题让写出一个静态资源服务器的关键配置实现给js、css、图片这类文件设置浏览器缓存并开启gzip压缩。这题的核心考点其实就两个地方location匹配规则和缓存头设置。location /static/ 前缀匹配和 location ~* .(js|css|png)$ 正则匹配的区别优先级顺序是什么这是Nginx配置里面最容易出错的问题。正常来说location匹配的优先级是精确匹配 前缀匹配^~ 正则匹配~* 普通前缀匹配 通用匹配如果顺序搞不清楚配置了不生效的情况反复出现。而浏览器缓存这块用expires 30d直接设置相对过期时间或者用add_header Cache-Control max-age2592000设置绝对时间都是面试官希望看到的答案。Nginx相关题目还有一个经典排查题后端服务正常但通过Nginx访问一直报502 Bad Gateway怎么排查。常规思路是先看Nginx错误日志确认upstream连接被拒绝还是超时再确认后端服务监听地址和端口是否正确还要检查Nginx所在服务器到后端服务器之间的防火墙或者安全组策略。我当时额外写了一个常被忽略的排查点后端服务绑定的地址如果后端进程只监听了127.0.0.1而Nginx在另外一台机器上请求自然无法转发过去。这类问题在真实运维中经常遇到能答出来说明你不是纸上谈兵。6. 综合题与开放性问题运维开发的核心竞争力6.1 故障排查类开放题的答题框架这套笔试题的最后一部分设计了几道开放式综合题没有标准答案考察的是分析和表达能力。其中一道题我到现在还记得它给了这样一个场景周五晚上突然接到业务方反馈游戏充值系统部分玩家充值不到账而且不是全部玩家是特定网络运营商的一部分玩家要你说明排查思路。这种题放在真实运维场景里就是典型的网络链路问题。答题可以从几个维度展开一是确认影响范围是所有人都出问题还是部分出问题这决定了排查方向完全不同二是从客户端到服务器的链路逐段排查包括DNS解析、机房入口、负载均衡、后端服务三是重点排查运营商和机房之间的互联互通当年的游戏运维最怕的就是跨运营商网络丢包延迟问题常常出现电信用户访问联通机房很慢联通用户访问电信机房很慢的情况。这类题的答题框架其实是一个通用方法论“影响范围确认、链路分段排查、环境变更排查、数据对比分析”。在包含多个服务的大型系统里面故障点不确定的情况下定位思路一定要分层从用户端开始网络层、系统层、应用层一层层往下剥。这个框架也是我后来带新人时反复强调的能在一张白纸上把排查逻辑画清楚的人面对真正的乱局也不会慌。6.2 架构设计与容量评估类题目的答题思路综合题目里还有一个方向让我印象很深是设计题假设一个游戏新版本上线老板预估次日在线人数会比平时翻一倍要你评估现有服务器集群是否扛得住如果不扛不住需要扩容多少台机器。这种题本质上是容量评估。答这类题的关键是要先拆分指标再估算峰值。第一确认当前集群的总连接数上限、带宽上限、CPU核数、内存总量第二按在线人数翻倍来推算如果1万在线对应需要多少并发连接、多少QPS、多少带宽第三结合游戏业务的特殊性热点活动会导致入口流量突增比值往往不是线性关系比如在线人数翻倍登录接口的QPS可能翻三倍第四留足冗余一般建议水位不要超过峰值的70%。这道题答得好的同学往往会考虑得更细比如加机器解决的是计算和内存的扩展但带宽如果到瓶颈了加机器并不能解决数据库如果是单库扩容了应用服务器数据库反而可能成为新的瓶颈热点玩家集中在同一台服务器上怎么办需不需要提前做负载均衡或分区调度。这些都是在实际做游戏服务器扩容时需要考虑的问题笔试中能把这些考虑到位说明对线上集群架构有全局理解。7. 运开岗位的复盘思考与备考建议重做完整套题之后我最大的感受是2015年的运维开发笔试和现在的面试核心考察点没有本质区别变的只是具体的命令工具和技术栈。当年考的是用netstat看连接状态现在考的是用ss命令当年考的是Nginx配置现在可能会加一个K8s的Ingress当年考的是写Shell脚本现在会更强调Go或者Python的自动化平台开发。但底层的知识体系操作系统、网络、数据库、脚本能力、架构思维这些骨架从来没变过。对现在想投运维开发岗位的校招生我有几点很实际的建议。第一一定不要把精力只花在背命令上命令只是工具理解背后的原理才是核心。第二多动手做一些真实场景的小项目自己搭一个网站然后模拟故障来排查比刷一百道题都有用。第三笔试和面试中遇到没见过的问题不要慌只要你把排查思路讲清楚即使没有找到最终原因面试官也会认可你的逻辑能力。第四坚持写脚本把日常重复的运维操作都写成自动化的程序这是运维开发岗位区别于传统运维最核心的能力。我当年笔试阶段就吃过不小的亏。有一个关于Linux文件权限的题目题目本身很简单但我当时只记得chmod 755这种数字法的用法恰恰忽略掉了SUID、SGID、Sticky Bit这些特殊权限位的含义结果正好考到白白丢了分。后来在真实的运维工作里碰到/tmp目录的Sticky Bit权限、passwd命令的SUID权限时才明白这些东西不是笔试为了难为人而设计的它们就是日常系统管理里的基本盘。所以现在如果有人问我怎么准备运维开发的笔试我的回答永远是把最基础最琐碎的知识点老老实实过一遍别以为简单就不会考也别以为考过就不会再遇到。