1. 内容整体设计与思路拆解1.1 这场笔试到底在考什么聊到欢聚时代2018校招的业务运维岗位我的记忆还是挺深的。当年成都场的笔试题拿到手里第一反应是这公司是真的在招运维不是随便出两张卷子走过场。整张卷子没有一道纯背概念的题所有题目都落在“你到了线上能不能处理事”这个维度上。业务运维这个岗位和纯系统运维、网络运维最大的区别在于你维护的不只是服务器而是一整套“业务链路”。用户从App点一下直播背后涉及DNS解析、CDN调度、接入层负载均衡、业务网关、IM消息推送、直播间房间状态、弹幕消息队列、录制转码集群、对象存储回源……这一整条链路里任何一个环节出问题用户侧的体感就是卡顿、进不去、黑屏、声音不同步。所以笔试题的命题思路本质上就是在模拟“业务出问题你能不能定位”这个场景。成都场比较有代表性的几个考察方向我复盘下来大概是这几类Linux基础命令和系统状态排查给一堆输出让你判断系统哪里出了问题。网络基础知识TCP握手、HTTP状态码、DNS解析过程这些高频点。数据库和缓存MySQL的SQL编写、Redis的常见使用场景和坑。Shell脚本编程手写脚本完成日志分析、批量操作。场景题模拟一个线上故障让你描述排查思路和处理方案。这个结构很典型几乎把业务运维日常工作中最常用的几块能力全覆盖了。作为过来人我建议准备校招的同学不要死记硬背题目的标准答案而是从“如果这台服务器现在归我管我该怎么处理”的角度去理解每一类题背后的逻辑。1.2 成都场的特殊性在哪里很多人会问校招笔试题既然全国统一出为什么还要标“成都场”根据当年参加过的同学反馈和我的了解欢聚时代的校招笔试虽然是同一套题库但不同城市场的题目侧重点会有微调尤其是业务运维这种岗位。成都场有一个明显特点手写代码的题量占比比其他场次要高。因为成都的团队偏底层基础设施和中间件方向面试官比较看重候选人的脚本功底和Linux操作熟练度。另外成都场的场景题更偏向“直播业务”相关的故障毕竟欢聚的核心产品YY直播、虎牙直播当年还在集团体系内对音视频链路的要求非常高笔试出题自然会往这个方向倾斜。所以准备这场笔试你不能只刷通用的运维面试题一定要把“直播业务场景下运维会遇到哪些典型问题”单独当做一个模块来准备。比如直播间进不去、推流断开、卡顿率升高、弹幕延迟变大这些场景背后的链路排查思路都是高频考点。1.3 笔试的隐藏评分标准笔试不是只看你答对了没有还会看你的答题习惯和思维方式。我自己也参与过校招笔试的阅卷说几个真实的评分倾向场景题答得好不好关键看“排查顺序”。上来就重启大法、直接重装系统的分数不会高。有条理地“先看系统负载、再看进程状态、然后看日志、最后才操作”这种思路才是加分项。手写脚本哪怕是伪代码也要把流程写清楚。面试官会看你有没有考虑到边界情况比如文件不存在、日志格式带空格、目录需要先创建这些细节。写SQL题的时候字段名和表名写错字是大忌。笔试阅卷不会像机器判题那样完全按关键字匹配但字段对不上基本就没分了。这些隐藏标准说实话比题目本身更值得研究。答对题目只能保证及格答出“生产环境的思维”才能拿高分。2. Linux系统管理与命令细节解析2.1 文件管理和权限控制的必考姿势Linux是运维的基本盘笔试里文件管理和权限这块的题目一般不会缺席。最常见的出题方式是给你一段ls -l的输出让你解释每一列的含义或者问某个用户对某个文件有没有写权限。看起来基础但很多同学挂在细节上。举个例子题目给一个文件权限-rw-r--r--拥有者是 root组是 root问一个普通用户能不能修改这个文件。很多人看到“r--r--”就直接说不能这没错但如果没有补充“除非用户属于root组或者文件有ACL特殊权限”这个前提条件就会被认为考虑得不够全面。实际答题的时候先答标准权限判断再补一句“如果有ACL或者root用户可以直接操作”这种边界情况会显得你见过真实的生产环境。文件管理方面笔试常考的还有软链接和硬链接的区别。一句话版本软链接是快捷方式删了原文件链接就断硬链接是同一个inode的另一个名字删一个不影响另一个。成都场那年就出了一道题让你用ln命令创建硬链接然后问删除原文件后通过硬链接还能不能读到内容。答案是能因为硬链接指向的inode还在数据没有被真正释放。2.2 进程排查和资源定位的实战思路进程这块是业务运维笔试的重头戏出题方式通常有两种一种是给你top或者ps的输出让你分析系统状态另一种是场景题里让你排查CPU飙升的问题。先说top输出分析的答题套路。看到top的第一眼重点看三块load average、%CPU和%MEM、以及排在前面的是哪个进程。load average有三个数值分别代表1分钟、5分钟、15分钟的平均负载。如果三个数都高说明系统持续过载如果只有1分钟高而15分钟低说明是突发流量或者刚启动的任务导致的尖峰。这个判断逻辑面试官很在意因为它能体现你对“负载”这个概念有没有真正的理解。再说CPU飙升的场景题这是我在前面提到的“高频故障”之一。标准排查顺序应该是先用top找到CPU占用最高的进程PID。再用top -H -p PID找到这个进程内部哪个线程在吃CPU。然后用printf %x\n 线程ID把线程ID转成十六进制。最后用jstack PID | grep -A 30 线程ID的十六进制看线程堆栈定位到具体代码行。这套流程在笔试里写出来比直接写“重启服务”要高级太多。因为面试官可以从这个回答里看出你是真的处理过线上问题而不是只背了面试题。2.3 计划任务和日志管理的靠谱写法crontab也是笔试常客而且经常结合场景题出现。比如题目说“每天凌晨2点需要清理 /data/logs 下7天前的日志文件请写出crontab配置”。标准答案如果是0 2 * * * rm -rf /data/logs/*.log那基本就挂了。首先是find加-mtime的写法问题其次清理日志一般不建议用rm而是用find ... -delete或者在脚本里先把日志压缩归档再删除避免误删正在写入的文件。一个生产环境可用的写法是0 2 * * * find /data/logs -type f -name *.log -mtime 7 -delete /var/log/cleanup.log 21这里有几个细节值得展开-mtime 7表示修改时间超过7天-type f只处理文件不碰目录避免误删了目录结构。输出重定向到日志文件是为了方便回溯排查“为什么没删掉”或者“为什么删多了”的时候有据可查。日志这块笔试还可能考rsyslog的简单配置、logrotate的配置项比如按大小切割、保留多少份。实际工作中的经验是logrotate比很多人想象的更重要日志不切割导致磁盘写满的事故我在不同公司都见过好几回。笔试如果考到一定要答出daily、rotate 7、compress这几个关键参数的含义。3. 网络与Web服务的核心考点3.1 TCP和HTTP的细节才是拉分项网络部分的笔试题目表面看考的是“三次握手和四次挥手的过程”但成都场的出题风格是往细节里抠。我在其他地方看到过这道变体就是给你一个抓包结果让你判断这个TCP连接处于什么状态。正常的握手过程不说了我重点说两个容易被忽略的细节。第一个是“为什么是三次握手而不是两次”这道题的深度版本要答到“防止已失效的连接请求突然又传到服务端导致服务端误开连接”。第二个是“TIME_WAIT状态为什么需要等待2MSL”因为要保证最后一个ACK能到达对端同时让本连接产生的所有报文在网络中消失避免干扰后续连接。HTTP状态码更是业务运维笔试的送分题和送命题。送分是因为常见状态码大家都会背送命是因为只会背常见的不够。成都场那年就考了一个502 Bad Gateway和504 Gateway Timeout的区别。简单说502是网关从上游收到了无效响应504是网关等上游响应等超时了。但深入一层这两个状态码对应的排查方向完全不同502要先查后端服务是否存活、端口是否在监听、防火墙是否拦截504要查后端服务处理请求是否太慢、网关的超时时间设置是否合理。3.2 DNS解析流程和排查方法DNS这块笔试常考的题目是全链路解析过程。比如用户在浏览器输入一个域名背后发生了哪些事。标准答题链路是浏览器缓存、操作系统缓存、本地hosts文件、本地DNS服务器LDNS、根DNS服务器、顶级域服务器、权威DNS服务器。很多同学把这七层背下来就完事了但从业务运维的角度面试官更想听到的是“怎么排查DNS问题”。补充一下我会写的排查思路先用nslookup或dig看解析结果是否正确。再对比dig 114.114.114.114和dig 8.8.8.8的结果判断是不是本地DNS缓存的问题。然后看解析出来的IP是不是预期IP如果解析到了CDN的节点还要确认是不是调度到了就近节点。这个排查思路在笔试场景题里特别好用。因为DNS故障的典型表现是“一部分用户能访问一部分不能”或者“域名解析到了错误的IP”如果你能完整写出从用户侧到服务侧的排查链路基本就能拿满分。3.3 Nginx配置题的高分套路Nginx是业务运维笔试的压轴常客出题形式一般是给一个配置片段让你解释含义或者补全配置。比如server { listen 80; server_name example.com; location /api/ { proxy_pass http://backend_server; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }看到这道题不能只回答“这是反向代理配置”。要把每个指令都解释到位proxy_pass是做反向代理转发proxy_set_header Host $host是把客户端请求的Host头传给后端X-Real-IP $remote_addr是让后端能拿到用户真实IP。如果后端是Tomcat或者Java应用通常还会有一行proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for这是为了传递完整的代理链路信息。另一个常考的是负载均衡配置里 upstream 的调度策略。笔试答案进阶一点可以这样说默认是轮询weight按权重分配ip_hash按客户端IP哈希保证同一用户请求落到同一台后端least_conn会把请求发给当前连接数最少的后端。每个策略的适用场景不同比如需要session保持的场景优先用ip_hash但如果是分布式缓存之类的无状态服务用默认轮询就够了。3.4 防火墙和系统安全的常识性问题成都场的笔试里防火墙的题考得不算深但基本都会带一两道。比如iptables允许某IP访问本机80端口规则应该怎么写iptables -A INPUT -s 10.0.0.1/32 -p tcp --dport 80 -j ACCEPT这里有个坑是很多新手会漏了先允许回包流量。更稳妥的写法是在INPUT链里加一条状态相关的放行规则iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT笔试考到防火墙其实考的是你有没有生产环境配置防火墙的经验。因为单机房时代可以图省事直接关防火墙但稍微大一点的集群防火墙策略直接关系到业务的安全和可用性。这个点在回答里带一句“实际场景中还会考虑规则顺序因为iptables的规则是从上往下匹配的”会非常加分。4. 数据库与缓存的高频考点4.1 MySQL笔试必备SQL编写和主从复制MySQL在业务运维笔试里占的比重很高因为几乎所有互联网业务的核心数据都落在MySQL里。SQL题一般给你两张表让你写查询语句考的是JOIN、GROUP BY、HAVING这些基本语法。我不展开具体的SQL语法了只说一个笔试做题的经验写完SQL一定要自己检查一遍字段名、表名、别名是否一一对应。很多同学思路完全正确就是因为把“表名.字段名”写错了结果白丢分。还有一个细节面试官会比较关注你是否会在GROUP BY后面使用HAVING而不是WHERE来过滤聚合结果。这是SQL书写的规范性也体现基础扎不扎实。主从复制的原理题也经常出现核心是讲清楚三个线程主库上的Binlog Dump 线程负责把binlog发给从库。从库上的I/O 线程负责接收binlog并写入中继日志relay log。从库上的SQL 线程负责读取中继日志并回放到从库。如果笔试出场景题“从库同步延迟怎么排查”我会这样答先show slave status\G看Seconds_Behind_Master的值再排查从库的磁盘IO是不是满了、大事务是不是在执行、主库的binlog是不是太大导致从库拉取不及时。还可以补充一条“检查从库有没有在做备份或者跑大批量分析任务”这种操作常会导致同步延迟属于生产环境非常典型的坑。4.2 Redis的必背考点和经典坑Redis在业务里最常见的用途是缓存、分布式锁、排行榜、会话保持。笔试常考的题目包括“Redis的过期删除策略”、“Redis持久化有哪几种方式区别是什么”、“缓存穿透、击穿、雪崩的区别和应对”。这几个概念特别容易混淆我帮大家梳理一遍缓存穿透查询一个不存在的key缓存里没有数据库里也没有每次请求都打到数据库。应对方案是布隆过滤器或者缓存空值。缓存击穿某个热点key在过期的一瞬间大量请求同时打到数据库。应对方案是互斥锁或者该热点key永不过期后台异步更新。缓存雪崩大量key同时过期或者Redis实例宕机导致数据库被大量请求压垮。应对方案是过期时间加随机值、多级缓存、Redis高可用。笔试题如果考缓存穿透除了答出布隆过滤器和缓存空值还有一个加分项是补充“缓存空值时要设置较短的过期时间一般30到60秒就够否则大量空值key会占用内存”。这个细节能体现你真得考虑过这个方案的实施成本。Redis持久化考的是RDB和AOF的区别。一句话版本RDB是快照恢复快但可能丢最后一次快照之后的数据AOF是日志最多丢一两秒的数据但恢复慢、文件大。生产环境的常见做法是RDBAOF混合使用既保证重启恢复速度又尽量降低数据丢失风险。4.3 慢查询和索引的基础排查MySQL慢查询的题笔试里几乎必考。一种是问你怎么开启慢查询日志另一种是给你一条执行很慢的SQL让你分析原因和优化思路。开启慢查询日志的方式是在MySQL配置文件里设置slow_query_log ON slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1long_query_time 1表示超过1秒的SQL都会被记录。生产环境一般会把这个阈值设置得更低比如500毫秒甚至200毫秒因为对于业务系统来说超过200毫秒的查询已经能感知到卡顿了。遇到一条慢SQL我的排查习惯是先用EXPLAIN看执行计划重点看type字段是不是ALL全表扫描key字段有没有用到索引rows预估扫描了多少行。如果判断是缺索引就用CREATE INDEX idx_name ON table(column)加索引。这里要提醒笔试答题的时候写出完整的创建索引语句不要只写“加索引”三个字那跟没答是一样的。5. 场景题排查思路与高分模板5.1 服务启动失败的排查套路场景题是校招笔试里最能拉开差距的题型。我先说一个最经典的服务启动失败问题题目大概是部署好的新版本服务启动报错进程起不来日志也没有明显报错你怎么排查。这道题考察的是“面对未知问题你的排查路径是否清晰”。我的答题思路是这样的大家可以直接当模板用先看进程有没有起来ps -ef | grep 服务名如果进程在但端口没监听说明启动到一半崩了。再看端口监听状态ss -lntp | grep 端口确认端口是否被占用或者没有监听。查系统日志journalctl -u 服务名 --since 5 minutes ago。查应用日志重点看启动时最后输出的几行报错。看资源限制ulimit -n和df -h排查是不是文件句柄耗尽或者磁盘写满导致无法启动。最后才是尝试手动启动并看前台输出或者用strace跟踪系统调用。这套流程从前到后由浅入深每一步都有明确的目的。笔试答题把流程写出来比直接给一个“查看日志”的答案要完整得多。面试官看到这种答案脑子里第一反应就是“这人真的处理过线上故障”。5.2 磁盘空间满的处理流程磁盘写满算是业务运维最常遇到的事故之一笔试考到的概率极高。典型的问题是服务器磁盘使用率100%服务出现异常怎么处理。比“删除日志”这个答案更完整的回答应该包含以下步骤先用df -h确认是哪个分区满了顺便看inode够不够有些系统出现“No space left on device”的报错但df -h显示还有空间那就是inode耗尽。用du -h --max-depth1 /目录逐层定位大文件或者大目录这个过程叫“从根上往下查”。找到大文件后确认是不是可以安全删除比如旧的日志归档、临时文件、core dump文件。对于正在被进程占用但被删除了的文件用lsof | grep deleted找到哪个进程还在持有句柄这种情况如果只删文件不重启进程磁盘空间不会真正释放。第四点特别重要很多新手在线上删了文件发现磁盘空间没变化就是没弄懂“文件被删除但进程还在写”这个原理。笔试能写出lsof | grep deleted这一步说明你真正理解Linux文件系统的删除机制。5.3 网络不通的定位思路网络不通的场景题可以有一百种出题方式但核心排查思路是一样的。我给一个通用的定位模板先判断是“完全不通”还是“某些网络不通”。本机ping 127.0.0.1通说明网卡协议栈正常ping 网关IP不通说明二层有问题ping 外网IP不通可能是路由或者运营商问题。再判断是IP层问题还是端口层问题。ping通但telnet IP 端口不通说明目标主机的防火墙过滤或者服务没有监听。然后用traceroute看路径定位是哪个跳数丢包严重。最后结合业务拓扑判断是单点问题还是链路问题比如直播卡顿就要看是推流链路还是拉流链路。这套模板在笔试里可以直接套用无论题目怎么包装万变不离其宗。6. Shell脚本题的实战技巧与避坑6.1 日志分析类脚本的高频写法成都场的笔试手写脚本题最常出的就是日志分析。比如给你一个nginx访问日志让你统计访问量最大的前10个IP。这道题考察的是awk、sort、uniq这几个命令的组合使用。标准答案awk {print $1} access.log | sort | uniq -c | sort -rn | head -10拆解一下每个环节的作用awk {print $1}提取第一列IPsort排序让相同IP相邻uniq -c去重并统计次数sort -rn按次数倒序排列head -10取前10个。这个命令链是日志分析的经典套路笔试必背。变体题可能是不统计IP而是统计某个URL的访问量那就把$1换成$7。也可能要求过滤掉某个状态码那就加一层grep。掌握了命令链的组合思想怎么变都不怕。6.2 批量操作脚本的边界处理批量操作的脚本题比如“把 /data 目录下所有 .log 文件打包并移动到 /backup 目录”这道题考察的是对for循环、变量引用、文件是否存在这些细节的把握。一个比较稳的写法for file in /data/*.log; do if [ -f $file ]; then tar -czf $file.$(date %Y%m%d).tar.gz $file mv $file.$(date %Y%m%d).tar.gz /backup/ fi done注意几个细节[ -f $file ]判断文件存在才操作防止通配符没匹配到文件时直接操作字符串变量最好加双引号避免路径里带空格导致命令报错$(date %Y%m%d)每次调用时间可能不一样稳妥做法是先赋值给一个变量再复用。这些细节在笔试里写不写直接反映你的脚本经验是“能跑”还是“工程化”。6.3 笔试手写脚本的踩坑总结手写脚本最容易踩的坑我整理了几条漏了#!/bin/bash开头虽然阅卷不一定会扣分但正规脚本都该有。变量赋值等号两边不要有空格写成file /data/access.log是错的这是新手最常见的笔误。if后面的判断条件和方括号之间要有空格if [ -f $file ]才是合法语法。循环里用到管道的时候注意管道的变量修改不会带出循环体这是Shell的经典坑不过笔试问得比较少。写脚本题的时候即使时间紧张写不完整也把思路和关键命令写出来让阅卷人知道你懂怎么实现。很多笔试题目是按点给分的不要因为一个地方卡住就整道题放弃。7. 常见误区与实战经验总结7.1 校招笔试最常见的几个翻车点从阅卷角度和当年参加考试的同学反馈来说笔试翻车通常不是不会做而是错在一些很基础的地方。第一个是命令拼写错误。systemctl拼成systemctrlcrontab拼成crontrab这些错误在笔试里出现非常可惜。建议考前把高频命令完整默写一遍别以为眼熟就行手写和识别是两码事。第二个是场景题只答结论不答过程。比如题目问“用户反映直播间卡顿怎么排查”只写“可能是网络问题”就结束了。这种答案几乎没有得分。正确的打开方式是描述排查顺序、每一步看什么指标、怎么判断问题范围是个别用户还是所有用户、是推流端还是播放端、最后如何定位。第三个是不注意答题的完整性。题目如果问“怎么开启MySQL慢查询日志”不能只答配置文件改参数还要写改完后需要重启或者用SET GLOBAL热加载。这说明你对操作的影响面有没有概念。7.2 给准备校招的运维同学几条实用建议笔试只是校招的第一关从长远来看真正重要的还是你对运维这份工作的理解有没有到位。我给几条实用建议第一扎实练好Linux基本功。我在实际工作招人时发现很多应届生的简历里写着“熟悉Linux”但连awk、sed、grep这三个文本处理命令的组合用法都写不流利。笔试是一个筛选器基本功不扎实的在这关就会被刷掉这很公平。第二学会用“链路思维”看问题。业务运维和其他运维方向最大的不同是你眼里要有整条业务链路。服务挂了不是只查服务器本身还要看上游依赖、下游调用、网络链路、缓存命中率。平时多画画系统架构图笔试遇到场景题会顺手很多。第三多动手搭环境实践。笔试考的是纸面的知识但面试和实际工作考的是动手能力。建议自己用虚拟机装一套Linux环境把nginx、MySQL、Redis都手动部署一遍再人为制造一些故障比如把磁盘写满、删掉某个系统文件、错误配置防火墙然后练习排查和恢复。这个过程比刷一百道笔试真题都有用。第四关注岗位方向。业务运维和纯网络运维、桌面运维、系统运维的知识侧重并不完全相同。投递之前先研究一下岗位JD里写的能力要求有针对性地准备不要拿着一套资料去面所有岗位。7.3 笔试结束之后还能从中学到什么很多人把笔试当成“考完就完”的一次性任务但我自己的经验是一场校招笔试其实是一次很好的知识体检。当年我参加完欢聚时代这场笔试发现自己在网络知识这块特别薄弱后来花了一段时间专门补TCP、HTTP、DNS这些基础补完之后处理线上问题的思路明显清晰了很多。现在回过头看笔试里那些题目本身已经有些年头了技术栈可能会变但考察的能力模型一直没变对Linux系统的熟练度、对网络基础的理解、对数据库和缓存的认识、以及面对故障时的排查逻辑。这四块能力不管过多少年都是业务运维吃饭的家伙。最后再多说一句如果笔试中遇到完全没头绪的题目不要空着。把你能想到的排查命令、相关思路、可能的原因都写上去哪怕方向不完全正确至少让面试官看到你的思考过程。运维这个岗位非常看重解决问题的能力而“面对未知问题时愿意动手去查”的态度有时候比答案本身更重要。 业务运维校招笔试实战解析：从Linux基础到故障排查
1. 内容整体设计与思路拆解1.1 这场笔试到底在考什么聊到欢聚时代2018校招的业务运维岗位我的记忆还是挺深的。当年成都场的笔试题拿到手里第一反应是这公司是真的在招运维不是随便出两张卷子走过场。整张卷子没有一道纯背概念的题所有题目都落在“你到了线上能不能处理事”这个维度上。业务运维这个岗位和纯系统运维、网络运维最大的区别在于你维护的不只是服务器而是一整套“业务链路”。用户从App点一下直播背后涉及DNS解析、CDN调度、接入层负载均衡、业务网关、IM消息推送、直播间房间状态、弹幕消息队列、录制转码集群、对象存储回源……这一整条链路里任何一个环节出问题用户侧的体感就是卡顿、进不去、黑屏、声音不同步。所以笔试题的命题思路本质上就是在模拟“业务出问题你能不能定位”这个场景。成都场比较有代表性的几个考察方向我复盘下来大概是这几类Linux基础命令和系统状态排查给一堆输出让你判断系统哪里出了问题。网络基础知识TCP握手、HTTP状态码、DNS解析过程这些高频点。数据库和缓存MySQL的SQL编写、Redis的常见使用场景和坑。Shell脚本编程手写脚本完成日志分析、批量操作。场景题模拟一个线上故障让你描述排查思路和处理方案。这个结构很典型几乎把业务运维日常工作中最常用的几块能力全覆盖了。作为过来人我建议准备校招的同学不要死记硬背题目的标准答案而是从“如果这台服务器现在归我管我该怎么处理”的角度去理解每一类题背后的逻辑。1.2 成都场的特殊性在哪里很多人会问校招笔试题既然全国统一出为什么还要标“成都场”根据当年参加过的同学反馈和我的了解欢聚时代的校招笔试虽然是同一套题库但不同城市场的题目侧重点会有微调尤其是业务运维这种岗位。成都场有一个明显特点手写代码的题量占比比其他场次要高。因为成都的团队偏底层基础设施和中间件方向面试官比较看重候选人的脚本功底和Linux操作熟练度。另外成都场的场景题更偏向“直播业务”相关的故障毕竟欢聚的核心产品YY直播、虎牙直播当年还在集团体系内对音视频链路的要求非常高笔试出题自然会往这个方向倾斜。所以准备这场笔试你不能只刷通用的运维面试题一定要把“直播业务场景下运维会遇到哪些典型问题”单独当做一个模块来准备。比如直播间进不去、推流断开、卡顿率升高、弹幕延迟变大这些场景背后的链路排查思路都是高频考点。1.3 笔试的隐藏评分标准笔试不是只看你答对了没有还会看你的答题习惯和思维方式。我自己也参与过校招笔试的阅卷说几个真实的评分倾向场景题答得好不好关键看“排查顺序”。上来就重启大法、直接重装系统的分数不会高。有条理地“先看系统负载、再看进程状态、然后看日志、最后才操作”这种思路才是加分项。手写脚本哪怕是伪代码也要把流程写清楚。面试官会看你有没有考虑到边界情况比如文件不存在、日志格式带空格、目录需要先创建这些细节。写SQL题的时候字段名和表名写错字是大忌。笔试阅卷不会像机器判题那样完全按关键字匹配但字段对不上基本就没分了。这些隐藏标准说实话比题目本身更值得研究。答对题目只能保证及格答出“生产环境的思维”才能拿高分。2. Linux系统管理与命令细节解析2.1 文件管理和权限控制的必考姿势Linux是运维的基本盘笔试里文件管理和权限这块的题目一般不会缺席。最常见的出题方式是给你一段ls -l的输出让你解释每一列的含义或者问某个用户对某个文件有没有写权限。看起来基础但很多同学挂在细节上。举个例子题目给一个文件权限-rw-r--r--拥有者是 root组是 root问一个普通用户能不能修改这个文件。很多人看到“r--r--”就直接说不能这没错但如果没有补充“除非用户属于root组或者文件有ACL特殊权限”这个前提条件就会被认为考虑得不够全面。实际答题的时候先答标准权限判断再补一句“如果有ACL或者root用户可以直接操作”这种边界情况会显得你见过真实的生产环境。文件管理方面笔试常考的还有软链接和硬链接的区别。一句话版本软链接是快捷方式删了原文件链接就断硬链接是同一个inode的另一个名字删一个不影响另一个。成都场那年就出了一道题让你用ln命令创建硬链接然后问删除原文件后通过硬链接还能不能读到内容。答案是能因为硬链接指向的inode还在数据没有被真正释放。2.2 进程排查和资源定位的实战思路进程这块是业务运维笔试的重头戏出题方式通常有两种一种是给你top或者ps的输出让你分析系统状态另一种是场景题里让你排查CPU飙升的问题。先说top输出分析的答题套路。看到top的第一眼重点看三块load average、%CPU和%MEM、以及排在前面的是哪个进程。load average有三个数值分别代表1分钟、5分钟、15分钟的平均负载。如果三个数都高说明系统持续过载如果只有1分钟高而15分钟低说明是突发流量或者刚启动的任务导致的尖峰。这个判断逻辑面试官很在意因为它能体现你对“负载”这个概念有没有真正的理解。再说CPU飙升的场景题这是我在前面提到的“高频故障”之一。标准排查顺序应该是先用top找到CPU占用最高的进程PID。再用top -H -p PID找到这个进程内部哪个线程在吃CPU。然后用printf %x\n 线程ID把线程ID转成十六进制。最后用jstack PID | grep -A 30 线程ID的十六进制看线程堆栈定位到具体代码行。这套流程在笔试里写出来比直接写“重启服务”要高级太多。因为面试官可以从这个回答里看出你是真的处理过线上问题而不是只背了面试题。2.3 计划任务和日志管理的靠谱写法crontab也是笔试常客而且经常结合场景题出现。比如题目说“每天凌晨2点需要清理 /data/logs 下7天前的日志文件请写出crontab配置”。标准答案如果是0 2 * * * rm -rf /data/logs/*.log那基本就挂了。首先是find加-mtime的写法问题其次清理日志一般不建议用rm而是用find ... -delete或者在脚本里先把日志压缩归档再删除避免误删正在写入的文件。一个生产环境可用的写法是0 2 * * * find /data/logs -type f -name *.log -mtime 7 -delete /var/log/cleanup.log 21这里有几个细节值得展开-mtime 7表示修改时间超过7天-type f只处理文件不碰目录避免误删了目录结构。输出重定向到日志文件是为了方便回溯排查“为什么没删掉”或者“为什么删多了”的时候有据可查。日志这块笔试还可能考rsyslog的简单配置、logrotate的配置项比如按大小切割、保留多少份。实际工作中的经验是logrotate比很多人想象的更重要日志不切割导致磁盘写满的事故我在不同公司都见过好几回。笔试如果考到一定要答出daily、rotate 7、compress这几个关键参数的含义。3. 网络与Web服务的核心考点3.1 TCP和HTTP的细节才是拉分项网络部分的笔试题目表面看考的是“三次握手和四次挥手的过程”但成都场的出题风格是往细节里抠。我在其他地方看到过这道变体就是给你一个抓包结果让你判断这个TCP连接处于什么状态。正常的握手过程不说了我重点说两个容易被忽略的细节。第一个是“为什么是三次握手而不是两次”这道题的深度版本要答到“防止已失效的连接请求突然又传到服务端导致服务端误开连接”。第二个是“TIME_WAIT状态为什么需要等待2MSL”因为要保证最后一个ACK能到达对端同时让本连接产生的所有报文在网络中消失避免干扰后续连接。HTTP状态码更是业务运维笔试的送分题和送命题。送分是因为常见状态码大家都会背送命是因为只会背常见的不够。成都场那年就考了一个502 Bad Gateway和504 Gateway Timeout的区别。简单说502是网关从上游收到了无效响应504是网关等上游响应等超时了。但深入一层这两个状态码对应的排查方向完全不同502要先查后端服务是否存活、端口是否在监听、防火墙是否拦截504要查后端服务处理请求是否太慢、网关的超时时间设置是否合理。3.2 DNS解析流程和排查方法DNS这块笔试常考的题目是全链路解析过程。比如用户在浏览器输入一个域名背后发生了哪些事。标准答题链路是浏览器缓存、操作系统缓存、本地hosts文件、本地DNS服务器LDNS、根DNS服务器、顶级域服务器、权威DNS服务器。很多同学把这七层背下来就完事了但从业务运维的角度面试官更想听到的是“怎么排查DNS问题”。补充一下我会写的排查思路先用nslookup或dig看解析结果是否正确。再对比dig 114.114.114.114和dig 8.8.8.8的结果判断是不是本地DNS缓存的问题。然后看解析出来的IP是不是预期IP如果解析到了CDN的节点还要确认是不是调度到了就近节点。这个排查思路在笔试场景题里特别好用。因为DNS故障的典型表现是“一部分用户能访问一部分不能”或者“域名解析到了错误的IP”如果你能完整写出从用户侧到服务侧的排查链路基本就能拿满分。3.3 Nginx配置题的高分套路Nginx是业务运维笔试的压轴常客出题形式一般是给一个配置片段让你解释含义或者补全配置。比如server { listen 80; server_name example.com; location /api/ { proxy_pass http://backend_server; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }看到这道题不能只回答“这是反向代理配置”。要把每个指令都解释到位proxy_pass是做反向代理转发proxy_set_header Host $host是把客户端请求的Host头传给后端X-Real-IP $remote_addr是让后端能拿到用户真实IP。如果后端是Tomcat或者Java应用通常还会有一行proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for这是为了传递完整的代理链路信息。另一个常考的是负载均衡配置里 upstream 的调度策略。笔试答案进阶一点可以这样说默认是轮询weight按权重分配ip_hash按客户端IP哈希保证同一用户请求落到同一台后端least_conn会把请求发给当前连接数最少的后端。每个策略的适用场景不同比如需要session保持的场景优先用ip_hash但如果是分布式缓存之类的无状态服务用默认轮询就够了。3.4 防火墙和系统安全的常识性问题成都场的笔试里防火墙的题考得不算深但基本都会带一两道。比如iptables允许某IP访问本机80端口规则应该怎么写iptables -A INPUT -s 10.0.0.1/32 -p tcp --dport 80 -j ACCEPT这里有个坑是很多新手会漏了先允许回包流量。更稳妥的写法是在INPUT链里加一条状态相关的放行规则iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT笔试考到防火墙其实考的是你有没有生产环境配置防火墙的经验。因为单机房时代可以图省事直接关防火墙但稍微大一点的集群防火墙策略直接关系到业务的安全和可用性。这个点在回答里带一句“实际场景中还会考虑规则顺序因为iptables的规则是从上往下匹配的”会非常加分。4. 数据库与缓存的高频考点4.1 MySQL笔试必备SQL编写和主从复制MySQL在业务运维笔试里占的比重很高因为几乎所有互联网业务的核心数据都落在MySQL里。SQL题一般给你两张表让你写查询语句考的是JOIN、GROUP BY、HAVING这些基本语法。我不展开具体的SQL语法了只说一个笔试做题的经验写完SQL一定要自己检查一遍字段名、表名、别名是否一一对应。很多同学思路完全正确就是因为把“表名.字段名”写错了结果白丢分。还有一个细节面试官会比较关注你是否会在GROUP BY后面使用HAVING而不是WHERE来过滤聚合结果。这是SQL书写的规范性也体现基础扎不扎实。主从复制的原理题也经常出现核心是讲清楚三个线程主库上的Binlog Dump 线程负责把binlog发给从库。从库上的I/O 线程负责接收binlog并写入中继日志relay log。从库上的SQL 线程负责读取中继日志并回放到从库。如果笔试出场景题“从库同步延迟怎么排查”我会这样答先show slave status\G看Seconds_Behind_Master的值再排查从库的磁盘IO是不是满了、大事务是不是在执行、主库的binlog是不是太大导致从库拉取不及时。还可以补充一条“检查从库有没有在做备份或者跑大批量分析任务”这种操作常会导致同步延迟属于生产环境非常典型的坑。4.2 Redis的必背考点和经典坑Redis在业务里最常见的用途是缓存、分布式锁、排行榜、会话保持。笔试常考的题目包括“Redis的过期删除策略”、“Redis持久化有哪几种方式区别是什么”、“缓存穿透、击穿、雪崩的区别和应对”。这几个概念特别容易混淆我帮大家梳理一遍缓存穿透查询一个不存在的key缓存里没有数据库里也没有每次请求都打到数据库。应对方案是布隆过滤器或者缓存空值。缓存击穿某个热点key在过期的一瞬间大量请求同时打到数据库。应对方案是互斥锁或者该热点key永不过期后台异步更新。缓存雪崩大量key同时过期或者Redis实例宕机导致数据库被大量请求压垮。应对方案是过期时间加随机值、多级缓存、Redis高可用。笔试题如果考缓存穿透除了答出布隆过滤器和缓存空值还有一个加分项是补充“缓存空值时要设置较短的过期时间一般30到60秒就够否则大量空值key会占用内存”。这个细节能体现你真得考虑过这个方案的实施成本。Redis持久化考的是RDB和AOF的区别。一句话版本RDB是快照恢复快但可能丢最后一次快照之后的数据AOF是日志最多丢一两秒的数据但恢复慢、文件大。生产环境的常见做法是RDBAOF混合使用既保证重启恢复速度又尽量降低数据丢失风险。4.3 慢查询和索引的基础排查MySQL慢查询的题笔试里几乎必考。一种是问你怎么开启慢查询日志另一种是给你一条执行很慢的SQL让你分析原因和优化思路。开启慢查询日志的方式是在MySQL配置文件里设置slow_query_log ON slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1long_query_time 1表示超过1秒的SQL都会被记录。生产环境一般会把这个阈值设置得更低比如500毫秒甚至200毫秒因为对于业务系统来说超过200毫秒的查询已经能感知到卡顿了。遇到一条慢SQL我的排查习惯是先用EXPLAIN看执行计划重点看type字段是不是ALL全表扫描key字段有没有用到索引rows预估扫描了多少行。如果判断是缺索引就用CREATE INDEX idx_name ON table(column)加索引。这里要提醒笔试答题的时候写出完整的创建索引语句不要只写“加索引”三个字那跟没答是一样的。5. 场景题排查思路与高分模板5.1 服务启动失败的排查套路场景题是校招笔试里最能拉开差距的题型。我先说一个最经典的服务启动失败问题题目大概是部署好的新版本服务启动报错进程起不来日志也没有明显报错你怎么排查。这道题考察的是“面对未知问题你的排查路径是否清晰”。我的答题思路是这样的大家可以直接当模板用先看进程有没有起来ps -ef | grep 服务名如果进程在但端口没监听说明启动到一半崩了。再看端口监听状态ss -lntp | grep 端口确认端口是否被占用或者没有监听。查系统日志journalctl -u 服务名 --since 5 minutes ago。查应用日志重点看启动时最后输出的几行报错。看资源限制ulimit -n和df -h排查是不是文件句柄耗尽或者磁盘写满导致无法启动。最后才是尝试手动启动并看前台输出或者用strace跟踪系统调用。这套流程从前到后由浅入深每一步都有明确的目的。笔试答题把流程写出来比直接给一个“查看日志”的答案要完整得多。面试官看到这种答案脑子里第一反应就是“这人真的处理过线上故障”。5.2 磁盘空间满的处理流程磁盘写满算是业务运维最常遇到的事故之一笔试考到的概率极高。典型的问题是服务器磁盘使用率100%服务出现异常怎么处理。比“删除日志”这个答案更完整的回答应该包含以下步骤先用df -h确认是哪个分区满了顺便看inode够不够有些系统出现“No space left on device”的报错但df -h显示还有空间那就是inode耗尽。用du -h --max-depth1 /目录逐层定位大文件或者大目录这个过程叫“从根上往下查”。找到大文件后确认是不是可以安全删除比如旧的日志归档、临时文件、core dump文件。对于正在被进程占用但被删除了的文件用lsof | grep deleted找到哪个进程还在持有句柄这种情况如果只删文件不重启进程磁盘空间不会真正释放。第四点特别重要很多新手在线上删了文件发现磁盘空间没变化就是没弄懂“文件被删除但进程还在写”这个原理。笔试能写出lsof | grep deleted这一步说明你真正理解Linux文件系统的删除机制。5.3 网络不通的定位思路网络不通的场景题可以有一百种出题方式但核心排查思路是一样的。我给一个通用的定位模板先判断是“完全不通”还是“某些网络不通”。本机ping 127.0.0.1通说明网卡协议栈正常ping 网关IP不通说明二层有问题ping 外网IP不通可能是路由或者运营商问题。再判断是IP层问题还是端口层问题。ping通但telnet IP 端口不通说明目标主机的防火墙过滤或者服务没有监听。然后用traceroute看路径定位是哪个跳数丢包严重。最后结合业务拓扑判断是单点问题还是链路问题比如直播卡顿就要看是推流链路还是拉流链路。这套模板在笔试里可以直接套用无论题目怎么包装万变不离其宗。6. Shell脚本题的实战技巧与避坑6.1 日志分析类脚本的高频写法成都场的笔试手写脚本题最常出的就是日志分析。比如给你一个nginx访问日志让你统计访问量最大的前10个IP。这道题考察的是awk、sort、uniq这几个命令的组合使用。标准答案awk {print $1} access.log | sort | uniq -c | sort -rn | head -10拆解一下每个环节的作用awk {print $1}提取第一列IPsort排序让相同IP相邻uniq -c去重并统计次数sort -rn按次数倒序排列head -10取前10个。这个命令链是日志分析的经典套路笔试必背。变体题可能是不统计IP而是统计某个URL的访问量那就把$1换成$7。也可能要求过滤掉某个状态码那就加一层grep。掌握了命令链的组合思想怎么变都不怕。6.2 批量操作脚本的边界处理批量操作的脚本题比如“把 /data 目录下所有 .log 文件打包并移动到 /backup 目录”这道题考察的是对for循环、变量引用、文件是否存在这些细节的把握。一个比较稳的写法for file in /data/*.log; do if [ -f $file ]; then tar -czf $file.$(date %Y%m%d).tar.gz $file mv $file.$(date %Y%m%d).tar.gz /backup/ fi done注意几个细节[ -f $file ]判断文件存在才操作防止通配符没匹配到文件时直接操作字符串变量最好加双引号避免路径里带空格导致命令报错$(date %Y%m%d)每次调用时间可能不一样稳妥做法是先赋值给一个变量再复用。这些细节在笔试里写不写直接反映你的脚本经验是“能跑”还是“工程化”。6.3 笔试手写脚本的踩坑总结手写脚本最容易踩的坑我整理了几条漏了#!/bin/bash开头虽然阅卷不一定会扣分但正规脚本都该有。变量赋值等号两边不要有空格写成file /data/access.log是错的这是新手最常见的笔误。if后面的判断条件和方括号之间要有空格if [ -f $file ]才是合法语法。循环里用到管道的时候注意管道的变量修改不会带出循环体这是Shell的经典坑不过笔试问得比较少。写脚本题的时候即使时间紧张写不完整也把思路和关键命令写出来让阅卷人知道你懂怎么实现。很多笔试题目是按点给分的不要因为一个地方卡住就整道题放弃。7. 常见误区与实战经验总结7.1 校招笔试最常见的几个翻车点从阅卷角度和当年参加考试的同学反馈来说笔试翻车通常不是不会做而是错在一些很基础的地方。第一个是命令拼写错误。systemctl拼成systemctrlcrontab拼成crontrab这些错误在笔试里出现非常可惜。建议考前把高频命令完整默写一遍别以为眼熟就行手写和识别是两码事。第二个是场景题只答结论不答过程。比如题目问“用户反映直播间卡顿怎么排查”只写“可能是网络问题”就结束了。这种答案几乎没有得分。正确的打开方式是描述排查顺序、每一步看什么指标、怎么判断问题范围是个别用户还是所有用户、是推流端还是播放端、最后如何定位。第三个是不注意答题的完整性。题目如果问“怎么开启MySQL慢查询日志”不能只答配置文件改参数还要写改完后需要重启或者用SET GLOBAL热加载。这说明你对操作的影响面有没有概念。7.2 给准备校招的运维同学几条实用建议笔试只是校招的第一关从长远来看真正重要的还是你对运维这份工作的理解有没有到位。我给几条实用建议第一扎实练好Linux基本功。我在实际工作招人时发现很多应届生的简历里写着“熟悉Linux”但连awk、sed、grep这三个文本处理命令的组合用法都写不流利。笔试是一个筛选器基本功不扎实的在这关就会被刷掉这很公平。第二学会用“链路思维”看问题。业务运维和其他运维方向最大的不同是你眼里要有整条业务链路。服务挂了不是只查服务器本身还要看上游依赖、下游调用、网络链路、缓存命中率。平时多画画系统架构图笔试遇到场景题会顺手很多。第三多动手搭环境实践。笔试考的是纸面的知识但面试和实际工作考的是动手能力。建议自己用虚拟机装一套Linux环境把nginx、MySQL、Redis都手动部署一遍再人为制造一些故障比如把磁盘写满、删掉某个系统文件、错误配置防火墙然后练习排查和恢复。这个过程比刷一百道笔试真题都有用。第四关注岗位方向。业务运维和纯网络运维、桌面运维、系统运维的知识侧重并不完全相同。投递之前先研究一下岗位JD里写的能力要求有针对性地准备不要拿着一套资料去面所有岗位。7.3 笔试结束之后还能从中学到什么很多人把笔试当成“考完就完”的一次性任务但我自己的经验是一场校招笔试其实是一次很好的知识体检。当年我参加完欢聚时代这场笔试发现自己在网络知识这块特别薄弱后来花了一段时间专门补TCP、HTTP、DNS这些基础补完之后处理线上问题的思路明显清晰了很多。现在回过头看笔试里那些题目本身已经有些年头了技术栈可能会变但考察的能力模型一直没变对Linux系统的熟练度、对网络基础的理解、对数据库和缓存的认识、以及面对故障时的排查逻辑。这四块能力不管过多少年都是业务运维吃饭的家伙。最后再多说一句如果笔试中遇到完全没头绪的题目不要空着。把你能想到的排查命令、相关思路、可能的原因都写上去哪怕方向不完全正确至少让面试官看到你的思考过程。运维这个岗位非常看重解决问题的能力而“面对未知问题时愿意动手去查”的态度有时候比答案本身更重要。