又是一年秋招季后台收到不少私信问大厂运维笔试怎么准备。翻出我当年复盘的美团2017秋招运维工程师B卷这套题虽然过去有些年头了但里面的考察思路放到现在依然很能打。特别是B卷偏重实践能力不像A卷那样大篇幅考理论它更像是在模拟一个运维工程师真实会遇到的场景。今天就把我记得的题目类型和做过的深度拆解分享出来给准备冲头部互联网公司运维岗的朋友一个参考。这套卷子给我的整体印象是不考死记硬背考的是你有没有真正在服务器上折腾过。如果你只是背了《Linux就该这么学》的目录或者刷过几套题库很多细节题会做得特别难受。但反过来如果你平时遇到报错会去strace追一下、写脚本会考虑异常处理、看监控会想告警阈值为什么这么设这套卷子反而会觉得“有话说”。所以与其说它是笔试不如说是一场“运维思维”的体检。1. 美团B卷考察逻辑从题目倒推运维工程师的能力模型1.1 当年B卷的整体结构与侧重点先说整体结构。B卷大概由三类题型组成单选多选混合的基础知识题约30分、命令产出及代码阅读题约30分、以及综合场景分析题约40分。总分100分考试时间90分钟题量不算特别大但陷阱多做起来非常赶。选择题的范围很广从/proc文件系统到TCP三次握手从MySQL索引失效到Docker数据卷几乎覆盖了日常运维的各个角落。简答题和编程题则集中考察Linux常用命令、Python脚本能力、网络故障定位思路。最后的场景题算重头戏通常是给一个线上事故描述让你写出排查过程和解决方案。这比单纯问“查看端口用什么命令”高了好几个维度它考察的是你有没有完整的排查框架。当年我做完的感受是**美团要的不是“命令机器人”而是有工程化意识的运维开发者。**这一倾向在B卷里表现得很明显——所有考点都带着“线上可能出现的问题”这个前缀。1.2 美团运维岗位画像他们要的不是“会敲命令”的人为什么这么设计因为美团的业务特点决定了它的运维岗位必须贴近业务、拥抱自动化。外卖订单峰值极高一台两台服务器出问题不算事但整个集群的调度、降级、容灾必须在几分钟内完成。这种场景下只会手动敲命令的运维根本无法应对——你需要写脚本批量处理需要理解服务依赖需要从监控数据里提前发现隐患。所以B卷中无论考awk还是考strace都不是为了考命令本身而是在看你的“运维思维”看到一个问题你能不能快速定位到根本原因能不能用最合适的工具去验证能不能把临时的解决办法自动化成长效机制我当时在备考笔记里写过一句话“美团笔试考的不是你知道多少命令而是在网络分层、进程调度、系统调用、数据一致性这些底层概念之上你能否搭建出一套可复用的排查逻辑。”这句话到现在依然成立。2. 真题模块详解Linux基础与Python脚本的拿分点2.1 Linux高频考点进程管理、文件系统、性能命令B卷的Linux部分没有出偏题怪题都是运维日常里的高频操作但提问方式很刁钻。比如我记得有几道题是这样的“查看某进程打开的文件的命令是如何根据端口号反查进程PID”答案核心是lsof -i:端口或ss -lntp。但很多人会答netstat -lntp这不算错可美团的考点在于如果你在容器里执行netstat往往没有这个命令而ss来自iproute2几乎在所有基础镜像里都预装了。所以遇到这类问题最好两个都能写注明不同工具的适用场景。“如何判断系统是否存在僵死进程如何清理父进程为1的僵尸”这道题考察ps -ef状态列里的Z状态以及kill无法直接清理僵尸进程的本质——僵尸是子进程结束后父进程未调用wait()导致的内核只保留其进程描述符。所以回答时一定要先讲原因再提“除了重启父进程外很难主动清理”这才符合实际。“磁盘满了但df -h显示没满怎么排查”这算是文件系统经典题。答案涉及inode耗尽、已删除文件被进程占用、挂载点覆盖等。df -i看inodelsof | grep deleted找残留文件句柄。这道题的价值在于考察你是否遇到过“看似没满却写不进数据”的真实场景。还有一类命令组合题比如“统计Nginx访问日志中访问量TOP10的IP”这个既可以用awk加sort加uniq加head也可以用Python一行式。B卷里往往要求你写出完整命令我建议练习时直接在服务器上跑一遍别只在纸上写。2.2 Python脚本题从“写脚本”到“写工程”美团B卷的Python题不会让你实现红黑树而是给一个真实的运维小需求。我记得有一道题大致是写一个Python脚本每分钟检查某服务的HTTP状态码若大于等于500则调用接口告警并记录日志。这题看着简单但想拿满分不容易。笔试时很多人只写了核心循环但高分答案通常要包括用requests库但设置了timeout避免网络异常导致脚本卡死。捕获异常并区分“连接失败”和“状态码错误”。日志记录带时间戳、目标URL、状态码、异常信息。支持命令行参数如通过argparse传入URL和检查间隔而不是写死常量。考虑脚本本身崩溃怎么办比如简单使用while True加time.sleep或者用supervisor守护。从这些角度写代码哪怕核心逻辑稍微简化也能向面试官表达一件事你写的不是一次性的临时脚本而是可维护的运维工具。我当年答题时还特意在代码注释里写了“通过退出码区分异常类型方便外部系统识别”这属于锦上添花但也确实能让答案更亮眼。Python题还有一个常考点文件处理。比如“读取一个几GB的日志文件统计包含某个关键字的行数”考察点是用with open()迭代而非readlines()避免内存溢出。这个知识点不复杂但能筛选出真正处理过较大文件的人。3. 网络与系统排查实战题答题顺序和诊断思路3.1 一个经典的“网络故障排查”大题现象、层次、工具美团B卷的最后大题里有一道非常典型的网络问题用户反馈App加载很慢打开图片要等很久请写出排查思路。这种题没有标准答案但你的答题结构本身就是评分点。我总结过一套“顺序排查法”在笔试和面试里都很好用第一步明确现象范围是所有用户慢还是部分地区慢是Wi-Fi慢还是4G慢这个信息决定了从哪个方向下手。 第二步客户端到服务端的链路逐步判断客户端DNS解析是否异常dig或nslookup看解析耗时。TCP连接建立耗时curl -w输出time_connect等指标。服务端响应速度time_to_first_byte如果TTFB高问题多半不在网络而在应用或数据库。中间链路丢包或延迟mtr或traceroute看每一跳。服务端负载top、free、df排除资源瓶颈。同时看接入层Nginx访问日志的upstream_response_time。答题时如果能写出每一步用什么工具、预期结果、下一步分支判断基本就是高分模板。例如curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n URL这个命令一行就能定位HTTP时延分布笔试时写出来会显得你很专业。注意很多人会一上来就ping但如果目标服务禁Ping或者中间有负载均衡做转发ping的结果并不能代表真实业务质量。所以答题时要把ping的局限性也点出来这能让评卷人觉得你有实战经验。3.2 从tcpdump到traceroute笔试中最实用的命令组合B卷选择题里有一类题是给网络现象选工具比如“怀疑服务器被恶意扫描端口”选tcpdump抓包还是选netstat查看连接实际上前者看实时包后者看连接表两个可能需要配合使用。还有一道题是解释tcpdump -i eth0 tcp port 80 -w capture.pcap的作用。我见过的答案里很多人漏了-i指定接口导致在有多网卡的服务器上抓错包也有人忽略-w是保存原始数据包而不是直接打印信息。抓包后当然还要用Wireshark或tshark分析但笔试通常只要求写出命令和含义。这类的终极题是“线上出现大量TIME_WAIT连接如何排查和优化”这题既是网络题也是系统调优题。正确思路是用ss -s看连接状态统计确认TIME_WAIT数量。用ss -ant state time-wait dport :80或netstat -ant | grep TIME_WAIT | wc -l量化。结合业务判断短连接过多、代理层不启用持久连接都会导致TIME_WAIT堆积。优化方向开启net.ipv4.tcp_tw_reuse需要配合tcp_timestamps、调整tcp_max_tw_buckets但更重要的是在应用层改用长连接或者连接池。我当年笔试时还加了一句“TIME_WAIT并不是洪水猛兽它主要是为了可靠地关闭连接所以优化前要先看是否存在端口耗尽或连接失败的问题”这一句真的能体现思维的成熟度。4. 监控与架构思维题当笔试考的不是命令而是方案4.1 监控系统设计题如果让你为美团外卖设计监控你会怎么做B卷的场景题中有一道开放设计题大意是为美团外卖的核心链路设计监控方案包括监控指标、监控手段和告警策略。这类题很多运维会懵因为它不是“填空”而是考察全局视角。我的答题框架是分三层业务层订单量、支付成功率、出餐时长、骑手平均配送时长。核心是“这个数字跌了用户会明显感知”。应用层接口的QPS、P99延迟、错误率依赖方用户服务、商家服务、支付回调的超时和熔断状态。系统层每台机器的CPU、内存、磁盘、网络JVM的GC时间DB的慢查询数、连接池使用率。监控手段不能只说“用Prometheus/Grafana”要说清楚指标的采集方式业务指标通常通过代码埋点暴露到端点再由Prometheus拉取应用日志用ELK做聚合分析系统指标交给node_exporter采集。告警策略要强调“避免告警风暴”。比如不设置简单阈值而是采用动态基线把告警级别拆成P0/P1/P2P0只给最核心的链路告警必须带“当前影响、排查入口”让人拿到告警就能开始处理。这道题其实没有完美答案但答题时能体现出“从用户感知出发搭建监控”的思路就能和单纯罗列监控软件的人拉开差距。4.2 容量评估与高可用方案运维不只是“救火”B卷还有一道让人印象深刻的题某业务平时QPS 5000双十一大促预计涨到8万你是运维怎么保证系统不挂这题考察容量估算和扩容策略。我的答法分四步第一步做压力测试。先在测试环境用ab或wrk压测单机极限QPS假设单机能扛2000 QPS那么8万QPS至少需要40台应用实例再加上20%~30%的弹性冗余目标扩容到50台。第二步拆分瓶颈。QPS高了数据库一般会先扛不住。要么增加只读副本分担读流量要么引入Redis缓存。当时的答案是先看缓存命中率把热点数据尽量挡在缓存后面。第三步依赖治理。梳理核心链路上有哪些外部依赖提前做降级和限流预案。比如把非关键服务如积分、消息通知做降级保证订单主流程可用。第四步压测验证和预案演练。扩容不是“加机器”那么简单还要考虑负载均衡配置、连接池上限、MySQLmax_connections是否够用。回答里如果能加入“提前把扩容脚本写好通过API创建云主机并自动加入集群”会非常加分因为这体现了运维的自动化能力。5. 高频易错题复盘这些细节让多数候选人丢分5.1 看似简单却容易掉坑的选择题B卷的选择题里藏着不少“文字游戏”我挑几道复盘一下“下面哪个命令可以查看系统CPU使用率多选”top、vmstat、uptime都可以但很多人漏了uptime因为它只显示平均负载不能直接显示CPU使用率。但是平均负载是考量CPU的重要指标所以需要理解它们的区别。这类题考察对不同命令输出的深层理解。“修改/etc/crontab文件后是否需要重启cron服务”答案是不需要因为cron会定期读取配置文件。但有人会选“需要重启”说明没真正配置过定时任务。“crontab -e和vi /etc/crontab有什么区别”前者是当前用户的计划任务后者是系统计划任务且格式上需要指定执行用户。这题初中级运维特别容易混。“MySQL中select count(*)在大表上很慢能用什么办法优化”这题不考加索引因为count(*)统计行数很难走索引优化。正确思路是从“信息价值”出发如果只要近似值可以用show table status里的rows字段如果要精确值建议用独立的计数器表或者Redis记录。很多人在上面写explain其实切不中要点。“Docker容器和宿主机如何共享文件两种方式”答案是-v挂载卷和Dockerfile里的COPY指令。这题太基础但依然有人答非所问。我复盘这些题时发现丢分原因从来不是“不知道命令”而是“只知道命令不知道原理”。所以复习时别只记命令的写法务必理解输出里的每一个字段、命令背后的内核行为。5.2 面试官评卷时最反感的回答模式根据我后来看到的点评方向评卷人非常不喜欢三类回答第一类是“只见树木不见森林”。比如问“服务器负载高怎么排查”有人直接写top查看CPU却不说先看负载均值、再区分CPU高还是IO等待高更高级的还要用pidstat或perf看具体进程和调用栈。如果只写一个top只能说明你背过命令。第二类是“只给答案不给备份方案”。比如问“Nginx 502怎么处理”如果只写“重启Nginx”或“重启PHP-FPM”那也就比零分好一点。合格的答题要先列可能原因后端服务挂了、FastCGI超时、文件句柄耗尽、防火墙拦截然后给每一种原因对应的排查命令和解决步骤。记住运维笔试不是考你运气好能猜中原因而是考你能否系统性地把所有的可能性排掉。第三类是“不考虑对业务的影响”。比如问“某台数据库磁盘满了怎么办”有人答“删大文件”。可是线上数据库删文件可能会触发严重问题正确做法是先确认是哪个实例、是否有从库、能否直接扩容云盘而不是为了救一台机器破坏数据一致性。答题时把你的操作后果也写出来评卷人会觉得你有风险意识。6. 基于真题的备考路线笔试之外还需要沉淀什么6.1 建立自己的“运维命令手册故障案例库”刷完这套B卷我最大的收获不是知道了答案而是找到了自己的短板。所以那之后我开始强制自己做两件事一是每学一个命令就在自己的笔记里写上“这个命令在什么故障场景下用输出里哪个字段最关键”。比如vmstat重点不只是看us和id而是看r运行队列和waIO等待配合free和iostat一起看才能判断CPU高是计算密集还是等待IO。这种“命令场景关联命令”的记录方式比单纯抄命令有效得多。二是坚持整理“故障复盘库”。每次处理完一个线上问题我会把时间线、现象、排查动作、根本原因、修复方案、改进措施写清楚。久而久之这些案例就成了我应对笔试和面试的素材库。遇到“你处理过的印象最深的故障”这种问题你可以非常有条理地讲出一个完整的故事。6.2 大厂运维笔试推荐的练习资源与思路关于备考我的建议分三步走第一步基础打牢。把《鸟哥的Linux私房菜》和《Unix环境高级编程》中的重点章节吃透。不需要背所有命令但常见命令的每个参数要多用、多练。每天在虚拟机或者云主机上模拟几类故障文件删不掉、服务起不来、端口被占、网络丢包逼自己不看搜索引擎去解决。第二步脚本自动化。专门用Python写一些运维小工具比如批量检查服务器时间同步、扫描日志中的异常关键字、自动备份数据库并上传到远程存储。写脚本时主动考虑异常处理、日志记录、幂等性。笔试里的Python题本质是看你有没有“工程习惯”。第三步研究开源方案。去了解Prometheus、Grafana、ELK、Ansible这些工具的原理和部署方式。不要求精通但要能说出它们各自解决什么问题、互相之间怎么配合。美团这类大厂很看重这些实际工具链的覆盖面。我在备考时还做过一个很有效的练习把Nginx的访问日志拿到本地每天用Python写一种不同角度的分析脚本——有时候统计状态码有时候看用户行为路径。一个月下来我的Python数据处理能力和Linux命令熟练度都有了质变。这类练习不依赖复杂环境但非常贴近大厂笔试的要求。笔试过了只是第一步后续面试还会追问这些考点背后的细节。但我始终觉得带着这套真题去查漏补缺比盲目刷题高效太多。你现在看到的这些复盘内容就是我当年从“读完题没思路”到“能搭建出完整分析框架”的真实过程。如果你正在准备运维岗不妨也把这些题目当一面镜子照照自己到底是在“背运维”还是真正“懂运维”。