业务运维笔试题拆解：从故障排查到高可用架构的核心能力

1. 从一份笔试题聊起业务运维到底考什么前几天整理资料翻到了欢聚时代2018年的校招笔试题岗位是业务运维。虽然过去了几年但把这份题重新刷一遍之后我反而觉得挺有代表性——它考的不是那种“背一背就能过”的八股文而是把一名业务运维日常会遇到的真实场景压缩到了试卷里。先说结论这份笔试题的核心不是考察你会不会用某个具体的命令、能不能写出某个复杂的脚本而是考察你有没有“业务视角”。什么意思就是给你一个线上故障你能不能快速定位、能不能分清轻重缓急、能不能在最短时间内恢复服务同时把影响面控制住。这种能力光靠看书学不来得靠对系统的整体理解和对业务链路的敏感度。如果你现在准备的是业务运维、SRE、应用运维相关的校招或社招岗位这份笔试题的拆解过程值得看看。我下面会把题目背后的考点逐层剥开结合我自己在实际运维工作中踩过的坑讲清楚每类题型为什么这么出、该怎么答以及对应的知识体系怎么补。业务运维这个岗位在不少公司里定义是模糊的。有的公司叫应用运维有的叫SRE有的直接归到技术运营部。但不管名字叫什么核心职责都绕不开三件事保障线上服务的稳定、提升交付和运维效率、控制成本和风险。欢聚时代的这份笔试题基本上就是绕着这三件事来出题的。2. 岗位定位先搞清楚业务运维和系统运维不是一回事2.1 业务运维的“业务”两个字是关键我在面试候选人的时候经常问一个问题线上服务挂了你的第一反应是什么如果答案是“上服务器看日志”那说明思维还停留在系统运维层面。如果答案是“先看监控大屏确认影响范围再决定是回滚还是止血”那才有业务运维的雏形。业务运维和传统系统运维最大的区别就是对“业务连续性”的理解。系统运维关注的是单台机器的CPU、内存、磁盘网络通不通业务运维关注的是整个调用链路上哪个环节出了问题会导致用户看到报错、订单丢失、消息积压。同样是看监控系统运维看的是“这台机器负载高不高”业务运维看的是“这个接口的P99延迟为什么从50ms涨到了2秒”。欢聚时代作为直播、音视频领域的头部玩家业务运维要面对的场景非常典型高并发实时互动、海量音视频传输、多地域节点调度。这些场景对运维的要求不是“出了问题能修”而是“在出问题之前就能预判出问题之后能分钟级恢复”。所以笔试题里出现故障排查、性能分析、方案设计这类题目一点都不意外。2.2 从笔试题反推岗位能力模型把这份笔试题里的题型归归类基本可以对应到业务运维的四个能力域。基础能力Linux系统、网络协议、数据库、缓存。这部分考察你是否具备排查问题的最底层的工具箱。工具能力脚本编写、日志分析、监控告警。这决定你能不能把重复劳动自动化能不能在海量日志里快速捞到关键信息。架构能力负载均衡、高可用设计、容量评估。这决定你能不能从一台机器看到整个集群甚至从整个机房看到全局流量调度。软素质故障沟通、优先级判断、文档沉淀。这部分通常不会直接在笔试里打分但会体现在你答题的思路和表达里。我当时带过的一个实习生Linux命令敲得很熟但有一次线上告警他花了半小时在排查一台机器的负载最后发现是上游服务超时拖垮了这台机器的连接池。这个案例说明命令熟只是基本功能从全局链路去定位问题才是业务运维的核心价值。3. 核心考点逐题拆解这些知识点必须吃透3.1 网络基础是排查故障的“第一现场”网络相关的题目在业务运维笔试题里几乎是必出的。常见考法包括TCP三次握手和四次挥手的过程、TIME_WAIT状态过多的原因和处理方式、HTTP状态码语义、DNS解析流程、CDN回源逻辑等。以TIME_WAIT为例来说很多新手只知道“TIME_WAIT是主动关闭连接的一方进入的状态”但一旦问到“线上TIME_WAIT过多怎么办”就答不上来了。实际上在业务运维的日常里TIME_WAIT过多是一个特别常见的现象。尤其是高并发的短连接场景比如Nginx到后端的连接、压测工具到服务的连接都会产生大量的TIME_WAIT。看到TIME_WAIT多先别急着调内核参数。正确的排查路径应该是先用ss -s看系统层面的连接统计再用ss -antlp | grep TIME_WAIT确认是哪些端口、哪些对端IP产生的然后结合业务形态判断。如果是短连接场景TIME_WAIT多其实是正常现象只要不导致端口耗尽就没问题。如果确实影响了新连接建立再考虑调整net.ipv4.tcp_tw_reuse、tcp_fin_timeout这些参数或者从业务侧改成连接池复用长连接。这个排查思路其实就是业务运维和纯网络工程师的区别我们不只要懂协议还要懂业务场景对协议行为的影响。3.2 Linux系统与性能分析从top到strace的排查链Linux系统相关的题目笔试里通常会给出一个场景某台服务器CPU使用率飙升怎么排查负载高是CPU忙还是IO等待进程D状态卡死怎么处理这类题的答题思路我建议遵循“从全局到局部”的原则。先用top或htop看整体负载用vmstat 1看CPU的us、sy、wa、st分别高不高。如果wa高说明IO有瓶颈用iostat -x 1看具体磁盘的%util和await如果st高说明宿主机层面有CPU抢占需要确认是否被其他虚拟机影响。确认进程之后再用pidstat、perf top、strace -p PID去抓进程在干什么。这里有一个很典型的坑很多人在CPU飙高时第一时间就去看Java进程的GC日志或者直接抓线程栈这没错但效率太低。先明确CPU到底消耗在内核态还是用户态再从对应方向去查会快很多。如果是用户态CPU高抓线程栈才有意义如果是内核态CPU高可能需要关注系统调用频率比如大量中断、锁竞争、上下文切换。当年我在处理一次CPU异常时top显示某个worker进程CPU到了300%但抓线程栈又看不到业务代码的热点。后来用perf top才发现是连接池组件里的一个自旋锁在高并发下剧烈竞争。这个定位过程花了大半天后来我把这套排查思路整理成了标准操作流程团队里其他人再遇到类似问题效率提升了不少。3.3 数据库与缓存高并发场景的命门数据库和缓存几乎是业务运维笔试题里占比最高的一类因为绝大多数业务场景都绕不开存储层。常见考点有索引失效的场景、慢查询分析、主从复制延迟、死锁的排查、缓存穿透/击穿/雪崩的区别和应对。以慢查询为例笔试里可能会给你一条SQL和它的执行计划让你分析为什么慢、怎么优化。正确的分析路径是先看EXPLAIN的type字段如果是ALL全表扫描那大概率是索引没建对或没走索引如果是ref或range但要扫描的行数还是很多就要看是不是选错索引或者需要覆盖索引来减少回表。再往深一层业务运维看数据库问题不能只看单条SQL还要关注整个数据库的负载特征。比如主库的QPS并不高但磁盘IO的util长时间接近100%这可能是大量的SELECT COUNT(*)或者未分页的全表查询吃满了buffer pool。这种情况下单纯加索引解决不了根本问题要从业务侧减少不必要的大查询或者用汇总表、缓存来承接。缓存这块缓存穿透查询一个不存在的数据请求打到数据库、击穿热点key过期瞬间高并发打到数据库、雪崩大量key同时过期导致数据库压力骤增这三兄弟的区分和解决方案是高频考点。我自己的习惯是穿透用布隆过滤器或缓存空值击穿用互斥锁或逻辑过期雪崩给过期时间加随机值、做多级缓存。这些方案并不复杂关键是能不能在答题时把“为什么这么选”讲清楚。3.4 监控告警与SRE思维从“能用”到“好用”监控相关的题目在2018年的笔试题里已经出现了放到现在更是必考。考法通常是如果要监控一个Web服务的健康状态你会采集哪些指标这些指标之间是什么关系告警阈值怎么定回答这类题我会把指标分成四个层次机器层CPU、内存、磁盘、网络、中间件层连接数、队列深度、GC频率、应用层QPS、RT、错误率、成功率、业务层订单量、播放成功率、登录成功率。前两层是基础设施后两层才是业务运维真正要盯的。这里需要特别强调业务层的指标因为它是判断“服务到底有没有问题”的最终依据。有一次我们某个服务的CPU、内存、网络看起来都正常但业务方反馈用户无法充值。最后发现是充值回调接口的第三方证书过期了服务本身没有任何异常。如果监控只停留在机器和应用层这种故障根本发现不了。所以我现在设计监控的时候一定会要求接入核心业务指标哪怕初期接得粗糙一些也要先把业务水位线画出来。告警阈值这块我的经验是宁可先放宽不要一开始就追求精准。告警太多会导致疲态最终真正出问题时反而没人看。一个告警规则上线后要持续观察误报率和漏报率根据实际故障复盘去调整阈值。这个“监控运营”的过程比单纯搭一套监控系统重要得多。4. 实战演练三道典型题目的完整解题思路4.1 场景题用户反馈App无法登录如何排查这种题在笔试里通常没有标准答案但评分点很明确排查路径是否清晰、能否体现分层排查的思路、有没有考虑到回滚和止血。我建议的回答框架是这样的第一先确认影响范围。是单个用户还是大面积用户是个别网络环境还是所有网络用监控大屏看登录接口的成功率、错误码分布、平均延迟用分钟级曲线判断是从哪个时间点开始异常的。第二按可能性从高到低排查。登录链路通常涉及网关、Web服务、鉴权服务、Redis、数据库。用链路追踪工具定位到具体是哪一跳慢或者失败。如果是数据库连接数打满可能是慢SQL拖垮了连接池如果是Redis超时可能是缓存集群出现了大key热读。第三执行止血措施。如果是发布导致的先回滚如果是外部依赖问题考虑切流或降级如果是数据问题考虑临时修复或限流。第四复盘和长期改进。写故障报告包括时间线、影响范围、根因、改进项。这个框架体现的不只是技术能力更是业务运维的“大局观”。即使你具体的技术细节答得不够深只要框架清晰面试官通常会给一个不错的分数。4.2 脚本题写一个日志分析脚本欢聚时代这类公司很看重脚本能力因为业务运维每天都跟日志打交道。笔试里可能让你用Python或Shell写一段脚本比如统计Nginx访问日志中Top 10的IP、统计某个时间段内5xx状态码的数量、找出响应时间超过3秒的请求。我强烈建议用Python来答因为Python处理文本和数据分析比Shell灵活得多。即使笔试没指定语言Python的defaultdict、Counter、正则表达式这些库写起来又快又清晰。一个Top IP统计的参考思路按行读取日志用正则或split提取IP字段用Counter累加最后取前10个输出。如果能用上re.compile预编译正则再用生成器逐行处理而不是一次性读入内存还能体现你对大文件处理的理解。这种题想拿高分需要注意的点有三个一是异常处理日志里偶尔有不完整的行要能跳过不报错二是内存控制几GB的日志不能一次性读入三是输出格式用format或f-string对齐输出让别人一眼能看懂。4.3 设计题如何设计一个高可用架构设计题通常不会让你画完整的架构图而是问你某个核心服务要做高可用改造你会从哪些维度考虑这类题答得好不好直接反映你有没有架构思维。我一般从四个维度去答。冗余服务多实例部署避免单点。数据库做主从或集群跨可用区部署。负载均衡前置后端节点故障时自动摘除。容错服务之间用超时控制和重试机制但要防止重试风暴。引入熔断降级当下游依赖不稳定时快速失败而不是一直等待。容量做容量评估和压测确定单机水位和集群规模。预留一定的冗余容量应对突增流量。可观测完善的监控、日志、链路追踪。没有可观测性的高可用架构出了问题根本无法快速定位。如果能结合具体业务场景来答会更好。比如直播业务重点可能是上行推流和下行拉流的链路容灾如果是IM消息业务重点可能是消息不丢失不重复的顺序保证。结合业务场景才能让设计不空泛。5. 复习路径与答题技巧校招备考的实操建议5.1 三个月备战节奏怎么安排如果你现在是在校生准备投业务运维岗位我建议的复习节奏是第一个月打基础系统过一遍Linux、网络、数据库的基础知识参考《鸟哥的Linux私房菜》基础篇、《TCP/IP详解》卷一、《高性能MySQL》前三章这些够用。第二个月做项目、写脚本、搭环境。一定要动手比如自己搭一套LNMP环境用监控工具Prometheus或Zabbix接入指标体系模拟一次故障排查。动手做过一遍和只看书差得非常远尤其是命令的执行结果和报错信息只有自己跑过才有体感。第三个月刷题和复盘。找各家公司的运维笔试题来做重点不是背答案而是看别人怎么拆解题目。做完之后对照自己的排查思路看有没有遗漏的环节。也可以找同学模拟面试互相提问练表达。5.2 答题时候的三个小技巧先说“先框架后细节”。不管什么题先在草稿纸上列出要回答的步骤或维度再往里面填细节。这样既能保证思路完整也让阅卷人觉得你有条理。再说“用数据说话”。回答性能问题时不要说“如果CPU高就查进程”而要说“当us超过70%且sy超过30%时我会先看用户态热点再看系统调用”。有具体的阈值和判断逻辑显得你对问题有真实的感知。最后是“展示沟通意识”。在设计题或场景题里适度加入“我会先和开发确认改动的目的”“我会在变更前通知相关方”这类表达。业务运维是强沟通岗位这种表达会给你加分。5.3 不要把笔试当终点笔试只是校招的第一关后面还有面试和实际工作。就算笔试没发挥好也不代表你不适合做业务运维。我见过笔试成绩一般但面试时思路清晰的候选人最终也拿到了offer。关键是你有没有真正理解这个岗位要解决什么问题。从2018年到今天业务运维的职责也在进化云的普及让很多底层运维工作被平台承接运维工程师的工作重心越来越偏向稳定性工程、成本优化、容量规划、故障演练这些更高阶的领域。但不管怎么变排查思路、对业务的理解、把问题复盘的意识始终是核心。6. 经验复盘业务运维新手最容易踩的四个坑6.1 一上来就查日志不做全局判断这是我见过最普遍的问题。线上报障一来很多人第一反应是登录服务器tail -f看日志看到几个报错就开始改配置。但是业务运维的价值在于先判断“这是不是当前最优先要解决的问题”。如果登录接口大面积报错第一件事应该是看网关层是不是已经拒绝了一部分流量或者看发布系统是不是有人刚变更过。日志当然要看但要带着假设去看而不是漫无目的地翻。6.2 只会看指标不会关联分析监控面板上CPU、内存、带宽、磁盘全都有但很多人只是截图看不出这些指标之间的关联。比如磁盘IO升高同时接口RT升高这可能是日志落盘太频繁导致IO抢占。比如CPU的sy占比高同时上下文切换次数飙升这可能是线程数配置过大导致锁竞争。关联分析的能力需要积累但平时可以有意识地多问一句“这个指标异常还有哪些指标会一起变”。6.3 把优化手段用在错误的场景内核参数调优是个典型。比如tcp_tw_reuse能不能开、tcp_max_syn_backlog调多少都要结合实际的连接模型来看。很多新手拿到网上的优化清单就往下执行结果在长连接场景里开了短连接优化参数反而引入了新问题。我的原则是每次调优前先记录当前基线调完之后对比效果没有效果甚至变差就回滚留下调优记录。6.4 故障复盘只写根因不写改进项复盘的价值不在于找到根因而在于后续怎么避免同类问题再发生。一份合格的复盘除了时间线和根因还要有可落地的改进项比如增加告警、补充自动化检查项、优化发布流程。改进项最好能指定负责人和截止时间否则复盘就成了一纸空文。我个人在实际带团队时的习惯是每次故障之后改进项里至少有一条是“自动化”——把人工操作变成脚本或平台能力。因为人总会犯错但脚本不会忘记执行。7. 笔试之外的成长建议如果你是被“业务运维”这个岗位吸引进来的我建议你在日常学习中多培养一种“经营思维”。不要只看一台服务器的状态要把它当成一条业务链路里的一个节点。机房断网、云厂商故障、第三方接口抖动、证书过期每一个环节都可能让业务受损而业务运维就是那个把各个环节串起来、提前埋好安全网的人。实操层面有三件事越早做越好一是养成记录和写文档的习惯每解决一个线上问题就写一篇简短的处理记录包括现象、排查步骤、根因、解决方案。几年下来这些都是宝贵的经验库。二是建立自己的工具集把常用排查命令脚本化、平台化比如日志关键字告警、磁盘水位巡检、证书到期提醒这些都是可以自动化的重复劳动。三是有机会就去参与大促或演练真正的高压场景对能力的提升胜过平时一个月的练习。欢聚时代这份2018年的笔试题虽然具体题目可能早就过期了但其中考察的业务运维思维放在今天依然适用。稳定性和效率是业务运维永远的核心命题。希望这篇拆解能帮你建立自己的知识框架而不是背几道题的答案。