从滴滴运维真题看Linux笔试高频考点与故障排查思路

1. 这份真题一份值得细读的运维能力画像前两天整理电脑资料翻出一份2017年滴滴出行秋招运维岗的笔试题目来回看了几遍觉得挺有意思。那会儿正值网约车业务快速扩张期滴滴的运维团队承担着非常大的线上压力笔试题目自然也不是随便出几个命令题应付了事。整套题覆盖了Linux基础、网络协议、脚本编写、数据库、故障排查等多个方向很多题目到现在拿出来看依然是运维面试里的常客。我自己做运维也有不少年头了从最初在IDC机房搬服务器到后来维护云上几万台实例中间换过几家公司也帮别人筛过简历、出过面试题。说实话一份笔试题目最能反映一个团队对运维岗位的真实定位到底是把你当网管使还是希望你能真正扛住线上稳定性压力。滴滴这份题偏向后者——它不考偏题怪题考的都是一线运维日常必然会遇到的东西但深度上比普通公司的题目要扎实不少。这篇就拿这份真题当引子顺着题目覆盖的模块把运维笔试里最常出现的考点、出题逻辑、答题思路和踩坑点一次性讲透。不管你是准备校招、社招还是单纯想摸底自己的运维基本功认真看完应该都有收获。需要先说明的是网上流传的版本大多是当年笔试同学的回忆整理我下面提到的题目是结合这些回忆和同类岗位的考察范围做了还原和重构重点在于考点分析和解题思路而不是逐字逐句照搬原卷。2. 题型拆解笔试各模块的考点与出题逻辑2.1 Linux基础知识不止是背命令运维笔试的第一道坎通常都是Linux基础。滴滴这份题也不例外文件权限、进程管理、系统资源查看这些都有涉及。但和很多小公司直接问“如何查看CPU使用率”这种送分题不一样稍微有水平的题目会把知识串起来问比如“请说明 top、free、df、iostat 这几个命令分别侧重查看哪类资源如果系统负载突然升高你如何一步步定位是CPU、内存、磁盘还是IO问题。”这种题考的其实不是命令本身而是你有没有建立系统性的排查意识。单纯背命令的人能答出来第一条、第二条但往往到第三步就乱了。我自己面试的时候也会用这种开放式题目来筛人因为运维这个岗位命令会多少永远不是核心核心是遇到问题的时候脑子里的排查链路是不是清晰的。另外一个高频考点是文件系统与inode。很多同学对df -h和df -i的区别不敏感觉得反正都是看磁盘空间。但在真实生产环境里inode耗尽导致无法创建文件的情况很常见尤其是在跑大量日志、大量缓存小文件的业务上。有个运维朋友之前就遇到过日志目录里上千万个小文件直接把inode打满df -h看还有几十GB空间但应用就是报磁盘写入失败。这道题如果笔试里出现“磁盘空间显示充足但业务报无法写入文件请说明可能原因”你脑子里一定要有inode这个答案。还有一类经常出现在笔试里的题目是软链接和硬链接的区别。这类题看起来基础但能拦住很多人特别是硬链接和软链接对inode的影响、跨文件系统能否创建硬链接、删除源文件后链接是否还有效这些细节。备考建议很简单自己搭一个虚拟机空文件、写内容、建硬链接、建软链接、删源文件一步步试一遍比死记硬背强十倍。2.2 网络基础能讲清三握四挥才不算白学网络这一块在滴滴运维岗笔试里占的比重不小毕竟网约车业务对网络链路和实时性要求很高订单调度、位置上报、支付回调任何一环网络抖动都直接影响用户体验。TCP三次握手和四次挥手几乎是必考题。但考察方式不只限于“描述三次握手过程”这种默写题更多时候会结合实际场景“一台服务器上出现大量TIME_WAIT状态的连接可能是什么原因会对业务造成什么影响如何解决”这个题目背后涉及的知识点很丰富TIME_WAIT是主动关闭方在四次挥手中进入的状态作用是确保旧连接的报文在网络中消失避免影响新连接。服务器上TIME_WAIT多通常说明服务端主动关闭了大量短连接可能的原因包括连接池配置不合理、负载均衡健康检查频率过高、高并发短连接场景下没开复用。解决方案也分几个层级应用层可以调整连接池、改用长连接内核层可以开启tcp_tw_reuse但要注意场景不是无脑开再不行就从架构层面考虑比如减少直接暴露的短连接入口。HTTP状态码这个知识点也是笔试里的常客。201身上、502、503、504这几个运维最常碰到的状态码笔试里会让考生说明含义和排查方向。比如504 Gateway Timeout通常要查的是后端服务是否真的慢、代理层超时配置是否合理、后端到数据库或下游服务的链路是否异常。很多人只答了“网关超时”四个字这种答案基本拿不到分要的是后面的排查思路。DNS解析流程也是一个值得好好准备的方向。从浏览器访问一个域名开始依次经过本机hosts、DNS缓存、本地DNS服务器、根服务器、权威服务器整个链路中任何一环出问题都可能导致解析故障。笔试里如果问“用户反馈某个域名偶尔解析失败你怎么排查”答题思路应该按“本机缓存 → DNS服务器 → DNS配置 → 域名解析记录 → 网络连通性”这个顺序展开一层层排除。2.3 Shell脚本与自动化运维的基本功试金石滴滴这份题里Shell脚本相关的比重也不小这是正常现象。运维这个岗位说白了就是把大量重复的工作自动化掉而Shell脚本是自动化最基础的手段。笔试中常见的考察方式有两种一种是给你一个场景让你写出完整脚本另一种是给一段脚本让你找错或说明执行结果。比较典型的一道题是“编写一个Shell脚本统计Nginx访问日志中访问量最大的前10个IP并输出访问次数。”这道题考察的是对文本处理命令的熟悉程度。标准解题思路用 awk 提取IP字段再配合 sort、uniq -c、sort -nr、head -10 完成统计。命令本身不难但能不能在纸上写完整、能不能考虑日志格式差异、能不能处理字段分隔符变化这些细节就拉开了差距。我见过不少简历上写“熟悉Shell脚本”的同学这道题都答不完整要么管道的顺序写错要么忘了uniq需要先sort要么没考虑文件路径不存在的情况。另一类常见题目是定时任务相关的场景题“业务方提出每天凌晨3点执行数据清理脚本如果当天服务器3点时负载很高你如何设计这个定时任务以保证清理任务能顺利执行并不过度影响业务”这题考的不只是crontab写一行配置那么简单还涉及系统负载判断、脚本锁、日志记录等工程化思维。比较好的答案会提到在crontab里设置计划比如3点但脚本内部先判断系统负载超过阈值就往后延时同时脚本要加锁防止重复执行执行日志要单独落文件方便后续排查。能把这一层想清楚的人说明真的在生产环境里踩过坑。2.4 数据库与中间件没有分布式概念会吃大亏数据库在运维笔试里是绕不开的模块。滴滴这类业务对数据库的依赖非常大MySQL的使用深度也比较高。笔试中经常出现的考点包括索引失效场景、慢查询优化、主从复制原理与延迟、事务隔离级别、常见的高可用方案等。索引这块最常见的题目是“where条件中对索引列使用了函数操作索引是否还能生效请举出至少三种会导致索引失效的写法。”这题考的是对MySQL索引机制的底层理解。函数操作、隐式类型转换、前导模糊查询%xxx、or条件中包含非索引列都会导致索引失效。答题时如果能再补一句“用EXPLAIN看执行计划关注type列和key列”整体得分会更高因为这体现了你平时是真的会用工具分析SQL的。MySQL主从复制也是高频考点。笔试会用这样的方式问“主从延迟过大的原因有哪些有什么常见处理手段”参考答案至少要覆盖主库并发写入压力大、从库硬件配置弱、从库上跑了大量分析型查询、大事务执行时间过长、网络延迟等。处理手段包括优化大事务、从库开启并行复制、减少从库上的分析负载、提升从库硬件、增加只读实例分摊读压力。这个知识点在今天分布式数据库遍地走的背景下依然有意义因为很多企业还是在用MySQL一主多从的架构主从延迟问题会长期存在。中间件方面Redis是出现频率最高的。缓存穿透、缓存击穿、缓存雪崩这三个概念的辨析是必备题。很多同学容易把击穿和穿透搞混笔试里一旦出辨析题就翻车。我的记忆方法很简单穿透是请求了一个缓存和数据库里都不存在的数据击穿是某一个热点key过期瞬间大量请求直接打到数据库雪崩是大量key同一时间过期导致数据库压力骤增。这三者对应的解决方案也不同穿透用布隆过滤器或缓存空值击穿用互斥锁或热点数据不过期雪崩用过期时间加随机值、多级缓存、限流降级。3. 典型真题重现与答题思路剖析3.1 线上服务不可用你的排查顺序是什么这是一道我在多个运维岗笔试里都见过的高频场景题滴滴这份题里也有类似的表述“某天下午线上业务反馈服务不可用你作为运维工程师接手排查请描述你的排查顺序。”这种题没有标准答案但阅卷人一眼能看出你有没有真实处理过线上故障。比较稳的排查顺序是先确认故障范围是单台机器还是整个集群是个别用户还是全部用户再检查服务进程状态进程是否存活、端口是否监听接着看系统资源CPU、内存、磁盘、IO是否异常然后看应用日志有没有报错、有没有OOM、有没有明显的Exception最后再看网络链路负载均衡、防火墙、DNS解析是否正常。答题的时候需要特别注意顺序不能乱。很多人上来就查日志这在生产环境里是不现实的。服务器都连不上了你怎么查日志第一件事永远是搞清楚故障的影响范围和底层资源状态。所以这道题表面上考的是排查步骤实际上考的是故障处理时的优先级判断能力。如果答题时能加一句“处理过程中要同步向业务方同步进展”会显得更专业。3.2 CPU负载突高的定位方法另外一道很典型的真题是“服务器CPU使用率飙到80%以上如何定位是哪类进程或哪段代码导致的”这道题的经典答案链路是先用top查看哪个进程CPU高再用top加-H参数查看该进程下哪个线程CPU高然后把线程ID转成十六进制用jstack针对Java应用导出线程栈在线程栈里搜索对应的线程定位到业务代码行。如果是非Java应用可以配合perf top或者gdb来分析。这个链路本身不复杂但笔试里能完整写出来的人不多。很多同学只写到“用top看进程”就停了没有继续往下深挖线程和代码层面。实际上面试官想看到的恰恰是后面这几步因为这才是运维和技术支持拉开差距的地方。另外如果能补充一句“进程CPU高不一定就是应用本身的问题也有可能是频繁GC、死循环、锁竞争或者CPU亲和性设置不当”会显得你的知识面更完整。3.3 磁盘空间满却找不到大文件磁盘满的场景题在笔试里出现频率也很高而且出题方式很刁钻“服务器df -h显示根分区使用率100%但用du查看根目录下各个目录加起来远小于总占用空间可能是什么原因”这个现象在生产环境里非常经典某个日志文件被进程打开后又被运维或logrotate删除了在文件系统层面看不到这个文件du找不到但进程仍然持有该文件的文件描述符占用的空间不会释放。解决方法是使用lsof | grep deleted找到这个进程然后确认是否可以重启进程或者是让logrotate以更合理的方式处理日志文件。我当年第一次遇到这个问题时也懵了一段时间后来养成了排查磁盘问题先跑lsof的习惯。如果你在笔试里能把lsof这个命令答出来并且说明背后“文件被删除但fd仍被持有”的原理这道题基本就稳了。再往深了说还可以提到日志滚动策略的设计比如按大小切割、定期清理、日志集中收集等这样整个答案就有从“解决问题”到“预防问题”的升华。3.4 数据库慢查询的处理思路数据库相关的实操题滴滴笔试中常见的是“业务反馈某条查询很慢你如何分析并优化”答题时比较完整的思路应该是先确认慢查询是否存在开启慢查询日志或查看现有慢日志拿到慢SQL之后用EXPLAIN分析执行计划重点看type、key、rows三个字段根据执行计划判断是因为缺少索引、索引失效、查询了过多数据还是连表方式有问题然后进行针对性优化包括加索引、改写SQL、拆分大查询等最后观察优化效果并持续关注。这道题还经常延伸出一个坑很多人一上来就建议加索引但没分析为什么慢。加索引虽然是最常见的优化手段但索引不是万能的也不是越多越好。索引写多了一样有副作用会降低写入性能、增加存储开销。所以笔试答题时一定不能只给结论要把分析过程展示出来面试官真正想看的是你的判断依据和权衡思路。4. 当年笔试中最容易翻车的几个点4.1 会操作不会讲原理有不少工作过一两年的运维去参加笔试反而考不过应届生原因就在于平时都是“鼠标点一点”或“键盘敲一敲”从没想过底层是怎么回事。笔试题目一旦上升到原理层面比如“为什么ping不通但业务端口正常”“为什么删了日志文件空间没释放”就完全露馅了。我自己带人的时候也发现很多”熟练工“其实是在靠经验堆日子而不是靠原理在工作。一个很典型的例子是free命令的输出大部分人都知道看available和used但问起buff/cache的区别能讲清楚的人不多。其实buff是针对块设备的读写缓冲cache是针对文件系统的页缓存两者机制不同对内存回收的优先级也不同。笔试里一旦出现“如何理解free命令中的buff/cache”这类题最容易考的恰恰是这些平时被忽略的细节。备考建议很直接平时用命令没问题但每用一条命令都问自己一遍“这个输出里每一列代表什么含义”“如果数值异常可能的原因是什么”。这个过程坚持半年基础会非常扎实。4.2 排查题只写命令不画流程笔试场景题里最常见的翻车是只罗列命令没有逻辑顺序。比如问“网站访问很慢你怎么排查”有人能写出十条命令但顺序是乱的一会儿检查网络一会儿看数据库一会儿又回来看进程看起来什么都会实际上什么思路都没有。面试官看这种答卷第一反应就是这个人没处理过真实故障。真实故障处理跟做题不一样不是把工具都试一遍就能找到答案的你需要在一堆噪声中快速确定瓶颈。正确的方式是按链路分层排查客户端 → DNS → 网络链路 → 负载均衡 → Web服务 → 应用服务 → 数据库/缓存。每一层确认正常了再去下一层不要跳来跳去。笔试作答时也应该按照这个分层思路来写而不是命令大杂烩。4.3 忽视安全与权限管控运维笔试里还有一类容易被忽视的题目就是账号权限和安全管理。滴滴这份题里虽然没有单独的安全大题但在多个场景题里都隐含了权限管理的考察点。比如写脚本时是否考虑过用最小权限账号执行比如配置Nginx时是否留意过server_tokens关闭比如使用root执行日常命令是否合适。这些点在平时工作中容易被忽略但却是运维水平高低的体现。笔试答题时如果能在合适的场景里主动提一句“生产操作一定要走堡垒机审计”“脚本执行使用专门的服务账号不用root”会给阅卷人留下相当好的印象。这种安全意识不是突击背出来的是日常工作中真正养成的习惯。4.4 忽视日志管理和历史经验沉淀运维笔试里还经常出和日志相关的题目但多数同学只关注日志排查很少有人关注日志管理本身。比如“如何保证服务器日志不会把磁盘写满”“日志文件轮转怎么配置”“发生故障后如何采集现场信息”。这些问题的本质是运维不能只在出问题时救火更要提前设计好机制。设计日志轮转时需要考虑按天还是按大小切割、保留多少份历史日志、日志是否要压缩、切割后是否需要通知应用重新打开文件描述符。这些都是实际经验非Linux基础好的人不一定能答全但这就是运维岗位日常要面对的问题。笔试里如果能体现出这种“预防优于救火”的思路会显得比平均水平高出一个档次。5. 从笔试到实战这些考点在今天变成了什么5.1 传统运维技能在新场景下的演化2017年到现在技术圈的变化非常大。容器化、Kubernetes、云原生已经把运维的工作方式彻底改变了。当年笔试里考察的那些手工排查思路很多已经沉淀成了平台能力或自动化工具。比如以前定位CPU高要手动jstack现在直接在监控平台上点一下就能看到整条调用链的火焰图。以前处理主从延迟要手动登库执行命令现在数据库管理平台一键切换。但底层的知识体系和排查思路并没有过时。Kubernetes里Pod的调度、重启、日志采集本质上还是在跟Linux内核、网络、存储打交道容器里一个应用CPU飙升定位的手段依然是看进程、看线程、抓栈数据库慢查询优化不管数据库部署在物理机还是云上核心方法也还是分析执行计划、优化索引。基础不牢的人哪怕天天用炫酷的平台出了故障一样抓瞎。5.2 运维笔试的进化方向现在的大厂运维笔试跟2017年相比题目方向有了明显变化。除了传统的Linux、网络、Shell、数据库越来越多地出现容器化题目比如Docker镜像构建优化、Pod资源限制配置、Service与Ingress的区别、Kubernetes调度器的工作原理。甚至有些公司开始考持续集成和持续部署的流程设计考监控告警体系的搭建思路。但不管题目怎么变考察的核心能力始终是那几个维度对操作系统和网络底层理解的深度、面对故障时的排查逻辑、对自动化和效率提升的追求、以及预防性和安全性的思维。把这份滴滴早期真题里的考点吃透再往容器和云原生方向延伸学习应对今天的运维岗笔试依然可行。最后再分享一点我个人的体会。笔试只是进入一个团队的第一道门槛真正决定你能否在运维这条路上走远的是持续学习的能力和对系统底层原理的好奇心。很多当年一起入行的同事有的已经转去做开发有的做SRE有的做云架构师共同特点都是从来不满足于“能用就行”而是一直在追问“为什么”。如果你正在准备运维岗的笔试刷题之余多动手搭环境验证多读些系统底层和协议相关的书这些长期积累带来的回报远比临时背题大得多。