1. 从岗位JD反推SRE笔试到底在考什么每年秋招季SRE站点可靠性工程师方向的岗位总会被很多人误解。有同学把它当成“运维岗”有人觉得是“开发岗的备胎”还有人认为“会搭个环境、会用监控工具就够了”。如果你带着这些认知去笔试大概率会栽。我先说结论SRE笔试考的不是单一技能而是“系统工程能力”的压缩包。它同时涉及Linux操作系统、网络协议、编程能力、故障排查思路、容量规划意识甚至还有一部分沟通协作的软技能。Shopee这类电商平台对SRE的要求尤其高——大促流量峰值、多区域部署、微服务架构下的链路追踪任何一个环节出问题影响的是真金白银的订单。那次提前批笔试给我的整体感受是题目不算偏但覆盖面很广而且非常注重“你怎么思考”而不是“你背了多少命令”。接下来我会把笔试题型、核心考点、答题技巧和复盘经验逐块拆开全部基于我个人的备考经历和后续面试验证希望能帮后面准备同类岗位的同学少走弯路。2. 核心考点拆解五大模块逐个击破2.1 Linux与操作系统不只是背命令操作系统是SRE的底盘。笔试里这一块基本是必考但考法和你在学校学的“操作系统原理”差别很大。学校考的是“进程和线程的区别”“虚拟内存是什么”笔试考的是“系统负载突然飙高你怎么定位”“文件句柄耗尽会出现什么现象”。我复盘了一下Linux相关的题目主要集中在几个方向进程管理僵尸进程和孤儿进程的区别如何排查和清理内存机制内存溢出时的表现Swap的利弊Buffer和Cache的区别文件系统inode耗尽意味着什么如何定位大文件、清理日志系统调优文件描述符上限、TCP连接数限制、内核参数调整笔试里有一道题让我印象很深大意是某台服务器load average突然升高到30但CPU使用率只有20%怎么解释这就是典型的“IO等待导致负载升高”场景。如果你能联想到磁盘读写瓶颈、NFS挂载延迟、或者其他同步阻塞操作就能给出合理的排查方向。提示Load average升高但CPU不高优先看IO等待和D状态进程。用top按D状态进程排序再通过iostat确认是不是磁盘打满。这个问题在SRE面试中出现频率极高。2.2 网络基础从TCP三次握手到HTTP全链路网络也是重头戏。SRE日常要面对的问题里网络层的问题最让人头疼因为它的排查链路最长涉及DNS、TCP、TLS、HTTP、负载均衡、网关等多个环节。笔试涉及的网络知识点我整理了这些高频项TCP三次握手和四次挥手的过程、各个状态的含义特别是TIME_WAIT和CLOSE_WAITHTTP/1.0、HTTP/1.1、HTTP/2的区别Keep-Alive机制队头阻塞问题HTTPS握手流程TLS版本协商证书链验证DNS解析过程A记录、CNAME、TTL的作用负载均衡策略轮询、加权轮询、最小连接数、一致性哈希有一道题考的是大量TIME_WAIT连接堆积是什么原因如何优化。如果你答“调整net.ipv4.tcp_fin_timeout参数”只能得一半分。更完整的思路是先说明TIME_WAIT产生的原因主动关闭连接的一方会进入该状态再分析这个场景是短连接过多导致的最后给出优化方案——开启tcp_tw_reuse、调整tcp_fin_timeout、或者改造服务使用长连接。2.3 编程与脚本能力伪代码也要讲逻辑SRE的笔试通常不会让你完整写一个系统但一定会考代码题。考察形式有两种一种是真的写一段代码或脚本另一种是给你一段有问题的代码让你挑错。Shopee的笔试我记得是有编程题的考的是用你熟悉的语言实现某个功能。我当时选了Python题目和字符串处理、数据结构相关。这类题本身的算法难度低于后端开发岗但会额外关注你的代码风格和边界处理。除了算法题SRE笔试还经常出现“写一个Shell脚本完成某个自动化任务”的题目比如写脚本批量检查多台服务器的磁盘使用率超过阈值就告警写脚本解析Nginx日志统计Top 10的IP写脚本定时清理超过N天的日志文件我建议你把Python和Shell都准备一下。笔试时如果题量不大尽量用Python写因为可读性强、处理文本方便。但Shell也别完全放弃因为它是SRE日常操作里的基本功。注意笔试里的代码题不要求一次通过所有测试用例但你的思考过程必须清晰。建议先写注释说明思路再写实现。判卷的人能看出来你是不是真懂。2.4 数据库与缓存必考的“老三样”电商场景下数据库和缓存是SRE绕不开的环节。笔试会怎么考不太会让你写复杂的SQL更多是考你“在某个场景下系统会出什么问题你怎么办”。我把这个模块的常考点整理了一下MySQL主从复制的原理主从延迟的原因和解决方案索引失效的常见场景慢查询定位与优化思路Redis持久化机制RDB和AOF的区别优缺点对比缓存穿透、缓存击穿、缓存雪崩的区别和应对策略数据一致性缓存和数据库的双写一致性怎么做其中“缓存三大问题”几乎是必考的一定要能分清缓存穿透查询一个不存在的key请求直接打到数据库缓存击穿某个热点key过期大量请求同时打到数据库缓存雪崩大量key同时过期或者Redis集群整体不可用应对策略也有经典答案布隆过滤器拦截非法key、互斥锁重建缓存、随机过期时间、Redis高可用架构。但如果你想答得比其他人出彩可以补充一下“热点key过期时用分布式锁避免缓存击穿”的细节以及“多级缓存本地缓存分布式缓存”的思路。2.5 故障排查与系统设计拉开差距的地方这一块是SRE笔试的重头戏也是能和普通候选人拉开差距的部分。它的题型往往是“给出一个线上故障场景请你描述排查思路”或者是“设计一个监控告警系统/日志系统”。故障排查类的题目如果你想拿高分不能只罗列命令得建立“从现象到根因”的推理链。我给你一个通用框架明确故障范围和影响面影响多少用户、多少服务、哪些地域快速定位入口看监控大盘、告警消息确认最先异常的时间点分楼层排查客户端DNS、网络→接入层LB、网关→应用层服务、容器→数据层DB、Redis、MQ止血优先先恢复服务再找根因根因分析结合日志、链路追踪、指标数据做关联分析复盘改进输出故障报告指定后续改进项这个框架在笔试里直接套用能显得你思路清晰。而系统设计题通常考的也不复杂常见的有设计一个监控告警系统指标怎么采集、怎么存储、告警规则怎么做设计一个日志收集管道海量日志怎么接入、缓冲、消费设计一个限流方案固定窗口还是滑动窗口令牌桶还是漏桶答这类题时你不需要把架构画得很复杂。关键是把链路说清楚以及说明每个环节要解决什么问题。3. 实战复盘题型结构、时间分配与答题节奏3.1 题型分布与分值逻辑我记得那次笔试整体分为几个部分单选题、多选题、填空题、简答题和编程题。整体时间大概90到120分钟不同批次可能略有差异。单看题型单选和多选覆盖的基础知识面最广但单题分值低简答题是拿分的关键因为每题分值高而且考官能从这里看到你的思考深度编程题分值中等但如果你完全放空会影响整体印象。我随手记忆了一下当时的感受大致分布是选择题含多选覆盖OS、网络、数据库、Linux基础知识约占总分40%简答题故障排查、架构设计类约占总分40%编程题约占总分20%这个分布意味着什么意味着你就算选择题错几道只要简答题答得好总分依然能稳住。所以策略上简答题绝对不能空着哪怕思路不完整也要把你想到的排查链路写出来。判卷时是采点给分你多写一个合理的方向就多一分机会。3.2 时间分配宁可留白不可恋战我的时间分配建议是这样的如果总时长120分钟选择题控制在40分钟以内拿不准的先标记跳过坚决不纠结。简答题留足60分钟每道题先花几分钟列提纲再落笔写答案。编程题留20分钟先写主逻辑边界情况有剩余时间再补。很多同学有个坏习惯在选择题上反复犹豫导致后面简答题时间不够。我在实际笔试中也遇到过这种情况——有一道关于TCP状态流转的多选题让我纠结了很久后来发现完全没必要因为后面简答题的分值更高、更好拿。提示笔试不是高考不需要每道题都做完。你的目标是“有限时间内拿到尽可能多的分”而不是“所有题目都作答完毕”。3.3 答题表达像写技术文档一样写你的答案简答题的表达方式我觉得很值得单独说一下。同样的知识点两种答法得分可能差一个档次。差劲的答法是“MySQL主从延迟会导致从库读取到陈旧数据。”好一点的答法是“MySQL主从复制中由于从库需要串行执行主库的binlog当主库写入并发较高或从库硬件性能不足时从库重放速度跟不上主库写入速度导致主从延迟。表现为从库查询到的数据落后于主库。解决方案包括优化大事务、并行复制、升级从库硬件、业务上读写分离策略调整如延迟敏感的读请求走主库。”看出差别了吗好的答案包含三个要素现象描述、原因分析、解决方案。加上逻辑连接词让读者能一眼看出你的思考链条。笔试里我遇到的一道简答题是“服务发生OOM你如何排查”我给的回答分了几层先通过监控确认是堆内存还是堆外内存再抓dump文件用MAT分析对象引用链同时检查JVM参数和代码中是否有大对象没释放最后结合发布记录确认是否是最近变更引入的问题。这种分层答法即使不是标准答案也能让面试官看到你具备完整的排查思维。4. 常见问题与教训这些坑我替你踩过了4.1 复习方向偏了背了一堆用不上的命令第一次准备SRE笔试时我犯了一个典型错误——花了大量时间背各种冷门命令参数比如tcpdump的复杂过滤规则、find的N种高级用法。结果笔试里考得并不多反而是在高性能系统设计、故障排查框架这些偏“软实力”的地方丢了分。复盘后我调整了策略基础知识以原理为主命令只需要掌握最常用的十几个。比如top、iostat、free、df、ss、netstat、ps再加上日志分析、文件处理相关的命令就够了。重要的是理解这些命令输出里的关键指标代表什么含义而不是把命令参数背得滚瓜烂熟。4.2 简答题没有结构想到哪写到哪这是很多人容易踩的坑——不是不会做是答案太乱。比如问“Redis缓存雪崩如何解决”有人会答“加缓存、做熔断、限流、集群”但缺少归类和层级看起来就像随口列举。我的经验是简答题答案一定要有框架。上面提到的“现象-原因-方案”三步式就是一个很好的框架。碰到“如何排查XX问题”的题按照“确认影响范围→从链路分层排查→定位根因→止血→根治”这个顺序写分数一定不会低。框架不是束缚而是保证你不漏答、不乱答的工具。4.3 编程题忽视边界条件编程题即使不要求全部通过我也建议你展现出足够的工程意识。我笔试时写了一段处理字符串的代码核心逻辑写出来了但没考虑输入为空串的情况。这种疏漏在判卷人眼里代表工程习惯不好。一个实用技巧写完代码后花30秒做一次自查。检查三个边界——空输入、超长输入、特殊字符。如果有异常处理或参数校验写上去哪怕代码长一点都能给判卷人留下“这个人考虑问题很周全”的印象。4.4 对业务场景的理解不够我发现有些同学对“技术本身”很熟但对“技术为什么这么用”不敏感。比如限流算法大家都知道令牌桶和漏桶但问到“电商大促场景下你选哪种”就答不上来了。这里我给一个思路选方案时要看业务特性。电商大促的特点是流量突发性强令牌桶允许一定的突发流量适合应对这种场景漏桶则更平滑适合保护下游系统。如果你能在答案里补充“我选令牌桶因为大促开始瞬间流量是突发的令牌桶允许一定的burst”就能明显拉开和别人的差距。SRE笔试的技术考点看似庞杂但核心永远指向一件事你对“系统稳定性”的理解有多深。技术是会变化的今天用的监控工具明年可能就被替代了但排查问题的思路、设计高可用方案的逻辑、权衡取舍的决策能力这些是跨工具、跨平台、跨公司稳定存在的底层能力。后面如果你也在准备类似岗位建议把时间花在这类能力的打磨上而不是追逐具体工具的新版本。等笔试真的通过后你会发现面试里考察的还是这些东西。