美团运维笔试那点事把2017年的真题当今日的镜子聊聊我踩过的坑前几天整理旧电脑里的面试资料翻出一份当年美团秋招运维工程师笔试的保存截图。时间真快转眼过去好几年。那会儿我还是个刚接触 Linux 不久、连awk都写不利索的菜鸟如今好歹也算在运维圈子里摸爬滚打了几个春秋日常面对的不再是笔试题目而是真刀真枪的线上故障和自动化工单。但今天把这套旧题重新读一遍反而有点感慨运维笔试真的和行业里很多人想的不一样它不考你背了多少命令而是考你在一个生产环境事故现场能不能冷静地把问题拆开、判断边界、给出可执行的恢复方案。2017年美团这套题大致覆盖了网络基础、Linux 命令、Shell 脚本、负载均衡、故障排查方法论这几大块说白了它就是给运维工程师这个岗位画了一张能力地图。哪怕过了这些年考点骨架依然没有太大变化变的只是工具和平台变得更复杂了。这篇文章我就以这套真题为引子结合我后来在实际运维工作中遇到的人和事把每个考点背后的真实场景和准备方法说清楚。如果你正在准备运维岗位面试、笔试或者刚转行进这个圈子这篇文章能帮你少走很多弯路。1. 网络基础题不是背协议而是判断流量走向先说整套卷子里的网络基础部分。美团这套题的题量不算大但网络题出得比较典型。大致有这几种考法TCP 三次握手的具体状态变化、HTTP 状态码在实际场景中的含义、DNS 解析的完整链路。1.1 三次握手和四次挥手别只会画箭头三次握手是几乎每一份运维笔试题都躲不开的题目。常见的问法是简述 TCP 三次握手的过程很多人的答案是客户端发 SYN服务端回 SYNACK客户端再回 ACK表面上没错但拿不到高分因为这里缺了最关键的状态转换和异常场景。2017年那道题我记得是给了一个场景客户端向服务端发起连接分析每一步客户端和服务端所处的 TCP 状态。实际上这就是在考TCP状态机。你在 Linux 上执行netstat -anpt或者ss -tanp时看到的各种状态比如SYN_SENT、SYN_RECV、ESTABLISHED、TIME_WAIT笔试题目就是希望你把这些和三次握手的阶段对应起来。我当时答题时只画了三次握手的流程但没有写状态转换表这就是失分点。正确的答法是客户端 CLOSED → SYN_SENT发送 SYN 服务端 LISTEN → SYN_RECV收到 SYN回复 SYNACK 客户端 SYN_SENT → ESTABLISHED收到 SYNACK发送 ACK 服务端 SYN_RECV → ESTABLISHED收到 ACK这个状态链路不能错因为面试官后续可能会追问如果客户端发完 SYN 之后一直收不到 SYNACK会怎样实际上就是连接超时客户端会等待一段时间后放弃这个等待时间在 Linux 里由tcp_syn_retries参数控制。运维排查服务端端口连不上的问题时第一步就是看服务端有没有在LISTEN状态再去抓包看有没有SYN到达区分是网络不通还是服务没起来这套排查思路的起点就是状态机和三次握手。1.2 HTTP 状态码从 2xx 到 5xx 的实际含义HTTP 状态码这道题几乎每次笔试都会出现。美团那年的考法是给了一批状态码让你写出各自含义或者给你一个线上现象让你判断是哪个状态码导致的。线上运维里大家打交道的通常就这么几个200 OK正常响应。301/302重定向。301是永久重定向302是临时重定向。Nginx 里如果你配了 http 跳 https用的就是 301。403 Forbidden服务端拒绝请求。常见原因是文件权限不对或者防盗链策略生效。404 Not Found资源不存在。499Nginx 特有的状态码表示客户端在服务端还没返回结果时就主动断开了连接。这是排查超时问题时的高频词汇。500 Internal Server Error服务端内部错误通常是后端代码异常。502 Bad Gateway网关收到无效响应。常见的场景是 Nginx 后面的 PHP-FPM 或者 Java 应用挂了、没有进程监听端口。503 Service Unavailable服务暂时不可用通常是服务过载或者正在维护Nginx 配置了限流也会产生 503。504 Gateway Timeout网关超时后端处理请求的时间超过 Nginx 设定的proxy_read_timeout。很多面试者会把 502 和 504 弄混。我后来在真实排查中遇到过无数次这样的情况用户上报打开页面报 502我登上服务器一看后端应用进程已经退出了端口没有监听所以 Nginx 转发过去拿不到任何响应就直接抛 502。而 504 则不同——后端进程还活着请求也能到达但处理时间太长Nginx 等得不耐烦自己先断了。这两个的排查方向完全不同。1.3 DNS 解析链路本地 hosts 到权威服务器的完整路径美团这套题里有一道 DNS 相关的题目现在想想这个考点在运维工作中太实用了。题目大概是一个用户在浏览器输入域名系统是怎么把域名解析成 IP 的完整的解析链路大概是查询浏览器缓存。查询本地操作系统 hosts 文件。查询本地 DNS 解析器的缓存。向配置的 DNS 服务器比如 114.114.114.114 或 223.5.5.5发起递归查询。DNS 服务器向根域服务器查询顶级域比如.com的服务器地址再向顶级域服务器查询该域名的权威服务器地址最后从权威服务器拿到记录。当时我答到第4步就停了其实还有递归查询和迭代查询的区别以及 TTL 缓存时间的影响。后来在业务联动故障里DNS 的缓存导致流量不切换、用户访问老 IP 这类问题追根溯源都是对 DNS 缓存机制理解不透。2. Linux 基础命令笔试简单实战里全是细节美团运维工程师笔试中对 Linux 的考察不算难常见的是top、ps、grep、awk、sed、find这些高频命令的参数和使用场景。但可别小看这类基础题它们其实是笔试中的送分题也是拉开差距的地方。2.1 排查 CPU 飙高从 top 到线程级定位我记得有一道题是服务器 CPU 使用率飙升如何定位是哪个进程导致的以及哪个线程导致的这道题我当时只写了top然后看%CPU最大的那个 PID。这个答法不能说错但不够完整。在一个注重实战的面试官眼里完整的排查链路应该是执行top -c查看占用 CPU 最高的进程记住它的 PID。执行top -Hp PID查看该进程下各线程的 CPU 占用情况找到耗 CPU 的具体线程 TID。把 TID 转成十六进制比如printf %x\n TID。如果有 Java 应用执行jstack PID | grep -A 30 nid0x...查看对应线程栈定位到具体的业务代码如果是 C/C 或者 Python 等其他语言可以用gdb或perf进一步分析。我当时没有把后面这几步写出来因为当时只知道top不知道有-H这个参数。但其实这恰恰是笔试的深意**运维不止是能执行命令而是要能根据现象一步步缩小排查范围。**这个思路在后来的日常工作中几乎每周都能用上。2.2 磁盘空间满了df 却看不出大文件还见过一道经典题目df -h显示磁盘已满但用du -sh *统计目录大小后却发现加起来不到磁盘总容量这是怎么回事这种情况在真实环境里非常常见尤其是跑 MySQL、容器、Nginx 等频繁写日志或删除文件的服务器上。原因有几个可能文件被进程删除但进程没有关闭该文件的句柄空间仍被占用。解决方式是找到这个进程并重启或者用lsof | grep deleted找到对应进程让它释放句柄。这在运维里几乎是标准的操作属于文件句柄未释放问题。文件系统中有隐藏的保留空间或 inode 耗尽。当 inode 用尽时即使 df 显示有空间也无法创建新文件。用df -i查看 inode 使用率。挂载点层级的问题NFS 或子目录被单独挂载导致排查目录大小的时候遗漏了某个挂载点内的数据。笔试中通常只要答出前两个原因就够了但实际排查中lsof | grep deleted这一招几乎能解决一大半磁盘显示满但找不到大文件的怪问题。2.3 权限和软链容易被忽略的基础题还有一些基础题是考文件和目录权限的比如chmod、chown的使用以及软链接和硬链接的区别。这类题本身不难但很多人会忽略细节chmod对目录的x权限意味着是否可以进入该目录没有x权限即使有r权限也无法cd进去。软链接和硬链接的区别用一句话可以概括软链接是一个独立的文件存的是目标文件的路径硬链接和目标文件共享同一个 inode相当于给同一份数据起了一个新名字。笔试会考创建一个软链接用ln -s创建一个硬链接用ln但真实工作中我们最常用的其实是软链接——比如部署新版本时把/data/www软链到/data/releases/20230801这样切换版本只需要改一条软链回滚也快。3. Shell 脚本题考的不是编程是自动化思维美团运维笔试里肯定会有一两道 Shell 脚本题。内容大致是写一个脚本统计日志里某类 IP 的出现次数或者找出一个目录下的所有大文件或者检查某服务是否在运行如果不在就启动它。3.1 统计 Nginx 访问日志某个 IP 的请求数我当时遇到的题目类型大概是有一个 Nginx access.log需要统计访问次数前五的 IP。这题的核心就是awk和sort的组合。awk {print $1} access.log | sort | uniq -c | sort -rn | head -5如果把 IP 换成 URL、状态码、User-Agent也是一个套路。做题时容易犯的错是忘了sort后再uniq -c——如果不先排序uniq -c只会把连续相同的行合并统计结果就是错的。这个细节在笔试中特别容易踩。3.2 找出占用空间最大的目录第二个常见脚本题是查找某个目录下占用磁盘空间最大的前10个文件或目录。du -ah /data | sort -rh | head -10注意sort -h是按照人类可读的数字大小排序-r是倒序。如果是老版本的 Linux 系统不支持-h那就得用sort -n配合du -k以 KB 为单位输出来处理。这类题目表面上是在考命令实际上考的是你有没有对重复性工作做自动化的意识。面试官希望看到你不仅会一条条命令执行还会把这些命令封装成脚本能在多台机器上批量执行。我当时的答法只给了一条命令虽然结果正确但没有展示封装成函数的意识这其实是一个加分项的丢失。3.3 写一个服务监控脚本守护进程的思路还有一种更进阶的 Shell 题写一个脚本监控某个进程比如nginx是否在运行如果不在就启动它并且把日志写入文件。我当时写的一个版本大概是这样#!/bin/bash if ! pgrep -x nginx /dev/null; then /usr/sbin/nginx echo $(date) nginx restarted /var/log/nginx_watch.log fi这道题现在复盘有三个可以深挖的点用pgrep -x精确匹配进程名避免误匹配到其他带 nginx 关键字的进程。用if ! ... then比用if [ ... ]; then ... else更精简。更严谨的脚本要加上启动失败怎么办的告警逻辑比如发送邮件或者写入单独的错误日志。不过在真实生产环境里这种单纯靠 Shell 脚本守护进程的方式早就过时了主流方案是 systemd 的Restarton-failure或者用 Supervisor 管理进程。笔试中写了守护脚本如果能结合 systemd 说明更优方案会显得你对运维工具有更完整的认知。4. 负载均衡与反向代理从笔试到线上架构的关键衔接美团这套题里有一道挺有意思的题考的是负载均衡的几种算法和应用场景。那时候我对负载均衡的理解还停留在把请求分发到多台服务器这个层面实际上负载均衡是整个后端架构里最核心的流量入口。4.1 常见的负载均衡算法对比round robin轮询请求轮流分发到每台后端机器。适合后端机器配置差异不大的场景。weighted round robin加权轮询按权重分配权重高的机器分到的请求多。适合机器配置不统一或者某些机器承担了更多公共任务的情况。ip_hash/hash $remote_addr按客户端 IP 做哈希保证同一个客户端的请求固定落在同一台后端机器。适合有 session 且没有集中式 session 存储的老项目。least_conn最少连接数把请求发给当前活跃连接数最少的后端机器。适合长连接或请求处理时间差异大的场景。这个知识点的价值体现在 Nginx upstream 配置上upstream backend { least_conn; server 192.168.1.10:8080 weight5; server 192.168.1.11:8080 weight3; keepalive 32; }4.2 健康检查负载均衡器最容易被忽视的能力美团那套笔试题里有一道是问负载均衡节点上的某台后端服务器挂了怎么保证用户无感知这个问题的标准答案是——健康检查。Nginx 自带的max_fails和fail_timeout就是最原始的被动健康检查upstream backend { server 192.168.1.10:8080 max_fails2 fail_timeout10s; server 192.168.1.11:8080 max_fails2 fail_timeout10s; }这个配置的含义是如果 10 秒内向这台服务器失败了 2 次就把这台服务器标记为不可用后续请求不再转发给它。这算是一种被动探测实现简单但问题在于它只在真实请求失败后才摘除节点如果那台机器只是响应慢并没有返回错误就不会触发摘除。商业负载均衡器比如 F5或者云上的 SLB 通常支持主动健康检查——每隔几秒主动发一个探测请求HTTP 探活或 TCP 探活检查后端是否正常。掌握了这个区别笔试中答题会显得老练很多。4.3 Session 会话保持笔试经常问面试容易答偏另一个高频考点是session 会话保持。为什么要有会话保持因为负载均衡默认是无状态的每次请求可能会被分发到不同的后端服务器。如果业务系统把用户登录状态存在了本机内存比如老牌的 Tomcat 单机 session用户第一次请求落在 A 机器刷新页面后请求落在了 B 机器B 机器没有这份 session用户就被踢下线了。解决方案通常有几种在负载均衡层配置ip_hash让同一个 IP 的请求固定到同一台机器。业务层把 session 存到集中式的 Redis 或数据库中这样任何一台后端机器都能读到。使用 Cookie 植入方式让负载均衡器根据 Cookie 中的标识来路由。笔试中如果把方案一和方案二都列出来并说明各自优缺点基本就能拿全分数。5. 故障排查题像侦探一样还原问题现场这套笔试中还有一个让我印象深刻的题型——给你一段线上故障描述让你分析可能的原因和排查步骤。这道题非常典型因为运维工作有相当一部分时间就是在做从现象推理根因这件事。5.1 用户反馈网站打开很慢你要怎么入手美团那年有一道类似的题用户反馈网站打开速度变慢作为运维工程师请写出你的排查思路。这种题没有唯一的正确答案但有章可循的答题框架。我当时的回答罗列了一大堆命令比如ping、telnet、curl但缺少分层排查的逻辑。前几年我再回忆这套题的时候总结出一个相对规范的排查链路先确认是单个用户慢还是所有用户慢。如果所有用户都慢问题大概率在后端如果只是个别网络环境慢可能和用户本地网络、DNS 解析、CDN 节点有关。检查入口负载均衡和 Web 服务器的请求量、响应时间指标。用 Nginx 的$request_time和$upstream_response_time定位耗时发生在哪个环节。检查后端服务的 CPU、内存、磁盘、网络负载。执行top、free、iostat、vmstat查看系统资源是否有瓶颈。查看数据库的慢查询日志和连接数数据库层面往往是响应慢的重灾区。如果以上都没有明显问题再往深了查是否存在锁竞争、GC 停顿、依赖的外部接口比如第三方支付、云存储响应缓慢。这套链路的核心是先宏观后微观从入口到出口一层层切。笔试中如果能画出这个思路哪怕不用列出具体的命令面试官也知道你不是一个只会敲键盘的工具人。5.2 线上服务突然大量 502如何处理还有一类故障题很喜欢考你的服务突然大量报 502。我在真实工作中处理过不少类似的突发状况。正常的处理流程是先连续curl几次故障域名/IP确认是不是已恢复。登上去看nginx error.log确认 502 产生的频次和高峰时段。用ss -lanp | grep 8080看后端端口有没有监听。如果后端进程挂了立刻重启然后去查为什么会挂看日志、看内存、看是否有内核 OOM。注意这里最关键的一步是重启前尽量先把现场信息留下来。比如dmesg | tail -50看有没有 OOM 记录sar -q看负载历史否则一旦重启很多线索就永远找不回来了。这也是笔试和实际工作最大的区别——考题里不存在现场破坏这个概念但真实运维里这是要命的。5.3 数据库连接数被打满从哪儿下手有一道关于数据库的题也值得一提大意是MySQL 连接数达到上限新请求无法建立连接怎么处理这类问题的根因往往不是连接不够用而是连接没有被及时释放。所以排查思路是show processlist;查看当前有哪些连接处于Sleep或Query状态是哪个业务方占用的。检查代码连接池配置连接池最大连接数是否过高空闲连接是否会被回收。检查是否有慢查询导致连接长期占用开启慢查询日志定位执行时间长的 SQL。如果是连接风暴导致的问题比如突然大量请求进来先调大max_connections应急再在中间件层加上连接排队机制防止把数据库打垮。这一步在现场做完笔试分数通常能上去一个档次——因为你不只给出了调大 max_connections这种治标方案还想到了从代码和慢查询层面根治。6. 笔试之外美团运维岗真正在意的能力和准备建议最后谈谈比刷题更重要的事情。美团这套题并不难但它在运维工程师的招聘中的定位很清楚筛选出那些基础扎实、有逻辑、能落地的人。所以笔试只是第一关后面还会有一到两轮技术面试重点考察你实际处理过的系统、踩过的坑、做过的优化。6.1 基础命令要过关但不能只停留在会敲的层面如果现在有人问我运维工程师最核心的能力是什么我的回答是理解系统的能力。同样是top你能从load average看出系统是 CPU 密集还是 IO 密集吗同样是free你能判断目前的内存是够用还是已经溢出到 swap 了吗同样是df你能分清文件系统空间满了和 inode 满了有什么区别吗这些都是笔试和面试隐含的要求。我的建议是在准备时不要只看命令的参数而是给自己出一些场景题比如如果 CPU 高、负载低是什么原因、如果负载高、CPU 低是什么原因——把命令和系统运行机制结合起来你的理解深度会和背命令的人完全不同。6.2 数据流比工具链更重要还有一个更高维度的能力理解数据流。从用户点击浏览器开始经过 DNS 解析、CDN 加速、四层负载均衡、七层负载均衡、应用服务器、Redis 缓存、消息队列、数据库、对象存储……整条链路上每一层都有它的作用也都可能成为故障点。笔试中的网络基础题、HTTP 状态码题、负载均衡题本质上都是在考你这条链路是否完整。我建议准备者把这条链路画一遍用自己的话说明每一层的作用、常见故障、常用的排查工具能做到这一步再去看笔试题目会发现很多题只是这条链路中某个点的小测试。6.3 笔试题之外学会总结和复盘美团这套题早已是过去时但它的意义在于帮你建立一个知识框架。真正能让运维能力成长的是每天工作中的复盘。比如你今天处理了一次磁盘满的故障那就可以顺手整理一下查了哪些命令导致磁盘满的文件是什么它的产生机制是什么以后怎么提前预防能否写一个巡检脚本自动发现类似问题。把这些整理成文档积累一两年你就不再是那个遇到问题只会重启的服务员而是真正具备架构视角的运维工程师。在我个人看来运维这个岗位的成长路径有两条一条是走深比如在特定领域数据库、网络、容器、云原生成为专家另一条是走宽成为懂网络、懂系统、懂业务、懂自动化的全栈运维。无论哪条路基础知识和排查逻辑都是底座。美团 2017 年的这套笔试题目虽然简单但它给运维工程师画了一个清晰的起点剩下的路靠你自己走了。