1. 运维开发笔试到底在筛什么人先聊聊这个岗位本身。运维开发工程师英文叫 DevOps Engineer 或者 SRESite Reliability Engineer在很多公司里也叫“应用运维”“平台运维”。和传统运维不一样的地方在于这个岗位的核心不是“守着服务器不宕机”而是“用代码把运维工作自动化”。换句话说你既要懂 Linux、网络、数据库这些基础设施又要会写 Python、Shell、Go 这类开发语言能自己撸工具、写平台、搭监控系统。滴滴的那场校招内推笔试本质上就是在筛这两类能力都达标的人。我记得当时收到内推链接后HR 邮件里附了一份笔试说明写了考试范围Linux 基础、网络基础、数据库、Python/Shell 脚本、算法基础、系统设计。当时一看就觉得这岗位真不是“会敲命令”就能进来的它要求的是“能解决问题的工程师”。为什么滴滴会这么考因为出行平台的业务场景太典型了。每天的订单量千万级司机端、乘客端、客服系统、支付系统、地图服务全都挂在线上任何一个服务抖动都会直接变成用户投诉。这时候运维开发要做的不是等人报警了再去重启而是提前把监控、告警、自动扩容、故障自愈这些能力做成平台化产品让业务方自己也能看数据、配策略。笔试考的就是你有没有这种“平台思维”和“自动化意识”。如果你现在正准备投运维开发岗不管目标公司是哪家这场笔试的题目结构和考察逻辑都有很强的参考价值。我把当时印象深的题目、踩过的坑、以及后来复盘时总结的经验整理出来希望能帮你少走些弯路。2. 笔试整体结构与时间分配2.1 试卷长什么样滴滴的运维开发笔试大概两个半小时题型分几块单选题大概 20 道覆盖 Linux、网络、数据库常识每道题不算难但覆盖面广。多选题大概 10 道比单选多一个坑容易漏选或者多选考的是对细节的准确记忆。编程题2-3 道用 Python 或 Shell 实现一些具体功能比如日志分析、文本处理、简单算法。系统设计题1-2 道给定业务场景让你设计监控方案或者自动化运维方案。整体感觉是客观题刷人编程题拉开差距系统设计题决定上限。如果客观题错太多基本就没戏了编程题写不出来面试也难约系统设计题答得好就算前面有小瑕疵面试官也愿意给你机会聊一聊。2.2 时间分配的策略我当时定的原则是“先客观题后编程题最后设计题”客观题控制在 40 分钟内完成编程题留 60-70 分钟系统设计题 30-40 分钟。为什么这么分因为客观题考的是记忆和理解看了不会就是不会纠结两分钟和十秒效果一样不如快速过把时间留给分值更高、更考察综合能力的主观题。这里有个教训我一开始在几道多选题上磨太久了特别是涉及 iptables 规则顺序和 TCP 状态转换的题目越想越不确定结果编程题的时间被压缩了。后来学乖了凡是客观题卡壳超过一分钟直接标记后跳过等全部做完再回头。2.3 涉及的知识域占比从记忆和复盘来看Linux 基础大约占 30%网络基础约 20%数据库约 15%编程题约 25%系统设计约 10%。这个配比其实很符合运维开发的日常工作日常操作要在 Linux 上完成出问题要懂网络排查数据要会查库效率提升要写脚本整体稳定性要做设计。3. 高频考点拆解与避坑3.1 Linux 基础不只是背命令Linux 这块的笔试题看着是选择题实际上是在考你有没有真实的操作经验。比如有一道题问 “ls -l 输出中硬链接数的含义”如果你只是背过答案是“硬链接数”没真正在文件系统里建过硬链接可能过几天就忘了。我建议准备时动手搭个环境把每个知识点过一遍。高频考点大概有文件权限chmod、chown、umask尤其是 rwx 对文件和目录的差异。进程管理ps、top、kill -9 和 kill -15 的区别僵尸进程怎么处理。系统负载load average 的三个值分别代表什么CPU 和 IO 负载怎么区分。文本处理三剑客grep、sed、awk其中 awk 的频率极高。软链接和硬链接inode 概念ln -s 和 ln 的区别。系统启动流程从 BIOS 到内核到 init/systemd了解每个阶段。拿 load average 举例很多人只知道“三个数分别代表 1/5/15 分钟平均负载”但笔试会深一层负载高一定是 CPU 满吗不是可能是 IO 等待。Linux 的 load average 计算包含了不可中断睡眠状态的进程D 状态如果磁盘性能差大量进程在等 IOload 也会飙升。这道题的坑就在于“负载高”和“CPU 高”是否等价答案是否定的。再看 awk 这种工具笔试不考你背语法而是给你一个日志文件片段让你选出能提取第 3 列和最后 1 列的命令。此时 $NF 这个内置变量就得能想起来awk {print $3, $NF} 和 awk {print $3, $5} 的区别一目了然。这种题光看不练一定会翻车。实操上最好在虚拟机里准备一套标准环境把系统监控、进程调优、日志切割这些操作过一遍。另外一个容易忽略的点是 systemd 的 systemctl 命令笔试中出现的频率逐年增高像 systemctl list-units --typeservice 和 systemctl status 的输出格式都要熟悉。3.2 网络基础七层模型和实际排查相结合网络这块的知识点面试官和出题人默认你是懂的但笔试题目会故意把“理论”和“实践”搅在一起。有一道题印象很深访问一个网站很慢怎么排查选项包括 ping、dig、curl -w、traceroute、ss -t。如果只背过“ping 测通不通”不知道 curl -w 可以显示 DNS 解析时间、TCP 连接时间、SSL 握手时间这道题就选不全。网络的高频考点TCP 三次握手和四次挥手每个阶段的状态尤其是 TIME_WAIT 和 CLOSE_WAIT 的产生原因和区别。DNS 解析流程递归查询和迭代查询的区别A 记录、CNAME 的区别。HTTP 状态码502、504、301、302、499 这些在运维中特别常见的码。负载均衡LVS、Nginx、HAProxy 的区别四层和七层负载的差异。iptables 规则nat 表和 filter 表的典型用法规则匹配顺序。TIME_WAIT 和 CLOSE_WAIT 是笔试的常客。TIME_WAIT 是主动关闭连接的一方进入的状态会持续 2MSL大约 60 秒大量 TIME_WAIT 多见于高并发的短连接场景解决方案是开启 reuse 和 recycle不过现代内核里 recycle 有点坑。CLOSE_WAIT 则是被动关闭方没调用 close()场景通常是程序有 bug连接不被释放。问你线上大量 CLOSE_WAIT 怎么排查答案不是调内核参数而是先找代码问题。HTTP 499 也是滴滴这类互联网公司喜欢考的因为 Nginx 日志里经常出现。499 代表客户端主动断开连接通常意味着后端处理时间太长用户等不及关了页面。这个状态码说明问题在后端慢而不是 Nginx 本身挂了对排查方向很有指导意义。TCP 连接状态图要多花时间看结合 ss 命令和 netstat -tunlp 去理解每种状态。不要死记硬背而是在本机模拟个场景比如开一个服务器、一个客户端用 tcpdump 抓包看握手挥手过程理解立刻就不一样了。3.3 数据库索引和锁是重头戏数据库考得比较常规但很看重对索引和事务的理解。比如有一道题某查询语句很慢explain 显示 typeALL应该怎么优化答案很直接——建索引让 type 变成 ref 或者 range。但如果只是背了“要建索引”不理解为啥覆盖索引能减少回表后面再考联合索引的最左前缀原则就蒙了。核心考点索引原理B 树结构聚簇索引和非聚簇索引的区别覆盖索引。最左前缀联合索引 (a, b, c) 能命中哪些查询。事务特性ACID隔离级别尤其是 RR 和 RC 的区别。锁行锁、表锁、间隙锁死锁产生原因。主从复制binlog、从库延迟排查。最左前缀原则这个点笔试特别爱出变体。联合索引 (name, age, city)以下哪些查询能使用该索引条件是 where namexx and age10 能用where age10 不能用where cityxx and age10 不能where namexx 能用。关键在于联合索引排序是按第一个字段、再第二个字段、再第三个字段跳过了前导字段直接用后面的字段索引就无法高效定位。还有一道题是关于主从延迟的问的是从库延迟增大排查方向是什么。选项包括检查从库所在机器的 CPU 和 IO、看大事务、看从库是不是在做备份、看主库 binlog 是否被清理。这几个都对因为它们确实是导致延迟的常见原因。这种题考的就是你有没有真实处理过主从延迟问题而不是只做过单机 MySQL。数据库的准备建议是装一个 MySQL用 explain 看几条 SQL 的执行计划再手动开启和关闭事务测一下不同隔离级别下的表现。光看书的话索引知识很难真正转过弯来。3.4 编程题Python 脚本能力是刚需编程题是拼真功夫的地方。滴滴的题目不会太难但一定贴合运维场景比如让你处理日志文件、统计某个接口的 P95 耗时、找出重复出现的错误码并排序等。我这边的建议是准备模板文件读写、正则表达式、字典排序、时间转换。基本能覆盖大部分运维脚本题。当时编程题里有一道印象很深的题有一个日志文件每行格式是 [时间] [接口名] [响应码] [耗时ms]要求输出每个接口的调用次数、平均耗时、以及耗时 P99。实现思路import collections stat collections.defaultdict(list) with open(api.log, r) as f: for line in f: parts line.strip().split() if len(parts) 4: continue time_str, api, code, cost_str parts[0], parts[1], parts[2], parts[3] try: cost int(cost_str) except ValueError: continue stat[api].append(cost) for api, costs in stat.items(): cnt len(costs) avg sum(costs) / cnt sorted_costs sorted(costs) p99 sorted_costs[int(cnt * 0.99) - 1] print(f{api} 调用次数{cnt} 平均耗时{avg:.2f}ms P99{p99}ms)这段代码的思路其实用到了几个常用技巧defaultdict 避免手动判断 key 是否存在异常处理防止脏数据让程序崩掉排序取 P99 而不是求平均因为平均耗时容易被极端值带偏。如果笔试环境允许用 pandas也能用 pandas 很轻松实现但保险起见建议掌握纯 Python 写法因为有些笔试环境没有第三方库。Shell 方向也可能会有一两题。比如让你用一行命令找出访问量前 10 的 IP。不少人的第一反应是 awk、sort、uniq 分开写但其实可以串起来awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这道题的考点是 uniq -c 只能统计相邻重复的行所以必须先 sort。很多人一上来就 uniq -c统计出来的结果是错的这就是典型的没实操经验。编程题时间紧的话优先保证思路清晰、代码结构良好不用追求一次通过但核心逻辑不能偏离题意太多。我在笔试时有一道题其实运行超时了但因为逻辑写对了最后还是进了面试说明出题人更看重你的思考过程而不是纯刷题能力。3.5 系统设计题把运维思路讲清楚系统设计题看起来没有标准答案但其实是整套卷子里最能看出一个人“有没有做过事”的部分。我记得当时的大概题目是设计一个监控系统要求能收集多台服务器的 CPU、内存、磁盘、网络等指标并在异常时告警。这题很基础但想答好需要把链路想清楚。我当时的回答思路大致如下数据采集层每台服务器部署 Agent用 Python 脚本定时采集指标通过 HTTP 上报给 Collector。数据存储层使用时序数据库如 InfluxDB 或 Prometheus保存指标按时间线组织数据方便聚合查询。告警判断层配置阈值规则例如 CPU 90% 持续 5 分钟触发告警用 Alertmanager 或自研规则引擎实现。通知层通过邮件、短信、企业微信等渠道发送告警支持按级别分层通知。可视化层接入 Grafana 展示实时曲线和历史趋势。那时候我还没用过 Prometheus只了解过 Zabbix所以回答里写的是“参考 Zabbix 的架构用 Python 自研采集器”。后来复盘发现能得分的关键不是用了什么具体工具而是表达出了“采集、传输、存储、告警、展示”这个完整链路并且能说出每一步的重点比如 Agent 要支持故障自愈、监控数据要有保留策略、告警要防抖以减少误报。如果你是第一次接触这种题可以从“用户打开页面→数据从哪来→数据去哪→异常了怎么办”这个流程去推把思路讲清楚比堆砌术语重要得多。如果在传输层能加上消息队列如 Kafka在数据层加上时序数据库在告警层加上恢复通知面试官基本就会认为你有过真实项目的经验了。4. 实操过程回顾一次完整的准备与模拟4.1 模拟笔试环境笔试前一周我给自己搭了一个模拟环境一台 Linux 虚拟机、一个 MySQL、一本笔试题集并规定自己两个半小时内必须完成一套卷子。这件事非常关键因为在真实笔试时你面对的是在线编码页面没有 IDE 的自动补全没有本地调试更不可能像 LeetCode 那样反复提交。提前模拟能让你适应这种“裸写代码”的感觉。我准备的方法是先做一套真题找薄弱点然后用三天时间重点补最后再做一套模拟题验证效果。第一套题我做下来Linux 题的错误率最高尤其是 awk 和 load average 相关的多选数据库的索引题也有点糊编程题倒是勉强能写但时间非常紧张。于是后三天我用半天专门练 Linux 命令半天刷数据库索引和事务的题再半天练 Python 脚本最后半天复习网络和系统设计。4.2 编程题模拟实录为了给读者一个可以直接抄作业的参考我把当时练过的一道模拟题完整记录在这里。题目给定一个文件每行是 “user_id api_name response_time_ms”要求统计每个用户的平均耗时并按平均耗时从高到低排序输出前 10 个用户。import sys records {} for line in sys.stdin: line line.strip() if not line: continue parts line.split() if len(parts) ! 3: continue user_id, api_name, resp_time parts[0], parts[1], parts[2] try: resp_time int(resp_time) except ValueError: continue if user_id not in records: records[user_id] [] records[user_id].append(resp_time) result [] for user_id, times in records.items(): avg_time sum(times) / len(times) result.append((user_id, avg_time)) result.sort(keylambda x: x[1], reverseTrue) for user_id, avg_time in result[:10]: print(f{user_id}\t{avg_time:.2f})这道题的关键点有两个一是用字典把散落的数据聚合起来二是对字典的值做求平均和排序。如果数据量特别大比如几千万行纯 Python 会有点慢可以改用 defaultdict 加 Counter 优化或者直接用 pandas groupby。但在笔试场景下只要逻辑对、能跑出结果就够。4.3 系统设计模拟我给自己出了一道题公司有 1000 台服务器每台运行着多个 Java 应用目前靠人工登录排查问题效率很低。请你设计一个日志收集与排查系统。我当时的解答每台服务器部署 Filebeat 或 Logstash将应用日志写入 Kafka。使用 Logstash 消费 Kafka 做过滤、字段解析、格式转换。输出到 Elasticsearch 做全文检索和聚合分析。用 Kibana 做可视化支持按应用名、时间、关键字筛选。接入告警规则例如出现 ERROR 关键字超过阈值就通知。这个方案其实就是现在业界最常见的 ELK Kafka 架构。面试官听到你能说出这个链路就会觉得你不只是懂单个工具而是有整体架构意识。我在回答里还提了一嘴“如果量很大可以考虑冷热数据分离把超过 30 天的日志归档到对象存储”这句话后来成了面试的加分项因为显示你有容量规划的思考。4.4 时间线回顾第 1 天摸底测试记录错题。第 2-4 天重点补 Linux、数据库、网络知识。第 5 天练编程题Python 和 Shell 都要写。第 6 天系统设计题专项。第 7 天模拟笔试复盘。这样安排的好处是每天的任务聚焦不会东一榔头西一棒子。如果你是边实习边准备建议把周期拉长到两周每天投入 1-2 小时即可。5. 常见问题与避坑经验5.1 多选漏选和错选的坑运维开发岗位的笔试多选题的恶心程度在互联网公司里排得上号因为每个选项都写得像是对的。我踩过最大的坑是“iptables 规则匹配顺序”和“TCP 状态迁移条件”。iptables 的规则是从上往下匹配一旦匹配就不再往下走如果顺序错了后面的规则永远不生效。这个知识点在实际配防火墙的时候特别重要但笔试时很容易被选项带偏。我后来的办法是把这类“顺序敏感”的知识点全部整理成一张表。比如 iptables 的链执行顺序是 PREROUTING → INPUT/FORWARD → OUTPUT → POSTROUTING匹配时按规则顺序执行TCP 状态机里 SYN_SENT、SYN_RECV、ESTABLISHED 的转移条件也要背熟。把这些做成思维导图考前过一遍多选的正确率会高很多。5.2 编程题最常见的“超时”运维场景的日志量动辄几 GB如果你写的脚本用两层大循环去匹配大概率会在真实数据上超时而笔试系统会模拟大数据量来测试性能。比如统计日志里某个字段唯一值的数量用 set 没问题但如果要按 IP 聚合访问次数用 dict 是基本要求。踩过的坑是忘了去掉字符串末尾的换行符导致 key 出现偏差或者在遍历文件时用 read() 把整个文件读进内存十几 GB 的日志直接内存爆炸。正确的做法是用 readline() 逐行处理。模拟题里文件不大看不出来但笔试系统就是用大数据量卡你这种不会的人。5.3 系统设计题不要为了“大而全”失去重点有些同学可能在准备时看到了 Kubernetes、容器、微服务等技术系统设计题里全往里面堆结果反而显得空洞。出题人想听的是你在这个场景下怎么采集数据、怎么定告警阈值、怎么避免告警风暴而不是用十个新名词编织一个你无法落地的空中楼阁。我在回答“监控系统设计”时一开始也提到了 Kubernetes 服务发现但面试官追问的是“如果某个 Agent 挂了你怎么发现”这个问题让我意识到设计题关键不在于技术的炫目程度而在于把基础链路想完整。发现问题的方式很多你可以说 Agent 定时上报心跳如果 3 个周期没上报就认为它失联告警通知运维。这个答案不需要任何高深技术就能得高分。5.4 一个提分小技巧写出你的思考过程在线笔试的编程题有些平台支持在注释里写思路我当时就习惯把“为什么这么写”用注释标出来。比如“这里用 defaultdict 而不是普通 dict 是因为免去初始化”这种注释虽然不影响运行结果但阅卷人能看到印象分会提高不少。系统设计题也一样每一段如果都有“为什么这么做”的说明哪怕方案本身不够完善也能展示出你的思考深度。5.5 关于环境问题的预防在线笔试最怕的其实是环境出问题浏览器崩了、网络断了、代码没保存。建议提前半小时进考场检查摄像头、麦克风部分公司会要求双机位、网络稳定以及本地编辑器能否正常使用。如果笔试平台支持自动保存一定要开着如果不支持建议每写一段代码就主动 CtrlS。别小看这个细节我听说过有人写了一个小时最后提交时发现代码是空白的心态直接崩了。最后再分享一点个人的观察运维开发这个岗位笔试只是入场券真正拉开差距的是后面面试中对“故障排查思路”和“自动化设计思路”的考察。笔试里那些基础题其实是在帮你把地基打牢。如果你们在准备过程中有遇到什么拿不准的题目或者对某个知识点有不同的理解欢迎一起交流。祝准备参加校招的朋友都能顺利拿到心仪的 offer。 运维开发笔试备考指南：从Linux到系统设计的核心考点与避坑经验
1. 运维开发笔试到底在筛什么人先聊聊这个岗位本身。运维开发工程师英文叫 DevOps Engineer 或者 SRESite Reliability Engineer在很多公司里也叫“应用运维”“平台运维”。和传统运维不一样的地方在于这个岗位的核心不是“守着服务器不宕机”而是“用代码把运维工作自动化”。换句话说你既要懂 Linux、网络、数据库这些基础设施又要会写 Python、Shell、Go 这类开发语言能自己撸工具、写平台、搭监控系统。滴滴的那场校招内推笔试本质上就是在筛这两类能力都达标的人。我记得当时收到内推链接后HR 邮件里附了一份笔试说明写了考试范围Linux 基础、网络基础、数据库、Python/Shell 脚本、算法基础、系统设计。当时一看就觉得这岗位真不是“会敲命令”就能进来的它要求的是“能解决问题的工程师”。为什么滴滴会这么考因为出行平台的业务场景太典型了。每天的订单量千万级司机端、乘客端、客服系统、支付系统、地图服务全都挂在线上任何一个服务抖动都会直接变成用户投诉。这时候运维开发要做的不是等人报警了再去重启而是提前把监控、告警、自动扩容、故障自愈这些能力做成平台化产品让业务方自己也能看数据、配策略。笔试考的就是你有没有这种“平台思维”和“自动化意识”。如果你现在正准备投运维开发岗不管目标公司是哪家这场笔试的题目结构和考察逻辑都有很强的参考价值。我把当时印象深的题目、踩过的坑、以及后来复盘时总结的经验整理出来希望能帮你少走些弯路。2. 笔试整体结构与时间分配2.1 试卷长什么样滴滴的运维开发笔试大概两个半小时题型分几块单选题大概 20 道覆盖 Linux、网络、数据库常识每道题不算难但覆盖面广。多选题大概 10 道比单选多一个坑容易漏选或者多选考的是对细节的准确记忆。编程题2-3 道用 Python 或 Shell 实现一些具体功能比如日志分析、文本处理、简单算法。系统设计题1-2 道给定业务场景让你设计监控方案或者自动化运维方案。整体感觉是客观题刷人编程题拉开差距系统设计题决定上限。如果客观题错太多基本就没戏了编程题写不出来面试也难约系统设计题答得好就算前面有小瑕疵面试官也愿意给你机会聊一聊。2.2 时间分配的策略我当时定的原则是“先客观题后编程题最后设计题”客观题控制在 40 分钟内完成编程题留 60-70 分钟系统设计题 30-40 分钟。为什么这么分因为客观题考的是记忆和理解看了不会就是不会纠结两分钟和十秒效果一样不如快速过把时间留给分值更高、更考察综合能力的主观题。这里有个教训我一开始在几道多选题上磨太久了特别是涉及 iptables 规则顺序和 TCP 状态转换的题目越想越不确定结果编程题的时间被压缩了。后来学乖了凡是客观题卡壳超过一分钟直接标记后跳过等全部做完再回头。2.3 涉及的知识域占比从记忆和复盘来看Linux 基础大约占 30%网络基础约 20%数据库约 15%编程题约 25%系统设计约 10%。这个配比其实很符合运维开发的日常工作日常操作要在 Linux 上完成出问题要懂网络排查数据要会查库效率提升要写脚本整体稳定性要做设计。3. 高频考点拆解与避坑3.1 Linux 基础不只是背命令Linux 这块的笔试题看着是选择题实际上是在考你有没有真实的操作经验。比如有一道题问 “ls -l 输出中硬链接数的含义”如果你只是背过答案是“硬链接数”没真正在文件系统里建过硬链接可能过几天就忘了。我建议准备时动手搭个环境把每个知识点过一遍。高频考点大概有文件权限chmod、chown、umask尤其是 rwx 对文件和目录的差异。进程管理ps、top、kill -9 和 kill -15 的区别僵尸进程怎么处理。系统负载load average 的三个值分别代表什么CPU 和 IO 负载怎么区分。文本处理三剑客grep、sed、awk其中 awk 的频率极高。软链接和硬链接inode 概念ln -s 和 ln 的区别。系统启动流程从 BIOS 到内核到 init/systemd了解每个阶段。拿 load average 举例很多人只知道“三个数分别代表 1/5/15 分钟平均负载”但笔试会深一层负载高一定是 CPU 满吗不是可能是 IO 等待。Linux 的 load average 计算包含了不可中断睡眠状态的进程D 状态如果磁盘性能差大量进程在等 IOload 也会飙升。这道题的坑就在于“负载高”和“CPU 高”是否等价答案是否定的。再看 awk 这种工具笔试不考你背语法而是给你一个日志文件片段让你选出能提取第 3 列和最后 1 列的命令。此时 $NF 这个内置变量就得能想起来awk {print $3, $NF} 和 awk {print $3, $5} 的区别一目了然。这种题光看不练一定会翻车。实操上最好在虚拟机里准备一套标准环境把系统监控、进程调优、日志切割这些操作过一遍。另外一个容易忽略的点是 systemd 的 systemctl 命令笔试中出现的频率逐年增高像 systemctl list-units --typeservice 和 systemctl status 的输出格式都要熟悉。3.2 网络基础七层模型和实际排查相结合网络这块的知识点面试官和出题人默认你是懂的但笔试题目会故意把“理论”和“实践”搅在一起。有一道题印象很深访问一个网站很慢怎么排查选项包括 ping、dig、curl -w、traceroute、ss -t。如果只背过“ping 测通不通”不知道 curl -w 可以显示 DNS 解析时间、TCP 连接时间、SSL 握手时间这道题就选不全。网络的高频考点TCP 三次握手和四次挥手每个阶段的状态尤其是 TIME_WAIT 和 CLOSE_WAIT 的产生原因和区别。DNS 解析流程递归查询和迭代查询的区别A 记录、CNAME 的区别。HTTP 状态码502、504、301、302、499 这些在运维中特别常见的码。负载均衡LVS、Nginx、HAProxy 的区别四层和七层负载的差异。iptables 规则nat 表和 filter 表的典型用法规则匹配顺序。TIME_WAIT 和 CLOSE_WAIT 是笔试的常客。TIME_WAIT 是主动关闭连接的一方进入的状态会持续 2MSL大约 60 秒大量 TIME_WAIT 多见于高并发的短连接场景解决方案是开启 reuse 和 recycle不过现代内核里 recycle 有点坑。CLOSE_WAIT 则是被动关闭方没调用 close()场景通常是程序有 bug连接不被释放。问你线上大量 CLOSE_WAIT 怎么排查答案不是调内核参数而是先找代码问题。HTTP 499 也是滴滴这类互联网公司喜欢考的因为 Nginx 日志里经常出现。499 代表客户端主动断开连接通常意味着后端处理时间太长用户等不及关了页面。这个状态码说明问题在后端慢而不是 Nginx 本身挂了对排查方向很有指导意义。TCP 连接状态图要多花时间看结合 ss 命令和 netstat -tunlp 去理解每种状态。不要死记硬背而是在本机模拟个场景比如开一个服务器、一个客户端用 tcpdump 抓包看握手挥手过程理解立刻就不一样了。3.3 数据库索引和锁是重头戏数据库考得比较常规但很看重对索引和事务的理解。比如有一道题某查询语句很慢explain 显示 typeALL应该怎么优化答案很直接——建索引让 type 变成 ref 或者 range。但如果只是背了“要建索引”不理解为啥覆盖索引能减少回表后面再考联合索引的最左前缀原则就蒙了。核心考点索引原理B 树结构聚簇索引和非聚簇索引的区别覆盖索引。最左前缀联合索引 (a, b, c) 能命中哪些查询。事务特性ACID隔离级别尤其是 RR 和 RC 的区别。锁行锁、表锁、间隙锁死锁产生原因。主从复制binlog、从库延迟排查。最左前缀原则这个点笔试特别爱出变体。联合索引 (name, age, city)以下哪些查询能使用该索引条件是 where namexx and age10 能用where age10 不能用where cityxx and age10 不能where namexx 能用。关键在于联合索引排序是按第一个字段、再第二个字段、再第三个字段跳过了前导字段直接用后面的字段索引就无法高效定位。还有一道题是关于主从延迟的问的是从库延迟增大排查方向是什么。选项包括检查从库所在机器的 CPU 和 IO、看大事务、看从库是不是在做备份、看主库 binlog 是否被清理。这几个都对因为它们确实是导致延迟的常见原因。这种题考的就是你有没有真实处理过主从延迟问题而不是只做过单机 MySQL。数据库的准备建议是装一个 MySQL用 explain 看几条 SQL 的执行计划再手动开启和关闭事务测一下不同隔离级别下的表现。光看书的话索引知识很难真正转过弯来。3.4 编程题Python 脚本能力是刚需编程题是拼真功夫的地方。滴滴的题目不会太难但一定贴合运维场景比如让你处理日志文件、统计某个接口的 P95 耗时、找出重复出现的错误码并排序等。我这边的建议是准备模板文件读写、正则表达式、字典排序、时间转换。基本能覆盖大部分运维脚本题。当时编程题里有一道印象很深的题有一个日志文件每行格式是 [时间] [接口名] [响应码] [耗时ms]要求输出每个接口的调用次数、平均耗时、以及耗时 P99。实现思路import collections stat collections.defaultdict(list) with open(api.log, r) as f: for line in f: parts line.strip().split() if len(parts) 4: continue time_str, api, code, cost_str parts[0], parts[1], parts[2], parts[3] try: cost int(cost_str) except ValueError: continue stat[api].append(cost) for api, costs in stat.items(): cnt len(costs) avg sum(costs) / cnt sorted_costs sorted(costs) p99 sorted_costs[int(cnt * 0.99) - 1] print(f{api} 调用次数{cnt} 平均耗时{avg:.2f}ms P99{p99}ms)这段代码的思路其实用到了几个常用技巧defaultdict 避免手动判断 key 是否存在异常处理防止脏数据让程序崩掉排序取 P99 而不是求平均因为平均耗时容易被极端值带偏。如果笔试环境允许用 pandas也能用 pandas 很轻松实现但保险起见建议掌握纯 Python 写法因为有些笔试环境没有第三方库。Shell 方向也可能会有一两题。比如让你用一行命令找出访问量前 10 的 IP。不少人的第一反应是 awk、sort、uniq 分开写但其实可以串起来awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这道题的考点是 uniq -c 只能统计相邻重复的行所以必须先 sort。很多人一上来就 uniq -c统计出来的结果是错的这就是典型的没实操经验。编程题时间紧的话优先保证思路清晰、代码结构良好不用追求一次通过但核心逻辑不能偏离题意太多。我在笔试时有一道题其实运行超时了但因为逻辑写对了最后还是进了面试说明出题人更看重你的思考过程而不是纯刷题能力。3.5 系统设计题把运维思路讲清楚系统设计题看起来没有标准答案但其实是整套卷子里最能看出一个人“有没有做过事”的部分。我记得当时的大概题目是设计一个监控系统要求能收集多台服务器的 CPU、内存、磁盘、网络等指标并在异常时告警。这题很基础但想答好需要把链路想清楚。我当时的回答思路大致如下数据采集层每台服务器部署 Agent用 Python 脚本定时采集指标通过 HTTP 上报给 Collector。数据存储层使用时序数据库如 InfluxDB 或 Prometheus保存指标按时间线组织数据方便聚合查询。告警判断层配置阈值规则例如 CPU 90% 持续 5 分钟触发告警用 Alertmanager 或自研规则引擎实现。通知层通过邮件、短信、企业微信等渠道发送告警支持按级别分层通知。可视化层接入 Grafana 展示实时曲线和历史趋势。那时候我还没用过 Prometheus只了解过 Zabbix所以回答里写的是“参考 Zabbix 的架构用 Python 自研采集器”。后来复盘发现能得分的关键不是用了什么具体工具而是表达出了“采集、传输、存储、告警、展示”这个完整链路并且能说出每一步的重点比如 Agent 要支持故障自愈、监控数据要有保留策略、告警要防抖以减少误报。如果你是第一次接触这种题可以从“用户打开页面→数据从哪来→数据去哪→异常了怎么办”这个流程去推把思路讲清楚比堆砌术语重要得多。如果在传输层能加上消息队列如 Kafka在数据层加上时序数据库在告警层加上恢复通知面试官基本就会认为你有过真实项目的经验了。4. 实操过程回顾一次完整的准备与模拟4.1 模拟笔试环境笔试前一周我给自己搭了一个模拟环境一台 Linux 虚拟机、一个 MySQL、一本笔试题集并规定自己两个半小时内必须完成一套卷子。这件事非常关键因为在真实笔试时你面对的是在线编码页面没有 IDE 的自动补全没有本地调试更不可能像 LeetCode 那样反复提交。提前模拟能让你适应这种“裸写代码”的感觉。我准备的方法是先做一套真题找薄弱点然后用三天时间重点补最后再做一套模拟题验证效果。第一套题我做下来Linux 题的错误率最高尤其是 awk 和 load average 相关的多选数据库的索引题也有点糊编程题倒是勉强能写但时间非常紧张。于是后三天我用半天专门练 Linux 命令半天刷数据库索引和事务的题再半天练 Python 脚本最后半天复习网络和系统设计。4.2 编程题模拟实录为了给读者一个可以直接抄作业的参考我把当时练过的一道模拟题完整记录在这里。题目给定一个文件每行是 “user_id api_name response_time_ms”要求统计每个用户的平均耗时并按平均耗时从高到低排序输出前 10 个用户。import sys records {} for line in sys.stdin: line line.strip() if not line: continue parts line.split() if len(parts) ! 3: continue user_id, api_name, resp_time parts[0], parts[1], parts[2] try: resp_time int(resp_time) except ValueError: continue if user_id not in records: records[user_id] [] records[user_id].append(resp_time) result [] for user_id, times in records.items(): avg_time sum(times) / len(times) result.append((user_id, avg_time)) result.sort(keylambda x: x[1], reverseTrue) for user_id, avg_time in result[:10]: print(f{user_id}\t{avg_time:.2f})这道题的关键点有两个一是用字典把散落的数据聚合起来二是对字典的值做求平均和排序。如果数据量特别大比如几千万行纯 Python 会有点慢可以改用 defaultdict 加 Counter 优化或者直接用 pandas groupby。但在笔试场景下只要逻辑对、能跑出结果就够。4.3 系统设计模拟我给自己出了一道题公司有 1000 台服务器每台运行着多个 Java 应用目前靠人工登录排查问题效率很低。请你设计一个日志收集与排查系统。我当时的解答每台服务器部署 Filebeat 或 Logstash将应用日志写入 Kafka。使用 Logstash 消费 Kafka 做过滤、字段解析、格式转换。输出到 Elasticsearch 做全文检索和聚合分析。用 Kibana 做可视化支持按应用名、时间、关键字筛选。接入告警规则例如出现 ERROR 关键字超过阈值就通知。这个方案其实就是现在业界最常见的 ELK Kafka 架构。面试官听到你能说出这个链路就会觉得你不只是懂单个工具而是有整体架构意识。我在回答里还提了一嘴“如果量很大可以考虑冷热数据分离把超过 30 天的日志归档到对象存储”这句话后来成了面试的加分项因为显示你有容量规划的思考。4.4 时间线回顾第 1 天摸底测试记录错题。第 2-4 天重点补 Linux、数据库、网络知识。第 5 天练编程题Python 和 Shell 都要写。第 6 天系统设计题专项。第 7 天模拟笔试复盘。这样安排的好处是每天的任务聚焦不会东一榔头西一棒子。如果你是边实习边准备建议把周期拉长到两周每天投入 1-2 小时即可。5. 常见问题与避坑经验5.1 多选漏选和错选的坑运维开发岗位的笔试多选题的恶心程度在互联网公司里排得上号因为每个选项都写得像是对的。我踩过最大的坑是“iptables 规则匹配顺序”和“TCP 状态迁移条件”。iptables 的规则是从上往下匹配一旦匹配就不再往下走如果顺序错了后面的规则永远不生效。这个知识点在实际配防火墙的时候特别重要但笔试时很容易被选项带偏。我后来的办法是把这类“顺序敏感”的知识点全部整理成一张表。比如 iptables 的链执行顺序是 PREROUTING → INPUT/FORWARD → OUTPUT → POSTROUTING匹配时按规则顺序执行TCP 状态机里 SYN_SENT、SYN_RECV、ESTABLISHED 的转移条件也要背熟。把这些做成思维导图考前过一遍多选的正确率会高很多。5.2 编程题最常见的“超时”运维场景的日志量动辄几 GB如果你写的脚本用两层大循环去匹配大概率会在真实数据上超时而笔试系统会模拟大数据量来测试性能。比如统计日志里某个字段唯一值的数量用 set 没问题但如果要按 IP 聚合访问次数用 dict 是基本要求。踩过的坑是忘了去掉字符串末尾的换行符导致 key 出现偏差或者在遍历文件时用 read() 把整个文件读进内存十几 GB 的日志直接内存爆炸。正确的做法是用 readline() 逐行处理。模拟题里文件不大看不出来但笔试系统就是用大数据量卡你这种不会的人。5.3 系统设计题不要为了“大而全”失去重点有些同学可能在准备时看到了 Kubernetes、容器、微服务等技术系统设计题里全往里面堆结果反而显得空洞。出题人想听的是你在这个场景下怎么采集数据、怎么定告警阈值、怎么避免告警风暴而不是用十个新名词编织一个你无法落地的空中楼阁。我在回答“监控系统设计”时一开始也提到了 Kubernetes 服务发现但面试官追问的是“如果某个 Agent 挂了你怎么发现”这个问题让我意识到设计题关键不在于技术的炫目程度而在于把基础链路想完整。发现问题的方式很多你可以说 Agent 定时上报心跳如果 3 个周期没上报就认为它失联告警通知运维。这个答案不需要任何高深技术就能得高分。5.4 一个提分小技巧写出你的思考过程在线笔试的编程题有些平台支持在注释里写思路我当时就习惯把“为什么这么写”用注释标出来。比如“这里用 defaultdict 而不是普通 dict 是因为免去初始化”这种注释虽然不影响运行结果但阅卷人能看到印象分会提高不少。系统设计题也一样每一段如果都有“为什么这么做”的说明哪怕方案本身不够完善也能展示出你的思考深度。5.5 关于环境问题的预防在线笔试最怕的其实是环境出问题浏览器崩了、网络断了、代码没保存。建议提前半小时进考场检查摄像头、麦克风部分公司会要求双机位、网络稳定以及本地编辑器能否正常使用。如果笔试平台支持自动保存一定要开着如果不支持建议每写一段代码就主动 CtrlS。别小看这个细节我听说过有人写了一个小时最后提交时发现代码是空白的心态直接崩了。最后再分享一点个人的观察运维开发这个岗位笔试只是入场券真正拉开差距的是后面面试中对“故障排查思路”和“自动化设计思路”的考察。笔试里那些基础题其实是在帮你把地基打牢。如果你们在准备过程中有遇到什么拿不准的题目或者对某个知识点有不同的理解欢迎一起交流。祝准备参加校招的朋友都能顺利拿到心仪的 offer。