那年秋天我坐在学校的机房里对着一个全屏的在线考试系统右上角的倒计时一直在跳。三套试卷里我抽到的是“滴滴出行2018校园招聘网申笔试-运维开发工程师(第三套)”。运维开发这个岗位当年在应届生里还不像现在这么卷但“滴滴”这两个字本身就意味着业务体量巨大它的笔试明显不靠背诵过关而是考你有没有一套完整的工程思维。现在回头看这套题核心考察的链条非常清晰Linux系统基础、网络与数据库原理、脚本与自动化能力、监控与故障排查方法论再加上一点系统设计思路。这篇文章我就把这几大方向的考点拆开配上我自己踩过的坑和事后总结的备考方法给准备走运维开发路线的学弟学妹做一个参考。无论你是刚接触Linux的应届生还是已经有了一些服务器维护经验、想往DevOps方向转的同学这篇复盘应该都能对得上你的需求。1. 考前先想清楚运维开发笔试到底在考什么1.1 岗位定位与传统运维的差别很多同学一看到“运维开发”四个字就以为考的是Linux命令大全或者以为是纯后端开发考一堆算法和框架。这两种理解都偏了。从滴滴这类互联网公司的岗位定义来看运维开发工程师处在传统运维和业务开发之间的位置既要懂服务器、网络、数据库这些基础设施也要会写代码把重复的运维工作变成自动化工具和平台。笔试里的“开发”不是让你设计一个高并发秒杀系统而是考察你有没有能力用Shell或Python解决实际运维问题。比如批量日志分析、定时巡检脚本、接口异常重试、一个简单的发布流程设计。这些东西看起来不大但在真实生产环境里直接决定一个运维平台能不能跑得起来。所以备考时别一头扎进算法题里先把“用代码解决运维问题”的感觉练出来。1.2 2018年前后的技术环境与出题趋势理解笔试内容还得放到当时的行业背景里看。2018年容器化刚刚开始普及Kubernetes在少数头部公司进入生产但大多数公司还在用Ansible、SaltStack做自动化OpenStack在私有云里还有不少存量。滴滴这类体量的公司订单量千万级服务器和容器数量非常庞大纯靠人工去维护根本不现实所以自研运维平台、调度系统、发布系统是必然方向。这就决定了笔试绝对不会只考死记硬背的命令而是更看重你懂不懂“批量操作”“服务发现”“容量管理”“故障恢复”这些概念。哪怕你Docker没看过只要Linux、网络、数据库功底扎实还是有很大机会。反过来如果你简历里写了会Kubernetes但对TCP三次握手都说不清楚面试官反而会觉得基础不牢。1.3 从题型分布看复习优先级按我当时的回忆和经验这套卷子的题型大致分四块基础选择题、简答/场景设计题、编程题、综合逻辑题。分值权重按常规经验预估基础原理占四成左右编程脚本占三成系统设计类占两成其余是逻辑与综合。这个比例不是绝对的但能说明一个方向背命令细节的收益有限理解原理和动手写代码才是大头。这套卷子里单选题多考察概念辨析比如HTTP和HTTPS的区别、进程和线程的区别、TCP和UDP的区别这类。简答题通常给出一个运维场景让你描述处理思路。编程题则有明确的输入输出需要现场写Shell或Python。复习时我建议按“基础概念不需要逐字背诵但要做到能用自己的话讲清楚脚本必须自己敲一遍并跑通”这个标准来准备。2. 基础考点逐个拆解Linux、网络与数据库2.1 Linux不只考命令更考系统思维Linux部分看着都是命令题但背后考的是对系统运行机制的理解。拿最常见的日志分析题来说给你一个access.log要求统计访问量Top 10的IP。正确答案其实很简短awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这行命令考察了四个点awk取列、sort排序、uniq去重计数、管道串联。看起来简单但笔试里不少同学会把uniq -c的计数值放在第二列然后继续用$1取IP结果错位。这里有个习惯建议写完命令后自己心里推导一遍每一列是什么尤其是在管道符比较多的情况下。比命令更难的是概念题比如僵尸进程和孤儿进程的区别、文件描述符是什么、为什么rm删掉的文件空间没有释放。这些问题在笔试卷子里出现频率很高因为它们在真实故障排查中真的会遇到。我记得当时复习的一个重点是lsof | grep deleted生产环境里磁盘写满但du看不到大文件十有八九就是某个进程持有一个已删除文件的句柄文件空间被占用却不释放。笔试不会直接考这条命令但会考“磁盘空间被占用但找不到文件”这个场景答案就是这个机制。进程管理也是重点。top和ps基础用法必须烂熟还要理解systemd的基本概念比如systemctl status、systemctl enable是干什么的。端口查看命令ss -lntp当时已经逐渐替代netstat建议两个都看一眼。另外权限部分除了chmod的基本数字法setuid、sticky bit这些只要概念上有印象即可笔试如果出题通常是选择题不会让你现场实现一个ACL系统。2.2 网络基础从TCP握手到HTTP状态码网络是运维开发笔试中绝对不能丢分的大项。TCP三次握手几乎年年考但考法越来越活。不是简单问“为什么三次握手”而是问“为什么TIME_WAIT要等2MSL”。这个问题的回答要点有两层第一保证最后一次ACK如果丢失能让对方重发FIN第二让本次连接中所有迟到的报文在网络中自然消失避免干扰新的连接。理解了这层再延伸一下高并发短连接服务会出现大量TIME_WAIT影响新连接建立这种场景下怎么处理就是一个很好的简答题素材。HTTP状态码也是高频考点而且会结合场景出。比如用户访问网页出现502通常意味着网关后面的服务挂了出现504则说明服务还在但响应超时。301与302的区别、403和404的区别这些要能用自己的话解释清楚。有个简单记法4xx是客户端问题5xx是服务端问题。笔试时遇到过一道题给出一个请求从浏览器输入URL到页面展示的完整过程要求列出中间涉及的协议。这道题想看到的是你有没有整体网络思维一般按这个顺序答浏览器解析URL检查自身缓存。发起DNS解析请求拿到目标IP。建立TCP连接完成三次握手。如果是HTTPS先完成TLS握手协商密钥。浏览器发送HTTP请求服务端返回响应。浏览器解析HTML加载页面资源。每一步都可能继续展开比如DNS查询是递归还是迭代、CDN作用、Nginx反向代理怎么转发。备考时建议把这个过程反复练到能脱口而出很多网络题都能嵌套在这个框架里。2.3 数据库索引、事务、主从复制都要能说清楚数据库考察集中在MySQLRedis也偶尔出现。MySQL索引为什么快、为什么主键推荐自增整数这是必问点。B树索引能减少磁盘IO次数、有序存储适合范围查询同时叶子节点形成链表这是核心结论。笔试简答题里让你“分析一条慢查询”需要你能想到用EXPLAIN看执行计划看懂type、key、rows三个字段然后判断是不是索引失效。索引失效的常见原因要背熟对索引列使用函数或运算、隐式类型转换、LIKE以%开头、联合索引不满足最左前缀原则。这些知识点在选择题和场景题里反复出现。还有一个小点SELECT *不仅浪费内存和IO还可能让优化器放弃覆盖索引这个印象要建立起来。事务隔离级别是数据库部分的另一座“大山”。四个隔离级别从低到高分别是读未提交、读已提交、可重复读、串行化它们分别解决脏读、不可重复读、幻读的问题。MySQL默认是可重复读级别在可重复读下通过MVCC避免了大部分幻读但在某些锁定读场景下仍然可能发生。笔试一般不会考到这么深但你要能分辨三个术语脏读指的是读到别的事务未提交的数据不可重复读指的是同一查询在事务内两次结果不一致幻读指的是新增数据导致的“凭空多出”的记录。主从复制的原理也值得准备。它的基础逻辑不复杂主库把变更写入binlog从库的IO线程拉取binlog并写入relay logSQL线程再执行relay log里的内容。笔试里可能问“主从延迟怎么解决”你至少能说出几个方向优化大事务、降低单表写入压力、考虑读写分离分拆、监控延迟时间并用强制读主库兜底。Redis部分重点准备几个数据结构string、hash、list、set、zset和典型应用场景以及缓存穿透、缓存击穿、缓存雪崩的区别。穿透是查询了一个不存在的key每次都要请求数据库击穿是热点key突然过期大量请求直接打到数据库雪崩是大面积key同时过期或Redis宕机导致流量打崩数据库。应对方案分别是布隆过滤器/空值缓存、互斥锁/逻辑过期、过期时间加随机值/高可用。3. 脚本与自动化运维开发的基本功3.1 Shell脚本的常见题型与实战写法Shell编程在笔试里出现的概率非常高而且基本是两道题起步。一道简单的可能是“写脚本检查Nginx进程是否存在不存在则启动并记录日志”一道复杂的可能是“解析某个日志文件统计每类错误次数并输出Top 5”。我当时遇到的是前者但事后看这种题拼的不是“能不能实现功能”而是“实现得够不够稳”。#!/bin/bash pid$(pgrep -f nginx: master | head -1) if [ -z $pid ]; then echo nginx is down, restarting... /usr/local/nginx/sbin/nginx echo restart at $(date) /var/log/nginx_check.log fi这道题写完看起来简单但其中有几个会被扣分的点一是pgrep可能匹配到无关进程最好用-f加完整字符串二是检查命令执行结果要用退出码不能只看输出三是重启失败也要有处理比如再发告警四是脚本要加set -euo pipefail防止中途出错继续跑。笔试环境虽然不要求那么完善但这些细节写在注释里能让阅卷人觉得你有生产经验。写Shell有个通用口诀变量赋值等号两边不能有空格字符串变量记得加双引号在管道子shell里修改的变量不会带出子shellbash -x是调试神器。还有一点容易被忽略脚本开头加#!/bin/bash否则可能默认用sh解释语法兼容性会出问题。3.2 Python在运维开发中的位置如果说Shell是螺丝刀Python就是运维开发手里的电动工具。笔试里的编程题允许用Python但考的不是LeetCode那种算法而是跟文件处理、日志分析、接口请求相关的题目。比如给你一个日志文件每行包含接口名和响应时间要求输出平均响应时间最长的三个接口这就是一个非常典型的运维场景题。from collections import defaultdict cost_map defaultdict(list) with open(api.log, encodingutf-8) as f: for line in f: parts line.strip().split() if len(parts) 2: continue api, cost parts[0], float(parts[1]) cost_map[api].append(cost) result [] for api, costs in cost_map.items(): avg_cost sum(costs) / len(costs) result.append((api, avg_cost)) result.sort(keylambda x: x[1], reverseTrue) for api, avg_cost in result[:3]: print(api, round(avg_cost, 2))这道题考察的地方主要是文件读写是否健壮、空行和格式异常能否处理、数据结构选择是否合理、以及是否知道怎么排序取前三。我在实际笔试里吃过亏的是没做异常处理日志里混了一行空行导致整个程序崩溃。后来总结经验凡是处理外部数据的程序第一件事就是考虑脏数据先用try/except或者过滤逻辑把异常数据挡在外面。Python部分还经常考一些内置库的用法比如os、re、requests、json、subprocess。这些不用背API但至少要能用出来。比API更重要的是思路让脚本能应对“文件不存在”“网络请求超时”“目标服务未启动”这些异常情况。笔试时如果时间宽裕尽量在最后补一个main()函数和异常处理框架这会让代码看起来很工程化分数更容易上去。3.3 配置管理与发布流程一套“概念落地”组合拳除了命令和编程卷子里通常还会有一两道跟自动化运维相关的简答题常见的是“请描述一次完整的发布流程”或者“请说明蓝绿部署与滚动发布的区别”。这种题考查的是你有没有亲身参与过线上变更或者至少理解其中的关键环节。Ansible这类工具在2018年已经是主流核心概念是inventory、playbook、module。笔试不会让你背文档但你要知道Ansible基于SSH、无agent、playbook采用YAML声明式写法、模块要幂等这些特点。幂等这个概念可以类比成“同一份菜谱反复做每次做出来的菜都一样”放到系统里就是重复执行操作不会产生副作用这是自动化配置管理的基本要求。发布策略是另一个要懂的点。蓝绿部署是准备两套完全相同的环境切换流量的时候整体切过去好处是回滚快坏处是资源成本高。滚动发布是分批替换旧版本实例优点是节省资源缺点是发布和回滚过程更容易出错。金丝雀发布是最先放量到一小部分机器或一小部分用户上观察没问题再放量。回答这类题时一个比较讨喜的结构是先说方案目的再讲具体怎么操作再补一句该方案的优缺点最后落到“如果失败怎么回滚”。能把这四点说全基本上分数就稳了。4. 监控、日志与故障排查运维的“眼睛”和“直觉”4.1 监控系统设计分层比工具更重要监控相关的题目在笔试卷子里不一定直接问“Prometheus怎么配”但会问“系统突然变慢你怎么排查”“线上服务挂了你通过什么方式发现”。这些题的根源都在监控体系上。我备考时把监控分了三层来理解答题时会按这个顺序展开。第一层是基础设施监控关心CPU、内存、磁盘、网络这些机器指标。工具上2018年Zabbix和Prometheus已经开始并行出现Prometheus加Grafana的组合在面试中提起来会很加分。第二层是应用性能监控关心QPS、平均响应时间、错误率、线程池饱和度这些能反映服务本身的健康状态。第三层是业务监控比如滴滴会关心下单成功率、支付成功率、司机接单时长这一类指标才真正影响用户体感。告警阈值设计也有讲究。不是说CPU到了100%才告警就合理通常建议CPU使用率持续5分钟超过85%就触发告警磁盘使用率超过80%就需要关注因为不少临时文件、日志增长会在短时间内把剩余空间打满。笔试答题时提一句“告警要分级不能所有告警都拉人否则狼来了喊多了就没人响应”会显得你有实战经验。4.2 日志分析把分散的信息串成一条线日志是排查问题的第一手资料也是运维开发笔试里常出现的场景。一套线上服务前端有Nginx访问日志应用有业务日志数据库有慢查询日志怎么通过日志快速定位问题是考点。理想的方案是集中式日志系统2018年最常见的组合是ELK也就是Elasticsearch、Logstash、Kibana。笔试不会让你搭建一套ELK但会问“日志格式怎么设计”这类问题。我的回答思路是所有日志必须有统一的时间戳和唯一标识。拿请求链路来说网关在入口生成一个request_id后续微服务收到的请求都携带同一个request_id这样在排查问题时只要用request_id去每个服务日志里搜索就能把整条调用链串起来。这个思路在笔试里是可以直接写进简答题答案的而且很加分。另外日志文件要定期切割和归档。很多同学不知道为什么日志要按天切割其实一是避免单个文件过大导致磁盘爆满二是方便按时间段排查。如果没有切割一个几十GB的日志文件在定位问题时体验非常痛苦。笔试如果问“磁盘被日志写满了怎么办”除了清理归档还要想到配置logrotate这类工具按大小或者按天自动分割日志。4.3 经典故障排查案例从现象到根因的思考过程故障排查题是整套卷子里最能拉开差距的部分因为这类题没有标准答案考的是思路。跟我一起笔试的同学出来后抱怨说“没答完”其实就是栽在这种开放题上。遇到这类题最忌讳一上来就写“重启一下”要展示从现象逐步定位根因的过程。场景一接口响应突然变慢。我的排查路径是先看监控大盘判断是单机问题还是整体问题然后登录机器执行top查看CPU和负载再用free -h看内存如果CPU不高就去看慢查询和下游RPC调用耗时如果还找不到就用strace -p跟一下进程的系统调用。这道题的关键是让阅卷人看到你的排查顺序是有逻辑的不是东一下西一下。场景二磁盘空间满了。先df -h确认哪块盘满再用du -sh /path/*逐层找到大目录排除普通文件后如果磁盘依然显示被占用但看不到大文件就要用lsof | grep deleted查找被删除但仍被进程占用的文件。生产环境非常经典的场景是日志文件被rm了但进程一直持有文件句柄空间不释放只能重启进程或者 file清空处理。场景三CPU达到100%。用top定位到高CPU进程后再用top -Hp 进程号找到具体线程如果是Java应用用jstack打印线程栈配合grep找到对应线程号就能看到在跑什么代码。这种题在笔试卷子里可能不会考到JVM那么细但你至少要知道线程栈是排查Java程序CPU飙升的必备工具。高频流量冲击下的系统设计也很重要。限流、降级、熔断这三个词在2018年的运维开发笔试里已经出现。限流控制请求速率常用令牌桶和漏桶算法保护系统不被突发流量打垮降级是在依赖服务不可用时返回兜底数据或直接拒绝确保核心链路不受影响熔断是当某个下游错误率达到阈值后快速失败相当于给系统加了一个断路器。把这些概念讲清楚答简答题的时候会非常出彩。5. 笔试实战心得与备考路线5.1 我踩过的坑希望你别再踩现在回看那次笔试有几个教训特别深刻。第一是时间分配失误。我前半小时在几道概念选择题上反复纠结结果做到编程题时只剩不到20分钟草草写出来的代码根本没有跑通的把握。正确做法是先快速扫一遍全卷找分多的题先做尤其是编程题和系统设计题。选择题里面再难也就一两分不值得用10分钟去赌。第二是审题不够仔细。笔试题目有时候会限定“请使用Shell脚本实现”我身边有同学平时用Python顺手忽略了题目要求直接写了Python结果就是整道题不给分。这个太可惜了。考试时读完题先把关键词圈出来是Shell还是Python是输出Top 10还是统计总数差一个词答案就完全不同。第三是代码不写注释且不考虑边界。在线笔试的阅卷环境虽然很多时候是人工看的但代码的可读性会影响评分。变量命名清晰、函数拆分合理、关键步骤加注释这些习惯都在考官眼里。还有边界条件比如处理的文件不存在、日志为空、输入参数异常如果你能提前在代码里过滤掉这些情况说明你具备上线代码的基本素养。5.2 不同基础的人备考路线怎么走如果你目前只会用几条命令建议把时间花在核心命令和脚本语法上。鸟哥的Linux私房菜基础篇通读一遍重点掌握grep、awk、sed、sort、uniq、xargs每学一条就立刻在命令行里练一遍。网络和数据库部分可以看《TCP/IP详解卷一》的精选章节和《高性能MySQL》的索引与事务部分不必全读但原理要理解。如果你已经有一些服务器维护经验可以集中精力练编程和系统设计题。Python刷题不需要去挑战难题重点做字符串处理、文件操作、字典统计、简单排序这类。发布流程、监控体系这些概念花半天整理成自己的话术然后用费曼技巧讲给别人听讲不出来的地方就是你的知识漏洞。考前一周非常关键不建议再啃新知识点把之前整理的命令笔记、状态码表、索引失效场景、隔离级别对比全部过一遍。如果能把常见简答题的答案流畅地写出来说明水平已经比较稳定了。5.3 拿到卷子以后我推荐的答题顺序这算是我的“压箱底”经验。整个笔试过程大概90分钟到120分钟我的习惯是拿到卷子先花3分钟浏览全卷做一次“分值标记”把编程题和规模较大的场景设计题找出来。然后按这样的顺序作答先写编程题因为分值高且需要思考时间再做系统设计题这类题写多不扣分尽量把监控、发布、回滚都说上最后做选择题和判断题它们是稳定拿分项但不要过度纠结。简答题的回答策略我总结为“结论前置加三步展开”。比如问“线上服务挂了你怎么处理”第一句话先给结论“先恢复再定位”然后列步骤看监控和告警确定影响范围通过日志快速定位直接原因并恢复事后复盘和补充监控。每一步都再补一两句具体细节整段答案看起来就有条理。还有个小技巧遇到完全不会的题把你能想到的相关步骤写出来比如“我会先看内存和CPU再查nginx error log”这种流程描述也能拿到部分过程分。结尾那次滴滴笔试之后我又陆续参加过其他几家互联网公司的运维开发笔试套路其实大同小异。现在回头想真正让我受益的不是某一道题的正确答案而是备考过程中建立的体系感遇到任何线上问题都知道先看监控再查日志然后定位进程最后落到代码和配置。运维开发这个岗位本质上就是拿代码去解决运维问题把一次手工操作变成可重复、可观测、可回滚的系统能力。我后来带过不少新人发现笔试里表现的差距往往就是平时有没有真正管理过服务器、看过线上日志、处理过宕机决定的。如果你还在校建议别只刷题自己搭一台虚拟机把Nginx跑起来故意改坏配置再修复模拟一次磁盘写满再清理这些经历比任何题库都有用。等你在笔试里遇到“服务响应变慢”这类问题时你会发现自己居然能写得停不下来。 运维开发笔试核心考点全拆解：Linux、网络与自动化
那年秋天我坐在学校的机房里对着一个全屏的在线考试系统右上角的倒计时一直在跳。三套试卷里我抽到的是“滴滴出行2018校园招聘网申笔试-运维开发工程师(第三套)”。运维开发这个岗位当年在应届生里还不像现在这么卷但“滴滴”这两个字本身就意味着业务体量巨大它的笔试明显不靠背诵过关而是考你有没有一套完整的工程思维。现在回头看这套题核心考察的链条非常清晰Linux系统基础、网络与数据库原理、脚本与自动化能力、监控与故障排查方法论再加上一点系统设计思路。这篇文章我就把这几大方向的考点拆开配上我自己踩过的坑和事后总结的备考方法给准备走运维开发路线的学弟学妹做一个参考。无论你是刚接触Linux的应届生还是已经有了一些服务器维护经验、想往DevOps方向转的同学这篇复盘应该都能对得上你的需求。1. 考前先想清楚运维开发笔试到底在考什么1.1 岗位定位与传统运维的差别很多同学一看到“运维开发”四个字就以为考的是Linux命令大全或者以为是纯后端开发考一堆算法和框架。这两种理解都偏了。从滴滴这类互联网公司的岗位定义来看运维开发工程师处在传统运维和业务开发之间的位置既要懂服务器、网络、数据库这些基础设施也要会写代码把重复的运维工作变成自动化工具和平台。笔试里的“开发”不是让你设计一个高并发秒杀系统而是考察你有没有能力用Shell或Python解决实际运维问题。比如批量日志分析、定时巡检脚本、接口异常重试、一个简单的发布流程设计。这些东西看起来不大但在真实生产环境里直接决定一个运维平台能不能跑得起来。所以备考时别一头扎进算法题里先把“用代码解决运维问题”的感觉练出来。1.2 2018年前后的技术环境与出题趋势理解笔试内容还得放到当时的行业背景里看。2018年容器化刚刚开始普及Kubernetes在少数头部公司进入生产但大多数公司还在用Ansible、SaltStack做自动化OpenStack在私有云里还有不少存量。滴滴这类体量的公司订单量千万级服务器和容器数量非常庞大纯靠人工去维护根本不现实所以自研运维平台、调度系统、发布系统是必然方向。这就决定了笔试绝对不会只考死记硬背的命令而是更看重你懂不懂“批量操作”“服务发现”“容量管理”“故障恢复”这些概念。哪怕你Docker没看过只要Linux、网络、数据库功底扎实还是有很大机会。反过来如果你简历里写了会Kubernetes但对TCP三次握手都说不清楚面试官反而会觉得基础不牢。1.3 从题型分布看复习优先级按我当时的回忆和经验这套卷子的题型大致分四块基础选择题、简答/场景设计题、编程题、综合逻辑题。分值权重按常规经验预估基础原理占四成左右编程脚本占三成系统设计类占两成其余是逻辑与综合。这个比例不是绝对的但能说明一个方向背命令细节的收益有限理解原理和动手写代码才是大头。这套卷子里单选题多考察概念辨析比如HTTP和HTTPS的区别、进程和线程的区别、TCP和UDP的区别这类。简答题通常给出一个运维场景让你描述处理思路。编程题则有明确的输入输出需要现场写Shell或Python。复习时我建议按“基础概念不需要逐字背诵但要做到能用自己的话讲清楚脚本必须自己敲一遍并跑通”这个标准来准备。2. 基础考点逐个拆解Linux、网络与数据库2.1 Linux不只考命令更考系统思维Linux部分看着都是命令题但背后考的是对系统运行机制的理解。拿最常见的日志分析题来说给你一个access.log要求统计访问量Top 10的IP。正确答案其实很简短awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这行命令考察了四个点awk取列、sort排序、uniq去重计数、管道串联。看起来简单但笔试里不少同学会把uniq -c的计数值放在第二列然后继续用$1取IP结果错位。这里有个习惯建议写完命令后自己心里推导一遍每一列是什么尤其是在管道符比较多的情况下。比命令更难的是概念题比如僵尸进程和孤儿进程的区别、文件描述符是什么、为什么rm删掉的文件空间没有释放。这些问题在笔试卷子里出现频率很高因为它们在真实故障排查中真的会遇到。我记得当时复习的一个重点是lsof | grep deleted生产环境里磁盘写满但du看不到大文件十有八九就是某个进程持有一个已删除文件的句柄文件空间被占用却不释放。笔试不会直接考这条命令但会考“磁盘空间被占用但找不到文件”这个场景答案就是这个机制。进程管理也是重点。top和ps基础用法必须烂熟还要理解systemd的基本概念比如systemctl status、systemctl enable是干什么的。端口查看命令ss -lntp当时已经逐渐替代netstat建议两个都看一眼。另外权限部分除了chmod的基本数字法setuid、sticky bit这些只要概念上有印象即可笔试如果出题通常是选择题不会让你现场实现一个ACL系统。2.2 网络基础从TCP握手到HTTP状态码网络是运维开发笔试中绝对不能丢分的大项。TCP三次握手几乎年年考但考法越来越活。不是简单问“为什么三次握手”而是问“为什么TIME_WAIT要等2MSL”。这个问题的回答要点有两层第一保证最后一次ACK如果丢失能让对方重发FIN第二让本次连接中所有迟到的报文在网络中自然消失避免干扰新的连接。理解了这层再延伸一下高并发短连接服务会出现大量TIME_WAIT影响新连接建立这种场景下怎么处理就是一个很好的简答题素材。HTTP状态码也是高频考点而且会结合场景出。比如用户访问网页出现502通常意味着网关后面的服务挂了出现504则说明服务还在但响应超时。301与302的区别、403和404的区别这些要能用自己的话解释清楚。有个简单记法4xx是客户端问题5xx是服务端问题。笔试时遇到过一道题给出一个请求从浏览器输入URL到页面展示的完整过程要求列出中间涉及的协议。这道题想看到的是你有没有整体网络思维一般按这个顺序答浏览器解析URL检查自身缓存。发起DNS解析请求拿到目标IP。建立TCP连接完成三次握手。如果是HTTPS先完成TLS握手协商密钥。浏览器发送HTTP请求服务端返回响应。浏览器解析HTML加载页面资源。每一步都可能继续展开比如DNS查询是递归还是迭代、CDN作用、Nginx反向代理怎么转发。备考时建议把这个过程反复练到能脱口而出很多网络题都能嵌套在这个框架里。2.3 数据库索引、事务、主从复制都要能说清楚数据库考察集中在MySQLRedis也偶尔出现。MySQL索引为什么快、为什么主键推荐自增整数这是必问点。B树索引能减少磁盘IO次数、有序存储适合范围查询同时叶子节点形成链表这是核心结论。笔试简答题里让你“分析一条慢查询”需要你能想到用EXPLAIN看执行计划看懂type、key、rows三个字段然后判断是不是索引失效。索引失效的常见原因要背熟对索引列使用函数或运算、隐式类型转换、LIKE以%开头、联合索引不满足最左前缀原则。这些知识点在选择题和场景题里反复出现。还有一个小点SELECT *不仅浪费内存和IO还可能让优化器放弃覆盖索引这个印象要建立起来。事务隔离级别是数据库部分的另一座“大山”。四个隔离级别从低到高分别是读未提交、读已提交、可重复读、串行化它们分别解决脏读、不可重复读、幻读的问题。MySQL默认是可重复读级别在可重复读下通过MVCC避免了大部分幻读但在某些锁定读场景下仍然可能发生。笔试一般不会考到这么深但你要能分辨三个术语脏读指的是读到别的事务未提交的数据不可重复读指的是同一查询在事务内两次结果不一致幻读指的是新增数据导致的“凭空多出”的记录。主从复制的原理也值得准备。它的基础逻辑不复杂主库把变更写入binlog从库的IO线程拉取binlog并写入relay logSQL线程再执行relay log里的内容。笔试里可能问“主从延迟怎么解决”你至少能说出几个方向优化大事务、降低单表写入压力、考虑读写分离分拆、监控延迟时间并用强制读主库兜底。Redis部分重点准备几个数据结构string、hash、list、set、zset和典型应用场景以及缓存穿透、缓存击穿、缓存雪崩的区别。穿透是查询了一个不存在的key每次都要请求数据库击穿是热点key突然过期大量请求直接打到数据库雪崩是大面积key同时过期或Redis宕机导致流量打崩数据库。应对方案分别是布隆过滤器/空值缓存、互斥锁/逻辑过期、过期时间加随机值/高可用。3. 脚本与自动化运维开发的基本功3.1 Shell脚本的常见题型与实战写法Shell编程在笔试里出现的概率非常高而且基本是两道题起步。一道简单的可能是“写脚本检查Nginx进程是否存在不存在则启动并记录日志”一道复杂的可能是“解析某个日志文件统计每类错误次数并输出Top 5”。我当时遇到的是前者但事后看这种题拼的不是“能不能实现功能”而是“实现得够不够稳”。#!/bin/bash pid$(pgrep -f nginx: master | head -1) if [ -z $pid ]; then echo nginx is down, restarting... /usr/local/nginx/sbin/nginx echo restart at $(date) /var/log/nginx_check.log fi这道题写完看起来简单但其中有几个会被扣分的点一是pgrep可能匹配到无关进程最好用-f加完整字符串二是检查命令执行结果要用退出码不能只看输出三是重启失败也要有处理比如再发告警四是脚本要加set -euo pipefail防止中途出错继续跑。笔试环境虽然不要求那么完善但这些细节写在注释里能让阅卷人觉得你有生产经验。写Shell有个通用口诀变量赋值等号两边不能有空格字符串变量记得加双引号在管道子shell里修改的变量不会带出子shellbash -x是调试神器。还有一点容易被忽略脚本开头加#!/bin/bash否则可能默认用sh解释语法兼容性会出问题。3.2 Python在运维开发中的位置如果说Shell是螺丝刀Python就是运维开发手里的电动工具。笔试里的编程题允许用Python但考的不是LeetCode那种算法而是跟文件处理、日志分析、接口请求相关的题目。比如给你一个日志文件每行包含接口名和响应时间要求输出平均响应时间最长的三个接口这就是一个非常典型的运维场景题。from collections import defaultdict cost_map defaultdict(list) with open(api.log, encodingutf-8) as f: for line in f: parts line.strip().split() if len(parts) 2: continue api, cost parts[0], float(parts[1]) cost_map[api].append(cost) result [] for api, costs in cost_map.items(): avg_cost sum(costs) / len(costs) result.append((api, avg_cost)) result.sort(keylambda x: x[1], reverseTrue) for api, avg_cost in result[:3]: print(api, round(avg_cost, 2))这道题考察的地方主要是文件读写是否健壮、空行和格式异常能否处理、数据结构选择是否合理、以及是否知道怎么排序取前三。我在实际笔试里吃过亏的是没做异常处理日志里混了一行空行导致整个程序崩溃。后来总结经验凡是处理外部数据的程序第一件事就是考虑脏数据先用try/except或者过滤逻辑把异常数据挡在外面。Python部分还经常考一些内置库的用法比如os、re、requests、json、subprocess。这些不用背API但至少要能用出来。比API更重要的是思路让脚本能应对“文件不存在”“网络请求超时”“目标服务未启动”这些异常情况。笔试时如果时间宽裕尽量在最后补一个main()函数和异常处理框架这会让代码看起来很工程化分数更容易上去。3.3 配置管理与发布流程一套“概念落地”组合拳除了命令和编程卷子里通常还会有一两道跟自动化运维相关的简答题常见的是“请描述一次完整的发布流程”或者“请说明蓝绿部署与滚动发布的区别”。这种题考查的是你有没有亲身参与过线上变更或者至少理解其中的关键环节。Ansible这类工具在2018年已经是主流核心概念是inventory、playbook、module。笔试不会让你背文档但你要知道Ansible基于SSH、无agent、playbook采用YAML声明式写法、模块要幂等这些特点。幂等这个概念可以类比成“同一份菜谱反复做每次做出来的菜都一样”放到系统里就是重复执行操作不会产生副作用这是自动化配置管理的基本要求。发布策略是另一个要懂的点。蓝绿部署是准备两套完全相同的环境切换流量的时候整体切过去好处是回滚快坏处是资源成本高。滚动发布是分批替换旧版本实例优点是节省资源缺点是发布和回滚过程更容易出错。金丝雀发布是最先放量到一小部分机器或一小部分用户上观察没问题再放量。回答这类题时一个比较讨喜的结构是先说方案目的再讲具体怎么操作再补一句该方案的优缺点最后落到“如果失败怎么回滚”。能把这四点说全基本上分数就稳了。4. 监控、日志与故障排查运维的“眼睛”和“直觉”4.1 监控系统设计分层比工具更重要监控相关的题目在笔试卷子里不一定直接问“Prometheus怎么配”但会问“系统突然变慢你怎么排查”“线上服务挂了你通过什么方式发现”。这些题的根源都在监控体系上。我备考时把监控分了三层来理解答题时会按这个顺序展开。第一层是基础设施监控关心CPU、内存、磁盘、网络这些机器指标。工具上2018年Zabbix和Prometheus已经开始并行出现Prometheus加Grafana的组合在面试中提起来会很加分。第二层是应用性能监控关心QPS、平均响应时间、错误率、线程池饱和度这些能反映服务本身的健康状态。第三层是业务监控比如滴滴会关心下单成功率、支付成功率、司机接单时长这一类指标才真正影响用户体感。告警阈值设计也有讲究。不是说CPU到了100%才告警就合理通常建议CPU使用率持续5分钟超过85%就触发告警磁盘使用率超过80%就需要关注因为不少临时文件、日志增长会在短时间内把剩余空间打满。笔试答题时提一句“告警要分级不能所有告警都拉人否则狼来了喊多了就没人响应”会显得你有实战经验。4.2 日志分析把分散的信息串成一条线日志是排查问题的第一手资料也是运维开发笔试里常出现的场景。一套线上服务前端有Nginx访问日志应用有业务日志数据库有慢查询日志怎么通过日志快速定位问题是考点。理想的方案是集中式日志系统2018年最常见的组合是ELK也就是Elasticsearch、Logstash、Kibana。笔试不会让你搭建一套ELK但会问“日志格式怎么设计”这类问题。我的回答思路是所有日志必须有统一的时间戳和唯一标识。拿请求链路来说网关在入口生成一个request_id后续微服务收到的请求都携带同一个request_id这样在排查问题时只要用request_id去每个服务日志里搜索就能把整条调用链串起来。这个思路在笔试里是可以直接写进简答题答案的而且很加分。另外日志文件要定期切割和归档。很多同学不知道为什么日志要按天切割其实一是避免单个文件过大导致磁盘爆满二是方便按时间段排查。如果没有切割一个几十GB的日志文件在定位问题时体验非常痛苦。笔试如果问“磁盘被日志写满了怎么办”除了清理归档还要想到配置logrotate这类工具按大小或者按天自动分割日志。4.3 经典故障排查案例从现象到根因的思考过程故障排查题是整套卷子里最能拉开差距的部分因为这类题没有标准答案考的是思路。跟我一起笔试的同学出来后抱怨说“没答完”其实就是栽在这种开放题上。遇到这类题最忌讳一上来就写“重启一下”要展示从现象逐步定位根因的过程。场景一接口响应突然变慢。我的排查路径是先看监控大盘判断是单机问题还是整体问题然后登录机器执行top查看CPU和负载再用free -h看内存如果CPU不高就去看慢查询和下游RPC调用耗时如果还找不到就用strace -p跟一下进程的系统调用。这道题的关键是让阅卷人看到你的排查顺序是有逻辑的不是东一下西一下。场景二磁盘空间满了。先df -h确认哪块盘满再用du -sh /path/*逐层找到大目录排除普通文件后如果磁盘依然显示被占用但看不到大文件就要用lsof | grep deleted查找被删除但仍被进程占用的文件。生产环境非常经典的场景是日志文件被rm了但进程一直持有文件句柄空间不释放只能重启进程或者 file清空处理。场景三CPU达到100%。用top定位到高CPU进程后再用top -Hp 进程号找到具体线程如果是Java应用用jstack打印线程栈配合grep找到对应线程号就能看到在跑什么代码。这种题在笔试卷子里可能不会考到JVM那么细但你至少要知道线程栈是排查Java程序CPU飙升的必备工具。高频流量冲击下的系统设计也很重要。限流、降级、熔断这三个词在2018年的运维开发笔试里已经出现。限流控制请求速率常用令牌桶和漏桶算法保护系统不被突发流量打垮降级是在依赖服务不可用时返回兜底数据或直接拒绝确保核心链路不受影响熔断是当某个下游错误率达到阈值后快速失败相当于给系统加了一个断路器。把这些概念讲清楚答简答题的时候会非常出彩。5. 笔试实战心得与备考路线5.1 我踩过的坑希望你别再踩现在回看那次笔试有几个教训特别深刻。第一是时间分配失误。我前半小时在几道概念选择题上反复纠结结果做到编程题时只剩不到20分钟草草写出来的代码根本没有跑通的把握。正确做法是先快速扫一遍全卷找分多的题先做尤其是编程题和系统设计题。选择题里面再难也就一两分不值得用10分钟去赌。第二是审题不够仔细。笔试题目有时候会限定“请使用Shell脚本实现”我身边有同学平时用Python顺手忽略了题目要求直接写了Python结果就是整道题不给分。这个太可惜了。考试时读完题先把关键词圈出来是Shell还是Python是输出Top 10还是统计总数差一个词答案就完全不同。第三是代码不写注释且不考虑边界。在线笔试的阅卷环境虽然很多时候是人工看的但代码的可读性会影响评分。变量命名清晰、函数拆分合理、关键步骤加注释这些习惯都在考官眼里。还有边界条件比如处理的文件不存在、日志为空、输入参数异常如果你能提前在代码里过滤掉这些情况说明你具备上线代码的基本素养。5.2 不同基础的人备考路线怎么走如果你目前只会用几条命令建议把时间花在核心命令和脚本语法上。鸟哥的Linux私房菜基础篇通读一遍重点掌握grep、awk、sed、sort、uniq、xargs每学一条就立刻在命令行里练一遍。网络和数据库部分可以看《TCP/IP详解卷一》的精选章节和《高性能MySQL》的索引与事务部分不必全读但原理要理解。如果你已经有一些服务器维护经验可以集中精力练编程和系统设计题。Python刷题不需要去挑战难题重点做字符串处理、文件操作、字典统计、简单排序这类。发布流程、监控体系这些概念花半天整理成自己的话术然后用费曼技巧讲给别人听讲不出来的地方就是你的知识漏洞。考前一周非常关键不建议再啃新知识点把之前整理的命令笔记、状态码表、索引失效场景、隔离级别对比全部过一遍。如果能把常见简答题的答案流畅地写出来说明水平已经比较稳定了。5.3 拿到卷子以后我推荐的答题顺序这算是我的“压箱底”经验。整个笔试过程大概90分钟到120分钟我的习惯是拿到卷子先花3分钟浏览全卷做一次“分值标记”把编程题和规模较大的场景设计题找出来。然后按这样的顺序作答先写编程题因为分值高且需要思考时间再做系统设计题这类题写多不扣分尽量把监控、发布、回滚都说上最后做选择题和判断题它们是稳定拿分项但不要过度纠结。简答题的回答策略我总结为“结论前置加三步展开”。比如问“线上服务挂了你怎么处理”第一句话先给结论“先恢复再定位”然后列步骤看监控和告警确定影响范围通过日志快速定位直接原因并恢复事后复盘和补充监控。每一步都再补一两句具体细节整段答案看起来就有条理。还有个小技巧遇到完全不会的题把你能想到的相关步骤写出来比如“我会先看内存和CPU再查nginx error log”这种流程描述也能拿到部分过程分。结尾那次滴滴笔试之后我又陆续参加过其他几家互联网公司的运维开发笔试套路其实大同小异。现在回头想真正让我受益的不是某一道题的正确答案而是备考过程中建立的体系感遇到任何线上问题都知道先看监控再查日志然后定位进程最后落到代码和配置。运维开发这个岗位本质上就是拿代码去解决运维问题把一次手工操作变成可重复、可观测、可回滚的系统能力。我后来带过不少新人发现笔试里表现的差距往往就是平时有没有真正管理过服务器、看过线上日志、处理过宕机决定的。如果你还在校建议别只刷题自己搭一台虚拟机把Nginx跑起来故意改坏配置再修复模拟一次磁盘写满再清理这些经历比任何题库都有用。等你在笔试里遇到“服务响应变慢”这类问题时你会发现自己居然能写得停不下来。