从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回复SYNACK后等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 weight5 max_fails3 fail_timeout30s;这类基本配置。另外要理解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这几个模块揉进链路里理解把场景题按自己的话多写几遍比盲目刷题有用得多。 业务运维校招笔试B卷考点解析：从Linux到中间件的排查链路
从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回复SYNACK后等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 weight5 max_fails3 fail_timeout30s;这类基本配置。另外要理解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这几个模块揉进链路里理解把场景题按自己的话多写几遍比盲目刷题有用得多。