几年前网易的系统运维实习生笔试题在圈子里流传度很高很多人把它当作进互联网大厂运维岗的第一块敲门砖来刷。我当时也认真做过这套题后来带实习生时又拿类似的题目面过不少人。一个很直观的感受是这套题表面上在考Linux命令、网络协议、Shell脚本这些零散知识点实际上它想验证的是一个更底层的东西——你有没有建立“系统思维”。这篇文章我想以这道笔试题为引子结合这些年在生产环境摸爬滚打的经验聊聊系统运维这个岗位到底在考什么、生产环境的系统是怎么从零搭起来的、互联网运维和国企运维的差异在哪以及准备这类笔试时真正值得投入时间的方向。不管你是准备投实习的在校生还是刚转行想入门的运维新人这篇应该都能给你一些比刷题本身更有用的东西。1. 一张运维笔试题背后的真实岗位画像它到底在考什么1.1 运维实习生每天和什么打交道先说个很多人会有的认知偏差以为运维实习生进去就是天天敲命令、重启服务、看监控告警。实际情况是实习生接触最多的往往是一些“看起来不太酷”的事——配权限、写部署文档、跟着处理工单、帮忙梳理资产清单、把一条告警的排查过程记录下来。但这些琐碎事情的背后全部指向同一个核心能力在复杂环境里快速定位问题并恢复服务的能力。网易当时那道笔试题型大概是选择题加简答题覆盖了Linux基础、网络、Shell编程、数据库、安全这几个大块。如果只看题目本身难度其实不算高很多知识点在学校里都学过。但它的巧妙之处在于它会把知识点放在一个具体的运维场景里来考。比如不直接问你“TCP三次握手是什么”而是给你一个连接超时的现象让你推断可能的原因。这时候如果你只是背了握手过程没有理解它和实际故障之间的关系就会卡住。1.2 笔试题目映射的能力坐标系我后来复盘这套题把它考察的能力归成四个象限。你可以对照着看看自己在哪个象限比较薄弱能力象限典型考察点对应的日常工作场景系统基础Linux文件系统、进程管理、系统性能分析线上CPU飙高需要快速定位是哪个进程网络排查TCP/IP协议、DNS解析、HTTP状态码、抓包思路用户反馈接口超时需要判断是网络还是应用问题自动化能力Shell脚本、Python脚本、定时任务日志清理、数据备份、批量服务器操作安全意识权限管理、防火墙规则、常见攻击方式服务器被扫描、被入侵后的应急处理这四个象限不是孤立的。比如一个典型的故障排查流程收到告警 → SSH登录服务器 → 用top/ps看进程状态 → 用netstat/ss看连接数 → 用tcpdump抓包分析 → 用脚本临时摘流量 → 定位到应用层问题。整个过程把四个象限全部串起来了。笔试就是想通过有限几道题快速判断你在这种连招场景下能不能打出节奏来。2. “从零搭建生产环境系统”从这道题拆出完整的运维实施框架热词里面有一条很扎眼“作为一个运维工程师如何在生产环境从零搭建一个系统并做好后续维护”。这几乎可以说是系统运维岗位笔试里的“大作文题”网易那套题里也有类似的开放性问答。很多人看到这种题就懵了不知道从哪说起。其实它考的不是你用过哪个具体工具而是你有没有一个完整的运维实施框架。2.1 需求确认与环境规划所有后续工作的地基很多新手答这道题上来就写“安装CentOS配好IP部署Nginx”。这个答案在面试官眼里基本等同于没答。生产环境和自己的测试虚拟机有本质区别——你需要先搞清楚一系列前置问题这个系统跑什么业务预估多少并发对可用性的要求是几个9有没有等保合规要求预算多少这些直接决定了你的架构选型。我的习惯是先把需求拆成一张表业务类型Web服务、API服务、数据库、中间件还是离线计算任务流量预估峰值QPS、日常QPS、数据量增长预期可用性要求99.9%还是99.99%决定了要不要做冗余和负载均衡资源预算几台机器、多大配置、用什么云厂商或者自建机房安全合规是否需要过等保、日志留存多久、敏感数据怎么加密这些信息确认之后才开始规划网络拓扑、机器分配、服务部署方式。比如一个典型的Web应用至少需要区分内网和外网数据库不能直接暴露公网应用层前面加负载均衡日志系统单独收集。这个架构不是拍脑袋定的而是根据上面的需求表一层层推导出来的。笔试里如果能把这个推导过程写出来比罗列一堆工具名有用得多。2.2 应用栈与部署结构一台机器到多节点的思考生产环境部署最忌讳的就是“把一堆服务塞进一台机器”。这就像租房一个人住一居室没问题但一家五口挤一居室肯定要出事。生产环境的基本逻辑是分层接入层、应用层、数据层、缓存层每层独立部署故障时可以单独扩容和摘除。以一套典型的LNMP架构为例我会这样规划接入层Nginx负责静态资源处理和反向代理配置HTTP/2、Gzip压缩、连接超时参数应用层PHP-FPM或Node.js服务设置进程数和请求超时搭配Systemd做守护数据层MySQL做主从复制主库负责写从库负责读定期全量备份加binlog增量备份缓存层Redis存热点数据设置合理的过期策略防止缓存雪崩这里有个实操中很重要的点所有配置文件要纳入版本管理不能直接在生产机器上改完就不管了。我见过太多事故就是“有人手动改了配置没有同步到其他机器重启后行为不一致”。所以从零搭建的时候一定要把配置管理这件事从一开始就做起来哪怕只是用Git简单地管起来也比裸奔强。2.3 监控与备份让系统从“能跑”变成“能维护”一个系统部署完能访问其实只完成了30%的工作。剩下的70%是“后续维护”而这部分恰恰是运维笔试里难得分的点。判断一个系统是否“生产可用”核心标志不是功能正常而是出了问题能不能被发现、能不能被定位、能不能被恢复。监控体系至少要覆盖三层基础监控CPU、内存、磁盘、网络IO用Prometheus加node_exporter采集应用监控接口响应时间、错误率、QPS用SkyWalking或者Pinpoint做链路追踪日志监控ELK或者Loki收集应用日志对ERROR关键字做告警备份这件事更要提前设计。我给自己定了一条铁律任何系统上线前必须验证过一次备份恢复流程。备份文件躺在存储上没有任何意义只有确定能恢复它才算资产。所以从零搭建时要把备份脚本写进crontab然后定期做一次演练式恢复确保备份本身没坏、流程走得通。2.4 安全基线最容易丢分也最容易忽略的一环笔试里如果涉及从零搭建系统安全这块是很多人的盲区。其实安全不是说让你上多复杂的防护设备而是把基础的安全习惯做对禁用root直接SSH登录改用普通用户加sudo并配置密钥登录修改SSH默认端口减少被扫描的风险但注意不要指望这个能挡真正有针对性的攻击防火墙只放行必要的端口比如只开放80、443其他端口一律限制在内网访问数据库连接使用最小权限账号不要上来就grant all privileges系统用户和密码定期轮换密码存放到专门的密钥管理系统这些虽然都是基础操作但能坚持做到的团队并不多。我早期带过一个项目上线第二天数据库就被删了原因就是开发图方便把3306端口暴露到公网密码还是admin123。那次的教训让我明白安全基线的执行不能靠自觉必须在搭建阶段就固化到流程里。3. “互联网运维”和“国企运维”另一类行业认知题的答法搜热词里还有一条很有意思“互联网系统运维和国企系统运维的区别”。我当时看到这条忍不住笑了——因为这种对比恰好是我在面试实习生时很喜欢问的一道开放式问题。它没有标准答案但非常能反映一个人对行业的观察深度。3.1 稳定性导向与合规导向的差异互联网公司的运维核心目标是支撑业务快速迭代稳定性是生命线。每天的发布次数可能几十上百次运维要解决的是如何在频繁变更中保证系统不崩。为此会引入灰度发布、回滚机制、全链路监控、容量预估这些手段。出故障不可怕可怕的是不能快速发现和恢复。国企或者传统行业的运维核心目标更多是合规和可控。系统变更要走严格的审批流程重要操作要双人复核甚至多人复核整个变更过程需要可追溯。这种环境下的运维文档能力、流程意识、沟通协调能力往往比技术细节更重要。你可能一年到头也没几次发布但每次发布的准备材料要写一大堆。3.2 技术栈、迭代节奏与团队协作对比从技术栈来看互联网运维更偏向开源生态Kubernetes、Docker、Prometheus、Grafana、Ansible基本是这个组合。迭代节奏快新技术引入也快。国企运维则可能更多使用商用软件或者自研平台比如某些监控系统、某些云管平台技术栈相对固定对稳定性的追求体现在“不轻易换”上。团队协作上差异更明显。互联网公司运维和开发是紧密协作的经常一起复盘故障、一起优化架构国企环境里运维和开发更偏向“流程上下游”的关系开发和运维之间的交接有很多制度化的约束。这不是说哪种更好而是说不同环境需要不同的工作方式。我自己比较认可的一个观点是没有好坏之分只有适配问题。刚入行的年轻人可能会觉得互联网运维更“酷”但如果你性格偏好稳定、喜欢做事有余量国企运维反而能让你更舒服。笔试里如果问到这类题建议别踩一捧一而是客观分析差异再结合自己的特质说明倾向这样给人的印象会成熟很多。3.3 这个对比题想考察的底层能力说实话面试官问这种对比题并不是真需要你发表多么深刻的行业洞察而是想通过你的回答看三件事第一你有没有主动观察过周边环境而不是只埋头敲命令第二你能不能把现象抽象成规律——很多技术选择背后的逻辑是通用的第三你的表达有没有条理能不能把一个对比讲得清楚。这些能力在真实的运维工作里比任何单项技术都重要。4. 运维实习笔试的知识地图与典型失分点每次有学弟学妹来问我笔试怎么准备我都会先让他们画一张自己的知识地图把掌握的知识点分成三类非常熟悉、知道但说不清、完全没概念。然后按照考试频率和重要程度排序优先补“知道但说不清”的部分。因为这部分是最可惜的失分点——明明见过就是没吃透。4.1 网络与系统基础把“背概念”变成“讲链路”网络部分是笔试的必考项但很多人复习方式有问题。比如TCP三次握手几乎人人都会背但换个问法就懵了“为什么连接建立需要三次握手而不是两次”如果你能从“确认双方的收发能力都正常”这个角度来解释才是真的理解了。系统基础方面Linux的文件权限、进程状态、软硬链接、常用排查命令这些是硬通货。我建议复习的时候不要单独背命令而是给自己设计场景题比如“服务器load average突然升高你会怎么排查”然后沿着这个场景把top、vmstat、iostat、pidstat、strace这一串命令全部过一遍搞清楚它们分别能看到哪一层的问题。这种“链路式”复习法比刷一百道题都有效。4.2 脚本与自动化从“能写”到“写得像生产环境”Shell和Python脚本是运维笔试的送分题也是失分题。送分是因为题目本身不难失分是因为很多人写得不够“生产级”。一道典型的题目是“写一个脚本每天凌晨备份数据库保留最近7天的备份文件”。看起来简单但里面有好几个坑。我写过一版比较完备的可以当模板参考#!/bin/bash # 数据库每日备份脚本 # 用法: ./backup_mysql.sh 数据库名 set -euo pipefail DB_NAME${1:?请指定数据库名} BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d_%H%M%S) KEEP_DAYS7 MYSQL_USERbackup_user MYSQL_PASSWORD$(cat /etc/mysql_backup_credential) # 创建备份目录 mkdir -p ${BACKUP_DIR}/${DB_NAME} # 执行备份 mysqldump \ --single-transaction \ --quick \ --lock-tablesfalse \ --user${MYSQL_USER} \ --password${MYSQL_PASSWORD} \ ${DB_NAME} | gzip ${BACKUP_DIR}/${DB_NAME}/${DB_NAME}_${DATE}.sql.gz # 删除超过保留天数的备份文件 find ${BACKUP_DIR}/${DB_NAME} -name *.sql.gz -mtime ${KEEP_DAYS} -delete # 输出备份结果 echo [$(date %Y-%m-%d %H:%M:%S)] 备份完成: ${BACKUP_DIR}/${DB_NAME}/${DB_NAME}_${DATE}.sql.gz这个脚本里值得注意的细节用了set -euo pipefail让脚本在出错时及时退出密码不从命令行参数传入而是从文件读取--single-transaction保证备份期间不锁表MySQL InnoDB引擎下备份目录按月分目录存放方便管理。这些细节如果能在笔试里体现出来会比只会写基本逻辑的回答醒目得多。4.3 笔试现场最容易犯的三个错误我参加过不少实习生笔试的判卷发现有几个非常典型的失分原因。第一是审题不清题目明明要求写出排查思路你直接甩了一堆命令没有任何解释。运维工作很重视沟通表达光会敲命令不会说清楚判断逻辑是明显的短板。第二是答题不分层次不管分值多少都用同一种篇幅这类题一定要先搭框架再填充细节。第三是遇到不会的题直接空白——正确的做法是写出你已知的条件和可能的方向至少能体现出分析思路。5. 一些针对备考和日常积累的实在建议说到最后想围绕备考和日常积累这件事分享一些比较实在的建议。这些都是我自己当年备考、带人时验证过的路子适合所有准备投运维实习岗位的同学参考。5.1 在个人电脑上复刻一套最小运维环境刷题的最高效方式是动手。我个人强烈建议在你自己电脑上搭一套最小化的模拟生产环境哪怕只有一台虚拟机或者云服务器。在这台机器上完整地走一遍装系统 → 配置网络 → 部署Nginx → 装MySQL → 写备份脚本 → 配Prometheus监控 → 设置告警 → 模拟一次故障并排查恢复。这一套流程走完你对运维工作的理解会和只看书完全不一样。因为你会遇到各种意想不到的问题端口被占用、防火墙没放行、SELinux拦截、磁盘空间不足、时区不对导致日志时间错乱。这些坑在纸面上永远不会出现但在生产环境里天天都在发生。提前踩过一遍笔试里遇到类似场景题时你的答案会带着真实的细节。5.2 从“会操作”到“会解释为什么”我面试过很多“熟练工”操作溜得飞起但一问“为什么要这样配置”就卡壳。比如会用ulimit -n 65535调文件句柄数但不知道底层是Linux的进程级限制和全局限制两层模型。这种“知其然不知其所以然”的状态在笔试里很容易被简答题和场景题击中。所以我建议做任何操作的时候强迫自己多问三个为什么这个命令背后的原理是什么它影响的是哪一层如果不做会有什么后果带着这三个问题去查资料你积累知识的效率会翻很多倍。笔试考的不是谁背得多而是谁理解得深。5.3 我最看重实习生的三个特质最后以一个带过团队的人的角度说说什么样的实习生在我这里容易拿到return offer。第一是靠谱——分配的任务能按时完成遇到问题会提前同步不会闷头憋大招结果交上来一个不能用的东西。第二是手快心细——动手能力强同时操作前会想清楚影响范围不会在服务器上乱敲命令。第三是愿意写文档——再简单的操作能沉淀成文档分享出来就能帮整个团队节省时间。这三个特质都不在笔试的考纲里但恰恰是笔试过后真正决定你能否留下的东西。如果你现在还有时间不妨在刷题之外开始刻意培养这些习惯。最后分享一个我个人的体会系统运维这个岗位听起来像是在和机器打交道实际上做久了你会发现它最核心的职责是在混乱中找到秩序在故障中保持冷静。笔试只是这段旅程的第一站真正精彩的部分在你登录进生产环境、看到监控大屏上密密麻麻的曲线、第一次独立解决线上问题的那一刻才刚刚开始。