金九银十的招聘季又到了后台不少准备投运维岗位的朋友都在翻老题。我注意到“爱奇艺2019秋招运维方向笔试题B”这份材料最近又被翻了出来评论区讨论得很热闹。作为经历过多个视频、直播类公司运维面试的老兵我可以负责任地说这份试卷虽然已经过去几年但它的考点结构和考察思路放到今天依然是互联网运维笔试的“标准模板”。它不考偏题怪题考的就是你日常维护、故障排查、脚本落地这些基本功。这篇文章我结合当年参加考试的同学回忆、网上流传的考点整理以及我自己带人和面试时的出题经验把这份B卷背后真正想考察的东西拆开讲透。不管你是应届生、转行运维的还是干了两年想跳槽的都能从中找到复习方向。1. 整体考察思路与题型结构爱奇艺B卷在筛什么样的人1.1 先从试卷结构反推公司诉求一份笔试题的设计往往比面试更能看出团队的真实诉求。爱奇艺2019秋招运维方向笔试题B整体呈现出“基础题占比大、场景题少而精、码代码不能怂”的特点。题型基本围绕这几类展开选择题和填空题主要扫射Linux命令、网络协议、数据库基础简答题集中考察你对某个服务或某个故障场景的理解深度最后的编程题和场景设计题则专门用来刷掉那些只会背命令、不会解决实际问题的人。这种结构传递的信号非常明确校招运维候选人公司并不指望你一来就能扛起线上大梁但你必须证明自己有扎实的底层功底以及遇到问题时具备独立排查的潜力。视频公司的运维环境尤其复杂从用户端到播放端中间隔着DNS、CDN、源站、转码集群、存储集群每一条链路都不能掉链子。所以你会发现试卷里很多题目表面上在问Linux实际上在考察你对整个业务链路有没有感知。1.2 为什么这份试卷现在还有参考价值有人会问2019年的题现在容器化、云原生都这么普及了还有必要看吗我的答案是看考点而不是看具体题目。运维工程师的底子是没什么变的Linux系统管理、网络排障、Shell脚本、数据库和缓存的使用边界这些在任何时代都是运维吃饭的家伙。比如试卷里考到iptables规则、TCP状态排查、磁盘inode耗尽这类问题今天依然会原封不动地出现在各大公司的笔试题里。云原生带来的变化在于工具链和架构模式但底层排障逻辑没有变。你排查一个Kubernetes里Pod启动失败最后往往还是落到镜像拉取、磁盘空间、网络CNI插件这些老朋友身上。所以把这份老题吃透再叠加上容器和云原生知识去应对现在的中大型互联网公司运维笔试基本就够用了。我建议复习时把它当成一份“知识地图”而不是背答案的题库。2. 核心考点拆解Linux、网络、脚本三板斧2.1 Linux基础不是背命令而是理解系统运转爱奇艺B卷的Linux题目大概率会围绕文件管理、权限、进程、磁盘、系统性能这几个方向出。很多候选人在准备时喜欢刷“Linux常用命令大全”把参数背得滚瓜烂熟一看到实际场景就慌了。最典型的例子就是排查磁盘空间很多人只会df -h看到磁盘使用率100%却不知道用du从根目录开始逐层定位大文件更不知道还要检查inode是不是也满了。试卷里只要把故障场景一包装这类“半吊子”就直接现形。我建议复习Linux时不要停留在命令记忆要把每个命令背后对应的系统机制搞清楚。比如权限不光要会chmod 755还要理解为什么有些场景下必须用chown而不是chmod改权限。比如进程不光会ps -ef还要知道zombie进程是怎么产生的为什么不能被kill -9杀掉需要让父进程去回收它。再比如systemd很多公司已经不用SysV init了你要能看懂unit文件知道服务启动失败时用journalctl -u看日志而不是去翻/var/log/messages大海捞针。2.2 网络知识从三次握手到异常状态判断网络是运维笔试的重灾区也是爱奇艺这类视频公司特别看重的能力。面试官很清楚视频业务对网络的依赖极其敏感用户看视频卡顿很多时候不是服务器性能问题而是网络链路的问题。B卷里的网络题目基本是两个方向一是基础协议原理比如TCP三次握手和四次挥手的状态变化HTTP和HTTPS的区别DNS解析过程二是实际排障比如给你一个服务端口不通的场景让你写出排查步骤。这里我特别想提醒一个高频考点TIME_WAIT。你搞视频上传或下载服务会看到大量连接处于TIME_WAIT状态这时候该怎么处理很多人第一反应是调内核参数把tcp_tw_reuse和tcp_tw_recycle打开。这其实是个大坑tcp_tw_recycle在NAT环境下会引发严重问题可能导致用户无法访问服务。正确的做法是结合业务判断短连接过多造成的TIME_WAIT优先考虑让客户端复用连接或者通过调整keepalive参数来缓解而不是盲目改内核。这种题没有标准答案考的就是你踩过多少坑。2.3 Shell脚本与Python把运维工作工程化爱奇艺B卷基本都会有编程题常见的是Shell脚本或Python脚本考察日志分析、文本处理、批量操作这些运维日常。很多自学运维的朋友对“会写脚本”这件事有误解以为会写for循环批量ping IP就算会了。其实面试官想考察的点很明确能不能用脚本处理真实场景比如统计Nginx日志里Top 10的访问IP找出某个时间段内错误率最高的接口写一个日志按天切割的cron脚本。我见过最可惜的失分情况是思路完全正确但脚本语法细节一塌糊涂。比如在shell脚本里用了一个没有初始化的变量或者在awk里忘记处理分隔符导致结果对不上。笔试没法现场调试所以平时练脚本一定要养成好习惯每个变量都随手加双引号、管道命令的每个环节都要确认输出格式、关键步骤用set -x打印执行过程、脚本开头加set -e防止错误继续执行。这些细节不会让你写出更“华丽”的代码但能让你在笔试那种紧张环境里少犯低级错误。3. 视频公司运维的特色考点CDN、存储和缓存3.1 从用户播放卡顿反推CDN调度逻辑爱奇艺是视频公司它的运维笔试题一定绕不开业务特色。B卷里最值得琢磨的是那些“视频播放变慢”“上传转码失败”之类的场景题。这背后牵涉到整套视频分发链路从用户发起请求到DNS解析调度到最近的CDN节点再到CDN节点回源站拉取内容最后通过流媒体协议推给播放器任何一个环节抖动用户体感都是转圈或卡顿。这类题考察的不是你能背出多少命令而是你有没有建立全链路视角。比如播放首帧时间变长你要能列出可能的原因本地DNS解析慢、CDN节点命中率低、源站带宽被打满、视频转码后封装格式不兼容。然后针对每种原因给出对应的排查方法。面试官并不期待你在笔试里真的把问题定位出来而是想看你能不能有条理地把问题拆开给出一个可执行的排查顺序。这里有个小技巧回答时按“链路顺序”走从用户端逐步到服务端会显得逻辑特别清晰。3.2 MySQL和Redis缓存的边界与一致性虽然笔试不会让你写特别复杂的SQL但对MySQL主从复制、慢查询、索引失效这些概念的考察一定会有。爱奇艺B卷在这块的出题风格更偏向“你知道什么情况下该用缓存什么情况下不该用”。视频App里用户点赞数、评论数这种读多写少的场景用Redis扛热点是常规操作但你要能说清楚缓存和数据库的一致性怎么保证。缓存穿透、缓存击穿、缓存雪崩这三个概念几乎年年考关键是要分清它们和对应策略。我建议准备这个模块时不要只背Redis的八股文要想想在视频业务里这些问题的具体表现。比如某个热门剧集上线瞬间几百万用户同时请求同一个视频详情页如果缓存里没有这条数据请求直接打到MySQL就是典型的缓存击穿。这时候用互斥锁或者提前把热点数据预热到缓存才是合格的答案。能把基础概念和业务场景结合起来讲比单纯背定义得分高得多。3.3 从“服务活着”到“用户体验正常”监控告警设计B卷还会出现一类开放题让你设计某个服务或某个集群的监控方案。这类题没有标准答案但可以体现出你对监控体系的理解是否完整。初级候选人会回答监控CPU、内存、磁盘、网络有问题就告警。这个回答只能拿基础分。稍微有经验的候选人会补充告警要有分级核心业务告警通过电话一般告警通过企业微信同时要配告警阈值和收敛策略。但我想强调的更高一层是想清楚监控的终极目标是保障用户体验而不仅仅是保证进程不挂。以视频场景为例你不仅要监控服务器的CPU和内存还要关注卡顿率、首帧时长、CDN命中率、转码队列长度这些业务指标。服务器CPU高不一定影响用户但如果卡顿率明显上升就算CPU不高也必须立刻介入。2019年这套题出现的时候很多人的监控思维还停留在“主机层面”能把业务指标纳入监控体系的人在试卷里会显得特别突出。现在AIOps概念普及了这个思路就更加必不可少。4. 实操演练一套覆盖B卷风格的模拟题与解题思路4.1 场景题磁盘使用率告警5分钟内你要做什么这道题几乎可以作为运维笔试的“代表作”因为它足够基础又特别能拉开差距。题目大概是你收到一条磁盘告警/data分区使用率达到95%简单描述你的排查步骤。我看到过很多答案只写“删除日志”这完全不是面试官想要的。正常的思路应该是先用df -h确认是不是真的满了有时候是文件误报或者挂载异常。用df -i检查inode使用率排除inode耗尽场景。用du -sh /data/*从一级目录开始逐层找定位到具体是哪个目录占空间最大。确认占用后判断文件类型是日志文件、临时文件、还是用户上传的视频碎片文件。针对不同类型采取不同动作日志可以切割压缩或清理临时文件可以直接删除但如果是业务数据需要联系对应负责人确认后再处理。这里要特别注意所有删除操作必须先确认业务影响。常见的翻车操作是一上来就rm -rf大文件结果那是数据库的binlog或者是一个还在被进程写入的日志文件删掉之后磁盘空间根本没释放反而把服务搞挂了。正确的做法是先用lsof查看该文件是否被进程打开如果是需要先确认是否有备份、业务是否可以接受丢失日志再决定怎么清理。在笔试里把这种谨慎的思维方式写出来比直接写“删日志”要专业一个档次。4.2 场景题用户反馈视频上传变慢按什么顺序排查这道题是我认为爱奇艺B卷里最有含金量的一道。上传慢不是一个孤立问题它涉及用户端、网络链路、服务端接收、存储写入等很多环节。我建议的排查顺序是第一先确认影响面。是单个用户反馈还是大面积反馈是某个地区集中出现还是全国都有如果是地域性问题大概率是网络链路或运营商互联互通问题如果是全局性问题可能出在服务端。这一步非常关键能帮你快速缩小排查范围。第二检查服务端容量。看上传网关的负载、带宽使用率、存储集群的写入延迟。视频文件都很大上传过程中如果存储写入跟不上就会表现为“上传卡住”或“速度越来越慢”。第三检查链路和调度。看用户被分配到了哪个接入点是否存在跨地域调度问题。比如用户在华东却被调度到了华北节点写入延迟自然会高。第四基于以上信息再决定是否需要看客户端日志或抓包。很多候选人一上来就层层traceroute去分析网络丢包这样不是不可以但在笔试里会显得主次不分没有全局意识。按影响面、服务端、链路、客户端的顺序来写答案会让面试官觉得你具备大型互联网公司运维需要的大局观。4.3 编程题写一个日志清理脚本笔试编程题最常见的场景就是写日志清理。题目描述一般是某个服务每天产生大量日志存放在/data/logs/目录下子目录按日期命名如2024-01-01请写一个Shell脚本删除7天前的日志目录并输出被清理的目录列表。这道题看似简单但能筛掉很多眼高手低的候选人。基础版本的答案无非是date命令计算日期加上find和rm。但想要拿高分必须考虑几个生产环境里的现实问题脚本的容错性目录不存在时怎么办时间计算失败时是否要终止脚本安全性find出来的路径如果包含空格或特殊字符for循环会出错最好用while read处理。执行效率如果日志目录特别多直接用rm -rf每个目录会慢可以先拼接好路径再批量处理。可维护性保留天数、日志根目录这些参数要变量化方便以后修改。我给一个生产可用的简单版本作为参考#!/bin/bash # 日志清理脚本保留最近7天日志 LOG_ROOT/data/logs KEEP_DAYS7 # 计算7天前的日期格式为YYYY-MM-DD CUTOFF_DATE$(date -d -${KEEP_DAYS} days %F) # 安全判断如果日期计算失败直接退出 if [ -z $CUTOFF_DATE ]; then echo Error: date calculation failed exit 1 fi cd $LOG_ROOT || { echo Error: cannot access $LOG_ROOT; exit 1; } # 遍历日期格式的目录删除早于保留时间的目录 find $LOG_ROOT -maxdepth 1 -type d -name ????-??-?? | while read dir; do dir_date$(basename $dir) # 字符串比较早于保留日期的目录需要清理 if [[ $dir_date $CUTOFF_DATE ]]; then echo Deleting: $dir rm -rf $dir fi done这个脚本里用date -d精确计算截止日期而不是用mtime判断是因为日志目录名就是日期直接按名字比较更加直观和准确。同时在删除前打印一条日志方便事后审计。这样的脚本拿到笔试里比“无脑find -mtime 7 -exec rm -rf”要严谨得多因为它能应对各种异常路径。5. 常见问题与备考避坑笔试里最容易被扣分的地方5.1 四个高频失分点看看你中没中招我在面试中见过太多候选人栽在同一个坑里这里集中整理一下。第一个失分点是答非所问题目明确问“排查思路”结果你上来就写配置命令把系统优化参数列了一大堆。笔试批卷人看的是逻辑框架不是看你会几条命令所以答题前一定要先判断题型是“原理问答题”还是“场景操作题”。第二个失分点是只写结论不写依据。比如问到MySQL主从延迟怎么办很多人直接写“换半同步复制”或者“优化SQL”这确实是对的但你没解释为什么。正确的答题结构应该是先说主从延迟的常见原因比如中大事务执行时间过长、备库单线程并行复制能力不足、主库写入压力过大再针对原因给出对应方案。有因果链的答案才显得有思考深度。第三个失分点是忽略边界条件。写脚本时不考虑路径不存在、文件被占用、权限不足讲方案时不考虑回滚和备份。运维最讲究的就是“稳”你设计的操作如果没有任何保护措施在面试官眼里就是“上线必出事故”的类型。我在实际评审时只要看到没有备份和回滚意识这道题最高只能给及格分。第四个失分点是对新技术的理解浮于表面。这几年很多候选人在简历里写熟悉Docker和Kubernetes笔试题目一来就漏洞百出。比如问容器网络模式只会说bridge和host说不出CNI的作用问Pod调度原理只知道“调度器把Pod放到Node上”说不清亲和性、污点、容忍度的实际应用。这部分知识不是笔试核心但如果你写了面试官就有理由深挖所以没搞清楚的技术栈宁可不写在简历上。5.2 一份可执行的复习路线从基础到业务如果你想认真准备运维笔试我给出的建议是分三轮走。第一轮用两周时间打基础主攻Linux、网络、Shell每天保持至少一小时命令行实操。不能只背书要在虚拟机或云服务器上把每个命令跑一遍尤其要把tar、grep、awk、sed、find、lsof、ss这些高频命令练熟。这门功课没有捷径敲得越多笔试的时候越从容。第二轮用一周时间攻数据库和缓存把MySQL主从复制原理、索引失效场景、Redis持久化机制、缓存穿透和雪崩这几个核心问题彻底搞懂。复习的时候不要看一篇博客就划过去要自己动手搭建一个主从环境手动制造一次主从延迟看看实际效果。这套环境以后面试也能用。第三轮就是刷题和讲题。把网上能找到的运维笔试真题过一遍重点是场景题和编程题。看完之后不要只对着答案看要关掉屏幕自己复述一遍用笔写下排查思路。我认为最好的复习方式就是“假装你在给一个实习生讲题”能把它讲清楚说明你真的懂了。临考前再把简历里提到的每个技术点过一遍确保每一个词都能经得起追问。写在最后每年秋招运维岗位的竞争都比大家想象中激烈但真正有准备的人其实不多。很多人刷题只记答案不去想题目背后的业务逻辑结果笔试过了面试一问细节就崩。爱奇艺2019秋招运维方向笔试题B是一面很好的镜子它能帮你看清自己到底是在“背考点”还是在“建体系”。我个人带人的经验是运维这个岗位越往后走拼的越是解决问题的方法论和面对故障时的那份冷静。而这些恰恰是从认真准备一场笔试开始的。不要只盯着题海多问问自己如果这个问题真的出现在生产环境我敢不敢按下确认键想清楚这一点你可能就离一份满意的Offer不远了。