先交代一下背景我当年正好也在刷大厂运维开发的校招题看到滴滴这套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(?Ptime\S) \S (?Papi\S) (?Pcost\d\.?\d*) (?Pstatus\d{3}) ) api_total_cost defaultdict(float) api_request_count defaultdict(int) api_error_count defaultdict(int) with open(access.log, r, encodingutf-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, keylambda x: api_total_cost[x] / api_request_count[x], reverseTrue)[: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每台机器上要不要装AgentAgent用什么语言写采集频率设多少频率太高会增加Agent自身消耗频率太低又会影响告警时效性。传输采集到的数据怎么汇总到监控服务端走HTTP还是UDP要不要做数据缓冲如果监控服务端挂了Agent端的数据是丢弃还是暂存存储监控数据的写入量很大普通关系型数据库扛得住吗要不要用时序数据库数据保留策略是什么原始数据存多久聚合数据又存多久告警告警规则怎么配置阈值怎么设如何避免告警风暴比如某台机器CPU飙高到底该按“绝对值超过90%”还是“较历史均值突增50%”来告警很多人会把答案写在“用什么开源组件”上比如用PrometheusGrafanaAlertmanager。但更好的回答是先说出每一环考虑的问题再讲选型。因为选型背后是一系列权衡只有把权衡讲清楚才证明你在真实环境里做过决策而不是在网上看过架构图。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调小看并发上来之后会发生什么。这些亲手实践过的经验比刷十套题都管用。从长期发展来看运维开发这个方向会越来越偏向“平台化”和“产品化”。你以为你在维护服务器实际上你在为公司搭建一套基础设施的自动化调度系统。今天笔试里考的日志统计可能就是明天你写的监控平台的某个功能模块今天考的故障排查思路可能就是后天你负责的告警降噪策略。这样想想这套卷子考得其实很实在——它考的就是这个岗位每天都要面对的日常。