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，有的做云架构师，共同特点都是从来不满足于“能用就行”，而是一直在追问“为什么”。如果你正在准备运维岗的笔试，刷题之余，多动手搭环境验证，多读些系统底层和协议相关的书，这些长期积累带来的回报，远比临时背题大得多。
