1. 从一份校招笔试卷看运维工程师的真实能力画像每年的秋招季总有不少同学在后台问我同一个问题运维岗笔试到底考什么是不是就背背Linux命令、看看网络基础就能过说实话我当年也有过这种天真想法。直到自己实际参加过几场大厂校招笔试又作为面试官参与过几次校招面试之后才真正意识到运维工程师的笔试不是考察你会不会背命令而是在用一套精心设计的题目快速筛选出那些真正理解系统、理解网络、理解业务架构的人。尤其在网易这种级别的公司2018年的校招运维笔试卷几乎可以看作行业的风向标——它不追求偏题怪题而是把运维日常工作中的核心场景压缩进一两个小时考察你的工程素养和问题排查思维。这篇文章不打算逐题复现当年的试卷毕竟题目版权在那里我能做的是把运维笔试中反复出现的核心考点、常见的题型思路、以及我最近几年从事运维工作后回头看这套笔试题的复盘心得尽量完整地给你拆开讲透。文中的所有结论和案例都来自我实际带过的校招生、我参与过的面试题库评审以及我自己踩过的坑。不管你是正在准备校招的应届生还是打算转行运维的开发者这篇文章都能帮你把复习方向理清楚。先给一个总体的结论大厂运维笔试的考察权重大概遵循Linux基础 30%、网络 20%、脚本编程 20%、数据库与中间件 15%、云计算与容器 10%、其他软技能 5%这个比例。下面我按这个顺序逐块拆解每块都会给出典型的出题形式和答题思路。2. Linux基础题看似送分实则暗藏杀机的方向Linux操作系统是运维工程师的生存工具笔试中这块内容占比最高但经常出现的情况是你觉得都会分数出来却不高。为什么因为Linux基础题太容易出细节了而细节恰恰是区分背过命令和真正用过系统的分水岭。2.1 文件系统与常用命令考察的是组合能力单纯的ls、cd、cp、mv这种命令背诵在笔试里基本不会出现出题人真正想看的是你能不能在限定条件下用命令完成任务。比如这类经典题有一个日志文件access.log需要找出访问量排名前10的IP地址并输出到top10.txt中。这道题看起来平平无奇但考察点至少有三个awk的字段切割、sort的排序与去重、uniq -c的统计逻辑。我见过太多人写出来的答案是用一层层管道硬凑但完全没有考虑到sort -rn和uniq -c配合时的坑。正确的解题思路是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10 top10.txt这里有一个非常隐蔽的考点为什么要在uniq -c前先sort因为uniq只能去除连续重复的行如果IP出现的位置不连续uniq -c会输出多行统计结果导致最终的结果完全错误。这个细节没有实际处理过日志的人很难注意到。我在面试中遇到过不少候选人前面聊得挺好一追问这个为什么立刻露馅。另一个高频方向是磁盘与inode相关的排查题。笔试会给一个场景服务器提示No space left on device但df -h显示还有空间剩余问你怎么处理。这个题目其实是在考察你知不知道df -h和df -i的区别以及你是否接触过inode耗尽的问题。答案很简单用df -ih查看inode使用率找到满的那个分区然后排查是否有大量小文件堆积。但就是这么简单的一个问题当时的笔试正确率不到四成因为很多人在简历上写了熟悉Linux实际上连df有哪些参数都没仔细看过。2.2 权限管理不止是chmod 777权限类题目也是笔试的常客但考察方式往往很刁钻。直接考chmod 755什么意思太简单了大厂会换个角度一个文件权限为-rwsr-xr-x请问这个s代表什么如果将这个文件的所有者改为root会发生什么这道题考的是setuid位。运维工作中passwd命令、sudo命令都涉及setuid的机制如果你只停留在chmod 777的层面这道题基本只能靠蒙。答案是s代表setuid位表示执行该文件时进程的有效用户ID被临时设置为文件所有者的用户ID。将所有者改为root后任何用户执行该文件时都以root权限运行这也是很多系统漏洞的根源。另一个容易被忽略的点是umask。笔试常给一个场景系统umask为027新建一个文件权限默认是多少很多人直接回答644忽略了umask对文件和目录的不同影响文件默认权限是666减去umask目录是777减去umask。0666 - 0027 0640所以新建文件的权限是640而不是644。这个细节在工作中影响极大特别是你写脚本去创建配置文件时默认权限一旦过宽就可能在安全审计时被单独拎出来点名。2.3 进程管理与系统负载排查思路比命令本身更重要进程管理相关的题目笔试中通常不会直接问kill和kill -9有什么区别这种低水平问题而是给你一个故障场景让你描述排查流程。比如某台服务器CPU使用率100%负载持续升高但通过top查看时CPU占用最高的进程却一直在变化可能是什么原因下一步你会怎么做这道题考察两个层次第一你是否知道top查看的是瞬时状态进程变化快说明可能有进程在频繁fork子进程第二你是否掌握了pidstat、ps -ef --forest、pstree等命令的组合用法能否顺着进程树找到真正的根进程。我记得当时笔试后和几个同学对答案不少人的回答只有一句kill掉占用最高的进程这个答案如果放到生产环境不仅解决不了问题还可能误杀关键进程导致业务中断。我还想提一类题给出free -h和top的部分输出问这个系统的内存是否不足很多人的第一反应是看free列是不是接近0。但实际上Linux对内存的使用策略是能用则用大量内存被用作文缓存(page cache)是正常现象真正需要关注的是available列的值。如果available已经很低同时swap的使用率在持续增长才说明系统确实存在内存压力。笔试中这类题考察的就是你有没有真实经历过内存告警还是只背过概念。3. 网络与协议考点这五类题答不上来基本没戏网络是运维工程师的另一条腿。不同于网络工程师需要深入理解路由交换原理运维岗的网络笔试更聚焦在应用层的连通性排查和常见协议的工作机制上。但这个聚焦并不代表简单反而因为贴近日常工作出题人可以把问题挖得很深。3.1 TCP三次握手与故障排查的经典结合三次握手几乎是每个岗位笔试都会涉及的基础题但运维笔试不会让你默写三次握手的流程而是这样问客户端连接服务器超时如何通过抓包定位是哪一步出了问题或者服务器的TCP连接队列溢出通常会出现什么现象如何确认这两个问题都是真实的线上故障。第一个问题的排查思路是在客户端和服务端分别抓包观察SYN包是否有响应如果SYN包发出后没有SYN-ACK返回大概率是中间网络问题或服务器的iptables规则丢弃了包如果SYN-ACK发出但客户端没有回ACK则可能客户端侧有连接数限制或者网络问题。第二个问题考察的是半连接队列和全连接队列的概念服务端出现大量SYN_RECV状态或accept队列溢出时客户端表现是连接超时或延迟很高这时候可以通过ss -lnt查看Send-Q是否积压来确认。你看这些内容在教科书里就是三次握手的过程五段话但到了运维笔试里变成了一个完整的排障链路。复习的时候如果只是背概念而不去实际抓包看几次遇到这种题很难答得系统。3.2 HTTP状态码别只记404HTTP协议是Web运维的基础笔试中对于状态码的考察通常会混合在场景题里。比如用户在浏览器访问一个页面返回200但页面内容显示不全可能是什么原因或者反向代理返回502你会从哪些方面排查第一个问题可能的原因包括响应被截断如负载均衡的buffer配置不当、页面引用了部分加载失败的静态资源、服务端返回了部分内容后连接中断。第二个问题502 Bad Gateway通常意味着反向代理无法从上游服务器获得有效响应排查顺序是先确认上游服务进程是否存活再确认上游服务的监听端口是否正确接着确认代理配置中的超时时间是否过短最后看上游服务的错误日志。这种题没有标准答案但题考察的是你的排查逻辑是否有条理能不能把代理层-应用层之间的链条理清楚。还有一个容易被忽略的考点是Location头。笔试常给一个302跳转的响应让你判断跳转地址是什么前缀的协议。大多数人看到302就下意识认为是HTTP跳转但如果header里Location写的是https://这就意味着它实际是一个HTTPS的重定向。运维在处理混合协议场景时如果忽略这个字段写的重定向规则会一直不生效。3.3 DNS、负载均衡和HTTP的深层链路题大厂笔试最喜欢出的综合性题目长这样用户反馈访问某个域名很慢从浏览器到服务器整个链路有哪些环节可能造成这个现象如何一步步定位这道题考察的是对整个访问链路的全局认识大致包括DNS解析包括递归解析和缓存、TCP建连包括三次握手和TLS握手、反向代理转发、应用服务器处理、数据库查询、响应返回、浏览器渲染等环节。真正完整的答案是针对每个环节给出对应的排查命令和指标比如dig看解析耗时、curl -w看各阶段耗时、ss看连接队列、top看应用负载、慢查询日志看数据库问题。这种综合题没有标准答案得分完全取决于你的知识面是否成体系。我当时笔试能通过一个很重要的原因是平时习惯把用户访问慢当作一个链条来理解而不是单纯的是不是服务器性能不行。这个习惯也让后面实际工作时受益很多很多看起来玄学的线上问题最后都是沿着链路一层层往下查找到根因的。4. 脚本编程与自动化校招笔试里的硬通货运维工程师的日常一半时间在处理故障另一半时间在写脚本消灭重复劳动。笔试题对脚本编程的考察往往不是让你从零写一个复杂程序而是考察你能否用最简洁有效的方式处理数据、文本和日志。Shell和Python是两大出题方向Shell更多考察文本处理和系统命令的组合能力Python则更倾向逻辑和类库的使用。4.1 文本处理三剑客grep、sed、awk的典型考察姿势关于文本处理的题目我印象最深的一道是有一个文本文件每行格式为时间 IP 状态码 响应时间要求输出所有状态码为500的记录中响应时间大于3秒的行。答案是awk $3500 $43 {print} access.log看起来简单但笔试中经常有人把awk的分隔符、字段编号搞错或者忘记awk中字符串和数字之间的隐式转换可能带来的问题。如果你用$3500而不是$3500在awk中会因为类型不同而无法匹配。这是一个非常实用的细节真的线上排查日志时如果写错你会得到一个空的结果然后误判为没有慢请求。sed的考点则集中在替换、删除和行区间操作。比如将配置文件中的所有注释行删除、将第10行到第20行之间的#开头的行注释去掉这类题。正常情况下sed -i /^#/d就能删除注释行但如果配置文件里既有左边缩进的注释又有末尾的注释往往还需要配合正则细化。考察的核心是正则表达式的熟练度以及sed的p、d、s、c四种常用命令在什么场景下选哪个。4.2 Linux运维常用命令大全笔试的隐形考察点很多同学复习时会去背Linux常用命令大全但笔试真正考察的往往是你面对具体场景时能不能想到合适的命令组合。以日常文件处理为例考察频率极高的是找出指定目录下最大的前10个文件、统计日志中某种错误出现的次数、批量重命名、批量替换配置文件中的某个参数等。我建议每个准备笔试的同学都自己动手做一套运维命令速查表不是那种网上抄来的大全而是针对你实际用过的场景做分类记录。比如我自己整理的文件排查、进程排查、网络排查、性能排查四类速查表在笔试前复习一遍比翻书效率高得多。笔试题最后的开放题往往就是让考生描述一次线上故障的处理过程如果你脑中有一张清晰的排查命令地图写出来的答案自然比别人有条理。4.3 Python脚本题的常见套路和踩坑Python在运维笔试中的地位逐年上升。笔试中的Python题通常不考算法而是考实际的数据处理和系统交互。常见出题方式包括读取一个日志文件统计IP出现次数并排序输出调用shell命令获取服务器磁盘、内存等信息格式化为JSON输出遍历目录找到所有大于指定大小的文件并删除。这些任务用Python写起来并不难但笔试时间有限很多人会在细节上丢分。第一个坑是忘记处理文件编码日志文件经常不是UTF-8读之前先open指定编码第二个坑是系统命令的结果是bytes类型直接当字符串处理会导致判断失败第三个坑是路径处理时没有用os.path.join而是手动拼接字符串在跨平台场景下很容易出问题。这些都是我在批改校招笔试时反复见到的错误你自己平时练习时也要养成写健壮代码的习惯。5. 数据库与中间件笔试中拉开差距的分水岭数据库和中间件在运维笔试中的占比不低而且是区分只懂服务器和懂业务架构的关键板块。一个优秀的运维工程师不仅要保证数据库实例正常运行还要能在业务量增长时给出合理的容量评估和性能优化建议。5.1 MySQL索引与SQL基础都是必考课MySQL相关的笔试题目基本不会直接让你写增删改查而是围绕索引、优化、事务这三块做文章。比如有一个user表数据量500万行查询select * from user where age25 and city北京发现每次查询都很慢如何优化这类题考察的是首先是否知道用explain查看执行计划其次是否理解联合索引最左前缀原则在此基础上给出建议对(city, age)建立联合索引还是把city放前面的查询频率更高最后是覆盖索引的优化如果只需要id和name字段尽量使用select id, name而不是select *避免回表。我看过不少答案纠结点全在用哪个索引上却忽略了加索引前先explain这个前置步骤。在笔试中你的答题顺序能直观体现出你的工程习惯。5.2 Redis、缓存一致性、幂等性场景题越来越多随着互联网业务对高并发的需求越来越大缓存几乎是每个运维笔试的必考项。Redis的考察重点通常在缓存穿透、缓存击穿、缓存雪崩三兄弟的区别和解决方案以及缓存与数据库的一致性如何保证。我还记得有一道题特别有意思秒杀场景下缓存中的库存数量如何扣减才能保证不超卖很多人的第一反应是用Redis的decr命令然后补充在数据库事务中再扣减一次。但真正的问题在于如果扣减库存后业务逻辑执行失败需要回滚缓存这时候如何保证缓存与数据库的最终一致这题没有唯一答案但至少有三种靠谱的思路事务消息、延迟双删、binlog订阅同步。笔试考这种题表面考Redis命令实际考你面对分布式系统时有没有一致性意识。5.3 Nginx从配置题到原理题的跨越Nginx作为Web服务器和反向代理在笔试中出现的频率很高。低阶题目是写一个Nginx配置将/api/开头的请求转发到后端服务高阶题目会问Nginx的worker_processes和worker_connections如何配置为什么一个进程能处理成千上万个并发连接前者做对不难后者就涉及事件驱动模型和epoll的原理了。当年笔试中有一道让我印象深刻的题在高并发场景下Nginx返回大量502但后端服务的CPU和内存都正常最可能的原因是什么答案是后端服务的进程数或最大连接数限制被耗尽Nginx无法建立新的连接。如果你只看过Nginx的配置模板而没理解upstream的并发限制机制这道题基本无从下手。6. Docker/Kubernetes与云原生2018年笔试卷中的前瞻性布局现在看2018年校招笔试试卷很多人觉得考Docker和K8s很超前。但实际上那一年国内大厂的生产环境已经在大规模落地容器化运维工程师的岗位要求里明确写着熟悉容器技术者优先。这一方向在试卷中的分值虽然不高但它承担着筛选对这行有热情且有技术敏感度候选人的任务。6.1 Docker基础题镜像与容器的生命周期Docker的考点集中在镜像和容器的关系、容器和虚拟机的区别、常用命令以及Dockerfile的编写规范。笔试题中常见的是一道Dockerfile排错题给一个写好的Dockerfile让你找出其中至少三个不合理的地方。这类题考察的点很细比如是否用了COPY而非ADDADD有隐式的自动解压和远程URL拉取行为容易引发安全风险是否在镜像中留存了不必要的构建依赖是否以非root用户运行应用是否指定了精确的基础镜像版本而不是latest。我当年就是在latest标签这个点上丢了一分事后回顾才发现生产环境用latest标签会导致镜像不可复现这是大忌。Kubernetes的考察则更偏向概念理解比如Pod与容器的关系、Deployment与StatefulSet的适用场景、Service的几种类型区别、以及kubectl常用操作。有一道题让我记忆犹新是要你解释如果Kubernetes集群中的一个Pod频繁重启你会从哪些方面排查。答案是看kubectl describe pod的事件信息、看Pod的日志结合退出码判断、检查资源限制是否导致OOM被kill、检查探针配置是否合理尤其是liveness探针误判导致容器被反复重启的情况。6.2 云计算运维的新考题方向虽然2018年的试卷以传统运维为主但已经出现了少量云平台相关的题目比如如何评估一个云上应用的高可用架构对象存储与传统文件系统的区别等。这类题目不需要你背某个云厂商的具体产品而是考察你对分布式架构的理解比如无状态应用可以水平扩展、有状态应用需要持久化存储和主从同步、数据备份与容灾要遵循两地三中心的冗余逻辑。到了今天云计算和容器化已经是大规模普及的状态。即使你复习的是多年前的笔试卷我也建议你在掌握传统运维知识的基础上重点补一下Kubernetes的核心概念、云平台的基础产品和监控体系比如Prometheus和Grafana的组合。这些内容在校招笔试中出现的比重只会越来越大提前准备不吃亏。6.3 从kubernetes调用containerd看考察趋势近几年有一个比较新的考点方向值得提一下Kubernetes是如何调用containerd的。这道题反映了大厂笔试正在从你会不会用转向你理不理解内部机制。简单来说kubelet通过CRIContainer Runtime Interface与containerd通信kubelet作为CRI客户端containerd作为CRI服务端通过containerd内置的cri插件实现containerd再通过runC或其它OCI运行时创建和运行容器。整个调用链是kubelet - CRI - containerd - OCI - runC。这类题目在笔试卷中出现说明出题人希望筛选出不只是背命令而是愿意深入源码和原理的工程师。如果你能熟练描述这条链路并解释为什么需要CRI这一层抽象在面试里绝对是一个加分项。7. 从笔试到面试校招备战的策略与复盘心得笔试通过只是第一步但笔试的备战过程会直接影响你在面试中的表现。很多面试题就是从笔试题目演变而来的面试官会拿着你笔试时的答案追问细节和为什么。所以备战校招笔试和面试应该当成一个整体来准备而不是分两个割裂的阶段。7.1 做题顺序与时间分配这两年份血的教训我记得自己在参加笔试时最怕的是前面的大量选择题耗费了太多时间导致后面的命令题和排障题没有时间写。实际上大厂笔试试卷的分数分布通常是选择题占大头、命令题和简答/场景题各占一部分。选择题的答案是客观的能做就做举棋不定的题先标记跳过把时间留给后面的场景题——因为场景题只要写出合理的排查思路就能得分而选择题完全靠记忆蒙对的概率并不高。另一个建议是对于场景题先列提纲再写答案。比如一道线上故障排查题先在草稿纸上写1、先看监控2、确认影响范围3、逐层排查网络、系统、应用4、定位根因5、恢复与复盘然后每一点再展开一两句话。这样写出来的答案逻辑清晰得分的概率远远高于想到什么写什么。7.2 收集整理属于自己的运维手册备考期间我建议你开始建立自己的知识库把网上分散的内容整合成自己的运维手册。内容可以包括Linux常用命令按场景分类的记录、常见报错和解决方法的截图、常用的排查命令模板CPU高、内存不足、磁盘满、端口不通、连接超时、以及Shell或Python脚本的常用片段。自己动手整理一遍和单纯看别人的总结效果完全不同。整理的过程其实就是主动回忆的过程你在复习时做过的每一道题、排过的每一个假想故障都能变成你面试时随口说出的案例。包括前面提到的运维工具箱、uos运维工具、网络运维工具等你可以逐个尝试找到自己顺手的几款把它们写进你的工具链记录里。7.3 经验与体会最后分享一点我最真实的体会运维笔试考的不是一个点而是一张网。它把Linux、网络、脚本、数据库、容器这些知识点交织在一起模拟的是生产环境中你从一条告警发现一个可疑线索然后顺藤摸瓜定位到另一个服务的问题这种真实工作状态。所以刷题时不要满足于这道题我会每次做完可以问自己三个问题这道题的考点在真实工作中对应什么场景如果数据规模再大一倍答案还成立吗如果这个故障在半夜两点发生我的处理步骤和时间线是什么这三个问题想清楚了你准备的就不仅仅是一份笔试而是这份运维工作的基本功。
大厂运维校招笔试核心考点与备战策略解析
1. 从一份校招笔试卷看运维工程师的真实能力画像每年的秋招季总有不少同学在后台问我同一个问题运维岗笔试到底考什么是不是就背背Linux命令、看看网络基础就能过说实话我当年也有过这种天真想法。直到自己实际参加过几场大厂校招笔试又作为面试官参与过几次校招面试之后才真正意识到运维工程师的笔试不是考察你会不会背命令而是在用一套精心设计的题目快速筛选出那些真正理解系统、理解网络、理解业务架构的人。尤其在网易这种级别的公司2018年的校招运维笔试卷几乎可以看作行业的风向标——它不追求偏题怪题而是把运维日常工作中的核心场景压缩进一两个小时考察你的工程素养和问题排查思维。这篇文章不打算逐题复现当年的试卷毕竟题目版权在那里我能做的是把运维笔试中反复出现的核心考点、常见的题型思路、以及我最近几年从事运维工作后回头看这套笔试题的复盘心得尽量完整地给你拆开讲透。文中的所有结论和案例都来自我实际带过的校招生、我参与过的面试题库评审以及我自己踩过的坑。不管你是正在准备校招的应届生还是打算转行运维的开发者这篇文章都能帮你把复习方向理清楚。先给一个总体的结论大厂运维笔试的考察权重大概遵循Linux基础 30%、网络 20%、脚本编程 20%、数据库与中间件 15%、云计算与容器 10%、其他软技能 5%这个比例。下面我按这个顺序逐块拆解每块都会给出典型的出题形式和答题思路。2. Linux基础题看似送分实则暗藏杀机的方向Linux操作系统是运维工程师的生存工具笔试中这块内容占比最高但经常出现的情况是你觉得都会分数出来却不高。为什么因为Linux基础题太容易出细节了而细节恰恰是区分背过命令和真正用过系统的分水岭。2.1 文件系统与常用命令考察的是组合能力单纯的ls、cd、cp、mv这种命令背诵在笔试里基本不会出现出题人真正想看的是你能不能在限定条件下用命令完成任务。比如这类经典题有一个日志文件access.log需要找出访问量排名前10的IP地址并输出到top10.txt中。这道题看起来平平无奇但考察点至少有三个awk的字段切割、sort的排序与去重、uniq -c的统计逻辑。我见过太多人写出来的答案是用一层层管道硬凑但完全没有考虑到sort -rn和uniq -c配合时的坑。正确的解题思路是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10 top10.txt这里有一个非常隐蔽的考点为什么要在uniq -c前先sort因为uniq只能去除连续重复的行如果IP出现的位置不连续uniq -c会输出多行统计结果导致最终的结果完全错误。这个细节没有实际处理过日志的人很难注意到。我在面试中遇到过不少候选人前面聊得挺好一追问这个为什么立刻露馅。另一个高频方向是磁盘与inode相关的排查题。笔试会给一个场景服务器提示No space left on device但df -h显示还有空间剩余问你怎么处理。这个题目其实是在考察你知不知道df -h和df -i的区别以及你是否接触过inode耗尽的问题。答案很简单用df -ih查看inode使用率找到满的那个分区然后排查是否有大量小文件堆积。但就是这么简单的一个问题当时的笔试正确率不到四成因为很多人在简历上写了熟悉Linux实际上连df有哪些参数都没仔细看过。2.2 权限管理不止是chmod 777权限类题目也是笔试的常客但考察方式往往很刁钻。直接考chmod 755什么意思太简单了大厂会换个角度一个文件权限为-rwsr-xr-x请问这个s代表什么如果将这个文件的所有者改为root会发生什么这道题考的是setuid位。运维工作中passwd命令、sudo命令都涉及setuid的机制如果你只停留在chmod 777的层面这道题基本只能靠蒙。答案是s代表setuid位表示执行该文件时进程的有效用户ID被临时设置为文件所有者的用户ID。将所有者改为root后任何用户执行该文件时都以root权限运行这也是很多系统漏洞的根源。另一个容易被忽略的点是umask。笔试常给一个场景系统umask为027新建一个文件权限默认是多少很多人直接回答644忽略了umask对文件和目录的不同影响文件默认权限是666减去umask目录是777减去umask。0666 - 0027 0640所以新建文件的权限是640而不是644。这个细节在工作中影响极大特别是你写脚本去创建配置文件时默认权限一旦过宽就可能在安全审计时被单独拎出来点名。2.3 进程管理与系统负载排查思路比命令本身更重要进程管理相关的题目笔试中通常不会直接问kill和kill -9有什么区别这种低水平问题而是给你一个故障场景让你描述排查流程。比如某台服务器CPU使用率100%负载持续升高但通过top查看时CPU占用最高的进程却一直在变化可能是什么原因下一步你会怎么做这道题考察两个层次第一你是否知道top查看的是瞬时状态进程变化快说明可能有进程在频繁fork子进程第二你是否掌握了pidstat、ps -ef --forest、pstree等命令的组合用法能否顺着进程树找到真正的根进程。我记得当时笔试后和几个同学对答案不少人的回答只有一句kill掉占用最高的进程这个答案如果放到生产环境不仅解决不了问题还可能误杀关键进程导致业务中断。我还想提一类题给出free -h和top的部分输出问这个系统的内存是否不足很多人的第一反应是看free列是不是接近0。但实际上Linux对内存的使用策略是能用则用大量内存被用作文缓存(page cache)是正常现象真正需要关注的是available列的值。如果available已经很低同时swap的使用率在持续增长才说明系统确实存在内存压力。笔试中这类题考察的就是你有没有真实经历过内存告警还是只背过概念。3. 网络与协议考点这五类题答不上来基本没戏网络是运维工程师的另一条腿。不同于网络工程师需要深入理解路由交换原理运维岗的网络笔试更聚焦在应用层的连通性排查和常见协议的工作机制上。但这个聚焦并不代表简单反而因为贴近日常工作出题人可以把问题挖得很深。3.1 TCP三次握手与故障排查的经典结合三次握手几乎是每个岗位笔试都会涉及的基础题但运维笔试不会让你默写三次握手的流程而是这样问客户端连接服务器超时如何通过抓包定位是哪一步出了问题或者服务器的TCP连接队列溢出通常会出现什么现象如何确认这两个问题都是真实的线上故障。第一个问题的排查思路是在客户端和服务端分别抓包观察SYN包是否有响应如果SYN包发出后没有SYN-ACK返回大概率是中间网络问题或服务器的iptables规则丢弃了包如果SYN-ACK发出但客户端没有回ACK则可能客户端侧有连接数限制或者网络问题。第二个问题考察的是半连接队列和全连接队列的概念服务端出现大量SYN_RECV状态或accept队列溢出时客户端表现是连接超时或延迟很高这时候可以通过ss -lnt查看Send-Q是否积压来确认。你看这些内容在教科书里就是三次握手的过程五段话但到了运维笔试里变成了一个完整的排障链路。复习的时候如果只是背概念而不去实际抓包看几次遇到这种题很难答得系统。3.2 HTTP状态码别只记404HTTP协议是Web运维的基础笔试中对于状态码的考察通常会混合在场景题里。比如用户在浏览器访问一个页面返回200但页面内容显示不全可能是什么原因或者反向代理返回502你会从哪些方面排查第一个问题可能的原因包括响应被截断如负载均衡的buffer配置不当、页面引用了部分加载失败的静态资源、服务端返回了部分内容后连接中断。第二个问题502 Bad Gateway通常意味着反向代理无法从上游服务器获得有效响应排查顺序是先确认上游服务进程是否存活再确认上游服务的监听端口是否正确接着确认代理配置中的超时时间是否过短最后看上游服务的错误日志。这种题没有标准答案但题考察的是你的排查逻辑是否有条理能不能把代理层-应用层之间的链条理清楚。还有一个容易被忽略的考点是Location头。笔试常给一个302跳转的响应让你判断跳转地址是什么前缀的协议。大多数人看到302就下意识认为是HTTP跳转但如果header里Location写的是https://这就意味着它实际是一个HTTPS的重定向。运维在处理混合协议场景时如果忽略这个字段写的重定向规则会一直不生效。3.3 DNS、负载均衡和HTTP的深层链路题大厂笔试最喜欢出的综合性题目长这样用户反馈访问某个域名很慢从浏览器到服务器整个链路有哪些环节可能造成这个现象如何一步步定位这道题考察的是对整个访问链路的全局认识大致包括DNS解析包括递归解析和缓存、TCP建连包括三次握手和TLS握手、反向代理转发、应用服务器处理、数据库查询、响应返回、浏览器渲染等环节。真正完整的答案是针对每个环节给出对应的排查命令和指标比如dig看解析耗时、curl -w看各阶段耗时、ss看连接队列、top看应用负载、慢查询日志看数据库问题。这种综合题没有标准答案得分完全取决于你的知识面是否成体系。我当时笔试能通过一个很重要的原因是平时习惯把用户访问慢当作一个链条来理解而不是单纯的是不是服务器性能不行。这个习惯也让后面实际工作时受益很多很多看起来玄学的线上问题最后都是沿着链路一层层往下查找到根因的。4. 脚本编程与自动化校招笔试里的硬通货运维工程师的日常一半时间在处理故障另一半时间在写脚本消灭重复劳动。笔试题对脚本编程的考察往往不是让你从零写一个复杂程序而是考察你能否用最简洁有效的方式处理数据、文本和日志。Shell和Python是两大出题方向Shell更多考察文本处理和系统命令的组合能力Python则更倾向逻辑和类库的使用。4.1 文本处理三剑客grep、sed、awk的典型考察姿势关于文本处理的题目我印象最深的一道是有一个文本文件每行格式为时间 IP 状态码 响应时间要求输出所有状态码为500的记录中响应时间大于3秒的行。答案是awk $3500 $43 {print} access.log看起来简单但笔试中经常有人把awk的分隔符、字段编号搞错或者忘记awk中字符串和数字之间的隐式转换可能带来的问题。如果你用$3500而不是$3500在awk中会因为类型不同而无法匹配。这是一个非常实用的细节真的线上排查日志时如果写错你会得到一个空的结果然后误判为没有慢请求。sed的考点则集中在替换、删除和行区间操作。比如将配置文件中的所有注释行删除、将第10行到第20行之间的#开头的行注释去掉这类题。正常情况下sed -i /^#/d就能删除注释行但如果配置文件里既有左边缩进的注释又有末尾的注释往往还需要配合正则细化。考察的核心是正则表达式的熟练度以及sed的p、d、s、c四种常用命令在什么场景下选哪个。4.2 Linux运维常用命令大全笔试的隐形考察点很多同学复习时会去背Linux常用命令大全但笔试真正考察的往往是你面对具体场景时能不能想到合适的命令组合。以日常文件处理为例考察频率极高的是找出指定目录下最大的前10个文件、统计日志中某种错误出现的次数、批量重命名、批量替换配置文件中的某个参数等。我建议每个准备笔试的同学都自己动手做一套运维命令速查表不是那种网上抄来的大全而是针对你实际用过的场景做分类记录。比如我自己整理的文件排查、进程排查、网络排查、性能排查四类速查表在笔试前复习一遍比翻书效率高得多。笔试题最后的开放题往往就是让考生描述一次线上故障的处理过程如果你脑中有一张清晰的排查命令地图写出来的答案自然比别人有条理。4.3 Python脚本题的常见套路和踩坑Python在运维笔试中的地位逐年上升。笔试中的Python题通常不考算法而是考实际的数据处理和系统交互。常见出题方式包括读取一个日志文件统计IP出现次数并排序输出调用shell命令获取服务器磁盘、内存等信息格式化为JSON输出遍历目录找到所有大于指定大小的文件并删除。这些任务用Python写起来并不难但笔试时间有限很多人会在细节上丢分。第一个坑是忘记处理文件编码日志文件经常不是UTF-8读之前先open指定编码第二个坑是系统命令的结果是bytes类型直接当字符串处理会导致判断失败第三个坑是路径处理时没有用os.path.join而是手动拼接字符串在跨平台场景下很容易出问题。这些都是我在批改校招笔试时反复见到的错误你自己平时练习时也要养成写健壮代码的习惯。5. 数据库与中间件笔试中拉开差距的分水岭数据库和中间件在运维笔试中的占比不低而且是区分只懂服务器和懂业务架构的关键板块。一个优秀的运维工程师不仅要保证数据库实例正常运行还要能在业务量增长时给出合理的容量评估和性能优化建议。5.1 MySQL索引与SQL基础都是必考课MySQL相关的笔试题目基本不会直接让你写增删改查而是围绕索引、优化、事务这三块做文章。比如有一个user表数据量500万行查询select * from user where age25 and city北京发现每次查询都很慢如何优化这类题考察的是首先是否知道用explain查看执行计划其次是否理解联合索引最左前缀原则在此基础上给出建议对(city, age)建立联合索引还是把city放前面的查询频率更高最后是覆盖索引的优化如果只需要id和name字段尽量使用select id, name而不是select *避免回表。我看过不少答案纠结点全在用哪个索引上却忽略了加索引前先explain这个前置步骤。在笔试中你的答题顺序能直观体现出你的工程习惯。5.2 Redis、缓存一致性、幂等性场景题越来越多随着互联网业务对高并发的需求越来越大缓存几乎是每个运维笔试的必考项。Redis的考察重点通常在缓存穿透、缓存击穿、缓存雪崩三兄弟的区别和解决方案以及缓存与数据库的一致性如何保证。我还记得有一道题特别有意思秒杀场景下缓存中的库存数量如何扣减才能保证不超卖很多人的第一反应是用Redis的decr命令然后补充在数据库事务中再扣减一次。但真正的问题在于如果扣减库存后业务逻辑执行失败需要回滚缓存这时候如何保证缓存与数据库的最终一致这题没有唯一答案但至少有三种靠谱的思路事务消息、延迟双删、binlog订阅同步。笔试考这种题表面考Redis命令实际考你面对分布式系统时有没有一致性意识。5.3 Nginx从配置题到原理题的跨越Nginx作为Web服务器和反向代理在笔试中出现的频率很高。低阶题目是写一个Nginx配置将/api/开头的请求转发到后端服务高阶题目会问Nginx的worker_processes和worker_connections如何配置为什么一个进程能处理成千上万个并发连接前者做对不难后者就涉及事件驱动模型和epoll的原理了。当年笔试中有一道让我印象深刻的题在高并发场景下Nginx返回大量502但后端服务的CPU和内存都正常最可能的原因是什么答案是后端服务的进程数或最大连接数限制被耗尽Nginx无法建立新的连接。如果你只看过Nginx的配置模板而没理解upstream的并发限制机制这道题基本无从下手。6. Docker/Kubernetes与云原生2018年笔试卷中的前瞻性布局现在看2018年校招笔试试卷很多人觉得考Docker和K8s很超前。但实际上那一年国内大厂的生产环境已经在大规模落地容器化运维工程师的岗位要求里明确写着熟悉容器技术者优先。这一方向在试卷中的分值虽然不高但它承担着筛选对这行有热情且有技术敏感度候选人的任务。6.1 Docker基础题镜像与容器的生命周期Docker的考点集中在镜像和容器的关系、容器和虚拟机的区别、常用命令以及Dockerfile的编写规范。笔试题中常见的是一道Dockerfile排错题给一个写好的Dockerfile让你找出其中至少三个不合理的地方。这类题考察的点很细比如是否用了COPY而非ADDADD有隐式的自动解压和远程URL拉取行为容易引发安全风险是否在镜像中留存了不必要的构建依赖是否以非root用户运行应用是否指定了精确的基础镜像版本而不是latest。我当年就是在latest标签这个点上丢了一分事后回顾才发现生产环境用latest标签会导致镜像不可复现这是大忌。Kubernetes的考察则更偏向概念理解比如Pod与容器的关系、Deployment与StatefulSet的适用场景、Service的几种类型区别、以及kubectl常用操作。有一道题让我记忆犹新是要你解释如果Kubernetes集群中的一个Pod频繁重启你会从哪些方面排查。答案是看kubectl describe pod的事件信息、看Pod的日志结合退出码判断、检查资源限制是否导致OOM被kill、检查探针配置是否合理尤其是liveness探针误判导致容器被反复重启的情况。6.2 云计算运维的新考题方向虽然2018年的试卷以传统运维为主但已经出现了少量云平台相关的题目比如如何评估一个云上应用的高可用架构对象存储与传统文件系统的区别等。这类题目不需要你背某个云厂商的具体产品而是考察你对分布式架构的理解比如无状态应用可以水平扩展、有状态应用需要持久化存储和主从同步、数据备份与容灾要遵循两地三中心的冗余逻辑。到了今天云计算和容器化已经是大规模普及的状态。即使你复习的是多年前的笔试卷我也建议你在掌握传统运维知识的基础上重点补一下Kubernetes的核心概念、云平台的基础产品和监控体系比如Prometheus和Grafana的组合。这些内容在校招笔试中出现的比重只会越来越大提前准备不吃亏。6.3 从kubernetes调用containerd看考察趋势近几年有一个比较新的考点方向值得提一下Kubernetes是如何调用containerd的。这道题反映了大厂笔试正在从你会不会用转向你理不理解内部机制。简单来说kubelet通过CRIContainer Runtime Interface与containerd通信kubelet作为CRI客户端containerd作为CRI服务端通过containerd内置的cri插件实现containerd再通过runC或其它OCI运行时创建和运行容器。整个调用链是kubelet - CRI - containerd - OCI - runC。这类题目在笔试卷中出现说明出题人希望筛选出不只是背命令而是愿意深入源码和原理的工程师。如果你能熟练描述这条链路并解释为什么需要CRI这一层抽象在面试里绝对是一个加分项。7. 从笔试到面试校招备战的策略与复盘心得笔试通过只是第一步但笔试的备战过程会直接影响你在面试中的表现。很多面试题就是从笔试题目演变而来的面试官会拿着你笔试时的答案追问细节和为什么。所以备战校招笔试和面试应该当成一个整体来准备而不是分两个割裂的阶段。7.1 做题顺序与时间分配这两年份血的教训我记得自己在参加笔试时最怕的是前面的大量选择题耗费了太多时间导致后面的命令题和排障题没有时间写。实际上大厂笔试试卷的分数分布通常是选择题占大头、命令题和简答/场景题各占一部分。选择题的答案是客观的能做就做举棋不定的题先标记跳过把时间留给后面的场景题——因为场景题只要写出合理的排查思路就能得分而选择题完全靠记忆蒙对的概率并不高。另一个建议是对于场景题先列提纲再写答案。比如一道线上故障排查题先在草稿纸上写1、先看监控2、确认影响范围3、逐层排查网络、系统、应用4、定位根因5、恢复与复盘然后每一点再展开一两句话。这样写出来的答案逻辑清晰得分的概率远远高于想到什么写什么。7.2 收集整理属于自己的运维手册备考期间我建议你开始建立自己的知识库把网上分散的内容整合成自己的运维手册。内容可以包括Linux常用命令按场景分类的记录、常见报错和解决方法的截图、常用的排查命令模板CPU高、内存不足、磁盘满、端口不通、连接超时、以及Shell或Python脚本的常用片段。自己动手整理一遍和单纯看别人的总结效果完全不同。整理的过程其实就是主动回忆的过程你在复习时做过的每一道题、排过的每一个假想故障都能变成你面试时随口说出的案例。包括前面提到的运维工具箱、uos运维工具、网络运维工具等你可以逐个尝试找到自己顺手的几款把它们写进你的工具链记录里。7.3 经验与体会最后分享一点我最真实的体会运维笔试考的不是一个点而是一张网。它把Linux、网络、脚本、数据库、容器这些知识点交织在一起模拟的是生产环境中你从一条告警发现一个可疑线索然后顺藤摸瓜定位到另一个服务的问题这种真实工作状态。所以刷题时不要满足于这道题我会每次做完可以问自己三个问题这道题的考点在真实工作中对应什么场景如果数据规模再大一倍答案还成立吗如果这个故障在半夜两点发生我的处理步骤和时间线是什么这三个问题想清楚了你准备的就不仅仅是一份笔试而是这份运维工作的基本功。
