爱奇艺2019秋招运维方向笔试题B这套题放到今天看坑不深但范围很宽。当时考完不少人吐槽知识点太杂但等我工作几年再回头看会发现出题人其实很克制几乎没有死记硬背的名词解释选择题也大多落在看到某个现象选择最合理的定位手段这种思路层面。作为经历过那个时期秋招的运维工程师我把这套卷子的考察方向、高频考点和答题思路完整拆了一遍给准备运维岗面试的朋友做个参考。这份复盘不只针对爱奇艺一家。视频类公司的运维笔试通常围绕内容分发链路展开但底层的Linux、网络、脚本、容器能力是所有互联网公司通用的。把这套题吃透再去面其他公司你会发现考来考去就是这些东西。1. 试卷整体印象这场笔试真正在筛什么人1.1 从A/B卷的设置看筛选逻辑爱奇艺2019秋招笔试分A/B卷这在当年的校招里是常规操作。A/B卷的核心目的是两个一是防止同考场前后排互相借鉴二是支撑多批次、多场次的统一考试安排。实际题目难度不会因为A卷或B卷有本质差异只是题序打乱、部分选择题选项顺序调整、个别题目替换成同考点另一道变体而已。所以不要纠结我抽到B卷是不是更难筛选标准是等价的。但运维方向这份试卷和常规技术卷有明显区别。纯选择题占比不高简答题、场景题、脚本题占了相当比例。原因很直接运维岗位判断一个人能不能干活靠选择题是看不出来的。你能背出netstat -an的输出格式不代表你会排查连接数暴涨能默写Dockerfile关键字不代表你能把一个镜像从3GB降到300MB。所以出题人会用开放题看你的排查思路用脚本题看你的代码习惯用场景题看你有没有基本的服务意识。这种卷子的通过率通常不高我当时身边一批投运维岗的同学能过笔试进入面试的大概只有三到四成。卡人的主要不是那些硬核知识点而是很多人面对场景题时只会写重启服务看看日志这种一句话答案完全没有分层排查的概念。1.2 五类核心考点与考察占比从整套卷子来看考点主要落在五个方向模块大致占比考察重点Linux与Shell脚本30%常用命令、文件系统、进程管理、文本处理网络与HTTP25%TCP状态、HTTP协议、DNS、CDN基础Python/脚本编程20%文本处理、系统巡检、批处理能力容器与持续交付15%Docker、Kubernetes基础概念、发布策略场景排查与设计题10%故障处理思路、系统设计逻辑这个占比分布是有道理的。Linux和网络是运维吃饭的本事占比最高Python和脚本是会不会自动化的分水岭容器是2019年已经开始成为标配的技术方向场景题则是用来观察候选人思维方式。如果你现在准备笔试可以按这个比例分配复习精力不要花太多时间在冷门参数上。2. Linux与Shell看似送分实则区分度最高2.1 文件系统、权限与进程管理的高频题Linux基础这块2019年考的和现在差别不大。文件系统、权限、进程这三块几乎是必出题范围但出题角度不是让你背定义而是让你在具体场景里做选择。硬链接和软链接的区别是经典送分题但很多人会丢分。硬链接和原文件共享同一个inode删除其中一个名字数据还在另一个名字依然能访问软链接是一个独立文件存的是目标路径原文件被删软链接就变成悬空链接。笔试里如果问日志文件用软链接还是硬链接做轮转答案就是用软链接因为ln -s 可以指向路径而硬链接跨文件系统做不了。进程管理方面僵尸进程和孤儿进程是高频考点。僵尸进程是子进程已经退出但父进程没有调用wait()回收它的退出状态码导致进程表中残留一条记录。这种进程kill不掉因为已经死了正确做法是处理父进程让父进程完成回收或者干脆结束父进程让init进程现在叫systemd接管回收。孤儿进程则是父进程先退出子进程被1号进程收养这个是正常现象不存在危害。我记得这套卷里还有一个关于SUID的题目ls -l看到某个文件权限是-rwsr-xr-x问这个s是什么意思。答案就是这个文件执行时会临时获得文件属主的权限典型例子是/usr/bin/passwd需要以root身份去写/etc/shadow。反过来说如果运维发现系统中一个普通文件有SUID权限那基本可以认定是安全隐患需要第一时间排查。2.2 文本处理三剑客与日志统计套路Shell文本处理是运维笔试的稳定出题点因为生产环境里大量问题要靠分析日志定位。爱奇艺这种视频平台每天产生的CDN日志、播放器日志、转码任务日志都是亿级别的你不可能用Excel打开只能靠命令行工具快速过滤统计。最常见的题目就是统计access.log中访问次数最多的前10个IP。标准解法awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这条命令链的每个环节都有考点awk提取第一列sort让相同IP相邻uniq -c按连续相同内容计数sort -rn按数字逆序head取前10。很多人会漏掉中间那个sort结果uniq -c统计出来全是1这题就白做了。还有人在排序时用sort -nr不需要但写成sort -n -r也行关键是要按数字排序而不是按字典序。更深一层的题是统计某个URL的PV/UV或者统计5xx状态码的占比。这类题目通常要grep和awk配合比如grep HTTP/1.1 5[0-9][0-9] access.log | wc -l或者用awk直接按状态码分段计awk {codesubstr($9,1,1); if(code2) a[2xx]; else if(code3) a[3xx]; else if(code4) a[4xx]; else if(code5) a[5xx]} END{for(k in a) print k, a[k]} access.log这套思路在笔试里反复出现本质是考你能不能把一个业务问题翻译成命令逻辑。平时多练几次形成条件反射比背什么命令大全有用得多。2.3 笔试里最容易丢分的Shell坑Shell脚本题是区分度很大的部分因为语法细节特别多坑也很密集。我印象中这套卷子里有一道改错题给了几行脚本让找出错误。常见坑基本就这几个第一变量赋值时写成了a 1。Shell里等号两边不能有空格a 1会被解释成执行命令a后面是参数和1直接报command not found。这个错误在笔试里出现的频率非常高。第二整数比较用了而不是-gt。if [ $a $b ]在单中括号里不是数值比较而是把$a $b当成重定向执行。正确写法是if [ $a -gt $b ]或者用双中括号if [[ $a $b ]]双中括号里支持字符。第三for循环的花括号展开问题。for i in {1..$n}这种写法不会按照预期展开因为花括号展开发生在变量替换之前你得到的可能是{1..5}这个字面量字符串。正确做法是用seq命令或者C风格for循环。第四管道里的子shell变量问题。echo test | read var之后外面再用echo $var是空的因为管道右边的命令在子shell里执行变量不会传到当前shell。这个笔试里也常考通常的解决方法是改用here-string需要bash或者直接在同一个子shell里消费变量。如果你能把这些坑都讲明白并且指出正确的替换写法这部分基本就是满分。面试官要的不是你会背语法而是你真在脚本里踩过这些坑知道为什么不能那么写。3. 网络与HTTP从TCP状态机到视频调度链路3.1 TCP状态机与TIME_WAIT的经典考法网络部分的题量在整套卷子里仅次于Linux而且普遍比Linux题深。TCP三次握手和四次挥手是必考但爱奇艺这类视频公司考得更具体经常和实际故障挂钩。TIME_WAIT是高频考点。为什么主动关闭连接的一方要进入TIME_WAIT并等待2MSL最大报文段生存时间原因有两个一是保证最后一个ACK能到达对端如果ACK丢失对端会重发FIN你还能再回一次ACK二是让旧的报文段在网络中自然消失避免它们干扰新连接。高并发场景下TIME_WAIT连接数过多会占用大量本地端口和内存你可能会看到ss -s统计里TIME_WAIT到几万甚至十几万。常见的优化手段是开启net.ipv4.tcp_tw_reuse让内核在发起新连接时可以复用TIME_WAIT状态的端口。但这里有个大坑net.ipv4.tcp_tw_recycle这个参数看起来像双胞胎实际上在NAT环境下会导致严重丢包因为它的原理是校验时间戳是否递增NAT后面多个设备共用同一个公网IP出口时时间戳完全不连续所有通过NAT上来的连接都会被动丢包。内核从4.12开始已经彻底移除了这个参数但2019年这套题考它的时候还有很多人不知道这个坑。CLOSE_WAIT也是常考状态。服务端收到对端FIN后进入了CLOSE_WAIT正常情况下服务端应该自己调用close()关闭连接但如果代码没释放连接就会卡在这个状态。笔试题经常给一个服务端存在大量CLOSE_WAIT的现象让你推断原因。答案大多是应用程序的连接池没配置超时回收或者代码里忘了close连接。3.2 视频场景下的HTTP状态码与CDN调度HTTP协议部分爱奇艺的题明显围绕内容分发展开。状态码是基本功但考的不是200代表什么这种送分题而是给你一个播放场景让你判断该看哪个状态码。视频播放链路里常见的状态码组合302用于播放地址的调度重定向用户拿到302后跳到离自己最近的CDN节点304用于缓存协商CDN和源站确认资源没有变更就直接用缓存不传文件体403多是防盗链校验失败502/503/504分别对应网关异常、服务过载、网关超时。CDN命中率是一个重要指标。如果命中率从95%掉到80%最直观的影响就是回源流量增加源站带宽压力大同时用户首帧时间可能变长。排查顺序一般是先看CDN控制台的命中率曲线确认是全局掉还是某个节点掉再看是否有新版本内容上线导致大量缓存过期这种情况属于正常波动最后看URL是否带随机参数如果播放器请求的URL带了时间戳或设备IDCDN会当成不同资源缓存命中率就会被拖垮。3.3 DNS解析流程与调度故障DNS在视频公司运维的笔试里很常见因为DNS决定了用户会被调度到哪个CDN节点直接影响播放体验。一道典型题目是用户在浏览器输入一个视频域名从输入到拿到播放地址中间DNS经过哪些步骤。答案要覆盖完整链路浏览器缓存 - 操作系统缓存 - hosts文件 - 本地DNS服务器LDNS- 根域名服务器 - 顶级域名服务器 - 权威域名服务器最后递归返回解析结果。TTL是另一个考点。TTL太短比如30秒DNS解析量会爆炸LDNS和权威服务器压力都大TTL太长比如24小时出故障时切换调度就特别慢用户可能一直访问故障节点。实际运维中二级域名一般设60到600秒之间低TTL只给需要快速切换的调度域名用。这部分最后通常还会让你写几个排查命令。dig trace看完整解析链路dig 8.8.8.8指定服务器解析nslookup -typecname查CNAME记录curl -vo /dev/null看HTTP响应头里的Server和X-Cache字段判断是否命中CDN缓存。这些命令笔试考到面试也会继续深挖。4. Python与自动化2019年运维笔试的分水岭4.1 从读代码到写脚本的题目变化2019年的运维笔试比前两年有一个明显变化Python题从阅读代码写出输出变成了写一段脚本实现某个功能。这个变化背后是运维开发趋势的加速。纯手工的运维模式已经不能满足大规模集群的需求自动化能力成为运维工程师的硬门槛。这套卷里Python题大概有三类。第一类是文本处理比如统计一个文本文件中出现频率最高的10个单词第二类是系统巡检比如检查磁盘使用率、内存使用率、进程存活状态第三类是批量操作比如遍历目录清理过期日志。三种题都不难但能写出来的人比例不高很多人在这部分直接交白卷。4.2 一个典型的磁盘巡检脚本拆解我印象比较深的一道题是写一个Python脚本遍历所有挂载点检查磁盘使用率超过80%的磁盘并输出告警。这道题有几种写法但最能看出代码功底的版本大概是这样的#!/usr/bin/env python3 import shutil threshold 80.0 def check_disk_usage(path): usage shutil.disk_usage(path) percent usage.used / usage.total * 100 return percent def main(): mounts [] with open(/proc/mounts) as f: for line in f: fields line.split() if len(fields) 2: continue mount_point fields[1] fs_type fields[2] # 跳过伪文件系统 if fs_type in (proc, sysfs, devtmpfs, tmpfs, cgroup, overlay): continue if mount_point not in mounts: mounts.append(mount_point) for mount_point in mounts: try: percent check_disk_usage(mount_point) if percent threshold: print(fALERT: {mount_point} usage {percent:.1f}%) except OSError as e: print(fWARN: cannot check {mount_point}: {e}) if __name__ __main__: main()这个脚本里有几个加分点用shutil.disk_usage而不是解析df命令的输出避免跨平台差异读取/proc/mounts而不是/etc/mtab因为前者更实时过滤掉伪文件系统避免tmpfs这些不影响磁盘容量的挂载点触发误报用try/except包住可能抛OSError的检查避免单个挂载点异常导致整个脚本崩溃。这些细节就是评分差异点。功能写完只是及格线能处理边界情况和异常才是运维开发要的代码。4.3 运维Python笔试的高分习惯结合这类题我总结几个拿高分的关键习惯第一文件操作一定要用with语句。很多人写f open(file)能跑但如果前面异常文件句柄就泄漏了。with open()能保证无论正常还是异常都关闭文件这是最基本的代码洁癖。第二处理大文件不要一次read。readlines()会把整个文件读进内存一个几GB的日志文件直接让机器卡死。正确做法是for line in f:逐行迭代或者用line.strip()按需处理。第三执行系统命令用subprocess.run()而不是os.system()。因为os.system()拿不到命令输出的内容subprocess.run()能捕获stdout/stderr还能设置超时。笔试里如果涉及调用外部命令这个差异很容易被加分。第四脚本入口写if __name__ __main__:。不写这行只能算简单脚本写了这行才具备模块化意识代码可以被import复用而不是一导入就执行一遍。这些习惯不需要你是不是科班出身练几次就能形成肌肉记忆。面试官看代码的时候第一眼扫的就是这些地方。5. 容器与Kubernetes从基本概念到运行时原理5.1 2019年容器相关题目的考察边界2019年秋招容器在运维笔试里已经不是加分项而是必考项了但考察深度和现在不一样。当时主要考的是Dockerfile、镜像分层、容器和镜像的区别、Cgroup和Namespace的作用、Kubernetes核心组件的关系基本属于概念题和应用题的结合。Cgroup和Namespace是高频概念题。Namespace负责隔离让容器里的进程只能看到自己命名空间内的进程、文件系统、网络栈Cgroup负责限制资源给容器配置CPU、内存的上限。爱奇艺这种视频平台一台物理机会切几十个容器跑转码服务或边缘缓存资源隔离和限制必须靠Cgroup兜底。Kubernetes部分常考的是Pod、Deployment、Service三者的关系。Pod是Kubernetes最小的调度单位一个Pod内可以有多个容器共享网络和存储Deployment负责声明期望状态和滚动更新Service提供稳定的访问入口后端Pod挂了也能通过标签选择器漂移流量。5.2 从Docker到containerdKubernetes调用运行时到底走哪条路这部分是这几年运维社区讨论热度很高的方向也是笔试和面试里越来越深的问题Kubernetes到底是怎么调起一个容器的我要把这个调用链讲清楚。最早的Kubernetes通过Docker API直接操作Docker Daemon来创建容器。但Kubernetes需要对接多种运行时不只是Docker于是Google牵头定义了CRIContainer Runtime Interface把运行时调用抽象成一套标准接口。Kubelet作为节点上的核心代理通过CRI接口和Runtime通信。Docker为了接入CRI在kubelet和Docker Daemon之间加了一个叫dockershim的中间层。这就是为什么你在Kubernetes节点上会看到一个名为kubelet的进程但它内部会调用一个shim再由shim去调Docker。与此同时containerd作为从Docker Daemon中剥离出来的纯容器生命周期管理组件直接实现了CRI接口省去了Docker Daemon和dockershim两层中间环节。今天的调用链是这样的kubelet - CRI插件containerd内置的CRI实现 - containerd - runc - 容器进程展开来说kubelet收到Pod创建请求后通过CRI接口向containerd发出CreateContainer请求containerd创建沙箱和容器配置然后调用runcrunc是一个命令行工具负责利用Linux内核的Namespace、Cgroup技术真正启动容器进程。runc最终调用的是操作系统的clone、execve等系统调用完成隔离环境的创建和进程的启动。这也是Kubernetes 1.24版本彻底移除dockershim之后containerd成为默认主流运行时的根本原因它更轻、更直接不需要经过Docker Daemon这个中间商。如果你能在笔试里把这个演化逻辑讲清楚分数一定高。5.3 滚动更新、资源限制与发布回滚容器部分的应用题通常结合发布场景来出。比如Deployment滚动更新时如何控制同时杀掉和新建的Pod数量。答案就是maxUnavailable和maxSurge两个参数maxUnavailable决定更新过程中允许不可用的Pod数默认25%maxSurge决定允许超出期望副本数的Pod数默认25%。资源限制是另一个常见考点。requests是调度时的资源预留limits是容器运行时的资源上限。一个经典坑是limits设置了CPU但requests没设置调度器可能把Pod调度到资源不足的节点运行时一忙起来就OOM。笔试里如果考到Kubernetes和资源相关基本都会围绕为什么request和limit都要设置展开。6. 故障排查场景题先找证据再改配置6.1 CPU负载飙高的完整排查链路场景题是我认为这套卷里最有含金量的部分因为它没有标准答案考察的是排查思路的完整性和逻辑性。典型的题目类型是某台线上服务器CPU负载飙高怎么定位原因。死记硬背命令没用完整思路应该是先看现象uptime看负载均值top按CPU占用排序确认是单个进程还是整体飙高。如果是单个进程用top -Hp pid切到线程视图找到具体是哪个线程。然后区分是业务代码问题还是系统问题。如果是Java应用用jstack pid导出线程栈搜索线程状态为RUNNABLE的线程结合Grep找到业务方法。如果是Python应用用py-spy dump --pid pid可以直接看到Python解释器当前正在执行的代码行这个工具在线上遇到Python死循环时简直是救命稻草。再进一步用strace -p pid看系统调用判断进程是不是卡在某个IO或锁等待上用perf top看内核热点函数确认是否有异常中断或上下文切换。最后结合变更记录判断根因是不是刚发过代码是不是有定时任务在这台机器上跑全量脚本是不是日志目录满了导致程序疯狂重试写入这些通常才是真正的根因。笔试评分时能答出先看有没有新变更、再顺着连接数定位到具体线程、最后用strace确认这种完整链路和只写重启一下是两个级别。6.2 用户播放卡顿的运维视角爱奇艺这种视频平台的场景题经常围绕播放体验出题比如用户反馈视频播放卡顿你怎么排查。这个题对没接触过视频业务的人来说容易懵但解题思路本质还是分层排查。第一步确定范围是单个用户、单个地域、还是全网问题。单个用户手机或Wi-Fi有问题属于客户端问题单个地域有大量用户反馈就要怀疑该地域的CDN节点或者运营商线路全网问题大概率是源站、核心服务或账号系统故障。第二步看指标。视频运维的黄金指标是首帧时间、卡顿率、平均码率、CDN命中率、回源带宽。如果首帧时间上升但CDN命中率正常说明用户到CDN节点的链路有问题可能是DNS调度把用户分到了远节点如果命中率下降回源带宽上升说明CDN缓存策略或新内容发布出了问题源站压力大卡顿是必然的。第三步用工具验证。dig确认用户解析到的CDN节点IP和预期是否一致curl -H Range: bytes0-1048575测试节点分片下载速度再用mtr看从用户IP到自己测试节点之间的丢包和延迟。一套流程走下来问题基本能被定位到具体环节。6.3 数据库连接数打满的应急处理数据库连接数打满也是互联网运维笔试常考的场景。这个题看两个能力一是短时间内能不能保住业务二是事后会不会根治。应急处理思路是先用show processlist查看当前连接状态区分连接来源是哪台应用服务器再用show status like Threads_connected确认连接数是否达到上限。如果在线慢查询很多需要先找到慢SQL用explain看执行计划必要时临时kill掉大量长时间运行的查询让连接数降下来。如果应用层有连接池泄漏重启应用服务是临时的止血动作但必须同时保留现场收集堆栈和连接池监控数据否则重启后问题还会复现。这类题的得分点在于你做每一步时有没有说清楚为什么。为什么先看慢查询而不是直接重启因为你要先判断是数据库本身性能问题还是应用连接泄漏为什么保留现场因为重启会销毁堆栈信息根因就很难查了。7. 五年后的视角这套题的价值与备考思路7.1 哪些考点至今没变哪些已经过时把2019年这套题放到现在看有些考点始终没变有些已经明显过时。没变的是Linux基础、TCP/IP、HTTP、故障排查方法论这些是运维的底层能力十年后也变不了。过时的是具体参数和工具细节比如tcp_tw_recycle已经在内核中移除Docker命令背诵逐渐让位于Kubernetes原生工作负载管理和云上托管服务。新增的方向也值得关注。可观测性现在是运维笔试的高频内容Prometheus监控、Grafana看板、ELK日志平台都会出现云上资源管理、IaC基础设施即代码也在逐步普及用Terraform或Pulumi管理基础设施成了云运维的基本功GitOps和CI/CD流水线则进一步把发布流程标准化、自动化。如果你现在备考不能只刷2019年的老题要把容器、云原生、可观测性这三大方向补充进来。但反过来也不要觉得老题没用Linux命令、网络协议、排查思路这些东西在2024年的笔试里依然是一等一的重点。7.2 针对这类笔试题的备考框架基于这套题的考察分布我给一个比较实用的备考时间分配30%复习Linux和Shell20%复习网络和HTTP20%手写Python脚本20%学容器和Kubernetes基础10%研究故障排查思路。这个比例和实际笔试的分数占比基本吻合不会浪费精力。Linux和Shell部分的备考资料不需要多把《鸟哥的Linux私房菜》基础篇过一遍然后每天在虚拟机上做三到五个真实场景操作比如找出某个目录下最大的文件并删除“统计某个日志里报错次数最多的行”“写一个脚本备份目录并保留最近7天”。脚本能力要练到不用翻手册能独立写完一个50行左右的脚本。Python部分的练习可以结合运维场景。先写一个磁盘使用率告警脚本再写一个批量重命名日志文件的脚本再写一个遍历目录统计各文件类型占用空间的脚本这三个练完基本能应付大多数运维笔试。写的时候随时注意用with、处理异常、加入__name__入口判断养成好习惯。故障排查思路这个方向光看书没用要刻意练习。把常见的故障案例CPU飙高、内存泄漏、连接数打满、磁盘满、延迟抖动在纸上先写一遍排查步骤再对照标准流程找不足。重点是培养先确认现象、再缩小范围、最后定位根因的思维链路而不是记住某一个具体问题的解法。7.3 从会做题到能干活笔试之外的真实差距每年都有人问运维是不是没岗位了但从我接触的团队招聘情况看运维需求量一直不小只是要求变了。纯手工运维、只会重启服务、遇到问题就百度的人确实在退出市场但能写自动化脚本、能搭建监控体系、能在一小时内定位线上故障根因的运维工程师依然非常稀缺。互联网公司运维和国企或传统行业运维的笔试、面试风格差别很大。互联网更强调高并发、大规模集群、快速迭代下的稳定性所以笔试会像爱奇艺这份卷子一样考Linux命令深水区、考网络状态机、考场景排查传统或国企运维更侧重流程规范、合规运作、标准化操作考题会更偏向资产管理、巡检规范、操作文档。我建议备考的同学先确定目标方向再针对性准备。如果目标是互联网中大厂就按这套题的方向去练尤其把场景题和Python脚本题练扎实如果目标是国企或传统行业信息化部门重点学习运维流程文档、安全基线、数据备份恢复这些偏向规范性的内容。两条路没有优劣只有适不适合。这套题给我最大的启发是运维笔试不是看你背了多少命令而是看你有没有顺着现象一路找到根因的能力。这种能力没法临时突击靠的是平时多处理真实问题、多复盘故障过程。你每多处理一次线上故障以后面对任何一道场景题都会多一分底气。