我在面试候选人时发现一个很普遍的现象很多简历上写着“熟悉Linux”“掌握网络基础”的运维新人一到笔试环节就露怯。不是知识点没看过而是不知道大厂出题人真正想考察什么。爱奇艺2019秋招这套运维方向笔试题A在当年校招圈里流传很广它的命题思路非常典型覆盖了操作系统、网络、脚本、数据库、中间件这几个运维核心模块。我最近又把它翻出来对照着这些年带团队、做面试官的经验重新看了一遍发现这套题哪怕放在今天依然有很强的参考价值。无论你是准备秋招的应届生、打算跳槽的初级运维还是已经在职但想自查知识盲区的工程师这篇文章都值得花几分钟读完。这篇文章我会从题型的整体设计逻辑切入把核心考点逐个拆开讲清楚再结合我实际带人、踩坑的经历告诉你哪些地方最容易丢分以及从笔试到实战之间还差哪些能力。我不打算逐题贴答案那样没有意义我更想帮你看懂这套题背后的运维能力模型。1. 笔试全景拆解一道A卷背后的大厂筛选逻辑1.1 题型分布与时间分配爱奇艺这套A卷是典型的“广度优先”筛选卷题量不小涵盖单选、多选、判断、简答和shell编程题考试时间通常在90到120分钟。如果你做过类似的互联网公司运维笔试题会发现这个结构非常熟悉前面是大量基础概念题中间是场景分析最后一定要有一道手写脚本的题。我当时给团队出面试题时也沿用过类似的框架。为什么这么设计因为运维岗位的特殊性在于你既要懂底层原理又要能快速动手解决问题。纯选择题只能筛掉完全没基础的人简答题能看出你表达思路是否清晰而手写脚本则直接暴露你的真实动手能力。整套题做完一个人是“背过面试题”还是“真用过这些命令”基本能看出来。时间分配上我建议选择题和判断题控制在40分钟内完成不要恋战简答题每题控制在8到10分钟把自己的排查思路写清楚比单纯堆术语强得多。shell编程题留至少20分钟因为这类题往往不只考语法还考你对文本处理、定时任务、日志切割这类实际场景的理解。1.2 核心知识模块的权重分析从这套题覆盖的范围来看知识模块的权重有明显的倾向性。我根据自己的经验给一个大致的占比参考知识模块预估占比主要考察方向Linux系统与运维基础30%常用命令、进程管理、文件系统、权限、systemd网络基础25%TCP/IP、HTTP、DNS、抓包工具Shell/Python脚本15%文本处理、循环判断、定时任务、日志分析MySQL/Redis10%主从复制、备份恢复、缓存使用Nginx/中间件10%反向代理、负载均衡、常见配置Docker/容器与云10%镜像容器、部署思路、Kubernetes基础这个权重分配其实反映了视频类互联网公司的技术栈特点高并发、大流量、海量日志所以对Linux性能排查和网络排查的要求特别高。我见过不少候选人把精力全扑在容器和K8s上反而把Linux基础给丢了结果笔试中栽在最朴素的命令题上非常可惜。1.3 命题背后的隐藏意图看这套题不能只看题目本身还要琢磨出题人到底想要什么样的人。我的判断是三个关键词能值班、能定位、能自动化。“能值班”对应的是Linux和网络基础这是运维的底线能力。系统出问题时你要能登录上去用命令把症状摸清楚。“能定位”对应的是场景题给你一个故障现象你要能说出排查链路、确定影响范围、找到根因。“能自动化”对应的是脚本题互联网公司的服务器规模动辄几百上千台你要还靠手动一台一台登上去改配置那效率就太低了。这套题表面上在考察知识点实际上在模拟一个运维工程师的工作日常。你答题时如果能顺着这个思路去组织语言比如在简答题里主动提到“先看监控告警再登服务器查日志”分数往往比干巴巴列几个命令要高。2. 核心考点逐项击破从Linux到容器每一类题怎么答2.1 Linux系统与常用命令高频考点集中营Linux相关题目在整套题里占比最高出题方式也非常灵活可能是判断正误也可能是给出一个故障场景让你选命令。常见的高频考点包括top中load average三个数值的含义、free中buff/cache与可用内存的关系、ps输出中进程状态D/R/S/Z分别代表什么、软链接和硬链接的区别、crontab的写法、find与xargs的组合使用等。我特别想提醒一个容易被忽视的点inode耗尽。很多候选人知道df -h看磁盘空间但不知道df -i看inode。真实生产环境里磁盘明明还有几十GB却提示“No space left on device”根源往往是磁盘分区inode被小文件占满了。这种题判断正误的时候如果你能主动把inode和block这两个概念区分清楚面试官对你的印象会明显不一样。进程管理也是必考内容。比如ps -ef和ps aux的区别kill -9与kill -15的差异为什么优先用kill -15而不是直接kill -9。我见过太多候选人一上来就说“杀不掉就kill -9”这在实际生产中是很危险的操作。对于Java应用或者数据库进程直接kill -9可能导致数据丢失或主从切换异常正确做法是先kill -15给进程优雅退出的机会。系统初始化这块现在很多题会考systemd比如systemctl enable和systemctl start的区别、写一个service unit文件需要哪些关键字段。这类题不难但能看出你是否真的在Linux环境里部署过服务而不是只在虚拟机里敲过几条命令。2.2 网络与TCP/IP不仅考概念更考排障思路网络题是另一座大山。爱奇艺这种视频流媒体公司对网络的理解要求很高因为CDN调度、回源、带宽调度都是日常。笔试里TCP三次握手和四次挥手基本是必考的但我建议你不要只背状态流转要能说清楚为什么需要三次握手、为什么TIME_WAIT大量出现、怎么优化。这里有个特别经典的场景题服务器上出现大量TIME_WAIT怎么办标准答案是检查ss -s或netstat -s查看统计然后通过调整net.ipv4.tcp_tw_reuse、tcp_tw_recycle、tcp_fin_timeout等内核参数来缓解。但这里有个坑tcp_tw_recycle在NAT环境下开启会导致丢包问题很多老内核版本已经默认废弃这个参数。如果笔试时你能提到“现代内核通常不建议开启tcp_tw_recycle”就能体现出你不仅知道命令还知道背后的坑。HTTP状态码也是高频考点。除了最基础的200/301/302/403/404/500/502我建议把503和504的区别也弄清楚503是服务暂时不可用比如过载或维护中504是网关超时说明后端服务处理时间过长。遇到这类题最好能补一句“504要先查后端业务日志而不是盯着Nginx日志看”这会给面试官留下“有实战经验”的印象。DNS这块要掌握递归查询和迭代查询的区别能说出浏览器输入域名后完整的解析流程。像nslookup和dig这些命令的基本用法也要熟悉尤其是dig能直接看到TTL和权威服务器的响应排查解析慢或解析不一致时会用到。2.3 Shell脚本与自动化手写题的得分关键Shell题是运维笔试的压轴项目也是最容易拉开分差的地方。爱奇艺这类公司日常有大量日志分析、数据统计、定时清理的工作一个能写一手好脚本的运维效率会比别人高出好几倍。常见的出题形式是“统计Nginx日志中访问量前10的IP”或者“找出日志中某个时间段内出现次数最多的错误信息”。这类题核心考察awk、sort、uniq这组合拳。比如统计Top 10 IP一行命令就能搞定awk {print $1} access.log | sort | uniq -c | sort -rn | head -10别小看这行命令里面藏了好几个考点第一你要知道IP在Nginx日志里是第几列默认$1就是客户端IP第二uniq只能去重相邻行所以必须先sort第三sort -rn是按照数字逆序排列-n是关键不加的话会出现“10排在2前面”这种问题。很多候选人会把uniq -c和sort的顺序写反这就是动手经验不足的典型表现。再有一种高频题是“写一个脚本监控某个进程是否存在不存在则拉起”。这种题要考察的是如何用pgrep或ps判断进程状态、怎么写while循环或crontab定时检查、如何记录日志、如何避免脚本自身被重复执行。我建议用文件锁或者pgrep -f过滤脚本自身进程名来解决重复执行的问题这是实战中一定会遇到的细节。写脚本的时候还要注意规范开头加#!/bin/bash变量尽量加双引号防止空格导致的问题set -e要慎用因为有些命令返回非零会导致脚本直接退出。这些细节不见得会单独出题但会综合体现在阅卷人的印象里。2.4 MySQL、Redis、Nginx与容器中间件题的常见套路数据库题主要围绕MySQL展开主从复制原理、binlog格式、mysqldump常用参数、慢查询排查是几个重点方向。比如问“主从延迟怎么排查”你要能说出Seconds_Behind_Master这个指标的局限它不一定能真实反映延迟情况还要结合show slave status里Read_Master_Log_Pos和Exec_Master_Log_Pos的差值来判断。能答到这个层次说明你真的处理过主从延迟问题。Redis题相对基础但缓存穿透、缓存击穿、缓存雪崩这三个概念是必考。很多候选人知道名字但说不清楚区别穿透是查一个不存在的key请求直接打到数据库击穿是一个热点key过期瞬间大量请求打到数据库雪崩是大面积key同时过期导致数据库压力飙升。答题时最好能针对每种情况给出解决方案比如穿透用布隆过滤器或缓存空值击穿用互斥锁或逻辑过期雪崩用过期时间加随机值。Nginx的题一般围绕反向代理和负载均衡展开负载均衡算法要掌握轮询、加权轮询、ip_hash、least_conn几种并知道各自的适用场景。比如ip_hash适合需要会话保持的场景但后端扩容时会影响hash结果导致session丢失所以很多场景下更推荐用一致性哈希。能讲出这些trade-off分数就上去了。容器和Kubernetes在2019年的笔试题里还只是入门级但放到现在已经是运维的基本功。一个值得弄清楚的链路是kubectl请求到达kubelet后kubelet通过CRIContainer Runtime Interface调用containerdcontainerd再通过runC与内核交互创建容器。很多文章只讲到“containerd是容器运行时”就停了但如果你能答出“containerd收到来自kubelet的CRI请求后会经过内部shim进程调用runc来启动容器”这个深度在面试里会非常加分。3. 高频易错题与答题策略那些年年都有人踩的坑3.1 细节判断题字里行间全是陷阱这套笔试题里有很多细节判断题出题人专门在表述上做文章。比如“Linux中硬链接可以跨文件系统创建”这句话看起来好像没问题但硬链接的本质是同一个inode的多个目录项跨文件系统意味着inode号可能冲突因而是不允许的。如果对这个概念不熟很容易判断错。还有一个典型坑“kill -9可以杀死所有进程包括不可中断睡眠状态D状态的进程”。这个表述是错的D状态进程处于内核态等待IO你发什么信号都杀不掉只能等它自己结束或者重启系统。这类题考察的是对进程状态机的理解光背命令不够得知道内核层面的行为逻辑。针对这类题我的建议是判断正误时重点关注句子里有没有绝对化的词比如“所有”“一定”“必须”“不会”这类词出现时大概率是有隐藏的反例。再配合临界条件去推演比如跨文件系统、D状态进程、root用户权限、NAT环境下TCP参数等场景正确率能提高不少。3.2 场景分析题回答的逻辑比答案本身更重要场景分析题是运维笔试里最有含金量的部分。常见出题形式是“用户反馈网站访问很慢请列出排查思路。”这种题没有唯一标准答案但阅卷时能明显分辨谁是背过题、谁是真有排障经验。一个成熟的排查思路应该按这个顺序展开先确认影响范围——是所有用户都慢还是个别用户慢是某个地域慢还是全网慢然后看监控图表——CPU、内存、磁盘IO、带宽有没有异常这个阶段要会用top、iostat、vmstat、free这些命令快速拿到数据。接着看应用日志和访问日志判断是入口层的问题还是业务代码的问题。我见过一类特别典型的错误答案一上来就说要看日志、重启服务。这种回答没有“优先级”概念也没有“影响范围判断”。真实生产环境里你先确认影响范围是为了决定是马上止损回滚还是花时间慢慢定位根因。比如线上大面积故障时第一时间应该是监控看全局、确认是否多台机器同时异常而不是登录某一台机器去敲命令。另一个常见场景是“磁盘空间满了怎么处理”标准步骤是df -h看分区使用率du -sh *找出大目录再进一步定位大文件。但进阶回答还要提到先看有没有被进程删除但还被占用的文件用lsof | grep deleted这类文件虽然磁盘上看不到但空间不会释放必须重启进程或通过/proc文件系统处理。这个细节我很少在笔试答案里见到但它在生产环境里出现过太多次了。3.3 手写脚本题语法只占一半分思路占另一半手写shell脚本题很多人以为关键是语法正确其实在实际阅卷中思路清晰、注释到位、边界考虑周全的脚本比语法华丽但无法落地的脚本得分更高。举个常见题目“每周末凌晨3点清理/data/log/下7天前的日志文件并记录删除日志。”这个题至少考察了三个能力第一find /data/log/ -type f -mtime 7 -name *.log的时间参数是否写对第二定时任务写法是否标准crontab里星期和小时的位置是否搞混周是第五位小时是第二位很多人会写反第三删除前是否需要先dry-run确认删除日志本身要不要追加记录。我给出的参考实现会这样写#!/bin/bash # 清理7天前的日志文件 LOG_DIR/data/log BACKUP_LOG/var/log/clean_log.log find $LOG_DIR -type f -name *.log -mtime 7 -print -delete $BACKUP_LOG 21分数高的关键不是这五行代码本身而是你能不能在答案里写出这么思考的先确认要清理的目录和文件后缀避免误删其他文件先打印再删除保证有审计记录用双引号包裹变量防止路径包含空格时出错。这些面试官不会明说但都在默默打分。4. 从笔试到实战这套题背后的运维能力模型4.1 笔试题和真实排障之间的距离我经常跟团队里新人说一句话笔试里的每一道题几乎都能在真实生产环境里找到对应场景。load average高对应的是CPU或IO瓶颈排查TIME_WAIT多对应的是高并发短连接优化MySQL主从延迟对应的是大事务或从库负载问题。关键在于做题时你面对的是确定性问题而生产环境里是一个模糊的开局。比如监控报警说某台机器CPU持续跑满你登录上去后CPU可能已经降下来了这时你要会从历史监控曲线、进程启动时间、crontab执行记录、最近变更这几条线索反向推导。这种“从现象倒推根因”的能力光靠刷题刷不出来需要你在真实环境里不断积累。但反过来说笔试成绩依然很重要。它能证明你对基础知识的掌握程度能给面试官一个“这个人值得聊聊”的初始信任。我建议你把笔试当作一次知识体检做错的每道题都值得深挖一下背后的原理而不只是记住正确答案。4.2 生产环境从零搭建一个系统融会贯通的终极场景答题时那些零散的知识点最终要能串成一条线。运维工程师最核心的能力之一就是“从零到一搭建一套系统并保证它稳定运行”。这个过程能倒逼你把Linux、网络、数据库、中间件、监控、备份的知识全部用上。大致链路是选型评估物理机还是云主机、机房还是多活→ 系统初始化分区规划、内核参数、时区、yum源、基础安全加固→ 基础组件部署Nginx、MySQL、Redis、消息队列→ 业务应用发布代码发布、依赖安装、环境变量、健康检查→ 监控告警节点存活、端口、进程、日志关键字、拨测→ 日志收集与ELK或Loki方案→ 定时备份与恢复演练→ 应急预案与扩容方案。这套流程里每一个环节都能对应到笔试考点分区规划对应df和inode的理解内核参数对应网络优化题健康检查对应HTTP状态码备份恢复对应mysqldump参数掌握程度。如果你能自己动手把一个系统从零跑起来刷题时很多理解会变得顺理成章因为你知道这些知识在哪个环节会被用到。我面试时经常问候选人“你自己有没有完整部署过一套环境”这不是要刁难人而是因为运维这个岗位太依赖实感了。没部署过的人遇到故障时往往会慌乱部署过的人再遇到故障时脑子里会有一个清晰的全景图知道先查哪个环节。4.3 桌面运维与边缘场景大厂笔试容易忽略但真实存在的考察点提到运维很多人只想到服务器和机房忽略了桌面运维这个同样庞大且繁琐的领域。爱奇艺这套题偏向服务器方向但实际工作中至少有一半的基础运维工作是桌面支持系统卡顿、蓝屏、网络断连、打印机故障、外设识别异常、软件兼容性问题。我在带团队时发现做过桌面运维的人有一个很宝贵的特质懂得如何跟用户沟通、如何在不影响对方工作的前提下完成排查。比如用户报“电脑卡”有经验的桌面运维不会上来就重装系统而是先看任务管理器的CPU和内存占用定位是某个进程异常还是系统服务异常再决定处理方案。这个排查思路和服务器端CPU高的排查逻辑其实是一致的。还有一些国产化场景比如统信UOS系统或者麒麟系统的运维工具使用这在近年越来越多地出现在实际项目中。这类系统在软件生态和使用习惯上与主流发行版有差异但底层的系统管理思想是相通的。我在给新人做培训时会专门花一两个小时演示如何用livecd模式去修复系统引导、修改密码、备份数据这套思路在物理机故障时极其好用。5. 备考路线与学习资源三个月把知识体系补齐5.1 一套自学地图覆盖从命令到云原生如果你正在为运维方向的笔试做准备我建议按三个月的周期来规划前一个月打基础第二个月专项强化第三个月综合刷题加模拟。第一个月主攻Linux和网络基础。Linux要做到看到命令就能说出常用参数man手册要会查网络要把TCP协议状态流转图背到能默写抓包工具至少会用tcpdump抓一个HTTP请求并看懂关键字段。这个阶段不建议直接刷题而是跟着教材或文档把命令和概念过一遍边看边敲。第二个月主攻脚本、数据库和中间件。Shell脚本从最简单的变量赋值开始到awk和sed处理日志每学一个知识点就写一个真实场景的脚本练手。MySQL和Redis可以自己在本地起一个实例试着做主从复制、写备份脚本、模拟缓存穿透。Nginx至少要做到能配置反向代理和负载均衡知道每个指令的意义。第三个月进入刷题和模拟面试阶段。可以把爱奇艺这套题和其他大厂的运维笔试题放在一起做限时完成做完后不是对答案就完事而是把每道错题对应的知识点重新看一遍。这个阶段还要刻意训练自己“手写脚本不调试一次通过”的能力因为笔试环境下没有搜索引擎给你查语法。5.2 自查清单对照这个表检查你的知识盲区下面这个清单是我自己平时用来评估候选人基础水平的你也可以拿来自查。能流畅说出每一项基本概念和常用场景的笔试基本不会有太大问题如果有些项目想不起来就说明还需要补充。类别自查项掌握标记系统top/load average/iostat/vmstat/free的含义与定位方法[ ]系统硬链接与软链接、inode与block、文件系统结构[ ]系统systemd unit文件的编写与排障[ ]网络TCP三次握手四次挥手、TIME_WAIT产生原因与优化[ ]网络HTTP状态码语义、DNS解析流程、CDN概念[ ]脚本awk/sed/grep/xargs/sort/uniq组合使用[ ]脚本crontab时间语法与脚本锁[ ]数据库MySQL主从复制原理、mysqldump常用参数、慢查询排查[ ]缓存缓存穿透/击穿/雪崩的区分与解决[ ]中间件Nginx反向代理、负载均衡算法、日志格式[ ]容器Docker镜像与容器、Dockerfile编写、基础网络模式[ ]云原生Kubernetes核心组件、kubelet调用CRI到containerd的链路[ ]5.3 关于“运维已经无岗”的一点实话我不想回避这个问题。这几年的确很多声音在说运维岗在减少、运维已死但实际上准确的说法应该是“只会敲命令、只负责装系统修电脑的运维岗在减少”而“具备自动化能力、懂云原生、能写代码的运维/SRE岗位需求一直在增长”。看这套笔试题的方向也能看出来它考察的早已不是单纯的操作技能而是系统思维和工程能力。一个能读懂系统行为、能写自动化工具、能快速定位问题根因的人在任何公司都是稀缺的。哪怕AI工具再发达也只是辅助你更快地定位和修复问题真正判断“系统为什么这样表现”“这个变更有什么风险”的还是人。所以我给准备入行的朋友的建议是别被焦虑情绪带偏把基础打扎实把脚本和自动化能力练好再往上走就是云原生和可观测性领域。运维这条路的职业上限不在命令敲得多熟练而在你理解系统有多深。最后再分享一点个人体会我带了这么多年团队招过的运维新人不少发现一个规律笔试成绩好的往往不是知识面最广的而是“敢想敢写”的。遇到没见过的题他们不会空着而是会从已知的知识出发推理出合理答案。比如没记清awk的某个内置变量但能写出用cut或sed替代的方案这种能力在真实排障时太重要了。另外一个小技巧刷题时别把每个知识点孤立看待试着问自己“如果我值班时遇到这个报警我会先跑哪条命令”。把一道选择题变成一个演练场景学到的东西就不是死知识而是能直接用的求生技能。希望这篇拆解对你准备运维笔试有帮助。