企业官网建设流程全解析

1. 生产环境初始化这件事，为什么必须靠SOP

做Ubuntu运维和服务器管理这些年，我最大的感触就是：装系统是入门，初始化才是分水岭。很多朋友在虚拟机里装好Ubuntu，敲两行lsb_release -a，看到版本号出来就觉得自己会了。可真到了要把一台机器投入生产的那天，面对的问题完全不是这么回事。

生产环境初始化和个人电脑装系统有本质区别。个人电脑装好系统、连上WiFi、装个输入法就能用。生产环境不行，它要承载业务流量，要考虑安全基线，要考虑后续运维的标准化接口，要考虑故障出现时能不能快速定位、快速恢复。这一大堆要求如果每次靠临时想一想，靠哪位同事记得哪条命令就补哪条，结果必然是灾难。

这也是为什么“跟韩工学Ubuntu”系列到了第10章，专门拿出整整一章讲生产环境初始化标准流程（SOP）。前面那么多课时在打基础，到了第10章，就是把散落的技能点串成一条完整的生产线。而004篇作为这一章的练习题篇，干的事更具体：把你从“看懂了”推到“能上手、能复盘、能出错”的位置。

我一直认为，看教程和做练习之间的差距，就是“我以为我会了”和“我真的会了”之间的差距。看别人敲命令，跟在生产环境里自己从头初始化一台机器，是完全不同的认知体验。前者是线性阅读，后者是要做决策、踩坑、回滚、补漏的完整闭环。这一篇练习题，就是逼着你把这个闭环跑一遍。

先说清楚这篇练习题的定位：它不是课后应付式的小测验，而是严格按照一套真实生产环境初始化SOP拆出来的实操训练。每一道题背后，都对应着生产环境初始化流程里一个绕不开的环节。做完这套题，你应该能独立完成一台全新Ubuntu服务器从裸机状态到可以承接业务的全部标准动作，并且知道自己每一步在干什么、为什么这么干。

2. 先复盘：生产环境初始化SOP的标准全流程

不把SOP全貌讲清楚就上练习题，等于不教游泳直接把人扔水里。所以在做题之前，我们把韩工这章的初始化SOP主干流程先过一遍。这既是对003篇的复习，也是练习题的内容索引。

2.1 初始化SOP的分层思想

一套能落地的初始化SOP，绝不是一条命令一条命令的堆叠，而是有清晰层次的。我自己习惯把初始化分成四层：

• 基础层：系统安装、磁盘分区、内核参数、时区语言、软件源配置。这一层解决的是“机器能不能稳定运行”的问题。
• 安全层：SSH加固、防火墙规则、用户权限体系、自动更新策略。这一层解决的是“机器能不能被信任”的问题。
• 运行时层：Docker等容器运行时、日志收集、监控探针、时钟同步。这一层解决的是“业务怎么在上面跑、出事了怎么发现”的问题。
• 交付层：初始化脚本归档、基线配置导出、文档记录。这一层解决的是“以后还能不能复现、交接给下一个同事能不能接得住”的问题。

004篇练习题就是按照这个分层逻辑设计的。你做题时如果发现某道题卡住了，不要急着翻答案，先退回对应的层次去想一想：这道题考的是哪一层的能力。

2.2 每一层初始化动作的选型逻辑

光知道分几层还不够，每一层里的具体选型，背后都有讲究。

基础层最常见的争议是分区方案。生产环境我强烈建议/boot独立分区，/和/home分开，数据盘单独挂载。原因很简单：日志和用户数据如果和系统目录搅在一起，系统盘满了以后整台机器可能直接进入只读状态，业务瞬间全挂。数据独立挂载还能在系统崩溃时把数据盘拔下来插到别的机器上接着用。练习题里就会让你针对不同业务场景设计合适的分区方案，这块没有标准答案，但有明确的判断标准。

安全层最核心的是SSH和用户权限。SSH我从来不允许直接用root登录，也从来不允许使用密码登录。生产环境的密钥管理至少要做到：每个运维人员独立密钥、独立账户、按需授权。禁止共享密钥，因为共享密钥出问题的时候你根本查不出来是哪个人的操作导致了故障。练习题里有一个场景题就是围绕这个设计的。

运行时层这块，时间同步是最容易被忽略但又特别致命的一个环节。分布式系统里，日志时间戳不统一，排错的时候对不上时间线，那种痛苦我经历过一次就再也不想经历。所以chrony或ntp的配置，在练习题里专门出了一道题。

2.3 韩工这套SOP和其他教程的区别

网上讲Ubuntu初始化的文章一搜一大把，为什么韩工的教学值得专门做一套练习题？我总结下来有三个不同点。

第一是强调“为什么”而不是“怎么敲”。很多教程给你一串命令，告诉你复制粘贴就行。韩工这套SOP会解释每一条命令背后的目的，比如为什么设置vm.swappiness而不是直接关掉swap，为什么生产环境要用国内镜像源而不是官方源。练习题里很多判断题，考的就是你知不知道这个“为什么”。

第二是强调SOP的可复制性和版本管理。真正的SOP不是写在你笔记本里的备忘录，它应该是能放进git仓库、能走评审流程、能根据环境迭代的正式文档。所以练习题里有专门一道题，要求你把初始化脚本整理成带注释、带输出检查点的规范脚本，而不是一串跑完就算完事的临时命令。

第三是强调验收与回滚。很多初始化流程讲完就结束了，没有人告诉你初始化完了怎么验证每一条都生效了，出了问题怎么回滚。韩工的初始化SOP每一个阶段都有明确的验收命令和回滚策略，对应地，练习题里也有验收和回滚相关的题目。

3. 004篇练习题全解析：题目、思路与答案

下面进入正题。我把这组练习题拆成四道，从基础到综合，难度递增。每一道题都按照“题目 → 考察点 → 参考操作 → 常见错误”的结构来展开。建议你先自己动手做一遍，再来看解析。

3.1 练习题A：全新服务器的环境信息采集与基线确认

题目内容：

你拿到一台全新的Ubuntu 22.04 LTS服务器，系统已安装完成，尚未做任何配置。请写出一组命令，完成以下信息采集：

• 操作系统版本和内核版本
• CPU核数、内存大小、磁盘分区与剩余空间
• 系统默认语言、时区、当前时间
• 是否已启用SSH服务，监听的端口是什么
• 已安装的软件包总数

考察点：

这道题看起来简单，但实际非常关键。生产环境初始化的第一步不是改配置，而是摸清现状。很多人上来就改SSH、换源，结果改了以后发现系统里装了不该装的东西、磁盘空间根本不够、时区还是UTC导致日志时间对不上，来回返工。

参考操作：

# 版本与内核信息 lsb_release -a uname -a # CPU与内存 lscpu free -h # 磁盘分区与使用率 lsblk df -hT # 语言与时间 locale timedatectl # SSH服务状态与监听端口 systemctl status ssh ss -tlnp | grep ssh # 软件包数量（dpkg方式统计） dpkg --list | wc -l

到这里还没完，生产环境的信息采集必须形成一份基线记录。我建议把这些输出重定向到一个文件里，跟上主机名和时间戳，存档备用：

mkdir -p /root/system-baseline { echo "===== 主机名 =====" hostnamectl echo "===== 内核与版本 =====" lsb_release -a uname -a echo "===== 硬件资源 =====" lscpu free -h lsblk df -hT echo "===== 时间与语言 =====" timedatectl locale echo "===== SSH监听状态 =====" ss -tlnp | grep ssh || echo "SSH未监听" } > /root/system-baseline/$(hostname)-baseline-$(date +%F).txt

常见错误：

这道题最常见的错误就是只采集了自己“想得到”的信息，而不是按照一套固定模板去采集。生产环境初始化最忌讳想起一出是一出。所以韩工在流程里反复强调，信息采集也要模板化。你可以不抄我上面的命令，但一定要提前准备好自己的采集清单，这是SOP意识的第一课。

3.2 练习题B：编写一键初始化脚本（含软件源替换、系统更新、基础工具安装）

题目内容：

请编写一个 Bash 脚本/root/init/init_base.sh，要求实现以下功能：

• 自动判断当前用户是否为 root，非 root 则退出并给出提示
• 将软件源替换为国内阿里云镜像源（以 Ubuntu 22.04 为例）
• 执行apt update和apt upgrade -y
• 安装基础工具包：vim、curl、wget、git、tree、htop、net-tools、chrony
• 每一步执行后检查上一条命令是否成功，失败则记录错误日志并退出
• 脚本结束后输出“初始化完成”和基础工具版本号

考察点：

这道题考的是自动化能力和脚本规范性。生产环境初始化不能每次靠手工一条一条敲命令，你必须把重复动作固化成脚本，而且要保证脚本可追溯、可复用、可排错。

参考操作：

#!/bin/bash #============================================= # 文件: init_base.sh # 功能: Ubuntu 22.04 基础环境初始化 # 用法: sudo bash init_base.sh #============================================= set -u # 变量未定义时报错 LOG_FILE="/var/log/init_base.log" ERROR_FLAG=0 # 检查root权限 if [ "$(id -u)" -ne 0 ]; then echo "[错误] 请使用root用户或sudo运行此脚本。" | tee -a "$LOG_FILE" exit 1 fi # 备份并替换软件源 echo "[1/4] 替换软件源..." if [ -f /etc/apt/sources.list ]; then cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F) fi cat > /etc/apt/sources.list <<EOF deb https://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse EOF if [ $? -ne 0 ]; then echo "[错误] 软件源替换失败。" | tee -a "$LOG_FILE" exit 1 fi # 更新与升级 echo "[2/4] 更新软件源与升级系统..." apt update >> "$LOG_FILE" 2>&1 || { echo "[错误] apt update失败。" | tee -a "$LOG_FILE"; exit 1; } apt upgrade -y >> "$LOG_FILE" 2>&1 || { echo "[错误] apt upgrade失败。" | tee -a "$LOG_FILE"; exit 1; } # 安装基础工具 echo "[3/4] 安装基础工具..." apt install -y vim curl wget git tree htop net-tools chrony >> "$LOG_FILE" 2>&1 || { echo "[错误] 基础工具安装失败，请检查网络或软件源。" | tee -a "$LOG_FILE" exit 1 } # 输出完成信息 echo "[4/4] 初始化完成。" echo "关键工具版本信息：" vim --version | head -1 curl --version | head -1 git --version chronyd --version

常见错误：

这道题的高频翻车点有三个。

第一个是apt upgrate拼写错误（正确是upgrade），这种低级错误在手工敲命令时可能很容易发现，写进脚本里就不一定了，尤其是脚本一长、输出刷屏的时候。所以要养成脚本里每条命令后检查返回码的习惯，这个脚本里用了|| {}的方式，就是出于这个目的。

第二个是忘了在脚本开头设置set -u或类似的安全选项。脚本里如果用了未定义的变量，默认情况下Bash会把它当空字符串继续跑，这在生产环境里可能引发很难排查的诡异问题。set -u的作用就是让未定义变量直接报错退出。

第三个是软件源配置写死成jammy版本。这个脚本只适用于Ubuntu 22.04，如果你拿到的是24.04，源地址要替换成noble。更稳妥的做法是在脚本里先读取系统版本，再动态生成源，类似下面这样：

. /etc/os-release echo "deb https://mirrors.aliyun.com/ubuntu/ ${VERSION_CODENAME} main restricted universe multiverse" > /etc/apt/sources.list

这样脚本的兼容性会好很多。练习题只要能跑通就行，但生产环境里我强烈建议你做成动态的。

3.3 练习题C：SSH安全加固与sudo权限配置

题目内容：

完成以下安全配置：

• 禁止root用户通过SSH登录
• 禁止SSH密码登录，仅允许密钥登录
• 新增运维用户deploy，加入sudo组，并为其配置SSH密钥登录
• 修改SSH默认端口为 22822
• 配置防火墙，仅放行 22822 端口和 80/443 端口
• 重启SSH和防火墙服务，并验证配置生效

考察点：

这道题是安全层的核心实战。生产环境的SSH入口如果裸奔，被扫到弱口令爆破基本是迟早的事。这道题要完成的不仅是一堆命令，而是一整套“最小暴露面”的安全思路。

参考操作：

# 1. 创建deploy用户并加入sudo组 useradd -m -s /bin/bash deploy usermod -aG sudo deploy passwd deploy # 2. 切换至deploy用户，创建SSH密钥对 su - deploy ssh-keygen -t ed25519 -C "deploy@production" -f ~/.ssh/id_ed25519 touch ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys exit # 3. 编辑SSH服务端配置 /etc/ssh/sshd_config # 修改以下配置项： # Port 22822 # PermitRootLogin no # PasswordAuthentication no # PubkeyAuthentication yes # 注意：改Port前先把22822端口在防火墙放行，不然有可能把自己锁在门外 sudo sed -i 's/^#\?Port.*/Port 22822/' /etc/ssh/sshd_config sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config sudo sed -i 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config # 4. 检查配置语法 sudo sshd -t # 5. 重启SSH服务（CentOS用sshd，Ubuntu用ssh） sudo systemctl restart ssh # 6. 配置防火墙 sudo ufw allow 22822/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status

常见错误：

这道题翻车率相当高，我几乎每次带人都能碰到类似事故。最典型的是改完SSH配置直接重启，没先跑sshd -t检查语法，结果某个配置项写错，SSH直接起不来。这时候如果人在机房还有救，远程操作就只有哭的份了。

另一个典型问题是防火墙把自己锁在外面。ufw默认规则是拒绝所有入站流量，你先把SSH端口改了，但防火墙只放行了22，重启防火墙以后22和22822都不通，这台机器就在你面前但你就是连不进去。所以操作顺序很重要：先放行新端口，再改SSH配置，最后启用防火墙。

还有一个细节是密钥的权限。authorized_keys、.ssh目录、私钥文件的权限如果不对，SSH服务端会直接拒绝用这个密钥。我做这次练习时故意把chmod命令漏掉一次，就是想提醒自己权限问题100%会发生。

3.4 练习题D：综合场景题——独立设计一套生产环境初始化SOP

题目内容：

某公司采购了一台新服务器，规划用于部署一个Nginx反代和多个Spring Boot应用。系统为Ubuntu 22.04 LTS，硬件配置为8核16G内存、1块512G SSD系统盘、1块2T HDD数据盘。请你：

• 给出磁盘分区方案
• 给出时区、时间同步、主机名修改方案
• 给出Docker及Docker Compose安装方案
• 给出Swap设置建议
• 给出日志切割策略

考察点：

这道题没有固定答案，考的是综合决策能力。生产环境初始化永远没有放之四海而皆准的“标准答案”，只有针对具体场景的最优解。这道题就是让你模拟一次真实的方案设计。

参考设计思路：

磁盘分区上，512G SSD我会采用LVM布局，/分配100G，/boot分配2G，swap分配8G，剩余空间留给/var和/home的逻辑卷。2T HDD单独分区挂载到/data，用于存放应用数据和日志。SSD跑系统和应用，HDD存数据，这是很经典的分层方案。

Swap设置上，16G物理内存的机器，swap给8G比较合理。韩工在课程里提醒过很多次，不要完全关掉swap。有些优化教程说关swap能提升性能，那是针对特定数据库场景的，通用业务跑着跑着内存飙上来，没有swap做缓冲，OOM Killer直接杀进程，那酸爽不想体验第二次。

时间同步用chrony，配置国内NTP服务器地址，这个没什么争议。主机名建议按“业务-环境-序号”的规则命名，比如nginx-prod-01，不要用意义不明的ubuntu-server-2这种，运维场景下主机名就是机器识别的第一标签。

Docker安装我倾向于使用官方脚本加国内镜像加速器组合。这里有个易错点：Docker CE在Ubuntu上默认源是官方源，国内服务器如果直接用官方源安装成功率不高，一定要先换源再装。

日志切割用logrotate，生产环境的日志不切割，一个月就能把磁盘吃干净。按天切割、保留30天、压缩旧日志，这套配置要写进SOP。

这道题做完之后，建议再做一个动作：把你的方案写成一页纸文档，然后找身边有经验的人帮你评审。方案设计能力不是靠背命令练出来的，是靠方案被批评、被质疑练出来的。

4. 做这套练习题时最常踩的坑与排查方法

练习题做完对答案只是第一步，更值钱的是从错误中提炼出排查经验。下面几个坑是我从大量练习者反馈和自己实操中总结出来的高发问题，做个速查整理。

4.1 SSH端口修改后无法连接

症状：运维人员修改Port后重启ssh服务，再用新端口连接时提示Connection refused或超时。

排查步骤：

• 先确认sshd进程是否在监听新端口：ss -tlnp | grep ssh
• 确认防火墙是否放行：ufw status
• 确认云服务器的安全组规则是否同步放行新端口
• 如果是在虚拟机里，确认是否有外部防火墙或NAT转发在干扰

这里插一个经验：修改SSH端口在生产环境里不是必须操作。如果你把SSH暴露在公网上，改端口确实能挡掉一部分扫描流量，但真正解决安全问题的还是密钥登录禁root这些硬措施。端口从22改成22822，在fail2ban等工具面前意义不大，因为它记录的是IP而不是端口。所以这道题的重点不是让你推广改端口，而是让你掌握改端口后全链路连通性检查的思路。

4.2 apt update失败或速度极慢

症状：执行apt update时长时间卡住，或者报错提示无法解析、连接超时。

排查步骤：

• 先确认网络：ping mirrors.aliyun.com
• 检查DNS：cat /etc/resolv.conf
• 检查源配置是否有低版本（bionic/cosmic等）与系统版本不匹配
• 确认是否有代理环境变量干扰：env | grep -i proxy

Ubuntu的apt源配置在不同版本上有差异。22.04及以前主要用/etc/apt/sources.list；24.04开始引入了/etc/apt/sources.list.d/ubuntu.sources这种deb822格式的文件，两者语法不一样。如果你拿老教程的命令直接改24.04的源，大概率不生效。这个版本差异在韩工的课程里专门强调过，也是练习题里容易踩坑的地方。

4.3 chrony时间同步状态异常

症状：chronyc tracking显示Leap status不是Normal，或者System time偏差过大。

原因排查：

• 检查chrony是否正常运行：systemctl status chrony
• 检查防火墙是否放行UDP 123端口
• 确认NTP服务器的域名解析是否正常
• 检查是否有其他时间同步服务（如systemd-timesyncd）在抢占

Ubuntu默认可能带着systemd-timesyncd，如果你装完chrony但没禁用前者，两个服务会打架。正确做法是安装chrony后主动停用并屏蔽systemd-timesyncd服务，然后重启chrony。这个问题不做一遍实操根本意识不到，我当年也是看了好几天日志才发现。

4.4 练习题里最容易被忽视的三个小点

结合我自己做题和带人的经验，有三处细节是大多数人第一次做这套题都会忽略的。

第一，hostnamectl set-hostname改完主机名以后，/etc/hosts里也要同步修改。很多服务靠主机名做本地解析，/etc/hosts里的老主机名不更新，某些服务会解析出错误地址，排错时极其迷惑。

第二，ufw默认的sshd规则是允许22端口，你改了SSH端口后，旧的22端口放行规则还留在防火墙里。虽然无害，但修整一下更干净。可以在/etc/ufw/user.rules里清理，或者直接ufw delete allow 22/tcp。

第三，练习脚本里的apt upgrade在生产环境的执行策略要谨慎。大版本升级、内核升级可能在重启后引入不兼容问题。很多生产环境的策略是只执行apt update并升级安全补丁，不主动做全量upgrade，或者升级前先在测试环境验证。你的练习题可以全量升级，但心里要清楚这两者的区别。

5. 练习题的隐藏价值：把SOP变成身体记忆

很多人误解练习题的作用，以为做题只是为了验证“我学会了”。实际上，这套004篇练习题的真正价值，是把SOP从一份文档变成你的身体记忆。

怎么理解这件事？你第一次照着SOP初始化一台机器，每一个步骤都要查文档、看命令、确认参数，动作很慢；第二次做，稍微快一点；等到你独立做完这套练习题的四个场景，再次拿到一台新服务器时，你脑子里会自然浮现出下一步该做什么、上一步的结果怎么验证、哪一步容易出错、出错以后去哪儿排查。这个过程就是把显性知识内化成隐性能力的过程。

我见过太多运维新人拿着网上零散的教程东拼西凑，今天学一条命令，明天看一个配置文件，知识是碎片化的，遇到真实环境立刻不知所措。而系统做一套题，等于在脑子里搭好了一个框架，之后遇到任何新环境，你只是往框架的不同位置补内容，而不是推倒重来。

韩工的课把练习题放在整章的最后，这个编排很刻意。前面的课程给了你砖块、水泥、图纸，练习题是让你亲手把房子盖一遍。盖的过程中你才会发现哪些砖块是缺损的，哪些水泥配比不对，哪些图纸标注意思不明。发现这些问题，恰恰是这门课最重要的收获。

这套题做完以后，我个人建议你找个不用的虚拟机，从头再跑一遍完整流程，但这次不看任何参考材料，完全凭记忆写脚本、做配置。跑完了再对照标准SOP逐项检查。你很快就会发现自己漏了防火墙的某条规则，或者忘了配置日志切割，或者时区没改过来。这些漏项就是你现在最需要补的短板。

生产环境初始化看着是脏活累活，不如写业务代码有成就感，但它是整个运维体系的基石。一台没有初始化好的机器，后续无论部署什么业务都会埋雷。基础不牢，地动山摇，这句话放在服务器初始化上，一点都不过分。