做运维这些年我见过不少想入行的新人也帮人改过简历、模拟过面试。每次聊到“美团2017秋招笔试真题-运维工程师A”这套题我都会多讲几句这套题虽然年份早了点但它的考点分布和出题思路放到今天依然很有参考价值。尤其是运维工程师这个岗位看起来考的是命令、协议、系统参数实际上考的是你面对故障时的底层判断力。这篇文章我就以这套笔试为引子把运维工程师笔试里最常碰到的知识点、答题思路、以及从笔试延伸到生产环境的实操经验一起梳理一遍。不管你是准备秋招的应届生还是已经工作几年想查漏补缺的同行这篇文章应该都能给你一些实在的东西。我会尽量用“当时我是怎么想的”“生产环境里我会怎么做”这种角度来写而不是干巴巴地背答案。1. 真题概览与岗位定位1.1 这场笔试在考什么先说说这套题的总体感觉。美团2017秋招运维工程师A卷整体难度属于“广度优先、深度适中”它不像某些公司那样一上来就让你手写红黑树而是更看重你有没有完整的知识面。我记得当时网上能搜到的回忆版题目里大致有这几个方向Linux基础操作、网络协议、Shell脚本、数据库概念、还有一部分故障排查场景题。这套题有几个特点值得注意。第一它不考偏题怪题基本都在运维日常工作的范围内。第二它喜欢把多个知识点揉在一个场景里比如给你一个“网站响应变慢”的描述让你从网络、系统、应用三个层面去排查。第三它比较看重你能不能把原理说清楚而不是只知道命令怎么敲。所以如果你现在准备运维岗的笔试我建议别只刷题。你刷完一道题最好追问自己三个问题这个知识点在生产环境的哪个环节会出现如果它出问题了我的排查顺序是什么我能不能用一句话跟非技术同事解释清楚这三个问题想明白了笔试基本不会太差。1.2 运维工程师的能力模型与考察逻辑很多人对运维工程师有误解觉得运维就是“服务器坏了重启一下”或者“天天盯着监控看”。实际上运维工程师的核心能力可以拆成四块基础架构的理解能力、自动化与脚本能力、故障排查能力、以及沟通协调能力。笔试阶段最直接考察的是前两块。基础架构理解能力体现在你对Linux、网络、数据库、中间件的熟悉程度上自动化与脚本能力体现在你能不能写一段清晰的Shell或Python来解决重复性问题。而故障排查能力在笔试里往往以“场景题”的形式出现给你一段日志或者一个现象让你分析原因。至于沟通协调能力笔试里不容易直接考但面试一定会问。美团这套题基本就是按这个逻辑设计的。你会发现它没有特别多“背诵型”的题目更多是“理解型”的题目。比如它不会问你“TCP三次握手是哪三次”而是会问“为什么TCP需要三次握手两次行不行”。这种题没有标准答案但能看出你是不是真正理解网络协议的设计意图。这也是我给所有准备运维笔试的同学的第一个建议复习的时候尽量把每个知识点都往“为什么”上想一想。2. 高频考点拆解从操作系统到网络协议2.1 Linux 进程与文件系统的底层逻辑Linux是运维的基本盘笔试里关于Linux的题目一般不会太难但覆盖面很广。我记得这套题里出现过进程管理、文件权限、软硬链接、inode、系统负载等概念。先说说进程管理。有一个很容易混淆的知识点ps aux和ps -ef有什么区别其实两者展示的信息差不多只是参数风格不同。ps aux是BSD风格ps -ef是System V风格。笔试如果问你“怎么查看某个进程的CPU占用”你至少得知道top、htop和ps的用法。但更关键的是你要能解释清楚load average是什么意思。很多人以为负载高就是CPU忙其实不一定。负载是处于R状态和D状态的进程数的平均值如果IO卡住了D状态的进程变多负载也会飙升但CPU可能很闲。再比如文件系统。软链接和硬链接这个考点几乎是运维笔试的保留节目。硬链接的本质是多个目录项指向同一个inode所以硬链接不能跨文件系统也不能对目录创建。软链接则是一个独立的文件内容存的是目标路径所以可以跨文件系统。笔试里如果给你一个场景“删除源文件后软链接和硬链接分别会怎样”正确答案是软链接会失效硬链接不受影响因为inode还在被引用。还有一个我建议重点看的点磁盘inode耗尽。很多新手只会看df -h不知道还要看df -i。当硬盘空间还剩很多但系统报“No space left on device”的时候八成就是inode耗尽了。这类小知识点特别容易被笔试考到因为它是典型的“看起来简单实际没经验的人真不会”。2.2 网络排查的思维框架网络题在运维笔试里的占比通常不低因为网络故障是运维日常最头疼的问题之一。关于网络我建议大家不要死记协议细节而是建立一张“排查地图”。这张地图大致是这样的当用户说“网页打不开”你从下往上排查先看物理链路网线、交换机端口、WiFi信号再看IP层能不能ping通、路由表是否正确再看传输层端口通不通telnet或nc试一下最后看应用层HTTP状态码、DNS解析、证书、后端服务。美团这种大厂笔试时很可能会给你一段这样的描述让你写出排查步骤。你要做的不是背步骤而是理解每一层可能出现什么问题以及各层的排查工具是什么。比如说DNS解析失败时dig和nslookup能告诉我们什么HTTP返回502和504分别代表什么TCP三次握手中如果第三次握手的ACK丢了服务端会怎样这些问题看起来分散其实都是同一条链路客户端到服务端每一跳都可能出问题。我特别想说一下TCP三次握手。三次握手的核心目的是让双方都确认“我能收到你的消息你也能收到我的消息”。第一次握手客户端发了SYN服务端知道了客户端在第二次握手服务端回SYNACK客户端知道了服务端在第三次握手客户端回ACK服务端知道了客户端能收到自己的消息。这个设计是为了防止历史连接请求导致的资源浪费。笔试如果往深了问可能会问SYN Flood攻击的原理攻击者不停地发SYN但不回ACK导致服务端的半连接队列被占满。这个知识点在生产环境的防护里非常常见值得认真理解。2.3 数据库与缓存的高频概念数据库这块运维笔试不会像DBA岗位考得那么深但你至少要知道索引的原理、事务的ACID、常见存储引擎的区别、慢查询的排查思路。先说索引。索引的本质是空间换时间通过B树之类的数据结构减少磁盘扫描次数。笔试常见的坑是问“为什么联合索引要遵循最左前缀原则”。其实答案就在索引的存储结构里联合索引是先按第一列排序再按第二列排序所以如果你跳过了第一列直接查第二列索引就没法用了。我建议大家复习索引的时候不要只背“最左前缀”四个字而是画一棵B树自己推演一遍。再说缓存。Redis是运维笔试里的热门词。至少要知道Redis支持哪几种数据类型String、Hash、List、Set、ZSet各适合什么场景。还要知道缓存穿透、缓存击穿、缓存雪崩的区别穿透是查一个不存在的key导致请求直接打到了数据库击穿是某个热点key过期瞬间大量请求打到数据库雪崩是大批key同时过期数据库压力骤增。这三个概念几乎年年考而且面试时也经常追问“你怎么解决”。数据库连接池也是个容易被忽视的考点。连接池的作用不是加速SQL执行而是复用数据库连接减少TCP握手和鉴权的开销。如果你发现应用偶尔报“Too many connections”不一定是连接数配小了也可能是有慢查询把连接占住不释放。这种“看起来是连接池问题其实是SQL问题”的排查思路笔试不会直接考但生产环境一定会遇到。3. 笔试答题的思路与实操笔记3.1 遇到故障场景题时怎么拆场景题是运维笔试最有区分度的题型。给你一段描述“线上某服务凌晨CPU飙升但流量没有明显变化请分析可能原因和排查步骤。”这种题没有唯一答案但阅卷人一眼就能看出你有没有实战经验。我自己的答题框架是三步走。第一步收集信息。先看监控确认CPU是用户态高还是内核态高是单核高还是整体高有没有伴随load飙升、磁盘IO升高、网络流量异常。第二步缩小范围。通过top按CPU排序找到具体进程再用pidstat、strace、perf这些工具去定位是业务代码问题还是系统调用问题。第三步验证假设。比如怀疑是JVM频繁Full GC就去看GC日志怀疑是定时任务撞车就去查crontab和任务调度平台。笔试作答时你不用写得太具体但要把“先看什么、再看什么、最后怎么定位”的逻辑写清楚。千万不要一上来就说“重启一下”。重启确实能解决很多问题但也掩盖了很多问题而且在大厂的生产环境里重启一个实例可能要先走变更流程。所以笔试里你要展示的是“我能找到根因”而不是“我会重启”。还有一点场景题如果有“用户反馈页面打不开”这类描述你最好把检查顺序写成分层结构客户端到DNS、到CDN、到接入层、到应用层、到数据库。这样写阅卷人会认为你有全局视野。3.2 命令与脚本题的答题要点笔试里出现命令题时有一个普遍的丢分点知道命令的名字但是说不清参数。我建议你复习Linux命令时挑最常用的十几个命令把它们的主要参数背熟并且理解组合起来怎么用。比如netstat和ss查看端口监听状态-lntp、-anp这些组合参数要能脱口而出。tcpdump抓包分析至少会抓指定端口tcpdump -i eth0 port 80和写文件-w。find按名称、时间、大小查找文件-mtime、-size、-exec要会用。awk和sed文本处理三剑客里最常用的两个笔试经常让你“统计日志里某个字段的出现次数”。Shell脚本题也常出现比如让你写一段脚本备份数据库、清理过期日志、监控磁盘空间。这里我提个醒不要只写功能还要考虑健壮性。比如脚本里定了变量最好加个set -e或set -u避免变量为空或命令失败时继续往下执行。再比如清理日志的脚本一定要先确认路径正确否则可能误删。我见过真实案例一条find / -name *.log -delete把系统日志全删了那酸爽谁删谁知道。笔试里遇到“写脚本统计access.log里每个IP的出现次数并按降序排列”一行命令就能搞定awk {print $1} access.log | sort | uniq -c | sort -rn。但你要能讲清楚每一步在干什么awk取第一列sort排序让相同IP相邻uniq -c统计次数sort -rn按次数降序。如果你只是背命令面试官一追问怎么把次数也输出来你可能就卡壳了。3.3 估算题和架构题的拿分技巧大厂笔试偶尔会出一些“估算题”比如“估算一个城市有多少台服务器”或者“估算每秒能处理多少请求”。这种题看起来跟运维技术没关系实际上考的是你的逻辑拆解能力。我当时遇到这类题习惯用公式“每秒请求数 每日总请求数 / 峰值秒数”来拆。先把问题分解成若干因子再给每个因子一个合理的假设值最后算出结果。注意结果不重要过程重要。你要让阅卷人看到你是“有章法地估算”而不是“瞎猜”。架构题在大厂运维笔试里出现概率不高但一旦出现往往分值很大。常见问法是“如果让你设计一个高可用的Web架构你会怎么做”。这时候你要回答的关键词包括负载均衡Nginx/LVS、多副本部署、数据库主从、缓存、消息队列、监控告警、容灾切换。你不用讲得太细但要表现出“我知道每个组件解决什么问题”。比如你提到Nginx负载均衡就要知道它的几种调度算法轮询、加权轮询、ip_hash、least_conn分别适用什么场景。提到数据库主从就知道主库写、从库读以及半同步复制和异步复制的区别。提到Redis就知道哨兵和Cluster的区别以及为什么用Cluster而不是把所有数据放一个实例里。4. 从笔试到生产用真题思维解决实际问题4.1 一个服务上线流程的梳理真正工作之后你会发现笔试里那些知识点不是一个一个孤立的而是会贯穿到一次完整的服务上线流程里。我以自己做过的一个小服务上线为例把笔试考点和生产操作串一遍。第一步是申请资源和配置基础环境。拿到一台全新的机器你要做的第一件事是配置主机名、时区、DNS、yum源或apt源还有系统参数。这里就用到Linux的知识了sysctl调内核参数比如net.ipv4.tcp_tw_reuse、net.core.somaxconn、vm.swappiness每个参数含义都要清楚。第二步是部署应用写systemd service文件。这里会用到权限管理、日志管理、环境变量注入的概念。第三步是接入负载均衡和监控。Nginx配置upstreamPrometheus接节点上报Grafana配面板。第四步是切流量灰度发布。这就涉及到上线策略了比如蓝绿部署、金丝雀发布以及回滚方案。整个过程走下来你会发现笔试里的每一个考点都有实际映射。ps aux对应的是你看进程是否正常df -h对应的是你判断磁盘是否够用tcpdump对应的是你排查调用链路上是不是有报文丢失。所以我一直说准备运维笔试最好的方式不是刷题而是自己动手搭一套完整的小系统从零把它跑起来再把它弄坏再把它修好。4.2 监控、告警与容量规划笔试里关于监控的题不多但面试一定会问。而且从我的经验看很多运维新人最大的短板就是监控。他们知道要装Prometheus、Grafana但不知道监控的核心不是“好看”而是“能预警”。一个合格的监控体系至少要覆盖四个层面硬件层CPU、内存、磁盘、网络、系统层文件描述符、进程数、系统负载、应用层接口延迟、错误率、QPS、业务层订单量、注册量、支付成功率。笔试如果考监控大概率会问你“你觉得监控哪些指标最重要”这时候你要能说出层级而不是只报一两个指标。监控和告警的难点在于“阈值怎么定”。定得太松故障发生了不报警定得太紧每天被告警轰炸最后大家都麻木了。我自己的经验是先用历史数据做基线。跑一个月看正常情况下的P99和P95然后把告警线设在P99的1.5倍左右。告警一定要分级P0是服务不可用P1是功能受损P2是性能劣化不同级别对应不同的响应时间。容量规划和这个道理类似不是等磁盘满了才想起扩容而是根据增长曲线预判未来一个月、三个月的使用量提前申请资源。4.3 容器化与 kubernetes 时代的运维变化近几年运维工程师的知识结构有一个很大的变化容器化和Kubernetes已经成了标配。你可能在笔试里看到一些老题是问怎么配Nginx、怎么调JVM参数但面试里一定会问你对容器和K8s的理解。热词里提到的“kubernetes是如何调用containerd”其实就是这个方向的核心问题之一。我简单说一下这个调用链路。Kubernetes的kubelet通过CRIContainer Runtime Interface跟容器运行时通信。containerd实现了CRI所以kubelet把请求发给containerdcontainerd再通过它内部的组件去拉镜像、创建容器、启动进程。整个过程大概可以拆成kubelet - CRI插件 - containerd - containerd的shim进程 - runc最后由runc通过Linux的namespace、cgroup等内核能力把容器跑起来。你不需要把每一行源码都背下来但你要理解每一层存在的意义CRI是为了让K8s不绑定具体的运行时containerd是为了管理容器的生命周期shim是让容器进程和containerd解耦runc是真正干活的“最小执行单元”。容器的出现改变了运维的很多习惯。以前你排查问题直接登到机器上看现在你可能要看Pod日志要进容器里执行命令要理解镜像分层的机制要会处理镜像仓库的认证和构建缓存。但底层的东西没变容器里的进程还是会占CPU、内存网络还是走TCP/IP磁盘还是可能写满。所以不要觉得有了K8s就不用学Linux了恰恰相反K8s对底层知识的要求更高了。5. 常见问题与避坑清单5.1 考生常见的丢分点结合我帮人复盘笔试的经验我总结了几个常见的丢分点你可以在复习时对照自查。第一个丢分点是“背了命令但不知道原理”。比如很多人知道curl -I能看HTTP头但不知道-I是HEAD请求不是GET请求更不知道HEAD请求和GET请求有什么区别。这类问题不细想的人笔试遇到“为什么用curl -I测试比curl正常访问更快”就会懵。第二个丢分点是“排查思路没有闭环”。场景题里你只写了“看CPU、看内存、看日志”但没有说明“看到什么结果之后下一步做什么”。比如你写“用top查看CPU占用”后面应该接一句“如果CPU占用高则进一步用pidstat确认是用户态还是内核态再用perf采样定位热点函数”。这样才算闭环。第三个丢分点是“没有考虑异常分支”。写脚本题的时候只写正常流程不写文件不存在、目录权限不足、磁盘空间不够等异常情况。笔试阅卷人经验丰富看到你没有异常处理就会认为你缺少生产意识。这个非常容易丢分。第四个丢分点是“无视题目的限定条件”。比如题目问“线上环境不能重启服务如何排查问题”你上来就说重启试一下。这种答案直接暴露了实战经验不足。5.2 我踩过的坑和补救经验说几个我自己工作里踩过的坑也是笔试时容易犯的思维错误。第一个坑是“只看现象不看根因”。有一年我处理过一个线上问题服务每隔一小时就卡顿一次。我一开始以为是网络波动排查了半天没结果。后来发现是crontab每小时跑一次日志清理任务跟业务高峰撞在一起导致IO被打满。从那以后我遇到周期性故障第一反应一定是去看定时任务和监控上的周期曲线。笔试里如果给你“服务每小时卡顿”的描述这个思路就很值钱。第二个坑是“没有备份就执行危险命令”。我刚开始做运维的时候有一次想清理日志手快写了rm -rf目标路径写错了一个字符差点把应用目录删了。从那以后我给自己定了一条铁律凡是清理类、删除类的操作先看一眼磁盘空间和目录内容再执行并且尽量用“移动到一个临时目录确认没问题再删”的方式来操作。这条规矩放到笔试里也很适用脚本题里如果有删除动作你一定先判断一下路径是否来自外部输入如果是就要加校验。第三个坑是“不懂TCP状态就乱猜”。有一次接口偶发超时我抓了包看到一堆TIME_WAIT本能地以为是TIME_WAIT太多导致的后来才发现这是一次正常现象TIME_WAIT多是主动关闭连接的一方大量出现并不直接导致超时。真正的问题是后端服务处理慢客户端等不及就断开了。所以笔试里如果问TIME_WAIT你要能说清楚它出现的条件和主要影响而不是简单地认为“多就是坏”。5.3 一份面向面试的自查清单最后给你一份我自己整理的自查清单如果你能把这些点都说明白笔试面试基本稳了。Linux能不能解释软硬链接、inode、进程状态、文件描述符、僵尸进程会不会用find、grep、awk、sed、top、vmstat、iostat、strace网络能不能说清TCP三次握手和四次挥手能不能按“物理层到应用层”的顺序讲一个网页请求的完整链路会不会用tcpdump抓包并分析数据库能不能解释B树索引、事务隔离级别、慢查询排查Redis的数据类型和缓存三大问题能不能讲清楚脚本与自动化能不能用Shell写一个带参数校验和异常处理的脚本了解不了解Ansible、Python运维脚本容器与云原生能不能说清K8s调用containerd的链路理解不理解Pod、Service、Deployment的关系有没有实际操作过容器排障监控与故障处理有没有完整的监控指标体系和告警分级经验遇到故障时有没有一套固定的排查框架这个清单不一定覆盖所有公司的所有考题但覆盖了运维工程师这个职业最核心的通用能力。不管你是刚准备入行还是已经在做运维但想跳槽到大厂顺着这个清单去梳理自己的知识盲区比盲目刷题要高效得多。我个人的体会是运维工程师这个岗位入门容易做好很难。面试官真正想招的不是一个“会敲命令的人”而是一个“对系统有敬畏心、对故障有敏感度、对原理有好奇心”的人。笔试只是第一关但它的出题逻辑往往能反映一家公司对运维岗位的期待。如果你能从这套题里看到“为什么这么考”而不是“这道题答案是什么”那这篇文章就没有白写。