前几天整理移动硬盘翻到一份2018年秋招的资料里面有当年欢聚时代校招的业务运维笔试题。那会儿直播和社交业务正打得火热运维岗位的笔试也远没有现在这么卷但回看这套题再对照我后面几年在业务运维一线的经历发现很多考点其实一直没变——基础命令、网络排查思路、数据库原理、脚本能力、场景题的整体答题框架依然是业务运维工程师的核心竞争力。这篇文章我就借这套题聊聊业务运维笔试到底考什么、背后在筛选什么人以及现在准备这类校招笔试哪些思路依然值得借鉴。1. 业务运维笔试到底在筛什么人先说清楚业务运维这个岗位的定位。欢聚时代当年核心产品是YY直播、多玩、以及后面起来的各类社交产品业务体量大、用户在线时长高、实时性要求强。这类公司的业务运维不是传统意义上管服务器、装系统、定期备份的机房运维而是贴着业务走的——直播卡不卡、弹幕延迟高不高、活动大促扛不扛得住、线上故障能不能快速定位这些都是业务运维要管的事。所以笔试的筛选逻辑很清晰基础要扎实链路要清楚动手要能写遇事要有思路。我后来带校招生发现这套筛选逻辑至今有效。基础不扎实的人遇到线上问题只会重启和回滚链路不清楚的人给他拓扑图也不知道从哪查起不能写脚本的人日志分析全靠手翻效率极低没有排查思路的人一告警就慌群里刷屏也找不出根因。回看当年这套题题型分布大概是这样考察模块主要题型占比估考察目的Linux基础与命令选择、填空、简答25%日常操作基本功网络基础与排查选择、简答、场景20%网络链路理解与排障能力数据库与缓存选择、简答20%数据链路认知Shell/Python脚本编程题20%自动化能力业务场景分析场景题15%整体排障与容量思路这个分布和现在很多互联网公司运维笔试的侧重点基本一致只是现在会额外加容器、K8s、CI/CD相关的内容。接下来我按模块拆开讲每块都会结合当年题目复盘和一些我在实际工作中验证过的判断。2. Linux基础与命令行送分题里的隐藏陷阱Linux基础题是整套卷子里最不能丢分的部分。这批题看上去简单但恰恰是区分背过命令和真用过命令的地方。我印象比较深的有几类。2.1 文件权限和用户管理光会chmod 777是不够的题目考的是类似这样的场景一个Web服务以www用户运行日志目录需要让部署用户比如deploy可读但不可写同时其他用户不能访问。这种题写法有很多但正确思路是检查目录权限数字、属主属组以及对特殊权限位setuid、setgid、sticky bit的理解。我实际工作中就遇到过因为权限配置不对导致新版应用启动后写不了日志排查了半天发现目录被某次批量操作设成了只读。笔试当时只是填数字权限工作后才知道权限设计直接关系到服务安全和稳定性。建议准备这类题时不仅要记住chmod 755这种经典组合还要理解umask、chown、usermod这些命令在实际部署中的用法尤其是用户组和sudo权限配置属于面试追问概率很高的点。2.2 文本处理三剑客grep、awk、sed的实战考法文本处理几乎是每次运维笔试的保留节目考法极其固定给你一个Nginx或者Apache的访问日志文件让你统计某个接口的请求量、按IP聚合、取Top N。这类题看的是你平时有没有真的用命令行处理过日志而不是只在工具书里见过名字。典型的解法是awk {print $1} access.log | sort | uniq -c | sort -rn | head -20这个组合命令里awk负责取第一列也就是客户端IPsort排序后uniq -c去重并计数再次sort -rn按数字倒序排最后head取前20行。看着简单但很多人会漏掉第一个sort导致uniq统计出错——uniq只能合并相邻的重复行不排序的情况下统计结果一定是错的。这种细节就是笔试区分度所在。sed的考点通常是替换、删除、按行范围处理。比如把配置文件里的旧域名全部替换成新域名sed -i s/olddomain.com/newdomain.com/g nginx.conf这里-i表示直接修改文件笔试经常会问-i的作用以及不带-i和带-i的区别。我建议这类题多动手敲光看答案背下来上机实操很容易露馅。2.3 系统启动、进程管理与systemd2018年那会儿CentOS 7已经普及systemd相关题目开始出现在笔试题里。考察点包括查看服务状态、设置开机自启、查看端口监听、查看进程资源占用。常用命令基本是systemctl status nginx systemctl enable nginx systemctl start nginx ss -lntp ps aux --sort-%mem | head有一个容易混淆的点ss -lntp和老的netstat -lntp有什么区别笔试喜欢挖这类细节。ss是现阶段更推荐的工具netstat已经逐步被替代但很多人写命令时还习惯性用netstat。其实两者的核心信息一致但ss在连接数很大的情况下性能更好输出可读性也更强。我实际排障时基本都用ss快很多。另外进程优先级nice/renice、后台运行nohup和setsid的区别、僵尸进程怎么处理这些也是笔试高频点。它们在实际运维中出现的频率不高但一旦出现就是大事笔试考这些本质上是在考察系统原理的扎实程度。3. 网络基本功不背清楚三次握手场景题必吃亏网络题是业务运维笔试的大头。因为业务运维日常处理的大量问题本质上是网络问题——连接超时、丢包、握手失败、DNS解析异常。这套卷子在这方面着墨不少我把核心考点和答题思路拆一下。3.1 TCP三次握手与四次挥手理解比背诵更重要笔试常考描述TCP三次握手过程以及为什么是三次不是两次。单纯背出SYN、SYNACK、ACK不算完面试官往往会追问如果第三次握手丢了会怎样服务端的半连接队列和全连接队列会有什么变化实际生产环境中SYN队列溢出是一个经常遇到的故障点。当并发连接数突增超过系统tcp_max_syn_backlog或somaxconn设置时客户端表现就是连接建立缓慢或者超时服务端ss -lntp能看到大量SYN_RECV状态的连接。这种题如果在笔试里出现你除了把三次握手画出来最好还能补一句当半连接队列满时会发生丢包或者SYN Flood 表现这就能和其他候选人拉开差距。四次挥手也是同理重点在TIME_WAIT状态的理解。高并发的短连接服务服务器会出现大量TIME_WAIT占用本地端口。笔试问到这个合理的答题路径是先解释TIME_WAIT为什么存在为了保证最后一个ACK能到达对端以及让旧连接的数据包在网络中消逝再说如何优化调tcp_tw_reuse、开启长连接、调整tcp_fin_timeout而不是简单说把tcp_tw_recycle打开。tcp_tw_recycle开了会在NAT环境下引发更严重的问题这属于写进过很多坑总结的经典教训。3.2 网络排查工具的使用顺序笔试里经常给这样一个场景用户反馈某个页面打不开让你写出排查思路。答题的时候光列工具是不够的关键是顺序。我常用的排查顺序是先确认本机和服务端的连通性ping再确认端口是否可达telnet ip port或nc -vz ip port然后检查DNS解析nslookup/dig再抓包看具体交互tcpdump -i eth0 host x.x.x.x and port 80最后结合ss -lntp看服务端状态这个顺序看起来简单但很多人一上来就抓包反而被海量流量淹没。笔试作答时写出先通性、后端口、再解析、最后抓包的递进逻辑比单纯堆命令要加分得多。3.3 从直播业务看DNS、CDN和负载均衡的考点欢聚时代这种直播业务用户分布广、实时性强对网络链路的依赖非常重。笔试里DNS和CDN是必考项。DNS考点通常包括DNS解析过程递归查询与迭代查询、常见记录类型A、CNAME、MX、TXT、DNS缓存对业务变更的影响。实际业务中很经典的一个坑是改了CDN的CNAME记录后因为本地DNS缓存或者客户端缓存部分用户长时间访问的还是旧节点造成业务异常。笔试考DNS本质上是看你能不能理解DNS变更不是即时生效的这一业务事实。CDN考点则偏向于回源链路。比如直播推流和拉流是否走CDN、CDN节点缓存是否生效、回源失败的表现是什么。答这类题要有端到端链路的概念用户播放卡顿可能是用户本地网络差、CDN节点故障、源站压力大、或者链路质量劣化不能只看某一跳。负载均衡也是高频考点。LVS、Nginx、HAProxy的区别四层和七层负载均衡的应用场景会话保持怎么实现健康检查怎么配置。笔试如果给一张简单的架构图用户 - CDN - Nginx(LVS) - 应用服务 - DB/Redis让你指出单点环节能答出接入层Nginx可以双机主备、应用服务多实例、DB和Redis要做主从或集群这道题就稳了。4. 数据库与缓存数据链路的必考环节业务运维可以不用写业务代码但必须懂数据是怎么流转和存储的。笔试中的数据库题目重点落在MySQL和Redis两块。4.1 MySQL索引、事务隔离级别、慢查询索引几乎是每年必考。常见问题包括索引为什么用B树而不是哈希或二叉树最左前缀原则是什么explain输出中的type字段怎么判断索引效率like %xx%为什么走不了索引笔试题里最容易丢分的是事务隔离级别。MySQL默认隔离级别是Repeatable Read需要搞清楚四种隔离级别分别解决什么问题Read Uncommitted有脏读Read Committed解决脏读但可能有不可重复读Repeatable Read解决不可重复读但可能有幻读Serializable最严格但性能最差。如果题目问InnoDB在Repeatable Read下如何解决幻读能答出通过间隙锁Gap Lock和临键锁Next-Key Lock就是加分项。慢查询这块笔试常给一条执行很慢的SQL让你分析原因。答题要点包括先看是否命中索引、是否全表扫描、数据量多大、是否有锁等待、explain结果如何、是否需要拆分查询或加缓存。实际工作中我处理过很多同样一条SQL白天正常晚上就慢的问题最后定位到是定时任务和大查询撞在一起导致行锁竞争。这种从数据链路角度反推业务行为的思维笔试时也要体现。4.2 Redis缓存穿透、击穿、雪崩Redis作为业务缓存层考题集中在数据类型、过期策略、持久化、以及三种经典故障场景。三种故障场景一定要区分清楚缓存穿透查询一个不存在的key请求直接打到DB。应对方案布隆过滤器、缓存空值。缓存击穿某个热点key过期一瞬间大量请求打到DB。应对方案互斥锁、逻辑过期、热点key不过期。缓存雪崩大量key同时过期或者Redis宕机导致DB被压垮。应对方案过期时间加随机值、多级缓存、Redis高可用。这三种场景在直播业务里太常见了。比如一场大促活动某个商品的库存key恰好过期瞬间流量全部穿透到数据库DB连接数打满整个服务雪崩。业务运维笔试考这些就是看你对缓存层和存储层之间依赖关系的理解。Redis持久化RDB和AOF的区别也是常考选择/简答题。RDB是定时持久化文件体积小、恢复快但可能丢数据AOF是追加日志数据更安全但文件大、恢复慢。生产环境常两者结合使用。答这类题时如果还能提到AOF重写机制和子进程fork时的内存占用问题会显得你考虑得更深入。4.3 数据库连接数被打满的排查套路这是一道综合题笔试出现频率极高。题目通常是业务突然报数据库连接数超限让你给出排查步骤。我的答题框架大致是先看告警面和影响范围是全部业务还是某个接口。登录数据库执行show processlist;看当前连接都卡在什么状态。按来源IP、时间、SQL类型聚合找出是哪一类请求把连接吃满。检查是否有慢SQL积压explain分析执行计划。检查是否有连接泄漏比如代码里获取连接后没释放。临时手段调大max_connections、杀掉阻塞会话、重启连接池但一定要同步定位根因。这套思路笔试题能用面试追问也能用实际工作里更能用。我处理过一次典型的连接数打满事件根因就是某个新上线接口在循环里查数据库每次查询都新建连接连接池完全失效。表象是数据库连接数超限根子却在应用代码不动链路排查根本找不到。5. 脚本与自动化一道写监控脚本题能筛掉一半人运维笔试基本必有一道Shell或者Python编程题这道题是我认为整套卷子里淘汰率最高的。因为命令和原理可以靠背但脚本能力靠的是平时真写。2018年那套卷子的编程题核心出题方向大致两类一类是写监控脚本另一类是写日志统计。我分别展开说顺便给出可直接套用的模板。5.1 进程/服务监控脚本从能跑到能上线典型题目写一个Shell脚本监控Nginx进程如果发现进程不存在就自动拉起来并记录日志。一个能拿分的答案大概是这样的#!/bin/bash # nginx_monitor.sh NGINX_BIN/usr/local/nginx/sbin/nginx LOG_FILE/var/log/nginx_monitor.log if ! pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx is down, restarting... $LOG_FILE $NGINX_BIN sleep 2 if pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx restart success $LOG_FILE else echo $(date %Y-%m-%d %H:%M:%S) nginx restart failed, please check manually $LOG_FILE fi fi这个脚本看起来简单但有几个拿分点容易被忽略用了pgrep -x做精确匹配防止误杀grep进程或者其他带nginx字符的进程。记录了详细日志包括时间、动作、结果方便事后排查。拉起来之后再次确认而不是发完启动命令就完事。脚本以#!/bin/bash开头权限、格式都规范。进阶一点可以补一个周期执行的方案。笔试如果问怎么让这个脚本每1分钟跑一次,答crontab -e然后添加* * * * * /usr/local/scripts/nginx_monitor.sh并顺手补一句注意脚本路径要写绝对路径cron环境变量和交互shell不同容易踩坑这就体现出实战经验了。5.2 日志统计题用Python还是Shell都能过另一类高频编程题是日志统计。题目往往会伪装成最近公司上线了新活动让你统计某个时间段的用户访问情况本质是考察文本处理能力。如果笔试环境允许选择语言我建议熟练Shell就写Shell熟练Python就写Python不要纠结哪个更好能用最少时间写出正确结果最重要。一个Python版的URL访问量统计大概是from collections import Counter counter Counter() with open(access.log, r, encodingutf-8, errorsignore) as f: for line in f: parts line.split() if len(parts) 6: url parts[6] counter[url] 1 for url, cnt in counter.most_common(10): print(f{cnt}\t{url})这个版本的优势是逻辑清晰、不会漏掉Top N排序而且Counter.most_common直接把排序做了。Shell版可以更快写完但容易踩空格和管道坑。笔试时间有限我建议平时两种都练熟考场上选最顺手的那种。5.3 写脚本最容易触发的隐藏雷区脚本编程题丢分往往不是逻辑不会而是犯了几个经典错误变量赋值等号两边有空格比如NGINX_BIN /usr/local/nginx/sbin/nginx这在Shell里会直接报错。if语句的方括号内没留空格写成[$name nginx]运行时语法错误。忘记给脚本加执行权限或者不写shebang导致直接./script.sh执行失败。日志目录不存在就直接写文件脚本在无人值守时静默失败。这些问题在本地练习时很容易发现但笔试时一紧张就容易忽略。我建议准备阶段刻意用不同格式的日志文件多练几遍把常见的报错信息记熟这样笔试时能少踩很多坑。6. 业务场景题如果线上直播出现卡顿你怎么办场景题是整套笔试题里最贴近欢聚时代业务的一类也最考验综合能力。题目往往不是问什么是CDN,而是给一个具体业务故障场景让你讲述排查思路。我挑几个典型方向展开。6.1 一个典型的直播故障排查链路题目大意用户在App内观看某个主播的直播出现卡顿和延迟运营反馈问题持续了10分钟你作为业务运维怎么排查我的答题框架分四层第一层确认影响面。是整个平台的直播全卡还是某个主播、某个地区、某个网络环境Wi-Fi/4G的问题。这个信息决定了排查方向。如果是全平台问题大概率在源站或网络链路如果是单个主播优先怀疑主播端推流异常如果是某地区优先怀疑CDN节点故障。第二层按链路分段排查。直播链路通常是主播推流 - 边缘节点接入 - 源站转码/转发 - CDN分发 - 用户拉流播放。运维能查的是链路中各节点的状态、带宽、CPU、连接数、丢包率。笔试作答时画出这条链路本身就是得分点说明你有全局视角。第三层定位根因。这需要结合监控数据和日志。比如源站带宽被打满、CDN回源失败、某节点负载过高、网络运营商链路抖动。作答时如果能提到用tcpdump抓包分析是否有大量TCP重传、用mtr看链路节点延迟和丢包、用Grafana看源站带宽曲线会非常加分。第四层临时恢复与根治。临时手段是切流、扩容带宽、调整CDN调度策略根治手段是优化链路、节点容灾、加缓存、做质量监控和自动切换。6.2 容量规划与活动大促笔试题有时会升级成运营要搞一个主播PK活动预估在线人数是平时的3倍你如何评估系统是否扛得住。这类题考察的不是精确计算而是思路。我的答题框架是先梳理核心链路的所有组件包括接入层、应用层、缓存层、存储层、消息队列、CDN带宽。找历史数据做参考日常峰值QPS、在线人数、带宽消耗按3倍放大得到目标值。评估各组件瓶颈比如Nginx的并发连接数、MySQL的最大连接数、Redis的内存和带宽、出口带宽上下行。给出扩容建议包括云资源扩容、带宽升级、服务横向扩容、数据库只读副本等。如果笔试时间充裕还可以写一句建议提前做压测用压测数据替代估算数据这会让答案显得更专业。6.3 高可用设计从单点到无单点场景题里经常藏着高可用考点。比如给出一套简单的业务架构让你指出其中的单点故障。经典的坑有前端只有一台Nginx没有备机。MySQL只有一主一从从库只做备份不承担读流量。Redis没有持久化也没有高可用重启即丢数据。应用服务器本身做了多实例但所有实例连接同一个数据库DB成了单点。能答出接入层用Keepalived做VIP漂移、应用层多实例前置负载均衡、DB做主从并启用半同步复制、Redis用哨兵或集群方案这个层次就达到业务运维校招的合格线了。6.4 场景题答题的通用框架我把这类题的通用答法总结成四句话先定影响面再画链路图锁定可疑段给出止损和根治方案。这个框架在笔试和面试里都可以反复用比我见过很多人一上来就说重启用Nginx重启一下要靠谱得多。笔试时场景题不需要把每一步的具体命令写出来但一定要把排查顺序、判断依据、关键监控指标、临时恢复方案写清楚。阅卷人看的是思维有没有闭环而不是命令背了多少。7. 回看这套卷子给现在准备运维校招的人几句实在话欢聚时代那套题是2018年的这几年运维技术栈变化很大容器化、云原生、K8s、可观测性体系都成了主流业务运维笔试里也越来越多地出现K8s Pod调度、ingress、监控告警、日志采集这类题目。但说实话技术工具会变底层原理和解决问题的思路没变。我给我带过的实习生的建议是这样的。7.1 笔试暴露的问题面试一定会被追问不要以为笔试答完就过去了。很多公司会把你笔试中的错题作为面试时的追问素材。比如你笔试里写了netstat -lntp面试官可能就会问你知道ss和netstat有什么区别吗知道TIME_WAIT状态意味着什么吗如果你笔试时是蒙的这个环节会很难受。所以准备笔试时不要只背答案尽量把每道题涉及的知识点往深挖一层。一个很有效的办法是笔试结束后把每道错题对应到实际工作场景自己动手复现一遍。比如怎么看端口占用就真的开一台机器起一个服务用ss和lsof各查一遍再看/proc/net/tcp里的状态。做过一次后面就不会忘。7.2 时间和精力分配建议如果现在距离笔试还有两到三周我给这样的时间分配参考第一周集中刷Linux命令和网络基础争取选择填空拿满分。第二周练Shell脚本和Python脚本每天至少手写一个能跑的小脚本统计日志、监控进程、批量处理文件都可以。第三周主攻场景题和数据库/缓存题重点是把排查思路和多故障场景的应对方案形成自己的一套框架。要特别警惕只刷选择题的备考方式。选择题能帮你扫盲但笔试中的简答题和编程题才是拉开差距的地方。平时在虚拟机或者云服务器上多操作效率比只看资料高很多。7.3 业务感是校招生最容易被忽略的加分项最后说一个校招笔试里很少被提到但很重要的点业务感。同样回答直播卡顿怎么排查有人只写技术命令有人会先说直播链路包括推流、转码、分发、拉流不同环节的表现不一样卡顿是持续的还是间歇的、是所有人都卡还是部分区域卡这些信息决定了排查方向。后者就是业务感它来自对业务本身的理解而不是单纯的技术知识。对于业务运维来说技术是底子业务是方向。没有业务感技术再好也可能在错误的方向上使劲。准备笔试时多想想这套题背后的业务场景——直播业务关注实时性和链路质量电商业务关注大促峰值和库存一致性IM业务关注消息可靠性和推送延迟——答题时自然能更有针对性。我现在回看2018年这套题最大的感受是纸上得来终觉浅运维这门手艺考的是从知道到做到的距离。笔试只是第一道门真正能让你站稳脚跟的是肯动手、懂业务、能扛事。希望这篇复盘能帮你把备考思路理顺少走点弯路。