京东运维开发笔试复盘：考点拆解与高效备考路径

先说个结论这份“京东2019春招运维开发类试卷”虽然已经是好几年前的东西但它的考点设计放在今天看依然能打。我见过不少准备运维开发岗的同学一边刷LeetCode一边背面经结果拿到这类偏工程、偏全局的试卷时反而不知道怎么下笔。原因很简单——运维开发考的不是单一知识点而是你在“系统出问题时能不能快速定位”、“在业务扩张时能不能提前做出容量判断”、“在重复劳动面前能不能用代码把它干掉”这三件事上的综合能力。这篇文章我会把试卷背后的能力模型拆开结合当时京东运维开发岗位的典型考点逐条讲清楚每类题目在考什么、为什么这样考、以及如果你现在要准备类似岗位应该按什么路径去复习。文中涉及的题目方向是我根据历届运维开发笔试的常见范围、结合岗位JD和实际工作内容整理出来的还原版不是原卷逐字复刻但每类题的出题逻辑和踩分点具备很强的参考价值。1. 先看清这张试卷在考什么运维开发岗位的能力模型1.1 从岗位JD反推考察逻辑京东的运维开发岗在2019年春招时挂出来的JD里通常会有这么几条负责自动化运维平台的建设、参与监控系统和故障排查体系的优化、负责业务系统的部署和变更、推动运维流程的标准化。这些描述拆开看对应到试卷上就是四个命题方向操作系统底层功底、网络与故障排查、数据库与中间件原理、脚本和平台开发能力。更重要的是“开发”两个字。传统运维笔试如果只考命令、考参数那是网工和系统工程师的路子运维开发岗位会把代码能力、接口设计能力、流程抽象能力也塞进试卷。所以你会看到试卷里既有“排查CPU飙升”这种实战题也有“用Python写一个日志采集脚本”这种开发题还有“设计一套监控系统”这种架构题。三者比例大约在4:3:3具体数字不同批次会有浮动但底层逻辑是一致的——既要求你懂底层原理又要求你有工程化交付能力。1.2 能力分层广度、深度、工程化我在带团队面试时习惯把候选人的能力分三层看。第一层是广度就是操作系统、网络、数据库、缓存、消息队列这些基础组件你都知道遇到问题能说出“可能跟什么有关”。这一层是及格线试卷前面的选择题和判断题基本在这一层筛人。第二层是深度就是某个方向上你能讲清楚原理。比如问“DNS解析超时怎么排查”浅的回答是“用dig看”深一点要能说出“先看本地缓存、再看上游递归、再看权威服务器响应、最后看TCP连接状态”这样一条完整链路并且能解释每个环节可能出现的超时类型。试卷里的场景题、故障题考的就是这个深度。第三层是工程化就是你能不能把重复的工作变成工具能不能把一次性的排查沉淀成平台能力。这是运维开发和传统运维最本质的区别也是试卷压轴设计题的主战场。1.3 为什么这样设计业务场景倒逼岗位能力京东的运维场景有几个特点大促流量峰值明显、系统规模大、调用链路长、变更频繁。这决定了运维开发工程师不能只会修服务器他必须能在高峰来临前做好容量评估在故障发生时从全链路视角判断瓶颈在平时用自动化工具把人从重复操作里解放出来。所以试卷不考偏题怪题题目几乎都能在真实的京东运维场景里找到对应。比如考“单台服务器QPS上不去”对应的就是大促前扩容时的真实困境考“写脚本批量处理日志”对应的就是每天几千台服务器日志采集的需求考“监控系统设计”对应的就是京东内部那套庞大监控体系的缩影。想明白这一点答题时就不会只去背答案而会主动往“生产环境遇到这种情况怎么处理”的方向靠这恰恰是出题人最想看到的。2. 考点拆解五大常考模块与典型题型复盘2.1 Linux与系统原理——看似送分实则筛人Linux基础在运维类试卷里永远是大头但这部分恰恰是很多科班出身的同学翻车的地方。因为学校课程讲Linux通常停留在命令层面而笔试考的是“命令背后的内核行为”。举几个高频考点进程状态。不只要知道R/S/D/Z/T这几个字母还要知道D状态不可中断睡眠通常意味着进程在等IO如果大量进程处于D状态大概率是存储链路出了问题Z状态是僵尸进程父进程没来得及回收连续出现大量僵尸说明父进程可能卡住了。文件描述符和句柄泄露。有一道很经典的题服务器运行一段时间后报“Too many open files”怎么排查。答案不是直接把ulimit调大就完了而是要先看是哪个进程、哪类文件耗尽了fd用lsof或/proc/PID/fd去定位再看是不是代码里没关连接。负载与CPU、IO的关系。考察点是uptime里的load average高不代表CPU忙可能是D状态进程堆积也可能是CPU等待IO。这种题当时正确率很低因为大多数人只会用top看一眼就下结论。内存管理。Free命令里的buffer和cache区别、swap的换入换出对性能的影响也是选择题常客。复习建议不要死记命令参数每个命令的man手册挑核心部分看一遍然后去一台测试机上模拟故障。比如用dd制造IO压力观察D状态进程和load变化再用iostat、pidstat去定位。亲手走一遍比背十个命令好用得多。2.2 网络基础与排障思维——七层模型不只是背出来网络题在试卷里的占比不低但不会直接让你默写七层模型。它通常是给一个现象让你沿着协议栈一层层排查。常见题型有两类一类是“访问某个域名超时如何排查”。标准思路是先用dig或nslookup确认解析是否正常再ping目标IP确认链路通不通然后telnet或nc测试目标端口是否可达再检查本机防火墙和安全组最后用curl -v看具体卡在哪个环节。这套流程考察的就是分层排查思维每一步都有明确目的。另一类是TCP相关比如“TIME_WAIT过多怎么处理”。正确答案不只是改net.ipv4.tcp_tw_reuse还要说清楚为什么会出现大量TIME_WAIT、哪些场景下可以安全开启复用、开启后有什么代价。如果直接回答“把这个参数改成1”说明你只背了答案没理解机制。还有个容易忽略的点是HTTP层。运维开发岗位会接触大量接口和平台开发HTTP状态码的含义、常见请求头的作用、GET和POST的区别、Restful接口设计规范都在考察范围内。甚至有一年考过“304 Not Modified”的缓存机制这个题目看似简单但能完整讲清楚协商缓存流程的人并不多。2.3 数据库与缓存原理——从“会写SQL”到“懂原理”数据库在运维开发试卷里也是一个重头但考的不是写复杂SQL而是原理和问题排查。必考知识点包括索引的底层结构。B树为什么适合做索引、聚簇索引和非聚簇索引的区别、最左前缀原则是怎么回事。这个考点几乎是必出建议结合InnoDB的实际存储结构去理解。慢查询排查。如何开启慢查询日志、如何用EXPLAIN分析执行计划、重点看哪些字段type、key、rows、Extra。当时有一道题给了一段慢SQL让分析索引是否生效很多人栽在没看type字段看到用了索引就以为优化完成了。事务隔离级别。四种隔离级别分别解决什么问题、MySQL默认是哪个Repeatable Read、MVCC机制大概怎么回事。这个考点考察的是并发场景下的数据一致性理解。主从复制原理。binlog格式、复制延迟的可能原因、半同步复制和应用层补偿的区别。Redis也是常客。缓存穿透、缓存击穿、缓存雪崩这三兄弟是必考但不要只背定义。试卷通常会出具体场景某个热点key突然过期大量请求打到数据库怎么办。回答时要给出多层方案比如热点数据永不过期加逻辑过期、互斥锁重建缓存、布隆过滤器拦截不存在的数据并且要能比较每种方案的优缺点。2.4 脚本与编程能力——Python/Shell落地能力这一部分是把“运维”和“开发”连起来的关键。试卷里通常会出1到2道编程题考察的不只是语法而是用代码解决运维问题的能力。Shell方面高频题型有写脚本统计Nginx日志里访问量TOP10的IP写脚本监控某进程是否存在不存在则拉起写脚本批量修改多台服务器的配置文件。这些题考察的是文本处理、循环、条件判断、计划任务等基本功。需要注意的坑是变量引用、空格处理、以及set -e这类健壮性设置很多人在本地跑没问题但没考虑脚本在生产环境的异常情况导致失分。Python方面通常会出现用psutil或subprocess采集系统信息写一个简单的HTTP接口处理一个日志文件提取指定字段并做聚合统计。写这类题目时除了功能正确阅卷人还看代码风格——有没有用函数封装、异常处理是否完整、有没有硬编码路径。如果你能主动用上argparse做参数解析、用logging替代print会明显加分。一个容易被忽略的点题目如果没限定语言尽量选你最有把握的那个。运维开发岗位Python用得最广其次GoShell作为辅助。不要在考场上临时尝试不熟练的语法代码题能跑通是第一位的。2.5 容器、虚拟化与持续交付——19年前后开始加重的方向2019年正好是容器技术在国内大厂大规模落地的阶段京东的运维体系那时候已经大量使用Docker和Kubernetes所以试卷里容器相关的考点已经在明显增加。常见考点Docker镜像和容器的区别、镜像分层原理、CMD和ENTRYPOINT的区别。容器网络模式特别是bridge和host模式的使用场景。数据卷和容器持久化的方式。Kubernetes的基础概念比如Pod和Deployment的关系、Service如何做负载均衡、探针的作用。这一部分对没接触过容器的同学是难点但对已经有容器使用经验的人来说几乎是送分题。如果你现在才开始准备运维开发岗位容器部分已经不是加分项而是必选项建议至少要在自己电脑上用minikube或k3s搭一套实验环境把Pod、Service、Deployment、Ingress都手动部署一遍。持续交付方面笔试可能涉及发布系统的核心流程构建、打包、部署、验证、回滚、蓝绿发布和灰度发布的区别、CI/CD工具链的基本概念。这些内容在2019年还属于“了解即可”放到现在已经是运维开发的日常基本功了。3. 经典题型还原与解题思路从故障题到设计题3.1 线上故障排查题CPU飙升、内存溢出、连接超时故障排查题是整张试卷里最考验综合能力的部分通常给一段场景描述让候选人写出排查思路。这类题没有标准答案但有条理的回答和零散的回答得分差距会非常大。以“线上服务器CPU使用率持续100%如何排查”为例我建议按下面的顺序作答先用top找到CPU占用率最高的进程PID。用top -Hp PID找到该进程内耗CPU最高的线程TID。把TID转换成十六进制printf %x\n TID。用jstack PID | grep -A 20 nid0x十六进制Java场景或pstack查看线程堆栈定位到具体代码行。如果是GC导致用jstat -gcutil确认GC频率和耗时配合堆 dump 分析对象占用。这个流程每一步都有明确目的而且顺序不能乱。很多人的回答停留在第1步说“用top看哪个进程高”然后就没有然后了。但阅卷人想看到的是你能一路追到代码级别因为这才具备真正解决线上问题的能力。内存溢出类题目思路类似先jstat或heap查看堆内存使用判断是堆内不足还是直接内存溢出再通过jmap导出堆快照用MAT或JProfiler分析大对象和引用链。如果不是Java应用则用gdb或perf去分析对试卷而言提到“结合dump文件做进一步分析”就能拿到大部分分数。连接超时类题目在电商场景特别常见。考察方向包括确认超时发生在哪个环节客户端还是服务端、服务端端口是否处于LISTEN状态、连接数是否达到上限、后端应用线程池是否耗尽、数据库连接池是否满、是否依赖了第三方慢接口。回答时需要体现“从客户端到服务端的全链路排查意识”。3.2 监控系统设计题指标先行、链路完整、降级兜底监控系统设计是运维开发岗位笔试题里的压轴级别。题目通常表述为“请设计一套针对某核心交易链路的监控系统”或“设计一套服务器基础监控方案”。这类题考察的是架构能力和对监控体系的理解。我的建议是不要上来就画架构图纸面上也很难画清楚先列监控的层次再讲每层的数据来源和告警策略。一个完整方案通常包含以下五层基础资源监控CPU、内存、磁盘、网络。数据通过Node Exporter或Agent采集关注的是Utilization使用率、Saturation饱和度、Errors错误量三类指标也就是Google SRE那套USE方法论。应用性能监控接口RT、QPS、错误率。需要埋点通常用Java Agent或字节码注入技术。重点在于按接口维度、实例维度、机房维度做聚合。依赖组件监控MySQL、Redis、MQ等中间件的状态。比如连接数、慢查询数、主从延迟、队列积压量。这些数据通常来自中间件自带的管理接口。业务监控订单量、支付成功率、购物车转化率等。这是最容易遗漏的一层但业务方最关心。运维开发如果只盯着技术指标不关注业务指标一上线就会被人问“这个故障影响多少订单量”而答不上来。告警与通知包括告警规则配置阈值告警、同比告警、环比告警、告警分级P1-P4、通知渠道电话、短信、IM、告警聚合防止告警风暴和值班排班。回答这类题目时宁可把每个层次的埋点方式、数据采集频率、告警阈值都说清楚也不要只甩一个“用Prometheus Grafana”的框架。框架谁都会说但指标怎么定、告警怎么收敛才是考察的核心。3.3 容量评估计算题不会精确估算但要会量级推演容量评估是运维笔试里少数涉及计算的题型。常见问法假设单台服务器能支撑的QPS为X现峰值流量为Y需要多少台服务器这样一道题很多人只会拿Y除以X却忽视了高可用冗余、单机故障、扩容时间窗口等因素。一个完整的容量评估流程应该是确定性能基线的来源。单机QPS不是拍脑袋而是来自压测数据。如果没有压测数据至少要说明如何通过压测获得这个基线。计算峰值流量。以历史峰值的2倍到3倍作为目标容量电商大促通常会预留更多。加上高可用余量。如果要求N1故障转移至少多备一台如果有跨机房容灾需求容量要翻倍。考虑扩容时间。如果扩容需要小时级那么必须提前扩容如果是分钟级可以适当降低冗余。面试官期望看到的不是精确的数字而是你考虑问题的维度——你懂不懂用压测拿基线、懂不懂留冗余、懂不懂应对突刺流量。回答时把这些思路逻辑讲清楚哪怕数字算得保守一些分数依然很高。4. 实操准备路线从试卷反推可落地的复习方法4.1 底层必须补操作系统和网络不要靠背操作系统和网络这两块是运维开发的基础设施也是笔试里最容易拉开差距的板块。但很多人复习时有个误区拿着《深入理解计算机系统》和《TCP/IP详解》从头啃结果坚持不了两周就放弃。我建议换一种方式先做题再带着问题看书。准备周期以3到4周为宜第一周先刷2到3套往年的运维开发笔试真题不用在乎对错把不会的知识点全部标记出来你就得到了一个很明确的复习清单。然后再去对应章节看书比如发现进程状态老是搞混就去读进程管理那一章发现网络排障题不会答就重点看TCP三次握手、四次挥手和HTTP协议。这个逆向复习法的好处是你始终知道自己为什么在读这些内容而不是从头到尾机械地翻书。复习完一个知识点就在测试机上亲手造一次故障并排查一次比如用tc命令模拟网络延迟观察TCP重传和RTT变化这种实操记忆比看书牢固得多。4.2 脚本要写到能直接用的程度编程题是很多运维背景同学的短板但也是短期提升最快的地方。不要满足于“看懂别人的脚本”要每天写一到两个小工具写到可以直接交给别人使用的程度——有参数处理、有日志输出、有异常捕获、有返回值约定。一个很好的练习题目是“写一个日志归档脚本”对指定目录下的日志文件按日期归档压缩后移动到备份目录并清理30天前的文件。这题看起来简单但能覆盖os模块、glob匹配、压缩处理、日期计算、日志记录等多个知识点还能考察脚本的健壮性。我当时反复练习了多遍最后笔试里遇到类似题目很顺畅就写出来了。如果你是零基础建议先选Python作为主攻语言因为它的类库在运维场景里最全而且代码读起来接近自然语言。不要在复习阶段同时学Python和Go容易两个都学不精。等到笔试时如果要求写Go可以用Go但作为主力准备Python效率最高。4.3 设计题的回答框架指标先行、链路完整、降级兜底设计题是整张试卷里最能体现“高级感”的题目但也是很多人最头疼的。如果你平时只做单点运维没有从系统全局思考过问题确实会觉得无从下手。我总结了一个万能的回答框架适用于绝大部分监控、发布、容灾类设计题先列指标。任何系统设计题第一件事都是定义“我要观测或保障哪些指标”有了指标才有后续的数据采集和告警。再画链路。系统是怎么流转的从用户请求到后端存储每一层是什么组件组件之间怎么交互。链路画清楚了监控点、瓶颈点、故障点都会自然浮现。最后讲降级和兜底。出故障了怎么办有没有熔断、降级、限流、容错机制数据不一致怎么补偿这些兜底策略是设计方案里最容易加分的地方。以监控系统设计题为例指标层就是USE法加RED法链路层就是“客户端→接入层→应用层→数据层→存储层”兜底层就是“告警静默、告警聚合、值班升级、降级预案”。把这三个维度讲透不需要华丽的架构名词也能拿到高分。另外回答设计题时建议多问两句题干里没有明说的条件比如“系统的量级是什么样的”、“对可用性的要求是几个9”、“目前已有的基础设施是什么”。虽然笔试是书面作答但如果你能在开头写明“这里的核心假设是……”会显得思路清晰。4.4 模拟面试与错题复盘不要做完就扔很多人刷题有个毛病做完对完答案就觉得自己“会了”。但如果过一周再让你做同样的题还是会在同样的地方卡壳。真正的复盘不是看答案而是把每道错题按下面三个问题重做一遍正确答案的思路是什么和我当时想的差别在哪里这个知识点还能怎么变形出题如果我同学来考我我会怎么出这个知识点在真实生产环境里有没有对应场景如果有我遇到过吗我当时准备春招时用这个方式复盘了大概150道错题每道题都写了详细笔记包含题目还原、错误原因、正确思路、关联知识点、可能的变体五个部分。虽然费时间但效果立竿见影尤其是选择题里的细节坑经过一次深度复盘之后基本不会再错。如果条件允许找一位有运维背景的朋友做模拟面试效果会更好。笔试里很多知识点是相通的口述一遍能逼你把思路理清楚还能发现自己“以为自己知道、但一说不出来”的知识盲区。这不是浪费时间这是在省钱——面试官问的很多问题和笔试考察的底层能力一模一样。5. 真实场景中的常见问题与避坑经验5.1 笔试常见的失分点第一类是审题不清。题目问“最可能的原因是什么”你回答了完整排查步骤虽然内容没毛病但踩不中得分点。运维笔试题里大量选择题都有“最”“通常”“优先”这类限定词答题时一定要先确认题目问的是“是什么”还是“怎么做”不要答非所问。第二类是回答没有落地感。比如问“如何处理MySQL主从延迟”只回答“优化主从复制参数”这种话等于没答要具体到“把binlog改成ROW格式”“从库提升硬件配置”“把大事务拆分”“重要读请求走主库”这些可操作的动作。第三类是编程题只写核心逻辑不写输入输出和异常处理。阅卷人一眼就能看出来你写的代码能不能跑。就算时间紧张也要把函数定义写完整至少让调用关系是自洽的。顺手加个try/except和参数默认值会拉开很多差距。5.2 那些容易翻车的细节题这类细节题在运维笔试里非常容易成为“陷阱”。举几个例子crontab环境变量问题。cron执行时的PATH非常精简很多脚本在命令行能跑在cron里却报“command not found”。你如果能在脚本开头显式加载source /etc/profile或写全绝对路径就能避免这个坑。ss和netstat的差异。新版系统里netstat未必安装但ss更高效。很多人还在用netstat遇到最小化安装的机器就懵了。防火墙和安全组。在云环境下除了本机的iptables/firewalld还有云平台的安全组策略。排查端口不通时两层都要看。笔试题目如果偏向云环境提这一点会是加分项。curl -I和curl -X HEAD的区别。-I发的是HEAD请求但有些服务器不响应HEAD另外curl -I和-X HEAD行为也有细微差别在实际开发接口时这些细节会直接影响联调效率。归纳起来一句话笔试考的不只是知识点还有你在实操中积累的“呼吸感”。那些看起来不起眼的细节往往是区分有没有真实运维经验的重要标尺。5.3 给后来者的一些补充2020年代准备运维开发还要加什么虽然我们复盘的是2019年的试卷但如果你现在才准备运维开发岗还需要在这份试卷的基础上额外加几门课Kubernetes要学到能独立部署和排查的程度不再只是会概念。云原生相关比如Service Mesh、Serverless至少要理解它们解决的问题。IaC基础设施即代码工具Terraform、Ansible这类至少掌握一种。可观测性体系Metrics、Logging、Tracing三者的关系和落地方式已经是运维开发的标配技能。一门开发语言要达到能独立写小项目的水平。Java和Go在京东内部的运维平台里大量使用Python则在脚本和数据处理上依然不可替代建议至少一门主攻、一门辅助。说到底运维开发是一个“越老越值钱”的方向因为它的核心不是某个工具或某个框架而是你对整个技术栈的理解深度和故障时的判断力。试卷可以过时但在它背后沉淀出来的学习方法和问题拆解框架能让你受用很多年。最后还是那句老话运维开发不是靠背题能拿下的把每个知识点都放到真实场景里走一遍你会发现自己比想象中准备得更充分。