每年校招季都有不少同学在找金山办公运维开发工程师的笔试题。市面上流传的版本很零散多数是某年某题的残片缺少对整个考察逻辑的梳理。我结合自己多年运维开发的从业经验把金山办公2020校招软件运维开发工程师笔试题一这套卷子背后的出题思路、核心考点、典型题型和答题策略掰开揉碎讲一遍。先说结论这场笔试不是用来筛背了多少命令的人而是筛能不能用代码思维解决运维问题的人。金山办公的WPS Office服务着数亿用户客户端、云文档、会员体系、广告系统每一块背后都是海量请求和复杂链路。运维开发在这个场景下要做的不是传统意义上的机器挂了赶紧重启而是通过平台化、自动化手段让系统在不太需要人工干预的前提下稳定运行。所以你看这套题会明显感觉到Linux基础、网络原理、脚本能力、数据库常识这几大块权重非常高而且每道题背后基本都能映射到一个真实线上场景。这篇文章适合三类人看正在准备金山办公校招的应届生、想从传统运维转到运维开发方向的同学以及单纯想检验自己基础功底的工程师。我会从岗位画像、知识模块、题型拆解、场景映射、备考路线五个维度展开尽量把每个考点讲透而不是只给一个考试范围清单。1. 从岗位JD反推笔试题金山办公的运维开发在招什么样的人1.1 运维开发和传统运维的本质区别很多同学对运维开发这个词的理解是运维 开发仿佛就是一边值班一边写代码。实际不是这样。传统运维的核心动作是响应——监控告警响了人上去处理业务发版了人上去部署。运维开发的核心动作是消除响应——把需要人去做的事情用代码和平台自动化掉。举一个例子你就明白了。WPS的某个服务每天要发几十次版本传统做法是运维同学手动登录服务器拉代码、跑构建、重启进程。运维开发的做法是写一套发布平台开发者提交代码后自动触发测试、构建、灰度、全量、回滚整个过程只需要点一个按钮或者完全自动化。笔试题里考Shell、考Python、考CI/CD流程本质就是在看你能不能胜任用代码消灭重复劳动这件事。金山办公2020年这套笔试题一我判断是校招的第一轮筛选重点考察的是地基——因为你还没接触过他们的业务不可能考你具体的内部系统怎么用。所以卷子里出现的内容基本是计算机基础、操作系统、网络、数据库、脚本语言这些通用但扎实的东西。1.2 出题人的三个隐藏考察点除了知识本身这套笔试题有很强的行为考察意味。第一个隐藏考察点是做题习惯。选择题里故意设置一些看似正确实则片面的选项看你会不会凭印象选。比如考察Linux命令时问查看系统负载用什么命令选项里同时出现uptime、top、w和free——这四个命令在某种场景下都能看到负载信息但准确的答案是uptime和top能直接显示load averagefree只能看内存。如果你不看题目具体问的是load average很容易把free也选进去。第二个隐藏考察点是边界意识。编程题也好脚本题也好评分标准里经常有考虑异常输入这一项。比如让你写一个日志清理脚本如果你只写删除7天前的日志不考虑脚本重复执行时的幂等性或者不考虑路径不存在时的报错可能就丢分了。第三个隐藏考察点是表达能力。简答题部分阅卷人不是看你写得多长而是看你的排查链路是否完整。一道线上服务CPU飙高如何排查的题完整的答案应该包含先用top确认是哪个进程、再用top -H确认是哪个线程、再用jstack或pstack抓线程栈、结合日志定位到具体代码段、最后给出修复方案。很多同学只写到重启就好了这在笔试里等于没答。2. 核心知识模块逐个过这些考点没准备到就亏了2.1 Linux基础比的是理解深度不是背命令数量Linux在运维开发笔试里占比最大这是行业共识。但校招笔试题不会考你ls的参数有哪些这种纯背诵题而是考你知不知道系统在底层是怎么工作的。高频考点集中在几个方向进程管理。要清楚进程状态R、S、D、Z、T分别代表什么要知道Zombie进程是怎么产生的——父进程没有调用wait()回收子进程的退出状态子进程就变成僵尸进程。笔试里常见的一个场景题是服务器上出现大量僵尸进程怎么处理很多人第一反应是kill -9但僵尸进程是杀不掉的因为它已经死了。正确思路是找到它的父进程让父进程回收它如果父进程是init一般会自动回收如果回收不掉就要检查父进程是不是卡住了。文件系统与权限。SUID、SGID、SBIT这三个特殊权限是选择题的常客。很多同学只记得r、w、x但对SUID的具体作用说不清楚。说白了SUID就是当用户执行这个程序时临时获得该程序属主的权限典型例子是passwd命令普通用户需要通过它修改/etc/shadow而shadow文件只有root能写所以passwd命令就有SUID权限。笔试里如果给你一个文件的权限字符串-rwsr-xr-x你要能认出这个s就是SUID。性能排查命令。top、free、df、iostat、netstat、ss这些命令笔试很少直接考参数而是放在场景题里。比如系统变慢怎么判断是CPU、内存还是磁盘的问题就是考察你会不会用vmstat看CPU上下文切换、用iostat看磁盘await、用free看swap使用情况。这里有个实操细节vmstat输出的r列代表就绪队列长度如果r长期大于CPU核数说明CPU确实不够用了如果r很小但系统很慢那问题大概率在磁盘IO或者锁等待上这时候要去看iostat的%util和await。2.2 网络原理从TCP握手到HTTP状态码一条链路串起来网络模块的题我见过最典型的出法是这样的给你一个用户访问WPS网页端变慢的场景让你分析可能的原因。这道题表面上是网络排查实际上把TCP、DNS、HTTP、负载均衡全考了一遍。TCP这块三次握手和四次挥手是必须能默写的。笔试里更爱考的是状态迁移尤其是TIME_WAIT和CLOSE_WAIT。TIME_WAIT是主动关闭连接的一方进入的状态要等2MSL才能消失大量TIME_WAIT会导致端口耗尽。CLOSE_WAIT是被动关闭方没有调用close()导致的状态出现大量CLOSE_WAIT基本可以断定是应用程序有bug没有正确关闭连接。这个在选择题里经常作为哪个状态异常说明程序有问题的答案出现。HTTP状态码的考察不算难但有个坑很多人把301和302搞混。301是永久重定向浏览器会缓存这个跳转302是临时重定向每次都需要重新请求原地址。在WPS这种体量的业务里区分这两个状态码很重要——如果该用301的用了302CDN和浏览器会反复回源流量和延迟都会上来。笔试选择题里如果问用户访问旧链接自动跳转到新链接且希望搜索引擎更新索引应该返回什么状态码答案是301。DNS的考察点通常和缓存绑定。比如修改了DNS解析记录为什么用户还是访问到旧IP答案涉及DNS缓存层级浏览器缓存、系统缓存、本地DNS缓存、权威DNS的TTL。有些同学会答把本机DNS缓存清掉就好了这只是第一层实际运维中还要考虑CDN节点缓存和运营商Local DNS缓存TTL没到改了也白改。2.3 脚本能力Shell和Python各有各的考法脚本题是运维开发笔试的重头戏因为这是区分会运维和会运维开发的分水岭。Shell和Python一般都会涉及考察侧重不一样。Shell侧重的是能不能用常用命令拼出解决问题的管道。我印象里这类题很爱考以下几种日志分析统计Nginx访问日志中每个IP的访问次数按降序排列文本处理从passwd文件中提取所有用户名的第N行到第M行批量操作查找并删除7天前的日志文件标准的解法长这样# 统计访问日志中每个IP的访问次数取前十 awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这题看着简单其实有几个拿分点一是awk取IP列要准确Nginx默认日志格式里IP是第一列所以是$1二是要想到用sort先排序再uniq -c直接uniq -c是不对的因为uniq只能合并相邻的重复行三是最后的sort -rn按数字降序少了-n就会变成字典序排序10会排在9前面。Python侧重的是能不能用代码写一个稍微完整的小工具。典型题目是写一个脚本定时检查多个HTTP接口的健康状态异常时发送告警。这种题考察的就不只是语法了还包括用requests库处理超时、用线程池做并发检查、结果写入日志、异常处理逻辑。我见过很多同学在笔试里把超时参数漏掉接口一直不返回脚本就卡死了。这种细节恰恰是线上环境最要命的。下面是一个比较标准的参考答案注意看超时和异常处理import requests import time import threading from concurrent.futures import ThreadPoolExecutor URLS [ https://www.wps.cn/, https://account.wps.cn/api/users, https://drive.wps.cn/api/ping, ] def check_url(url): try: resp requests.get(url, timeout5) status UP if resp.status_code 200 else fDOWN({resp.status_code}) except Exception as exc: status fDOWN({exc.__class__.__name__}) timestamp time.strftime(%Y-%m-%d %H:%M:%S) print(f[{timestamp}] {url} - {status}) # 实际场景中这里会把异常URL写入告警队列 with ThreadPoolExecutor(max_workers5) as executor: executor.map(check_url, URLS)这道题的评分点我估计是以下几个有没有设置timeout防止接口挂死拖垮脚本、有没有捕获所有异常网络抖动、DNS解析失败都要能兜住、有没有用并发顺序检查多接口太慢体现不出工程素养。你写代码的时候心里装着这三条基本能拿高分。2.4 数据库与中间件MySQL索引是必考Redis靠理解不是靠背诵数据库在运维开发岗位的笔试里考得比DBA岗位浅但比普通后端岗位深。核心集中在MySQL和Redis。MySQL必考的是索引和慢查询。选择题里经常出现以下哪个语句能用到索引这是一个经典的考察点。比如有联合索引(a, b, c)sql是WHERE b 1 AND a 2能不能走索引很多人一看联合索引就懵了其实只要记住最左前缀原则查询条件里必须包含联合索引的最左列也就是a所以这个SQL能走索引只是b的索引效率因为a已经确定会受限但不至于全表扫描。而如果sql是WHERE c 3 AND b 2没有a那就走不了索引。慢查询的解决思路也是一道高频简答题先用EXPLAIN看执行计划确认是否全表扫描、是否走了错误索引再看是不是查询条件里对索引列做了函数操作比如WHERE DATE(create_time) 2020-09-01这样索引就失效了正确写法是WHERE create_time 2020-09-01 00:00:00 AND create_time 2020-09-02 00:00:00。Redis部分笔试爱考的是数据类型和缓存常见问题。五个基本类型String、Hash、List、Set、ZSet的使用场景要能举例子String存验证码、Hash存对象属性、List做消息队列、Set做去重、ZSet做排行榜。缓存穿透、缓存击穿、缓存雪崩这三个兄弟经常放在一起考很容易记混。我提供一个记忆锚点穿透查的是不存在的数据缓存和DB都没有击穿查的是热点数据刚好过期缓存没有DB有雪崩是大面积过期缓存整体没有了。解决方案分别是布隆过滤器或缓存空值、互斥锁或逻辑过期、过期时间加随机值或做多级缓存。3. 经典题型复盘怎么答才能拿分3.1 选择题的常见陷阱这套卷子的选择题我复盘下来感觉出题人很会埋雷。总结几个高频陷阱模式。陷阱一把相关当因果。比如问哪个命令可以查看进程的CPU占用率选项里有ps、top、pidstat、uptime。uptime显示的是系统平均负载不是进程级CPU占用但很多同学看到load average里有CPU相关字样就选了。记住看进程级CPU占用ps aux里的%CPU列是自进程启动以来的平均占用率top里的是实时刷新值两个侧重点不同要看题目问的是实时还是平均。陷阱二混淆端口和服务。问Nginx默认监听哪个端口答案是80这没错。但如果问以下哪个是HTTPS默认端口443是标准答案可有些同学会把8080也选上——8080只是常见替代端口不是默认。这种题就是在考你对约定俗成的默认值是否精确。运维工作中差一个端口就是一次事故所以出题人爱在这里做文章。陷阱三网络层的边界。问ping不通目标主机最不可能的原因是什么选项有目标主机关机、防火墙禁了ICMP、目标主机IP配置错误、DNS解析失败。很多人会纠结半天其实ping是ICMP协议走的是IP层根本不涉及DNS解析所以DNS解析失败就是最不可能的原因。这个陷阱考的是你对协议栈层级的理解。3.2 简答题把排查链路写完整别只给答案简答题比选择题更区分水平。以一道高频题为例某天用户的反馈是打开WPS云文档网页特别慢你作为运维开发工程师怎么排查很多同学写的是看看服务器负载重启一下就好了。这种答案在笔试里几乎零分因为它暴露的不是知识不足而是没有系统排查意识。一个合格的答案应该这么组织先量化问题慢是所有人都慢还是一次性用户慢是全站慢还是某个页面慢先确认影响范围。按链路逐层排查用户端网络用浏览器开发者工具看资源加载时间→ DNS解析耗时 → CDN命中情况 → 接入层Nginx响应时间→ 应用层服务调用链→ 数据层DB慢查询、Redis延迟。结合指标定位看监控系统的黄金四指标延迟、流量、错误、饱和度。如果平均延迟从200ms涨到2s而流量没涨优先怀疑代码或依赖服务如果流量涨了10倍优先考虑扩容和限流。给出临时缓解 长期修复临时措施可以是限流、扩容、切流量长期修复要追到根因比如慢SQL、缓存穿透、代码死循环等。这个答案的完整度直接反映你有没有处理过线上问题。笔试不是为了考你会不会说术语而是看你在压力下有没有清晰的排查路径。3.3 编程题用最朴素的方式拿全部分数编程题是这套卷子里区分度最高的一道通常会给一个写脚本的题目。我的建议是用最稳妥、最直白的方式实现不要炫技。举个例子题目如果是写一个Shell脚本监控服务器磁盘使用率超过80%时告警两种写法对比#!/bin/bash # 简单可靠的写法 THRESHOLD80 df -P | tail -n 2 | while read fs size used avail use_percent mounted; do percent${use_percent%\%} if [ $percent -gt $THRESHOLD ]; then echo $(date): $fs 使用率 $percent% 超过阈值 $THRESHOLD% /var/log/disk_monitor.log # 实际可以在这里触发告警脚本 fi done这个写法有几个拿分点用tail -n 2跳过了df输出表头、用${use_percent%%}去掉百分号做数值比较、把告警信息追加到日志而不是简单print。笔试阅卷人看到这种严谨处理给分意愿会高很多。另一种炫技写法是用一行复杂的awk虽然能跑但如果某个环境里awk版本有差异或者字段解析有问题反而容易翻车。笔试环境下你追求的不是最短代码而是逻辑清晰、健壮、能跑通。记住这句话展示你的工程判断力比展示你的语法技巧更重要。编程题还有一个容易被忽略的点写注释。不是每行都写的那种废话注释而是在关键逻辑处用一两行说明这里为什么这么做。这能让阅卷人快速理解你的思路也符合实际工作中的代码规范。4. 笔试题和真实工作场景的对应关系每道题都不是白考的4.1 从一道选择题到一个线上事故你可能觉得笔试里那些知识点太基础、太理论实际工作中用不到。这是最大的误解。我举三个真实例子。第一个例子TIME_WAIT。曾经有一次WPS某个内部服务在发版后频繁出现连接不上的告警排查发现是服务短连接请求量巨大客户端主动关闭连接后产生大量TIME_WAIT占满了临时端口。解决方案不是改内核参数一劳永逸而是优化代码改成连接池复用长连接。你回头看笔试里那道TIME_WAIT的选择题是不是直接对应了这个场景第二个例子MySQL索引失效。线上一个报表查询突然从200ms变成10sEXPLAIN一看开发同学在WHERE条件里对索引列用了函数DATE_FORMAT(create_time, %Y-%m-%d)导致索引完全失效全表扫描了千万级数据。笔试里考的索引列上做函数操作会导致索引失效就是这种事故的预防针。第三个例子Shell脚本的幂等性。我自己就见过一个日志清理脚本因为没写文件不存在就跳过的判断在一个新服务器上第一次运行时把整个脚本跑挂了原因是ls一个不存在的目录直接返回非零退出码脚本没加set e就中断了。笔试编程题里对异常输入的考察防的就是这种真实事故。4.2 运维开发岗位的日常平台化思维是分水岭笔试考完真正入职后你会发现工作中衡量一个运维开发工程师水平的核心指标是你做的工具和平台能不能降低周边系统的维护成本。WPS这种体量下运维开发团队日常做的事情包括但不限于建设发布系统对接几十个业务模块的构建发布、建设监控告警平台接入Metrics、日志、链路追踪数据、开发故障自愈脚本检测到服务异常自动恢复、梳理容量数据为业务大促提前扩容。这些工作的共同点是全部需要写代码全部需要理解Linux和网络全部需要懂数据库。所以你再回头看这套笔试题的构成Linux、网络、脚本、数据库、中间件恰好就是运维开发日常工作中天天打交道的东西。它不是故意刁难你而是用一场考试模拟了一个合格同事应该具备的知识图谱。5. 备考时间线与考场策略一个月足够但方向要对5.1 按知识权重分配复习比例如果你还有一个月左右的时间别平均用力。按照这套题以及同类校招笔试题的出题规律我建议的复习时间分配如下模块建议占比优先级理由Linux基础与常用命令25%最高题型多、分数多且是其他模块的基础网络基础TCP/HTTP/DNS20%最高简答题和场景题的高频素材Shell与Python脚本25%最高区分度最大的部分直接体现开发能力MySQL与Redis15%中必考且内容固定投入产出比高监控、CI/CD、容器等概念题15%中了解核心概念和工作原理即可这个比例不是绝对的但方向是对的脚本和Linux能拉开的差距最大值得多花时间。5.2 每周复习节奏建议第一周主攻Linux和网络。Linux不要只看命令手册要动手在虚拟机或云服务器上实践自己创建一个用户并配置sudo权限写一个systemd服务用top和vmstat观察系统负载变化。网络部分画一遍TCP三次握手四次挥手的时序图把每个状态迁移的原因写清楚再把常见的HTTP状态码背熟。第二周主攻脚本。每天至少手写一个Shell脚本和一个Python小工具。Shell重点练习grep、awk、sed组合处理日志Python重点练习requests、subprocess、文件操作、并发。练完以后要反思如果输入数据格式变了怎么办如果脚本被重复执行怎么办这个反思过程本身就是笔试想要考察的。第三周主攻数据库和中间件。MySQL重点搞懂索引原理和EXPLAIN输出字段的含义Redis重点掌握五种数据结构和三个缓存问题的解决方案。这两块内容相对固定背熟了做题很快。第四周做整体模拟。找一套综合笔试题不一定是原卷按真实考试时间做一遍然后复盘错题把薄弱知识点再补一轮。同时把简答题的排查链路整理成自己习惯的模板考场上可以直接套用。5.3 考场上的实操策略最后说几个考场上的通用策略都是我实际接触过的经验。第一先做编程题再做选择题。编程题分值高且需要思路清晰趁头脑清醒时做。选择题如果卡住先跳过最后有时间再回头纠结。第二简答题分段作答。别写成一整段流水账用1、2、3或者第一步、第二步把排查链路拆开。阅卷人看这种答案一眼就能抓住你的思路给分也痛快。第三不确定的选择题用排除法 常识兜底。比如以下哪个协议用于发送邮件这种题忘记SMTP全称也没关系你记得HTTP是网页、FTP是文件、SMTP是邮件剩下那个就是答案。考场上没有搜索引擎但常识通常够用。第四善用演进式调试的心态。编程题如果一次写不对不要慌着推翻重写。先在草稿纸上把输入、处理、输出三个环节列出来再对着环节逐步写代码。实际工作中你没有一次写对的压力笔试里也不需要有。说到底金山办公2020校招这套笔试题一想传递的信号很明确运维开发这个岗位需要的不是一个什么都会一点的通才而是一个基础扎实、能写代码、有排查思路、有工程意识的人。你按这个方向去准备无论它是2020年的题还是2025年的新题核心逻辑都不会变。我最后再分享一个个人体会笔试只是敲门砖真正决定你能否拿到Offer的是笔试里体现出来的思维习惯——写脚本考虑边界条件、排查问题按链路推进、回答方案先讲清思路再谈细节。把这三个习惯带到考场上你的成绩大概率不会差。