一份合格的运维笔试题本质上不是在考你背了多少命令而是在“短时间、无设备、纯脑内”的条件下检验你排查故障时的思维链路是否清晰。爱奇艺2019秋招运维方向笔试题B就是典型代表。它没有超纲的偏题怪题但每道题都踩在运维日常工作的核心痛点上比如Linux系统状态分析、网络排查思路、数据库与中间件的高频故障处理。这篇文章我就以这套题为引子把运维笔试常见的命题逻辑、高频考点和实战作答思路整理出来。无论你是准备校招还是打算跳槽只要能把这份拆解吃透基本就能摸清大多数互联网公司运维笔试的出题套路。1. 从一份笔试题看运维岗位的能力要求1.1 出题人想筛选的不是“命令背诵机”我见过不少准备运维面试的同学把大量的时间花在背Linux命令参数上grep、awk、sed的每个选项都倒背如流结果一到笔试遇到“系统load average飙高你如何排查”这种开放性问题就懵了给出的答案东一榔头西一棒子。这恰恰暴露了一个核心问题出题人想看的从来不是你记住了多少个命令而是你在面对一个模糊的、无头绪的线上故障时能不能快速建立一个排查框架然后按照这个框架一步步缩小范围最终定位根因。爱奇艺2019秋招运维方向笔试题B里的绝大多数题目不管是以选择题、简答题还是场景题的形式出现最终都指向同一个考察目标——系统化的故障诊断能力。1.2 笔试题B卷的整体考点版图虽然这份试卷冠以“B”的编号但它反映出的考点结构是所有互联网公司运维笔试的通用模板。我把它拆解成四层第一层基础命令与系统原理。这一层最简单的也是用来淘汰“完全没接触过Linux”的候选人的。常见形式是“某条命令的输出是什么”“某条命令的作用是什么”。比如df -h、free -m、top输出的关键字段含义kill -9和kill -15的区别crontab的书写格式等。第二层网络排查能力。运维和网络是分不开的。这一层会考察TCP/IP协议栈的基础知识比如三次握手和四次挥手的过程、TIME_WAIT状态的理解、traceroute和tcpdump的使用场景。更高阶一点会给出一个网络症状比如“用户反馈访问超时”让你说明排查路径。第三层中间件与数据库运维。互联网公司的核心架构基本是“nginx 应用服务 MySQL Redis”这套组合拳。笔试里一定会出现MySQL的索引原理、主从复制延迟、慢查询优化以及Redis的缓存穿透、击穿、雪崩等经典问题。这些知识有很强的“背诵色彩”但深挖下去又要求你理解底层数据结构。第四层场景化智力题和开放题。这种题没有标准答案但恰恰是拉分最大的。比如“线上服务突然打不开你怎么处理”“如何设计一套监控告警系统”等。这类题考察的是你的全局观、沟通能力和故障应对的成熟度。从岗位匹配的角度来看这套题对应的是**业务运维SRE方向**的核心技能树而不是纯平台开发运维。所以你刷题的时候也要有侧重别把大量时间花在特别冷门的工具参数上。2. Linux部分从命令记忆到原理理解的跨越2.1 高频命令的“隐藏考点”笔试题里出Linux命令题是最不起眼却最阴险的。表面上考的是输出结果实际上考的是你是否理解这条命令背后的数据来源和核心机制。以free为例。很多新手只知道free -m能看内存但如果问“free命令里的available和free有什么区别buffer和cache分别缓存了什么”不少人会卡壳。在Linux内核中free表示完全未被使用的物理内存而available则是“估计可用的内存”它是根据当前内存水位线计算出的、在不触发交换swap的情况下还可以分配给应用程序的内存大小。对于运维笔试而言这两者的区别是必背的因为线上排查内存问题时available才是更有参考价值的指标。再比如top命令输出里的load average。这个值很多人只会看“高不高”但笔试会考你load average为1.0是不是代表系统满负荷答案是否定的。在Linux中load average是运行队列中可运行线程和不可中断睡眠线程的平均数它需要除以CPU核心数才具有实际的参考意义。如果你在笔试中答出“4核机器load average为4.0才算满载”这一层就能明显拉开和其他候选人的差距。2.2 文本处理三板斧grep、sed、awk的实战用法笔试中不会直接让你写出“用sed把某文件的第3行到第5行删除”这么简单的问题而是会给你一段日志让你提炼出某个维度的信息。比如“统计nginx访问日志中状态码为502的请求占比并列出TOP10的请求IP”。说实话这种题在笔试里不许查资料、不许上网搜拼的完全是平时的肌肉记忆。我建议在平时练习时就固定一套自己的“万能句式”。以统计502状态码为例我的固定套路是# 先看总量 grep -c 502 access.log # 再看IP分布 grep 502 access.log | awk {print $1} | sort | uniq -c | sort -rn | head -10很多人会问为什么不直接用awk一步完成因为笔试和面试现场你不仅要写出命令还要解释每一步的意图。分步写的好处是逻辑清晰、可读性强阅卷人一眼就能看出你的思路。更重要的是sort | uniq -c | sort -rn这个组合拳在几乎所有日志分析场景都通用你可以像背乘法口诀一样把它刻在脑子里。唯一要提醒的是日志文件的字段分隔可能不是空格而是制表符这时候awk -F\t就派上用场了。笔试中如果有类似的题先看清楚日志格式再动笔别默认字段分隔符一定是空格。2.3 系统启动流程与服务管理爱奇艺这类大厂的服务器大多基于CentOS或Ubuntu但笔试里很少直接考“systemd和SysV init的具体区别”这种纯记忆题。相反他们更喜欢考启动流程中故障定位的逻辑。比如这道经典变形题“服务器重启后nginx无法启动可能的原因有哪些如何排查”如果你按照“应用层→日志层→系统层”的思路来答就能拿到大部分分数先看nginx的配置文件语法是否正确nginx -t看端口是否被占用ss -lntp | grep 80看启动日志journalctl -u nginx看系统是否开启了SELinux或防火墙拦截getenforce、iptables -L这个递进逻辑非常重要。很多候选人在笔试中直接答“重启nginx”这就等于没有排查过程。真正的生产环境里systemctl restart nginx往往会把问题掩盖掉下次复现又得重来一遍。你只有通过日志和状态确认了根因重启才有意义。3. 网络篇TCP协议和故障排查的核心战场3.1 三次握手和四次挥手绝不只是“画流程图”网络基础题几乎是运维笔试的必考题。最常见的问法是“描述TCP三次握手的过程”。但如果你是照着教科书画一个客户端、服务端的箭头图就完事基本只能拿到基础分。要拿到高分你需要在这个基础上补充三个关键信息第一为什么要三次而不是两次。因为TCP是双工通信三次握手能够确认双方的收发能力都正常。客户端发出SYN服务端确认了客户端的发送能力服务端回复SYNACK客户端确认了服务端的发送和接收能力客户端再回ACK服务端确认了客户端的接收能力。只有经过这三轮双方才能确认彼此的收发信道都是畅通的。第二握手过程中可能出现的异常和队列认知。比如服务端收到大量SYN但未完成握手时连接会停留在SYN_RECV状态受限于半连接队列tcp_max_syn_backlog。而全连接队列accept队列满了之后会出现客户端握手成功但服务端应用accept不到连接的情况。笔试中如果问“为什么客户端显示连接建立但服务端应用没反应”很大程度上就是在考察这两个队列的理解。第三TIME_WAIT的意义。四次挥手后主动关闭方会进入TIME_WAIT状态持续2MSL。这个状态是监控和性能优化中永远绕不开的话题。大量TIME_WAIT连接通常是短连接服务比如高并发的nginx的典型特征增加端口复用、调整net.ipv4.tcp_tw_reuse可以缓解但不能盲目修改否则可能导致旧连接的数据包串扰到新连接中。3.2 网络排查工具链从ping到tcpdump的层层递进笔试中关于网络排查的工具题通常以“用户反馈某个页面打开很慢你如何排查网络层面问题”的形式出现。很多人的第一反应是ping。没错ping确实是最快的连通性测试手段但它的局限性也很大ICMP不通不代表TCP不通因为很多云厂商的安全组策略会丢弃ICMP包但业务端口是正常的。一个合格的排查链路应该是这样的# 第一步确认本机到目标是否通 ping -c 3 目标IP # 第二步确认路由路径和链路质量看哪一跳延迟异常 traceroute -n -T -p 80 目标IP # 第三步确认目标端口是否开放 telnet 目标IP 80 # 第四步抓包看协议栈行为 tcpdump -i eth0 host 目标IP and tcp port 80 -nn -c 100这套链路里的细节值得展开。traceroute默认使用UDP但很多网络设备对UDP不回应所以推荐加上-T参数TCP模式和-p 80更贴近真实业务。tcpdump抓包的话如果发现SYN包发出去了但对端一直没有SYNACK回复基本可以断定是服务端丢包或者防火墙拦截如果SYN重传了多次才收到响应就要考虑链路丢包或者服务端backlog队列满的问题。笔试中的网络排查题不会要求你输出完整的抓包分析但你要在文字里体现出“我知道抓包数据怎么看、SYN重传意味着什么”这样阅卷人就会认定你是真正踩过坑的人而不是只会背命令的应试者。3.3 nginx高频场景反向代理、负载均衡和连接超时nginx是互联网运维笔试中绝对不会缺席的角色。这部分考点高度集中在反向代理配置、负载均衡算法以及连接超时参数的理解上。最简单也最常见的题是“写出nginx反向代理的配置片段”。这里最稳妥的答案就是最经典的写法upstream backend { server 10.0.0.1:8080 weight3; server 10.0.0.2:8080 weight1; } server { listen 80; server_name www.example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }但笔试往往不会只让你写配置还会追问“weight参数的作用是什么”“默认负载均衡算法是什么”。你要能答出weight是权重分配默认是加权轮询round-robin并且能说出ip_hash、least_conn等算法的适用场景。比如ip_hash适合需要会话保持的无状态业务后端但它会导致负载不均衡所以现在更推荐用一致性哈希或使用Redis集中存储session来彻底解耦。超时参数也经常被挖坑。proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout三者的区别要分清连接超时是向后端发起连接的最大等待时间读超时是两次读操作之间的最大间隔写超时是两次写操作之间的最大间隔。有一个经典的坑是用户反馈上传大文件失败排查半天发现是proxy_read_timeout设置得太短导致nginx在等待后端响应时提前断开了连接。这种案例特别适合在笔试题的场景题里出现答的时候一定要体现“先查nginx错误日志再结合业务特点调整超时参数”的完整思路。4. 数据库与缓存中间件层面的经典大题4.1 MySQL索引和慢查询不会答就别想进大厂MySQL相关的题目在运维笔试中占据的权重非常高。大到爱奇艺、小到几十人的创业公司只要是互联网业务数据库一定是核心依赖。笔试题里最常见的就是索引和慢查询优化。索引部分必考的是“什么情况下索引会失效”。这个知识点需要你从B树的结构来理解复合索引遵循最左前缀原则如果查询条件里没用到最左列索引就派不上用场对索引列进行函数运算、隐式类型转换也会导致索引失效。比如WHERE age 1 30和WHERE phone 13800138000phone字段是varchar但查询条件是数字都是典型的索引失效场景。慢查询优化的问题通常会结合EXPLAIN来考。笔试时如果给出了EXPLAIN的输出结果你要能识别出type字段的值。从好到差依次是system const eq_ref ref range index ALL。看到ALL意味着全表扫描基本可以确定这条SQL需要优化。优化方向无非三个加索引、改写SQL、分库分表或引入缓存。但你要在答案中补充一点——加索引不是万能的。对于大表的写入性能索引过多会拖慢写入因此上线新的索引前最好在测试环境用真实数据量模拟压测。4.2 MySQL主从复制延迟线上经典事故的温床主从复制延迟是互联网公司的老生常谈也是笔试场景题的高频素材。题目一般会这样出“某天业务反馈刚写入的数据读不到排查发现主从延迟数秒你会如何处理”一个完整的答案至少要包含三部分影响分析先确认延迟的具体时间差和涉及的表评估对业务的影响范围。如果是非关键业务可以稍后处理如果影响核心交易链需要立即干预。原因排查主从延迟常见的原因是主库有大事务比如一次性DELETE大量数据、从库硬件性能不足、主从之间网络带宽瓶颈、从库上同时跑着分析型查询导致CPU争抢。SHOW SLAVE STATUS\G里的Seconds_Behind_Master只能作为参考更准确的是对比主库和从库上某个binlog的位置差。应急措施如果延迟影响严重可以将读流量临时切换到主库但这对主库压力很大不是长久之计或者把从库的定时任务暂停、杀掉长时间运行的慢查询给同步线程腾出资源。这里有一个非常容易被忽视的细节并行复制。MySQL 5.7之后的版本支持基于库级别的并行复制5.7.22以后支持基于组提交的并行复制MTS。在笔试答案里写下“检查从库是否开启了slave_parallel_workers调大并行复制线程数”会瞬间显得你很有实战经验。4.3 Redis缓存穿透、击穿、雪崩考的不是定义是应对方案缓存三兄弟穿透、击穿、雪崩是中间件运维的“政治题”几乎每家公司的笔试题里都会出现。你光知道定义是不行的题目一定会问你“如何解决”。缓存穿透是指查询一个根本不存在的数据缓存和数据库都没有导致每次请求都打到数据库。解决方案有两个方向一个是缓存空值给不存在的key也设置一个短TTL的空缓存另一个是布隆过滤器在请求进入缓存之前就过滤掉非法的key。缓存击穿是指某个热点key在过期的一瞬间大量请求同时涌入数据库。解决办法是热点数据不设置过期时间或者用互斥锁只允许一个线程去查数据库并回填缓存。缓存雪崩是指大量key在同一时间过期或者Redis宕机导致流量瞬间打到数据库。对策包括给key的过期时间加随机值避免同一时刻集体失效、Redis高可用部署哨兵或集群模式、以及做多级缓存本地缓存 Redis。在笔试题里如果你能针对每个问题举一个亲身经历或合理的业务场景样例比如秒杀时某个商品的库存key恰好过期导致数据库被打爆答案的含金量立刻就能上一个台阶。因为面试官从答案里能看到你不仅背了八股还真正思考过业务。5. 场景题与开放题的作答方法论5.1 “服务突然不可用”的排查框架从现象到根因开放场景题在整份笔试题B中是最能体现功力的一环。典型题目是“某个核心服务突然不可用用户大量投诉你应该按什么顺序排查”这类题没有标准答案但有一个公认的高质量作答框架。我的建议是先定界、后定位、再恢复。定界确认是单机问题还是集群问题是所有用户都不可用还是部分用户不可用。这决定了排查的方向。如果只是部分用户不可用优先怀疑网络链路和地域性调度问题如果是全量不可用大概率是服务本身挂了或者依赖的下游数据库、Redis、下游API出了问题。定位按照“网络 → 系统资源 → 应用日志 → 依赖组件”的顺序逐层排查。先看监控大盘确认CPU、内存、磁盘、网络有没有被打满再看应用自身的日志有没有大量报错最后看它依赖的MySQL、Redis等中间件是否健康。这个顺序是经过实际事故验证的——大多数时候问题并不在应用代码本身而在应用之下的资源层或依赖层。恢复先恢复业务再讨论根因。不要在意“优雅”和“完美”如果重启可以快速恢复就立即重启如果流量切换能解决问题就立即切换。很多笔试作答者会忽略这一点花大量篇幅讲怎么优雅地定位问题却忘了运维的第一原则是止损。5.2 监控告警体系设计题别漏掉“处理闭环”如果笔试中出现“你如何为一个新业务设计监控体系”的开放题多数人会罗列一堆监控项CPU、内存、磁盘、流量、接口响应时间、错误率……这些都没错但都不完整。一份高分答案一定要包含完整的处理闭环数据采集定义需要监控的指标来源。系统层指标用node_exporter或Agent采集应用层指标通过埋点暴露业务层指标从日志中解析。告警规则告警不是越灵敏越好。把阈值设置为合理值比如CPU使用率超过85%持续5分钟才告警配合持续时间来消除抖动噪声。通知分级P1级别核心服务宕机要电话和短信同时触达P2级别磁盘使用率高可以只发邮件或IM消息。不要把所有告警都设置为同一级别否则大家会逐渐对告警麻木。处理与复盘每一次告警触发后要有处理记录和归档。笔试里如果能主动提到“告警处理后要写复盘报告持续改进告警阈值和应急手册”会与那些只会罗列指标的候选人形成鲜明对比。6. 备考与答题的实战心得如何把笔试变成加分项6.1 时间分配别让“简单题”吞掉你的“争分题”运维笔试通常是60到90分钟题量在30到50道之间。我的建议是拿到卷子先花1分钟快速浏览所有题目把题目分为三类送分题基础命令、概念定义快速作答控制在每题30秒以内。核心题网络流程、MySQL优化、场景排查分配较多时间因为这些题分值高、区分度大。陌生题没见过的冷门工具、新概念不要死磕。先跳过把会做的题目稳定拿分后再回头处理。很多人在笔试中最大的问题不是不会做而是在一道不确定的题目上反复纠结最后导致后面的场景题没时间展开写。请记住开放题只要你写了就能拿到过程分空着不写一定零分。6.2 答题语言用“关键词 简短解释”代替长篇大论笔试阅卷一般看关键词给分而不是看你写了多少字。答简答题时我建议采用“结论先行 分点展开 关键命令或参数佐证”的格式。比如问“如何排查CPU飙升问题”千万不要上来写一大段背景而是直接写先用top -Hp定位到CPU占用较高的线程ID再用printf %x\n将线程ID转成16进制然后用jstackJava应用或perf非Java应用聚焦到这个线程的栈信息定位具体的函数和代码逻辑如果是Java应用还可以结合JMC或async-profiler做火焰图分析。这种答案的特点就是每条都有具体的命令或工具支撑阅卷人一看就知道你干过活。相比“使用系统工具查看CPU占用高的进程”这种模糊表述得分力度可以说是天壤之别。6.3 考后复盘比刷题更重要的是建立自己的排查手册笔试结束并不是学习的终点。每一次笔试中暴露出的知识盲区都值得你记录到自己的“排查手册”里。我自己当年准备运维岗位时做了一个按主题分类的Markdown笔记包括“Linux排查命令速查”“TCP状态机与异常排查”“MySQL问题诊断清单”“Redis故障场景与防护措施”等。后来我做了面试官发现能进终面的候选人通常都有两个共同点一是对常用的故障排查命令了然于胸能够脱口而出二是对“为什么会这样”有深入理解而不是停留在“我执行了某个命令、看到了某个输出”的层面。运维这个岗位最看重的是面对未知问题时的冷静拆解能力这种能力没办法靠临阵磨枪只能通过一次次实际排查和复盘慢慢积累。回到爱奇艺2019秋招运维方向笔试题B这份卷子它的题目难度其实并不极端但覆盖了运维工程师日常工作中最常踩坑的那些点。你如果能把Linux系统原理、TCPIP协议相关机制、MySQL和Redis的运维要点、以及通用的故障排查方法论都梳理清楚无论面对哪年哪家的运维笔试题都能游刃有余。最后再分享一个我踩过多次坑之后总结出来的经验笔试中如果遇到完全不会的场景题千万别交白卷。你可以写下一个最基础的排查动作比如“首先查看系统负载和监控面板”下一步再“根据监控数据缩小范围”。即便最终没有定位到根因你展现出的思路本身就是得分点。运维笔试从来不要求你成为百科全书它只希望看到一个“出了问题能顶上去、能一步一步找到问题源头”的人。