尧图网站建设 
做运维开发的这些年我经常被准备校招的学弟学妹问一个问题大厂的运维开发工程师笔试到底考什么市面上的面经大多集中在后端开发、算法岗专门针对运维开发这个方向的系统梳理反而很少。刚好前阵子有个读者拿着“滴滴出行2018校园招聘网申笔试-运维开发工程师(第三套)”这套题来跟我讨论我发现这套题虽然年代有点久但考察的知识框架放到今天依然不过时甚至可以说它把运维开发这个岗位“既要懂开发、又要懂运维”的复合属性体现得很典型。这篇文章就借这套笔试的考察脉络聊聊运维开发工程师校招笔试背后的知识体系、典型题目思路以及备考时容易踩的坑。不管你是正在准备秋招的应届生还是想转行做SRE/运维开发的在职人这篇文章都能给你一个相对完整的参考坐标系。1. 运维开发笔试的核心先搞清楚滴滴想招什么样的人1.1 运维开发 ≠ 传统运维岗位定位决定考察方向很多同学看到“运维开发”四个字第一反应是“是不是就是以前的网管/系统管理员”如果有这种想法笔试基本就凉了一半。滴滴出行这种体量的互联网公司业务场景是数亿用户的出行调度背后是海量的订单、实时定位、路径规划等高并发请求。这种场景下传统意义上“手动登录服务器、敲命令重启服务”的运维方式根本扛不住所以大厂里的运维开发工程师本质上是在做将运维工作产品化、自动化、平台化的事情。具体来说运维开发要解决的核心问题包括如何用代码管理成千上万台服务器配置管理如何让服务发布更高效、更安全CI/CD如何在海量监控数据里快速发现异常并定位故障监控告警与可观测性如何在流量突增时让系统平滑扩容容量规划与弹性伸缩。笔试题目考察的每一项知识最后都会落到这些真实场景上。如果你只是背了一堆命令和概念不理解背后的业务诉求答简答题时就会很虚。滴滴的业务特点决定了它对运维开发的几个硬性要求第一代码能力必须扎实不管是Python、Shell还是Go要能写出可维护的工程代码第二对Linux操作系统和网络的深入理解因为故障往往发生在底层第三对自动化工具链的熟悉程度因为效率就是生命线。所以你看笔试的卷面结构基本就是围绕这三块展开的。1.2 从第三套试卷反推考察模块虽然不能完整还原当年那套题目的每一个字节但根据参加过同类笔试的同学反馈和行业通用经验这套“第三套”试卷的知识点分布大致有以下几个模块编程基础与脚本能力约25%-30%Python语法、Shell脚本编写、简单的数据结构和算法字符串处理、数组操作、文件读写等Linux操作系统基础约20%-25%进程管理、内存机制、文件系统、系统调优常用命令网络与TCP/IP原理约15%-20%TCP三次握手/四次挥手、HTTP协议、DNS解析、常见网络故障排查数据库与缓存约10%-15%MySQL的基本操作和索引原理、Redis的数据结构和应用场景常用开源组件与工具约10%Nginx、ZooKeeper、Kafka、Docker等的基础概念场景设计与故障排查约10%-15%给出一个线上故障现象让你分析可能原因和排查步骤或者让你设计一个监控告警方案这个结构其实传递了一个很重要的信号校招笔试看的不是你会不会用某个具体工具而是你有没有完整的基础知识体系以及能不能把零散的知识串联起来解决实际问题。很多同学把精力花在背“面试宝典”上结果笔试里考了一个“某个进程CPU占用率过高如何定位”的题就懵了因为这种题需要的是系统性的思路而不是单一的知识点记忆。2. 核心知识模块拆解笔试背后的逻辑与实战要点2.1 脚本与编程能力笔试里的“送分题”和“送命题”运维开发的编程题难度通常不会特别高和纯后端开发岗的算法题是两回事。滴滴这套笔试里的编程题大概率是让你用Python或Shell实现某个运维场景的小工具。比如读取一个Nginx访问日志统计某个接口的QPS、PV/UV或者提取出响应时间超过3秒的请求再或者写个脚本批量检查一组服务器的存活状态。这里的“送分题”部分是基础语法。比如Python的文件操作、字典排序、正则匹配Shell的循环、条件判断、管道和文本处理工具grep、awk、sed的组合使用。如果有同学这些基础还不熟我建议先把菜鸟教程或者《Python核心编程》里的文件、字符串、异常处理章节过一遍再配合Shell的经典三剑客grep/awk/sed做专项练习。真正的“送命题”在于代码风格和工程意识。举个例子同样是写一个日志分析脚本初级选手可能会把所有的逻辑都堆在一个main函数里变量命名用a、b、c有经验的选手会拆成几个小函数加上注释考虑文件不存在时的异常处理甚至会考虑到日志文件过大时如何流式读取而不是一次性load进内存。笔试虽然不像代码评审那么严格但阅卷人很容易从代码结构看出你有没有工程基础。我强烈建议笔试里所有代码都按生产标准来写函数拆分、异常处理、注释三件套做好哪怕多花几分钟也值得。还有一个常见的坑是语言选型。运维开发笔试首选Python因为它的表达能力最强、库最丰富能覆盖绝大多数场景。Shell适合处理文本和调用系统命令但复杂逻辑写起来很痛苦。如果题目没有明确指定语言建议用Python如果题目明确要求Shell那就老老实实用Shell别秀操作写个Python让人看不懂。说白了笔试不是炫技场是展示你“能干活、好协作”的场所。2.2 Linux与系统原理从“会用命令”到“理解内核”Linux这块很多同学觉得简单无非就是看看进程、查查磁盘、改改权限。但笔试里真正拉开差距的是那些需要你“理解原理”才能答对的知识点。比如僵尸进程和孤儿进程的区别孤儿进程是父进程先退出子进程被init收养僵尸进程是子进程先退出但父进程没有调用wait/waitpid去回收它的PCB导致进程表项一直占着。这题考的是你对进程生命周期的理解以及在实际运维中如果遇到大量僵尸进程该怎么处理找到父进程看它为什么不回收通常需要修复父进程的逻辑而不是简单kill僵尸进程因为kill对僵尸进程无效你只能kill它的父进程让它被init接管后回收。硬链接和软链接的区别硬链接共享同一个inode软链接是存了目标路径的独立文件删除源文件后硬链接依然能访问数据软链接就断了。看似基础但结合实际问题“磁盘空间明明删了文件却没有释放”就能考出深度——因为还有进程持有该文件的句柄。Linux下如何找出一台机器上CPU使用率最高的前5个进程标准答案是ps aux --sort-%cpu | head -5或者用top按P键排序。简单但很多人写的时候会漏掉--sort-%cpu这个参数或者排序方向搞反。这类实操题考察的是日常积累没有捷径就是多练。除了命令内存和文件系统的原理也是高频考点。比如swap分区的作用、页缓存和脏页的概念、inode耗尽导致磁盘无法写文件但是df-h显示还有空间。这些知识点如果只靠死记硬背换个问法就不会了。我建议把《鸟哥的Linux私房菜》的基础篇翻一遍重点理解每个命令背后的系统调用逻辑而不仅仅是记住参数。2.3 网络基础笔试必考面试必问故障排查的基石网络这块是运维开发的基本功也是最容易丢分的模块。三次握手、四次挥手几乎是必考但很多人只知道包头的flags不理解为什么要这样设计。比如为什么建立连接是三次握手断开连接却要四次挥手因为TCP是双向全双工的断开时要保证双方都没有数据要发送了所以每个方向的关闭都要单独确认。这个理解到位了面试时再追问“TIME_WAIT大量出现怎么办”就有了解题的基础。还有一个高频考点是HTTP状态码和常见Header。比如503和502的区别502是网关从上游收到了无效响应503是服务暂时不可用Location头的作用重定向Cache-Control和Expires的区别前者是HTTP/1.1标准后者是HTTP/1.0的老字段且前者优先级更高。这些细节不一定会直接考但一旦和故障场景结合就是拉开差距的“加分题”。DNS解析原理也是滴滴这类大厂笔试青睐的考点比如你在浏览器输入一个域名到页面显示出来中间经历了哪些步骤这题需要你完整描述从浏览器缓存、操作系统缓存、本地hosts、LDNS递归查询、根域名服务器、顶级域名服务器、权威域名服务器一直到返回IP、建立TCP连接、发送HTTP请求、服务端处理、返回响应的全过程。这其实是个综合性题目考的是网络HTTP前后端协作的理解。2.4 数据库与缓存不只是会写SQL数据库和缓存这块笔试通常不会让你写特别复杂的多表join但会考察你对索引原理、事务隔离级别、Redis数据结构的理解。比如为什么MySQL的索引结构默认用B树而不是哈希表或平衡二叉树explain里的type字段从all到index到range到ref到eq_ref到const分别代表什么扫描级别实际优化时至少要到哪个级别Redis为什么快除了基于内存之外还有哪些原因单线程避免了锁竞争和上下文切换、IO多路复用、高效的数据结构设计Redis的持久化机制RDB和AOF各自的优缺点以及如果让你选你会怎么配Redis的缓存穿透、缓存击穿、缓存雪崩分别是什么怎么解决这些问题在笔试题里会以选择题或简答题出现考察的是你有没有真正在生产环境里思考过这些组件的选型和落地。尤其是缓存穿透查一个不存在的key缓存永远不命中请求全打到数据库如果没接触过可能连题目问什么都看不懂。我建议备考时把每个知识点都问自己一个“生产环境里这个机制到底解决什么问题”这样知识就不是死的。3. 典型题目场景复盘像老兵一样思考问题3.1 故障排查类题别急着给结论先建立排查框架运维开发笔试里我最喜欢的一类题是“线上故障排查”因为它最能反映一个人的实战思维。例如这道几乎每个大厂都会有的题线上突然出现大量用户反馈无法下单你作为运维开发工程师如何排查很多小白看到这种题上来就回答“重启服务”。这个答案即便不算错也是最差的答案。原因很简单重启是万不得已的兜底操作它会掩盖真正的根因而且滴滴这种体量随意重启核心服务可能引发更大的雪崩。一个合格的排查思路应该是这样的确认故障范围先看监控大盘是所有地域的用户都影响还是某个城市/某个运营商网络的用户故障范围决定了排查方向如果是地域性的优先考虑网络和DNS如果是全网性的优先考虑服务端。看监控告警和日志确认是不是订单服务本身的CPU、内存、磁盘、GC指标异常如果服务正常再往上走到网络层有没有丢包、延迟抖动、往下走到依赖层数据库是不是慢查询变多、缓存是不是大面积失效。排查最近变更发布变更、配置变更、流量调度变更是运维故障最常见的诱因回滚往往是解决这类问题最快的方式。隔离与止血如果确实有大量请求打到某一个有问题的节点先把流量切走或者限流保护核心服务避免拖垮整个集群。定位根因拿到关键日志和线程dump、堆dump结合代码逻辑确认问题。修复后再灰度上线同时复盘并补充监控盲点。这每一步背后都有对应的考察点。如果你在笔试中把这种框架写清楚即使没有给出最终结论阅卷人也会认为你有真实的排查经验或做过深度思考。切记故障排查题最重要的不是答案本身而是你“先做什么、后做什么、为什么”的逻辑链条。3.2 监控与告警设计题从“可用性”角度展示你的全局视野滴滴这种体量监控告警是运维开发的核心工作之一。笔试里可能出现类似这样的题让你为一套电商核心交易系统设计监控告警方案要包含哪些监控项告警级别如何划分这类题目考的其实是你对“可观测性”体系的理解广度和深度。不要只停留在“CPU高、内存高”这种主机层指标。一个完整的监控体系至少包含四层基础设施层CPU、内存、磁盘、网络IO、带宽、丢包率应用层QPS、响应时间平均/TP99/TP999、错误率4xx/5xx比例、JVM GC频率与耗时中间件层数据库连接池占用率、慢查询数量、MQ积压数、Redis命中率业务层下单成功率、订单量波动、支付转化率告警级别也不是一刀切。比如故障影响面大、用户直接感知、需要立即处理的问题设为P0立即响应、电话通知影响单个用户、有替代方案的问题设为P2工作时间处理。核心原则是告警要少而准每个告警都应该对应一个明确的行动项。如果告警太多变成“狼来了”反而会让值班同学麻木。一个加分项是提到告警聚合和智能降噪比如同一条链路上多个服务同时告警时如何把根因服务识别出来避免告警风暴。3.3 自动化与CI/CD设计题考察工程化思维滴滴的运维开发笔试也很可能出现一类“设计题”或“实现题”比如如何设计一条从代码提交到线上发布的自动化流水线这种题考察的不是你会不会用Jenkins或GitLab CI——因为这些工具本身谁都会点“下一步”而是要考察你对软件交付全流程的理解。一个成熟的发布流水线应该包括代码提交触发开发push代码到Git仓库触发Webhook。静态检查与单元测试跑lint、跑单测、跑代码安全扫描任一步失败就阻断。构建镜像把代码打成Docker镜像并打上唯一的tag分支名commit号时间戳。推送镜像仓库镜像推送到私有仓库如Harbor触发下一步。部署到测试环境自动部署到测试环境跑集成测试。部署到预发环境预发环境跟生产环境走同一套发布脚本只是流量不同可以让测试同学做验收。生产环境分批发布第一批先发布一个节点观察指标稳定后按百分比10%、50%、100%灰度放量如果关键指标异常就自动回滚。发布后巡检检查日志、错误率、业务指标确认无异常才宣布发布完成。如果你能把这个流程写清楚顺带补充每个环节的“卡点”要设置哪些自动化检测阅卷人就知道你是真的理解“持续交付”这件事而不只是用过GitLab里的一个按钮。3.4 手写代码类题从逻辑清晰到边界处理最后说说手写代码题。运维开发的代码题一般有明确的应用场景比如写一个Python脚本监控某个进程是否存在如果不存在则自动拉起它并记录日志。这题的考察点有几个逻辑清晰主循环里先检查进程是否存在不存在则启动启动失败要处理。边界处理进程名匹配时要避免把包含该名字的其他进程也算进去所以一般用pgrep -f或者精确匹配。防止脚本自身被误杀脚本本身可能会因为命令里带着进程名被误判为目标进程所以要做过滤比如pgrep -f时排除掉grep自身或者用pgrep -x精确匹配。健壮性脚本运行期间休眠间隔要合理避免空转日志要带时间戳要处理进程被反复重启的情况比如检测到1分钟内重启了多次可能是系统有问题不要继续盲目拉起要告警。一个完整的答案大概长这样#!/usr/bin/env python3 import subprocess import time import datetime def is_process_running(process_name): # 使用 pgrep 精确匹配进程名-x 避免模糊匹配 try: result subprocess.run([pgrep, -x, process_name], capture_outputTrue, textTrue) return result.returncode 0 except Exception: return False def start_process(command): # nohup ... 启动避免随着脚本退出而终止 try: with open(/var/log/process_monitor.log, a) as log: subprocess.Popen(command, shellTrue, stdoutlog, stderrlog) return True except Exception as e: log_time datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) print(f[{log_time}] 启动进程失败: {e}) return False def main(): process_name nginx start_command systemctl start nginx restart_times [] while True: if not is_process_running(process_name): log_time datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) now time.time() # 清理 5 分钟前的重启记录 restart_times [t for t in restart_times if now - t 300] if len(restart_times) 3: # 短时间内多次重启可能存在问题发送告警并暂停 print(f[{log_time}] 进程 {process_name} 在 5 分钟内重启超过 3 次停止自动拉起) time.sleep(60) continue print(f[{log_time}] 进程 {process_name} 不存在尝试拉起) if start_process(start_command): restart_times.append(now) time.sleep(5) if __name__ __main__: main()这段代码虽然不是什么复杂工程但能够体现出监控、拉起、防抖、日志、异常处理五个维度。笔试里如果能写出这个水平已经是资深候选人的表现了。4. 备考踩坑实录那些最容易丢分的地方4.1 只知道概念不落地实操我见过太多备考的同学笔试前刷了一堆选择题觉得“Linux命令这些都见过”结果考场上一写脚本就露馅sed -i和sed -e分不清楚grep -E和egrep混着用awk打印列时$NF写成了NF。这些都是纯手速和肌肉记忆的问题唯一的解决办法是真的打开终端去敲。随便到知乎搜一个“Linux文本处理练习100题”或者自己每天处理一个几十MB的真实日志文件比看十篇教程都有用。一个更典型的例子是“网络排查”。很多同学能背出traceroute的用途却不知道实际执行时第一跳通常是网关也不清楚telnet ip port是探测端口连通性的最常用姿势。这些内容不自己去试一遍笔试遇到“请写出排查一个服务端口不通的完整思路”就写不出具体命令只能写套话得分自然上不去。4.2 忽视“数据结构和算法”的基础题运维开发的笔试考算法吗考但绝对没有后端开发那么深。通常就是链表、栈、队列、hashmap、排序手写快排/归并、字符串处理、二分查找这些基础中的基础。但我发现一个现象很多运维方向的同学因为觉得“运维不用学算法”连单链表反转都写不完整。这就很亏。实际上滴滴这类公司的运维开发笔试里编程题虽然场景化但底层算法跟基本功是强相关的。比如写一个日志key的聚合统计本质上就是哈希表的运用实现一个简单的队列消费者本质上是对队列数据结构的理解。基础数据结构掌握了才能把业务场景抽象成代码否则就是拿一堆if-else硬凑。备考时至少把LeetCode的Top 100里那些简单和中等难度中跟字符串、数组、哈希表、二叉树相关的题刷一遍已经足够。4.3 题型理解偏差把选择填空当论述题把论述题当选择题这里说的是答题策略问题。有些同学做选择题的时候想太多把对的改成错的做主观题的时候又全写废话没有得分点。关于选择题我的建议是相信第一感觉除非你非常确定自己记错了否则别反复改关于主观题一定要分点作答、关键词前置。比如问“如何排查高CPU占用”你就直接写“1. top找到PID2. top -Hp找到线程3. printf %x转换线程ID4. jstack导出线程栈5. 定位到业务代码”每一条都是一句话但每一条都是得分点。千万别一整段话写下来阅卷人还要帮你找重点。特别注意主观题的“关键词”必须是你确实理解的术语不要瞎堆。比如问题问“如何排查网络问题”你写“可能是NAT转发的问题”就要能解释清楚NAT是什么、在哪一层、怎么查。写不了解的概念面试时被追问就是自己给自己埋雷。4.4 对“分布式与中间件”的认识过于表面滴滴的业务天然是分布式的所以运维开发笔试围绕分布式组件的考察几乎是必有的ZooKeeper是干什么的分布式协调、服务注册、配置管理、Kafka怎么保证消息不丢失producer端ack机制、broker端多副本、consumer端手动提交offset、Docker镜像和容器的区别镜像只是只读模板容器是运行态有可写层。这些概念题看似送分但如果只是背了定义没有画过架构图、没有手动部署过一个小集群答的时候就会干巴巴的。我建议备考时自己用虚拟机或者云主机搭一套最小可用的环境装一个Docker、跑一个Nginx容器、用docker-compose起一个MySQLRedis后端服务的组合。中间件的话搭一个单机ZooKeeper再搭一个单机Kafka试试往里面发消息、消费消息观察一下如果消费组挂了再恢复offset会怎么走。这个过程既能加深概念理解又能在笔试里举出“我实际部署过”的例子瞬间提升说服力。5. 从笔试到Offer运维开发工程师的长期修炼路线5.1 笔试只是起点别把备考和真实能力割裂开很多同学考完笔试就把这些知识扔了等面试过了才发现自己什么都不会。我想说一个反常识的观点运维开发笔试里考察的那些“死知识”恰恰是这份工作日常最需要的基本功。TCP握手和挥手、Linux进程模型、MySQL索引原理、Redis数据结构——这些不是背完就扔的考试内容而是你未来分析每一个线上问题都要用到的基础工具。面试官其实非常清楚这一点所以面试中会有大量的追问和情景模拟本质上就是要确认你到底是“背过”还是“懂”。就拿TCP的TIME_WAIT来说笔试里可能只是选择题面试里可能就会追问大量TIME_WAIT连接会有什么影响怎么通过sysctl参数调整tcp_tw_reuse和tcp_tw_recycle这两个参数分别解决什么问题为什么线上不建议开tcp_tw_recycle要想回答好这串问题你必须真正理解TCP状态机的运作机制而不是记住“出现大量TIME_WAIT就开tcp_tw_reuse”。我的经验是每复习一个知识点就把这个知识点往下挖两层“为什么”问到底直到你无法回答为止然后再去查资料补上。5.2 给不同阶段同学的备考顺序建议如果你是准备校招的应届生时间紧建议按优先级排序先把Python脚本能力打牢能独立写200行以内的小工具熟悉文件操作、日志管理、HTTP请求库requests、以及subprocess调用Shell命令。这是笔试和面试的生命线。Linux命令查漏补缺重点覆盖ps、top、netstat、ss、lsof、df、du、free、iostat、vmstat、sar、strace以及文件权限和软硬链接的理解。命令要知道常见参数而且要知道什么时候用哪个。TCP/IP和HTTP把三次握手、四次挥手、TIME_WAIT、TCP状态机、HTTP请求/响应结构、常见状态码、Cookie/Session的区别吃透。MySQL和Redis索引原理、事务、缓存穿透/击穿/雪崩会写基本的CRUD和简单的explain分析。Docker和CI/CD会用Dockerfile构建一个简单的Python应用镜像理解镜像分层和容器运行原理了解GitLab CI或Jenkins的基本配置方法。如果你是在职人员想转岗运维开发则建议增加一个完整的个人项目比如做一个简单的“服务器资产管理平台”或者“日志监控告警机器人”用Python写后端、MySQL存储、Redis做缓存再套一层Nginx反向代理用Docker部署。这个项目既能写在简历上也能在面试过程中展示你的工程能力比单纯堆一堆技术名词有说服力得多。5.3 运维开发的真正护城河故障处理的“肌肉记忆”最后我想说一个不那么“考试”但非常重要的点。笔试能考出你的知识储备但考不出你的“手感”——那种在凌晨三点被电话叫醒处理线上故障时能安静下来一步步排查问题、找到根因并止血的能力。这种手感来自大量真实事故的处理和复盘不是背题能学来的。但我可以给你一个成本很低的训练办法多读各大互联网公司的技术博客和故障复盘文章遇到一个故障案例先按下暂停键自己列一份排查方案再对照人家的方案看差在哪里。这个习惯坚持半年你的故障排查思路就会比同龄人高出一大截。我自己刚做运维开发那两年最深的体会是这个岗位最难的不是技术本身而是“在压力下保持冷静、在信息不全时做出判断”的能力。笔试只是这一长段修炼的入场券真正拉开差距的是后续在工作中对每一次故障、每一行代码、每一个告警的认真复盘和总结。备考滴滴这类大厂运维开发岗位核心就是三件事把Python写熟练、把Linux和网络的底层原理吃透、把监控和发布的知识体系搭建起来。把这篇里提到的知识框架梳理清楚再配合足量的线上实操你会发现自己面对的不只是一场笔试而是整个运维开发岗位的完整能力地图。 大厂运维开发笔试考什么？从滴滴真题拆解知识体系与备考要点
做运维开发的这些年我经常被准备校招的学弟学妹问一个问题大厂的运维开发工程师笔试到底考什么市面上的面经大多集中在后端开发、算法岗专门针对运维开发这个方向的系统梳理反而很少。刚好前阵子有个读者拿着“滴滴出行2018校园招聘网申笔试-运维开发工程师(第三套)”这套题来跟我讨论我发现这套题虽然年代有点久但考察的知识框架放到今天依然不过时甚至可以说它把运维开发这个岗位“既要懂开发、又要懂运维”的复合属性体现得很典型。这篇文章就借这套笔试的考察脉络聊聊运维开发工程师校招笔试背后的知识体系、典型题目思路以及备考时容易踩的坑。不管你是正在准备秋招的应届生还是想转行做SRE/运维开发的在职人这篇文章都能给你一个相对完整的参考坐标系。1. 运维开发笔试的核心先搞清楚滴滴想招什么样的人1.1 运维开发 ≠ 传统运维岗位定位决定考察方向很多同学看到“运维开发”四个字第一反应是“是不是就是以前的网管/系统管理员”如果有这种想法笔试基本就凉了一半。滴滴出行这种体量的互联网公司业务场景是数亿用户的出行调度背后是海量的订单、实时定位、路径规划等高并发请求。这种场景下传统意义上“手动登录服务器、敲命令重启服务”的运维方式根本扛不住所以大厂里的运维开发工程师本质上是在做将运维工作产品化、自动化、平台化的事情。具体来说运维开发要解决的核心问题包括如何用代码管理成千上万台服务器配置管理如何让服务发布更高效、更安全CI/CD如何在海量监控数据里快速发现异常并定位故障监控告警与可观测性如何在流量突增时让系统平滑扩容容量规划与弹性伸缩。笔试题目考察的每一项知识最后都会落到这些真实场景上。如果你只是背了一堆命令和概念不理解背后的业务诉求答简答题时就会很虚。滴滴的业务特点决定了它对运维开发的几个硬性要求第一代码能力必须扎实不管是Python、Shell还是Go要能写出可维护的工程代码第二对Linux操作系统和网络的深入理解因为故障往往发生在底层第三对自动化工具链的熟悉程度因为效率就是生命线。所以你看笔试的卷面结构基本就是围绕这三块展开的。1.2 从第三套试卷反推考察模块虽然不能完整还原当年那套题目的每一个字节但根据参加过同类笔试的同学反馈和行业通用经验这套“第三套”试卷的知识点分布大致有以下几个模块编程基础与脚本能力约25%-30%Python语法、Shell脚本编写、简单的数据结构和算法字符串处理、数组操作、文件读写等Linux操作系统基础约20%-25%进程管理、内存机制、文件系统、系统调优常用命令网络与TCP/IP原理约15%-20%TCP三次握手/四次挥手、HTTP协议、DNS解析、常见网络故障排查数据库与缓存约10%-15%MySQL的基本操作和索引原理、Redis的数据结构和应用场景常用开源组件与工具约10%Nginx、ZooKeeper、Kafka、Docker等的基础概念场景设计与故障排查约10%-15%给出一个线上故障现象让你分析可能原因和排查步骤或者让你设计一个监控告警方案这个结构其实传递了一个很重要的信号校招笔试看的不是你会不会用某个具体工具而是你有没有完整的基础知识体系以及能不能把零散的知识串联起来解决实际问题。很多同学把精力花在背“面试宝典”上结果笔试里考了一个“某个进程CPU占用率过高如何定位”的题就懵了因为这种题需要的是系统性的思路而不是单一的知识点记忆。2. 核心知识模块拆解笔试背后的逻辑与实战要点2.1 脚本与编程能力笔试里的“送分题”和“送命题”运维开发的编程题难度通常不会特别高和纯后端开发岗的算法题是两回事。滴滴这套笔试里的编程题大概率是让你用Python或Shell实现某个运维场景的小工具。比如读取一个Nginx访问日志统计某个接口的QPS、PV/UV或者提取出响应时间超过3秒的请求再或者写个脚本批量检查一组服务器的存活状态。这里的“送分题”部分是基础语法。比如Python的文件操作、字典排序、正则匹配Shell的循环、条件判断、管道和文本处理工具grep、awk、sed的组合使用。如果有同学这些基础还不熟我建议先把菜鸟教程或者《Python核心编程》里的文件、字符串、异常处理章节过一遍再配合Shell的经典三剑客grep/awk/sed做专项练习。真正的“送命题”在于代码风格和工程意识。举个例子同样是写一个日志分析脚本初级选手可能会把所有的逻辑都堆在一个main函数里变量命名用a、b、c有经验的选手会拆成几个小函数加上注释考虑文件不存在时的异常处理甚至会考虑到日志文件过大时如何流式读取而不是一次性load进内存。笔试虽然不像代码评审那么严格但阅卷人很容易从代码结构看出你有没有工程基础。我强烈建议笔试里所有代码都按生产标准来写函数拆分、异常处理、注释三件套做好哪怕多花几分钟也值得。还有一个常见的坑是语言选型。运维开发笔试首选Python因为它的表达能力最强、库最丰富能覆盖绝大多数场景。Shell适合处理文本和调用系统命令但复杂逻辑写起来很痛苦。如果题目没有明确指定语言建议用Python如果题目明确要求Shell那就老老实实用Shell别秀操作写个Python让人看不懂。说白了笔试不是炫技场是展示你“能干活、好协作”的场所。2.2 Linux与系统原理从“会用命令”到“理解内核”Linux这块很多同学觉得简单无非就是看看进程、查查磁盘、改改权限。但笔试里真正拉开差距的是那些需要你“理解原理”才能答对的知识点。比如僵尸进程和孤儿进程的区别孤儿进程是父进程先退出子进程被init收养僵尸进程是子进程先退出但父进程没有调用wait/waitpid去回收它的PCB导致进程表项一直占着。这题考的是你对进程生命周期的理解以及在实际运维中如果遇到大量僵尸进程该怎么处理找到父进程看它为什么不回收通常需要修复父进程的逻辑而不是简单kill僵尸进程因为kill对僵尸进程无效你只能kill它的父进程让它被init接管后回收。硬链接和软链接的区别硬链接共享同一个inode软链接是存了目标路径的独立文件删除源文件后硬链接依然能访问数据软链接就断了。看似基础但结合实际问题“磁盘空间明明删了文件却没有释放”就能考出深度——因为还有进程持有该文件的句柄。Linux下如何找出一台机器上CPU使用率最高的前5个进程标准答案是ps aux --sort-%cpu | head -5或者用top按P键排序。简单但很多人写的时候会漏掉--sort-%cpu这个参数或者排序方向搞反。这类实操题考察的是日常积累没有捷径就是多练。除了命令内存和文件系统的原理也是高频考点。比如swap分区的作用、页缓存和脏页的概念、inode耗尽导致磁盘无法写文件但是df-h显示还有空间。这些知识点如果只靠死记硬背换个问法就不会了。我建议把《鸟哥的Linux私房菜》的基础篇翻一遍重点理解每个命令背后的系统调用逻辑而不仅仅是记住参数。2.3 网络基础笔试必考面试必问故障排查的基石网络这块是运维开发的基本功也是最容易丢分的模块。三次握手、四次挥手几乎是必考但很多人只知道包头的flags不理解为什么要这样设计。比如为什么建立连接是三次握手断开连接却要四次挥手因为TCP是双向全双工的断开时要保证双方都没有数据要发送了所以每个方向的关闭都要单独确认。这个理解到位了面试时再追问“TIME_WAIT大量出现怎么办”就有了解题的基础。还有一个高频考点是HTTP状态码和常见Header。比如503和502的区别502是网关从上游收到了无效响应503是服务暂时不可用Location头的作用重定向Cache-Control和Expires的区别前者是HTTP/1.1标准后者是HTTP/1.0的老字段且前者优先级更高。这些细节不一定会直接考但一旦和故障场景结合就是拉开差距的“加分题”。DNS解析原理也是滴滴这类大厂笔试青睐的考点比如你在浏览器输入一个域名到页面显示出来中间经历了哪些步骤这题需要你完整描述从浏览器缓存、操作系统缓存、本地hosts、LDNS递归查询、根域名服务器、顶级域名服务器、权威域名服务器一直到返回IP、建立TCP连接、发送HTTP请求、服务端处理、返回响应的全过程。这其实是个综合性题目考的是网络HTTP前后端协作的理解。2.4 数据库与缓存不只是会写SQL数据库和缓存这块笔试通常不会让你写特别复杂的多表join但会考察你对索引原理、事务隔离级别、Redis数据结构的理解。比如为什么MySQL的索引结构默认用B树而不是哈希表或平衡二叉树explain里的type字段从all到index到range到ref到eq_ref到const分别代表什么扫描级别实际优化时至少要到哪个级别Redis为什么快除了基于内存之外还有哪些原因单线程避免了锁竞争和上下文切换、IO多路复用、高效的数据结构设计Redis的持久化机制RDB和AOF各自的优缺点以及如果让你选你会怎么配Redis的缓存穿透、缓存击穿、缓存雪崩分别是什么怎么解决这些问题在笔试题里会以选择题或简答题出现考察的是你有没有真正在生产环境里思考过这些组件的选型和落地。尤其是缓存穿透查一个不存在的key缓存永远不命中请求全打到数据库如果没接触过可能连题目问什么都看不懂。我建议备考时把每个知识点都问自己一个“生产环境里这个机制到底解决什么问题”这样知识就不是死的。3. 典型题目场景复盘像老兵一样思考问题3.1 故障排查类题别急着给结论先建立排查框架运维开发笔试里我最喜欢的一类题是“线上故障排查”因为它最能反映一个人的实战思维。例如这道几乎每个大厂都会有的题线上突然出现大量用户反馈无法下单你作为运维开发工程师如何排查很多小白看到这种题上来就回答“重启服务”。这个答案即便不算错也是最差的答案。原因很简单重启是万不得已的兜底操作它会掩盖真正的根因而且滴滴这种体量随意重启核心服务可能引发更大的雪崩。一个合格的排查思路应该是这样的确认故障范围先看监控大盘是所有地域的用户都影响还是某个城市/某个运营商网络的用户故障范围决定了排查方向如果是地域性的优先考虑网络和DNS如果是全网性的优先考虑服务端。看监控告警和日志确认是不是订单服务本身的CPU、内存、磁盘、GC指标异常如果服务正常再往上走到网络层有没有丢包、延迟抖动、往下走到依赖层数据库是不是慢查询变多、缓存是不是大面积失效。排查最近变更发布变更、配置变更、流量调度变更是运维故障最常见的诱因回滚往往是解决这类问题最快的方式。隔离与止血如果确实有大量请求打到某一个有问题的节点先把流量切走或者限流保护核心服务避免拖垮整个集群。定位根因拿到关键日志和线程dump、堆dump结合代码逻辑确认问题。修复后再灰度上线同时复盘并补充监控盲点。这每一步背后都有对应的考察点。如果你在笔试中把这种框架写清楚即使没有给出最终结论阅卷人也会认为你有真实的排查经验或做过深度思考。切记故障排查题最重要的不是答案本身而是你“先做什么、后做什么、为什么”的逻辑链条。3.2 监控与告警设计题从“可用性”角度展示你的全局视野滴滴这种体量监控告警是运维开发的核心工作之一。笔试里可能出现类似这样的题让你为一套电商核心交易系统设计监控告警方案要包含哪些监控项告警级别如何划分这类题目考的其实是你对“可观测性”体系的理解广度和深度。不要只停留在“CPU高、内存高”这种主机层指标。一个完整的监控体系至少包含四层基础设施层CPU、内存、磁盘、网络IO、带宽、丢包率应用层QPS、响应时间平均/TP99/TP999、错误率4xx/5xx比例、JVM GC频率与耗时中间件层数据库连接池占用率、慢查询数量、MQ积压数、Redis命中率业务层下单成功率、订单量波动、支付转化率告警级别也不是一刀切。比如故障影响面大、用户直接感知、需要立即处理的问题设为P0立即响应、电话通知影响单个用户、有替代方案的问题设为P2工作时间处理。核心原则是告警要少而准每个告警都应该对应一个明确的行动项。如果告警太多变成“狼来了”反而会让值班同学麻木。一个加分项是提到告警聚合和智能降噪比如同一条链路上多个服务同时告警时如何把根因服务识别出来避免告警风暴。3.3 自动化与CI/CD设计题考察工程化思维滴滴的运维开发笔试也很可能出现一类“设计题”或“实现题”比如如何设计一条从代码提交到线上发布的自动化流水线这种题考察的不是你会不会用Jenkins或GitLab CI——因为这些工具本身谁都会点“下一步”而是要考察你对软件交付全流程的理解。一个成熟的发布流水线应该包括代码提交触发开发push代码到Git仓库触发Webhook。静态检查与单元测试跑lint、跑单测、跑代码安全扫描任一步失败就阻断。构建镜像把代码打成Docker镜像并打上唯一的tag分支名commit号时间戳。推送镜像仓库镜像推送到私有仓库如Harbor触发下一步。部署到测试环境自动部署到测试环境跑集成测试。部署到预发环境预发环境跟生产环境走同一套发布脚本只是流量不同可以让测试同学做验收。生产环境分批发布第一批先发布一个节点观察指标稳定后按百分比10%、50%、100%灰度放量如果关键指标异常就自动回滚。发布后巡检检查日志、错误率、业务指标确认无异常才宣布发布完成。如果你能把这个流程写清楚顺带补充每个环节的“卡点”要设置哪些自动化检测阅卷人就知道你是真的理解“持续交付”这件事而不只是用过GitLab里的一个按钮。3.4 手写代码类题从逻辑清晰到边界处理最后说说手写代码题。运维开发的代码题一般有明确的应用场景比如写一个Python脚本监控某个进程是否存在如果不存在则自动拉起它并记录日志。这题的考察点有几个逻辑清晰主循环里先检查进程是否存在不存在则启动启动失败要处理。边界处理进程名匹配时要避免把包含该名字的其他进程也算进去所以一般用pgrep -f或者精确匹配。防止脚本自身被误杀脚本本身可能会因为命令里带着进程名被误判为目标进程所以要做过滤比如pgrep -f时排除掉grep自身或者用pgrep -x精确匹配。健壮性脚本运行期间休眠间隔要合理避免空转日志要带时间戳要处理进程被反复重启的情况比如检测到1分钟内重启了多次可能是系统有问题不要继续盲目拉起要告警。一个完整的答案大概长这样#!/usr/bin/env python3 import subprocess import time import datetime def is_process_running(process_name): # 使用 pgrep 精确匹配进程名-x 避免模糊匹配 try: result subprocess.run([pgrep, -x, process_name], capture_outputTrue, textTrue) return result.returncode 0 except Exception: return False def start_process(command): # nohup ... 启动避免随着脚本退出而终止 try: with open(/var/log/process_monitor.log, a) as log: subprocess.Popen(command, shellTrue, stdoutlog, stderrlog) return True except Exception as e: log_time datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) print(f[{log_time}] 启动进程失败: {e}) return False def main(): process_name nginx start_command systemctl start nginx restart_times [] while True: if not is_process_running(process_name): log_time datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) now time.time() # 清理 5 分钟前的重启记录 restart_times [t for t in restart_times if now - t 300] if len(restart_times) 3: # 短时间内多次重启可能存在问题发送告警并暂停 print(f[{log_time}] 进程 {process_name} 在 5 分钟内重启超过 3 次停止自动拉起) time.sleep(60) continue print(f[{log_time}] 进程 {process_name} 不存在尝试拉起) if start_process(start_command): restart_times.append(now) time.sleep(5) if __name__ __main__: main()这段代码虽然不是什么复杂工程但能够体现出监控、拉起、防抖、日志、异常处理五个维度。笔试里如果能写出这个水平已经是资深候选人的表现了。4. 备考踩坑实录那些最容易丢分的地方4.1 只知道概念不落地实操我见过太多备考的同学笔试前刷了一堆选择题觉得“Linux命令这些都见过”结果考场上一写脚本就露馅sed -i和sed -e分不清楚grep -E和egrep混着用awk打印列时$NF写成了NF。这些都是纯手速和肌肉记忆的问题唯一的解决办法是真的打开终端去敲。随便到知乎搜一个“Linux文本处理练习100题”或者自己每天处理一个几十MB的真实日志文件比看十篇教程都有用。一个更典型的例子是“网络排查”。很多同学能背出traceroute的用途却不知道实际执行时第一跳通常是网关也不清楚telnet ip port是探测端口连通性的最常用姿势。这些内容不自己去试一遍笔试遇到“请写出排查一个服务端口不通的完整思路”就写不出具体命令只能写套话得分自然上不去。4.2 忽视“数据结构和算法”的基础题运维开发的笔试考算法吗考但绝对没有后端开发那么深。通常就是链表、栈、队列、hashmap、排序手写快排/归并、字符串处理、二分查找这些基础中的基础。但我发现一个现象很多运维方向的同学因为觉得“运维不用学算法”连单链表反转都写不完整。这就很亏。实际上滴滴这类公司的运维开发笔试里编程题虽然场景化但底层算法跟基本功是强相关的。比如写一个日志key的聚合统计本质上就是哈希表的运用实现一个简单的队列消费者本质上是对队列数据结构的理解。基础数据结构掌握了才能把业务场景抽象成代码否则就是拿一堆if-else硬凑。备考时至少把LeetCode的Top 100里那些简单和中等难度中跟字符串、数组、哈希表、二叉树相关的题刷一遍已经足够。4.3 题型理解偏差把选择填空当论述题把论述题当选择题这里说的是答题策略问题。有些同学做选择题的时候想太多把对的改成错的做主观题的时候又全写废话没有得分点。关于选择题我的建议是相信第一感觉除非你非常确定自己记错了否则别反复改关于主观题一定要分点作答、关键词前置。比如问“如何排查高CPU占用”你就直接写“1. top找到PID2. top -Hp找到线程3. printf %x转换线程ID4. jstack导出线程栈5. 定位到业务代码”每一条都是一句话但每一条都是得分点。千万别一整段话写下来阅卷人还要帮你找重点。特别注意主观题的“关键词”必须是你确实理解的术语不要瞎堆。比如问题问“如何排查网络问题”你写“可能是NAT转发的问题”就要能解释清楚NAT是什么、在哪一层、怎么查。写不了解的概念面试时被追问就是自己给自己埋雷。4.4 对“分布式与中间件”的认识过于表面滴滴的业务天然是分布式的所以运维开发笔试围绕分布式组件的考察几乎是必有的ZooKeeper是干什么的分布式协调、服务注册、配置管理、Kafka怎么保证消息不丢失producer端ack机制、broker端多副本、consumer端手动提交offset、Docker镜像和容器的区别镜像只是只读模板容器是运行态有可写层。这些概念题看似送分但如果只是背了定义没有画过架构图、没有手动部署过一个小集群答的时候就会干巴巴的。我建议备考时自己用虚拟机或者云主机搭一套最小可用的环境装一个Docker、跑一个Nginx容器、用docker-compose起一个MySQLRedis后端服务的组合。中间件的话搭一个单机ZooKeeper再搭一个单机Kafka试试往里面发消息、消费消息观察一下如果消费组挂了再恢复offset会怎么走。这个过程既能加深概念理解又能在笔试里举出“我实际部署过”的例子瞬间提升说服力。5. 从笔试到Offer运维开发工程师的长期修炼路线5.1 笔试只是起点别把备考和真实能力割裂开很多同学考完笔试就把这些知识扔了等面试过了才发现自己什么都不会。我想说一个反常识的观点运维开发笔试里考察的那些“死知识”恰恰是这份工作日常最需要的基本功。TCP握手和挥手、Linux进程模型、MySQL索引原理、Redis数据结构——这些不是背完就扔的考试内容而是你未来分析每一个线上问题都要用到的基础工具。面试官其实非常清楚这一点所以面试中会有大量的追问和情景模拟本质上就是要确认你到底是“背过”还是“懂”。就拿TCP的TIME_WAIT来说笔试里可能只是选择题面试里可能就会追问大量TIME_WAIT连接会有什么影响怎么通过sysctl参数调整tcp_tw_reuse和tcp_tw_recycle这两个参数分别解决什么问题为什么线上不建议开tcp_tw_recycle要想回答好这串问题你必须真正理解TCP状态机的运作机制而不是记住“出现大量TIME_WAIT就开tcp_tw_reuse”。我的经验是每复习一个知识点就把这个知识点往下挖两层“为什么”问到底直到你无法回答为止然后再去查资料补上。5.2 给不同阶段同学的备考顺序建议如果你是准备校招的应届生时间紧建议按优先级排序先把Python脚本能力打牢能独立写200行以内的小工具熟悉文件操作、日志管理、HTTP请求库requests、以及subprocess调用Shell命令。这是笔试和面试的生命线。Linux命令查漏补缺重点覆盖ps、top、netstat、ss、lsof、df、du、free、iostat、vmstat、sar、strace以及文件权限和软硬链接的理解。命令要知道常见参数而且要知道什么时候用哪个。TCP/IP和HTTP把三次握手、四次挥手、TIME_WAIT、TCP状态机、HTTP请求/响应结构、常见状态码、Cookie/Session的区别吃透。MySQL和Redis索引原理、事务、缓存穿透/击穿/雪崩会写基本的CRUD和简单的explain分析。Docker和CI/CD会用Dockerfile构建一个简单的Python应用镜像理解镜像分层和容器运行原理了解GitLab CI或Jenkins的基本配置方法。如果你是在职人员想转岗运维开发则建议增加一个完整的个人项目比如做一个简单的“服务器资产管理平台”或者“日志监控告警机器人”用Python写后端、MySQL存储、Redis做缓存再套一层Nginx反向代理用Docker部署。这个项目既能写在简历上也能在面试过程中展示你的工程能力比单纯堆一堆技术名词有说服力得多。5.3 运维开发的真正护城河故障处理的“肌肉记忆”最后我想说一个不那么“考试”但非常重要的点。笔试能考出你的知识储备但考不出你的“手感”——那种在凌晨三点被电话叫醒处理线上故障时能安静下来一步步排查问题、找到根因并止血的能力。这种手感来自大量真实事故的处理和复盘不是背题能学来的。但我可以给你一个成本很低的训练办法多读各大互联网公司的技术博客和故障复盘文章遇到一个故障案例先按下暂停键自己列一份排查方案再对照人家的方案看差在哪里。这个习惯坚持半年你的故障排查思路就会比同龄人高出一大截。我自己刚做运维开发那两年最深的体会是这个岗位最难的不是技术本身而是“在压力下保持冷静、在信息不全时做出判断”的能力。笔试只是这一长段修炼的入场券真正拉开差距的是后续在工作中对每一次故障、每一行代码、每一个告警的认真复盘和总结。备考滴滴这类大厂运维开发岗位核心就是三件事把Python写熟练、把Linux和网络的底层原理吃透、把监控和发布的知识体系搭建起来。把这篇里提到的知识框架梳理清楚再配合足量的线上实操你会发现自己面对的不只是一场笔试而是整个运维开发岗位的完整能力地图。