从2018年那场校招笔试说起，业务运维这个岗位在当时的互联网公司里已经不算冷门，但真正愿意在校招环节里单独给业务运维出一套B卷、并且把题目范围铺得这么广的公司，其实并不多。欢聚时代这份B卷给我的整体感觉是：它不是在考你会不会背某个命令，而是在考你有没有一套“线上出问题时不慌、有次序、有依据”的思考习惯。如果你正准备类似的运维岗位笔试，这篇文章可以帮你把考点脉络理清楚，避开那些容易丢分的坑。
我当时拿到这套B卷的第一反应是：题目难度其实没有想象中那么高，但覆盖面确实广，从Linux基础、网络协议到MySQL、Redis、Nginx场景题都有涉及。换句话说，它考的不是深度，而是广度加逻辑。你要在有限时间里把每个模块的常识点都答得基本正确，同时还要在场景题里展示出清晰的排查链路，这比单独钻研某一个开源组件要难得多。下面我按自己的理解，把这份试卷背后的考察逻辑和具体备考方向拆开讲。
1. 笔试考的是业务运维的岗位画像，不是零散命令
1.1 业务运维和基础运维考核点的本质差异
很多人一听到“运维笔试”，第一反应就是背Linux命令、记端口号、默写TCP三次握手。这些当然是基础，但业务运维的核心画像和基础运维并不完全一样。基础运维更关注单台机器、单个集群的健康状态，而业务运维必须把视角上升到“一条完整业务链路”——从用户发起请求，到DNS解析、接入层负载均衡、应用服务器处理、缓存命中、数据库查询，再到响应返回，整条链路上任何一个环节抖动，都可能表现为同一个用户可感知的症状。
笔试里出现这个岗位的单独题目，本质上是在筛选具备“链路思维”的人。B卷里很多看似零散的题目，最终都能串联到一条业务链路上：DNS解析慢会导致整体请求耗时上升，Nginx upstream超时会导致接口报错比例升高，MySQL慢查询会导致某些页面接口卡顿，Redis连接数被打满会导致缓存不可用，进而拖垮数据库。你如果没有链路意识，就会把每道题当成独立的“知识点记忆题”，这样答出来的答案，阅卷人一眼就能看出来是背题还是真理解。
1.2 B卷的典型结构：三块内容，一条主线
综合我当时做题的经验和后来辅导过的人反馈，这份B卷的结构大致可以分成三块：
| 板块 | 主要考查范围 | 分值占比预估 |
|---|---|---|
| 基础理论与系统 | Linux、网络协议、进程/内存/磁盘、常见数据结构 | 30% |
| 中间件与存储 | Nginx、MySQL、Redis，少量消息队列概念 | 35% |
| 场景分析与综合 | 线上故障排查、变更管理、容量评估 | 35% |
这个占比不是官方数据，而是做完之后根据题目分布推测的。合理之处在于，它把“动手能力”和“判断能力”放在同等重要的位置。业务运维日常大量工作发生在这三类场景下：看系统资源、调中间件、应对线上异常。笔试如果只考Linux，你招进来的人可能只会处理单机问题；笔试如果只考场景题，又没法快速判断候选人的基础知识是否扎实。所以三块内容一条主线，主线就是“业务链路的稳定性”。
2. 基础部分：Linux、网络和计算机常识的运维化考法
2.1 Linux考点：不是考命令拼写，是考排错敏感度
Linux在业务运维笔试里的出现方式，通常是给出一个系统状态异常的描述，让你选排查工具或写出排查命令。这类题干背后的真实需求是：你能不能在系统负载高、IO打满、连接数飙高时，快速缩小范围并找到根因。
常见的排查链路，我建议你脑子里固定成模板：
- 先用
uptime看系统平均负载，再看top或htop确认是CPU还是内存导致的负载高； - 如果是CPU高，用
ps -eo pid,pcpu,comm --sort=-pcpu | head找出CPU占用top10进程； - 如果是磁盘IO高，用
iostat -x 1查看%util和await，并配合pidstat -d 1定位到具体进程； - 如果是内存压力大，用
free -h看整体水位，再用cat /proc/meminfo或ps --sort=-rss查RSS占用； - 如果涉及网络连接数异常，用
netstat -antp或ss -antp统计连接状态，重点看TIME_WAIT、CLOSE_WAIT、ESTABLISHED三类的数量。
考试时不用把命令拼写得非常完整，但关键参数最好写对。比如ss -antp里的-a表示显示所有socket，-n表示不反解域名，-t表示只显示TCP，-p表示显示对应的进程信息。阅卷人看到你对一个小参数的理解都到位，就会觉得你是真的用过，而不只是背过。
还有一个容易被忽略的点：df -h与df -i的区别。很多人只查磁盘空间，忘了inode耗尽也会导致“磁盘写满”的假象。笔试如果出一个“磁盘明明有空间但创建不了文件”的题，你如果能写出df -i查看inode使用率，这道题就稳了。
2.2 网络必答点：TCP状态、DNS解析和抓包思路
网络这块，业务运维笔试特别喜欢考TCP连接状态和DNS解析流程。原因是这两块直接决定线上问题的排查方向：大量TIME_WAIT说明短连接频繁，可能是连接池设置不当；大量CLOSE_WAIT说明对端关闭了连接但本端没有主动close，通常是应用层代码没有正确释放连接。
关于TCP三次握手和四次挥手，不要只背“SYN、ACK、FIN”这三个词。你要能把状态转移说清楚：三次握手从CLOSED到LISTEN，收到SYN变成SYN_RCVD，回复SYN+ACK后等ACK变成ESTABLISHED；四次挥手时主动关闭方先发FIN进入FIN_WAIT_1，收到ACK后进FIN_WAIT_2，收到对端FIN后进TIME_WAIT，等待2MSL后关闭。笔试里容易抠细节的是TIME_WAIT存在的意义——为了确保最后那个ACK如果丢了，对端重传FIN时本端还能响应。
DNS解析的考点通常是：用户在浏览器输入域名后发生了什么。完整回答应该是：浏览器查本地缓存，没找到就查系统hosts文件，再没找到就向配置的DNS服务器发起递归查询；DNS服务器如果本地没有缓存，会依次向根域名服务器、顶级域名服务器、权威域名服务器发起迭代查询。笔试中常见的延伸问题是“DNS解析慢会有什么现象”，答案是：请求整体耗时变长，但TCP连接本身不受影响，需要抓包确认是DNS阶段耗时还是TCP建连阶段耗时，用dig +trace或dig +stats可以快速区分。
抓包思路这一项，不见得会直接让你写tcpdump命令，但很可能给你一段线上抓包结果，让你判断哪个环节出了问题。例如大量SYN_RECV说明服务端收到了SYN但没完成握手，可能是半连接队列满了，也可能是SYN攻击；大量RST包说明有连接被异常重置，常见于服务端accept队列溢出或应用层主动关闭。答这类题时，先说明你看到了什么，再推断可能原因，最后提议验证方法，逻辑链越完整分越高。
2.3 计算机常识与数据结构的“运维变形题”
业务运维笔试偶尔会混入少量计算机基础题，比如进程和线程的区别、虚拟内存和物理内存的关系、常见数据结构的时间复杂度。这些题看起来和运维不相关，其实是在考你对“资源分配”的理解。
举个典型例子：题目问“数组和链表的区别是什么”，你如果只是答“数组内存连续、链表内存不连续”，属于基础分；如果你补充说“在运维场景中，经常用环形队列来做日志缓冲，从固定大小数组头尾指针覆盖写入，避免频繁分配内存；而业务上需要频繁插入删除的缓存数据，用链表更合适”，阅卷人会觉得你能把数据结构落到实际系统中。同理，进程和线程的差异也可以往“Nginx master-worker架构、Redis单线程模型为什么不用锁”这个方向去延伸，这样既回答了基础题，又体现了对常用中间件运行模型的理解。
3. 中间件与存储：Nginx、MySQL、Redis是业务运维的主战场
3.1 Nginx高频知识点：location匹配、超时和upstream机制
Nginx在校招笔试里几乎是必出的，因为它是绝大多数业务流量的第一站。关于Nginx，我最想提醒的一点是：不要只背配置文件语法，要理解它作为反向代理的核心机制。
location匹配规则是容易出选择题或简答题的地方。你需要记住优先级关系：精确匹配=最高，其次前缀匹配^~，再其次是正则匹配~、~*，最后才是普通前缀匹配。实际排错中，最常见的问题是“我加了新的location规则但没生效”，原因往往是规则优先级没排对，或者没有reload。笔试里如果给一段Nginx配置问你某个URL会命中哪个location，你就按“精确 > ^~ > 正则 > 普通前缀”的顺序逐层判断。
upstream机制里，高频考点是负载均衡策略和健康检查。写配置文件时要会写server 10.0.x.x:8080 weight=5 max_fails=3 fail_timeout=30s;这类基本配置。另外要理解Nginx默认对上游是轮询加权重，还可以配置least_conn按最少连接数分发、ip_hash保持会话。如果题目问“某个后端节点挂了为什么会继续收到请求”，答案通常是健康检查配置不完善，max_fails和fail_timeout没有设置，或者使用的是四层转发（stream模块）且没有做后端健康探测。
我还想单独提一下超时相关参数，因为这是业务运维日常处理频率最高的问题。proxy_connect_timeout控制与后端建立连接的超时，默认60秒；proxy_read_timeout控制两次连续读操作之间的超时，默认60秒。如果后端应用处理慢，前端Nginx往往会先返回504，这时候不要只加大proxy_read_timeout，要回到应用本身查耗时。笔试题如果问“504和502有什么区别”，就是考这个点：502通常是Nginx连不上后端或后端返回无效响应，504是连接建立了但后端在规定时间内没返回数据。
3.2 MySQL考点：慢查询、索引和主从复制思维
MySQL在业务运维笔试中的出现频率，可能比Nginx还高，因为数据库是业务链路上最脆弱也最关键的一环。核心考点集中在慢查询、索引原理和主从复制三个方向。
慢查询相关题目通常给你一条SQL语句，让你分析为什么慢。你首先要看是不是全表扫描，也就是有没有走索引。如果没有，用EXPLAIN看执行计划，重点看type字段：从system、const到ref、range再到index、ALL，越往右越慢。如果出现ALL，基本就是全表扫描了，优化方向是加索引。
索引部分容易丢分的地方是复合索引的最左前缀原则。比如建了一个(user_id, status, created_at)的复合索引，你查询条件是where created_at < ?，这个索引是不会生效的，因为没从最左列开始。笔试题里经常给你几个查询条件组合，让你判断哪些查询能用上复合索引，这时候就用最左前缀法则去套。
主从复制这块，业务运维主要关注延迟问题，不需要深入binlog源码，但你要明白基本原理：主库把变更写入binlog，从库的IO线程拉取binlog写到本地relay log，再由SQL线程回放。笔试常见题干是“主从延迟很大，如何排查”。回答思路是：先在从库上执行show slave status\G看Seconds_Behind_Master，然后判断是IO线程拉取慢还是SQL线程回放慢。如果Slave_IO_Running和Slave_SQL_Running都是Yes但延迟持续增长，通常是主库写入并发太大或从库配置弱、大事务回放慢导致的。
还有一个业务运维特有的MySQL考点是“连接数打满”。很多应用层报错是Too many connections，笔试题会让你给解决方案。初级答法是修改max_connections，但这是治标不治本，因为连接数打满往往意味着有连接没有被及时释放，或者有慢查询把连接占住了。正确顺序应该是：先看当前连接分布show processlist，区分Sleep、Query、Locked各类状态，再把长时间处于Query状态的SQL拿出来分析，最后才是考虑调整连接池上限或max_connections参数。
3.3 Redis考点：缓存穿透、击穿、雪崩和过期策略
Redis在校招笔试里非常“友好”，因为考点比较固定，不像MySQL那样容易挖得很深。但业务运维角度下的Redis题，从来不只是问“Redis支持哪些数据结构”，而是问“缓存和数据库之间的一致性怎么保证”。
缓存穿透是指请求的数据在数据库里不存在，导致每次请求都绕过缓存直接打到数据库。解决思路一般有三个方向：把空值也缓存起来并设置较短过期时间，使用布隆过滤器在缓存前拦截一定不存在的key，或者对不存在的key做限流降级。笔试里你只要能写出“空值缓存+布隆过滤器”这两个常见方案，基本就能拿分。
缓存击穿是指某个热点key在缓存失效的瞬间，大量请求同时打到数据库。核心解法是互斥锁——当缓存中没有数据时，只允许一个线程去加载数据并回填缓存，其他线程等待。另一种思路是逻辑过期时间，把过期时间放在value里，读到时发现逻辑过期则异步刷新，但返回旧值，适合对一致性要求不高的场景。
缓存雪崩是指大量key在同一时间失效，或者Redis实例整体宕机，导致所有流量直接压垮数据库。笔试里针对“大量key同时到期”的解法是过期时间加随机值，比如expire设置为基础时间加一个0到300秒的随机数，避免同一秒内大量key失效。针对“Redis宕机”的解法就要分层了：Redis本身做主从哨兵或Cluster保证高可用，业务侧配合本地缓存做多级降级，数据库侧做连接池限制和限流保护。
业务运维对Redis的运维视角还体现在内存管理上。笔试如果问“内存快满了怎么办”，你不能只答maxmemory-policy allkeys-lru，要说明这个策略适合缓存场景，但如果有持久化数据驻留在Redis里，随意LRU淘汰可能导致数据丢失。所以更进一步的做法是调整内存配置、拆分业务缓存实例、对热点大key做拆分或压缩，并且提前通过redis-cli info memory和监控系统观察used_memory的增长曲线。
4. 场景题是大头：把“排查思路”写成阅卷人看得懂的流程
4.1 场景一：接口响应时间突然上升
这类场景题通常会描述一个现象：某核心接口的P99响应时间从50ms升到500ms，但CPU和内存看起来都没有打满，问你怎么排查。
高分的作答思路不是直接给结论，而是展示分层排查框架：
- 先确认现象真实性。看监控系统里的历史曲线，是不是大促、定时任务、版本发布等时间点吻合的偶发抖动，避免被瞬时毛刺误导。
- 从用户请求链路逐层拆解。接入层看Nginx访问日志里这个接口的
$request_time和$upstream_response_time，先判断耗时是发生在Nginx自身还是后端上游。 - 应用层的排查。登录应用服务器，用
top看线程状态和上下文切换，用jstack或jstat看是否有线程阻塞、GC频繁或连接池等待。如果是Java应用，重点看Full GC次数是不是突然变多，以及数据库连接池有没有等待获取连接的线程。 - 数据层的排查。用
show processlist查看当前数据库连接里是否有长时间Query，用explain分析对应接口的SQL执行计划，确认是不是索引失效或数据量增长导致扫描行数变多。 - 外部依赖排查。这个接口是否依赖第三方服务或消息队列，如果依赖方响应慢，即使本机资源正常，接口一样会慢。
答案里如果能写明“我要用A工具确认B现象，再根据C结果判断是D方向的问题”，这样的排查链路就非常完整，阅卷人挑不出逻辑漏洞。
4.2 场景二：磁盘使用率冲到90%
磁盘满了是业务运维最高频的报警之一，也是笔试里最经典的场景题。这道题的陷阱在于，很多人一上来就清理日志，但不解决根因。
我建议的作答路径是：
- 先止血。用
df -h确认哪块分区满了，用du -sh /path/*逐层找出大目录和文件。如果是日志文件占空间，而且是很久以前的日志，可以先挪走或压缩，释放一部分空间。 - 定位增长源。用
lsof | grep deleted查看是否有已经被删除但仍被进程占用的文件。这个点非常关键，因为很多场景下你用df -h看到空间不够，但du找不到大文件，原因就是有进程在持续写入一个已经被删除的日志文件。线上环境经常发生在logrotate轮转日志后，应用进程没有重新打开日志文件，导致磁盘空间无法释放。 - 排查定时任务和持续写入。用
crontab -l查看是否有定期生成大文件的脚本，确认是无用数据还是核心数据。同时关注应用产生的临时文件、core dump文件。 - 根治方案。日志做好logrotate，按天或按大小切割，保留指定份数；核心数据要写入独立的数据盘，避免与应用日志抢占同一分区；建立磁盘空间监控，阈值设置在75%和85%就告警，留出足够的处理时间。
这道题的精髓在于，面试官不仅想知道你会不会清理磁盘，还想看你是否理解“空间释放了但进程还在写旧文件”这类隐蔽问题。你把lsof | grep deleted写出来，分数立刻就不一样了。
4.3 场景三：发布新版本后错误率上升
版本发布是业务运维日常风险最高的操作之一。笔试场景题里，如果问“发布后服务错误率上升，你怎么处理”，核心矛盾是：继续排查还是立即回滚。
我的建议是先明确回滚决策标准，这个标准应该在发布前就定义好。具体到答法：
- 如果错误率上升伴随用户核心功能不可用，或错误率超过预设阈值（比如从0.1%飙到5%），应该第一时间回滚，恢复服务后再分析原因，而不是在现场继续看日志。
- 如果错误率只是轻微上升，且没有大面积影响，可以保留新版本，同时快速定位是配置项问题、依赖服务问题还是代码逻辑问题。
- 在回滚时，要留意数据库变更的兼容性。如果新版本代码依赖一个新增字段或新表结构，代码回滚后旧版本读到这些新数据可能不兼容。所以发布前要有配套的数据库兼容设计，例如先加字段再发布代码，发布失败时只回滚代码，不动数据库结构。
答这类题时，能体现“变更管理”意识的人，分数普遍偏高。因为业务运维的一个重要职责就是控制变更风险，笔试里考“发布出错怎么办”，本质上是看你有没有一套自己的发布安全守则。
5. 应试细节：笔试卷上怎么组织答案更占便宜
5.1 按“现象-影响面-排查-止血-根治”的结构写解答题
校招笔试题量大，阅卷节奏快，阅卷人没有耐心在一堆文字里找你的得分点。我最建议的答题框架是，每道场景解答题都按五个分段来写：
| 模块 | 要写的内容 | 目的 |
|---|---|---|
| 现象 | 你看到了什么指标异常 | 证明你理解了题干 |
| 影响面 | 影响了哪些用户、哪些接口、哪些下游 | 展现你的全局意识 |
| 排查 | 用什么工具、按什么顺序查根因 | 核心得分点 |
| 止血 | 怎么快速恢复服务 | 体现应急能力 |
| 根治 | 如何避免下次再发生 | 体现长期治理意识 |
这个结构最大的好处是，就算你的排查顺序不完美，阅卷人也能看到你具备工程化处理事故的思维，而不是东一榔头西一棒子。
5.2 时间分配和易错项
按我的经验，总时长如果是90分钟，建议基础题控制在35分钟内，中间件题控制在30分钟内，剩下25分钟留给场景题。场景题宁可少写排查步骤，也要保证结构完整。很多人在基础题上过度纠结某个命令的参数，然后在场景题上草草两行带过，这是最大的失分原因。
容易丢分的“小坑”我也整理一份：
- TCP和UDP端口范围混淆，或者把DNS用的端口写成53、HTTP用的80和HTTPS用的443之外，还容易漏了MySQL的3306、Redis的6379、Nginx的80/443这些常见端口。
- MySQL和Redis的默认端口在某些协议类题目里会被混在一起考，答题时注意区分服务类型。
- 写Shell脚本题时，如果忘记加
#!/bin/bash或在变量前漏写$，可能只是小扣分；但如果逻辑写得混乱，被扣的分就多了。 - 在写Nginx配置时，如果忘了以分号结尾，即使配置内容写对了，阅卷人也可能认为你没有实际操作经验。
6. 一些个人的备考心得
最后聊点备考之外的东西。我见过不少准备业务运维岗位的人，复习资料里全是各种中间件的安装配置教程，却忽略了最重要的一件事：练出故障排查的“肌肉记忆”。
笔试和实际工作最大的区别在于，笔试是静态的，你落笔之后没有反馈。这就更需要你在平时练习时模拟真实故障场景，把“看到现象-缩小范围-定位根因-恢复服务”整个流程多过几遍。可以用虚拟机搭一套简单的环境：一个Nginx反代两个后端，后端接MySQL和Redis。然后人为制造故障，比如把MySQL慢查询日志开起来，写一条sleep的SQL；或者把Redis设置maxmemory 1mb，再往里面写大量数据，观察缓存淘汰策略，看整个链路的报错是怎么传递的。
这种自己折腾出来的经验，比看十篇面经都有用。因为你在笔试场景题里写“我先show processlist再explain”时，如果自己真的做过一次，字里行间会多一种笃定，阅卷人是能从细节里分辨出有没有实战感的。
还有一点，笔试时遇到完全没见过的名词或概念，不要直接空着。你可以基于常识推测，比如题目里出现一个你没用过的组件，你可以写“我会先查文档确认它的功能边界，再通过监控和日志确认它是否处于正常状态”。这种回答虽然不能得满分，但至少展示了你在陌生系统面前的认知方法和主动性，这恰恰是校招生最珍贵的特质。
从2018年到现在，这套卷子的具体题目可能已经被更新过很多轮，但业务运维校招笔试的内核一直没变：它考的不是谁的书本知识背得全，而是谁更有“让一个线上系统稳定跑下去”的直觉和方法论。准备的时候，沉下心把Linux、网络、MySQL、Redis、Nginx这几个模块揉进链路里理解，把场景题按自己的话多写几遍，比盲目刷题有用得多。
