作为常年混迹在各大互联网公司面试现场的老运维看到“爱奇艺2019秋招运维方向笔试题A”这份题目时我还是挺有感触的。那几年的运维岗笔试题风格非常统一不跟你玩虚的不考你背得出的八股文而是把你丢到一个快要出故障的系统面前问你怎么活下来。爱奇艺这套题更是典型中的典型它对网络、Linux、数据库、中间件以及监控应急的考察几乎覆盖了当时一线运维工程师日常工作的全部高频场景。我当年也参加过不少类似的笔试说实话纯背题的人看到这套卷子大概率会懵。因为它考的不是“你知道什么”而是“你遇到问题了会怎么查、怎么想、怎么干”。这篇文章我不打算给你一份标准答案的抄写稿而是站在一个从业者的角度把这份笔试题背后真正想考察的东西拆开揉碎了讲清楚。特别是那些看似简单、实则全是坑的题目我会把排查思路、底层原理和实战经验一起给你捋一遍。1. 这套题考的不是知识点是故障现场的肌肉记忆爱奇艺2019年秋招运维笔试的题目结构和当时大多数一二线互联网公司的风格是一脉相承的基础概念题占比不高更多的是给你一个具体的故障场景或命令输出让你判断问题出在哪、下一步该敲什么命令。1.1 为什么说它是“场景驱动”而不是“概念驱动”举个很典型的例子很多人背过TCP三次握手和四次挥手的流程画图画得行云流水。但笔试里如果给你一个netstat的输出里面全是TIME_WAIT或CLOSE_WAIT问你服务响应变慢是不是因为这个原因很多背题选手就卡住了。爱奇艺这套题里类似的考察方式非常密集。它要考察的是一个运维工程师在收到告警之后打开终端那一刻的“肌肉记忆”。你脑子里装的不应该是教科书上的定义而是一张排查地图先看什么指标再敲什么命令最后怎么确认根因。这种能力不是靠背出来的是靠一次次故障处理喂出来的。所以你看这套题会觉得它特别“干”干到没有任何废话每道题都在模拟一个真实的上线或救火场景。1.2 运维笔试的隐性筛选逻辑给多少钱办多少事站在出题人的角度想笔试的目的从来不是考倒所有人而是快速筛选出“能干活的人”和“需要从头教的人”。爱奇艺那会儿的运维团队规模不小业务线复杂视频业务对延迟和稳定性要求极高。他们要招的人是上来第二天就能独立处理日常工单、能在大促前配合完成容量评估、能在凌晨三点被叫起来处理告警时不慌的人。所以你会发现这套笔试题里的网络题不会问你IP地址分几类而是给你一个抓包结果让你分析Linux题不会问你chmod的权限数字怎么算而是给你一个进程僵死状态让你处理。这就是筛选逻辑的体现基础知识是底线但真正拉开差距的是你有没有处理过真实问题的经验。2. 网络与系统基础题这些“送分题”才是真正的分水岭网络和系统基础是运维笔试的必考板块也是很多自认为“基础扎实”的人最容易翻车的地方。因为这部分题目看起来都认识但选项里全是运维日常踩过的坑。2.1 TCP状态机别背流程图要能看懂netstat的输出随便翻开一套运维笔试题TCP状态机几乎是必考的。但爱奇艺这套题的考法很刁钻它会给出一台服务器的连接状态统计然后问大量TIME_WAIT出现在哪个角色上怎么优化CLOSE_WAIT大量堆积又说明什么先说TIME_WAIT。主动关闭连接的一方在发送最后一次ACK之后会进入TIME_WAIT状态要等待2MSLMaximum Segment Lifetime报文最大生存时间才会彻底消失。为什么要有这个等待两个原因一是防止最后一个ACK丢失后对端重发FIN时无法回应二是防止旧连接上的延迟报文干扰新连接。如果你的Nginx或LVS作为反向代理转发大量短连接请求那么它必然会产生大量TIME_WAIT。这不是故障只是连接回收的正常现象。但量太大了会占用本地端口资源导致Cannot assign requested address的报错。常见的优化手段有开启net.ipv4.tcp_tw_reuse在发起连接时复用TIME_WAIT前提是开启tcp_timestamps、调整tcp_max_tw_buckets、或者干脆让客户端使用长连接。再说CLOSE_WAIT。这个状态是收到对端的FIN后本地还没调用close()关闭连接时进入的。如果你的服务端出现大量CLOSE_WAIT几乎不用怀疑就是你的应用程序有bug连接没有正常关闭。常见原因包括代码里没有在异常路径中释放连接、线程池阻塞导致连接无法处理、数据库连接池泄漏等。很多刚入行的运维看到CLOSE_WAIT第一反应是调内核参数但实际上调了也没用内核参数解决不了应用层的连接泄漏问题。正确的处理方式是抓线程栈看哪个线程持有的连接一直没有释放。2.2 硬链接与软链接一条命令背后的inode原理Linux文件系统也是必考项尤其是软链接和硬链接的区别。这道题在面试中出现的频率极高因为它是理解文件系统底层逻辑的试金石。硬链接的本质是在同一个文件系统内多个目录项指向同一个inode。inode里记录着文件的元数据和数据块指针文件系统通过inode来管理文件内容。硬链接不会额外占用数据块空间每新建一个硬链接只是把inode的链接计数加1。当你rm一个硬链接时只要链接计数不为0数据块就不会被回收。这就是为什么运维在清理磁盘空间时即使删了文件发现空间没释放第一反应就是去查是不是还有进程持有这个文件的fd文件描述符。只要进程没退出文件数据块就还占着磁盘。软链接就完全不是一回事了。软链接是一个独立的文件它有自己的inode数据块里存的是目标文件的路径字符串。目标文件被删除后软链接就成了“悬空链接”访问它就会报No such file or directory。这里有个新手容易踩的坑删除软链接时rm -rf linkname/和rm -rf linkname结果完全不同。带斜杠的写法会报Not a directory因为软链接指向的是一个目录但rm -rf加上斜杠后会尝试去处理软链接指向的目录内容这里容易造成误删源目录的隐患。正确的做法永远是rm linkname。2.3 权限与ACLchmod 777 不是万能的Linux权限这块爱奇艺的题目倒不会出得太刁钻但一定会涉及SUID、SGID、Sticky Bit以及ACLAccess Control List访问控制列表的基础概念。SUID是运维排查中经常遇到的一个点。比如passwd命令普通用户执行它时需要修改/etc/shadow文件而这个文件权限是600属主是root。为什么普通用户能改自己的密码就是因为passwd命令设置了SUID位执行时进程的有效用户ID临时变成了文件属主root。排查这类问题时有一个非常实用的命令find / -perm -4000 -type f 2/dev/null这个命令会找出所有设置了SUID位的文件。如果服务器被入侵黑客经常会在系统里留一个SUID的shell后门这个命令就能帮你快速发现异常。ACL这块平时用得不多但一旦遇到就很头疼。最典型的是Nginx需要读取apache用户创建的文件时权限不足又不想把目录权限改成777。这时候用setfacl -m u:nginx:rx /data/www/就能精准控制。同样排查问题时别忘了用getfacl看ACL不然你可能会被“明明文件权限是755为什么www用户还是无法访问”这种问题折磨半天。3. Linux进阶与Shell脚本从“会敲命令”到“会写工具”的差距笔试考Linux命令其实考得有限因为命令本身是工具查man就能学会。但运维笔试里一定会有几道题考察你能不能把这些工具组合起来解决实际问题。这背后的差距是命令的“组合能力”。3.1 文本处理三剑客grep、sed、awk爱奇艺这套题里文本处理是考察重点。因为日志分析是运维每天都要做的事日志就是文本能在短时间内从海量日志里提取出关键信息是基本功。举个例子统计Nginx访问日志里访问量最大的前10个IPawk {print $1} access.log | sort | uniq -c | sort -rn | head -10这个组合命令里awk负责提取第一列客户端IPsort负责排序uniq -c负责去重并统计出现次数再sort -rn按次数倒序排列最后取前10个。拆开看每一步都简单但组合起来就是一个完整的统计链路。再比如查找日志里某个时间段内的报错信息提取出报错类型并分类统计sed -n /2024-01-15 10:00/,/2024-01-15 11:00/p error.log | grep -oP \[ERROR\] \K.* | sort | uniq -c | sort -rn这道命令里sed用了地址范围匹配来截取时间段grep用了-oP配合\K来精准提取匹配部分。这里有个经验\K是PCRE正则里的一个标记表示“从这开始才是真正要匹配的内容”前面的内容只做匹配但不进入输出。用这个技巧提取日志中的特定字段比用 awk 按分隔符拆列要灵活得多。3.2 系统问题排查负载高不等于CPU忙笔试里关于系统负载的问题最喜欢设置一个陷阱uptime显示 load average 很高让你回答该怎么排查。很多人第一反应是CPU满负荷了直接看top。但真相可能是IO等待太高。load average 的单位不是百分比它是一个“平均活跃进程数”。它统计了处于运行态R状态和不可中断睡眠态D状态通常是等待IO的进程数量。如果大量进程在等待磁盘IOload average同样会飙升但CPU使用率可能很低。排查这类问题时正确的思路是用top看第一行负载再看%Cpu(s)里的waIO等待占比。如果wa很高说明IO是瓶颈。用iostat -x 1看磁盘的%util和await。%util接近100%说明磁盘已经饱和await非常高说明IO响应延迟大。用pidstat -d 1看具体是哪个进程在大量读写磁盘。用lsof L1查看已被删除但仍被进程占用的文件这些文件会持续占用空间且不释放。这套链路走下来定位问题就很容易。但我见过太多新人在top里看到某个进程CPU高就直接kill完全没考虑它是不是在刷日志、在写临时表、或是在做正常的批量任务。运维排查的第一步不是处理而是搞清楚“这个现象正常吗”。3.3 Shell脚本笔试爱考但考的是边界假设Shell脚本在笔试题里通常不会要求写一个完整项目但会出一个修改日志清理脚本的题目或者给你一个脚本问里面哪里有问题。常见脚本错误我总结了一下笔试和面试最爱挖坑的有这几类变量未加引号rm -rf $DIR如果$DIR为空或者含有空格会变成rm -rf /或者拆成多个参数这绝对是灾难级别的bug。正确写法是rm -rf $DIR。管道前变量赋值不生效cat file | while read line; do count$line; done; echo $count什么都输出不了。因为while在子shell里执行子shell的变量不会影响父shell。解决方式是使用进程替换while read line; do ...; done file。set -e的误用很多人习惯在脚本开头加set -e但有些命令如grep匹配不到内容时返回非0会直接让脚本退出。所以更严谨的写法是grep -q pattern file || { echo not found; exit 1; }把错误处理显式写出来。脚本的价值在于减少重复劳动和人为失误。你在笔试里写脚本思路比语法重要。把边界条件考虑清楚比堆砌高级语法更能得分。4. 数据库与中间件业务稳定性的压舱石运维不光是管Linux服务器数据库和中间件的日常维护、问题排查也是笔试考察的重头戏。爱奇艺这种体量的视频平台数据库和缓存的稳定性直接关系到线上用户体验。4.1 MySQL索引失效和慢查询是永远的主题MySQL的笔试题目围绕索引和慢查询的概率极高。它的逻辑很好理解对于互联网公司数据库的性能问题90%出在SQL上10%出在硬件和参数配置上。索引失效是一个经典的考察点。比如给create_time字段建了索引但查询条件是WHERE DATE(create_time) 2024-01-15索引就不会生效。因为你对索引列使用了函数MySQL无法直接使用B树索引进行范围查找。正确写法是WHERE create_time 2024-01-15 00:00:00 AND create_time 2024-01-16 00:00:00。再比如最左前缀原则。一个联合索引(a, b, c)查询条件WHERE b 1 AND c 2是走不了索引的因为跳过了最左列a。但如果查询是WHERE a 1 AND c 2索引只能用到a这一列b和c的索引就用不上。这个机制笔试喜欢考工作里更是一堆人踩坑。排查慢SQL的手段除了开启slow query log还要会看EXPLAIN的输出。type字段是重点const最好ref其次range尚可ALL就是全表扫描基本是性能杀手。配合rows字段估算扫描行数就能判断SQL有没有优化空间。另外Extra字段里出现Using filesort或Using temporary时意味着查询里有排序或去重操作没有用到索引大表下这些操作极慢。4.2 Redis缓存穿透、击穿、雪崩是三位一体爱奇艺的笔试基本不会漏掉Redis因为视频网站的弹幕、推荐、用户状态等场景大量依赖缓存。缓存相关的三个经典问题经常混在一起考穿透、击穿、雪崩。穿透请求的数据在缓存和数据库里都不存在每次请求都直接打到数据库。攻击者可以利用这个特点伪造大量不存在的key来拖垮数据库。击穿某个key非常热点在缓存过期的一瞬间大量请求同时打到数据库。雪崩大量key在同一时间过期导致数据库瞬间压力激增。解决方案笔试里答上关键词就能拿分但工作里要结合业务场景选型。穿透的解法是布隆过滤器Bloom Filter把所有可能存在的key提前加载到过滤器里查询时先过过滤器如果过滤器说“不存在”直接返回不再查询数据库。击穿的核心解法是互斥锁在缓存失效时只让一个线程去重建缓存其他线程等待。但要注意锁的粒度分布式环境下要引入Redisson这类分布式锁组件。雪崩的解法有两个思路一是让缓存过期时间加一个随机因子避免大量key同时失效二是多级缓存本地缓存如Caffeine加分布式缓存如Redis组合本地缓存兜底。4.3 消息队列考原理更考丢消息的处理消息队列的题目常见的有RabbitMQ和Kafka两个方向。爱奇艺的笔试可能会问如何保证消息不丢失消息重复消费了怎么办保证消息不丢失要分三段来看生产者、Broker、消费者。生产者端Kafka可以设置acksall表示分区副本都写入成功才返回成功这在极端情况下会降低吞吐量但能有效防止消息写入失败。此外生产者端要开启重试机制并设置合理的retries和max.in.flight.requests.per.connection避免消息乱序。Broker端Kafka通过多副本机制保障replication.factor至少设置为3min.insync.replicas设置为2配合acksall即使有一台Broker宕机消息也不会丢。消费者端手动提交offset时要注意先处理业务逻辑再提交offset。如果先提交offset再处理业务进程崩溃后消息就丢了。但这样又引入了重复消费的问题。所以业界常用的思路是业务逻辑要做成幂等的或者通过记录处理状态来去重。这套题里如果涉及消息队列我猜出题人更想看到的是你“考虑问题的周全性”而不是你有没有背过术语。5. 监控、安全与自动化体面运维的最后一公里笔试的最后一个板块往往是综合性的考察运维的“全局视野”。爱奇艺的业务高峰期很明显晚上8点到11点是视频观看高峰节假日流量翻倍增长。这种业务形态对监控和自动化能力要求特别高。5.1 监控告警先问“用户感知到了吗”监控体系怎么设计是笔试的压轴题常客。很多人的回答是CPU、内存、磁盘、网络每个都配上告警。但面试官想听的绝对不仅仅是“监控四件套”。好的监控体系设计思路要从“用户可感知的指标”倒推。对视频业务来说首播时间、卡顿率、视频起播成功率是最核心的体验指标。然后才是支撑这些体验的系统指标CDN命中率、源站带宽、接口延迟、错误码分布等。底层才是硬件资源指标。这三个层次缺一不可单独监控任何一层都有盲区。另外告警要区分等级别让所有事情都P0。我见过一个团队因为磁盘告警阈值太低每天几十条告警最后真正重要的告警反而被淹没了。合理的做法是CPU使用率超过90%持续5分钟才触发告警而不是一超过60%就告警磁盘使用率超过80%发提醒超过90%发告警95%以上立刻升级。5.2 安全应急常见但绝不能犯的低级错误安全相关题目在运维笔试里通常不会考渗透测试那么深但会考一些基础的安全意识和应急响应流程。比如服务器被暴力破解怎么办发现异常进程怎么办这两个问题我很喜欢。因为答案并不复杂但非常考验操作规范。处理暴力破解的标准流程是先用lastb查看失败登录记录确认攻击来源IP。用who查看当前登录会话确认是否有异常用户在线。修改SSH默认端口或配置防火墙只允许内网IP访问22端口。配置fail2ban等工具对多次尝试登录失败的IP自动封禁。检查是否已经失陷看/tmp目录有没有可疑文件用find / -perm -4000查SUID异常看计划任务crontab -l和/etc/cron.*里有没有可疑任务检查~/.ssh/authorized_keys有没有被写入陌生的公钥。发现异常进程时不要直接 kill先通过ls -l /proc/PID/exe查可执行文件路径用cat /proc/PID/cmdline看启动命令再用lsof -p PID看它打开了哪些文件。排查完确认是恶意进程之后再把它连带启动脚本一起清理干净同时检查持久化后门。5.3 自动化与DevOps从“人肉运维”到“平台运维”面向2019年的考察自动化已经是一个重要的加分项。笔试里可能会问你用过哪些配置管理工具如何实现服务的自动部署和滚动更新我当时常用的方案是Ansible加SaltStack的组合或者用Puppet做配置管理。现在回头看工具会过时但核心思想不变一切皆代码。服务器的初始状态用代码描述应用的部署过程用脚本编排环境的差异用变量隔离。如果你在笔试里遇到这类题光回答“我用了Ansible”是不够的。要体现出你是用Playbook管理服务器初始化、用roles组织任务、用group_vars区分环境差异、用ansible-vault加密敏感信息这样才是完整的工作流。而不仅仅是“会运行一条ansible命令”。6. 一套“实战向”自测题还原笔试里最扎心的八道题前面聊的都是考点分析这里我整理了一套模拟题。题源来自我和同行们这几年笔试面试遇到的真实场景风格参考爱奇艺2019那套题你可以拿来自测一下。不用急着查答案先凭自己的经验推演一遍再去验证效果最好。6.1 题目列表一个Web服务近期频繁收到请求超时告警从监控看CPU和内存使用率都不高。你觉得下一步最应该查什么为什么在Linux终端执行df -h看到/data分区只剩5%空间但du -sh /data/*统计出来的总大小远小于分区已用大小。可能是什么原因怎么处理你的数据库连接数飙升DBA反映连接数达到上限但业务量并没有涨。你会从哪几个方向排查一台服务器负载为50但top里%Cpu(s)的 us 只有2%。请列出至少两种可能原因并给出对应的排查命令。Nginx 返回502 Bad Gateway而后端PHP-FPM的进程都在运行你可能怎么排查一条SQL在测试环境执行只要50ms在线上执行要5秒。两边数据量一样多。可能是什么原因线上服务出现了10分钟的延迟尖刺事后排查发现当时有定时任务在跑。你会怎么定位是哪条SQL或者哪个逻辑影响了主流程内网DNS解析到某个业务域名偶尔超时但不是每次都会。从DNS服务器和客户端两侧看你觉得该怎么排查6.2 答案解析与排查思路第1题CPU和内存都不高但请求超时第一个要怀疑的是文件描述符fd耗尽或者线程数达到上限。用cat /proc/PID/limits和ss -s快速确认。不要一上来就重启服务先看dmesg里有没有Too many open files的报错。第2题这是经典的“文件被删但空间不释放”问题。可能是有进程在持续写一个已删除的文件。用lsof L1查看然后确认进程后重启该进程或让它重置日志文件空间就会释放。第3题连接数飙升但业务没涨通常方向有四个连接池配置不当最大连接数设置的太高、代码里忘记释放连接连接泄漏、存在大量慢查询导致连接被长时间占用、以及有异常客户端在疯狂建立连接。排查顺序建议是先看SHOW PROCESSLIST确认这些连接在干什么再抓应用日志看是否有异常报错最后检查连接池配置和代码。第4题负载高但CPU不高典型原因有大量进程处于D状态即不可中断睡眠通常意味着磁盘IO饱和用iostat -x 1确认或者是CPU被大量短任务占满看起来us不高但上下文切换极其频繁用vmstat 1看cscontext switch列是否爆高。另外还有可能是大量线程在等待锁整体看CPU不高但用户态没有有效利用CPU。第5题Nginx 502代表网关收到了后端无效响应。PHP-FPM进程在跑不代表它能正常处理请求。先看PHP-FPM的slow log和错误日志确认是不是执行超时再查后端服务的并发连接数是不是达到了pm.max_children的上限还要确认Nginx和后端之间的unix socket或TCP连接是否正常比如socket文件权限有没有问题。第6题测试环境50ms线上5秒相同数据量下大概率是执行计划不同。常见原因是线上表的统计信息不准确导致优化器选错了索引。先运行ANALYZE TABLE更新统计信息再看EXPLAIN的type字段是否变好。另外线上可能有大量并发写入行锁竞争严重测试环境没有这种情况要看SHOW ENGINE INNODB STATUS里的锁信息。第7题定时任务影响主流程最有效的手段是全链路追踪。先看这个时间点的监控曲线确定是CPU还是IO先出现拐点然后结合定时任务日志定位到具体任务。如果任务和主流程共享数据库优先查慢查询日志看看定时任务是否触发了锁等待比如把大表给锁住了主流程的写入就在等待锁。另外用perf top看内核热点也会很快锁定IO或CPU的问题根源。第8题DNS偶发超时涉及链路长排查要分步。客户端侧先看/etc/resolv.conf的配置和DNS服务器的连通性用dig指定服务器看响应时间再确认是不是有搜索域导致查询步骤多。服务器侧要看DNS服务本身的日志确认该域名是从缓存返回还是转发了上游。还要注意一点如果DNS服务器开启了DNSSEC验证验证失败也会导致超时。7. 笔试答得好只是入场券从卷面到工位还有几步要补笔试题的分数高只能说明你“知道得不少”。但从笔试通过到真正成为一名合格的线上运维中间还差着实践经验的距离。7.1 把卷子上的命令变成自己的维护清单很多人笔试时可以顺畅写出ss -tn state time-wait | wc -l这类的命令但真正处理故障时会发现光有单个命令没用你得有一套组合拳。我的建议是把常见的故障场景整理成自己的SOP清单。比如针对“接口变慢”这个场景你的SOP可以是先top看负载和CPU再vmstat看r和wa列紧接着iostat -x确认是不是磁盘再用pidstat锁定进程最后用strace -p看这个进程在做哪些系统调用。这套流程走下来慢在哪个环节基本就水落石出了。这份SOP不是笔试答案是你自己的排查地图越用越值钱。7.2 从“处理过”到“能讲清楚”的复盘能力面试官问项目经历时最怕听到的回答是“上次遇到CPU飙高我加了台机器就好了。”这个回答等于没答。真正有价值的问题是CPU为什么飙高加了机器之后瓶颈转移到了哪里有没有可能在加机器之前就用更好的方式化解这就是复盘能力的价值。每一次故障处理完我都会写一份简单的复盘文档包含四个部分故障现象、影响范围、排查过程、根因与改进措施。这份文档不需要长几百字就行。但坚持半年下来你会发现自己看问题的方式完全不一样了。笔试里的场景题其实就是出题人把你未来要做的复盘提前考了一遍。7.3 最后再说一点面试的偏好爱奇艺这类公司的面试官普遍偏好有“手感”的候选人。所谓手感就是你提到一个工具时能顺口说出它在你实际业务中遇到的问题和克服的过程提到一个参数时能说出你当时是拍脑袋调的还是压测调优出来的。这些细节骗不了人编造的经验在追问下很容易露馅。所以我更建议你在日常工作中保持好奇心。遇到一个奇怪的报错别急着搜解决方案先自己查查日志、看看进程状态尝试理解它为什么会这样。这个过程积累下来的“手感”比刷一百套笔试题都管用。这套2019年爱奇艺运维笔试题距今有些年头了但核心考点放到现在的面试里也完全不过时。它考的网络排查、系统原理、数据库和中间的故障分析能力是一个运维安身立命的根本。公司可能会换业务可能会变但底层逻辑不会变运维的核心价值就是在复杂系统出问题时你能够冷静、准确、高效地让它恢复如初。