打开蘑菇街2019届实习生-PaaS开发工程师的笔试题时我第一反应是“这题放现在依然能打”。虽然标题里带着年份和公司名但它考的内核并不是某个产品版本而是PaaS开发工程师这个岗位最底层的几项能力基础功底、分布式常识、系统设计思维以及面对故障时的本能反应。这正是我认为这份题目值得拿来反复复盘的原因——它不像很多校招题那样堆砌偏题怪题而是把“你是否真的理解和操作过一个线上系统”这件事问得很透。这篇文章我会以这份笔试为引子结合我这些年做PaaS平台、中间件和云原生相关工作的实际经验拆解题目背后到底在考什么、怎么答才能拿到分以及如果你想走PaaS开发工程师这条路应该按什么顺序去补知识。不管是准备校招还是已经工作两三年想往平台型岗位转这轮梳理应该都能给你一些实质参考。1. 一份5年前的PaaS笔试题为什么今天还值得看1.1 PaaS赛道没有降温反而变得更实先聊点背景。PaaSPlatform as a Service这个概念火了十多年中间经历了Cloud Foundry、OpenShift、Kubernetes、Serverless几轮迭代。蘑菇街2019年招PaaS开发工程师本质上是在搭自己电商体系里的中间件平台、容器平台和基础运维能力。那时候一个电商公司的PaaS团队做的事情基本是统一配置中心、消息队列、缓存集群、微服务治理、容器编排、监控链路、发布系统。这些东西今天依然是每一个中大型互联网公司的刚需只是名字换了从“中间件团队”“基础架构部”变成“云原生平台组”“SRE平台团队”。所以别把这份题当成“考古”。PaaS开发工程师的核心职责在这五年里几乎没有变把分布式系统里通用的能力沉淀成平台让业务团队不需要关心底层细节。变化的只是技术选型比如Service Mesh从概念走向落地Kubernetes从“能跑”到“会调优”可观测性从“有日志”到“全链路TraceMetricsLogging”。这些变化反而让当年考的那些基础点更值钱因为越往上层做平台越依赖对底层的理解。1.2 当时考的不是“知识”而是“能不能上手做事”我自己带过几年校招生也出过笔试题。出题的人最怕的一种卷子是学生背书背得熟但一碰到线上故障就手足无措。蘑菇街这份题给我的感觉是它尽量在模拟“你已经在公司干活了”的场景。比如问Linux排查、问TCP状态、问缓存穿透、问消息可靠投递这些问题没有标准答案但每一道都能看出候选人有没有真实处理过类似情况。这其实就是PaaS开发岗位和其他后端岗位的一个明显差异PaaS团队通常人数不多但你维护的系统是公司所有业务共用的。一旦出问题影响面是全局性的。所以笔试里一定会考察候选人对“故障”“稳定性”“容量”这些词的理解深度。你不是在写一个订单接口你是在写几百个服务都要依赖的组件这种思维方式能不能建立起来是拿到这份offer的分水岭。2. 从真题拆解PaaS开发工程师的完整知识地图2.1 基础能力操作系统、网络、数据库这一部分几乎是送分题但送分不等于送命。很多候选人挂在“以为自己会了”的题上。常见的操作系统和Linux考点包括top、vmstat、free、df、iostat、netstat、strace这些命令的使用场景什么是上下文切换什么是系统负载怎么看CPU是IO密集还是计算密集。这类题看起来是考命令实际上考的是“你遇到线上问题时的第一反应”。比如一台机器CPU使用率到了100%你会怎么查不是直接kill进程而是先top看哪个进程、哪个线程再用strace看系统调用用jstack看Java线程栈最后定位到具体代码。网络部分TCP三次握手和四次挥手是永远的经典但PaaS岗位更爱问的是“TIME_WAIT 为什么多”“连接池参数怎么设”“什么情况下会出现大量CLOSE_WAIT”。这些问题在业务开发岗可能只是八股在PaaS岗位就是日常你维护的网关、注册中心、消息客户端全部都在跟连接打交道。数据库部分索引失效、联合索引最左匹配、MVCC、事务隔离级别、慢SQL分析是高频考点。但注意PaaS岗位问数据库往往不是考你写SQL优化而是考“你在设计一个平台组件时底层存储该怎么选”。比如配置中心的数据一致性要用数据库还是etcd来做消息队列的消息轨迹要存MySQL还是ES这些才是PaaS视角下的数据库问题。2.2 分布式中间件缓存、消息、注册中心这是PaaS笔试的“主场”也是一份卷子里区分度最高的部分。缓存方向Redis基本是必问。数据结构、过期策略、持久化方式RDB/AOF、主从复制、哨兵、Cluster分片这些属于必背。真正拉开差距的是场景题缓存穿透、缓存击穿、缓存雪崩分别怎么解决分布式锁用Redis实现要注意什么Redis在集群模式下为什么不能随便用keys命令。答题的时候不能只列方案要说出你的取舍。比如解决缓存穿透有人回答“用布隆过滤器”但你得接着说布隆过滤器有误判率而且需要提前加载全量key对于数据量小、更新频繁的场景其实“缓存空值短过期时间”的性价比更高。消息队列方向Kafka和RocketMQ是主流。PaaS岗通常不会只问“Kafka怎么保证消息不丢”而是会把生产环境的问题抛给你消费者消费变慢你怎么判断是分区数不够还是消费逻辑太慢消息重复消费你怎么做幂等Kafka的offset存在哪里为什么这些问题没有一个固定解但能看出你对消息队列原理的理解程度。注册中心和配置中心方向ZooKeeper和etcd是常客。PaaS岗位需要你理解CP和AP的区别。ZooKeeper适合做分布式协调选主、分布式锁因为它提供强一致性的Zab协议但写性能有限etcd用Raft协议也偏CP但现在很多云原生组件像Kubernetes都用它。答这类题时能说清楚“为什么Kubernetes选etcd而不是ZooKeeper”比背一堆概念要加分得多。2.3 容器与云原生Kubernetes、Service Mesh、Serverless2019年的时候Kubernetes已经是事实标准了所以笔试里出现容器相关题目很正常。但当时很多候选人只是听说过K8s真正实操过的很少。这部分题反而给了有真实项目经验的人一个秀肌肉的机会。考点包括Pod的生命周期阶段有哪些Pending、Running、Succeeded、Failed、Unknown探针livenessProbe和readinessProbe的区别Deployment滚动更新策略怎么控制Service和Ingress分别是做什么的HPA扩缩容的原理以及Pod的requests和limits对调度和QoS的影响。这里有一个特别典型的题目是“为什么Pod会被Evicted”。答案不是简单的“内存不够”而是Kubelet对节点资源的管理机制。你需要知道当节点内存达到一定阈值Kubelet会开始回收EvictionThreshold先驱逐BestEffort的Pod再驱逐Burstable最后才是Guaranteed。这个机制直接决定了你在写Deployment时应不应该设置resources。如果完全没设置那你的Pod就是BestEffort节点一紧张就被优先干掉这在生产环境是很危险的事情。Service Mesh和Serverless在2019年还算新概念现在已经是不少公司的标配了。笔试里出现这类题通常只要求概念层面Sidecar模式解决了什么问题Istio的数据平面和控制平面分工是什么Serverless的冷启动瓶颈在哪里。答题的核心是把自己的理解讲透而不是堆名词。比如冷启动可以提到镜像大小、依赖加载、Java的JIT预热甚至可以聊到“为什么Serverless更适合函数粒度小、调用不频繁的场景”。2.4 工程规范与代码能力设计模式、单元测试、代码风格PaaS开发工程师虽然做的是平台但代码质量依然是笔试考察的重点。有些题目会直接让你写一段代码但真正看的不是“能不能跑通”而是“代码长什么样”。设计模式方面单例、工厂、策略、模板方法、观察者、责任链在中间件代码里特别常见。比如一个配置变更通知组件很可能就用观察者模式一个多数据源路由组件通常会用策略模式。笔试里如果能看到候选人主动用设计模式去组织代码而且不是硬套那会是一个很加分的信号。单元测试和代码风格主要看两点一是会不会写边界条件和异常场景的测试而不是只测最顺的一条路径二是代码有没有基本的可读性——命名是否表意、方法是否过长、有没有写无意义的注释。PaaS代码会被很多团队依赖所以可维护性比炫技重要得多。我见过不少候选人代码写得“很聪明”但完全没有注释变量名全部是a、b、c这种代码上线后就是团队的灾难。3. 编程题与系统设计题最能拉开差距的两类题目3.1 编程题不仅是“写出来”更是“想清楚”蘑菇街这类公司校招的编程题一般不会出太偏的算法更多是“在实际场景里能用到”的数据结构题。比如实现一个带过期时间的LRU缓存、实现一个支持并发读写的配置类、实现一个简单的限流器。这些题表面考数据结构实际考的是你对并发、性能、边界条件的理解。以“实现一个带过期时间的LRU缓存”为例很多人第一反应是用LinkedHashMap重写removeEldestEntry这确实是标准解法。但如果你能考虑到“过期时间要不要惰性删除还是定时清理如果key过期了但还没被访问内存怎么回收高并发下怎么保证线程安全”这些问题你的代码会明显高一个档次。我建议笔试做编程题时养成这几个习惯先确认输入输出范围和边界条件而不是上来就写。思考数据结构的时空复杂度并在注释里写清楚。尽量写出可落地的代码而不是伪代码。写完以后自己检查几个典型边界空输入、大输入量、并发场景。编程题的代码不是给机器看的是给阅卷人看的。你要让他觉得“这个人回到工位可以直接开始写业务代码”。3.2 系统设计题永远从“规模”和“故障”出发系统设计题在PaaS笔试里通常不会直接让你设计一个完整的Kubernetes而是选择一个比较有代表性的业务系统比如“设计一个短链服务”“设计一个日志采集系统”“设计一个配置中心”。这类题目没有标准答案阅卷人看的是你推导的过程。拿“设计一个日志采集系统”来举例。我会按这个顺序回答先说链路应用日志产生 - Agent采集 - Kafka缓冲 - 消费处理 - 写入ES或对象存储 - 查询展示。再说关键设计Agent怎么做到低侵入用Filebeat或者自研Agent监控日志文件不修改业务代码Kafka的topic怎么分区按服务名分区保证同一服务的日志有序消费端怎么保证不堆积利用Kafka的消息堆积能力消费端按需扩消费者ES索引怎么设计按天建索引冷热数据分离。最后谈容灾Kafka挂了怎么办ES写入性能不够怎么办日志文件被rotate了Agent会不会漏采这些问题不用答得面面俱到但一定要让阅卷人看到你有“系统思维”——能够从数据流的角度把组件串起来同时能预判出每一环的瓶颈点和故障场景。这跟“背系统设计八股文”是两码事。3.3 开放题考察思路而非标准答案有些笔试最后会放一道开放题比如“如何把现有电商核心链路改造为PaaS化能力”。这种题没有参考代码纯看叙述逻辑。我见过很多候选人一上来就写“用Docker部署、用K8s编排”这是用工具替代思考。比较好的回答角度是先做业务梳理找出哪些能力是通用且被多个团队重复建设的比如登录鉴权、订单状态机、库存扣减、优惠券计算再做技术抽象把通用能力沉淀为API、SDK和平台服务最后做演进路径先从最简单的配置下发和灰度发布开始逐步实现服务编排和弹性伸缩。回答开放题的关键是展示“结构化思考”从问题定义到识别边界再到方案选型和演进路径每一步都有逻辑依据。即使你给出的方案不完美但只要推导过程合理就能拿到不错的分数。4. 笔试题背后的工程素养稳定性意识与排查能力4.1 蘑菇街这类电商公司的稳定性心态PaaS岗位笔试的很多题目表面是技术题底层是对“稳定性”的感知。我当年在电商公司做基础架构时每逢大促前最重要的不是上线新功能而是反复做容量评估和故障演练。Redis内存预估、数据库连接水位、消息队列积压量、Pod副本数每一个参数背后都可能影响整个交易链路的稳定性。笔试里出现“如何设计一个限流方案”“如何做服务降级”“如何保证消息不丢失”这类问题实际上就是在筛选有没有稳定性心态的人。什么叫稳定性心态就是你在做方案设计时第一反应不是“这个功能最好用”而是“如果它挂了会怎么样”。答这类题有一个万能的姿势先谈预防限流熔断降级、多副本多可用区、自动扩缩容再谈发现监控指标、告警规则、链路追踪最后谈恢复容灾切换、降级预案、快速回滚。把这个思路传达出来阅卷人就会知道你有“线上思维”。4.2 一个高频故障排查题接口突然超时你怎么查这是我在笔试和面试中几乎必问的一题。它看起来是个开放问题实际上考察的是排查路径的完整性。我一般期待候选人按这个顺序展开先看全局服务可用性有没有告警依赖的数据库、缓存、消息队列是否正常。再看链路用trace系统查这个接口的耗时分布是网络层耗时、业务逻辑耗时还是下游依赖耗时。然后分端排查如果是数据库慢查询看慢SQL日志和索引情况如果是缓存问题看Redis的慢日志和内存是否达到上限如果连接池不够看活跃连接数和等待线程数。最后看机器CPU、内存、磁盘、网络的监控曲线有没有异常是否有Full GC或者线程死锁。下面我整理一个快速排查表格方便笔试答题和实际使用。排查维度核心命令/工具关注指标定位思路应用层jstack、jstat、arthas线程状态、GC频率、方法耗时看是否有BLOCKED线程、频繁Full GC、热点方法网络层ping、telnet、ss延迟、连接数、丢包率判断是网络抖动还是连接池耗尽数据库show processlist、explain慢查询数、锁等待、连接数看是否有大事务、缺索引、死锁缓存redis-cli --latency、slowlog延迟、命中率、内存看是否存在大key、热点key、内存淘汰消息队列控制台/脚本查看堆积数消费延迟、堆积量判断消费者是否扩容或者逻辑是否卡住这道题建议你剪贴到自己的笔记里备考时反复练直到形成肌肉记忆。因为即使你笔试没遇到面试也一定会遇到工作后更是每天都会遇到。4.3 经验清单笔试和面试中那些不会写进题面的“潜规则”这里分享几条我在实际阅卷和面试中总结出来的经验可能比多刷一套题更有用。第一能用数据说话就别只说概念。比如你设计一个限流方案如果能说出“单机QPS大概是2000Redis单实例能抗住5万QPS但网络开销会比较大所以我会采用本地令牌桶分布式限流结合的方式”这比空谈“用Sentinel限流”有说服力得多。第二任何方案都有取舍不要追求“完美”。PaaS的开发过程本质是不断做取舍。比如配置中心用ZK做存储强一致性好但扩展性有限用MySQL做存储可用性好但需要自己处理缓存一致性。答系统设计题时主动说出“我选方案A因为场景是BA虽然牺牲了C但换来了D”这会让你看起来像一个真正做过技术决策的人。第三笔试不是考试是“预演工作”。我在阅卷时最反感的就是一份卷子写得像“标准答案摘抄”没有一句自己的话。哪怕你写的方案很朴素只要是你真的思考过、踩过坑得出的结论我会更愿意给你高分。事实上有时候看到候选人写“这块我在xx项目里遇到过当时我们采用的是xxx”这份卷子基本就是稳过了。5. 按这份真题制定你的PaaS备考路线5.1 基础层学什么、怎么学、多长时间如果你是零基础想转PaaS方向我的建议是先把基础层补齐预计用时1到2个月。操作系统、计算机网络和数据库是最重要的三门课目标不是考高分而是达到“能用来排查问题”的程度。这里我推荐一种“减法学习法”不要试图把教科书整本看完而是针对PaaS岗位常用的知识点动手实验。比如学操作系统重点做三件事用top看进程状态、用vmstat看内存和CPU切换、用strace追踪一个系统调用的执行过程。学网络重点做三件事用tcpdump抓三次握手、用ss看端口状态、用curl理解HTTP请求全流程。学数据库重点做三件事用explain分析一条慢SQL、用show processlist看锁等待、搭一个主从复制并且造一次主库宕机看看从库怎么接管。15天到20天就可以构建一个能用的基础框架剩下的交给实际踩坑。5.2 中间件层以“用起来看源码”双线推进中间件层是PaaS笔试的核心也是工作后最常用的技能。我的建议是以“用起来看源码”双线推进而不是只看文档。光会写Redis命令不算会Redis你得知道它底层用跳表实现有序集合内存淘汰时是怎么采样的主从复制为什么有延迟。Kafka同理你得知道它的Page Cache机制、分区副本的同步策略、消费者Rebalance的触发条件。具体路径可以这样排第一个月主攻Redis和MySQL每次学完一个知识点就自己搭环境做实验比如设置一个最大内存看它触发淘汰有什么表现第二个月主攻Kafka和RocketMQ重点比较两者的消费模型比如Kafka的消费组和RocketMQ的消费组有什么异同第三个月主攻Kubernetes可以在本地用Kind或者Minikube搭一个单机集群把Deployment、Service、HPA都亲手跑一遍。这个阶段最忌讳的是“只看不做”。很多候选人背了一堆概念一让他动手搭一个三节点的Redis Cluster就无从下手。PaaS开发工程师本质上是个“动手角色”纸上谈兵是过不了笔试也过不了试用期的。5.3 从真题到Offer练题、项目与心态当基础层和中间件层都过了一遍之后就要进入“笔试实战”阶段。这时候我建议你去找目标公司近两三年的真题按真实笔试的时长一般是90到120分钟来模拟。蘑菇街这份2019年的题很有代表性但不要只刷这一套最好把PaaS/基础架构/云原生方向的题目放在一起对比你很快会发现高频考点就那么几个缓存、消息、注册中心、容器、Linux排查、系统设计。除了刷题最好准备一段和PaaS相关的项目经历。校招生没有真实的大规模生产环境经验这没关系你可以自己写一些“小而真”的项目。比如自己实现一个类似Nacos的简易配置中心包含本地缓存、服务端存储、长轮询推送或者写一个基于Redis的分布式锁SDK又或者用Kubernetes部署一个自己的博客并配置好HPA和监控。把这些项目代码放到GitHub上笔试面试聊起来会有血有肉得多。最后是心态。PaaS岗位的笔试范围确实很广没有人能全知全能。遇到不会的题不要空着把你已有的理解一步一步写下来尽量展现推导过程。阅卷人和面试官想看的是“你的思维路径”而不是“标准答案”。我自己招人时也从来不是找“什么都会的人”而是找“遇到不会的东西会怎么学、怎么排查的人”。这份蘑菇街的笔试题真正考验的不是你背了多少技术名词而是你有没有在这个行业里“亲手做过事、踩过坑、总结过规律”的痕迹。希望这篇拆解能帮你把那些零散的知识点串成一条完整的线备考时少走弯路。