企业官网建设流程全解析

去年帮学弟整理秋招真题时，又把哔哩哔哩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 和吞吐需求选择”这个逻辑。

基础环境初始化是所有后续步骤的地基。很多人上来就装业务软件，结果系统参数没调，过两天服务一上线就出问题。我一般会把初始化分成六步，每一步都有明确目的：

1. 系统安装与分区：/boot给 1G，/和/data分开放，避免业务数据把系统盘写满。
2. 配置时间同步：用 chrony 或 ntpdate，确保所有机器时间一致，否则日志排查和分布式事务都会出问题。
3. 调整内核参数：vm.swappiness=10，net.core.somaxconn=65535，fs.file-max=1000000这些是基础；如果是数据库机器，还要调vm.dirty_ratio和vm.dirty_background_ratio。
4. 创建普通用户并配置 sudo：不要整天用 root 操作，至少要留审计线索。
5. SSH 安全加固：禁止 root 直接登录、禁止密码登录、使用密钥认证、修改默认端口（至少不要裸奔 22 端口）。
6. 配置统一 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 Exporter，Exporter 暴露/metrics接口，Prometheus 定期拉取；存储层就是 TSDB 时序数据库；展示层用 Grafana，画 CPU、内存、磁盘、网络、QPS、延迟这些面板；告警层通过 Alertmanager 把告警推送到钉钉、企业微信、邮件或者 Webhook。

但这里有一个新人特别容易踩的坑：告警规则写得太糙。比如“CPU 使用率超过 80% 就告警”，听起来没毛病，实际上生产环境 CPU 长期跑在 80% 以上但业务很稳的情况多的是。如果告警天天响，大家就会麻木，最后真出大事也没人看。我后来学乖了，告警规则一定是和 SLO 挂钩的，比如“Nginx 5xx 比例连续 5 分钟超过 1%”才告警，而不是只盯单一资源指标。

日志这块，生产环境最少要满足三个要求：采集、集中存储、便于检索。以前我在小公司就是tail -f /var/log/messages，出问题了逐台机器翻日志，效率极低。后来上了 ELK（Elasticsearch + 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 端口限制来源 IP；Nginx 配置里隐藏版本号、限制请求体大小、开启访问频率限制；操作系统定期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% 的追问方向。把那套笔试题吃透，再把这三个问题真正想明白，系统工程师这碗饭，你就能稳稳端住了。