摩拜运维开发校招笔试复盘：从编程到场景设计全解析-平芜编程栈

2018年秋天我做过一份摩拜运维开发校招笔试卷的复盘笔记，当时身边不少朋友都在投这家公司的运维开发岗。摩拜的业务形态很有代表性，共享单车的智能锁每天产生海量上报数据，后台同时对实时性和稳定性要求极高，这种场景决定了它考察的运维开发工程师，绝对不是只会敲几个排查命令的人。你如果想投运维开发岗位，这份试卷的考察逻辑放到今天依然有参考价值——工具和平台可能变了，但企业对运维开发这个岗位的核心期待没怎么变过：能写代码的运维、懂系统的开发、能扛故障的人。

这篇文章我会把这份笔试卷的考察维度、典型题型、答题思路完整拆一遍，也会补上我自己在类似岗位笔试和实际工作中的经验。没有拿到原始卷子的朋友不用担心，我按题型和能力维度做了还原和归纳，你可以把它当成一份“运维开发校招笔试全景解析”来用。

1. 一份校招笔试背后，运维开发到底在考什么

1.1 从摩拜的业务痛点反推岗位画像

先想清楚一件事：摩拜为什么要单独招“运维开发工程师”，而不是传统的运维工程师？因为当业务规模大到一定量级，纯手工运维已经跑不动了。

摩拜这个体量，智能锁终端数量级在千万级，每个锁定期上报位置、电量、状态、开锁指令，后端要接入的并发连接数非常大。加上单车运营调度需要依赖实时数据分析，订单、车辆状态、用户行为都要落到大数据平台上。这种业务形态带来的直接技术挑战是：基础设施规模大、链路长、组件多，任何一个环节出问题都会影响用户体验。所以它需要的运维开发工程师，核心能力不是“会修机器”，而是用开发手段解决运维问题——写自动化脚本、做监控系统、搞故障自愈、优化大数据任务调度。

理解了这个岗位画像，再看笔试卷就清晰很多：它不考死记硬背的琐碎细节，而是考你能不能像一个“小规模基础设施负责人”一样思考问题。

1.2 笔试考察的四个能力维度

我把这份试卷里里外外梳理了一遍，核心考点集中在四个维度：

能力维度	考察内容	占比估算	考察目的
编程基础	Python/Go/Shell、算法与数据结构	30%左右	判断你能否写出可用的运维工具
系统与网络	Linux操作、进程、网络协议、故障排查	30%左右	判断你是否具备运维基本功
数据与中间件	MySQL、Redis、消息队列、大数据组件	25%左右	判断你是否能支撑复杂业务链路
场景设计	监控、告警、高并发、容量规划	15%左右	判断你是否有全局架构意识

这个分布很典型。运维开发不是纯粹的开发，也不是纯粹的运维，知识点覆盖面要广，但深度不需要达到“造轮子”级别。笔试的目的就是把那些只会背题库、没有真正碰过系统的人筛掉。

1.3 拿到试卷后的答题时间分配策略

我记得这套卷子的题量不算小，包括选择题、简答题、编程题和最后的场景设计题。很多同学挂在时间分配上：前面选择题纠结太久，后面编程题没时间写，或者场景题只写了两行字。

我的建议是：先花5分钟通读全卷，把题目分成“秒杀题”“思考题”“硬骨头”三类。选择题里那些概念类、命令类的秒杀题，读一遍就选，不犹豫；需要计算或推演的思考题，控制在每题5分钟左右；编程题和场景题是拿分大头，至少要留出40%的时间。运维开发岗的编程题通常不会太难，但不写代码一定没分，写了就有分。

2. 编程与算法题：不只写代码，更考工程思维

2.1 高频题型：从字符串处理到海量数据Top K

运维开发笔试里的编程题，跟纯后端开发岗的套路有明显区别。纯开发岗喜欢考二叉树、动态规划，运维开发岗更偏爱跟实际运维场景沾边的题型。

我归纳了几个高频方向：

日志解析类：给一段日志，提取特定字段，统计某个维度。比如统计某个接口的P99延迟、按IP聚合访问次数。这类题考正则、字符串处理、字典计数，本质上是写一个轻量级日志分析脚本。
文件处理类：大文件拆分、合并、去重，或者从几GB的文件里找出出现次数最多的Top N。这类题考哈希、外部排序、堆的思路。
系统状态模拟类：模拟一个监控指标的滑动窗口统计，或者实现一个简单的限流器。这类题考队列、计数器、时间窗口。
常用算法变体：LRU缓存、Top K、布隆过滤器这些跟“缓存设计”“海量判重”强相关的算法，出现频率很高。

值得注意的是，这些题并不需要你写出生产级代码，但需要你体现“工程思维”——考虑边界情况、考虑输入规模、考虑时间复杂度。比如海量日志去重，如果直接说用HashSet读入内存，明显没考虑内存上限；如果能答出“分文件Hash到不同桶，再逐桶处理”，分数会高很多。

2.2 用“摩拜场景”包装的算法题怎么破

我第一次看到这套卷子的时候印象很深，因为它有一道编程题被包装成了业务场景：骑行者上报的GPS坐标数据文件很大，需要按城市维度拆分成多个小文件，每个城市一个文件，文件内按时间排序。

这个题表面上是文件拆分和排序，实际上考了两个点：

第一，分区逻辑。你不能把几千万条GPS记录全部读进内存再分组，而是应该逐行读取，用一个Hash函数把城市ID映射到文件编号，直接写对应文件。这样内存占用是常量的，跟数据总量无关。

第二，排序策略。每个文件内部要按时间排序，如果数据分散在多个临时文件里，可以每读一个就写入对应文件的同时维护一个小顶堆，或者最后用外部排序合并。做题的时候不用真写外部排序，但至少要说清楚思路。

我后来在实际做日志清洗任务时发现，这个题的思路完全可以直接迁移。不同来源的日志按租户拆分、按时间归档，就是同一套逻辑。所以这道题表面考算法，实际是在考你对“海量数据落地”的基本理解。

2.3 编程题答题的易扣分点

很多同学编程题能写出核心逻辑，但最后分数不高，我总结几个常见的扣分点：

不处理空输入和边界值。比如日志文件为空、字段缺失、非法格式，直接按正常数据处理。面试官一眼就能看出你平时写脚本的严谨程度。
不考虑内存和性能。几GB的文件说读就读，完全没有流式处理的意识。运维天天跟大文件打交道，这种代码在线上是要出事故的。
代码没有注释和结构。笔试不需要写工程级的代码，但至少要能看出来你有函数拆分意识，不是一大坨for循环套到底。
只写核心逻辑不写输入输出。题目要求从标准输入读、结果输出到标准输出，你直接写个函数就算了，判题跑不通。

提示：运维开发的编程题，我不建议一上来就追求“最优解”，先把一个“能跑通、思路正确”的解法写出来，再提优化。很多题最优解要堆各种复杂数据结构，写错了反而一分没有。

3. Linux与网络：排查能力才是运维的底色

3.1 Linux考察高频点

Linux相关知识在这份卷子里占了相当大的比重，而且它考的不是那种“背了就能答”的题，而是带一点“场景感”。高频考点主要集中在以下几个方面。

进程与资源排查是重头戏。比如给你一台负载过高的机器，问你怎么排查是哪个进程引起的，怎么判断是CPU瓶颈、内存瓶颈还是IO瓶颈。这种题没有标准答案，但有条理的答题思路是：先top或htop看全局，再ps按CPU或内存排序定位进程，然后用strace看系统调用、用vmstat看上下文切换、用iostat看IO等待。能说出这么一条完整链路的人，基本可以确定他是真动过手的人。

文件系统与磁盘也常考。比如磁盘满了但df显示还有空间，这种情况通常是删除了仍被进程占用的文件，解决办法是lsof | grep deleted找到进程再重启或释放。还有inode耗尽的问题，df -i一看就能确认，通常是小文件太多，需要调整文件系统策略或者清理。

文本处理三兄弟——grep、awk、sed——几乎是必考内容。题目可能直接让你统计某个日志里出现次数最多的IP，或者把某个时间段的日志筛出来。这没什么捷径，平时多用自然就熟了。我个人的习惯是：处理结构化文本用awk，改文件内容用sed，快速过滤用grep。三个工具配合起来，能解决绝大多数日志分析需求。

另外有一类题我觉得特别能区分水平，就是系统启动排查。比如一台服务器突然重启后服务没起来，你按什么顺序排查？答案不只是“看日志”，而是一个完整的排查链：先systemctl status看服务状态和错误提示，再journalctl -u看服务日志，然后通过dmesg看内核日志有没有OOM或硬件问题，最后看配置文件和依赖服务是否正常。这个链路本身就体现了排查的系统性。

3.2 网络协议题

网络协议在运维开发笔试里主要考TCP/IP、HTTP和DNS这三块。

TCP部分，三次握手、四次挥手已经是老朋友了，但这份卷子喜欢换个姿势考。比如“大量TIME_WAIT连接怎么处理”，这其实是一个线上很常见的问题，跟短连接频繁建立有关。处理思路包括：开启tcp_tw_reuse、调整tcp_max_tw_buckets、改用长连接或连接池。这种题考得好不好，关键看有没有解释清楚每个参数的影响，而不只是背答案。

HTTP部分，状态码语义是必考的。我建议不只记常见状态码，还要会结合场景分析。比如503和502都表示服务有问题，但502是网关从上游收到了无效响应，503是服务暂时不可用，排查方向完全不同。302和301的区别，Keep-Alive的作用，Cookie和Session的关系，这些高频考点都值得梳理。

DNS部分，重点在“域名解析的完整过程”。从浏览器缓存、本地hosts、系统DNS缓存、本地DNS服务器、根服务器这一整条链路，很多人答不全。有一个变体题也值得注意：“一个域名突然解析到错误IP，可能是什么原因”，这个问题会在下面的排查链路专门讨论。

3.3 一个常见的“线上故障排查”笔试变体

这套卷子里有一道题我印象很深，题目大意是：一台服务器上某个Web服务突然响应很慢，CPU和内存看起来都不高，请列出排查思路。

第一次做这种题，可能会觉得CPU和内存都不高，那就不是机器资源问题。但实际线上业务里，这个现象背后可能有几种完全不同的原因：

磁盘IO出现瓶颈。CPU和内存不高，但磁盘读写已经打满，每秒钟的IO等待很高。用iostat一看就能发现，如果是这个原因，进程在等磁盘，CPU当然是空闲的。
网络带宽被打满。网卡流量已经到了上限，数据包在网络层排队，服务自然响应慢。用iftop或sar看网络流量。
应用自身出现死锁或线程阻塞。JVM或Python GIL之类的问题，进程看似活着但不干活。用jstack或者py-spy dump线程栈来看。
外部依赖变慢。服务在等待调用下游接口、数据库、缓存等外部系统，所以自身CPU和内存都闲。这种问题排查思路就不应该聚焦在本机，而要看调用链。

这种题考的是“不要只盯着表面指标看问题”。运维开发日常工作中大部分故障排查，本质都是从这个思路出发：先全局看，再层层缩小范围，最后定位根因。笔试能把这个思维过程写出来，比背一堆命令更有说服力。

4. 数据库、中间件与大数据组件：运维开发的硬通货

4.1 MySQL索引与事务

数据库几乎是必考项，摩拜这种体量的业务，后端一定离不开MySQL。笔试对MySQL的考察主要集中在索引和事务两块，这两块也是面试官检验候选人“有没有真正写过业务SQL”的试金石。

索引部分，最经典的题是“为什么MySQL使用B+树而不是哈希索引或二叉树”。答案的要点在于：B+树数据有序存储，支持范围查询，而且只有叶子节点存数据，每个节点能容纳更多索引项，树高度更低，减少了磁盘IO。哈希索引虽然等值查询快，但无法支持范围查询和排序。这个回答同时体现了数据结构和数据库磁盘存储的理解，基本能拿满。

事务部分，ACID四个特性要能解释清楚，尤其要能区分“隔离级别”和“锁”。比较常见的一个坑是：“可重复读是不是就不会幻读了？”MySQL默认隔离级别是可重复读，但标准的可重复读不能完全避免幻读，只是InnoDB通过间隙锁和MVCC实现了对幻读的近似消除，而不是理论上杜绝。能答到这个层面，说明对事务机制有深入理解。

慢SQL优化也是高频考点。我觉得答题思路可以固定成：先用EXPLAIN看执行计划，关注type、key、rows这些字段；然后看是否没走索引、是否隐式类型转换导致索引失效、是否在索引列上做了函数操作；最后再看是否能改写SQL或增加冗余字段。这个思路拿到任何SQL优化题都能应付，因为它是从根因出发的。

4.2 Redis的缓存一致性

运维开发笔试对Redis的考察，很少问“Redis有哪些数据结构”这种入门题，更多是问“缓存穿透、缓存击穿、缓存雪崩怎么解决”以及“缓存和数据库的一致性怎么保证”。这些题跟实际业务强相关，摩拜的订单、车辆状态查询场景肯定离不开缓存。

缓存穿透可以简单理解为“查询一个根本不存在的数据”。由于缓存没有数据，请求直接打到数据库，如果被恶意利用，数据库可能被打垮。常用的解决办法有：布隆过滤器挡住不存在的key，或者把空值也缓存起来。

缓存击穿指“某个热点key过期瞬间，大量请求同时打到数据库”。解决办法包括：互斥锁只允许一个请求去回源、热点数据不过期、或者用逻辑过期时间提前刷新缓存。

缓存雪崩指“大量key同时过期，导致数据库压力瞬间飙升”。解决办法是把过期时间加一个随机值，打散过期时间。这三个问题几乎是Redis缓存场景的必背组合，但答题时如果能结合摩拜这种“某地车辆位置缓存集体失效”的场景来描述，会更有说服力。

关于缓存一致性，我更倾向给一个工程上常用的答案：先更新数据库，再删除缓存，而不是先更新缓存。因为先更新缓存的话，一旦数据库更新失败，缓存里就是脏数据；而先更新数据库再删缓存，即使删失败，也有一个较短的过期时间兜底，最终会趋向一致。笔试里能讲清楚这个顺序的逻辑，比单纯记结论有价值得多。

4.3 Kafka、Hadoop这类组件题会怎么出

摩拜的业务场景决定了它一定重度依赖消息队列和大数据组件，所以笔试中出现Kafka、Hadoop相关题目并不意外。

Kafka的考点比较集中，我整理过一套高频清单：

Kafka的架构角色：Producer、Broker、Consumer、Consumer Group、Topic、Partition、Offset这些基本概念要烂熟于心。
Partition的作用：一个Topic分成多个Partition，消息在Partition内有序，Partition之间无序。所以要做到全局有序，只能设置成一个Partition，但会牺牲吞吐。
消费者组：同一条消息同一个消费者组只有一个消费者能消费，不同消费者组可以各自独立消费。
消息不丢失：生产者端要设置acks=all，消费者端要在处理完业务逻辑后再提交offset，broker端要设置副本数大于1并开启同步复制相关的配置。
消息重复消费：消费者在重启或异常情况下可能重复消费，业务侧要具备幂等性，这是运维开发在设计消费任务时必须考虑的点。

Hadoop相关的题，则不会太深，高频的是HDFS的基本架构、MapReduce的shuffle过程、以及YARN的资源调度概念。笔试里问到这些，往往不是想考底层细节，而是想确认你有没有大数据组件的使用经验，能不能在后续的离线任务开发、集群运维中快速上手。

我的建议是：对这种组件题，不用去背源码，但要能讲清楚“它解决什么问题、核心机制是什么、有没有踩过什么坑”。比如Kafka的“消费者组重平衡导致消费延迟”，HDFS的“小文件问题导致NameNode内存紧张”，这些谈起来比背定义有感染力得多。

5. Python与自动化脚本：把重复劳动交给程序

5.1 Python语言本身的考点

运维开发岗位最常用的语言，国内互联网公司基本就是Python和Go，摩拜那个时期Python脚本在运维侧使用尤其普遍。笔试对Python的考察，不追求特别偏门的语法，而是看重日常脚本开发中容易用到、也容易出错的知识点。

有一个必考方向是可变对象与不可变对象，以及它们作为函数默认参数时那些让人意外的表现。比如def func(lst=[])这种写法，默认列表会在多次调用之间共享，导致数据污染。这个知识点，写过一段时间Python的人基本都踩过，笔试考的就是你有没有形成肌肉记忆。

GIL（全局解释器锁）也是高频考点。需要理解的是：GIL使得同一进程内的多个Python线程无法真正并行执行CPU密集型任务，所以多线程适合IO密集场景，多进程适合CPU密集场景。这个理解直接影响到运维脚本的并发模型选择。我在写批量日志处理脚本时，就踩过“开了多个线程却发现CPU只有一个核占用满”的坑，换成multiprocessing之后速度提升明显。

装饰器、生成器、上下文管理器这三个特性，也是运维脚本中很常用的。装饰器可以用来给监控脚本统一加日志、超时控制；生成器可以处理超大日志文件而不占内存；上下文管理器可以安全地管理数据库连接和文件句柄。笔试如果让你手写一个简单的装饰器或者生成器，一定不要只写“能用”，要注意函数签名保留和异常处理。

另外，Python 2和Python 3的区别虽然现在讨论得少了，但那份卷子里出现过字符串编码相关的题目。print是语句还是函数、/和//的行为差异、range和xrange、字符串默认编码等，这些都是那个时代容易踩坑的点。现在写Python基本都用3，但编码问题——Unicode和UTF-8的转换——依然是运维脚本里经常出问题的地方，值得专门看一下。

5.2 监控与自动化脚本的场景题

运维开发笔试卷里往往有一两道“针对具体运维场景写脚本”的题，这类题说难不难，却最能反映实际工作能力。比如：

“写一个脚本，定期检查所有服务器的磁盘使用率，超过80%的发出告警。”

这个题看着简单，实际上可以拉开梯度。基础版的答案是：用df命令循环取磁盘使用率，超过阈值就打印告警。稍好一点的会用配置中心下发阈值，并且把告警信息统一接入已有告警平台。更好的答案会考虑并发执行——用线程池或异步IO同时检查所有机器，而不是串行逐台执行；还会考虑失败重试、结果去重、防止重复告警。

我个人的经验是：这种题就是要展示你的“运维工程能力”，而不只是“会写几句命令”。答题时如果能自然地加上日志、异常处理和幂等控制，会比其他候选人明显高一个段位。

另外一个常见的场景题是“写一个日志统计脚本”，比如统计Nginx访问日志中每个URL的PV和UV。这个题除了考察awk、sort、uniq这些命令的熟练度，也考察你对UV统计口径的理解——比如UV按IP去重还是按Cookie去重，不同的业务场景口径不一样。如果能答出“用字典维护ip->set映射，内存不够用就分批落盘”这类处理方案，分数会更高。

5.3 面试官从代码里嗅到的坏味道

笔试的编程题往往不会批改得太细，但阅卷人一眼就能从代码风格里看出一个人有没有工程素养。我罗列几个常见“坏味道”，自己写代码的时候可以对照检查：

所有代码写在全局作用域，没有函数封装。哪怕是几十行的脚本，也应该用main()包一层，配合ifname== 'main'入口。
异常处理过于笼统。直接except Exception: pass是最要不得的，不仅掩盖了错误，排查时还无从下手。正确的做法是捕获具体异常类型，并记录堆栈日志。
硬编码严重。机器列表、阈值、路径这些应该作为参数或配置传入，而不是写死在代码里。运维脚本一旦要频繁改代码，就失去了自动化的意义。
没有日志输出。脚本逻辑再多，如果执行过程中没有任何输出，跑挂了都不知道在哪一步挂的。至少要加一些关键节点的print或logging。
不考虑重复执行。运维脚本经常要定时任务触发，如果脚本没有幂等性，执行两次和一次结果不一样，会导致数据错乱。

提示：笔试时就算时间紧张，也至少要把程序入口、函数结构、关键异常处理写出来，这比多堆几行代码更讨喜。

6. 场景设计题：给摩拜写一套设备运维方案

6.1 一个经典场景题：千万级设备的心跳上报

场景设计题是整套卷子里最能拉开差距的部分，也是我认为最有意思的部分。它通常会给你一个摩拜真实的业务场景，让你从运维开发的角度设计方案。我挑一个典型题目来拆解：智能锁需要定期向服务器上报心跳，高峰期每秒有几十万次上报请求，请设计后端接入和存储方案。

这种题一出来，很多没接触过高并发的人第一反应是“用Kafka啊，异步削峰”。但这只是第一步，一个完整的设计方案应该包含链路设计、存储设计、监控设计、故障处理四个层面。

链路设计：接入层前面要加负载均衡，比如LVS或Nginx。接入层之后，上报数据不能直接写数据库，而是写入消息队列进行削峰填谷。Kafka可以承担这个角色，上游即使流量波动剧烈，消费者侧也能按自己的节奏处理。这个设计的关键是，让消息队列成为整个系统的缓冲池。

存储设计：心跳数据是典型的时序数据，价值随时间递减，所以没必要都放MySQL。冷热数据分离是常见的思路：最近几天的热数据放在Redis或时序数据库里用于实时查询，历史数据定期归档到Hadoop/Hive里用于分析和离线计算。这个设计既控制了成本，也保证了查询性能。

监控设计：方案里必须考虑“如果设备掉线了你怎么发现”。上报延迟、当日活跃设备数、各地区上报量异常降低，这些指标都要配置监控和告警。心跳丢失率达到某个阈值时，要能自动触发告警并创建工单。

故障处理：如果消息队列本身积压了，怎么告警、怎么扩容消费者、要不要设计降级方案，这些都应该在方案里提到。能把这个层面的思考写出来，说明你不是只会画架构图，而是真的考虑过线上运行的问题。

6.2 设计题的标准答题框架

我总结了一个场景设计题的答题框架，不只是针对这道题，其他类似的题目都能套用：

明确目标和约束：题目里的数据量、延迟要求、可用性要求是什么，先告诉面试官自己清楚了这几个指标。
给出整体架构图：用文字描述或用简单的框图画出来，从接入层到存储层到展示层，每一层负责什么要说清楚。
拆解各个模块：逐一说明每一层的技术选型和关键逻辑，选型时给出理由，比如“这里为什么用Kafka而不是RocketMQ”。
考虑数据流和一致性：数据从产生到落库的完整路径是什么，如果某一步失败会怎样，如何保证数据不丢。
监控、告警、容灾：方案上线后怎么知道它跑得好不好，出问题怎么恢复。

这个框架的价值在于，它让答题过程全程结构化，不会想到哪写到哪。面试官看到的是一套有条理的思考，而不是几个孤立的技术点。

6.3 从笔试延伸到二面的追问

场景设计题在笔试里写完后，往往会在二面中被追问。我遇到过的一些追问方向有：你这个方案能扛多少QPS？Kafka的消费者组扩容之后会不会产生消息乱序？如果把存储层换成数据库直写，在什么情况下你是可以接受的？这些追问都指向同一个目标：检验你到底理解了这个方案，还是只是背了架构。

比如消息顺序问题，如果业务要求同一辆车的上报消息按顺序处理，而Kafka的某个topic有多个分区，那你需要按车辆ID做key，保证同一辆车的数据进入同一个分区，才能在分区内有序。如果这个点没想过，被追问几句就容易露馅。

所以我建议在笔试写方案时，主动写出“这里通过车辆ID哈希取模来保证同一设备的数据落在同一分区”，这一个小小的细节，比通篇泛泛而谈的高可用架构有力得多。

7. 备考与复盘：给即将参加运维开发校招的人

7.1 运维开发校招备考资料清单

备考运维开发岗，资料不需要多，但需要成体系。我按优先级整理了一份清单，供参考：

Linux命令与系统管理：找一本系统性的Linux基础书过一遍，重点在进程、内存、磁盘、网络、文件系统五大块。练习时多用虚拟机或云服务器实际操作。
Python核心语法：重点掌握装饰器、生成器、异常处理、多线程多进程、常用标准库比如os、sys、subprocess、json、logging。不需要看那些高深的框架源码，但脚本要写得顺手。
数据库：MySQL索引、事务、SQL优化，Redis缓存问题，这两块是笔试大头。有余力可以再看看MongoDB或ES，但优先级不高。
中间件与大数据基础：Kafka、Hadoop、Spark的架构概念和使用场景，不需要深入源码，但要能讲清楚组件定位和数据流转。
网络基础：TCP/IP协议栈、HTTP协议、DNS解析流程、常见的网络排查命令。
面经与笔试原题：牛客网、掘金、知乎上有大量运维开发相关的面经，多刷多练，但要自己归纳成知识点，不能只背题。

7.2 备考时间安排

如果从投递到笔试还有两个月，我建议这样安排：第一个月以看书和系统练习为主，每天固定1到2小时动手敲命令、写脚本，而不是光看不练。第二个月进入模拟题阶段，按真实笔试的时间限制做套题，训练速度和取舍能力。

每周至少留半天时间做“故障排查练习”——自己搭一个环境制造问题，比如磁盘写满、进程假死、网络延迟，然后用排查思路一步步定位。這種练习对笔试和面试的帮助，远大于刷十套模拟题。

备考过程中不用过度追求新框架，Redis、Kafka、MySQL这些基础组件的原理，比Kubernetes、容器这些当时的新技术更值得花时间。工具会迭代，但不变的底层原理才是笔试真正考察的东西。

7.3 我的几点真实体会

最后聊几句实在的。运维开发这个岗位，看起来是“什么都考一点”，实际上考察的核心只有一个：你亲手折腾过多少真实系统。笔试题目里很多细节，纯靠背是记不牢的——比如排查方案、脚本异常处理、消息队列积压原因，只有真实环境里踩过坑，才会形成直觉。我自己学Linux初期就是拿着自己的电脑反复折腾，搞坏了就重装，折腾多了，那些命令和排查思路想忘都忘不了。

另外一个体会是：答题时不要追求完美的“标准答案”，把思路完整、步骤清晰地呈现出来，比用词精确更关键。阅卷人更想看到的是一个能干活的人，而不是一个“行走的背题机器”。如果你能把题目的场景和你实际接触过的小项目结合起来作答，哪怕是课程设计、个人博客迁移、实验室服务器维护这种小事，都会让答题显得更有温度。

摩拜运维开发校招笔试复盘：从编程到场景设计全解析