2018年那会儿我还在为校招做准备。当时我看到滴滴出行系统运维工程师的笔试题第一套卷子给我的最大感受是它并不是要你证明自己背了多少命令而是想看看你能不能把一个业务系统真正从0到1搭起来并且保证它后续不会轻易挂掉。这和网上那句被反复讨论的“如何从零搭建一个生产环境系统并做好维护”本质上是一回事。这篇文章我会结合当时刷题的经验以及后来在不同业务场景里做运维的真实体会从笔试背后的考点分布、生产系统搭建流程、中间件选型、高可用设计、监控日志和故障排查几个角度展开最后给一些笔试现场能直接上手的建议。适合正在准备校招的准运维、想系统梳理运维知识体系的转岗同学以及刚接手第一套生产环境、心里没底的初级工程师。1. 这套笔试背后的“出题人视角”运维考核的不是命令而是稳定性设计在滴滴这类出行平台上核心链路是乘客发单、司机接单、订单计费、实时调度。早晚高峰、节假日、恶劣天气带来的瞬间流量会对整个系统产生巨大压力。所以系统运维工程师的笔试第一个要筛选的就是“你能不能理解在线系统为什么需要稳定”。它不会只问“df -h 看磁盘”这种单一命令而是会把命令、协议、组件放到一个业务场景里让你给出判断。1.1 业务场景决定了考点分布围绕一个典型互联网在线系统出题范围基本可以被拆成四层系统层Linux 操作系统、进程管理、systemd、内核参数、文件系统。网络层TCP/IP、HTTP、DNS、Nginx 反向代理、负载均衡。数据层MySQL、Redis、消息队列以及备份恢复、主从同步、缓存一致性。方法论层容量预估、限流降级、监控告警、故障恢复和复盘。很多人以为运维就是装系统、配环境但这个岗位真正要解决的是“系统能不能扛住流量”和“出了问题能不能快速恢复”。我在实际面试中见过不少简历写得花团锦簇的同学一问到“如果公司线上接口 P99 延迟突然涨到 3 秒你第一步做什么”就开始东扯西扯。这不是技术栈问题而是缺少一套稳定性的思考框架。1.2 笔试常见的五种题型把这套题拆开看题型基本稳定只是每年在细节上会变选择题Linux 命令、网络协议、数据库索引、进程状态。判断题考察对锁、主从同步、异步、缓存淘汰策略等概念的精确理解。场景题比如“高峰期 CPU 飙高如何排查”“数据库连接池被打满如何处理”。设计题比如“为订单系统设计高可用架构画出组件关系并说明理由”。脚本题给你一段日志让你用 Shell 或 Python 统计某个指标。选择题相对好准备把基础概念刷一遍基本能过。真正拉分的是那些需要写出完整排查思路的题目。1.3 校招题和社招题的真实差异校招题最大的特点是不会故意考你某个工具的小众参数反而倾向于考“你知不知道这个东西存在的意义”。比如它可能不会让你默写 Keepalived 的完整配置但会问“主备节点之间靠什么判断对方挂掉了”。能回答出“靠 VRRP 心跳和健康检查而不是单纯看端口通不通”说明你对高可用的理解已经到了原理层面。社招题更偏向实操比如“你之前调优过什么内核参数效果如何”。校招阶段没有实战经验很正常但你可以用笔试来证明我虽然没操作过但我知道正确步骤是什么也知道为什么要这样做。2. 生产环境从零搭建先盘点需求再动服务器“从零搭建一个系统”这个命题表面上看是“装个操作系统部署一下应用”实际上是一个完整的工程过程。我在笔试复盘里给自己定的回答框架是四个阶段盘点需求、初始化系统、部署基础组件、部署业务并验证。每一步都有坑少走一步后面维护期就会多出一堆问题。2.1 需求盘点清单搭系统之前先问清楚的问题很多新手拿到服务器第一件事就是装环境这是最容易翻车的习惯。生产环境不止一台机器而是整个链路里的一个节点。动手之前至少要确认这几件事这个系统承担什么业务是用户请求入口还是异步任务处理预估 QPS 是多少峰值是平时的多少倍数据量规模多大什么类型要不要存历史可用性目标是多少99.9% 还是 99.99%这决定你要不要做冗余。团队有没有值班体系出问题谁能响应部署环境是自建机房还是云主机是否已有统一的监控和接入层举个例子一个订单查询接口预估峰值 QPS 2000单台应用能扛 800 QPS那理论上 3 台就够了。但如果你的可用性目标是 99.99%还需要考虑故障替换期间要保留冗余容量可能就得部署 4 台甚至 5 台而不是卡着 3 台的临界点。2.2 系统初始化要做的那些事假设你拿到的是裸机或者一台全新的云主机第一步不是装 MySQL而是做基础初始化。我当时整理的检查清单是系统盘和数据盘分开避免日志写满系统盘导致整个机器挂掉。设置主机名、时区、DNS统一时间源避免日志时间对不上。更新系统补丁但要注意生产环境更新前先备份配置。创建普通运维用户禁止 root 远程登录配置 SSH 密钥登录。调整内核参数比如vm.swappiness、net.core.somaxconn、fs.file-max、net.ipv4.tcp_fin_timeout。部署 chrony 或 ntp 做时间同步。根据业务情况安装必要的监控采集器。为什么这些看似零碎的操作很重要因为后续所有排查都要依赖“时间一致”“日志有记录”“账号有权限边界”这些基础条件。我曾经遇到过一次线上故障两个服务的日志时间相差 5 秒导致前后比对非常痛苦后来才发现是其中一台机器没有做时间同步。初始化的内核参数不要乱抄网上的“优化方案”每套参数都有适用场景。比如net.ipv4.tcp_tw_reuse在某些内核版本下对连接复用有效但在 NAT 环境下可能引发问题。比较稳妥的做法是先压测再根据监控数据决定要不要调同时把每项参数变更记录到文档里。2.3 基础组件与应用部署的顺序部署顺序也有讲究。我习惯的顺序是负载均衡层、存储层、中间件层、应用层、监控层。原因很简单应用启动的时候通常需要连接数据库和缓存如果中间件还没有就绪应用就会出现“启动成功但实际不可用”的情况。先部署负载均衡是为了让应用启动后可以立即被纳入流量调度对客户端做灰度切换。监控层放在最后是因为你要等业务部署完才知道该采集哪些指标而不是一开始就铺一堆采集器。2.4 一条命令一段脚本减少人为失误我在笔试题里经常写一句话能用脚本完成的动作绝不要手工执行。无论是初始化还是应用发布手工敲命令都会带来两个隐藏问题一是容易漏步骤二是不同人操作习惯不同导致环境之间出现微小的、难以发现的差异。比较常见的方式是用 Ansible 或类似的配置管理工具。先写一个init.yml把初始化步骤固化下来ansible-playbook -i hosts init.yml这样新机器可以被反复以同样的标准初始化。即使你现在只有一两台机器我也建议养成这个习惯因为它能让“搭建系统”变成“执行代码”而不是依赖某个人的记忆。3. 中间件选型与配置细节这些笔试点最容易被拉分中间件一旦部署错后面要付出的代价是整个团队的排查时间。笔试里关于中间件的题往往不是“你用过什么”而是“你在什么场景下选它配置上要注意什么”。这需要你既懂对比又懂细节。3.1 Nginx 不只是反向代理Nginx 是流量入口的第一个关卡。笔试里最常考的方向有两个负载均衡策略和健康检查机制。upstream backend { server 10.0.0.11:8080 max_fails2 fail_timeout30s; server 10.0.0.12:8080 max_fails2 fail_timeout30s; } server { listen 80; location /api/ { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 3s; proxy_read_timeout 10s; } }这段配置看起来很常规但里面有几个容易被忽略的点。max_fails2 fail_timeout30s表示节点在 30 秒内连续失败 2 次会被标记为不可用。很多人以为这个配置是“立刻踢掉坏节点”其实它需要考虑业务重试逻辑如果业务本身会反复重试失败次数很容易被快速触发造成误摘除。proxy_read_timeout也要结合实际接口耗时去设置。设得太短慢接口会被 Nginx 直接断掉设得太长后端已经僵死时用户还一直被吊着。比较好的做法是先通过监控掌握接口耗时分布再根据 P99 延迟调整。3.2 MySQL主从复制和备份恢复数据库是笔试的硬核考点尤其是 MySQL。滴滴这类业务对数据库的依赖极强订单、账户、调度记录都不能丢。笔试里经常问的几个点是为什么用主从复制核心是读写分离、容灾备份、降低主库压力。binlog 格式怎么选一般生产环境推荐binlog_formatROW因为它对数据一致性更友好虽然日志量会比 statement 格式大。半同步复制解决什么问题在主库提交事务后至少要等一个从库确认收到 binlog才返回客户端成功能减少主从切换时的数据丢失。备份怎么做至少要有“全量备份 binlog 增量备份”并且定期做恢复演练。只答“配了主从”是不够的。你要能说出主从切换时最怕的是什么不是服务不可用而是主从数据不一致导致切过去之后用户数据出现错乱。所以笔试题里只要提到数据库高可用一定要补充“切换前检查数据同步位点”“切换后做数据校验”这两步。3.3 Redis缓存穿透、击穿、雪崩怎么解Redis 在笔试里的出镜率极高因为它直接关系到接口性能。三道经典题是缓存穿透查询一个不存在的数据每次都会打到数据库。解决办法是缓存空值或者用布隆过滤器先过滤。缓存击穿某个热点 key 过期瞬间大量请求同时打到数据库。解决办法是热点数据不过期或者加互斥锁让只有一个线程去重建缓存。缓存雪崩大量 key 在同一时间过期导致数据库压力暴增。解决办法是过期时间加随机值做多级缓存或者服务端做限流降级。如果题目再深入一点会问 Redis 哨兵和集群的区别。哨兵负责高可用节点存储的是全量数据集群负责水平扩展数据按 16384 个 slot 分散到多个节点。选哪个取决于数据量和写入压力不是越大越好。3.4 MQ消息不丢的四个条件消息队列在削峰、异步解耦场景下必不可少。笔试如果给你一个订单系统让你用 MQ 做流量削峰你要能从生产者、Broker、消费者三个环节把消息可靠性讲清楚。选型适用场景需要重点关注的配置Kafka大数据量日志、流量削峰、流处理分区顺序、消费者 offset、副本数RabbitMQ业务消息、复杂路由、低延迟镜像队列、消费确认机制RocketMQ交易类、订单、分布式事务顺序消息、事务消息、重试机制答这类题时记住四个关键字确认、持久化、备份、重试。生产端要等 broker 确认才算发送成功broker 要落盘并做多副本消费端处理成功后要主动提交 offset 或 ack失败消息要进入重试队列而不是直接丢弃。4. 高可用和“挂掉之后怎么办”笔试场景题的答题套路高可用是系统运维工程师笔试题里最绕不开的话题。它考察的不是你有没有听说过“双机热备”而是你在真实故障面前能不能给出一个可执行、分步骤、有兜底方案的处理过程。4.1 先明白可用性是怎么算出来的很多人背了“99.9%”却不知道它意味着什么。一年是 8760 小时99.9% 对应的不可用时间是 8.76 小时99.99% 对应的是 52.56 分钟99.999% 对应的是 5.256 分钟。这个数字直接决定了你要花多少钱去做冗余。如果你答“我们系统做到了 99.99%”但设计上只有一个数据库单点那这个可用性目标就是不可能实现的。所以笔试里看到可用性不要只报数字要把保障手段一起说出来负载均衡、多副本、自动故障转移、定期演练、监控告警。4.2 从单点到多副本负载均衡和健康检查一个服务只有一个实例一旦进程崩溃整个链路就断了。多副本是基础但多副本不等于高可用还要有正确的流量分配和健康检查机制。经典的方案包括LVS/负载均衡器 多台 Web 服务负载均衡器负责分发请求。Keepalived 加 VIP为主备节点提供虚拟 IP 漂移能力。Nginx upstream 配合健康检查自动摘除异常节点。云环境中使用 SLB 和健康检查探针把不健康节点从后端列表中移除。笔试答题时除了给出组件还要说明故障恢复时间。比如 VIP 漂移需要几秒钟期间如果有请求打过来可能失败此时客户端需要做重试。能把“故障恢复不是零时间”这一点说透答题档次完全不一样。4.3 数据库故障切换的完整步骤数据库故障切换是面试中的“承重墙”题目。我建议按这个顺序答确认主库状态检查进程、复制状态、磁盘、网络确认是主库不可写。提升从库在从库上停止复制执行STOP SLAVERESET SLAVE ALL然后关闭只读模式让从库可以接受写请求。切换业务连接把应用的数据库地址改成新主库进行读写验证。修复旧主库恢复旧主库重新建立主从关系让它作为新主库的从库。数据校验对比关键表的数据量、主键最大值和抽样记录确认没有严重丢失。这里面最容易被忽略的是“业务连接切换”。很多新手只盯着数据库本身忘了数据库地址往往被配置在多个服务里一处没改就会出现部分服务还在写旧库的情况。所以我会在最后补一句切换后要盯住监控看读写错误、连接数、主从延迟是否恢复正常。4.4 答题时先止损再找根因笔试场景题里经常出现“线上服务突然不可用你怎么处理”。不少人上来就说“先查 CPU、看日志”这个回答不算错但不够优。我倾向于这样答题先确认影响面立刻做止血操作比如摘除异常节点、临时限流、降级非核心功能保证系统整体可用接着扩容或者恢复基础服务等业务稳定后再慢慢排查根因。整个过程是“先恢复、再定位、后复盘”不是“先开会讨论根因”。这个思路在笔试分值上很占便宜因为出题人想看到的是你有没有责任感在故障面前第一要务是保住用户可用性而不是当侦探。5. 监控、日志与告警很多人栽在没有数据支撑的观点上一个有经验的运维不会凭感觉说“服务器好像有点卡”。监控和日志是判断一切问题的证据。笔试里考的往往不是“你会不会装 Zabbix”而是你有没有掌握“监控什么、怎么告警、告警之后怎么办”的完整链路。5.1 监控采集的五个层级一套完整的监控体系应该从下往上覆盖五个层级硬件层电源、风扇、磁盘状态、RAID 状态。系统层CPU、内存、磁盘、网络、文件句柄。中间件层Nginx 连接数、MySQL 主从延迟、Redis 命中率、MQ 积压量。应用层接口 QPS、耗时、错误率、JVM/GC 情况。业务层订单成功率、支付成功率、司机接单时长。越往上越难采集但在故障排查里越有用。系统层指标只能告诉你“哪台机器有问题”业务层指标才能告诉你“用户到底有没有受影响”。笔试设计监控题时如果能主动加上业务指标会明显比只说“监控 CPU 和内存”高一个段位。5.2 日志规范决定了排查效率日志不是越多越好而是越标准化越好。生产环境的每一行日志最好都包含时间、服务名、日志级别、请求 ID、业务关键字。比如2024-06-01 12:00:00.123 ERROR order-service orderId123456 userId789 msgpay timeout有了统一的 traceId一次用户请求经过网关、订单服务、支付服务时就能被串联起来。如果你在笔试里提到“全链路追踪”这个概念至少说明你意识到排查问题不能只看单个节点。集中式日志采集一般会用到 Kafka Elasticsearch 可视化平台这类组合但笔试不需要你背部署命令重点在于说明“日志采集后如何被搜索和分析”以及“如何根据关键字触发告警”。5.3 告警分级和响应 SOP告警不是越多越好。我在实际运维中见过最典型的问题就是告警风暴半夜里同一个问题触发几百条告警值班人直接麻木最后把手机调静音。真正有效的方式是分级P0核心业务不可用立即响应通知整个值班组。P1重要功能受损或可能演变为 P015 分钟内响应。P2局部异常但不影响核心链路工作时间处理。P3可观察到的异常趋势需要后续跟进。笔试里如果让设计告警策略建议把告警规则和场景绑定。比如“MySQL 主从延迟超过 30 秒”属于 P1因为延迟可能造成数据不一致“单台机器 CPU 超过 80% 持续 10 分钟”可能只是业务高峰可以先发 P2提醒检查容量而不是直接炸群。5.4 监控题目的标准答题框架如果笔试出现“如何为订单系统设计监控”我会用四步框架回答指标先用四个黄金信号来选指标延迟、流量、错误、饱和度。采集明确数据来源和采集周期比如系统指标 15 秒采集一次业务指标 1 分钟汇总一次。告警设定阈值和级别区分“故障告警”与“趋势预警”。动作告警触发后谁处理、多长时间内响应、下一步如何升级。这套框架的好处是完整且可落地。即使你没有真正搭过监控系统也能让人感觉到你具备“指标驱动”的运维思维。6. 实战排查链路接口突然变慢到底怎么定位故障排查是系统运维工程师最核心的实操能力也是笔试里的场景题最爱考的部分。我拿一个经典案例来演示完整排查链路某天晚上 22 点用户反馈订单接口明显变慢P99 延迟从 200ms 涨到 3 秒。6.1 第一步确认影响面不要先钻到某台机器里先确认“这是单机问题还是整个集群问题”。我会去看负载均衡的流量分发状态、错误率和耗时曲线确认是所有节点都慢还是只有某个节点慢。如果是单个节点慢优先摘除该节点让流量切到其他健康节点再慢慢排查。如果是整个集群慢说明问题出在依赖层面比如数据库、缓存、外部接口或网络链路。6.2 第二步系统层排查进入应用服务器后我会按顺序执行几个命令top vmstat 1 5 iostat -x 1 ss -stop能看 CPU 和内存整体情况vmstat关注r列运行队列和si、so交换分区情况iostat看磁盘 IO 是否打满ss -s看 TCP 连接状态是否有大量 TIME_WAIT。一个很常见的反直觉现象是CPU 占用不高但接口很慢。这时候要警惕可能是线程在等待锁或者网络 IO 到达了瓶颈。不要一看到慢就以为是 CPU 问题。6.3 第三步网络与依赖排查应用层没问题就去看网络和依赖组件。用ss -tpn查看应用进程与数据库/缓存的连接数用curl -w模拟请求带出耗时拆解curl -w connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n http://target如果time_connect很高可能是网络链路或并发连接耗尽如果time_starttransfer很高可能是后端应用处理慢。然后再去查数据库的慢查询日志、Redis 的慢日志、MQ 的积压量确认底层组件有没有抖动。6.4 第四步日志和代码定位最终定位往往靠日志。找到应用日志中该接口的耗时记录确认是某个 SQL 慢还是某个第三方接口调用没有设置超时。很多线上慢接口的根因都是“第三方接口响应慢而调用方没有超时控制导致线程池被打满”。笔试遇到这种场景不要只答“优化代码”这种空话。你可以把排查顺序、每个环节的验证方法写出来再强调超时、重试、降级和熔断这些保护机制。这才是运维视角而不是纯开发视角。6.5 复盘文档写什么故障处理完之后复盘也是笔试里会考察的意识。一份合格的复盘至少包含故障时间线什么时候发生、什么时候发现、什么时候恢复。影响范围哪些用户、哪些接口、损失了多少请求。根因分析不要只写表面原因要追到“为什么没有提前发现”。改进措施补监控、改配置、做容量评估、加自动化巡检。把复盘写清楚比事后发一堆“以后注意”有用得多。这也是我后来面试新人时非常看重的一点能不能用文档把一次事故变成团队资产。7. 笔试现场的备考建议会写脚本、懂协议、讲逻辑前面讲的都是知识面最后说几个更偏向“应试现场操作”的经验。这些看起来不起眼但在笔试里往往能帮你多拿不少分。7.1 手写脚本的能力怎么练笔试里经常出现“给一段 Nginx 日志统计每个接口 5xx 的数量”。这就是典型的管道命令题。提前把grep、awk、sed、sort、uniq组合练熟。比如统计每个接口路径的 5xx 数量grep 5[0-9][0-9] access.log | awk {print $7} | awk -F? {print $1} | sort | uniq -c | sort -rn | head -20不需要写得特别花哨关键是能一步步拆解先过滤再提取字段再聚合排序。如果你会 Python也可以用 Python 写但要保证逻辑清晰变量命名能看懂。7.2 TCP 与 HTTP 的基础一定要吃透笔试网络题大概率围绕 TCP 三次握手、四次挥手、TIME_WAIT、HTTP 状态码和连接复用展开。一个常见问题是“大量 TIME_WAIT 是好事还是坏事”。TIME_WAIT 本身是 TCP 协议正常状态但数量过多会占用本地端口导致新连接无法建立。解决思路包括开启连接复用、调整net.ipv4.tcp_fin_timeout、更合理的短连接策略或者升级到 HTTP/2 来复用连接。能说出这些层次说明你不只是知道一个命令而是理解连接生命周期的整体逻辑。7.3 遇到不会的题把“排查思路”写出来笔试最怕的不是不会而是空着。即使是拿不准的题目你也可以把“如果我在现场我会怎么验证”写出来。比如题目问“为什么数据库 CPU 突然很高”。你不知道最终原因也知道排查路径先看哪些 SQL 在跑取慢查询日志看连接数和活跃会话用SHOW PROCESSLIST定位异常会话再分析执行计划。写出这条链路即使结论不对阅卷人也会认为你有排错意识。7.4 把笔试当成一次小型架构评审做设计题时不要只给结论。用“现状分析、目标、方案、风险兜底”的结构去答会显得更成熟。比如设计高可用方案先说目标是可用性和恢复时间再说用哪些组件最后说如果主节点挂了怎么切换、有没有演练过。把后路也想进去这比只画一个拓扑图强得多。最后说一个我实际做运维之后反复验证过的心态运维不是保证永远不出故障而是不断缩短故障时长不断减小故障影响面。笔试也一样它的价值不在于你背了多少命令而在于面对一个不确定的系统问题时你能不能快速给出一个合理、有先后顺序、可验证的应对动作。把这一点想透了不管是刷题还是将来上岗你都不会跑偏。 系统运维工程师笔试指南：从零搭建生产环境的核心能力
2018年那会儿我还在为校招做准备。当时我看到滴滴出行系统运维工程师的笔试题第一套卷子给我的最大感受是它并不是要你证明自己背了多少命令而是想看看你能不能把一个业务系统真正从0到1搭起来并且保证它后续不会轻易挂掉。这和网上那句被反复讨论的“如何从零搭建一个生产环境系统并做好维护”本质上是一回事。这篇文章我会结合当时刷题的经验以及后来在不同业务场景里做运维的真实体会从笔试背后的考点分布、生产系统搭建流程、中间件选型、高可用设计、监控日志和故障排查几个角度展开最后给一些笔试现场能直接上手的建议。适合正在准备校招的准运维、想系统梳理运维知识体系的转岗同学以及刚接手第一套生产环境、心里没底的初级工程师。1. 这套笔试背后的“出题人视角”运维考核的不是命令而是稳定性设计在滴滴这类出行平台上核心链路是乘客发单、司机接单、订单计费、实时调度。早晚高峰、节假日、恶劣天气带来的瞬间流量会对整个系统产生巨大压力。所以系统运维工程师的笔试第一个要筛选的就是“你能不能理解在线系统为什么需要稳定”。它不会只问“df -h 看磁盘”这种单一命令而是会把命令、协议、组件放到一个业务场景里让你给出判断。1.1 业务场景决定了考点分布围绕一个典型互联网在线系统出题范围基本可以被拆成四层系统层Linux 操作系统、进程管理、systemd、内核参数、文件系统。网络层TCP/IP、HTTP、DNS、Nginx 反向代理、负载均衡。数据层MySQL、Redis、消息队列以及备份恢复、主从同步、缓存一致性。方法论层容量预估、限流降级、监控告警、故障恢复和复盘。很多人以为运维就是装系统、配环境但这个岗位真正要解决的是“系统能不能扛住流量”和“出了问题能不能快速恢复”。我在实际面试中见过不少简历写得花团锦簇的同学一问到“如果公司线上接口 P99 延迟突然涨到 3 秒你第一步做什么”就开始东扯西扯。这不是技术栈问题而是缺少一套稳定性的思考框架。1.2 笔试常见的五种题型把这套题拆开看题型基本稳定只是每年在细节上会变选择题Linux 命令、网络协议、数据库索引、进程状态。判断题考察对锁、主从同步、异步、缓存淘汰策略等概念的精确理解。场景题比如“高峰期 CPU 飙高如何排查”“数据库连接池被打满如何处理”。设计题比如“为订单系统设计高可用架构画出组件关系并说明理由”。脚本题给你一段日志让你用 Shell 或 Python 统计某个指标。选择题相对好准备把基础概念刷一遍基本能过。真正拉分的是那些需要写出完整排查思路的题目。1.3 校招题和社招题的真实差异校招题最大的特点是不会故意考你某个工具的小众参数反而倾向于考“你知不知道这个东西存在的意义”。比如它可能不会让你默写 Keepalived 的完整配置但会问“主备节点之间靠什么判断对方挂掉了”。能回答出“靠 VRRP 心跳和健康检查而不是单纯看端口通不通”说明你对高可用的理解已经到了原理层面。社招题更偏向实操比如“你之前调优过什么内核参数效果如何”。校招阶段没有实战经验很正常但你可以用笔试来证明我虽然没操作过但我知道正确步骤是什么也知道为什么要这样做。2. 生产环境从零搭建先盘点需求再动服务器“从零搭建一个系统”这个命题表面上看是“装个操作系统部署一下应用”实际上是一个完整的工程过程。我在笔试复盘里给自己定的回答框架是四个阶段盘点需求、初始化系统、部署基础组件、部署业务并验证。每一步都有坑少走一步后面维护期就会多出一堆问题。2.1 需求盘点清单搭系统之前先问清楚的问题很多新手拿到服务器第一件事就是装环境这是最容易翻车的习惯。生产环境不止一台机器而是整个链路里的一个节点。动手之前至少要确认这几件事这个系统承担什么业务是用户请求入口还是异步任务处理预估 QPS 是多少峰值是平时的多少倍数据量规模多大什么类型要不要存历史可用性目标是多少99.9% 还是 99.99%这决定你要不要做冗余。团队有没有值班体系出问题谁能响应部署环境是自建机房还是云主机是否已有统一的监控和接入层举个例子一个订单查询接口预估峰值 QPS 2000单台应用能扛 800 QPS那理论上 3 台就够了。但如果你的可用性目标是 99.99%还需要考虑故障替换期间要保留冗余容量可能就得部署 4 台甚至 5 台而不是卡着 3 台的临界点。2.2 系统初始化要做的那些事假设你拿到的是裸机或者一台全新的云主机第一步不是装 MySQL而是做基础初始化。我当时整理的检查清单是系统盘和数据盘分开避免日志写满系统盘导致整个机器挂掉。设置主机名、时区、DNS统一时间源避免日志时间对不上。更新系统补丁但要注意生产环境更新前先备份配置。创建普通运维用户禁止 root 远程登录配置 SSH 密钥登录。调整内核参数比如vm.swappiness、net.core.somaxconn、fs.file-max、net.ipv4.tcp_fin_timeout。部署 chrony 或 ntp 做时间同步。根据业务情况安装必要的监控采集器。为什么这些看似零碎的操作很重要因为后续所有排查都要依赖“时间一致”“日志有记录”“账号有权限边界”这些基础条件。我曾经遇到过一次线上故障两个服务的日志时间相差 5 秒导致前后比对非常痛苦后来才发现是其中一台机器没有做时间同步。初始化的内核参数不要乱抄网上的“优化方案”每套参数都有适用场景。比如net.ipv4.tcp_tw_reuse在某些内核版本下对连接复用有效但在 NAT 环境下可能引发问题。比较稳妥的做法是先压测再根据监控数据决定要不要调同时把每项参数变更记录到文档里。2.3 基础组件与应用部署的顺序部署顺序也有讲究。我习惯的顺序是负载均衡层、存储层、中间件层、应用层、监控层。原因很简单应用启动的时候通常需要连接数据库和缓存如果中间件还没有就绪应用就会出现“启动成功但实际不可用”的情况。先部署负载均衡是为了让应用启动后可以立即被纳入流量调度对客户端做灰度切换。监控层放在最后是因为你要等业务部署完才知道该采集哪些指标而不是一开始就铺一堆采集器。2.4 一条命令一段脚本减少人为失误我在笔试题里经常写一句话能用脚本完成的动作绝不要手工执行。无论是初始化还是应用发布手工敲命令都会带来两个隐藏问题一是容易漏步骤二是不同人操作习惯不同导致环境之间出现微小的、难以发现的差异。比较常见的方式是用 Ansible 或类似的配置管理工具。先写一个init.yml把初始化步骤固化下来ansible-playbook -i hosts init.yml这样新机器可以被反复以同样的标准初始化。即使你现在只有一两台机器我也建议养成这个习惯因为它能让“搭建系统”变成“执行代码”而不是依赖某个人的记忆。3. 中间件选型与配置细节这些笔试点最容易被拉分中间件一旦部署错后面要付出的代价是整个团队的排查时间。笔试里关于中间件的题往往不是“你用过什么”而是“你在什么场景下选它配置上要注意什么”。这需要你既懂对比又懂细节。3.1 Nginx 不只是反向代理Nginx 是流量入口的第一个关卡。笔试里最常考的方向有两个负载均衡策略和健康检查机制。upstream backend { server 10.0.0.11:8080 max_fails2 fail_timeout30s; server 10.0.0.12:8080 max_fails2 fail_timeout30s; } server { listen 80; location /api/ { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 3s; proxy_read_timeout 10s; } }这段配置看起来很常规但里面有几个容易被忽略的点。max_fails2 fail_timeout30s表示节点在 30 秒内连续失败 2 次会被标记为不可用。很多人以为这个配置是“立刻踢掉坏节点”其实它需要考虑业务重试逻辑如果业务本身会反复重试失败次数很容易被快速触发造成误摘除。proxy_read_timeout也要结合实际接口耗时去设置。设得太短慢接口会被 Nginx 直接断掉设得太长后端已经僵死时用户还一直被吊着。比较好的做法是先通过监控掌握接口耗时分布再根据 P99 延迟调整。3.2 MySQL主从复制和备份恢复数据库是笔试的硬核考点尤其是 MySQL。滴滴这类业务对数据库的依赖极强订单、账户、调度记录都不能丢。笔试里经常问的几个点是为什么用主从复制核心是读写分离、容灾备份、降低主库压力。binlog 格式怎么选一般生产环境推荐binlog_formatROW因为它对数据一致性更友好虽然日志量会比 statement 格式大。半同步复制解决什么问题在主库提交事务后至少要等一个从库确认收到 binlog才返回客户端成功能减少主从切换时的数据丢失。备份怎么做至少要有“全量备份 binlog 增量备份”并且定期做恢复演练。只答“配了主从”是不够的。你要能说出主从切换时最怕的是什么不是服务不可用而是主从数据不一致导致切过去之后用户数据出现错乱。所以笔试题里只要提到数据库高可用一定要补充“切换前检查数据同步位点”“切换后做数据校验”这两步。3.3 Redis缓存穿透、击穿、雪崩怎么解Redis 在笔试里的出镜率极高因为它直接关系到接口性能。三道经典题是缓存穿透查询一个不存在的数据每次都会打到数据库。解决办法是缓存空值或者用布隆过滤器先过滤。缓存击穿某个热点 key 过期瞬间大量请求同时打到数据库。解决办法是热点数据不过期或者加互斥锁让只有一个线程去重建缓存。缓存雪崩大量 key 在同一时间过期导致数据库压力暴增。解决办法是过期时间加随机值做多级缓存或者服务端做限流降级。如果题目再深入一点会问 Redis 哨兵和集群的区别。哨兵负责高可用节点存储的是全量数据集群负责水平扩展数据按 16384 个 slot 分散到多个节点。选哪个取决于数据量和写入压力不是越大越好。3.4 MQ消息不丢的四个条件消息队列在削峰、异步解耦场景下必不可少。笔试如果给你一个订单系统让你用 MQ 做流量削峰你要能从生产者、Broker、消费者三个环节把消息可靠性讲清楚。选型适用场景需要重点关注的配置Kafka大数据量日志、流量削峰、流处理分区顺序、消费者 offset、副本数RabbitMQ业务消息、复杂路由、低延迟镜像队列、消费确认机制RocketMQ交易类、订单、分布式事务顺序消息、事务消息、重试机制答这类题时记住四个关键字确认、持久化、备份、重试。生产端要等 broker 确认才算发送成功broker 要落盘并做多副本消费端处理成功后要主动提交 offset 或 ack失败消息要进入重试队列而不是直接丢弃。4. 高可用和“挂掉之后怎么办”笔试场景题的答题套路高可用是系统运维工程师笔试题里最绕不开的话题。它考察的不是你有没有听说过“双机热备”而是你在真实故障面前能不能给出一个可执行、分步骤、有兜底方案的处理过程。4.1 先明白可用性是怎么算出来的很多人背了“99.9%”却不知道它意味着什么。一年是 8760 小时99.9% 对应的不可用时间是 8.76 小时99.99% 对应的是 52.56 分钟99.999% 对应的是 5.256 分钟。这个数字直接决定了你要花多少钱去做冗余。如果你答“我们系统做到了 99.99%”但设计上只有一个数据库单点那这个可用性目标就是不可能实现的。所以笔试里看到可用性不要只报数字要把保障手段一起说出来负载均衡、多副本、自动故障转移、定期演练、监控告警。4.2 从单点到多副本负载均衡和健康检查一个服务只有一个实例一旦进程崩溃整个链路就断了。多副本是基础但多副本不等于高可用还要有正确的流量分配和健康检查机制。经典的方案包括LVS/负载均衡器 多台 Web 服务负载均衡器负责分发请求。Keepalived 加 VIP为主备节点提供虚拟 IP 漂移能力。Nginx upstream 配合健康检查自动摘除异常节点。云环境中使用 SLB 和健康检查探针把不健康节点从后端列表中移除。笔试答题时除了给出组件还要说明故障恢复时间。比如 VIP 漂移需要几秒钟期间如果有请求打过来可能失败此时客户端需要做重试。能把“故障恢复不是零时间”这一点说透答题档次完全不一样。4.3 数据库故障切换的完整步骤数据库故障切换是面试中的“承重墙”题目。我建议按这个顺序答确认主库状态检查进程、复制状态、磁盘、网络确认是主库不可写。提升从库在从库上停止复制执行STOP SLAVERESET SLAVE ALL然后关闭只读模式让从库可以接受写请求。切换业务连接把应用的数据库地址改成新主库进行读写验证。修复旧主库恢复旧主库重新建立主从关系让它作为新主库的从库。数据校验对比关键表的数据量、主键最大值和抽样记录确认没有严重丢失。这里面最容易被忽略的是“业务连接切换”。很多新手只盯着数据库本身忘了数据库地址往往被配置在多个服务里一处没改就会出现部分服务还在写旧库的情况。所以我会在最后补一句切换后要盯住监控看读写错误、连接数、主从延迟是否恢复正常。4.4 答题时先止损再找根因笔试场景题里经常出现“线上服务突然不可用你怎么处理”。不少人上来就说“先查 CPU、看日志”这个回答不算错但不够优。我倾向于这样答题先确认影响面立刻做止血操作比如摘除异常节点、临时限流、降级非核心功能保证系统整体可用接着扩容或者恢复基础服务等业务稳定后再慢慢排查根因。整个过程是“先恢复、再定位、后复盘”不是“先开会讨论根因”。这个思路在笔试分值上很占便宜因为出题人想看到的是你有没有责任感在故障面前第一要务是保住用户可用性而不是当侦探。5. 监控、日志与告警很多人栽在没有数据支撑的观点上一个有经验的运维不会凭感觉说“服务器好像有点卡”。监控和日志是判断一切问题的证据。笔试里考的往往不是“你会不会装 Zabbix”而是你有没有掌握“监控什么、怎么告警、告警之后怎么办”的完整链路。5.1 监控采集的五个层级一套完整的监控体系应该从下往上覆盖五个层级硬件层电源、风扇、磁盘状态、RAID 状态。系统层CPU、内存、磁盘、网络、文件句柄。中间件层Nginx 连接数、MySQL 主从延迟、Redis 命中率、MQ 积压量。应用层接口 QPS、耗时、错误率、JVM/GC 情况。业务层订单成功率、支付成功率、司机接单时长。越往上越难采集但在故障排查里越有用。系统层指标只能告诉你“哪台机器有问题”业务层指标才能告诉你“用户到底有没有受影响”。笔试设计监控题时如果能主动加上业务指标会明显比只说“监控 CPU 和内存”高一个段位。5.2 日志规范决定了排查效率日志不是越多越好而是越标准化越好。生产环境的每一行日志最好都包含时间、服务名、日志级别、请求 ID、业务关键字。比如2024-06-01 12:00:00.123 ERROR order-service orderId123456 userId789 msgpay timeout有了统一的 traceId一次用户请求经过网关、订单服务、支付服务时就能被串联起来。如果你在笔试里提到“全链路追踪”这个概念至少说明你意识到排查问题不能只看单个节点。集中式日志采集一般会用到 Kafka Elasticsearch 可视化平台这类组合但笔试不需要你背部署命令重点在于说明“日志采集后如何被搜索和分析”以及“如何根据关键字触发告警”。5.3 告警分级和响应 SOP告警不是越多越好。我在实际运维中见过最典型的问题就是告警风暴半夜里同一个问题触发几百条告警值班人直接麻木最后把手机调静音。真正有效的方式是分级P0核心业务不可用立即响应通知整个值班组。P1重要功能受损或可能演变为 P015 分钟内响应。P2局部异常但不影响核心链路工作时间处理。P3可观察到的异常趋势需要后续跟进。笔试里如果让设计告警策略建议把告警规则和场景绑定。比如“MySQL 主从延迟超过 30 秒”属于 P1因为延迟可能造成数据不一致“单台机器 CPU 超过 80% 持续 10 分钟”可能只是业务高峰可以先发 P2提醒检查容量而不是直接炸群。5.4 监控题目的标准答题框架如果笔试出现“如何为订单系统设计监控”我会用四步框架回答指标先用四个黄金信号来选指标延迟、流量、错误、饱和度。采集明确数据来源和采集周期比如系统指标 15 秒采集一次业务指标 1 分钟汇总一次。告警设定阈值和级别区分“故障告警”与“趋势预警”。动作告警触发后谁处理、多长时间内响应、下一步如何升级。这套框架的好处是完整且可落地。即使你没有真正搭过监控系统也能让人感觉到你具备“指标驱动”的运维思维。6. 实战排查链路接口突然变慢到底怎么定位故障排查是系统运维工程师最核心的实操能力也是笔试里的场景题最爱考的部分。我拿一个经典案例来演示完整排查链路某天晚上 22 点用户反馈订单接口明显变慢P99 延迟从 200ms 涨到 3 秒。6.1 第一步确认影响面不要先钻到某台机器里先确认“这是单机问题还是整个集群问题”。我会去看负载均衡的流量分发状态、错误率和耗时曲线确认是所有节点都慢还是只有某个节点慢。如果是单个节点慢优先摘除该节点让流量切到其他健康节点再慢慢排查。如果是整个集群慢说明问题出在依赖层面比如数据库、缓存、外部接口或网络链路。6.2 第二步系统层排查进入应用服务器后我会按顺序执行几个命令top vmstat 1 5 iostat -x 1 ss -stop能看 CPU 和内存整体情况vmstat关注r列运行队列和si、so交换分区情况iostat看磁盘 IO 是否打满ss -s看 TCP 连接状态是否有大量 TIME_WAIT。一个很常见的反直觉现象是CPU 占用不高但接口很慢。这时候要警惕可能是线程在等待锁或者网络 IO 到达了瓶颈。不要一看到慢就以为是 CPU 问题。6.3 第三步网络与依赖排查应用层没问题就去看网络和依赖组件。用ss -tpn查看应用进程与数据库/缓存的连接数用curl -w模拟请求带出耗时拆解curl -w connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n http://target如果time_connect很高可能是网络链路或并发连接耗尽如果time_starttransfer很高可能是后端应用处理慢。然后再去查数据库的慢查询日志、Redis 的慢日志、MQ 的积压量确认底层组件有没有抖动。6.4 第四步日志和代码定位最终定位往往靠日志。找到应用日志中该接口的耗时记录确认是某个 SQL 慢还是某个第三方接口调用没有设置超时。很多线上慢接口的根因都是“第三方接口响应慢而调用方没有超时控制导致线程池被打满”。笔试遇到这种场景不要只答“优化代码”这种空话。你可以把排查顺序、每个环节的验证方法写出来再强调超时、重试、降级和熔断这些保护机制。这才是运维视角而不是纯开发视角。6.5 复盘文档写什么故障处理完之后复盘也是笔试里会考察的意识。一份合格的复盘至少包含故障时间线什么时候发生、什么时候发现、什么时候恢复。影响范围哪些用户、哪些接口、损失了多少请求。根因分析不要只写表面原因要追到“为什么没有提前发现”。改进措施补监控、改配置、做容量评估、加自动化巡检。把复盘写清楚比事后发一堆“以后注意”有用得多。这也是我后来面试新人时非常看重的一点能不能用文档把一次事故变成团队资产。7. 笔试现场的备考建议会写脚本、懂协议、讲逻辑前面讲的都是知识面最后说几个更偏向“应试现场操作”的经验。这些看起来不起眼但在笔试里往往能帮你多拿不少分。7.1 手写脚本的能力怎么练笔试里经常出现“给一段 Nginx 日志统计每个接口 5xx 的数量”。这就是典型的管道命令题。提前把grep、awk、sed、sort、uniq组合练熟。比如统计每个接口路径的 5xx 数量grep 5[0-9][0-9] access.log | awk {print $7} | awk -F? {print $1} | sort | uniq -c | sort -rn | head -20不需要写得特别花哨关键是能一步步拆解先过滤再提取字段再聚合排序。如果你会 Python也可以用 Python 写但要保证逻辑清晰变量命名能看懂。7.2 TCP 与 HTTP 的基础一定要吃透笔试网络题大概率围绕 TCP 三次握手、四次挥手、TIME_WAIT、HTTP 状态码和连接复用展开。一个常见问题是“大量 TIME_WAIT 是好事还是坏事”。TIME_WAIT 本身是 TCP 协议正常状态但数量过多会占用本地端口导致新连接无法建立。解决思路包括开启连接复用、调整net.ipv4.tcp_fin_timeout、更合理的短连接策略或者升级到 HTTP/2 来复用连接。能说出这些层次说明你不只是知道一个命令而是理解连接生命周期的整体逻辑。7.3 遇到不会的题把“排查思路”写出来笔试最怕的不是不会而是空着。即使是拿不准的题目你也可以把“如果我在现场我会怎么验证”写出来。比如题目问“为什么数据库 CPU 突然很高”。你不知道最终原因也知道排查路径先看哪些 SQL 在跑取慢查询日志看连接数和活跃会话用SHOW PROCESSLIST定位异常会话再分析执行计划。写出这条链路即使结论不对阅卷人也会认为你有排错意识。7.4 把笔试当成一次小型架构评审做设计题时不要只给结论。用“现状分析、目标、方案、风险兜底”的结构去答会显得更成熟。比如设计高可用方案先说目标是可用性和恢复时间再说用哪些组件最后说如果主节点挂了怎么切换、有没有演练过。把后路也想进去这比只画一个拓扑图强得多。最后说一个我实际做运维之后反复验证过的心态运维不是保证永远不出故障而是不断缩短故障时长不断减小故障影响面。笔试也一样它的价值不在于你背了多少命令而在于面对一个不确定的系统问题时你能不能快速给出一个合理、有先后顺序、可验证的应对动作。把这一点想透了不管是刷题还是将来上岗你都不会跑偏。