每年秋招季刷题都是绕不开的一道坎。今天想聊聊搜狐畅游2019年校招的那套运维开发工程师笔试题。当年这道题在圈子里流传挺广的不光是游戏行业很多互联网公司后端的运维开发岗出题思路都和它大同小异。我把它拿出来重新拆一遍不是因为题目本身多难而是它非常典型既不堆砌冷门知识点又能在基础题里看出一个人是不是真的写过脚本、碰过服务器、处理过线上问题。如果你正在准备运维开发工程师方向的校招或者想从传统运维转岗到 DevOps 方向这篇文章应该能帮你省不少瞎折腾的时间。我会把这类笔试题背后的考点逻辑、常见题型、答题思路以及我当年踩过的坑全部摊开来讲清楚。整套题吃透了再去面同类岗位心里会踏实很多。1. 岗位画像与笔试题的命题逻辑1.1 运维开发工程师到底是个什么岗位先说岗位本身。运维开发工程师也叫 DevOps 工程师、SRE不同公司叫法不一样和传统运维最大的区别在于传统运维的核心是“守住线上”关注的是不宕机、不丢数据、及时响应而运维开发的核心是“把运维工作自动化、平台化”也就是要用代码来解决运维问题。这套题选在 2019 年出其实很有代表性。那会儿容器化已经开始普及CI/CD 概念深入人心很多公司都在从“人肉运维”向“平台化运维”转型。搜狐畅游作为游戏公司对运维的要求更偏向高并发、高可用、大批量服务器的管理能力。游戏行业的特性决定了他们在笔试中会更看重Linux 基础扎不扎实、会不会写脚本、懂不懂常见的故障排查手段、有没有基本的数据库和网络功底。这些能力对应届生来说就是“能直接上手干活”的信号。1.2 这类笔试题想筛选什么样的人很多同学刷题时容易陷入一个误区觉得笔试就是比谁背的面试题多。实际上命题人想要的答案往往是“你知道原理并且能用自己的话讲清楚”的答案而不是“你背过某篇博客里的标准答案”的答案。从搜狐畅游这套题的风格来看它考查的重点可以归纳成四个维度基础广度操作系统、网络、数据库这些计算机基础知识是硬门槛不过关直接淘汰。实战敏感度题目常常会给一个具体场景比如“服务器负载过高你如何排查”考察的是你有没有真实处理过问题的经验。编码能力运维开发要有开发能力纯 Shell 不算数Python 至少得能写脚本、能处理文本、能调用 API。学习与表达有些开放题没有标准答案看的是你的思路是否清晰表达是否有逻辑。换句话说这套题不是在考“你会什么”而是在考“你能解决什么”。你回答时踩到的每一个得分点背后都对应着一个实际运维场景。2. 笔试题型全景拆解每道题都在问什么2.1 Linux 基础与常用命令这一块几乎是所有运维岗位笔试的必考项搜狐畅游的题也不例外。题目形式通常是给一个场景让你写出用到的命令、参数和理由。常见的场景包括查看系统负载情况uptime、top、vmstat、mpstat查找 CPU 占用最高的进程top进入后按P键排序或者用ps aux --sort-%cpu | head查看磁盘占用并找出大文件df -h、du -sh *、find / -type f -size 1G分析日志中某个错误出现的次数grep ERROR app.log | wc -l定时任务管理crontab -e、crontab -l还有系统定时任务目录/etc/cron.d/这里我要特别提醒一句不要只背命令要理解命令的输出含义。比如load average的三个数值分别代表什么如果 1 分钟负载是 105 分钟是 515 分钟是 2说明什么答案是系统负载正在快速上升可能有问题在发生。这种追问才是笔试里真正拉开差距的地方。2.2 网络基础与排查能力网络知识在运维开发笔试里占的比重也不小因为绝大多数线上故障都跟网络有关系。出题方向一般集中在下面几块TCP 三次握手和四次挥手的过程以及为什么是三次不是两次HTTP 状态码的含义比如 301、302、403、404、500、502、504 分别代表什么DNS 解析过程包括递归查询和迭代查询的区别常用排查命令ping、telnet、nc、traceroute、ss、netstat、tcpdump我印象很深的一道题是“用户在浏览器里输入网址到看到页面的过程涉及哪些协议越详细越好”。这题其实就是把网络基础串起来考DNSUDP/TCP 53→ TCP 三次握手 → HTTP 请求 → 服务器处理 → HTTP 响应 → TCP 四次挥手。你能写出每一步、每个协议的作用基本就能拿满分。2.3 Shell 和 Python 脚本能力既然是运维开发脚本能力是重头戏。搜狐畅游的笔试题里编程题通常不要求你用某种特定语言但 Shell 和 Python 你至少得熟练一个。题目类型大致有写一个 Shell 脚本统计日志中某个字段的出现次数写一个 Python 脚本批量处理文件、批量 SSH 执行命令写脚本实现“监控某个进程如果挂了就自动拉起”写脚本实现“对 N 台服务器做批量文件分发”说实话这类题不难但很考验基本功。拿“批量 SSH 执行命令”来说很多人会想到用for循环加ssh但如果在真实环境中你还要考虑免密登录配置、超时处理、并发控制、错误日志记录。笔试题可能只要求基础版但你在答题时如果能多写一个“异常处理”或“并发控制”面试官就会觉得你确实有实战经验。2.4 数据库、缓存与常见中间件游戏公司对数据库的要求比较高因为游戏业务的数据一致性、实时性都很敏感。笔试题里常见的有MySQL 索引的原理B 树为什么适合做索引写出一个 SQL查询表中某个条件下的记录并考虑索引是否生效Redis 的数据类型有哪些分别适用什么场景什么是缓存穿透、缓存击穿、缓存雪崩如何解决消息队列Kafka/RabbitMQ的基本概念和使用场景这些题看着多但其实都有套路。复习的时候你不需要把每个中间件的源码都读一遍核心是把“是什么、解决什么问题、怎么用、有什么坑”这四件事搞清楚就够用了。2.5 容器化、CI/CD 与监控体系2019 年那会儿 Docker 和 Kubernetes 已经非常火了所以这套题里也出现了容器和 CI/CD 相关的题目。你别指望它考你特别深的 K8s 运维知识但基本的Docker 镜像和容器的区别是什么写一个 Dockerfile 部署一个简单应用Jenkins 的构建流程、Pipeline 的基本概念蓝绿发布、灰度发布、滚动发布的区别监控体系怎么搭通常是 Zabbix/Prometheus Grafana现在的题更偏向 Prometheus这里我想多说一句笔试遇到容器题不要只背概念。比如“Docker 镜像和容器的区别”很多人能说出“镜像是模板容器是运行实例”但如果再追问一句“容器启动时发生了什么”很多人就卡住了。实际上容器启动就是镜像层 可写层 进程隔离 namespace 的组合你能把这个链路讲清楚才算真懂。2.6 算法与基础编程有些同学可能不理解为什么运维开发岗也考算法其实不奇怪运维开发一样需要写代码处理数据、设计系统。不过这类岗位的算法题通常不会太偏太难常见的有字符串处理反转字符串、判断回文、统计字符出现次数数组操作去重、排序、求最大值、合并两个有序数组简单数据结构栈、队列、链表的操作搜索类二分查找、DFS/BFS 的简单应用重点不在题本身而在于你要能用一种语言干净利落地写出来。哪怕时间复杂度不是最优只要逻辑清晰、边界处理齐全也能拿不错的分数。3. 核心考点深度解析为什么经常有人在这些题上翻车3.1 TCP 三次握手为什么不能是两次这道题几乎是网络部分的必考题但大部分人回答得都很浅。我见过最常见的回答是“三次握手可以确认双方的发送和接收能力都正常。”这没错但不够。要回答好这道题你得从“连接的本质是分配资源”这个角度去讲。如果只有两次握手服务端在收到 SYN 后就会分配连接资源、进入 ESTABLISHED 状态。问题在于如果客户端第一次发的 SYN 因为网络延迟很久之后才到达服务端服务端把这当做一个新连接来建立分配了资源而客户端其实早就放弃了这次连接不会响应服务端的 SYNACK。这样一来服务端的资源就被白白占用大量这种情况会导致 SYN 泛洪攻击。四次握手当然也可以但三次已经足够少一次不行多一次浪费。你能把“资源浪费”和“历史延迟连接导致的问题”这两点讲清楚面试官就知道你是真的理解而不是背答案。3.2 一条慢 SQL 的排查与优化思路数据库题里最经典的就是慢 SQL。我记得搜狐畅游这套题里有一个场景是“线上有个查询特别慢你怎么排查和优化”这类题不需要你写出最终答案而是考你的排查思路。我的建议是按照下面的顺序来答开启慢查询日志确认慢 SQL 的具体内容。用EXPLAIN查看执行计划重点看 type 字段、key 字段、rows 字段。判断是否走了索引。如果 type 是 ALL说明是全表扫描大概率没走索引。分析为什么没走索引是索引没建还是查询条件里有函数/隐式转换导致索引失效还是数据区分度太低优化器认为没必要走针对性优化加索引、改写 SQL、调整查询条件、把大事务拆小。如果单表数据量太大考虑分库分表或者引入搜索引擎。答题时如果你能把这个链路完完整整地写出来再补一句“索引不是越多越好写多读少的表索引多了反而影响插入性能”这题基本就稳了。3.3 写一个健壮的监控脚本需要注意什么“写一个脚本监控进程挂了自动拉起”这道题好像人人都会写但真正能写出亮点的人不多。普通版本是这样的#!/bin/bash while true; do if ! pgrep -f myapp /dev/null; then nohup /usr/local/bin/myapp fi sleep 5 done这能实现功能但问题很多没有日志、没有去重保护、没有考虑进程启动失败的情况、没有处理“进程还在但僵死”的情况。我在笔试时改进版基本是这样的思路#!/bin/bash # 监控 myapp 进程如果不在就拉起避免重复启动 LOG_FILE/var/log/myapp_monitor.log LOCK_FILE/tmp/myapp_monitor.lock log() { echo $(date %Y-%m-%d %H:%M:%S) [$1] $2 $LOG_FILE } # 防止脚本自身重复运行 exec 9$LOCK_FILE if ! flock -n 9; then log ERROR another monitor instance is running, exit. exit 1 fi while true; do # 判断进程状态排除 grep 自身 if ! pgrep -x myapp /dev/null 21; then log WARN myapp is down, try to start... nohup /usr/local/bin/myapp /var/log/myapp.log 21 # 启动后确认一次 sleep 2 if pgrep -x myapp /dev/null 21; then log INFO myapp started successfully else log ERROR myapp start failed, need manual check fi fi sleep 5 done核心改进点有三个一是加了文件锁避免脚本因为 crontab 或人为误操作被重复执行后拉起多个进程二是加了日志任何一次拉起动作都有据可查三是启动后做一次确认避免“以为拉起来了其实根本没起来”的假象。笔试的时候你不需要写这么长但你要把“锁、日志、启动确认、异常处理”这几个关键词说出来面试官一看就知道你有实战意识。3.4 监控告警体系的设计思路这也是开放题里出现频率很高的一道“假设你现在要为一个有 100 台服务器的业务设计监控告警你怎么做”这种题没有标准答案但高分回答有几个共性分层设计从基础设施层CPU、内存、磁盘、网络→ 中间件层Nginx、MySQL、Redis→ 应用层接口耗时、错误率→ 业务层订单量、PV/UV逐层覆盖。数据采集方式Agent 采集如 Prometheus Node Exporter vs 日志采集ELK vs 埋点。告警规则要有合理的阈值和持续时长避免抖动就报警。比如 CPU 使用率 80% 持续 5 分钟才触发而不是瞬时超过就报。告警分级P0 立即短信/电话P1 邮件IMP2 记录在案次日处理。告警去重与降噪同一故障不要给所有人发重复告警要考虑告警聚合和静默期。这类题考察的其实是系统设计能力。你如果没实际搭过监控平台至少要能画出整体的采集链路讲清楚数据是从哪来的、怎么存的、怎么展示的、怎么告警的把链路理清楚就已经是合格答案了。4. 一套可复现的刷题与实战路径4.1 常见笔试题型自测清单下面这份清单不是搜狐畅游的原题而是我根据同类运维开发笔试题提炼出的“高频自测题”。建议你关闭搜索引擎先尝试自己回答一遍再对照我给的要点查漏补缺题目考察点答题要点如何查找日志中访问量最高的前10个IPShell/文本处理awk {print $1} access.log解释nohup和的区别进程管理是后台运行nohup是忽略挂断信号通常配合使用NGINX 返回 502 是什么原因网络/中间件后端服务不可用、fastcgi 超时、连接数耗尽、防火墙拦截等Python 按行读取文件过滤含“ERROR”的行Python 基本功with open上下文管理配合if ERROR in line描述一次你独立排查线上故障的经历综合能力按“现象→定位→修复→复盘”四步来写突出数据和时间点一个用户的请求从发出到返回经过哪些环节系统全链路客户端→DNS→LB→Web服务器→应用→缓存/DB→响应这些题你要能不看资料写出至少六七成的答案说明基础已经够用了。4.2 实操题目实现一个日志统计脚本我们来做一道具体的题完整写一遍。题目是“有一个 Nginx 的 access.log每行格式为IP - - [日期] 请求 状态码 响应大小请统计状态码是 500 的请求数并输出这些请求的 IP 列表按出现次数从高到低排序。”用 Shell 实现#!/bin/bash LOG_FILE/var/log/nginx/access.log echo 500 状态码总数 awk $9 500 $LOG_FILE | wc -l echo 按 IP 统计 500 请求次数 awk $9 500 {print $1} $LOG_FILE | sort | uniq -c | sort -rn用 Python 实现import re from collections import Counter log_file /var/log/nginx/access.log counter Counter() with open(log_file, r, encodingutf-8) as f: for line in f: # 简单分割Nginx 默认格式中第9个字段是状态码 parts line.split() if len(parts) 9: continue if parts[8] 500: ip parts[0] counter[ip] 1 total_500 sum(counter.values()) print(f 500 状态码总数: {total_500} ) print( 按 IP 统计 500 请求次数 ) for ip, cnt in counter.most_common(): print(f{cnt}\t{ip})这种题目看着简单但有几个隐藏的细节值得注意一是 Nginx 日志格式可能不是标准的字段位置可能不同二是日志中可能混入畸形行要加判断三是如果文件很大几个 GB用 Python 逐行读取、用 Counter 统计内存占用不会太高但如果你用readlines()一次性读入内存就会爆掉。你能在答案里主动说出这几个点就是加分项。4.3 学习路径建议3~4 周冲刺方案如果你时间紧张我建议按下面的节奏来复习。这套路径是我从多份成功上岸的同学的复习计划里提炼出来的比较均衡第1周夯实 Linux 和网络基础。每天花 2 小时过知识点1 小时做实操。重点把top、ps、df、ss、tcpdump这些命令的输出彻底看懂而不是只会敲。网络部分把 TCP 握手、HTTP 状态码、DNS 流程理清。第2周攻 Shell 和 Python 脚本。每天写 2~3 个小脚本比如日志清洗、批量建用户、批量检查端口连通性。不用追求花哨但要保证自己能不查资料写出一个带函数、带参数校验、带日志输出的完整脚本。第3周补数据库、缓存、中间件和容器知识。用 MySQL 官方文档把一个简单的表设计出来练习EXPLAIN看执行计划把 Redis 五种数据结构过一遍能写一个最简单的 Dockerfile 并构建运行。第4周刷题 模拟面试。把历年真题、牛客网、LeetCode 上标签为“运维/Shell”的题过一遍每天做一次完整的限时模拟。这个计划的关键不在于“学完”而在于“能输出”。每日复盘只问自己一个问题今天学的这些如果让我写出来或讲出来我能讲清楚吗5. 实战踩坑记录准备这类笔试容易犯的错5.1 只背命令不看输出这是我最想强调的一点。很多人复习 Linux 时背了一堆命令和参数但到了笔试让写“查看端口占用情况”的输出就懵了。我当年备考时就吃过这个亏。我记得很清楚有一次模拟题问“ss -tlnp输出中 Local Address 是0.0.0.0:80和[::]:80有什么区别”我答不上来。后来才搞明白前者是 IPv4 监听所有地址后者是 IPv6 监听所有地址。这就是典型的“会敲命令但不会看输出”的问题。建议你复习的时候每个命令至少跑三次分别观察正常情况的输出、异常情况的报错、参数不同时的差异。把输出当成“阅读材料”来学而不是把命令本身当重点。5.2 手撕代码只写思路不写完整代码笔试题和你平时 LeetCode 刷题不太一样它的判分点往往在“能不能跑通”和“边界处理全不全”。很多人回答脚本题时写了核心几行就停笔了比如统计 IP 只写awk {print $1}后面排序、去重、统计全不写让人感觉“懂一点但没落地”。我自己后来总结的经验是宁可代码多写几行也要保证逻辑闭环。一个脚本函数必须有输入参数校验、核心处理逻辑、输出结果三部分。哪怕你有一个函数忘了写也要通过注释表达出来让阅卷人看到你的完整思路。5.3 忽视说明“为什么”很多同学答题时只写“怎么做”不写“为什么这么做”。比如题目问“服务器 CPU 高怎么排查”你的回答是“用 top 看哪个进程高然后 kill 掉”。这只能得基础分。更好的回答是先top看整体负载再按 CPU 排序找到高占用进程用top -Hp pid查看该进程内哪个线程占用高结合strace或perf看系统调用和热点函数根据线程号和业务日志定位到具体代码评估是代码死循环、锁竞争、还是 GC 频繁。你把每一步的“为什么”都写出来阅卷人就能感受到你是真的理解排查逻辑而不是背了一套命令组合。5.4 不知道什么时候该说“不知道”面试和笔试里都有一种陷阱题超纲的问题。比如“Kubernetes 里 CNI 插件的工作原理是什么”如果你完全没接触过硬编一个答案反而扣分。更稳妥的回答是“这部分我了解得不够深我目前的理解是……但我对它的网络模型还不是特别清楚后续我会补上。”既展示了诚实又展示了学习意愿。6. 准备过程中值得沉淀的几个习惯6.1 建一个自己的排障手册运维开发笔试的很多题目本质上都是在问“遇到问题你怎么办”。如果你能建立一份自己的排障手册把每一次遇到的线上问题、排查过程、根因、解决方案记录下来你的答题素材库就会越来越厚。我的手册结构很简单问题现象一句话描述影响范围哪些服务、多少用户受影响排查时间线几点几分做了什么操作结果如何根因分析为什么会发生解决方案短期怎么止血长期怎么根治复盘哪些地方可以提前发现面试时如果遇到“讲一个你印象最深的故障”你直接从手册里挑一个按这个结构讲信息密度和逻辑性都会比现场想好太多。6.2 动手搭一套自己的运维环境光靠刷题很难应对越来越偏实战的笔试题。我强烈建议你在自己的电脑上搭一套可以折腾的实验环境用 VirtualBox 或 VMware 装一台 CentOS/Ubuntu 虚拟机在上面部署 Nginx、MySQL、Redis写一个简单的 Python/Flask 应用用 Docker 把应用容器化搭一个最简单的 CI/CD 流水线GitHub Actions 或者本地 Jenkins这套环境花不了太多时间但能让你对所有笔试考点有一个直观的认知。尤其是容器和 CI/CD 部分你亲手跑过一遍构建部署流程笔试里遇到“如何实现一个自动化部署脚本”这样的题目思路就完全不一样了。6.3 刷题要输出不要只输入到最后阶段每天刷完题以后我建议你做一件事把当天做过的题用自己的话写成一篇简短的笔记或者假装在给一个新人讲题。能讲明白才是真会。这个方法听上去很简单但实际效果比我试过的任何刷题方法都好推荐你试试。7. 从笔试到 Offer多走一步的加分项7.1 简历里写项目经验时突出“自动化”和“数据”运维开发岗的简历项目经验不需要写“我部署了一个网站”这种流水账重点在于你解决了什么问题。同样一个项目普通版写的是“负责搭建测试环境部署应用”。升级版可以写成“负责搭建基于 Docker Jenkins 的自动化测试环境将原本每次约 40 分钟的人工部署流程压缩到 8 分钟并将部署成功率从 85% 提升到 99.5%通过钉钉机器人实时推送构建结果。”突出量化数据用代码解决重复劳动这是面试官最想看到的。7.2 笔试之外的“软加分项”运维开发的笔试题虽然重要但最终能不能拿到 Offer还取决于几个笔试之外的环节沟通能力运维开发经常要承接开发和运维两边的问题沟通能力直接影响工作效率。笔试里体现不出这点但面试一定会问。责任感与细心的程度运维的线上操作容错率很低一次误操作可能导致全站故障。面试官会通过追问细节来判断你是不是一个细心的人。持续学习的能力运维技术栈更新速度极快面试官问“你最近在学什么”其实是在考察你的学习动力和方法。笔试只是第一关后面还有面试、HR 面、谈薪每一个环节都需要认真准备。7.3 拿到 Offer 之后别急着停止学习如果你真的拿到了运维开发工程师的 Offer那恭喜你但这只是起点。游戏公司对线上稳定性要求极高新人入职后要学的东西更多具体的监控平台、内部的发布系统、业务架构、容灾方案。笔试里学的那些知识是你在新环境里站稳脚跟的基石而不是终点。从我接触过的同学来看能在校招里拿到运维开发 Offer 的人普遍有一个共同点他们不是“考试型选手”而是真的对系统、对自动化、对故障排查有兴趣。笔试只是他们平时积累和思考的自然结果。与其焦虑地刷题不如静下心来把基础打牢多动手实践多复盘总结。面试官每天面很多人你有没有真本事几句话就能探出来。 运维开发笔试题解析：搜狐畅游校招考点与备考实战指南
每年秋招季刷题都是绕不开的一道坎。今天想聊聊搜狐畅游2019年校招的那套运维开发工程师笔试题。当年这道题在圈子里流传挺广的不光是游戏行业很多互联网公司后端的运维开发岗出题思路都和它大同小异。我把它拿出来重新拆一遍不是因为题目本身多难而是它非常典型既不堆砌冷门知识点又能在基础题里看出一个人是不是真的写过脚本、碰过服务器、处理过线上问题。如果你正在准备运维开发工程师方向的校招或者想从传统运维转岗到 DevOps 方向这篇文章应该能帮你省不少瞎折腾的时间。我会把这类笔试题背后的考点逻辑、常见题型、答题思路以及我当年踩过的坑全部摊开来讲清楚。整套题吃透了再去面同类岗位心里会踏实很多。1. 岗位画像与笔试题的命题逻辑1.1 运维开发工程师到底是个什么岗位先说岗位本身。运维开发工程师也叫 DevOps 工程师、SRE不同公司叫法不一样和传统运维最大的区别在于传统运维的核心是“守住线上”关注的是不宕机、不丢数据、及时响应而运维开发的核心是“把运维工作自动化、平台化”也就是要用代码来解决运维问题。这套题选在 2019 年出其实很有代表性。那会儿容器化已经开始普及CI/CD 概念深入人心很多公司都在从“人肉运维”向“平台化运维”转型。搜狐畅游作为游戏公司对运维的要求更偏向高并发、高可用、大批量服务器的管理能力。游戏行业的特性决定了他们在笔试中会更看重Linux 基础扎不扎实、会不会写脚本、懂不懂常见的故障排查手段、有没有基本的数据库和网络功底。这些能力对应届生来说就是“能直接上手干活”的信号。1.2 这类笔试题想筛选什么样的人很多同学刷题时容易陷入一个误区觉得笔试就是比谁背的面试题多。实际上命题人想要的答案往往是“你知道原理并且能用自己的话讲清楚”的答案而不是“你背过某篇博客里的标准答案”的答案。从搜狐畅游这套题的风格来看它考查的重点可以归纳成四个维度基础广度操作系统、网络、数据库这些计算机基础知识是硬门槛不过关直接淘汰。实战敏感度题目常常会给一个具体场景比如“服务器负载过高你如何排查”考察的是你有没有真实处理过问题的经验。编码能力运维开发要有开发能力纯 Shell 不算数Python 至少得能写脚本、能处理文本、能调用 API。学习与表达有些开放题没有标准答案看的是你的思路是否清晰表达是否有逻辑。换句话说这套题不是在考“你会什么”而是在考“你能解决什么”。你回答时踩到的每一个得分点背后都对应着一个实际运维场景。2. 笔试题型全景拆解每道题都在问什么2.1 Linux 基础与常用命令这一块几乎是所有运维岗位笔试的必考项搜狐畅游的题也不例外。题目形式通常是给一个场景让你写出用到的命令、参数和理由。常见的场景包括查看系统负载情况uptime、top、vmstat、mpstat查找 CPU 占用最高的进程top进入后按P键排序或者用ps aux --sort-%cpu | head查看磁盘占用并找出大文件df -h、du -sh *、find / -type f -size 1G分析日志中某个错误出现的次数grep ERROR app.log | wc -l定时任务管理crontab -e、crontab -l还有系统定时任务目录/etc/cron.d/这里我要特别提醒一句不要只背命令要理解命令的输出含义。比如load average的三个数值分别代表什么如果 1 分钟负载是 105 分钟是 515 分钟是 2说明什么答案是系统负载正在快速上升可能有问题在发生。这种追问才是笔试里真正拉开差距的地方。2.2 网络基础与排查能力网络知识在运维开发笔试里占的比重也不小因为绝大多数线上故障都跟网络有关系。出题方向一般集中在下面几块TCP 三次握手和四次挥手的过程以及为什么是三次不是两次HTTP 状态码的含义比如 301、302、403、404、500、502、504 分别代表什么DNS 解析过程包括递归查询和迭代查询的区别常用排查命令ping、telnet、nc、traceroute、ss、netstat、tcpdump我印象很深的一道题是“用户在浏览器里输入网址到看到页面的过程涉及哪些协议越详细越好”。这题其实就是把网络基础串起来考DNSUDP/TCP 53→ TCP 三次握手 → HTTP 请求 → 服务器处理 → HTTP 响应 → TCP 四次挥手。你能写出每一步、每个协议的作用基本就能拿满分。2.3 Shell 和 Python 脚本能力既然是运维开发脚本能力是重头戏。搜狐畅游的笔试题里编程题通常不要求你用某种特定语言但 Shell 和 Python 你至少得熟练一个。题目类型大致有写一个 Shell 脚本统计日志中某个字段的出现次数写一个 Python 脚本批量处理文件、批量 SSH 执行命令写脚本实现“监控某个进程如果挂了就自动拉起”写脚本实现“对 N 台服务器做批量文件分发”说实话这类题不难但很考验基本功。拿“批量 SSH 执行命令”来说很多人会想到用for循环加ssh但如果在真实环境中你还要考虑免密登录配置、超时处理、并发控制、错误日志记录。笔试题可能只要求基础版但你在答题时如果能多写一个“异常处理”或“并发控制”面试官就会觉得你确实有实战经验。2.4 数据库、缓存与常见中间件游戏公司对数据库的要求比较高因为游戏业务的数据一致性、实时性都很敏感。笔试题里常见的有MySQL 索引的原理B 树为什么适合做索引写出一个 SQL查询表中某个条件下的记录并考虑索引是否生效Redis 的数据类型有哪些分别适用什么场景什么是缓存穿透、缓存击穿、缓存雪崩如何解决消息队列Kafka/RabbitMQ的基本概念和使用场景这些题看着多但其实都有套路。复习的时候你不需要把每个中间件的源码都读一遍核心是把“是什么、解决什么问题、怎么用、有什么坑”这四件事搞清楚就够用了。2.5 容器化、CI/CD 与监控体系2019 年那会儿 Docker 和 Kubernetes 已经非常火了所以这套题里也出现了容器和 CI/CD 相关的题目。你别指望它考你特别深的 K8s 运维知识但基本的Docker 镜像和容器的区别是什么写一个 Dockerfile 部署一个简单应用Jenkins 的构建流程、Pipeline 的基本概念蓝绿发布、灰度发布、滚动发布的区别监控体系怎么搭通常是 Zabbix/Prometheus Grafana现在的题更偏向 Prometheus这里我想多说一句笔试遇到容器题不要只背概念。比如“Docker 镜像和容器的区别”很多人能说出“镜像是模板容器是运行实例”但如果再追问一句“容器启动时发生了什么”很多人就卡住了。实际上容器启动就是镜像层 可写层 进程隔离 namespace 的组合你能把这个链路讲清楚才算真懂。2.6 算法与基础编程有些同学可能不理解为什么运维开发岗也考算法其实不奇怪运维开发一样需要写代码处理数据、设计系统。不过这类岗位的算法题通常不会太偏太难常见的有字符串处理反转字符串、判断回文、统计字符出现次数数组操作去重、排序、求最大值、合并两个有序数组简单数据结构栈、队列、链表的操作搜索类二分查找、DFS/BFS 的简单应用重点不在题本身而在于你要能用一种语言干净利落地写出来。哪怕时间复杂度不是最优只要逻辑清晰、边界处理齐全也能拿不错的分数。3. 核心考点深度解析为什么经常有人在这些题上翻车3.1 TCP 三次握手为什么不能是两次这道题几乎是网络部分的必考题但大部分人回答得都很浅。我见过最常见的回答是“三次握手可以确认双方的发送和接收能力都正常。”这没错但不够。要回答好这道题你得从“连接的本质是分配资源”这个角度去讲。如果只有两次握手服务端在收到 SYN 后就会分配连接资源、进入 ESTABLISHED 状态。问题在于如果客户端第一次发的 SYN 因为网络延迟很久之后才到达服务端服务端把这当做一个新连接来建立分配了资源而客户端其实早就放弃了这次连接不会响应服务端的 SYNACK。这样一来服务端的资源就被白白占用大量这种情况会导致 SYN 泛洪攻击。四次握手当然也可以但三次已经足够少一次不行多一次浪费。你能把“资源浪费”和“历史延迟连接导致的问题”这两点讲清楚面试官就知道你是真的理解而不是背答案。3.2 一条慢 SQL 的排查与优化思路数据库题里最经典的就是慢 SQL。我记得搜狐畅游这套题里有一个场景是“线上有个查询特别慢你怎么排查和优化”这类题不需要你写出最终答案而是考你的排查思路。我的建议是按照下面的顺序来答开启慢查询日志确认慢 SQL 的具体内容。用EXPLAIN查看执行计划重点看 type 字段、key 字段、rows 字段。判断是否走了索引。如果 type 是 ALL说明是全表扫描大概率没走索引。分析为什么没走索引是索引没建还是查询条件里有函数/隐式转换导致索引失效还是数据区分度太低优化器认为没必要走针对性优化加索引、改写 SQL、调整查询条件、把大事务拆小。如果单表数据量太大考虑分库分表或者引入搜索引擎。答题时如果你能把这个链路完完整整地写出来再补一句“索引不是越多越好写多读少的表索引多了反而影响插入性能”这题基本就稳了。3.3 写一个健壮的监控脚本需要注意什么“写一个脚本监控进程挂了自动拉起”这道题好像人人都会写但真正能写出亮点的人不多。普通版本是这样的#!/bin/bash while true; do if ! pgrep -f myapp /dev/null; then nohup /usr/local/bin/myapp fi sleep 5 done这能实现功能但问题很多没有日志、没有去重保护、没有考虑进程启动失败的情况、没有处理“进程还在但僵死”的情况。我在笔试时改进版基本是这样的思路#!/bin/bash # 监控 myapp 进程如果不在就拉起避免重复启动 LOG_FILE/var/log/myapp_monitor.log LOCK_FILE/tmp/myapp_monitor.lock log() { echo $(date %Y-%m-%d %H:%M:%S) [$1] $2 $LOG_FILE } # 防止脚本自身重复运行 exec 9$LOCK_FILE if ! flock -n 9; then log ERROR another monitor instance is running, exit. exit 1 fi while true; do # 判断进程状态排除 grep 自身 if ! pgrep -x myapp /dev/null 21; then log WARN myapp is down, try to start... nohup /usr/local/bin/myapp /var/log/myapp.log 21 # 启动后确认一次 sleep 2 if pgrep -x myapp /dev/null 21; then log INFO myapp started successfully else log ERROR myapp start failed, need manual check fi fi sleep 5 done核心改进点有三个一是加了文件锁避免脚本因为 crontab 或人为误操作被重复执行后拉起多个进程二是加了日志任何一次拉起动作都有据可查三是启动后做一次确认避免“以为拉起来了其实根本没起来”的假象。笔试的时候你不需要写这么长但你要把“锁、日志、启动确认、异常处理”这几个关键词说出来面试官一看就知道你有实战意识。3.4 监控告警体系的设计思路这也是开放题里出现频率很高的一道“假设你现在要为一个有 100 台服务器的业务设计监控告警你怎么做”这种题没有标准答案但高分回答有几个共性分层设计从基础设施层CPU、内存、磁盘、网络→ 中间件层Nginx、MySQL、Redis→ 应用层接口耗时、错误率→ 业务层订单量、PV/UV逐层覆盖。数据采集方式Agent 采集如 Prometheus Node Exporter vs 日志采集ELK vs 埋点。告警规则要有合理的阈值和持续时长避免抖动就报警。比如 CPU 使用率 80% 持续 5 分钟才触发而不是瞬时超过就报。告警分级P0 立即短信/电话P1 邮件IMP2 记录在案次日处理。告警去重与降噪同一故障不要给所有人发重复告警要考虑告警聚合和静默期。这类题考察的其实是系统设计能力。你如果没实际搭过监控平台至少要能画出整体的采集链路讲清楚数据是从哪来的、怎么存的、怎么展示的、怎么告警的把链路理清楚就已经是合格答案了。4. 一套可复现的刷题与实战路径4.1 常见笔试题型自测清单下面这份清单不是搜狐畅游的原题而是我根据同类运维开发笔试题提炼出的“高频自测题”。建议你关闭搜索引擎先尝试自己回答一遍再对照我给的要点查漏补缺题目考察点答题要点如何查找日志中访问量最高的前10个IPShell/文本处理awk {print $1} access.log解释nohup和的区别进程管理是后台运行nohup是忽略挂断信号通常配合使用NGINX 返回 502 是什么原因网络/中间件后端服务不可用、fastcgi 超时、连接数耗尽、防火墙拦截等Python 按行读取文件过滤含“ERROR”的行Python 基本功with open上下文管理配合if ERROR in line描述一次你独立排查线上故障的经历综合能力按“现象→定位→修复→复盘”四步来写突出数据和时间点一个用户的请求从发出到返回经过哪些环节系统全链路客户端→DNS→LB→Web服务器→应用→缓存/DB→响应这些题你要能不看资料写出至少六七成的答案说明基础已经够用了。4.2 实操题目实现一个日志统计脚本我们来做一道具体的题完整写一遍。题目是“有一个 Nginx 的 access.log每行格式为IP - - [日期] 请求 状态码 响应大小请统计状态码是 500 的请求数并输出这些请求的 IP 列表按出现次数从高到低排序。”用 Shell 实现#!/bin/bash LOG_FILE/var/log/nginx/access.log echo 500 状态码总数 awk $9 500 $LOG_FILE | wc -l echo 按 IP 统计 500 请求次数 awk $9 500 {print $1} $LOG_FILE | sort | uniq -c | sort -rn用 Python 实现import re from collections import Counter log_file /var/log/nginx/access.log counter Counter() with open(log_file, r, encodingutf-8) as f: for line in f: # 简单分割Nginx 默认格式中第9个字段是状态码 parts line.split() if len(parts) 9: continue if parts[8] 500: ip parts[0] counter[ip] 1 total_500 sum(counter.values()) print(f 500 状态码总数: {total_500} ) print( 按 IP 统计 500 请求次数 ) for ip, cnt in counter.most_common(): print(f{cnt}\t{ip})这种题目看着简单但有几个隐藏的细节值得注意一是 Nginx 日志格式可能不是标准的字段位置可能不同二是日志中可能混入畸形行要加判断三是如果文件很大几个 GB用 Python 逐行读取、用 Counter 统计内存占用不会太高但如果你用readlines()一次性读入内存就会爆掉。你能在答案里主动说出这几个点就是加分项。4.3 学习路径建议3~4 周冲刺方案如果你时间紧张我建议按下面的节奏来复习。这套路径是我从多份成功上岸的同学的复习计划里提炼出来的比较均衡第1周夯实 Linux 和网络基础。每天花 2 小时过知识点1 小时做实操。重点把top、ps、df、ss、tcpdump这些命令的输出彻底看懂而不是只会敲。网络部分把 TCP 握手、HTTP 状态码、DNS 流程理清。第2周攻 Shell 和 Python 脚本。每天写 2~3 个小脚本比如日志清洗、批量建用户、批量检查端口连通性。不用追求花哨但要保证自己能不查资料写出一个带函数、带参数校验、带日志输出的完整脚本。第3周补数据库、缓存、中间件和容器知识。用 MySQL 官方文档把一个简单的表设计出来练习EXPLAIN看执行计划把 Redis 五种数据结构过一遍能写一个最简单的 Dockerfile 并构建运行。第4周刷题 模拟面试。把历年真题、牛客网、LeetCode 上标签为“运维/Shell”的题过一遍每天做一次完整的限时模拟。这个计划的关键不在于“学完”而在于“能输出”。每日复盘只问自己一个问题今天学的这些如果让我写出来或讲出来我能讲清楚吗5. 实战踩坑记录准备这类笔试容易犯的错5.1 只背命令不看输出这是我最想强调的一点。很多人复习 Linux 时背了一堆命令和参数但到了笔试让写“查看端口占用情况”的输出就懵了。我当年备考时就吃过这个亏。我记得很清楚有一次模拟题问“ss -tlnp输出中 Local Address 是0.0.0.0:80和[::]:80有什么区别”我答不上来。后来才搞明白前者是 IPv4 监听所有地址后者是 IPv6 监听所有地址。这就是典型的“会敲命令但不会看输出”的问题。建议你复习的时候每个命令至少跑三次分别观察正常情况的输出、异常情况的报错、参数不同时的差异。把输出当成“阅读材料”来学而不是把命令本身当重点。5.2 手撕代码只写思路不写完整代码笔试题和你平时 LeetCode 刷题不太一样它的判分点往往在“能不能跑通”和“边界处理全不全”。很多人回答脚本题时写了核心几行就停笔了比如统计 IP 只写awk {print $1}后面排序、去重、统计全不写让人感觉“懂一点但没落地”。我自己后来总结的经验是宁可代码多写几行也要保证逻辑闭环。一个脚本函数必须有输入参数校验、核心处理逻辑、输出结果三部分。哪怕你有一个函数忘了写也要通过注释表达出来让阅卷人看到你的完整思路。5.3 忽视说明“为什么”很多同学答题时只写“怎么做”不写“为什么这么做”。比如题目问“服务器 CPU 高怎么排查”你的回答是“用 top 看哪个进程高然后 kill 掉”。这只能得基础分。更好的回答是先top看整体负载再按 CPU 排序找到高占用进程用top -Hp pid查看该进程内哪个线程占用高结合strace或perf看系统调用和热点函数根据线程号和业务日志定位到具体代码评估是代码死循环、锁竞争、还是 GC 频繁。你把每一步的“为什么”都写出来阅卷人就能感受到你是真的理解排查逻辑而不是背了一套命令组合。5.4 不知道什么时候该说“不知道”面试和笔试里都有一种陷阱题超纲的问题。比如“Kubernetes 里 CNI 插件的工作原理是什么”如果你完全没接触过硬编一个答案反而扣分。更稳妥的回答是“这部分我了解得不够深我目前的理解是……但我对它的网络模型还不是特别清楚后续我会补上。”既展示了诚实又展示了学习意愿。6. 准备过程中值得沉淀的几个习惯6.1 建一个自己的排障手册运维开发笔试的很多题目本质上都是在问“遇到问题你怎么办”。如果你能建立一份自己的排障手册把每一次遇到的线上问题、排查过程、根因、解决方案记录下来你的答题素材库就会越来越厚。我的手册结构很简单问题现象一句话描述影响范围哪些服务、多少用户受影响排查时间线几点几分做了什么操作结果如何根因分析为什么会发生解决方案短期怎么止血长期怎么根治复盘哪些地方可以提前发现面试时如果遇到“讲一个你印象最深的故障”你直接从手册里挑一个按这个结构讲信息密度和逻辑性都会比现场想好太多。6.2 动手搭一套自己的运维环境光靠刷题很难应对越来越偏实战的笔试题。我强烈建议你在自己的电脑上搭一套可以折腾的实验环境用 VirtualBox 或 VMware 装一台 CentOS/Ubuntu 虚拟机在上面部署 Nginx、MySQL、Redis写一个简单的 Python/Flask 应用用 Docker 把应用容器化搭一个最简单的 CI/CD 流水线GitHub Actions 或者本地 Jenkins这套环境花不了太多时间但能让你对所有笔试考点有一个直观的认知。尤其是容器和 CI/CD 部分你亲手跑过一遍构建部署流程笔试里遇到“如何实现一个自动化部署脚本”这样的题目思路就完全不一样了。6.3 刷题要输出不要只输入到最后阶段每天刷完题以后我建议你做一件事把当天做过的题用自己的话写成一篇简短的笔记或者假装在给一个新人讲题。能讲明白才是真会。这个方法听上去很简单但实际效果比我试过的任何刷题方法都好推荐你试试。7. 从笔试到 Offer多走一步的加分项7.1 简历里写项目经验时突出“自动化”和“数据”运维开发岗的简历项目经验不需要写“我部署了一个网站”这种流水账重点在于你解决了什么问题。同样一个项目普通版写的是“负责搭建测试环境部署应用”。升级版可以写成“负责搭建基于 Docker Jenkins 的自动化测试环境将原本每次约 40 分钟的人工部署流程压缩到 8 分钟并将部署成功率从 85% 提升到 99.5%通过钉钉机器人实时推送构建结果。”突出量化数据用代码解决重复劳动这是面试官最想看到的。7.2 笔试之外的“软加分项”运维开发的笔试题虽然重要但最终能不能拿到 Offer还取决于几个笔试之外的环节沟通能力运维开发经常要承接开发和运维两边的问题沟通能力直接影响工作效率。笔试里体现不出这点但面试一定会问。责任感与细心的程度运维的线上操作容错率很低一次误操作可能导致全站故障。面试官会通过追问细节来判断你是不是一个细心的人。持续学习的能力运维技术栈更新速度极快面试官问“你最近在学什么”其实是在考察你的学习动力和方法。笔试只是第一关后面还有面试、HR 面、谈薪每一个环节都需要认真准备。7.3 拿到 Offer 之后别急着停止学习如果你真的拿到了运维开发工程师的 Offer那恭喜你但这只是起点。游戏公司对线上稳定性要求极高新人入职后要学的东西更多具体的监控平台、内部的发布系统、业务架构、容灾方案。笔试里学的那些知识是你在新环境里站稳脚跟的基石而不是终点。从我接触过的同学来看能在校招里拿到运维开发 Offer 的人普遍有一个共同点他们不是“考试型选手”而是真的对系统、对自动化、对故障排查有兴趣。笔试只是他们平时积累和思考的自然结果。与其焦虑地刷题不如静下心来把基础打牢多动手实践多复盘总结。面试官每天面很多人你有没有真本事几句话就能探出来。