2017年秋天网约车大战刚消停没多久滴滴的业务量还在疯狂往上窜那会儿我正好在准备秋招投了不少互联网公司的运维岗。滴滴的笔试是让我印象比较深的一场——题量不算大但考察面铺得很开从Linux命令到网络排查、从数据库优化到脚本编写都有涉及而且题目很接地气基本都是在模拟线上真实会遇到的问题。不像有些公司喜欢出操作系统有几大模块这种八股滴滴更想知道你拿到一台服务器、一个线上故障的时候脑子里有没有一套清晰的排查路径。这篇文章把我当时整理的高频考点和解题思路做了个汇总每道题都附了分析和参考解答。毕竟是回忆版不可能跟官方原题一字不差但考点方向是准的对准备运维岗笔试、尤其是想去大厂做SRE/运维开发的朋友应该能省不少事。1. 2017年秋招运维笔试的整体格局与考察思路先说下当时的背景。2017年的滴滴已经不是补贴大战初期那个草台班子了日订单量千万级起步出行业务对实时性的要求极高——你要叫车系统得在几秒内完成派单、调度、价格计算一整套链路。这种业务形态决定了他们的运维团队必须搞定三件事高并发下的稳定性、跨地域的多机房容灾、以及快速迭代带来的频繁变更管理。所以那年的运维笔试题有个很明显的特点不考死记硬背考的是你遇到这个问题会怎么处理。同样是问Linux命令他不会直接问你查看磁盘空间的命令是什么而是给你一个场景线上服务报错说磁盘满了你怎么定位是哪个目录占的空间这就是在模拟一个运维每天都要干的活。从题型分布上看大致可以分为这几类考察方向大致占比常见题型Linux操作系统与常用命令25%场景描述题、命令拼写题网络基础与故障排查20%简答题、排查思路题数据库MySQL为主15%SQL优化、主从复制原理缓存Redis为主10%数据结构辨析、异常场景处理Shell/Python脚本20%手工编写脚本、看脚本说结果负载均衡/监控/安全10%方案设计题、概念辨析这个比例并不是我随便拍的是当时考完跟几个一起笔试的同学对题之后拼出来的印象。可以看出Linux和脚本占了将近一半这跟运维岗的日常工作重心完全一致——大部分时间就是跟服务器和自动化工具打交道。还有一个细节值得注意滴滴的笔试里几乎没有出Windows相关的题目清一色Linux。这其实也是国内互联网公司的普遍倾向如果你只会Windows Server那套在互联网运维方向确实不太吃香。2. Linux系统高频真题不是考命令是考排查思路Linux类的题目是整张卷子的重头戏而且出题方式特别场景化。他们不会单独问你一个命令而是会让你在一段故障描述里判断该用哪个命令、怎么一步步定位。这种题考的其实是你有没有形成自己的排查SOP。2.1 系统负载突然升高怎么查这个是当年笔试里出现频率最高的一道题几乎每一批考生都遇到了。完整描述大概是线上服务器负载从0.3飙到8.0你作为运维怎么排查我当时的答题思路分四步也是后来实际干活总结出来的顺序第一步先确认负载是怎么回事。跑uptime看1分钟、5分钟、15分钟的负载趋势如果1分钟特别高、15分钟很低说明是刚刚突发的如果三个值都很高说明已经持续一段时间了。再跑top按CPU占用排序看是用户态进程%us高、内核态%sy高还是等待IO%wa高。这三个方向对应的处理方式完全不同——用户态高可能是业务代码死循环内核态高可能是系统调用太频繁%wa高则是磁盘IO瓶颈。第二步根据第一步的结果深入。如果是进程占CPU高用top -H -p 进程ID看到线程级别再用strace -p 进程ID看它在调什么系统调用。如果是磁盘IO导致的高负载用iostat -x 1看util和awaitutil超过80%基本就能断定磁盘扛不住了。第三步查是不是有什么定时任务扎堆。很多线上问题是crontab里大家都在同一分钟跑脚本导致的cat /var/spool/cron/root或ls /etc/cron.d/翻一下看到一堆任务都排在整点那就八九不离十了。第四步才是考虑业务流量是不是真的涨了。查一下Nginx或网关的访问日志看看QPS是不是比平时翻了几倍。这一步放在最后是因为——如果真是流量涨了那负载高就是正常现象你要做的是扩容而不是排查问题。我后来跟几个在滴滴做运维的朋友聊他们说这题考察的核心不是你会不会看负载而是你能不能区分负载高是坏事和负载高是因为业务在涨这两种情况。这个区分很重要很多新手一看到负载高就慌其实业务大促的时候负载不高才说明系统有问题。2.2 磁盘空间告警的完整处理链路磁盘满了是运维面试的经典场景滴滴笔试也考了而且问得特别细。我记得原题大致是某台服务器的数据盘使用率达到95%告警已经触发了你要在不停服的情况下把使用率降下来怎么做这题的关键词是不停服所以像重启一下这类的回答直接扣分。正解是分两步走先找大文件再安全清理。找大文件的标准命令组合是# 先看哪个目录占的空间最大逐层下钻 du -h --max-depth1 /data | sort -rh | head -20 # 找出所有大于500M的文件 find /data -type f -size 500M -exec ls -lh {} \; | sort -k5 -rh找到大文件之后不要直接rm先确认它是不是被进程占用。这里有个运维老坑如果一个文件被正在运行的进程打开了你用rm删掉df看到的磁盘占用并不会释放因为进程还持有这个文件的句柄。正确做法是lsof | grep deleted找到持有已删除文件句柄的进程然后告诉业务方重启这个进程或者你直接kill掉如果这个进程允许重启。另外当年笔试也考了硬链接和软链接的区别。软链接可以跨文件系统硬链接不行软链接可以链接目录硬链接不行其实Linux原生硬链接不可以指向目录删掉原文件后软链接会失效但硬链接仍可访问。日常用得最多的地方是日志切割后保留软链以及用ln -s做版本切换——比如把/usr/local/nginx软链到nginx-1.12.2目录升级时改个软链就行。2.3 进程管理你是怎么杀掉一个杀不掉的进程有一道送分题也很典型某个进程正常kill不掉你会怎么做考察的是对Linux信号机制的理解。常规流程是先kill 进程ID发SIGTERM如果进程不响应再kill -9 进程ID发SIGKILL。但如果连SIGKILL都不好使一般是这个进程进入了D状态不可中断的睡眠多数是在等待磁盘IO。这种情况你杀也没用得等IO恢复或者查是不是有NFS挂载点失效了。还有一道跟nohup相关的题用nohup java -jar app.jar 启动服务后为什么关掉终端后进程还是活着原理是nohup让进程忽略SIGHUP信号而把它放到后台。但要注意如果有人用了setsid或systemd托管进程那它的生命周期就跟终端更没关系了。这个考点在容器化普及之前几乎是必考的现在问得少了但作为基础原理还是值得掌握。3. 网络题里的送分与送命从TCP到HTTP状态码网络部分的题量没有Linux大但区分度很高。简单题大家都拿分难一点的能拉开差距。滴滴那年考了不少跟真实业务相关的网络问题毕竟是做网约车的线上网络链路的质量直接决定了乘客和司机端体验。3.1 TCP三次握手为什么是三次而不是两次这题听起来是基础但能答得好的人不多。大多数人都会背SYN、SYN-ACK、ACK但被问到为什么不是两次就卡住了。我的理解是三次握手的核心目的是让通信双方确认彼此的收发能力都正常。第一次握手客户端发了SYN服务端收到后知道客户端发送能力没问题第二次握手服务端回SYN-ACK客户端收到后知道自己发送没问题、接收没问题服务端的发送和接收也都没问题但此时服务端只知道客户端能发还不知道客户端能不能收所以还需要第三次握手客户端回一个ACK服务端收到后确认客户端接收能力没问题。如果你答两次握手会存在半连接、历史重复报文干扰也可以——这属于实现层面的原因。当年这种题基本是送分的但要是答得磕磕巴巴还是会扣印象分。3.2 从502 Bad Gateway发散出去的排查体系HTTP状态码的题几乎年年有。滴滴笔试里有个题是线上API网关出现大量502你怎么排查这道题考察的不只是502表示网关收到上游无效响应这层含义而是一整套排查链路502的本质是Nginx作为反向代理向后端应用服务器发请求后没有得到有效响应。可能的原因有很多需要逐个排除先用curl -I验证看是不是所有路径都502还只是某个接口。如果只是某个接口大概率是这个接口的上游服务挂了或者代码抛异常。然后查Nginx的error.log常见的报错是connect() failed (111: Connection refused)和upstream timed out。前者说明后端的服务端口根本没监听——用ss -lntp | grep 8080确认服务是否在跑后者说明服务活着但响应太慢——用top看后端进程CPU用tail -f看应用日志是不是有慢查询或者死锁。再往下就是网络层中间有没有防火墙或安全组把端口拦了有没有跨机房跨区域的专线抖动。当时滴滴的业务是私有云公有云混合部署跨网络访问很常见所以这类网络问题他们比较看重。用mtr看链路丢包率用telnet 目标IP 端口验证端口通不通是排查网络问题的基础三板斧。3.3 DNS解析慢一个容易被忽视的线上事故源头那套卷子里还有一道DNS题用户反馈App加载很慢经排查发现是域名解析耗时1秒以上你怎么定位和优化问题定位上dig www.xxx.com trace能看到每一级DNS服务器的响应耗时dig www.xxx.com能看本地DNS的解析结果和总耗时。问题可能在几个环节本地DNS服务器递归查询慢、上游权威DNS响应慢、或者域名配置了多条A记录但其中一部分IP不可达。优化手段也分几层调低本地DNS的缓存时间TTL让域名解析结果在客户端多缓存一会做HTTPDNS绕过系统的DNS解析直接通过IP访问这在移动端App里用的比较多还有就是在服务端支持多IP避免单点。这个知识点我觉得现在依然很实用做移动端业务的公司对DNS的依赖特别大能把这个讲清楚面试官会觉得你真的在线上处理过问题。4. MySQL与Redis数据库类真题的三板斧数据库相关题目在运维笔试里占的比例不算小主要考MySQL和Redis。滴滴的业务对数据库依赖极重订单、支付、用户信息全都落在MySQL而高并发场景下Redis又是扛流量的主力。所以这两块几乎是必考。4.1 MySQL主从复制原理与延迟处理请简述MySQL主从复制的原理以及主从延迟怎么解决——这题在滴滴笔试里出现过也是互联网公司运维面试的经典问题。原理层面要答清楚三个线程主库的Binlog Dump线程把二进制日志发给从库从库的IO线程接收日志并写入中继日志Relay Log从库的SQL线程回放中继日志更新数据。为什么会有延迟关键就在于SQL线程是单线程回放而主库是并发写入从库的复制速度赶不上主库的写入速度。解决主从延迟的思路有几条拆分业务把实时性要求高的读流量打到主库或缓存升级MySQL到多线程复制版本提升SQL线程并行度优化慢SQL降低主库的写入压力还有就是把大事务拆小避免一个超大事务阻塞回放。我见过很多运维在这块吃亏原理背得滚瓜烂熟但一问到你怎么判断当前延迟大不大就答不上来了——这个简单show slave status\G里面Seconds_Behind_Master字段就是主从延迟的秒数。4.2 慢查询优化一条SQL暴露你的调优功力笔试里给了个具体场景某条查询订单列表的SQL执行时间从几十毫秒涨到两秒多从哪几个方向排查优化这题在笔试里算难度中上的因为在纸上写不出真实执行计划但可以写出排查思路第一步先EXPLAIN SELECT ...看查询计划重点看type字段能不能到ref或者const级别是不是全表扫描ALL看key字段用到哪个索引看rows估算扫描了多少行。第二步分析SQL写法是否有问题比如SELECT了不必要的列、在索引列上用了函数导致索引失效WHERE DATE(create_time) 2017-09-01这种写法就不会走索引要改成WHERE create_time 2017-09-01 00:00:00 AND create_time 2017-09-02 00:00:00。还要注意隐式类型转换字符串列和数字比较会导致索引失效。第三步看是不是表数据量涨了但索引没跟上。单表数据量过千万之后即使有索引普通B树的查询效率也会下降需要考虑分库分表或者归档冷数据。我当时还补充了一个点先看连接池是不是被打满了因为有时候慢查询不是SQL本身的问题而是数据库连接被占满、请求在排队。这个点让面试官觉得我确实处理过类似的事故。后来工作里也验证了这个判断——很多慢查询问题最后根因不在SQL而是连接池配小了。4.3 Redis高频数据结构和缓存雪崩Redis的部分那年考了缓存穿透、缓存击穿、缓存雪崩这个经典三兄弟还加了一道Redis有哪些数据结构分别适合什么场景。数据结构这道题基本是送分String适合存用户信息、计数Hash适合存对象属性List适合消息队列Set适合去重、共同好友ZSet适合排行榜。滴滴的业务里ZSet用得挺多司机接单排行榜、热门路线统计都可能用到。三道缓存问题要分清楚缓存穿透查询一个不存在的key缓存和数据库都没有请求直接打到数据库。解法是布隆过滤器、缓存空值。缓存击穿某一个热点key突然过期大量请求同时打到数据库。解法是互斥锁、热点数据永不过期加逻辑过期时间。缓存雪崩大量key同时过期导致数据库压力骤增。解法是过期时间加随机数打散或者用多级缓存。有一道扩展题我印象很深如果Redis集群整个挂了流量直接打到MySQL你会怎么做这个场景在运维笔试里算高阶题了我给的思路是先做限流降级把非核心请求直接返回兜底数据再让DB的读写分离扛住一部分读写都走主库基本是扛不住的同时紧急重启Redis集群优先恢复对核心链路的支持。这道题没有标准答案考的是你在极端故障下的决策优先级。5. 脚本与自动化笔试中最能拉开差距的部分脚本题是运维笔试里区分度最大的一块也是最能体现这个人是真写代码还是只会背命令的部分。滴滴的笔试题里有一道日志分析题和一道监控脚本题几乎每年都有人挂在上面。5.1 统计Nginx日志中访问量前十的IP这道题我印象太深了因为当年考完出来大家都在对答案。题目描述给你一个Nginx的access.log每行格式是IP - - [日期] GET /xxx HTTP/1.1 200 531 -写一条命令或脚本统计出访问量排名前10的IP。用Shell实现是最常见的解法awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这个解法看着简单但考察了三个点awk取字段、sort排序、uniq去重统计。有个细节是uniq只能统计相邻的重复行所以必须先sort再uniq -c很多人第一次写会漏掉sort统计结果全乱。更进一步如果日志量非常大比如几个GB单机跑这条命令会卡半天。那就要考虑用别的办法比如用grep先过滤出某个时间段的日志再统计或者用Python写流式处理import re from collections import Counter ip_pattern re.compile(r^(\d\.\d\.\d\.\d)) counter Counter() with open(access.log, r) as f: for line in f: match ip_pattern.match(line) if match: counter[match.group(1)] 1 for ip, count in counter.most_common(10): print(f{count}\t{ip})Python的好处是你可以直接在脚本里加条件——比如只统计POST请求或者只统计响应码为500的请求这些用一条awk就能搞定但如果要做更复杂的逻辑Python更顺手。笔试时如果能写出两种解法并说明各自的适用场景会很加分。5.2 写一个CPU使用率监控脚本还有一道脚本题是写一个Shell脚本监控CPU使用率超过80%就发送告警打印日志即可。这道题考的不只是命令还有逻辑完整性。#!/bin/bash THRESHOLD80 LOG_FILE/var/log/cpu_alert.log while true; do CPU_USAGE$(top -bn1 | grep Cpu(s) | awk {print $2 $4}) INTERGER_CPU${CPU_USAGE%.*} if [ $INTERGER_CPU -gt $THRESHOLD ]; then echo $(date %Y-%m-%d %H:%M:%S) CPU usage: ${CPU_USAGE}% $LOG_FILE fi sleep 5 done这里有几个坑要注意。第一个坑是top -bn1的-b参数不加这个参数top会进入交互模式脚本会卡住-n1表示只执行一次。第二个坑是CPU使用率的计算方式——top输出里的%us和%sy才是用户态和系统态的占用百分比有些版本的top还带%wa等待IO到底加不加这个值取决于你想监控的是什么。第三个坑是脚本要设置sleep间隔不然会无限循环把CPU打满形成一个监控工具自己占用过高CPU的乌龙。这个脚本在笔试现场能写出来的人不多但考题本身并不难主要考察候选人对Linux命令输出的敏感度——你天天用top知不知道它非交互模式怎么输出这也侧面说明运维平时要多积累命令的输出格式不能只会看不会用。5.3 自动化思维当你需要连到100台机器执行命令滴滴笔试还有一类比较进阶的题目不直接考语法考方案设计。我记得有一道类似这样的某个版本上线的配置变更需要在100台机器上同步更新一个配置文件假设所有机器都可用且SSH端口一致你会怎么做不允许用Ansible之类的工具这道题考察的是最原始的批量操作思路。基本解法是写一个for循环for ip in $(cat server_list.txt); do scp nginx.conf root${ip}:/etc/nginx/nginx.conf ssh root${ip} nginx -t systemctl reload nginx echo ${ip} OK || echo ${ip} FAIL done但要是往深了说这道题其实是在问你有没有想过批量操作会踩哪些坑比如scp遇到主机密钥确认会卡住要加-o StrictHostKeyCheckingno比如有些机器连不上会导致命令整条卡在那里要加-o ConnectTimeout5比如reload失败后要不要回滚回滚脚本是什么这些细节才是真实运维中决定成败的部分。能想到这一层的人说明他真的一台一台操作过大量服务器。6. 负载均衡、监控与安全方案设计题的隐形门槛滴滴笔试的最后一个容易丢分的板块是负载均衡、监控体系、安全加固这类偏架构设计的题。这类题占比不高但往往是区分普通运维和高级运维的分水岭。6.1 Nginx负载均衡策略请列出Nginx支持的负载均衡策略并说明各自适用场景——这个题当年我估计能答全的人不多。Nginx默认的策略是round-robin轮询按请求顺序轮流分配到后端服务器适合后端服务器配置相近的情况。least_conn是按当前连接数分配把请求分给连接数最少的服务器适合长连接场景。ip_hash是按客户端IP做哈希同一IP的请求会落到同一台后端服务器适合需要session保持一致但没有共享session服务的场景。还有weight权重轮询给配置高的服务器配更大的权重让它们多承担一些请求。深入一点的话还有fair按后端响应时间动态分配和url_hash按URL哈希适合缓存场景但这俩不在Nginx默认编译里需要安装第三方模块。笔试里提到这两点会显得你有广度但没提也不扣分。6.2 高可用架构设计你会怎么搭一套不挂的服务有一道方案设计题是假设你负责一个核心API服务要求全年可用性达到99.99%请画出你的架构设计并说明关键组件。虽然禁止用mermaid图但答题时文字描述要完整。我的思路是这样的前端挂一个统一的SLB或LVS做四层负载均衡上面用Keepalived做VIP漂移保证负载均衡器本身不单点。后端挂至少两台Nginx做七层反向代理Nginx后面挂多台应用服务器应用服务器做无状态化设计这样任意一台挂掉流量会自动切到其他节点。数据库用MySQL主从复制业务层读写分离Redis做缓存并且部署成集群保证缓存也不是单点。这个架构的关键在于每个可能出现故障的环节都要有冗余。负载均衡器会挂所以要有主备应用服务器会挂所以要有多台数据库会挂所以要有主从。没有冗余就没有高可用——这句话是整道题的核心。6.3 监控体系与告警设置监控类的题在那年笔试中出现频率不低滴滴的运维团队对监控的重视程度很高这也是大型互联网公司的共同特点。有一道题问的是线上服务突然不可用但你没有收到任何告警排查监控系统本身你会怎么做这道题考的是告警链路的理解。一条告警从产生到通知到你链路很长数据采集、数据存储、告警规则判断、告警发送、消息触达。任何一环出问题都会造成服务挂了但没人发现。排查看链路先确认采集端有没有挂看node_exporter当时流行的是Zabbix agent状态再确认数据有没有写入监控存储查监控面板看agent上报的数据曲线还有没有波动然后看告警规则配置有没有被动过比如阈值被误改、规则被禁用最后看告警通知渠道钉钉/邮件/短信的webhook有没有异常。我在实际工作中就遇到过因为webhook地址过期导致告警全部静默的情况排查了半天才发现是通知渠道的问题。6.4 安全加固两个必答题安全类的题在运维笔试里考得不多但几乎每次都会有一道SSH加固或DDoS的简答题。SSH加固的常见手段要能列出来修改默认端口22为其他端口禁用root直接登录PermitRootLogin no使用密钥认证、禁用密码登录配置AllowUsers限制可登录用户设置MaxAuthTries限制重试次数有条件的话用fail2ban做暴力破解拦截。DDoS那块考的是思路而不是具体配置在云厂商的DDoS高防上做流量清洗利用CDN节点分散攻击流量Web层的CC攻击用限流验证码缓解还有就是在网络入口配置ACL丢弃异常协议包。2017年DDoS攻击已经规模化了滴滴这种体量天然是攻击目标所以这个考点并不意外。7. 从这批真题反推滴滴运维工程师的能力画像把所有题目过了一遍之后你会发现这些考题并不是随机拼凑的它背后有一条很清晰的逻辑——滴滴在挑选的不是会背Linux命令的人而是能把问题定位清楚的人。整张卷子贯穿始终的一个思维模式就是现象负载高了/502了/查询慢了→ 分层排查 → 定位根因 → 修复验证。这也是运维这个岗位最核心的能力模型。如果你准备的是现在的运维笔试这堆内容基本还能用但建议在几个方向上做个升级容器化Kubernetes和Docker已经是必考项了云原生相关的服务发现、配置中心、可观测性Metrics/Logging/Tracing三件套也是高频考点。2017年那会儿OpenStack还在流行现在再问OpenStack的公司已经不多了但Linux、网络、数据库、脚本这几个底子任何时候都不会过时。我个人还有个体会笔试刷题只是第一步真正的分水岭在动手能力。你可以在卷子上写出完美的awk统计命令但如果你没有真的在服务器上处理过几G的日志、没手动搭过一遍MySQL主从、没经历过一次凌晨四点的线上告警面试官多问两句就能看出来。运维是个经验驱动很强的工种知识储备和实战经验缺一不可。刷完这套题我最大的收获是建立了一个认知大厂运维笔试的尽头不是背功而是逻辑。拿到任何一道题先别急着写答案问自己一句——这道题在真实场景里对应的是什么问题顺着这条线去答题即使遇到没见过的题目也不至于完全抓瞎。如果你正在准备运维岗建议把从发现现象到定位根因的每一步都写下来反复推演练多了笔试和面试都会顺很多。