金九银十的招聘季又到了，后台不少准备投运维岗位的朋友都在翻老题。我注意到“爱奇艺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_DAYS=7 # 计算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不远了。
