去年帮学弟整理秋招真题时又把哔哩哔哩2019秋招技术岗系统工程师笔试题翻了出来。说实话这套题放到现在依然不过时它没有追任何花哨的新技术名词反而把系统工程师最该有的基本功——从零搭建一个生产系统并把它稳定维护下去——问得明明白白。如果你正在准备系统工程师、运维开发或 SRE 相关岗位这套题的复习思路值得反复琢磨。这套题最难得的地方在于它把“系统工程师”这个岗位从纯技术维度拉到了业务维度。它不是问你“Nginx 的 worker_processes 配多少”而是给你一个真实场景让你作为运维工程师在生产环境从零搭起一套系统并说清楚后续怎么维护。今天我就围绕这个核心把我对这套题的理解、备考路径和实际踩过的坑完整拆一遍。1. 这套题为什么值得反复刷系统工程师笔试的底层逻辑1.1 它考的不是“会不会”而是“有没有体系”刷过这套题的人应该有个共同感受每道题单独拎出来都不算难但合在一起就非常考验人。比如同样问“如何部署一个 Web 服务”初级答案是“装 Nginx配个 server 块把代码放上去”但 B 站这种体量的平台背后要回答的其实是这个服务要支撑多少 QPS数据落在哪里挂了怎么恢复怎么发版不中断别人攻击怎么办磁盘满了怎么预警所以这套题的底层逻辑是考察你有没有建立一套“从需求到上线再到运维”的完整闭环。它默认你不是只会敲命令的“手工运维”而是能从系统架构角度思考问题的工程师。笔试里的大题往往就是给一个业务场景让你输出一整套搭建方案。这时候最怕的就是东一榔头西一棒子想到什么写什么。阅卷人想看到的是你脑子里有一套清晰的层次结构。我自己后来复盘时把系统工程师需要的能力拆成了四层底层是 Linux 系统和网络基础往上是中间件和数据库的运维能力再往上是监控、日志、安全、备份这些“保障能力”最顶层才是高可用架构设计、容量规划和成本控制。这套题基本把这四层都覆盖了所以它适合用来做一次全面的自我体检。1.2 从“救火队员”到“系统工程师”岗位画像变了以前很多团队对运维的认知还停留在“服务器挂了赶紧重启”“网络不通帮忙看看”。但到了 B 站这种以视频、直播、弹幕为核心业务的内容平台系统工程师的角色早就变了你得懂业务知道视频上传链路里哪个环节容易成为瓶颈你得懂开发能看懂服务日志定位代码问题你还得有产品思维在做容量规划时能判断“这个功能上线后会带来多少新增流量”。这套题里的很多场景其实就是从 B 站自己的业务土壤里长出来的。比如视频转码集群的资源调度、弹幕服务的高并发写入、投稿系统的数据一致性这些都不是纯理论问题而是真实生产环境里每天都要面对的事。所以准备这套题不能只背面试题得把自己代入到“我是这个平台的系统工程师”这个角色里去想问题。我当时准备时做了一件事把 B 站的主要业务流程从头到尾画了一遍。用户上传视频会发生什么转码任务怎么分发视频文件存在哪CDN 怎么回源弹幕和评论走什么存储会员、投币这些计数服务怎么保证不超卖把这个链路理清楚之后再看任何一道系统设计题都不会觉得没话说。2. 从零搭建一个生产系统笔试背后的完整链路2.1 第一步先想清楚这个系统到底要支撑什么笔试里如果让你“从零搭建一个系统”很多人上来就开始写安装命令这是大忌。任何系统都不是凭空存在的它一定是为了支撑某个业务。所以第一步永远是确认需求这个系统是给谁用的预期并发是多少数据量级多大可用性要求是 99.9% 还是 99.99%有没有合规或者安全上的硬性要求这里有一个很实用的框架叫“非功能需求六要素”可用性、性能、可扩展性、安全性、可维护性、成本。回答系统搭建题时把这六项逐一说明整个答案的完整度会立刻上一个档次。比如可用性要求决定你要不要做双机热备性能要求决定你要不要上负载均衡和缓存成本约束决定你是用物理机还是云主机是 SSD 还是普通云盘。我自己在做这类题时习惯先写一段“需求假设”假设这是一个面向内部用户的运营后台预计注册用户 5000 人峰值 QPS 50数据量一年不超过 100GB可用性要求 99.9%。把假设写清楚后面所有技术选型就都有了依据。面试官最怕的就是你什么都不问上来就配了一台 64 核 128G 的机器——不是不能用而是严重浪费。2.2 服务器选型、网络规划与基础环境初始化需求定清楚之后才轮到服务器选型。这里有一个容易被忽略的点选型不是越贵越好而是匹配业务场景。比如一个纯静态文件服务CPU 不需要太高但磁盘 IO 和带宽要够一个视频转码服务CPU 核数和指令集反而最关键一个数据库服务内存大小、磁盘随机读写能力、是否支持 NVMe都比 CPU 主频重要。系统工程师笔试里经常会考 RAID 的选择。生产环境我个人推荐系统盘用 RAID1数据盘根据场景选 RAID10 或 RAID5。RAID0 性能好但没有冗余SSD 单盘故障率虽然低但一旦坏了就是数据灾难别拿生产环境赌人品。如果是云服务器还要考虑云盘类型的选型高效云盘、SSD 云盘、ESSD 云盘的能力差异很大但考试和面试时你只需要说清楚“根据 IOPS 和吞吐需求选择”这个逻辑。基础环境初始化是所有后续步骤的地基。很多人上来就装业务软件结果系统参数没调过两天服务一上线就出问题。我一般会把初始化分成六步每一步都有明确目的系统安装与分区/boot给 1G/和/data分开放避免业务数据把系统盘写满。配置时间同步用 chrony 或 ntpdate确保所有机器时间一致否则日志排查和分布式事务都会出问题。调整内核参数vm.swappiness10net.core.somaxconn65535fs.file-max1000000这些是基础如果是数据库机器还要调vm.dirty_ratio和vm.dirty_background_ratio。创建普通用户并配置 sudo不要整天用 root 操作至少要留审计线索。SSH 安全加固禁止 root 直接登录、禁止密码登录、使用密钥认证、修改默认端口至少不要裸奔 22 端口。配置统一 yum/apt 源和基础监控 agent这一步是为了后续批量管理和发现故障。这套初始化动作笔试里不可能让你全写但你答题时只要提到“系统初始化要包含内核参数调整和安全加固”就已经能和其他考生拉开差距了。2.3 部署与配置管理从手工到脚本化单台机器初始化完接下来就是装运行时和中间件。以一套典型的 Web 系统为例Nginx 做反向代理后端是 Java 应用或者 Python 应用MySQL 存业务数据Redis 做缓存。很多人觉得这一步就是“yum install 一下然后改配置”但生产环境远没有这么简单。同一个应用要部署在 10 台机器上每台手工改配置文件改完还要保证一致性这就是灾难。所以笔试和面试里我非常推荐主动提到配置管理工具Ansible、SaltStack、Puppet或者至少用 shell 脚本 模板文件来实现自动化。我自己最常用 Ansible因为它是 agentless 的只需要控制机能 SSH 到目标机器学习成本相对低而且用 YAML 写 playbook 可读性很好。这里有个实战中的坑千万不要在 playbook 里写死 IP 和环境变量。把环境相关的配置抽到group_vars或host_vars里一份 playbook 可以在测试、预发、生产三套环境复用。我当时第一次写自动化部署脚本时图省事把数据库密码直接写在了 role 里结果代码仓库一同步密码就泄露了。后来改成用 Ansible Vault 加密敏感信息再结合 CI/CD 的密钥管理才把这个问题解决掉。部署时还要考虑“怎么发版不中断”。最简单的做法是 Nginx Upstream 里摘掉一台机器等它处理完存量请求后再拉新代码、重启服务、重新挂回负载均衡。复杂一点的可以用蓝绿部署或者金丝雀发布。笔试如果问到发布策略哪怕只是简单提到“先摘流量、再发代码、最后挂回”也说明你想过生产环境的真实情况而不是只会 git pull。3. 让系统“活下来”后续维护的日常功课3.1 监控、日志、告警三件套怎么搭才不踩坑系统搭起来只是开始“后续维护”才是这套笔试题真正想考察的重头戏。一个没有监控的系统就像开车不看仪表盘等发现出问题时大概率已经晚了。所以笔试里只要提到维护监控告警一定要排在前面。监控体系我推荐按“指标采集 → 存储 → 展示 → 告警”四层来设计。指标采集层现在事实标准是 Prometheus Node ExporterExporter 暴露/metrics接口Prometheus 定期拉取存储层就是 TSDB 时序数据库展示层用 Grafana画 CPU、内存、磁盘、网络、QPS、延迟这些面板告警层通过 Alertmanager 把告警推送到钉钉、企业微信、邮件或者 Webhook。但这里有一个新人特别容易踩的坑告警规则写得太糙。比如“CPU 使用率超过 80% 就告警”听起来没毛病实际上生产环境 CPU 长期跑在 80% 以上但业务很稳的情况多的是。如果告警天天响大家就会麻木最后真出大事也没人看。我后来学乖了告警规则一定是和 SLO 挂钩的比如“Nginx 5xx 比例连续 5 分钟超过 1%”才告警而不是只盯单一资源指标。日志这块生产环境最少要满足三个要求采集、集中存储、便于检索。以前我在小公司就是tail -f /var/log/messages出问题了逐台机器翻日志效率极低。后来上了 ELKElasticsearch Logstash Filebeat Kibana才真正体会到统一日志平台的好处。如果嫌 ELK 太重也有轻量方案Loki Promtail Grafana对中小团队更友好。另外所有服务器一定要开启日志轮转。不轮转的后果我真实遇到过一个 Java 服务没配 logrotate/var/log被日志撑满磁盘 100%服务直接只读。别问为什么没有监控告警因为监控本身也写在同一个磁盘上真就是“监控自己先死了”。现在我的机器上所有日志都会配logrotate按大小或天切割保留最近 30 天压缩旧日志。3.2 备份与容灾平时用不到出事救命笔试里如果有一道题问“你如何保证数据安全”备份策略是必答项。但很多人对备份的理解就是“写个脚本每天 tar 一下”这在小系统里勉强够用生产环境远远不够。先说数据库备份。MySQL 最基础的策略是物理备份XtraBackup加逻辑备份mysqldump再配合 binlog 做增量恢复。我一般这样设计每天凌晨 2 点用 XtraBackup 做一次全量备份 binlog 实时同步到备份服务器同时每 5 分钟做一次 binlog 增量拉取。这样即使数据库在下午 3 点被误删也可以从当天凌晨的全量备份 当天的 binlog 恢复到误删前的那一刻。恢复时间目标RTO和恢复点目标RPO是面试必问概念最好提前背熟并能结合实际场景说清楚。文件备份比数据库简单但也有讲究。不要只把文件复制到同一台机器的另一个目录——磁盘都坏了你备份得再勤也没用。一定要“异地”或者至少“异机”有条件就传到对象存储。我在实践中做了一个双保险本地 NAS 做每日快照对象存储每周做一次归档。成本可控而且真的遇到机房级故障时手里有粮。备份做完还要验证。这是我最想强调的一点没有做过恢复演练的备份等于没有备份。一次备份脚本因为权限问题每天报错但没人看三个月后才发现所有备份文件都是空的。当时真是后背发凉。从那以后我每个月至少做一次恢复演练把备份文件恢复到一台临时机器上启动服务跑一遍关键查询。这不只是笔试加分项是救命的。3.3 安全加固笔试里最容易丢分的隐藏考点很多系统工程师笔试的参考答案里都会把安全放在最后甚至直接忽略。但 2019 那套题里安全相关的内容其实穿插在好几个场景里。一个合格的系统工程师不可能不懂安全基础。安全加固可以从“进、出、内”三个维度来想。“进”就是控制谁能访问系统SSH 密钥登录、防火墙只放行必要端口、Web 应用加 WAF、数据库不暴露公网“出”就是防数据泄露服务器出方向访问控制、敏感信息加密存储、日志脱敏“内”就是横向渗透的防护最小权限原则、内网分段、堡垒机统一入口。以一台最普通的 Web 服务器为例我初始化时一定会做这几件事firewalld只放行 80/443 端口SSH 端口限制来源 IPNginx 配置里隐藏版本号、限制请求体大小、开启访问频率限制操作系统定期yum update打安全补丁安装fail2ban防止 SSH 爆破用auditd记录关键文件的变化比如/etc/passwd和/etc/shadow。这些动作有些可以写进 Ansible role做到新机器一上线就自动具备基础安全能力。4. 高可用设计笔试想拿高分必须补上的短板4.1 单点故障怎么消除负载均衡、主从、集群如果笔试题目里明确说了“系统要支撑 7×24 小时可用”那单点故障就是你必须正面回答的问题。所谓高可用说白了就是“任何一台机器挂了业务都不中断”。消除单点最基础也最常用的是这三板斧。第一入口层用负载均衡Nginx 做反向代理后面挂多台 Web 服务器一台挂了 Nginx 自动把流量分给其他机器更专业一点可以用 LVS 或云上的 SLB。第二数据层做主从复制MySQL 一主一从或者一主多从主库挂了从库可以提升为主库至少能先恢复读能力Redis 用 Sentinel 哨兵模式自动故障切换。第三无状态服务水平扩展应用服务本身不存会话数据会话放到 Redis 里这样新增机器只需要加一条 Nginx upstream不需要迁移任何东西。这套方案听起来不复杂但笔试里你能把每个环节的“为什么”解释清楚就是高分答案。比如 Nginx 后端某台机器挂了Nginx 是怎么感知的靠的是max_fails和fail_timeout的被动健康检查。那如果 Nginx 自己挂了怎么办前面再加一层 Keepalived 虚 IP或者直接交给云负载均衡。一层一层往上套这就是高可用设计的思维。4.2 故障演练从“纸上谈兵”到“真刀真枪”笔试最后如果让你写一套“上线后如何保障稳定性”的方案我建议一定要提到“故障演练”。这不是套话而是生产环境真实需要的动作。很多系统设计时看着很完美主从切换有脚本、负载均衡有健康检查、备份有定时任务但从来没验证过这些机制是否真的生效。等故障突然来了才发现脚本早就因为路径变更失效了。我印象最深的一次演练是模拟 MySQL 主库宕机。当时我们已经有了一套看似完整的主从切换方案结果演练一开始就发现写脚本的人把从库的 IP 写死在了应用配置文件里并没有走 VIP 漂移导致主库一挂应用完全连不上数据库。那一次之后我们把“每季度一次故障演练”写进了运维规范。演练内容包括随机 kill 掉一台应用服务器、拔掉一台机器的网线模拟网络分区、把数据盘写满、把主库进程停掉、强制重启每次演练都要输出一份复盘报告。笔试里你说出这些细节比背一百个命令都管用。因为阅卷人能明显感觉到你是真的做过而不是在背书。4.3 容量规划与性能调优提前为增长做准备高可用回答完“挂了怎么办”接下来就是“流量涨了怎么办”。这也是系统工程师和纯运维的另一个分水岭能不能提前判断系统瓶颈在业务增长前完成扩容。容量规划的核心方法是压测。先用工具wrk、ab、JMeter对系统做压力测试找到当前架构的瓶颈点比如 CPU 先跑满还是数据库连接数先耗尽然后针对瓶颈做优化。优化手段按性价比排序加缓存Redis、加索引、调内核参数、加机器。笔试里如果给你一个“系统响应变慢”的排查题优先怀疑顺序一般是慢 SQL → 缓存命中率低 → 连接数满 → 带宽打满 → 代码 bug。容量规划时还要看监控趋势数据。我一般会重点盯两个指标业务高峰期的 CPU 使用率和带宽使用率。如果高峰期 CPU 已经持续 70% 以上那就要开始准备扩容了别等到 90% 才动手。这里有一个经验值任何资源使用率持续超过 70%就要进入扩容评估流程超过 85%应该触发紧急扩容预案。5. 从笔试题到 Offer我的备考路径与踩坑记录5.1 知识模块怎么梳理才不会白学系统工程师的笔试范围看起来很散Linux、网络、数据库、中间件、脚本语言、云原生、安全……如果不梳理很容易今天学一点 Nginx明天看一点 MySQL最后什么都没吃透。我的建议是按“协议 → 组件 → 场景”三条线去组织知识。第一条线是协议。TCP 三次握手、四次挥手、HTTP 状态码、HTTPS 握手过程这些是理解所有上层组件的基础。第二条线是组件。Nginx、MySQL、Redis、Kafka、Zookeeper、Docker、Kubernetes每个组件都要能回答五个问题它解决什么问题核心架构是什么有哪些关键配置常见故障怎么排查有没有替代方案第三条线是场景。比如“服务响应变慢”“数据库连接数被打满”“CPU 负载飚高”“磁盘只读”每个场景都要有自己的排查手册。整理完之后一定要动手实践。只看书不敲命令笔试里的选择题也许能蒙对但大题和面试一定会露馅。我见过太多人简历上写着熟悉 MySQL结果问他怎么看慢查询日志支支吾吾说不出来。5.2 实操环境搭建用三台虚拟机模拟生产环境准备这类笔试最划算的实操方式就是自己搭一个迷你生产环境。不需要云服务器一台电脑装 VirtualBox 或 VMware开三台 CentOS 虚拟机每台 2C4G 就够组成一个小集群。我的练手项目是这样设计的一台装 Nginx Keepalived 做入口一台装应用服务随便写个 Python Flask 或者 Java Spring Boot 接口都行一台装 MySQL Redis。然后完成这些任务写 Ansible playbook 初始化所有机器手动把应用从单机扩展成双节点配置 Prometheus Grafana 监控把 MySQL 配好主从复制写一个全量备份脚本并实际执行一次恢复演练用 wrk 压测这套系统找出瓶颈。这套环境跟 B 站那种体量差了十万八千里但麻雀虽小五脏俱全所有笔试里可能考到的概念你都能在真实环境里亲手摸一遍。练完之后你再去答“从零搭建系统并做好维护”这类大题就不再是凭想象发挥了。每一步会遇到什么报错、配置参数怎么调、原理是什么你心里都有数。这种真实感是背任何面经都替代不了的。5.3 面试复盘笔试之后还会被追问什么笔试只是第一关面试时的追问才是真正拉开差距的地方。以那套题为蓝本面试官通常会往三个方向深挖方案里的细节、踩过的坑、以及对极端场景的反应。比如你在笔试里写了“用 Nginx 做负载均衡”面试官可能追问Nginx 的worker_processes和worker_connections到底怎么配upstream 的keepalive参数起什么作用如果后端有一台机器返回 502你是先查应用还是先查 Nginx这些问题没有一个标准答案考的就是你有没有真正用 Nginx 扛过线上流量。再比如你写了“MySQL 主从复制”面试官可能追问主从延迟怎么监控和解决半同步复制和异步复制有什么区别从库掉队了怎么重新同步binlog 有哪几种格式各有什么问题这些细节如果只看了几篇博客很容易被问住。我的建议是写进简历和笔试答案的每个技术点都要准备一个“如果你来做会怎么做”的完整故事。最后分享一个我自己的小习惯每次答完一道系统设计类题目我都会反问自己三个问题——这个方案挂了怎么办流量翻十倍还能扛住吗别人接手后能看懂吗这三个问题几乎能覆盖面试官 80% 的追问方向。把那套笔试题吃透再把这三个问题真正想明白系统工程师这碗饭你就能稳稳端住了。