先交代一下背景：我当年正好也在刷大厂运维开发的校招题，看到滴滴这套2018年的笔试题时，第一感觉是“这岗位比想象中有分量”。很多人以为运维开发就是“会点脚本的运维”，但看完这套题你会发现，它实际上在筛一类人——既要懂底层基础设施的运作逻辑，又要能写代码把重复劳动干掉，还要在系统出问题时能扛住压力把故障边界快速圈定。这篇文章不打算给你逐题报答案，那意义不大。我更想拆的是：这套题背后到底在考什么，以及如果你现在准备类似的岗位，应该按什么思路去补。
1. 大厂为什么单设“运维开发”这个岗
滴滴的业务形态决定了它的线上系统极其复杂：乘客端、司机端、订单中心、地图路径规划、计费系统、风控引擎……这些系统之间互相调用，任何一个环节抖动，都会直接反映到用户订单上。传统运维靠人肉盯监控、手工扩容的方式，在这种体量下根本跑不动。运维开发这个岗位的价值，不是“更会修服务器的运维”，而是用工程化的手段把运维工作本身变成一套自动化系统。
笔试考的不只是知识点，更是在筛选“有没有运维思维”的人。什么叫运维思维？举个例子：给你一个接口，它的平均响应时间从50毫秒涨到500毫秒，你第一步会怎么做？普通开发可能先看代码逻辑有没有变更，运维开发的第一反应是看这个接口部署在哪些机器上，这些机器的负载、网络、磁盘IO是否有异常，上游依赖是否抖动。这个排查路径的差异，就是岗位思维的差异。
这套卷子的结构也很典型，大致分了三块：计算机基础与网络、Linux与脚本编程、系统设计与故障排查。每一块都在为“能不能独立负责一个系统的稳定性”这个问题服务。它不考你在LeetCode上刷了多少道难题，而是考你在真实生产环境里能不能活下来。
2. 笔试前先弄明白：这套题到底在考什么
2.1 综合素质题其实在考“沟通成本”
很多考生拿到卷子，看到前几道综合素质题就开始放松警惕。实际上这类题是拉开差距的第一个关卡。比如给你一段描述：“线上出现订单高峰期订单量骤降，请写出排查思路”，这种题没有标准答案，但阅卷人能一眼看出你是在“背排查步骤”还是真的懂。
好的回答通常会这样组织：先确认影响范围（是所有订单还是某个城市），再缩小范围（是入口流量下降还是订单创建失败），然后按层次排查（客户端→网关→订单服务→数据库→依赖服务），每一步都对应具体可执行的命令或指标。差的回答就一句话“检查服务器负载”或者“重启服务”。这两种答案的差距，就是2个月实习经验和2年线上经验的差距。
2.2 运维基础题覆盖的面比想象中广
这一部分通常涵盖TCP/IP协议、HTTP状态码、DNS解析流程、Linux常用命令、Shell脚本、数据库基础等。范围看似杂，但核心逻辑是一根线：一个请求从用户手机发出，到滴滴服务器处理完并返回结果，中间经过的所有环节，你都要心里有数。
这类题有个很实用的准备方法：把自己想象成一个请求，从DNS解析开始，一路跟到数据库，把每一跳记录下来，再针对每一跳去补知识点。比如DNS这块，你要搞清楚递归查询和迭代查询的区别，A记录和CNAME的适用场景，以及本地DNS缓存对排障的影响。这些不是孤立的知识点，而是排障时一定要具备的背景知识。
2.3 编程题考的“不是算法，是工程效率”
运维开发的编程题，难度通常不会到LeetCode Hard的级别，但会特别强调“在资源受限环境下的处理能力”。比如日志文件太大不能一次性读入内存怎么办，数据量太大怎么分批处理，脚本运行超时怎么处理，这类问题才是重点。
这套卷子的编程题尤其偏爱用Python或Shell解日志分析类题目。这种选择有它的道理：日志是运维开发接触最多的数据源之一，你每天都要和它打交道。统计某个接口的请求量、平均耗时、错误率，用Python写个小脚本就能解决，但如何在几百万行日志里跑得够快，如何避免脚本本身变成新的故障点，这些才是工程上的真问题。
3. 编程题解析：日志统计才是运维开发的日常
运维开发笔试里最常出现的编程题，就是日志分析。比如给你一个访问日志文件，每行包含时间、接口名、响应耗时、状态码，让你统计出平均耗时最高的Top 10接口。这道题看着简单，但里面的门道不少。
3.1 先想清楚数据量再动手
如果日志文件有5GB，你上来就用readlines()把整个文件读进内存，机器可能直接就扛不住了。正确思路是逐行读取：一个几百MB甚至几个GB的文件，用for line in file这样的迭代方式处理，内存占用始终只有一行的大小。这看起来是个很基础的优化，但恰恰是很多没接触过真实日志量的考生最容易忽略的点。
3.2 效率瓶颈往往在“中间数据结构”
统计平均耗时，很多人第一反应是写两个字典，一个存每个接口的总耗时，一个存请求次数，最后相除。这个方案在接口数量少时没问题，但真实环境里接口可能有几百上千个，每个接口的耗时分布还很不均匀。你会发现，如果只是求均值，某些接口的耗时方差很大，均值根本说明不了问题。这时候最好同时算一下P90、P95这样的分位数，才能看出真实的服务质量。
注意：真实场景里，统计口径比统计方法更重要。比如“请求耗时”到底是从哪一段开始计的？是网关收到请求开始，还是业务代码入口开始？不同口径得出的结论可能完全相反，写脚本前必须先确认口径。
3.3 一段可以直接拿来改的示例代码
下面这段Python脚本就是一个很典型的日志统计框架，数据结构用defaultdict，读取方式用逐行迭代，处理完内存占用极小，适合直接套用到类似题目里。
import re from collections import defaultdict log_pattern = re.compile( r'(?P<time>\S+) \S+ (?P<api>\S+) (?P<cost>\d+\.?\d*) (?P<status>\d{3})' ) api_total_cost = defaultdict(float) api_request_count = defaultdict(int) api_error_count = defaultdict(int) with open('access.log', 'r', encoding='utf-8') as f: for line in f: match = log_pattern.search(line.strip()) if not match: continue api = match.group('api') cost = float(match.group('cost')) status = match.group('status') api_total_cost[api] += cost api_request_count[api] += 1 if status.startswith('5'): api_error_count[api] += 1 print(f"{'接口':<40} {'请求数':<10} {'平均耗时(ms)':<15} {'错误率':<10}") for api in sorted(api_total_cost, key=lambda x: api_total_cost[x] / api_request_count[x], reverse=True)[:10]: avg_cost = api_total_cost[api] / api_request_count[api] error_rate = api_error_count[api] / api_request_count[api] print(f"{api:<40} {api_request_count[api]:<10} {avg_cost:<15.2f} {error_rate:<10.2%}")为什么用defaultdict？因为它能省掉“判断key是否存在”的if-else，代码更干净，性能也更好。为什么用正则解析而不是简单的split()？因为生产环境的日志格式往往没那么规整，字段之间可能有多个空格，某些字段还可能出现可选值，正则的容错能力更强。当然，正则在极大数据量下会有性能损耗，所以更快的做法是先用split()试一下，不行再上正则。这段代码里为了通用性直接用了正则，实际使用时你可以根据自己的日志格式做调整。
3.4 写完脚本后的“自测思维”
很多时候笔试不只是看你脚本能不能跑通，还看你会不会自测。拿到这段代码，你有没有先构造一小段样例数据验证正则对不对？有没有考虑日志里出现异常行（比如某个接口名带特殊字符）会不会导致脚本崩溃？有没有想过如果按耗时排序，同样的代码在大文件上要跑多久？
这些自测的思维，其实是平时维护脚本留下的习惯。真实环境里一个脚本出bug，影响的可能不是一次考试得分，而是线上几台机器的数据统计结果，甚至可能触发错误告警，让值班同事半夜爬起来。所以，笔试里考察代码能力，本质上还是在考察你有没有“生产意识”。
4. 系统设计与故障排查：从“会用工具”到“会解决问题”
这部分是我认为整套卷子最有含金量的地方。它不靠背，靠的是你在真实系统里摸爬滚打的积累。
4.1 监控系统设计题的破题点
题目通常是这样的：设计一个监控系统，需要实时采集服务器CPU、内存、磁盘、网络等指标，并支持告警。你看完别急着写方案，要先在大脑里建立一条完整的数据链路：采集、传输、存储、展示、告警。
- 采集：用什么方式采集指标？PUSH还是PULL？每台机器上要不要装Agent？Agent用什么语言写？采集频率设多少？频率太高会增加Agent自身消耗，频率太低又会影响告警时效性。
- 传输：采集到的数据怎么汇总到监控服务端？走HTTP还是UDP？要不要做数据缓冲？如果监控服务端挂了，Agent端的数据是丢弃还是暂存？
- 存储：监控数据的写入量很大，普通关系型数据库扛得住吗？要不要用时序数据库？数据保留策略是什么？原始数据存多久，聚合数据又存多久？
- 告警：告警规则怎么配置？阈值怎么设？如何避免告警风暴？比如某台机器CPU飙高，到底该按“绝对值超过90%”还是“较历史均值突增50%”来告警？
很多人会把答案写在“用什么开源组件”上，比如用Prometheus+Grafana+Alertmanager。但更好的回答，是先说出每一环考虑的问题，再讲选型。因为选型背后是一系列权衡，只有把权衡讲清楚，才证明你在真实环境里做过决策，而不是在网上看过架构图。
4.2 故障排查题，本质是“二分法”的实战
这类题通常会给一个故障现象，让你写出排查思路。比如“用户反馈App打开很慢，可能的原因有哪些，如何一步步定位”。
这里有个很重要的方法论：先确认现象再动手。你得先问清楚“很慢”是首屏加载慢，还是点按钮后响应慢，还是整个App卡顿？范围有多大，是所有用户还是部分用户，是某个网络环境下还是所有网络环境？这些信息直接决定了排查的起点。
接下来就是一个逐层缩小的过程：用户端（手机性能、网络弱）→DNS解析→CDN→接入层（SLB/Nginx）→应用层（业务代码）→数据层（DB/缓存）→依赖服务（地图、支付、风控）。每一层都给一个“如何验证”的方法，比如在服务器上curl一下接口看内网耗时，用top看CPU负载，用dmesg看有没有OOM，用tcpdump看有没有丢包重传。
这里有个考生常见的错误：一上来就怀疑代码问题，然后开始翻代码。但是线上故障大概率不是单个代码bug导致的，而是资源、依赖、数据、容量等问题交叉作用的结果。运维开发的思维方式是“先外围后核心、先系统后代码”，这跟开发调试的思路是有本质区别的。
4.3 大厂真题里的“隐含加分项”
有些题表面上问“你怎么排查”，实际上在问你“你有没有一套可以沉淀的应急响应机制”。如果你在回答里提到“先告警，再拉群同步，再定位，再恢复，最后复盘”，这个思路会让阅卷人觉得你已经有了一定的生产经验。
我见过的优秀回答，通常会附带这样几个要素：第一，把影响面放在第一位，先止损再定位根因；第二，定位过程有充分的日志和监控数据支撑，而不是靠猜；第三，恢复操作有回滚预案，不会引入新的风险；第四，事后有改进项，比如补充监控、优化告警、增加自动化处理能力。这些细节，才是区分“做题家”和“从业者”的分水岭。
5. 笔试题之外的隐性考察逻辑
大厂校招笔试，尤其是运维开发这种岗位，题面往往不会很难，但坑都埋在你看不见的地方。
5.1 时间分配是笔试的第一道坎
运维开发的卷子题量一般不小，有选择题、判断题、简答题、编程题。如果前面选择题抠得太细，后面的大题大概率来不及写。我的建议是拿到卷子先花一分钟把所有题扫一遍，对整卷的难度分布心里有数，然后按照“先易后难，先拿分后攻坚”的原则做。
选择题、判断题属于送分题，快速过，不会的做个标记跳过。简答题要控制篇幅，写得再多也不一定加分，关键是把采分点写全。编程题一定要留至少40分钟时间，因为题本身不难，但你要考虑输入输出格式、边界条件、日志正则的匹配规则，这些细节很耗时。
5.2 卷面表达决定了阅卷人的耐心
很多人在笔试里会有个误区：觉得自己想得挺明白，写出来就不太像样。运维开发的答案尤其讲究条理，一个复杂的排查思路，如果不用编号分步骤写，阅卷人很可能没耐心看完。把每一步做什么、怎么验证、预期看到什么结果，都写清楚，这既是考试技巧，也是日常写故障复盘报告的能力。
5.3 把“踩坑经验”变成你的备考素材
准备这种笔试，不建议照着“操作系统十大问”“网络协议三十题”去背。更有效的做法，是找一台真实服务器，自己搭一套环境，模拟各种故障场景，然后一步一步排查。比如故意把磁盘写满，看看哪些服务会挂，日志会报什么错；再比如把Nginx的worker_connections调小，看并发上来之后会发生什么。这些亲手实践过的经验，比刷十套题都管用。
从长期发展来看，运维开发这个方向会越来越偏向“平台化”和“产品化”。你以为你在维护服务器，实际上你在为公司搭建一套基础设施的自动化调度系统。今天笔试里考的日志统计，可能就是明天你写的监控平台的某个功能模块；今天考的故障排查思路，可能就是后天你负责的告警降噪策略。这样想想，这套卷子考得其实很实在——它考的就是这个岗位每天都要面对的日常。
