企业官网建设流程全解析

“运维开发”这个词，放在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-CD

2019年是容器技术从野蛮生长走向标准化的过渡期。京东自己的容器化平台做得很早，所以试卷里出现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" admin@example.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. 踩过的坑与备考建议：从笔试到offer

5.1 时间分配与做题顺序

我前面已经提过，我因为死磕选择填空导致设计题没写完，这里再往细了说。整套试卷的难度不是均匀分布的，前面的选择题里经常藏着一些“看起来眼熟，但选项全是陷阱”的题，Nginx负载均衡算法、K8s资源对象的名称、MySQL隔离级别的默认值，这些细节题很容易让人纠结。除非一眼能确定答案，超过一分钟的题建议先蒙一个并标记出来，等后面做完再回头检查。

合理的做题顺序是：先快速浏览一遍全部题目，优先做简答题和设计题，因为这些题主观性强，写了就能拿分；再做编程题，编程题一般逻辑不复杂，但有时间要求，可以先列伪代码框架再完善；最后做选择填空，这时候如果时间不够，蒙完所有题还能保有较高概率的运气分。我一直觉得，笔试不只是考知识量，还是考时间管理。拿满能拿的分，比拿满分重要得多。

5.2 简历里没提到的项目会被追问

京东运维开发的笔试有一个特点：越往后的题目越像“面试题”，它不只是看你会不会，还在试探你简历上写过的项目是真是假。比如你写了“熟悉MySQL主从复制”，综合设计题里大概率会出现一个关于主从延迟的问题。所以备考时不是光看考点清单，还要把你简历上的每一条技能点都提前准备一个“深入追问预案”。

举个例子，如果你写了“熟悉Redis”，至少要把Redis的线程模型、持久化策略、主从同步过程、内存淘汰机制这几个方面都研究一遍。即使笔试没考，面试也会问。我当时在简历上写“熟悉Docker”，结果笔试里考了“镜像层的缓存原理”，因为我正好做过镜像构建优化，所以答得比较顺利。反而是一次面试，问我简历里的监控系统项目怎么实现告警去重的，我支支吾吾了半天。这个项目是临时拼的没沉淀好，根本经不起追问。

我的建议是，备考前拿出一张纸，把简历上的每个关键词都列出来，再给每个关键词写三到五个能展开讲的细节。这样笔试面试都会很稳。

5.3 运维开发的成长方向：从“脚本小子”到“平台化思维”

复盘完这份试卷，还有一个更大的收获：我清楚了运维开发这个岗位的成长路线。

刚入行的时候，很多人是从写脚本开始的，每天就是“写脚本、看监控、点发布”。但这套笔试给我最大的感触是，京东要的运维开发不是只会这些的“脚本小子”，而是能构建平台的人。试卷里出现的大量关于自动化、容器化、全链路监控、容量规划的内容，都是在提醒你：运维的终局是“让系统自己管理自己”。

所以备考期间，除了刷题，也很值得去了解一下行业内公认的优秀实践。比如了解混沌工程里“故障注入”的玩法，理解SRE方法论里的SLO和错误预算，研究告警平台怎么压缩和收敛事件。这不仅能帮你应付综合设计题，还会影响你未来两年到三年的职业方向选择。

我记得自己做这份试卷的时候，对“设计一套全链路监控系统”这个题完全没有头绪，只会想到“对每个服务器装一个Agent，CPU高了就告警”。后来看了很多资料才明白，全链路监控的核心不仅是指标采集，还包括日志聚合、链路追踪、异常检测、根因定位，最后要形成一个闭环。想通这一点，很多题目就变得清晰了。

写在最后的一点个人体会

整个备考过程中我最大的感受是，运维开发这个岗位的笔试，与其说是在考知识，不如说是在考“你平常是怎么干活的”。你排查过多少次线上故障，写过的脚本有没有考虑异常，有没有真正思考过系统为什么这么设计，都会从字里行间透出来。

我后来再去回想那套京东2019春招运维开发类试卷，发现里面没有任何一道题是离谱的超纲题，所有考点都指向运维开发日常工作中的真实场景。如果你的知识体系是零散的，我建议你换一种方式学习：以一个完整的业务系统为对象，从用户请求入口开始，把Nginx、DNS、CDN、网关、服务、缓存、数据库、消息队列、日志、监控、发布流程全部串起来，然后针对每个环节问自己“如果挂了怎么办、怎么自动化”。

最后再分享一个小技巧：平时排查完一个问题，不要只在群里说一句“搞定了”，而是把排查过程写成文档，把每个命令和结论记录下来，时间久了你会发现自己对很多问题的理解从“会操作”升级成了“懂原理”。笔试里那些让你“看起来像老手”的细节，大多都来自这些积累。这套方法，比我见过的任何刷题攻略都更管用。