“运维开发”这个词放在2019年春招的背景下已经是互联网大厂招聘里的高频标签了。京东这份2019春招运维开发类试卷虽然只是众多技术岗笔试中的一份但它背后传递的信号很明确企业要的不是只会敲命令的运维也不是只懂写业务代码的开发而是能把两者融会贯通的人。这篇文章我会结合自己备考和参加笔试的经历复盘这份试卷的题型结构、核心考点和几道印象深刻的真题帮想进大厂做运维开发、SRE的同学理清备考思路也聊聊这类岗位到底看重什么能力。我在准备京东运维开发笔试的时候其实走过不少弯路。一开始我以为是考“运维知识大全”把网络、Linux、数据库、中间件都背了一遍结果拿到试卷才发现真正的难点不在于单个知识点而在于把多个基础点串起来解决一个具体问题。所以这篇文章我不会只列考点还会把我踩过的坑和总结的解题思路一并写出来希望能让后来的人少走弯路。1. 简历筛过之后笔试才是第一道坎京东运维开发笔试的总体印象1.1 运维开发到底在考什么先说说这个岗位本身。运维开发英文通常会写DevOps Engineer或者SRE但在2019年那个时间点京东等互联网公司大量招的运维开发岗核心职责已经不再是传统意义上的机房巡检、装系统、重启服务。它更强调“用开发的思路解决运维的问题”比如写自动化脚本、搭监控告警系统、做发布平台、搞容量评估和故障演练。京东的电商业务场景非常复杂尤其是618、双11这种大促场景流量是平时的数倍甚至十几倍。对运维开发的考验是你能不能提前发现系统瓶颈能不能在大流量来临时保证服务不挂挂了之后能不能快速止血。这套笔试的命题思路其实是围绕“稳定、效率、自动化”三个关键词展开的。你光会背TCP三次握手不会用光会写Shell脚本但不会做异常处理都拿不到高分。所以准备笔试的第一步不是刷题而是搞清楚这个岗位究竟要你干什么。一句话概括既要会造轮子又要会补轮胎。1.2 试卷结构与时间分配我印象里这套试卷的题型大致分为四类单选题、多选题、简答题、编程题和综合设计题。前两类以基础概念为主网络、操作系统、数据结构、数据库都会涉及覆盖面很广但深度不会太夸张简答题重点考察你对原理的理解比如“为什么Redis这么快”“简述一次完整的HTTP请求过程”编程题一般会给你一个具体场景让你用Shell或Python写一段脚本综合设计题是重头戏往往会给你一个业务背景让你设计一套高可用架构或者一个监控告警方案。整个笔试时间一般控制在120分钟左右题量不算少如果前面选择题磨太久后面的编程和设计题很容易来不及。这里有一个非常实际的建议先做编程题和综合设计题因为这两类分值最高而且只要你写出了一个可用方案哪怕不完美也能拿到大部分分。选择题一道可能就一两分卡在某个TCP细节上十分钟性价比太低。我当时就是因为先死磕选择题结果最后一道综合设计题只写了个大纲分数出来非常可惜。这个教训后面我再展开讲。2. 从试卷看运维开发的技术栈网络、操作系统与脚本编程2.1 计算机网络与TCP/IP高频考点网络部分是这份试卷绕不开的重头戏。运维开发日常接触最多的事情就是“服务连不上”“接口超时”“流量异常”这些都是网络问题。试卷里考察的知识点主要集中在TCP协议、HTTP协议、DNS解析、负载均衡这几个模块。TCP三次握手和四次挥手几乎每年必考但2019年这套试卷里有两道变形题特别有意思。一道是“为什么TIME_WAIT状态要等待2MSL”另一道是“大量TIME_WAIT连接会导致什么如何优化”。前者考原理后者考实战。大量TIME_WAIT这个问题在京东这种高并发的短连接场景下非常典型一个前端Nginx节点在秒杀时可能出现数万个TIME_WAIT连接。解决办法一般有几个方向开启tcp_tw_reuse、调整tcp_fin_timeout、减少短连接使用改用长连接或者通过tcp_tw_recycle但这个在新版内核里已经不建议用了。笔试里如果能把这几个点写出来分数会明显不一样。HTTP状态码也是固定考点。200、301、302、403、404、500、502、503每一个都可能出现在反问里。我印象最深的是502和504的区别502是网关从上游收到了无效响应而504是网关在指定时间内没等到上游响应。很多人在简历里写了“熟悉Nginx”但碰到这种问题说不清楚笔试就会被筛掉。负责均衡相关的题目也会换着花样出现。比如Nginx的轮询、加权轮询、ip_hash、least_conn分别适合什么场景会话保持怎么做后端节点下线时如何优雅摘除。这些题目不难但如果你只是用过Nginx没深入理解很容易答串。2.2 Linux操作系统与系统调优运维开发的第二个核心底盘是Linux。试卷中关于操作系统和Linux的题目很少直接考你“进程和线程的区别”这种八股文而是放进一个具体问题里。比如“某台机器负载突然飙升如何排查”“CPU使用率不高但服务响应很慢可能是哪些原因”。这类问题考察的是你对系统性能指标的理解。load average和CPU使用率的关系很多新手分不清其实load还包含D状态的进程不可中断睡眠比如正在等待磁盘IO的进程。所以有时候CPU很空闲load也会很高原因可能是磁盘IO卡住了。京东的机器上跑着大量的MySQL、Redis、消息队列磁盘IO问题非常常见。文件描述符、内存分配、swap、软中断这些也都是高频考点。2019年试卷里有一道题问“ulimit -n 调大了为什么还是报 too many open files”其实是考进程级限制和系统级限制的区别。这个坑我在实际运维中也踩过只改了用户级limit没改systemd服务里的LimitNOFILE服务重启后照样报错。笔试题看起来是在考命令实际上是在考你有没有真正解决过线上问题。操作系统的调优题里写几个关键参数会加分比如net.ipv4.ip_local_port_range、vm.swappiness、net.core.somaxconn。但更重要的是要说明你为什么调这个参数它解决什么问题。一个合格的运维开发不是把网上抄来的优化清单粘上去而是能解释参数背后的机制。2.3 Shell/Python脚本编程实战编程题是运维开发笔试和普通运维笔试最大的区别。京东的试卷里编程题一般会给你一个日志文件或者一个进程状态让你写脚本去处理。比如统计Nginx日志里访问量Top 10的IP、找出每个接口的平均响应时间、写一个进程守护脚本。很多考运维开发的人栽在这些题上不是因为不会写而是因为写得“太脆”。什么叫太脆就是只考虑了正常情况没考虑异常。比如写一个进程监控脚本常见写法是ps -ef | grep nginx | grep -v grep但这里有个经典坑如果grep进程本身也被匹配进去怎么办更稳的做法是使用pgrep -f nginx或者在grep时用[ n]ginx这种技巧。笔试考的不只是语法更是经验。Python如果考到一般会要求你用os、subprocess、re这些模块做文本处理或系统调用。有一道题是“读取一个文件解析每行把年龄大于30的记录输出到另一个文件”这道题看起来简单但实际上考察了文件读写时的编码问题、异常处理、资源释放。如果你用with open()写又加了try except再考虑了文件不存在的情况基本就是满分答案。脚本编程这块给一个实用建议平时多用shellcheck检查脚本多写单元测试覆盖异常路径。笔试现场虽然不能用这些工具但养成了习惯写出来的代码自然会覆盖更多边界情况。3. 中间件、数据库与云计算运维开发离不开的“底盘”3.1 数据库索引、锁与高可用京东的试卷里数据库相关的题几乎和网络题一样多。这和京东的业务强相关电商系统最核心的就是订单、库存、商品、用户这些数据MySQL作为主力存储Redis作为缓存再加上分库分表和消息队列构成了一个庞大的数据链路。数据库高频考点第一类是索引。为什么MySQL用B树而不用哈希索引或者二叉树B树为什么把数据都放在叶子节点最左前缀原则是什么这类题其实是在考你有没有理解索引的本质——减少磁盘IO。我建议备考时画一画B树的结构搞清楚聚簇索引和非聚簇索引的区别这个理解了很多题都能答对。第二类是锁和事务。MVCC机制、当前读和快照读、间隙锁、死锁排查。有一道真题是“两个事务同时更新同一条记录如何避免死锁”最好的答案是“保证多个事务按相同的顺序获取锁”。这道题看起来很简单但很多人会答成“加分布式锁”虽然也不能说错但没答到MySQL本身的层面说明对底层机制不够熟悉。第三类是高可用和分库分表。主从复制的原理是什么半同步复制和异步复制的区别binlog和relay log的作用MySQL的高可用方案有哪些。在京东这种体量下单库根本扛不住一定会拆那么分片键怎么选、扩容怎么做、跨分片查询怎么解决都是很有区分度的题。哪怕笔试不直接考这个思路在综合设计题里也会用到。3.2 消息队列与缓存中间件这块最常考的是Redis和Kafka。Redis几乎是必考的因为它太适合电商场景了。商品详情页缓存、用户Session、秒杀库存预扣全都离不开Redis。试卷里会考Redis的数据结构、持久化机制RDB和AOF、过期策略、主从哨兵和集群模式。我遇到的一道题是“在秒杀场景下如何用Redis避免超卖”这道题问得很有水平答案是使用Lua脚本保证扣减库存的原子性而不是先查再扣。这种题目就是典型的“原理业务场景”结合靠死记硬背肯定答不好。缓存穿透、缓存击穿、缓存雪崩这三个概念也是高频考点而且容易被混为一谈。穿透是查一个不存在的key解决方案是布隆过滤器或者缓存空对象击穿是某个热点key在过期瞬间被大量请求打到DB解决方案是互斥锁或者逻辑过期雪崩是大批key同时失效解决方案是过期时间加随机值、多级缓存。2019年试卷里有一道多选题就是给你三个场景让你选哪个是击穿哪个是穿透如果没实际处理过很容易选错。Kafka在2019年的考察频率也很高。京东的日志收集、订单异步处理、消息削峰很多都依赖Kafka。常考的点包括分区和副本机制、消费组和offset管理、消息丢失怎么处理、消息重复怎么处理。尤其是“如何保证消息不重复消费”这个问题最好用“接口幂等性”来回答比如在数据库里加唯一约束、用Redis记录消费ID。3.3 容器技术、K8s与DevOps/CI-CD2019年是容器技术从野蛮生长走向标准化的过渡期。京东自己的容器化平台做得很早所以试卷里出现Docker和Kubernetes的题目并不意外。Docker常见的考点是镜像和容器的区别、Dockerfile的优化、docker network模式、资源限制。Kubernetes的考点会更偏概念和架构比如Pod和Deployment的关系、Service如何做负载均衡、ConfigMap和Secret的区别、探针的作用。有一道填空题问“Kubernetes中滚动更新默认最大不可用数是多少”这个如果没实际操作过很容易忽略。我在这里想提醒一下别觉得这些是加分项就不重点看运维开发将来做的事情有一大半是在容器平台上做应用编排和自动化发布笔试考这些其实是在筛“对主流技术有感知”的候选人。CI/CD和DevOps理念的考察则更偏向简答。比如“请描述你们项目中从代码提交到上线部署的完整流程”“如何设计一套自动化发布方案保证发布过程中服务不中断”。这类题目考的其实是你对“稳定大于一切”的理解。发布过程要有灰度、有回滚、有监控每一步都要考虑失败场景。如果只是答“提交代码后Jenkins自动构建部署到服务器”这个答案太初级了拿不到高分。我记得当时有一道设计题“现有10台后端服务器每次发布需要停机5分钟请提出改进方案。”正常思路是滚动发布一次发布一台前一台健康检查通过再发布下一台。这个方案能拿到基础分。但如果能补上前置的自动化测试、发布后的指标对比、异常时自动回滚就会明显超出预期。这类题其实没有什么标准答案考察的是你平时在项目里有没有真正的工程化意识。4. 真题复盘几个印象深刻的题目与解题思路4.1 网络题为什么TCP的TIME_WAIT需要等待2MSL这道题考得比较深入很多人只知道需要等但说不清原因。2MSL是Maximum Segment Lifetime的两倍也就是一个报文段在网络中存活的最长时间乘以2。等待2MSL的原因有两个一是为了保证最后一次ACK能够到达对端如果ACK丢失对端会重发FIN本端需要能再次响应二是为了让本连接内的所有旧报文从网络中消失避免干扰后续使用相同四元组的新连接。这道题的高分答法不能只停留在原理还要结合业务来讲。我当时就补充了一句在高并发短连接场景下如果服务器主动关闭连接会积累大量TIME_WAIT状态的连接占用fd和端口资源。优化方向包括缩短MSL的内核参数、复用TIME_WAIT连接、服务端尽量不做主动关闭方、或者应用层改成长连接。这样回答既是给笔试加分也直接说明你处理过线上问题。4.2 脚本题监控Nginx进程数并发送告警这道编程题我印象很深因为从题干来看很简单但它是个“陷阱题”。题目要求每分钟检查一次Nginx进程数如果小于3个就告警。初级写法是#!/bin/bash count$(pgrep -f nginx | wc -l) if [ $count -lt 3 ]; then echo nginx process count is $count | mail -s Nginx Down adminexample.com fi这个代码看起来是对的但至少有三个问题。第一pgrep -f nginx会匹配到运行这行命令的进程自身吗在某些环境里会需要做排除。第二告警脚本本身可能没有运行环境变量直接执行crond里配置的命令可能因为PATH问题失败。第三没有做“防抖”如果Nginx真挂了每分钟发一封邮件半夜能把人炸醒正确的做法是连续N次检测失败才告警或者告警后进入冷却时间。我当时的改进版思路是使用pgrep -x nginx精确匹配进程名、加入去重、加入锁定文件防止脚本重复执行、告警之后等待人工确认或者自动拉起一次。这道题的关键不是你会写if而是你写的脚本能不能上线跑一个月不出问题。面试官想要的“运维开发”不是会写代码是会写健壮的代码。4.3 数据库题一条慢SQL的优化过程试卷里有道题会给你一段慢查询日志让你分析原因并提出优化方案。典型的写法是先用EXPLAIN查看执行计划重点看type、key、rows三个字段。如果type是ALL说明全表扫描了大概率是没走索引如果key为NULL说明索引没生效可能是隐式类型转换或者like语句以%开头或者不满足最左前缀原则。我记得真题里有一条类似“SELECT * FROM orders WHERE user_id 123 AND status 1 ORDER BY create_time DESC LIMIT 10”的查询。优化路径是(user_id, status)建联合索引然后进一步考虑把create_time加进去变成(user_id, status, create_time)这样在排序时可以直接利用索引顺序避免filesort。当然优化SQL不能只看单条语句还要考虑对整个系统的影响。如果你在笔试卷上能写出“先用慢查询日志定位Top SQL再看执行计划然后评估数据量和访问模式最后决定是加索引还是改写SQL还是做分库分表”这个思路就非常完整了。它体现了你具备从全局定位问题的能力而不仅仅是一个会写SQL的人。4.4 综合设计题高并发场景下的服务降级与流控方案综合设计题往往会给你一个前后缀很长的业务背景但核心问题就是“如何保证系统在流量超过预期时不被击垮”。这正好是运维开发的核心战场京东的大促场景早已把这类问题推到了极致。我在试卷上写的思路分三层。第一层是流量入口层用Nginx和网关做限流比如Nginx的limit_req模块或者基于Redis做分布式限流。第二层是应用层开启熔断降级比如依赖的接口超时则快速返回兜底数据而不是让线程池等死。第三层是数据层优先保护核心数据比如把非核心业务的读请求切换到从库或者直接关掉非核心功能。这个答案其实不难想但大多数人会忽略一个点降级方案一定要有“自动恢复”机制。线上压测恢复后你得把流量逐步放回去而不是所有服务一瞬间全量恢复否则又会被打垮一次。这个细节是我在参与某次大促压测演练时总结出来的笔试写上去之后面试官还专门问了我“你怎么判断恢复时机”这其实比设计方案本身更能体现经验。5. 踩过的坑与备考建议从笔试到offer5.1 时间分配与做题顺序我前面已经提过我因为死磕选择填空导致设计题没写完这里再往细了说。整套试卷的难度不是均匀分布的前面的选择题里经常藏着一些“看起来眼熟但选项全是陷阱”的题Nginx负载均衡算法、K8s资源对象的名称、MySQL隔离级别的默认值这些细节题很容易让人纠结。除非一眼能确定答案超过一分钟的题建议先蒙一个并标记出来等后面做完再回头检查。合理的做题顺序是先快速浏览一遍全部题目优先做简答题和设计题因为这些题主观性强写了就能拿分再做编程题编程题一般逻辑不复杂但有时间要求可以先列伪代码框架再完善最后做选择填空这时候如果时间不够蒙完所有题还能保有较高概率的运气分。我一直觉得笔试不只是考知识量还是考时间管理。拿满能拿的分比拿满分重要得多。5.2 简历里没提到的项目会被追问京东运维开发的笔试有一个特点越往后的题目越像“面试题”它不只是看你会不会还在试探你简历上写过的项目是真是假。比如你写了“熟悉MySQL主从复制”综合设计题里大概率会出现一个关于主从延迟的问题。所以备考时不是光看考点清单还要把你简历上的每一条技能点都提前准备一个“深入追问预案”。举个例子如果你写了“熟悉Redis”至少要把Redis的线程模型、持久化策略、主从同步过程、内存淘汰机制这几个方面都研究一遍。即使笔试没考面试也会问。我当时在简历上写“熟悉Docker”结果笔试里考了“镜像层的缓存原理”因为我正好做过镜像构建优化所以答得比较顺利。反而是一次面试问我简历里的监控系统项目怎么实现告警去重的我支支吾吾了半天。这个项目是临时拼的没沉淀好根本经不起追问。我的建议是备考前拿出一张纸把简历上的每个关键词都列出来再给每个关键词写三到五个能展开讲的细节。这样笔试面试都会很稳。5.3 运维开发的成长方向从“脚本小子”到“平台化思维”复盘完这份试卷还有一个更大的收获我清楚了运维开发这个岗位的成长路线。刚入行的时候很多人是从写脚本开始的每天就是“写脚本、看监控、点发布”。但这套笔试给我最大的感触是京东要的运维开发不是只会这些的“脚本小子”而是能构建平台的人。试卷里出现的大量关于自动化、容器化、全链路监控、容量规划的内容都是在提醒你运维的终局是“让系统自己管理自己”。所以备考期间除了刷题也很值得去了解一下行业内公认的优秀实践。比如了解混沌工程里“故障注入”的玩法理解SRE方法论里的SLO和错误预算研究告警平台怎么压缩和收敛事件。这不仅能帮你应付综合设计题还会影响你未来两年到三年的职业方向选择。我记得自己做这份试卷的时候对“设计一套全链路监控系统”这个题完全没有头绪只会想到“对每个服务器装一个AgentCPU高了就告警”。后来看了很多资料才明白全链路监控的核心不仅是指标采集还包括日志聚合、链路追踪、异常检测、根因定位最后要形成一个闭环。想通这一点很多题目就变得清晰了。写在最后的一点个人体会整个备考过程中我最大的感受是运维开发这个岗位的笔试与其说是在考知识不如说是在考“你平常是怎么干活的”。你排查过多少次线上故障写过的脚本有没有考虑异常有没有真正思考过系统为什么这么设计都会从字里行间透出来。我后来再去回想那套京东2019春招运维开发类试卷发现里面没有任何一道题是离谱的超纲题所有考点都指向运维开发日常工作中的真实场景。如果你的知识体系是零散的我建议你换一种方式学习以一个完整的业务系统为对象从用户请求入口开始把Nginx、DNS、CDN、网关、服务、缓存、数据库、消息队列、日志、监控、发布流程全部串起来然后针对每个环节问自己“如果挂了怎么办、怎么自动化”。最后再分享一个小技巧平时排查完一个问题不要只在群里说一句“搞定了”而是把排查过程写成文档把每个命令和结论记录下来时间久了你会发现自己对很多问题的理解从“会操作”升级成了“懂原理”。笔试里那些让你“看起来像老手”的细节大多都来自这些积累。这套方法比我见过的任何刷题攻略都更管用。