从Linux到SRE：大厂运维开发笔试实战解析

聊聊“滴滴出行2018校园招聘网申笔试-运维开发工程师(第一套）”背后面试官想考什么

运维开发这个岗位在大厂校招里一直有点特殊，它既不像纯开发那样天天写业务代码，也不像传统运维那样盯着监控面板敲命令——它夹在中间，既要懂底层系统，又要能写自动化工具，还得理解业务架构。近几年大家习惯叫它SRE，其实早些年的运维开发工程师干的就是这摊事。

今天拿“滴滴出行2018校园招聘网申笔试-运维开发工程师(第一套）”这个题目当引子，聊聊当年这类笔试里面试官到底在筛选什么人、考点集中在哪、以及现在回头看这些能力要求有哪些仍然适用。如果你正在准备运维开发、SRE、DevOps方向的校招或社招笔面试，这篇应该能帮你把复习重心理清楚。

先给个结论：这类笔试本质上不是考“你会不会用某个工具”，而是考“你在真实故障和复杂环境下，有没有系统化解决问题的能力”。工具可以现学，但排查思路、脚本设计、对Linux底层的理解，这些短时间内突击不来。

1. 这类笔试的整体设计与考察目标

1.1 为什么大厂校招笔试爱考运维开发

我见过不少准备校招的同学，对运维开发笔试的内容分布感到困惑：为什么又要考Linux命令、又要考Python脚本、还要考网络协议和数据库索引？看起来像“大杂烩”。

其实这不是出题随意，而是岗位特性决定的。运维开发的日常工作是：通过代码和平台，保证线上系统稳定、高效、可扩展。这背后需要三类能力叠加——对基础设施（服务器、网络、存储）的理解、对应用程序（代码、数据库、中间件）的理解、以及把两者串联起来的自动化开发能力。

所以笔试题目会刻意覆盖多个技术面，目的不是让你拿满分，而是快速定位你的能力边界。比如同样一题，有人只能写出Shell脚本，有人能用Python封装成可复用的监控模块，有人还能考虑到异常处理和日志输出——这个差距，恰恰是面试官最想看的。

1.2 考试结构里的“分层筛选”逻辑

大厂校招题量大、时间紧凑（一般60到120分钟不等），通常包含四类题型：客观题（选择/判断）、简答题、编程题、场景分析题。这四类题目不是随意排列的，它们对应着从低到高的能力层级：

很多同学重编程轻基础，结果栽在前面的客观题上。说实话，这类岗位里Linux命令和网络协议就是“吃饭的家伙”，基础不扎实，后面写出的自动化工具也容易有各种隐性坑。

2. 高频考点拆解：运维开发的四大核心板块

2.1 Linux 系统与文本处理：不只是背命令

Linux相关题目在运维开发笔试中的占比通常在25%到35%之间。常考的点包括：进程管理（ps、top、kill、僵尸进程）、文件系统（inode、df、du、软硬链接）、权限体系（rwx、setuid/sticky bit）、系统性能排查（vmstat、iostat、free、sar）。

但我想提醒一点：现在很多题不再直接问“某个命令的某个参数是什么”，而是给你一段现实场景，让你选择或写出排查命令。比如“某台服务器CPU负载飙高，但具体进程一直在变，怎么定位是哪个进程在消耗CPU？”这种题如果只是背过top的用法，大概率会答偏，因为它实际在考察“CPU使用率”和“平均负载”之间的关系，你得上关注进程的瞬时状态，而不是只看load average。

文本处理三剑客grep、sed、awk几乎是必考的。我见过的高频考法：从Nginx日志里统计某个接口的调用次数、平均响应时间、Top IP分布。这种题看起来简单，但awk里的变量累加、BEGIN块初始化、pattern匹配这些细节写不对就是不对。建议备考时找一份真实日志，自己动手把常见的统计场景都刷一遍。

2.2 Python/Shell 编程：从“能写”到“写好”

编程题方面，Shell和Python二选一的情况比较多，但我建议两门都要会。Shell适合快速处理文本和调用系统命令，Python适合写复杂的监控脚本、调用API、处理数据结构。

常见的编程题类型：

• 日志分析类：从指定日志中统计出错误码分布、请求耗时超过阈值的URL列表。
• 文件处理类：找出目录下大于1GB的文件并输出路径和大小。
• 系统信息采集类：收集所有服务器的内存、磁盘使用率，输出成表格。
• 简单算法类：字符串处理、排序、去重，偶尔会有简单的动态规划。

很多同学在校招复习时狂刷LeetCode，这没有错，但对运维开发岗位，优先把脚本题练好更划算。算法题一道可能就20分，脚本题往往一道40分，而且脚本题更接近日后工作的真实需求。

写脚本时别只顾“出结果”，得注意几个细节：异常捕获（文件不存在、命令执行失败）、超时处理、日志输出、参数化设计。举个例子，写一个磁盘清理脚本，如果你把阈值写死在代码里，面试官会觉得你只是“能写”，但如果你用argparse接收参数、把需要清理的目录列表放在配置文件里，这就有了工程思维。

2.3 网络基础与排查：协议理解是关键

网络部分常考的包括TCP三次握手和四次挥手、TCP和UDP的区别、HTTP状态码语义、DNS解析流程、常用网络排查工具（ping、traceroute、netstat、ss、tcpdump）。

这里我想展开讲一个高频考点：当用户反馈网站访问慢，你会怎么排查？先查什么后查什么？很多同学的答案是“先ping一下看丢包”，但实际业务访问链路远比ping复杂——客户端到服务端的网络、服务端到数据库的网络、DNS解析耗时、HTTPS握手、后端接口处理时间，每一环节都可能是瓶颈。

好的回答思路是按“分层排查”的方式：先确认是单用户问题还是全量故障；再顺着客户端→DNS→接入层→应用层→数据层逐步定位；每个环节用对应的工具验证，比如dig查DNS、curl看连接耗时、tcpdump抓包确认重传、慢查询日志看数据库。

这个思维框架笔试会考，面试也会考。备考时不光要记命令，还要在脑子里预演几套完整的排查路径。

2.4 数据库与中间件：运维开发绕不开的依赖

数据库相关的考点主要集中在MySQL：索引失效的场景、事务隔离级别、explain执行计划、主从复制原理、慢查询优化。中间件方面，Redis和消息队列（Kafka/RabbitMQ）的出现频率也在上升。

MySQL里最常考的坑包括：索引左侧前缀原则失效（比如查询条件用了where name like '%xx'）、隐式类型转换导致索引失效、联合索引不满足最左匹配。这些点光背概念没用，要能结合具体SQL语句说出“为什么慢”和“怎么改”。

Redis方面重点看缓存穿透、缓存击穿、缓存雪崩的区别和应对方案。因为运维开发经常要处理“缓存导致线上故障”这类问题，所以笔面试官喜欢用场景题来考你。

3. 典型题目类型的作答思路与实战技巧

3.1 客观题：快速判断与排除法

客观题通常30到50道，覆盖很广，时间压力大。我建议的作答策略是：先做有把握的，标记不确定的，最后回来啃难题。运维开发考试里，命令参数类和多选类题最容易纠结，不要在一道题上耗超过两分钟。

分享一个实用规律：选命令的时候，如果题目描述里强调“实时性”，优先选包含top、ss、free这类直接读/proc或内核信息的命令，而不是需要轮询采样的命令；如果强调“历史排查”，优先看包含sar、dmesg、/var/log/messages这类持久化日志的选项。

多选和判断里，数字类考点很集中：TCP端口范围、HTTP状态码含义（301、302、403、429、502、503）、Linux文件权限的八进制表示、磁盘分区挂载规则。这些要练到秒选的程度，因为它们真的属于“送分题”。

3.2 简答题：用“结构化表达”拿高分

简答题最怕的是“知道答案但说不清楚”。比如“请描述一次你排查线上故障的过程”，很多人写的东西像流水账：先看监控，再登服务器，然后用top看进程——每个步骤都对，但没有因果逻辑。

我给一个建议：用“现象→假设→验证→结论→预防”五段式来组织答案。先说清楚线上出现了什么异常（报错信息、监控指标），然后依据现象提出2到3个可能原因，再讲你用什么命令/日志去逐一排除，定位到根因后怎么处理的，最后留了什么监控或脚本避免再次发生。

这种结构化的答案，不仅适用于笔试简答题，面试里讲项目经历时更是加分项。面试官能从你的表述里看出你有没有系统化的排障心智。

其他常考简答题方向：

• 服务器CPU飙高，如何定位到具体线程并分析其堆栈？
• 数据库连接数被打满，可能是什么原因，怎么解决？
• 一个服务从开发到上线，你如何设计发布方案和回滚方案？
• crontab执行的任务没有按预期运行，从哪些角度排查？

3.3 编程题：先跑通，再优化

编程题我强调一点：不管会不会，先把能写的框架写出来，拿步骤分。你写一个完整的不完美代码，远好过留白。

举例：日志分析题，通常给出一个日志格式样例，要求统计指定条件的记录。我会这么写：

1. 先定义日志解析规则，用正则或split方法提取关键字段；
2. 用数据结构存储统计结果（字典、Counter）；
3. 输出排序后的结果；
4. 加上异常处理，文件不存在时打印错误并退出。

代码风格上注意：变量命名要有业务含义，不写无意义的a、b、c；关键逻辑旁边写简短注释；输出格式严格遵循题目要求，因为它可能作为自动化判题依据。

如果题目没有限制语言，我用Python。但如果题目明确要求Shell，那你需要注意细节：使用#!/bin/bash吗？set -e加了吗？管道命令某个环节失败会导致什么？这些在真实生产环境里都会出问题，也算运维开发“特有小考点”。

3.4 场景题：全局视角与取舍决策

场景题是运维开发笔试里最“值钱”的题目，因为它没有标准答案，看的是分析问题的维度。

举个例子，有个经典场景题：假设你负责的业务在高峰期接口超时率突然上升，你如何排查？如果你是面试官，你会期待什么样的答案？我个人认为高分答案具备四个特征：

• 先确认影响面：是个别用户还是大面积故障，是全链路瓶颈还是单点问题？
• 分层面定位：网络层（带宽、丢包）、系统层（CPU、内存、IO）、应用层（线程池、连接池）、数据层（慢SQL、缓存命中率）；
• 有明确的动作顺序：先恢复再优化，必要时优先重启/限流/扩容保证可用性；
• 事后复盘：根因分析、改进监控指标、增加自动化告警。

这种题目考察的其实是你有没有“值班”过，有没有真正经历过故障。如果你是还没实习过的应届生，建议多在开源社区、技术博客里看真实故障复盘文章，把别人的处置流程转化为自己的思维框架。

4. 备考路线与资源推荐

4.1 三个月左右的复习时间怎么分配

如果你现在离笔试还有三个月，我建议这样拆：

• 第1个月：打基础。Linux命令过一遍重点用法（可以用《鸟哥的Linux私房菜》当参考），Python/Pipeline脚本的常用写法练熟，网络基础（TCP/IP卷一挑重点章节）和MySQL索引原理过完。
• 第2个月：刷真题和脚本。把能搜到的运维开发笔试真题做一遍，重点是编程题要动手写。同时用真实数据练日志分析，完成几个小项目，比如写一个服务器信息巡检脚本、一个日志关键字告警脚本。
• 第3个月：模拟考试和查漏补缺。卡时间做整套试题，锻炼节奏感。整理错题，把薄弱点集中攻克。这个阶段也建议练练手速，有些编程题在编辑器里写和纸上写完全不同，要提前适应。

4.2 值得反复刷的资料类型

第一个是历年笔试“回忆版”。大厂笔试通常不会公开原题，但每年校招季后会有人在牛客网、知乎等平台分享自己遇到的题目。看这些回忆贴的重点不是背答案，而是总结出题目分布规律。

第二个是故障复盘类文章。像“一次XX问题的排查过程”这类技术博客，比任何教科书都更能帮你建立排障思维。你能了解到生产环境里真实发生的问题、排查工具的组合用法、以及复盘时沉淀的优化项。

第三个是自己动手折腾。运维开发是实践性极强的工作，只看书不实操效果很差。你可以自己装几台虚拟机或容器实例，搭一个简单的Web服务，配好Nginx和MySQL，然后人为制造故障并排查——比如把磁盘写满、把CPU拉高、断开网络，然后自己救火。这个过程积累的经验，比刷十套题都有用。

5. 常见问题与避坑技巧

5.1 那些让我后悔没早点知道的事

不少同学复习时容易踩几个坑，我捡重点说：

• 只刷开发题，不碰系统题。前面提过，运维开发笔试非常看重Linux基础。很多开发能力很强的同学，在“查找占用8080端口的进程”这类题上犹豫半天，真的很吃亏。
• 编程题只写思路不实际跑。在纸上写和实际运行是两回事，在真实环境里跑一遍，你会发现变量类型、编码问题、甚至换行符都能让你翻车。
• 忽略日志处理细节。题目要求按时间倒序输出、按次数排序、输出到指定文件，这些“小要求”就是大量扣分点。

另外备考心态上，别太焦虑“我没在大厂实习过能不能考上”。运维开发笔试考的是实干能力，哪怕你只是在学校里维护过社团的几台服务器，只要复盘得足够细，比简历上写一堆“熟悉”却答不出细节的人强得多。

5.2 笔试现场的时间分配建议

以一套120分钟的试卷为例，如果客观题40分钟做完，简答题20分钟，你留给编程题和场景题的时间就只有60分钟。从我的经历来看，这个分配偏紧，因为编程题是最容易写超时的。

我的建议是：客观题尽量控制在35分钟内，不会的果断标记跳过，不恋战；简答题用25分钟，每题控制在8分钟以内，先答要点再适当展开；剩下60分钟按分值分配编程题和场景题，编程题一定要留出至少20分钟来测试和改错。

考试过程中写编程题时，先花2分钟理清思路、列好步骤再动手。很多同学一上来就写，写到一半发现数据结构选错了，推倒重来，那才是最耗时间的。

5.3 笔试之后：复盘和面试衔接

笔试结束不代表完事了。我强烈建议每一场笔试后都写一份复盘笔记，记录三个东西：遇到了哪些没答上来的知识点、做错题目的正确思路、编程题有没有更优写法。这份笔记不仅是查漏补缺，更直接能转化为面试里的素材——因为面试官经常会拿着你笔试时写得不够好的题目追问。

笔试里暴露的薄弱环节，基本就是后续面试的追问重点。比如笔试里TCP握手过程写错了，面试官大概率会在技术面里让你完整讲一遍握手流程并问你为什么不是两次或四次。趁着笔试结束后记忆新鲜，把薄弱点啃下来，面试时的底气会足很多。

还有一个小建议：笔试中你写过的脚本、场景题的解答思路，都同步记录下来。等到技术面试聊项目时，这些可以直接包装成“我处理过线上类似的日志分析需求”或“我设计过一个故障排查流程”，比空洞地说“我熟悉运维开发”有说服力得多。

6. 从2018年到现在，运维开发笔试的变与不变

6.1 短期来看，考点重心有哪些迁移

拿2018年前后的题目和近年的校招笔试题对比，能看到一些明显的变化。

容器和Kubernetes的权重明显上升。2018年时Docker还算加分项，K8s会问的人不多；现在运维开发岗位的JD里，“熟悉容器技术”几乎是标配。笔试里对镜像原理、Pod调度、Service网络模式的考查频率明显增加。

监控体系也开始从Zabbix单点监控向Prometheus、Grafana、告警规则设计偏移。以前考“怎么用Zabbix添加监控项”，现在考“怎么设计一套基于Prometheus的监控指标和大盘”。

另外，DevOps和CI/CD流水线的内容占比在加大。Jenkins、GitLab CI、ArgoCD这些工具链，以及“变更管理”“灰度发布”“滚动更新”这些部署策略，经常出现在简答题和场景题里。

如果你是按2018年的考点复习，却不补容器化和CI/CD的知识，说实话会比较吃亏。

6.2 长期来看，哪些核心能力一直没变

虽然考点在变，但我观察到一个事实：底层原理和排查能力，一直都是区分度最高的部分。

不管用Docker还是K8s，底层都是Linux的namespace、cgroups和网络栈；不管监控工具怎么换，核心都是CPU、内存、IO、网络四大类指标的采集和关联分析；不管你写的是Shell还是Python，核心都是“在生产环境下可靠地完成自动化任务”。

这也是为什么我劝备考的同学别在工具链上追新追到魔怔，更要把精力花在Linux原理、网络协议、排障方法论上。工具是流动的，原理是长久的。

从个人经验来看，运维开发笔试比较像一张“雷达图”：你的Linux能力、脚本能力、网络能力、数据库能力、架构意识都在图上有对应的得分。你的目标是让这张图尽可能不出现明显的凹陷短板——因为任何一块短板，都可能在未来的线上故障里变成事故的导火索。备考时不妨先做一次自我评估，找到自己的短板，然后一份真题一份真题地把它们补齐。等你把基础的每一块都夯到60分以上，像“滴滴出行2018校园招聘网申笔试-运维开发工程师”这类试卷，就只是一次能力体检，而不是什么拦路虎了。