1. 从运维岗笔试说起2017年滴滴秋招这道题到底想考什么这几年后台总有人翻出各种大厂真题来问问得最多的反而不是最新的题而是2017年滴滴秋招那套运维岗笔试题。为什么大家都盯着一套旧题看因为运维这个岗位的笔试题目不像开发岗那样年年翻新核心考点其实非常稳定。2017年那套题几乎把Linux基础、网络排障、数据库问题、系统监控、自动化脚本这几座大山全占了而且难度梯度明显既有送分题也有故意挖坑的题。我这些年带过不少新人也参与过几轮校招面试一个很深的感受是笔试通过的人未必是最会敲命令的但一定是对系统运行逻辑有整体认知的人。换句话说运维笔试的底层逻辑不是考你背了多少命令而是考你有没有一套“系统出问题知道去哪看、怎么看、看完怎么修”的方法论。2017年滴滴这套题恰恰是这种考察思路的典型代表。我自己在准备面试时养成了一个习惯拿到一份真题先不做题先把每个题目对应的知识域画出来。比如考tcpdump背后其实是网络排障能力考inode耗尽背后是对文件系统机制的掌握考负载均衡策略背后是对高可用架构的理解。这套分析思路比刷一百道题都管用。这篇文章就把这套思路完整拆开结合2017年滴滴秋招运维岗的典型真题把每个考点背后的原理、实操方法和踩坑经验一次性讲透。无论你是准备校招的应届生还是想跳槽的运维工程师甚至是想转行做云计算运维的开发者这篇文章都会给你一条比“背命令”高效得多的准备路径。2. 知识框架拆解运维笔试的四大核心能力域2.1 能跑通业务的技术广度从操作系统到应用层运维工程师日常面对的是整个技术栈所以笔试第一关考的就是广度。2017年滴滴这套题里Linux系统命令、进程管理、文件权限、shell脚本占了相当大比例。这不是出题人偷懒而是这些确实是最基础最常用的能力。以Linux命令为例核心其实可以分成几类系统状态类top、free、df、iostat、vmstat、netstat、ss文件与权限类ls、chmod、chown、find、tar、grep、awk、sed进程与服务类ps、kill、systemctl、service、crontab网络类ping、telnet、nc、curl、traceroute、tcpdump但光会命令列表没用笔试和面试真正拉开差距的是你在什么场景下知道该用哪条命令。比如系统突然变慢了有人一上来就top这没错但更严谨的排查顺序应该是先用uptime看负载再用vmstat看CPU和内存的交互状态然后用iostat看磁盘IO最后才用top看具体进程。顺着这个顺序问题的定位效率会高很多。滴滴的题里有一道典型的场景题服务器负载突然飙高到20以上你如何排查这道题考察的就是这个思路。我看到很多人的答案就是“top看CPU”但一个合格的运维至少要能说出先看是不是CPU密集型进程再看是不是磁盘IO阻塞导致D状态进程堆积还要排除swap频繁换页的可能性。不同原因的处理方式完全不同这一步判断错了后面全是白干。2.2 网络协议的认知深度不只是能ping通网络部分在运维笔试里是硬骨头滴滴2017年秋招也不例外。考察点集中在TCP/IP协议栈、HTTP协议、DNS解析、负载均衡这几个方向。TCP握手和四次挥手是必考中的必考。但光背“三次握手四次挥手”的流程是拿不到分数的题目往往会结合故障来考。比如你发现服务端有个连接一直处于TIME_WAIT状态量很大会不会有问题怎么解决这就要你理解TIME_WAIT产生的机制是为了保证最后一个ACK能被对端收到同时让旧连接的数据包在网络中消亡。生产环境里如果短连接特别多TIME_WAIT会占用大量端口和内存常规处理方案是开启tcp_tw_reuse配合tcp_timestamps使用。但这里有个坑tcp_tw_recycle在NAT环境下有严重问题会导致连接异常生产环境基本不敢开。这类细节只有真正踩过坑的人才能答得出来。HTTP状态码也是高频考点。2017年滴滴那道“500错误排查”的题目其实就是在考你对HTTP协议栈各层错误的理解。502是网关错误说明反向代理拿不到后端的响应504是网关超时说明后端在指定时间内没处理完。这两者排查方向完全不同502要先看后端服务是不是挂了504则要先看是哪个环节慢了。能把这些区分清楚说明你脑子里有一个“数据包在系统里怎么流动”的完整画像。2.3 数据存储的稳定性意识数据库与文件系统运维笔试里数据库相关内容核心考的是稳定性和备份恢复不会让你写复杂的SQL。滴滴这套题里涉及MySQL的主要就是主从复制原理、慢查询排查、binlog的作用这类问题。主从复制这块我建议准备的时候把binlog格式三者区别弄清楚statement格式记录的是SQL语句row格式记录的是行变更前后镜像mixed是两者的混合。生产环境一般推荐row格式因为它对数据一致性最有保障缺点就是binlog文件会变大。笔试如果问你“主从延迟怎么办”至少要从三个层面回答网络延迟、从库硬件性能、大事务或长事务导致的延迟。很多人只答了第一个层面其实在主从延迟这个场景里最常见的原因反而是从库上执行了太多次全表扫描的大查询或者是主库上有个跑了很久的大事务。文件系统方面inode耗尽是经典陷阱题。df -h显示磁盘还有空间但应用报“No space left on device”这考的就是文件系统知识。实际上需要查看的是inode使用率df -i。假设一个服务器磁盘是2TB但上面的小文件有几千万个inode会先耗尽。处理方案也很直接找出哪里的inode占用最多清理过期的小文件或者把部分目录迁到文件数较少的存储上。这道题在滴滴2017年的真题里出现了不止一次可见出题人对文件系统内部机制的重视。2.4 自动化与脚本的工程思维Shell/Python的实战场运维发展到今天手工时代早就过去了。滴滴2017年的笔试里就有shell脚本相关题目虽然放在现在看难度不算大但考察的工程思维是一致的能不能用脚本把重复劳动自动化。比如有一道题是“写一个脚本定时检查Nginx进程是否存活若死了则重启并发送报警”。这个需求到现在依然是运维面试的经典题。回答的时候好一点的版本不会只是循环if-else而是会添加判断如果重启后仍然启动失败应该停止重试并升级报警避免脚本陷入“死循环重启”的尴尬局面。这就要求你对进程启动机制有理解对告警升级流程有设计。另外Python在运维中扮演的角色越来越重要。滴滴这种体量的公司系统数量上千靠shell无法完成复杂的批量操作和数据处理Python是标配。准备时至少要掌握用subprocess或者paramiko做远程批量命令执行用requests做HTTP接口调用用pandas或awk处理后端日志等场景。3. 真题实战解析几道有代表性的运维笔试高频题3.1 系统排查场景题CPU飙高如何定位线程滴滴2017年秋招出现过一道很实战的题目用户反馈应用响应很慢你登录服务器发现CPU使用率接近100%如何定位是哪个进程的哪个线程在消耗CPU并进一步定位到具体代码这道题考察的是一套完整的排查链路。第一步用top查看按CPU排序找到PID。第二步如果应用是Java需要进一步用top -Hp PID查看线程级别的CPU占用记下最耗CPU的那个线程号十进制的。第三步把线程号转成十六进制用jstack dump线程快照搜索这个十六进制线程号就能看到对应的线程堆栈。堆栈里会明确告诉你卡在哪个类的哪个方法上。这道题对运维的要求已经超越了“系统管理员”的范畴要求你懂一点应用层知识。建议准备时把常见的Java线程状态也熟悉一下RUNNABLE、BLOCKED、WAITING、TIMED_WAITING看到BLOCKED密集就要考虑锁竞争看到TIMED_WAITING密集就要考虑线程池配置不合理。这不仅仅是应付笔试在生产环境中这套方法我实测过无数次非常有效。3.2 网络排查场景题从connect超时到tcpdump抓包网络题里有一类很典型的我印象很深用户反馈某个接口偶发超时但看监控系统服务器负载不高网络带宽也没有打满如何进一步排查这类题如果只回答重启服务基本就告别offer了。一套标准排查路径如下先确认客户端和服务端之间的网络链路用ping或者mtr看是否有丢包和中转节点延迟接着看TCP连接建立情况用ss -s查看系统当前连接状态统计关注SYN_SENT和SYN_RECV的数量如果怀疑是服务端处理慢可用tcpdump抓取特定端口的包分析请求到响应的耗时分布最后结合应用日志看是否出现了接口慢调用。这里有个细节值得展开tcpdump抓包时很多人不加参数直接抓结果抓下来的包文件巨大分析起来非常痛苦。正确姿势是先明确过滤条件比如只抓特定端口和特定IP的包tcpdump -i eth0 host 10.0.0.1 and port 8080 -w /tmp/capture.pcap等抓个几十秒到几分钟再用wireshark打开分析TCP握手时间、响应时间等指标。在2017年的环境里滴滴内部对tcpdump的使用非常频繁因为他们业务对实时性要求很高网络抖动直接影响用户体验。3.3 数据库场景题主从延迟排查思路数据库部分高频的是主从延迟题。滴滴的真题里场景大概是监控报警MySQL主从延迟达到了30秒以上而正常应该在1秒以内如何排查并解决我给的排查思路是分层的。先看从库状态用SHOW SLAVE STATUS\G命令关注Seconds_Behind_Master这个值同时看Slave_IO_Running和Slave_SQL_Running两个线程的状态排除IO线程或SQL线程断开的可能性。如果两个线程都在跑说明延迟是执行环节产生的。接下来看从库的CPU、内存和磁盘IO如果从库磁盘IO很高可能是因为binlog或relay log写入导致的考虑把binlog和relay log放在独立的磁盘。再往下要看主库的写入负载是否有大批量的UPDATE或DELETE操作如果有需要优化SQL或分批次执行。有一个很容易被忽略的点如果主从服务器时间不同步Seconds_Behind_Master这个值会不准。所以在排查延迟以前先确认ntp/chrory时间同步是否正常这是经验之谈笔试时主动提出来会加分不少。3.4 脚本编程题用Shell完成日志分析2017年滴滴笔试出现过一类题给出一个Nginx访问日志要求统计出访问量最大的前10个IP、以及每个IP访问了哪些URL。这题考的就是awk、sort、uniq的组合使用属于基本功但如果平时生产里用过回答会很快。我的标准答案是cat access.log | awk {print $1} | sort | uniq -c | sort -rn | head -10。这里有几个管道命令的作用要能说清楚sort用来排序uniq -c用来去重并统计次数sort -rn表示按数字逆序排序。这个组合在日志分析里非常常用笔试考它是有道理的。进阶版本会要求统计某个URL的响应时间分位数这需要awk对$NF最后一列做计算配合sort -n和percentile算法。Python版本要更直接一点用pandas读日志groupbyagg就能解决。我个人的经验是笔试时能用shell就用shell因为Shell是运维的基础标签用Python是加分项但shell答不出来就被动了。4. 避坑指南与面试准备策略4.1 笔试中最常见的丢分点根据我批改笔试和听候选人复盘的经验丢分最多的地方不是难题不会做而是简单题答得不完整。比如题目问“如何查看系统负载”很多人的回答是uptime这确实是对的但少了“结果怎么解读”这一层。负载值3.0到底意味着什么要看CPU核数如果是4核的机器负载3.0说明系统还有余量如果是2核的机器负载3.0说明已经超负荷了。只答命令不答解读在笔试中会显得缺乏深度在面试中也会被追问到露馅。另外操作步骤题一定要区分“检测”和“处理”两个阶段。比如问题“磁盘空间不足如何处理”有人直接写rm -rf这在新手答案里屡见不鲜。但严谨的流程一定是先df -h确认哪个分区满了再du -sh找大文件目录然后结合业务确认哪些文件能删、哪些要归档迁移最后才是清理操作。这道题在现实中稍有不慎就是事故笔试里考察的就是你有没有风险意识。4.2 面试官真正关注的三个底层能力笔试后通常紧接一面或二面。滴滴运维岗面试官在评估候选人时明显会关注三个底层能力。第一个是排查问题的路径感。面试官抛出一个故障场景他不会只看你的最终结论更在意你是不是沿着一条合理的路径在走。先看现象、再看系统状态、再缩小范围、最后定位到具体模块整个过程体现的是一种“侦探式”思维。如果候选人一上来就猜是某个原因但又说不出为什么排除其他可能分数不会高。第二个是Google/搜索引擎的使用能力。这听起来不像一个面试考核点但面试官非常在意你会不会自己找答案。一个合格的运维面对陌生报错时的第一反应不是问人而是先搜索、先查官方文档。面试时如果能把“我遇到这个问题时会先看官方文档里对XX参数的说明然后搜索类似案例”这样的思路说出来反而比背标准答案更有说服力。第三个是工作习惯与文档意识。运维工程师很容易变成口头沟通、口头交接的状态但大厂对运维的要求是每处理一起故障都要有记录、有复盘、有改进。笔试里如果有描述类题目不妨在答案里体现出“我在操作时会把变更步骤和结果记录下来”的习惯这是隐性加分项。4.3 如何高效准备运维岗笔试一个实操性很强的方法我知道很多同学准备笔试题时最大的困惑是“不知道从哪里下手”。这里分享一套我验证过很多次的方法特别适合有两到三个月准备周期的朋友。第一阶段第1~3周把Linux系统基础打牢。不要只刷题要真正在一台虚拟机上练习。装一个CentOS或者Ubuntu每天做一件具体的事比如配置一个Nginx静态站点写一个定时备份脚本搭一个MySQL主从。通过动手命令不用背也记住了。第二阶段第4~6周主攻网络和排障。这个阶段推荐读《TCP/IP详解》第一卷的精选章节重点看TCP状态机和超时重传机制。同时练习tcpdump抓包分析三次握手和四次挥手的过程。当你真的看到SYN、ACK、FIN这些包在网卡上流过时对网络的理解会上一个台阶。第三阶段第7~8周刷真题和模拟题。把滴滴2017年这套题按章节拆开每两天做一个领域做完后对照解析复盘这道题我当时为什么没想到这个思路是知识点缺失还是排查路径有问题把错题对应到知识点清单里回头去补。我见过有些朋友把真题刷了三遍每一遍都有新收获原因就是每次复盘的深度不一样。最后补充一点心态上的建议运维岗笔试考察的知识范围广但没有特别偏门的题所有考点最终都能归到“保障系统稳定运行”这一个目标上。准备时不要抱着应付考试的心态而是把每道题当成一次生产故障的预演。带着这个视角去准备笔试过不过另说你作为运维工程师的底子一定会扎实很多。