搜狐畅游运维开发笔试复盘：从Shell脚本到故障排查与监控设计

1. 2019年这套笔试题的科目构成与难度风向

先交代一下背景。搜狐畅游的校招运维开发工程师岗，笔试并不是只考Linux命令和网络基础，它比传统的"纯运维"卷子多了一个非常明显的信号——运维开发的"开发"二字不是白给的。我那一年拿到的卷子，整体时间90分钟，题型分布大概是：选择题/填空题占40%，编程题占20%，故障场景排查题占20%，架构设计/方案题占20%。这个比例放在今天看可能不算稀奇，但在2019年，很多公司招运维还在拿"会敲命令、会装系统、会配Nginx"当标准，畅游已经明显在往"懂开发的运维"方向筛人了。

从难度上看，这套题属于典型的"看着都会，动手就卡"型。选择题和填空题是真实的Linux、网络基础题，不算偏，但有几个选项是平时不真正折腾过服务器的人根本分辨不出来的。编程题也不难，Shell和Python二选一或者都要写，但它在题目里埋了一个很容易忽略的效率坑。场景排查题和架构设计题是拉开差距的地方——不背八股，只考你平时有没有真的在线上处理过问题。

所以我的建议是：如果你是冲着"运维工程师"去投递，先把这套题的岗位方向和传统运维做个切割。传统运维的笔试题，重心放在LNMP环境搭建、iptables规则、Nginx配置、ansible部署这些"执行层"的东西上；而畅游的卷子更像是在考察"遇到问题你怎么定位、怎么通过代码或脚本去自动化解决"。Linux基础和网络是底层，但真正决定你能不能进面试的，是后一半——脚本设计、故障排查思路、模块化意识。

2. 选择题里的高频暗坑：文件权限、进程状态、网络命令的细节

2.1 文件权限与umask的计算题

这些年几乎所有大厂的运维笔试题都会带一两道权限计算，畅游也不例外。题目大概是这样的：当前umask是027，创建一个新文件后，它的默认权限是多少？很多人背过结论——文件是666减去umask，目录是777减去umask——但一碰到umask有奇数位就会出错。

重点拆一下这个坑：umask 027，对应的是owner、group、other三部分。新文件的默认权限，规则是：666 & ~umask，不是直接做减法。把027转成二进制：0=000，2=010，7=111，所以umask的二进制是000 010 111，取反后是111 101 000，再和110 110 110（666）做按位与，得到110 100 000，也就是640。

如果直接按"666-027=639"来算，group少了一个读权限，other多了一个执行权限，两个地方全错。目录则可以直接用777 - 027 = 750，因为umask全是偶数的情况下，减法和按位与结果一样。记住这个"文件用与运算，目录用减法"的规律，这种题就稳了。

另外补充一个容易被忽略的点：umask只有在创建文件时才生效，chmod或者chown之后是不受umask控制的。还有，ACL权限存在时，用ls -l看到的权限最后会多一个加号，这道题如果问"该文件是否还能被other组读取"，你得先区分传统权限和ACL，否则就会错判。

2.2 进程状态里那些看起来一样的字母

有一道选择题给了几个进程状态码——R、S、D、Z、T、I——问哪个状态表示进程正在等待不可中断的I/O。答案是D状态（不可中断睡眠）。这个题本身不难，但它延伸出来的东西很有价值：D状态进程在top里频繁出现时，意味着系统磁盘或网络I/O有瓶颈，这种进程kill不掉，只能等I/O恢复或者重启系统。

还有一个细节，2019年的卷子里有一道题问"僵尸进程为什么不能被kill -9杀掉"，我猜很多考生看到"僵尸"两个字就选了"因为它已经死了所以杀不掉"，但严格说，僵尸进程本身已经结束，它只是在等待父进程调用wait()来回收资源。kill -9对僵尸进程无效，是因为它已经没有内核执行体可以接收信号了。正确做法是kill父进程，让init/systemd去收养并清理，或者检查父进程为什么不调用wait。

顺带说一个日常排查经验：如果你在线上服务器看到大量Z状态进程，大概率是父进程代码有缺陷——没有正确回收子进程。这在Python的multiprocessing、Shell里并发跑子命令、Java的Runtime.exec()场景里都很常见。笔试只考状态含义，但面试官大概率会追问一句"你线上遇到过吗？怎么处理"，提前准备一个真实案例会加分。

2.3 网络排查命令：netstat、ss、tcpdump、lsof的区分

这组选择题出现的频率非常高，基本套路是给一个场景让你选命令。例如：线上服务端口监听了但连接数异常高，怎么快速看到每个IP的连接数？首选ss -antp | awk '{print $5}' | sort | uniq -c | sort -rn，而不是netstat。原因是ss直接读内核socket信息，不依赖/proc/net/tcp的解析，连接量大的时候性能远好于netstat。如果题目问的是"查看某个进程打开了哪些网络连接"，答案往往是lsof -p -i或lsof -i :端口。

这里有个2019年普遍存在的误区：很多教程还在推荐netstat -ano，但新版本的CentOS/RHEL已经默认不装net-tools了，生产环境里ss才是"原配"。笔试如果考到这个知识点，本质不是考"哪个命令更高级"，而是考你对时代变迁的感知——旧命令、新命令、什么时候用哪个，心里有没有数。

tcpdump考得不多，但会有一道选项题，问"要抓访问80端口的所有HTTP流量，表达式怎么写"。标准答案是tcpdump -i eth0 -nn 'tcp port 80'，注意这里不能写http这个关键词，因为tcpdump的http过滤器在部分版本上并不存在或者匹配的是payload层内容。想抓HTTP的Host头或者URL，得用-A或-X看包内容，或者加-w落盘后再分析。这背后的逻辑是：tcpdump是抓包工具，不是协议分析工具，它在OSI第三/四层干活，到了第七层就是边界。

3. 编程题复盘：Shell提取游戏日志 + Python统计在线峰值

3.1 题目形态与真实场景的映射

畅游的编程题没有出算法，考的是和业务日志强相关的两类场景。

第一道Shell题：给定一个游戏服务器访问日志（某个入口网关的access log），格式大概是IP 时间 请求路径 状态码 响应耗时，要求统计出当天Top 10的请求来源IP，并输出每个IP的请求次数。这道题哪怕不写Shell，用awk一行流也能过，但它有一层隐含考点：当日志文件超过1GB，甚至几个GB时，你写的脚本还能不能跑完。你不说，但面试官希望你主动考虑。

我的解法是分两步：先用awk做统计，再排序取前10。awk '{count[$1]++} END {for (ip in count) print count[ip], ip}' access.log | sort -rn | head -10。但这里有个小坑：awk的数组是保存在内存里的，如果IP基数极大（比如几十万个独立IP），内存占用会比较高。在实际场景中，更稳妥的做法是先按IP做初步分组，或者直接用sort配合uniq -c，让外部排序来兜底。笔试环境下不需要过度设计，但你可以在注释里写一句"如果内存不足，可以换用hash分桶再合并"，面试官一般都会注意到。

第二道Python题：给定一个记录了所有玩家登录登出时间戳的文件，文件格式是uid, login_ts, logout_ts，要求统计全天在线人数峰值和峰值出现的时间段。这道题不涉及到什么高深算法，核心是"差分数组/事件驱动"的思路：把所有login时间记作+1，logout时间记作-1，然后按时间排序，依次累加，用当前值和历史最大值做比较，就能在O(n log n)复杂度内算出在线峰值。

我当时看到这道题还挺兴奋，因为这就是典型的"活动开始+1、活动结束-1、随时更新max"的模型，和直播弹幕峰值、接口QPS峰值是一样的套路。但真正让我觉得有价值的是它背后的应用场景：游戏运维日常要关注同时在线人数（CCU），如果CCU突增，一台数据库或网关可能扛不住；如果CCU掉得异常快，可能说明服务器出了问题或者版本更新劝退了玩家。会写这个脚本，对应的就是在监控系统里做一个"按时间段聚合在线数"的数据模块。

3.2 Shell脚本里的防御式写法

编程题评分不只看结果，还会看脚本健壮性。我给自己定的及格线是：能处理空文件、能兼容字段缺失、输出不夹带无关信息。

比如一条日志可能是乱序的，或者有一行的某个字段没值，在Shell里就得注意字段编号，不能直接$NF就当成耗时，因为一条异常日志的字段数可能只有计划的一半。我写的时候习惯先做一步字段数检查：awk 'NF>=5 { ... }' file。这算是一个小细节，但很多考生会忽略，导致整个统计结果偏差。

Python题同理，要处理时间戳格式不统一、uid重复（比如断线重连）的情况。断线重连这块特别重要：如果玩家先掉线再登录，但没有logout记录，你的统计就会多算一个人。笔试题里虽然没有把数据做成脏数据，但你在答案里主动写了"异常数据处理"逻辑，会明显比其他候选人高一个档次。

另外，我在写完脚本后，会顺手用time跑一下，把耗时写在注释里，比如"处理200万行耗时3.2秒"。这个行为不一定加分，但它传递了一个信息——你是真的在意线上性能的人，而不是"只要跑出结果就行"的学生思维。

4. 故障排查题：线上数据库连接数被打满，你的排查链路是什么

4.1 连不上数据库的时候，第一步先别慌

畅游的卷子里有一道场景题，几乎可以说是每届必考：某个游戏区服的玩家突然全部无法登录，后端服务报"Too many connections"；给出你的排查步骤。这道题没有标准答案，但它考察的是一个运维开发工程师的排查方法论——你的第一反应，是打开搜索引擎，还是沉着地看数据。

我的排查链路如下：

1. 先看数据库当前连接数和连接来源。执行SHOW PROCESSLIST;、SHOW STATUS WHERE Variable_name='Threads_connected';，立刻确认连接数是否真的打满，以及打满它的都是哪些IP、哪些账号。
2. 看连接状态是哪一阶段。是通过了鉴权在sleep，还是正在执行慢SQL，还是state显示"Waiting for table metadata lock"？这三类状态对应完全不同的解法。
3. 看是不是应用从连接池出去的连接没收回。最常见的就是Java应用或Python应用里的连接池最大连接数配置过大，比如应用开了100个实例，每个实例连接池100，数据库最大连接数却只配了1000，瞬间就能打满。这也是我最先看应用层的原因。

如果Threads_connected已经达到max_connections，我不建议一上来就直接改max_connections把上限调大，因为那通常只是把问题延后，真正的原因没找到，明天同一时间还会再次打满。正确的操作是：先临时把max_connections调大一点（比如从1000调到2000，注意内存上限），让服务先恢复，再立刻查慢查询日志、processlist，定位到底是谁把连接占着不释放。

4.2 如何区分"慢SQL导致"和"连接泄露导致"

这道场景题的进阶追问点是：如果你在processlist里看到大量time很大的SQL，分析方向是什么？如果你看到大量state为Sleep、time几十秒上百秒的连接，又是怎么处理？

前者是典型的SQL性能问题——缺少索引、单表数据量过大、复杂join、锁等待。处理方式：explain看执行计划，强制加上合适索引，或者跟开发商量改写SQL；必要时用pt-query-digest分析慢查询日志，把Top SQL抓出来。后者则是连接池或代码层面的问题——某个线程拿连接后没有归还。处理方式：去应用日志里找堆栈，看是哪个接口在持有连接不释放，或者把连接池的maxLifetime、idleTimeout调小，逼它回收。

还有一个我特别想强调的细节：排查时别只盯着数据库本身。2019年那会儿Redis已经大面积使用，如果数据库连接被打满是因为缓存雪崩——大量请求绕过Redis直接打到MySQL，那你光查MySQL是永远查不完的。所以排查链路里一定要有一环是"看缓存命中率、看上游调用链"，把视野拉到整个调用链路，而不是盯着一个单点。

提示：线上故障处理的第一原则是"先恢复，再根因"。不要试图在一个正在过载的数据库上做长时间的性能分析，先通过扩容、限流、改配置等方式把火扑灭，再降级到安全环境里慢慢复盘，这样才是成熟运维的做事方式。

4.3 复盘报告怎么写才显得专业

这类题目有时候还会附加一问：故障处理完之后，需要输出一份复盘报告，你怎么写？我见过很多候选人的回答只写了"我修好了数据库，调大了连接数，完事"——这种答案基本是0分。

一份合格的故障复盘至少要包含四个部分：故障时间线与操作记录（几点发现、几点定位、几点恢复、中间做了哪些操作）、根因分析（不只是"连接数打满"，要挖到"为什么打满"）、临时措施与长期改进项、谁来跟进和截止时间。笔试里写清楚这几块，面试官就能看出你有很好的生产意识，而不只是会敲命令。

5. 设计题：给一款MMO游戏项目组设计监控与发布体系

5.1 监控体系怎么分层，指标怎么选

这套笔试题的最后一道大题，是给一个MMO游戏项目组设计一套监控体系。MMO的特点非常鲜明：服务器数量多、逻辑复杂、玩家在线时长大、对延迟极敏感、维护窗口有时间限制。所以监控体系不能只是"装一个Zabbix，添加几台主机"，而是要覆盖基础设施、中间件、应用、业务四个层面。

我的答题思路分四层：

• 基础设施层：CPU、内存、磁盘、网络、硬件告警，用node_exporter或Zabbix Agent采集。
• 中间件层：MySQL（连接数、慢查询、主从延迟）、Redis（命中率、内存碎片、阻塞命令）、Kafka/RabbitMQ（堆积量、消费延迟）。
• 应用层：Java/Python进程的GC、线程池、接口RT、错误率、服内玩家心跳延迟。这部分更推荐用Prometheus + Grafana做指标采集和可视化，因为它的多维标签体系很适合按区服、按玩法维度聚合。
• 业务层：在线人数（CCU）、登录成功率、支付成功率、副本进入失败率、包体下载失败率。业务层指标通常需要开发配合埋点，不能全靠黑盒探测。

分层设计的好处是，故障发生时你可以快速固定范围：如果基础设施层没有明显异常，就去看中间件层；如果中间件也正常，就看应用层和业务层。这种"漏斗式"排查路径在游戏运维里非常实用，因为MMO的故障往往是发生在某一层，而不是全局崩盘。

5.2 告警分级与自愈：别让告警变成噪音

我在设计题里特意加了一个"告警分级"小节。很多候选人会把Zabbix/Prometheus的告警规则写得密密麻麻，完全没有分级，结果就是运维兄弟半夜被无关紧要的告警轰炸，真正重要的故障反而被淹没。

我的分级方案是：

P0和P1必须有电话/短信强告警，P2和P3走IM群通知就够。这里有一个关键思想：告警是为了让人做出决策，不是为了制造噪音。如果一条告警从来没有人认真处理过，它就不配存在。

自愈部分，2019年的笔试题没有那么前沿，但我会答上"面对常规问题可以先通过脚本自动处理"。比如发现某个游戏服负载持续偏高时，可以自动拉起同配置的新服做分流；发现磁盘空间不足时，自动清理过期的日志归档。但自愈必须带"熔断"机制——如果自动化脚本连续失败三次，必须停止操作并升级人工，否则就会变成故障放大器。

5.3 灰度发布和回滚方案：游戏版本的运维难点

设计题里另一部分考察发布体系，因为游戏维护和发版是家常便饭。游戏发版有个特殊难点：客户端更新是异步的，玩家可能还有人卡在旧版本，而服务器端必须要做到"新旧版本同时兼容一段时间"；同时游戏内配置表经常和代码一起发，又要保证数据一致性。

我的回答框架是：

1. 先灰度，再全量。先在一个小区服上发新版本，观察日志、错误率、玩家反馈，验证稳定后再扩展到更多区服。2019年K8s已经比较成熟，可以用Deployment的滚动更新策略，先提高maxUnavailable和maxSurge的步长来控制灰度粒度。
2. 配置和代码分离。游戏策划经常改数值，不可能每次都发二进制包。配置中心（Apollo或自研）负责动态下发配置，数据库变更用专门的migration脚本管理，保证可重复执行、可回滚。
3. 回滚预案。发布前就准备好回滚到上一个版本的镜像/包，数据库变更要做"前滚兼容"设计——新代码在老表结构上也能跑，老代码在新表结构上也不能崩。这个"双可运行"原则，是游戏运维最容易栽跟头的地方。
4. 发布窗口控制。MMO一般在凌晨低峰期维护，但整个发布过程要尽可能缩短。把检查项（备份、配置校验、DB迁移检查）提前做成脚本，避免到了半夜才手忙脚乱。

设计题不要求写出能跑的代码，它真正考察的是你有没有见过一个复杂的系统是怎么被"安全地变更"的。能写出"灰度、回滚、兼容、备份"这几个关键词背后的逻辑，这道题就已经稳了。

6. 校招备考的真实建议与个人体会

最后聊点备考层面的东西，这部分可能比具体某道题更值得你收藏。

运维开发这个岗位，绝对不是"运维+开发"两张皮。我见过很多候选人，Linux基础很扎实，但让他写一个自动化脚本就暴露了——要么是满屏的临时变量、硬编码路径、没有函数封装，要么是脚本一遇到异常输入就崩。搜狐畅游的笔试题虽然不会直接考软件工程，但你在编程题和设计题里展现的代码组织能力，面试官一眼就能看出来。我的建议是：备考阶段把日常的运维操作尽量"脚本化"和"工具化"，不要满足于"手动敲命令能通"，而是想想"如果这条命令要每天跑、要在100台服务器上跑，我应该怎么封装"。

多练场景题，少背八股。2019年是运维模板化考题还比较流行的时候，很多人还在背"iptables五链四表""TCP三次握手四次挥手"的八股，但这套题明显更偏重"线上出了问题你怎么去判断"。我当时给自己做训练的方法是：收集真实的生产故障案例（公司内部、开源社区、技术博客），不看解法，只凭自己的知识储备一步步写排查方案，然后再对照别人的复盘，找差距。这个习惯回头看特别有用，因为畅游的故障排查题，本质上就是在模拟真实的生产事故。

笔试时学会"展示过程"。很多人做设计题只写结论——"用Zabbix做监控，用K8s做发布"——然后就没了。但笔试题的得分点往往在你的思考过程里。我习惯在卷子上写清楚"为什么选型A而不是B""如果遇到这个边界情况怎么处理""系统的瓶颈会在哪里"。哪怕字迹丑、框架乱，只要思路清晰，面试官是能看出来的。

当年的遗憾与收获。我自己当年在这套题上栽过一个小跟头：Shell统计题的日志格式里有个字段是"HTTP状态码+响应耗时"混在一起，中间用冒号分割，我没仔细看，直接拿$NF当耗时用了，导致最后统计结果差了好几个数量级。笔试后复盘才意识到，这就是真实日志解析的常态——字段永远没有你想象的那么规整。这个教训到现在都刻在我脑子里：处理任何日志之前，先head几行看看格式，再动手写处理逻辑。这比什么都重要。