前几天整理旧资料翻出一份美团2020校招运维方向的笔试题。那会儿云计算还没现在这么卷但美团笔试已经很不客气了Linux、网络、数据库、Shell脚本、监控告警一个都没落下。很多同学拿到卷子第一反应是——这哪是运维笔试分明是半个后端开发加半个网络工程师。我后来带过不少实习生发现能把这份卷子吃透的人入职后上手速度普遍快。这篇文章我就以我自己的回忆和复盘为主把当年那套题背后的考点、踩坑点和准备方法完整拆一遍想冲运维校招的同学可以直接拿来当复习地图。1. 先聊卷子2020美团运维笔试到底在考什么1.1 题型结构与分值分布我记得的版本是单选、多选、填空、简答外加一道脚本编程题。整体题量不算大但时间紧尤其是简答题需要手写命令和解释原理很多人栽在“看着都会写出来不全”上面。我当时根据自己的回忆和同行交流整理过一个大致的考点权重现在看依然有参考价值考察模块大致占比典型题目方向Linux基础与系统管理30%进程管理、文件权限、系统负载、日志清理网络基础与排障25%TCP状态、HTTP状态码、DNS解析、抓包分析数据库15%MySQL索引、事务隔离级别、慢查询Shell/Python脚本15%日志统计、批量处理、文本提取监控与常见服务10%Nginx配置、Zabbix告警、systemd服务虚拟化/容器/云原生5%Docker命令、K8s基础概念2020开始出现这个比例不是官方数据是我和几个同期参加笔试的同行拼出来的但方向基本准确。运维笔试不像算法岗那样刷题就能过它更像一份“能力扫描”题目全部指向实际工作中会遇到的场景。1.2 考点背后的业务逻辑美团2020年的业务体量已经非常大外卖、到店、酒旅等核心链路都是高并发、高时效系统。运维工程师的职责不是“管服务器”而是保障这些系统在极端流量下不崩、不慢、不丢数据。所以笔试题目会刻意把“知识点”包装成“故障场景”。比如它不会直接问“top命令有哪些参数”而是问“某台服务器负载突然升高你如何定位”不会问“TCP协议有三报文握手”而是问“压测时出现大量TIME_WAIT可能是什么原因怎么解决”。这两种问法考察的深度完全不同。这也是我给准备校招的同学的第一个建议不要背命令要去背“排查链路”。命令只是工具面试官想看的是你在一个真实故障面前能不能按照“现象—定位—处理—验证—复盘”的顺序走下去。2. 我记得的几道题从现象到原理的完整拆解2.1 CPU100%不是背命令是背排查链路有一道题大概是线上某Java服务所在服务器CPU使用率到了100%接口响应变慢请说明排查过程。这道题在当年算送分题但答得完整的人并不多。标准排查链路应该是这样的先用top找到CPU占用最高的进程PID。注意top默认按CPU排序但进程可能短暂变化建议用top -b -n 1取一次快照或者用ps -eo pid,ppid,%cpu,%mem,cmd --sort-%cpu | head拿稳态数据。拿到PID之后再用top -Hp PID查看这个进程内部的线程找出CPU占用最高的线程TID。因为JVM的线程是映射到操作系统线程的接下来需要把TID转成十六进制printf %x\n TID然后用jstack PID | grep -A 20 十六进制线程号导出线程栈看具体卡在哪个类、哪个方法。很多人的答案到这一步就停了但完整的回答还要包括后续动作如果是业务代码死循环紧急处理可以先用jstack确认线程状态再通过发布系统回滚代码如果是GC频繁导致CPU飙升需要继续查看JVM参数用jstat -gcutil PID 1000观察GC频率如果怀疑是系统资源竞争还要用strace -p PID看系统调用或者用perf top看内核热点。我当时在这道题上专门补了一句“先备份线程栈快照再处理”因为线上问题处理完很难复现快照是事后复盘的关键证据。后来我带实习生的时候也会特意强调这一点排障的第一步从来不是解决问题而是保留现场。2.2 TIME_WAIT一个连接状态能问出多少东西还有一道题考察TCP连接状态。题目大意是压测过程中客户端连接服务端发现服务端出现了大量TIME_WAIT这是什么原因如何优化。这道题能答到什么深度基本能看出一个人是“学过TCP”还是“用过TCP”。先解释原因TIME_WAIT是主动关闭连接的一方在发送最后一个ACK之后进入的状态目的是确保对端收到ACK同时让旧连接的报文段在网络中过期消失。大量TIME_WAIT意味着这个方向上存在大量短连接并且都是本地主动关闭。美团这种高并发场景下服务端访问数据库、缓存、下游服务时通常会有连接池但如果连接池配置不当或者业务代码每次请求都新建连接就会出现TIME_WAIT堆积。解决思路有几个层面应用层改用连接池复用长连接这是最根本的解法。内核参数net.ipv4.tcp_tw_reuse1可以在新连接时复用TIME_WAIT连接net.ipv4.tcp_timestamps1是reuse的前提。但我特别提醒一句tcp_tw_recycle千万别乱开它在NAT环境下会导致部分用户连接被丢弃这是生产环境踩过的大坑。系统调优调整net.ipv4.ip_local_port_range扩大可用端口范围或者降低MSLnet.ipv4.tcp_fin_timeout缩短TIME_WAIT生命周期但这只是缓解不是根治。这道题回答得好的人通常会把“为什么不能只靠内核参数一劳永逸”讲清楚。面试官想听的不是你记住了哪个参数而是你理解TIME_WAIT的成因后能判断什么场景下该用什么手段。2.3 索引失效数据库题其实在考逻辑数据库部分有一道典型的索引失效题某个表在where条件字段上建了索引但查询依然很慢考察可能的原因。这种题没有标准答案能列多少种情况体现的是实际开发经验的厚度。我通常给实习生列一份排查清单对索引列做了函数运算比如WHERE DATE(create_time) 2024-01-01这会让索引失效正确写法是范围查询create_time 2024-01-01 AND create_time 2024-01-02。隐式类型转换比如索引列是varchar查询条件写了数字MySQL可能放弃索引。联合索引没遵循最左前缀原则查询条件跳过了第一列后面的列即使有索引也用不上。使用LIKE %keyword这种前缀模糊匹配索引失效。OR条件中存在非索引列可能导致全表扫描。索引区分度太低优化器认为走索引还不如全表扫描快。这道题背后真正想考的是“你能不能在写SQL时意识到执行计划的差异”。所以回答时最好带上EXPLAIN说清楚怎么看type、key、rows这几个字段。我在笔试时甚至直接画了一个简单的表格把“索引失效可能原因”和“解决方式”对应起来这种答题方式在简答题里很讨喜因为面试官一眼就能看出你有结构化思维。2.4 日志统计Shell题的标准答案与加分项最后通常会有一道Shell或Python脚本题我印象中是Nginx日志分析给定一个access.log统计访问量前10的IP。核心答案其实就一行awk {print $1} access.log | sort | uniq -c | sort -rn | head -10但这一行代码背后有无数细节。首先为什么要用awk而不是cut -d -f1因为Nginx默认日志格式中IP后面可能有多个空格用awk更稳。其次sort | uniq -c | sort -rn的链路要理解uniq -c只能统计相邻重复行所以必须先sort最后sort -rn是按数字逆序排取出前10个。如果有余力我建议再写一句进阶版统计top10 IP各自访问了哪些URL、分别返回了多少5xx状态码。这能展示你对 “日志分析不是为了看数字而是为了发现异常” 的理解。比如awk {print $1, $7, $9} access.log | awk $3 ~ /^5/ {print $1, $2} | sort | uniq -c | sort -rn | head -10这两段代码的差别就是普通做题和工程师思维的差别。校招笔试不要求你写多高深的脚本但要求你在简单功能里体现出“考虑边界、考虑可读性、考虑实际用途”的习惯。3. 跨界的考题容器与Kubernetes开始走进运维笔试3.1 为什么2020年的卷子里会出现K8s2020年其实是个很微妙的节点。当时很多传统企业还在用虚拟机部署但互联网公司已经开始大规模K8s化。美团、阿里、腾讯都在推动容器化改造运维工程师的工作边界从“管机器”变成了“管集群”。所以笔试里开始出现Docker和Kubernetes的题目一点也不意外。当时有一类题会问“描述Kubernetes创建Pod的流程”或者更具体一点“kubernetes是如何调用containerd的”。热搜词里这两年也一直在提这个话题说明直到现在它依然是运维面试的高频问题。因为它不仅是概念题更是一道能把“看过文档的人”和“真排过障的人”区分开的问题。3.2 Kubernetes调用containerd的完整实体链路我在给团队做分享时习惯把这套链路拆成四层kubelet运行在每个Node上的代理负责管理Pod生命周期。当你执行kubectl apply之后API Server把Pod写入Etcdkubelet通过Watch机制感知到新Pod开始创建。CRIContainer Runtime Interfacekubelet不会直接喊“containerd帮我起个容器”而是通过gRPC接口以CRI的格式发出请求。CRI是Kubernetes和容器运行时之间的标准协议相当于一个翻译层。containerd收到CRI请求后负责管理镜像、容器生命周期和网络。它本身并不是直接创建容器进程的而是调用containerd-shim再由shim拉起runc。runc真正和内核打交道的东西。runc根据OCI规范通过clone、namespace、cgroup等系统调用创建容器进程并设置资源限制。所以完整链路是kubelet - CRIgRPC- containerd - containerd-shim - runc - Linux内核。其中还有一个容易被忽略的细节每个Pod里会先启动一个 pause 容器用来持有网络命名空间和PID命名空间其他业务容器共享pause容器的namespace这样才能实现Pod内网络互通。这道题面试官想考察什么不是让你背下来这条链路就完了而是你在遇到“Pod一直ContainerCreating”的时候能根据链路逐层排查。比如kubectl describe pod看到错误去查kubelet日志kubelet日志里报无法连接containerd就去查containerd service状态containerd正常但runc起不来去看节点内核版本和权限配置。这才是链路知识真正值钱的地方。我在2020年参加笔试时对容器这块只能说出大概后来在实际生产环境踩过几次坑才真正把这条链路刻在脑子里。3.3 这类题的正确打开方式如果现在让我重新回答“kubernetes如何调用containerd”我会这样组织答案先讲CRI存在的意义再讲组件边界最后用一次真实排障经历收尾。为什么这么组织因为面试官问的是“如何调用”但你回答的重点应该是“中间有哪些角色各自负责什么出问题时怎么切分责任”。我见过很多同学在准备容器题目时花大量时间背YAML里每个字段的含义结果被问到底层调用就卡壳。其实校招阶段不需要你懂容器运行时的全部源码但至少要知道GRPC、CRI、OCI这些边界概念因为这是后续学习的基础。哪怕只是清楚“containerd和docker不再是同一个东西”就已经领先很多人了。这一部分给准备者的建议不要只学Kubernetes操作一定要花时间亲手装一次一主两从集群然后手动把节点上的containerd停掉看Pod会发生什么再重新拉起观察自愈过程。这比任何教程都有用。4. 手上的功夫考场答题的时间分配与工程思维4.1 命令题怎么写才不丢分笔试题里的命令题最怕的不是不会而是“写得太薄”。比如题目问“如何查看服务器负载”很多人只写一个uptime得不了满分。正确姿势是把uptime、top、cat /proc/loadavg、vmstat 1组合起来说明这几条命令分别能看到什么。举个例子如果题目问“如何排查磁盘空间不足”我的参考答案是df -h # 看每个文件系统的使用率 du -sh /var/log/* # 找大目录 du -sh /var/lib/docker/* # 如果是容器节点看docker目录 lsof | grep deleted # 查被删但仍被进程占用的文件最后一步特别关键很多人df -h发现磁盘满了但du找不到大文件就是因为有进程打开了已删除的文件空间一直被占用杀掉进程才能释放。这个经验不实际踩坑很难想到写在卷子上就很加分。还有一类命令题需要写“保存”和“生效”。比如让配置iptables规则不能只写iptables -A INPUT -p tcp --dport 80 -j ACCEPT还得写service iptables save或iptables-save /etc/sysconfig/iptables否则重启就丢了。这种细节很琐碎但恰恰是运维工程师和只会敲命令的人的区别。4.2 脚本题别只看结果脚本题通常有多个测试用例但判卷人更看重解题思路。我批过校招的笔试题发现一个普遍问题很多人脚本写得很长但逻辑混乱变量命名是a、b、c连注释都没有。建议在笔试时把脚本写出“能跑且能维护”的水准。比如前面提到的日志统计题可以分两步写先定义日志路径变量再写主命令最后加一句注释说明输出格式。不要太长但要让人一眼看懂你在干什么。如果时间允许可以额外写一个判断文件是否存在的保护逻辑LOG_FILE/var/log/nginx/access.log if [ ! -f $LOG_FILE ]; then echo log file not found exit 1 fi awk {print $1} $LOG_FILE | sort | uniq -c | sort -rn | head -10这段代码虽然多了几行但体现的工程意识非常直接脚本不是一次性玩具它会跑在生产环境里必须考虑输入异常。阅卷人看到这些通常会在心里给你加一分。4.3 不会的题怎么“蒙”才体面笔试遇到不会的题很正常尤其是复合型的简答题。我当年的策略是即使不知道标准答案也要把“我如果遇到这个问题会从哪几个方向查”写出来。比如遇到一道关于监控告警的题你忘了具体某个指标怎么看可以写第一步确认告警级别和影响范围第二步登录机器看CPU、内存、磁盘、网络四个基础指标第三步结合最近变更记录判断是否有发布或配置改动第四步回滚或扩容并持续观察。这个过程虽然不涉及具体命令但是确认了你的排障框架。面试官对“有框架但缺少细节”的人宽容度远高于“毫无思路”的人。另外时间分配上我建议先做有把握的题最后再做开放题。因为开放题很容易写嗨写到最后反而没时间回来做基础题了。我当时给自己定的规矩是客观题30分钟简答题70分钟脚本题20分钟。留出最后10分钟检查尤其是命令拼写和参数格式。5. 从这份卷子往后看运维校招的准备路线5.1 三个月复习路线校招笔试准备最怕“东一榔头西一棒子”。结合美团2020年这份卷子我给后来人总结了一条三个月的复习路线按周拆解第一个月Linux基础命令、文件系统、权限管理、用户管理、systemd网络基础TCP/IP、HTTP、DNS。每天至少花两个小时实际操作不要只看书。第二个月Shell脚本变量、条件、循环、awk、sed、grep、MySQL索引、事务、慢查询、Nginx基础配置。开始刷网上的运维笔试真题整理错题。第三个月监控系统Zabbix/Prometheus、容器与K8s基础、模拟排障。重点练“从现象到命令到结论”的完整表达。每月末给自己来一次模拟笔试按真实考试时间掐表。没有真实题就用网上能找到的“运维工程师面试题”把它当成笔试来做不能光看答案。5.2 必须亲手敲一遍的命令清单这里列一份我在团队里给新人的最低要求清单。每个命令不要只敲--help要真的构造场景去用命令必须会的场景top / htop定位CPU和内存占用最高的进程vmstat / iostat看系统瓶颈在CPU、IO还是内存ps / pstree查进程父子关系、僵尸进程netstat / ss查端口监听、连接状态统计lsof查某个文件被哪个进程占用find / xargs找大文件、批量操作tar / gzip打包解压、保留权限grep / sed / awk日志过滤、提取、统计curl带header请求接口看状态码和耗时tcpdump抓包分析TCP握手和重传systemctl管理服务、查服务状态和日志docker / crictl查容器状态、日志和容器内进程不要贪多把这些命令练到“不假思索”的程度。因为笔试现场没有搜索引擎也没有人让你慢慢试。5.3 错题本的正确用法我见过很多同学准备笔试时题目刷了一大堆但还是反复在同一个知识点上出错。原因很简单只对答案不写原因。我的做法是准备一个Markdown文档每道错题记录四件事题目考的知识点、我当时的答案、正确答案、错误原因。错误原因一定要写具体比如“不知道awk默认按空格分隔”和“没考虑重复行需要先排序”而不是简单写“记错了”。错题本要定期回看尤其考前一周不要刷新题只看错题本。把每一道错题当成一个“故障”先不翻答案自己像做题一样重新推一遍流程推不出来再回去翻笔记。这种方法比背题有效得多因为你是在训练“再次遇到类似场景时的大脑路径”而不是在训练短期记忆。我当时靠这份错题本把TIME_WAIT、索引失效、K8s调用链路这几个高频问题彻底弄明白了。后来带实习生时也让他们用同样的方法效果普遍很好。美团这份卷子其实不是故意难为人它只是把运维工程师日常要面对的问题提前放到了考卷上。你准备得越像一次真实排障考场上就越稳。
美团2020运维校招笔试复盘：Linux、网络、数据库与K8s考点全解析
前几天整理旧资料翻出一份美团2020校招运维方向的笔试题。那会儿云计算还没现在这么卷但美团笔试已经很不客气了Linux、网络、数据库、Shell脚本、监控告警一个都没落下。很多同学拿到卷子第一反应是——这哪是运维笔试分明是半个后端开发加半个网络工程师。我后来带过不少实习生发现能把这份卷子吃透的人入职后上手速度普遍快。这篇文章我就以我自己的回忆和复盘为主把当年那套题背后的考点、踩坑点和准备方法完整拆一遍想冲运维校招的同学可以直接拿来当复习地图。1. 先聊卷子2020美团运维笔试到底在考什么1.1 题型结构与分值分布我记得的版本是单选、多选、填空、简答外加一道脚本编程题。整体题量不算大但时间紧尤其是简答题需要手写命令和解释原理很多人栽在“看着都会写出来不全”上面。我当时根据自己的回忆和同行交流整理过一个大致的考点权重现在看依然有参考价值考察模块大致占比典型题目方向Linux基础与系统管理30%进程管理、文件权限、系统负载、日志清理网络基础与排障25%TCP状态、HTTP状态码、DNS解析、抓包分析数据库15%MySQL索引、事务隔离级别、慢查询Shell/Python脚本15%日志统计、批量处理、文本提取监控与常见服务10%Nginx配置、Zabbix告警、systemd服务虚拟化/容器/云原生5%Docker命令、K8s基础概念2020开始出现这个比例不是官方数据是我和几个同期参加笔试的同行拼出来的但方向基本准确。运维笔试不像算法岗那样刷题就能过它更像一份“能力扫描”题目全部指向实际工作中会遇到的场景。1.2 考点背后的业务逻辑美团2020年的业务体量已经非常大外卖、到店、酒旅等核心链路都是高并发、高时效系统。运维工程师的职责不是“管服务器”而是保障这些系统在极端流量下不崩、不慢、不丢数据。所以笔试题目会刻意把“知识点”包装成“故障场景”。比如它不会直接问“top命令有哪些参数”而是问“某台服务器负载突然升高你如何定位”不会问“TCP协议有三报文握手”而是问“压测时出现大量TIME_WAIT可能是什么原因怎么解决”。这两种问法考察的深度完全不同。这也是我给准备校招的同学的第一个建议不要背命令要去背“排查链路”。命令只是工具面试官想看的是你在一个真实故障面前能不能按照“现象—定位—处理—验证—复盘”的顺序走下去。2. 我记得的几道题从现象到原理的完整拆解2.1 CPU100%不是背命令是背排查链路有一道题大概是线上某Java服务所在服务器CPU使用率到了100%接口响应变慢请说明排查过程。这道题在当年算送分题但答得完整的人并不多。标准排查链路应该是这样的先用top找到CPU占用最高的进程PID。注意top默认按CPU排序但进程可能短暂变化建议用top -b -n 1取一次快照或者用ps -eo pid,ppid,%cpu,%mem,cmd --sort-%cpu | head拿稳态数据。拿到PID之后再用top -Hp PID查看这个进程内部的线程找出CPU占用最高的线程TID。因为JVM的线程是映射到操作系统线程的接下来需要把TID转成十六进制printf %x\n TID然后用jstack PID | grep -A 20 十六进制线程号导出线程栈看具体卡在哪个类、哪个方法。很多人的答案到这一步就停了但完整的回答还要包括后续动作如果是业务代码死循环紧急处理可以先用jstack确认线程状态再通过发布系统回滚代码如果是GC频繁导致CPU飙升需要继续查看JVM参数用jstat -gcutil PID 1000观察GC频率如果怀疑是系统资源竞争还要用strace -p PID看系统调用或者用perf top看内核热点。我当时在这道题上专门补了一句“先备份线程栈快照再处理”因为线上问题处理完很难复现快照是事后复盘的关键证据。后来我带实习生的时候也会特意强调这一点排障的第一步从来不是解决问题而是保留现场。2.2 TIME_WAIT一个连接状态能问出多少东西还有一道题考察TCP连接状态。题目大意是压测过程中客户端连接服务端发现服务端出现了大量TIME_WAIT这是什么原因如何优化。这道题能答到什么深度基本能看出一个人是“学过TCP”还是“用过TCP”。先解释原因TIME_WAIT是主动关闭连接的一方在发送最后一个ACK之后进入的状态目的是确保对端收到ACK同时让旧连接的报文段在网络中过期消失。大量TIME_WAIT意味着这个方向上存在大量短连接并且都是本地主动关闭。美团这种高并发场景下服务端访问数据库、缓存、下游服务时通常会有连接池但如果连接池配置不当或者业务代码每次请求都新建连接就会出现TIME_WAIT堆积。解决思路有几个层面应用层改用连接池复用长连接这是最根本的解法。内核参数net.ipv4.tcp_tw_reuse1可以在新连接时复用TIME_WAIT连接net.ipv4.tcp_timestamps1是reuse的前提。但我特别提醒一句tcp_tw_recycle千万别乱开它在NAT环境下会导致部分用户连接被丢弃这是生产环境踩过的大坑。系统调优调整net.ipv4.ip_local_port_range扩大可用端口范围或者降低MSLnet.ipv4.tcp_fin_timeout缩短TIME_WAIT生命周期但这只是缓解不是根治。这道题回答得好的人通常会把“为什么不能只靠内核参数一劳永逸”讲清楚。面试官想听的不是你记住了哪个参数而是你理解TIME_WAIT的成因后能判断什么场景下该用什么手段。2.3 索引失效数据库题其实在考逻辑数据库部分有一道典型的索引失效题某个表在where条件字段上建了索引但查询依然很慢考察可能的原因。这种题没有标准答案能列多少种情况体现的是实际开发经验的厚度。我通常给实习生列一份排查清单对索引列做了函数运算比如WHERE DATE(create_time) 2024-01-01这会让索引失效正确写法是范围查询create_time 2024-01-01 AND create_time 2024-01-02。隐式类型转换比如索引列是varchar查询条件写了数字MySQL可能放弃索引。联合索引没遵循最左前缀原则查询条件跳过了第一列后面的列即使有索引也用不上。使用LIKE %keyword这种前缀模糊匹配索引失效。OR条件中存在非索引列可能导致全表扫描。索引区分度太低优化器认为走索引还不如全表扫描快。这道题背后真正想考的是“你能不能在写SQL时意识到执行计划的差异”。所以回答时最好带上EXPLAIN说清楚怎么看type、key、rows这几个字段。我在笔试时甚至直接画了一个简单的表格把“索引失效可能原因”和“解决方式”对应起来这种答题方式在简答题里很讨喜因为面试官一眼就能看出你有结构化思维。2.4 日志统计Shell题的标准答案与加分项最后通常会有一道Shell或Python脚本题我印象中是Nginx日志分析给定一个access.log统计访问量前10的IP。核心答案其实就一行awk {print $1} access.log | sort | uniq -c | sort -rn | head -10但这一行代码背后有无数细节。首先为什么要用awk而不是cut -d -f1因为Nginx默认日志格式中IP后面可能有多个空格用awk更稳。其次sort | uniq -c | sort -rn的链路要理解uniq -c只能统计相邻重复行所以必须先sort最后sort -rn是按数字逆序排取出前10个。如果有余力我建议再写一句进阶版统计top10 IP各自访问了哪些URL、分别返回了多少5xx状态码。这能展示你对 “日志分析不是为了看数字而是为了发现异常” 的理解。比如awk {print $1, $7, $9} access.log | awk $3 ~ /^5/ {print $1, $2} | sort | uniq -c | sort -rn | head -10这两段代码的差别就是普通做题和工程师思维的差别。校招笔试不要求你写多高深的脚本但要求你在简单功能里体现出“考虑边界、考虑可读性、考虑实际用途”的习惯。3. 跨界的考题容器与Kubernetes开始走进运维笔试3.1 为什么2020年的卷子里会出现K8s2020年其实是个很微妙的节点。当时很多传统企业还在用虚拟机部署但互联网公司已经开始大规模K8s化。美团、阿里、腾讯都在推动容器化改造运维工程师的工作边界从“管机器”变成了“管集群”。所以笔试里开始出现Docker和Kubernetes的题目一点也不意外。当时有一类题会问“描述Kubernetes创建Pod的流程”或者更具体一点“kubernetes是如何调用containerd的”。热搜词里这两年也一直在提这个话题说明直到现在它依然是运维面试的高频问题。因为它不仅是概念题更是一道能把“看过文档的人”和“真排过障的人”区分开的问题。3.2 Kubernetes调用containerd的完整实体链路我在给团队做分享时习惯把这套链路拆成四层kubelet运行在每个Node上的代理负责管理Pod生命周期。当你执行kubectl apply之后API Server把Pod写入Etcdkubelet通过Watch机制感知到新Pod开始创建。CRIContainer Runtime Interfacekubelet不会直接喊“containerd帮我起个容器”而是通过gRPC接口以CRI的格式发出请求。CRI是Kubernetes和容器运行时之间的标准协议相当于一个翻译层。containerd收到CRI请求后负责管理镜像、容器生命周期和网络。它本身并不是直接创建容器进程的而是调用containerd-shim再由shim拉起runc。runc真正和内核打交道的东西。runc根据OCI规范通过clone、namespace、cgroup等系统调用创建容器进程并设置资源限制。所以完整链路是kubelet - CRIgRPC- containerd - containerd-shim - runc - Linux内核。其中还有一个容易被忽略的细节每个Pod里会先启动一个 pause 容器用来持有网络命名空间和PID命名空间其他业务容器共享pause容器的namespace这样才能实现Pod内网络互通。这道题面试官想考察什么不是让你背下来这条链路就完了而是你在遇到“Pod一直ContainerCreating”的时候能根据链路逐层排查。比如kubectl describe pod看到错误去查kubelet日志kubelet日志里报无法连接containerd就去查containerd service状态containerd正常但runc起不来去看节点内核版本和权限配置。这才是链路知识真正值钱的地方。我在2020年参加笔试时对容器这块只能说出大概后来在实际生产环境踩过几次坑才真正把这条链路刻在脑子里。3.3 这类题的正确打开方式如果现在让我重新回答“kubernetes如何调用containerd”我会这样组织答案先讲CRI存在的意义再讲组件边界最后用一次真实排障经历收尾。为什么这么组织因为面试官问的是“如何调用”但你回答的重点应该是“中间有哪些角色各自负责什么出问题时怎么切分责任”。我见过很多同学在准备容器题目时花大量时间背YAML里每个字段的含义结果被问到底层调用就卡壳。其实校招阶段不需要你懂容器运行时的全部源码但至少要知道GRPC、CRI、OCI这些边界概念因为这是后续学习的基础。哪怕只是清楚“containerd和docker不再是同一个东西”就已经领先很多人了。这一部分给准备者的建议不要只学Kubernetes操作一定要花时间亲手装一次一主两从集群然后手动把节点上的containerd停掉看Pod会发生什么再重新拉起观察自愈过程。这比任何教程都有用。4. 手上的功夫考场答题的时间分配与工程思维4.1 命令题怎么写才不丢分笔试题里的命令题最怕的不是不会而是“写得太薄”。比如题目问“如何查看服务器负载”很多人只写一个uptime得不了满分。正确姿势是把uptime、top、cat /proc/loadavg、vmstat 1组合起来说明这几条命令分别能看到什么。举个例子如果题目问“如何排查磁盘空间不足”我的参考答案是df -h # 看每个文件系统的使用率 du -sh /var/log/* # 找大目录 du -sh /var/lib/docker/* # 如果是容器节点看docker目录 lsof | grep deleted # 查被删但仍被进程占用的文件最后一步特别关键很多人df -h发现磁盘满了但du找不到大文件就是因为有进程打开了已删除的文件空间一直被占用杀掉进程才能释放。这个经验不实际踩坑很难想到写在卷子上就很加分。还有一类命令题需要写“保存”和“生效”。比如让配置iptables规则不能只写iptables -A INPUT -p tcp --dport 80 -j ACCEPT还得写service iptables save或iptables-save /etc/sysconfig/iptables否则重启就丢了。这种细节很琐碎但恰恰是运维工程师和只会敲命令的人的区别。4.2 脚本题别只看结果脚本题通常有多个测试用例但判卷人更看重解题思路。我批过校招的笔试题发现一个普遍问题很多人脚本写得很长但逻辑混乱变量命名是a、b、c连注释都没有。建议在笔试时把脚本写出“能跑且能维护”的水准。比如前面提到的日志统计题可以分两步写先定义日志路径变量再写主命令最后加一句注释说明输出格式。不要太长但要让人一眼看懂你在干什么。如果时间允许可以额外写一个判断文件是否存在的保护逻辑LOG_FILE/var/log/nginx/access.log if [ ! -f $LOG_FILE ]; then echo log file not found exit 1 fi awk {print $1} $LOG_FILE | sort | uniq -c | sort -rn | head -10这段代码虽然多了几行但体现的工程意识非常直接脚本不是一次性玩具它会跑在生产环境里必须考虑输入异常。阅卷人看到这些通常会在心里给你加一分。4.3 不会的题怎么“蒙”才体面笔试遇到不会的题很正常尤其是复合型的简答题。我当年的策略是即使不知道标准答案也要把“我如果遇到这个问题会从哪几个方向查”写出来。比如遇到一道关于监控告警的题你忘了具体某个指标怎么看可以写第一步确认告警级别和影响范围第二步登录机器看CPU、内存、磁盘、网络四个基础指标第三步结合最近变更记录判断是否有发布或配置改动第四步回滚或扩容并持续观察。这个过程虽然不涉及具体命令但是确认了你的排障框架。面试官对“有框架但缺少细节”的人宽容度远高于“毫无思路”的人。另外时间分配上我建议先做有把握的题最后再做开放题。因为开放题很容易写嗨写到最后反而没时间回来做基础题了。我当时给自己定的规矩是客观题30分钟简答题70分钟脚本题20分钟。留出最后10分钟检查尤其是命令拼写和参数格式。5. 从这份卷子往后看运维校招的准备路线5.1 三个月复习路线校招笔试准备最怕“东一榔头西一棒子”。结合美团2020年这份卷子我给后来人总结了一条三个月的复习路线按周拆解第一个月Linux基础命令、文件系统、权限管理、用户管理、systemd网络基础TCP/IP、HTTP、DNS。每天至少花两个小时实际操作不要只看书。第二个月Shell脚本变量、条件、循环、awk、sed、grep、MySQL索引、事务、慢查询、Nginx基础配置。开始刷网上的运维笔试真题整理错题。第三个月监控系统Zabbix/Prometheus、容器与K8s基础、模拟排障。重点练“从现象到命令到结论”的完整表达。每月末给自己来一次模拟笔试按真实考试时间掐表。没有真实题就用网上能找到的“运维工程师面试题”把它当成笔试来做不能光看答案。5.2 必须亲手敲一遍的命令清单这里列一份我在团队里给新人的最低要求清单。每个命令不要只敲--help要真的构造场景去用命令必须会的场景top / htop定位CPU和内存占用最高的进程vmstat / iostat看系统瓶颈在CPU、IO还是内存ps / pstree查进程父子关系、僵尸进程netstat / ss查端口监听、连接状态统计lsof查某个文件被哪个进程占用find / xargs找大文件、批量操作tar / gzip打包解压、保留权限grep / sed / awk日志过滤、提取、统计curl带header请求接口看状态码和耗时tcpdump抓包分析TCP握手和重传systemctl管理服务、查服务状态和日志docker / crictl查容器状态、日志和容器内进程不要贪多把这些命令练到“不假思索”的程度。因为笔试现场没有搜索引擎也没有人让你慢慢试。5.3 错题本的正确用法我见过很多同学准备笔试时题目刷了一大堆但还是反复在同一个知识点上出错。原因很简单只对答案不写原因。我的做法是准备一个Markdown文档每道错题记录四件事题目考的知识点、我当时的答案、正确答案、错误原因。错误原因一定要写具体比如“不知道awk默认按空格分隔”和“没考虑重复行需要先排序”而不是简单写“记错了”。错题本要定期回看尤其考前一周不要刷新题只看错题本。把每一道错题当成一个“故障”先不翻答案自己像做题一样重新推一遍流程推不出来再回去翻笔记。这种方法比背题有效得多因为你是在训练“再次遇到类似场景时的大脑路径”而不是在训练短期记忆。我当时靠这份错题本把TIME_WAIT、索引失效、K8s调用链路这几个高频问题彻底弄明白了。后来带实习生时也让他们用同样的方法效果普遍很好。美团这份卷子其实不是故意难为人它只是把运维工程师日常要面对的问题提前放到了考卷上。你准备得越像一次真实排障考场上就越稳。