Linux运维三天实操：环境搭建、系统部署与命令排查

1. 为什么我建议所有人都该系统过一遍 Linux 运维基础

先问一个问题：你手头有没有一台不带图形界面的服务器？如果有，你大概率已经体验过那种“两眼一抹黑”的感觉——鼠标用不了，桌面找不到，连个文件都靠敲命令。这就是 Linux 运维最真实的日常，也是我这次用三天时间从零搭建、部署、排错之后最想跟你分享的东西。

我做运维也有几年了，这几年带过不少新人，也帮朋友应急处理过几台出问题的服务器。我最大的感受是：很多人不是不想学 Linux，而是被“命令太多记不住”“环境总配不好”“出了问题不知道从哪查”这三座大山给劝退了。这篇文章不是一本教科书，也不是命令大全的搬运工，而是把我这次从环境准备、系统安装到基础命令实操的完整过程，包括踩过的坑、调整过的策略，一条条梳理出来。你如果愿意按照这个顺序走一遍，三天时间足够让你对 Linux 运维建立起一个真正能落地的操作框架。

这篇文章适合谁？零基础但想转运维的新人，被分配了服务器但不知从何下手的开发同学，以及准备考运维相关认证、需要补实操的求职者。文章里我不会堆砌太多理论，尽量用“我做了什么、为什么这么做、做完效果如何”的方式来说，这样你复现的时候心里更有底。

2. 三天从哪里开始：整体思路与环境准备

2.1 先想清楚这三天的学习主线

拿到“三天实操”这个目标之后，我没有直接去敲命令，而是先把整体路线拆成了三段。第一天的核心是“把环境跑起来”，包括虚拟机或者物理机的准备、操作系统的选择、安装过程中的分区和网络配置；第二天的核心是“做一次完整的系统部署”，我会实际部署一个 Nginx 服务，再配合 MySQL、Firewall 这些日常运维绕不开的组件，把部署流程走通；第三天的核心是“基础命令的实战强化”，但不只是背命令，而是按“文件操作、用户权限、网络排查、日志分析”几个高频场景去练。

这个顺序看着简单，但背后是有逻辑的。环境搭建解决的是“你手头有没有可用的机器”，系统部署解决的是“你怎么把业务跑起来”，基础命令则贯穿整个运维生命周期。很多人一上来就背命令，背得挺熟，结果让他部署一个服务就卡住，就是因为缺少中间那层“把命令串成流程”的训练。反过来，如果只学部署不练命令，出了问题连日志都找不到在哪儿，也很被动。所以这三天的内容是一条完整的链路，不建议跳着看。

2.2 虚拟机与云服务器：两个方向怎么选

做环境搭建，第一步是解决“机器从哪来”。我这次为了尽量模拟真实的生产环境，用了两套方案：本地用 VMware Workstation 搭虚拟机，同时在一台云服务器上走了一遍相同的过程。这样对比下来，两个方向的差异就很明显了。

虚拟机的好处是免费、可控、随便折腾。装坏了快照一恢复，继续练。适合练习系统安装、分区、Grub 引导这类操作，因为你可以反复重来而不用承担任何成本。缺点是你的笔记本性能会限制虚拟机配置，如果你机器只有 8G 内存，同时跑图形界面和虚拟机就会比较吃力。

云服务器的好处是配置就绪、网络真实。你买的云主机一般都已经装好了系统，直接 SSH 连上去就能用。部署 Nginx、Mysql、调整防火墙规则的时候，体验跟生产环境基本一致。缺点是费用会一直跑着，而且你没法练到“从裸机到装系统”这一层。所以我的建议是：有条件的两个都准备，一个负责练手一个负责跑服务；如果只能选一个，我更推荐先把虚拟机玩明白，因为那部分经验在云主机上补不回来。

提示：第一次做实验，虚拟机磁盘建议给 40G 到 60G，内存给 2G 到 4G，CPU 给 2 核就够了。太大的配置不仅跑不动，还会让后续的安装过程变得很慢，没必要。

2.3 系统版本选择：CentOS 停更之后，我在用什么

前几年聊到 Linux 运维，大家默认的首选都是 CentOS 7。但 CentOS 7 在 2024 年 6 月正式停止维护了，CentOS Stream 又是滚动发行版，不适合求稳的生产环境。这次我做实验的时候，在系统选型上特意做了调整：本地练习我选了 Ubuntu 24.04 LTS，云服务器上用了 Debian 12。这里说说我的考量。

Ubuntu 的生态对新手非常友好，出了问题几乎都能在网上搜到答案，软件源和桌面管理也做得省心。Debian 则更克制，默认安装非常干净，没有太多多余的服务占资源，适合用来模拟生产服务器的“清淡”状态。这两个系统都属于 Debian 系，命令习惯一致，从一个切到另一个几乎没有学习成本。如果你后续要学红帽系（Rocky Linux、AlmaLinux），命令上会有一点差异（比如包管理是 dnf/yum，防火墙是 firewalld），但底层的文件结构、权限模型、进程管理思想完全一致，不影响你已经建立的运维框架。

如果你问我为什么不用最热门的 Ubuntu Desktop 做本地练习而选 Server 版，原因很简单：运维阶段跟桌面打交道的机会本来就少，Server 版不装图形界面，能逼着你从一开始就适应命令行工作流。桌面环境可以后面需要的时候再单独装，但一开始就走命令行的路径，后面的效率会高很多。

2.4 搭建虚拟机环境的完整步骤

虚拟机环境搭建这部分，我按自己的实操过程整理成一份可以直接照做的清单。这里我以 VMware Workstation 17 为例，如果你用的是 VirtualBox，操作逻辑是一样的，只是菜单位置略有不同。

1. 下载 Ubuntu 24.04 LTS Server 版 ISO 镜像。官网下载就行，注意选“Server install”而不是“Desktop”，原因前面说过。
2. 在 VMware 中新建虚拟机，选择“典型（推荐）”安装类型。操作系统选择“Linux”，版本下拉选择“Ubuntu 64 位”。
3. 配置虚拟硬件：内存建议 2048 MB 起，我这个实验给了 4096 MB；处理器给 2 核；磁盘选“创建新虚拟磁盘”，大小给 40GB，并勾选“将虚拟磁盘存储为单个文件”，性能和移动性都更好。
4. 虚拟机创建完成后，先别急着启动，在“虚拟机设置”里把 ISO 镜像挂载到 CD/DVD 光驱，并勾选“启动时连接”。
5. 启动虚拟机，进入系统安装界面。Ubuntu Server 的安装器是全图形化引导的，虽然没桌面，但可以用方向键和回车操作，不用怕。

这里有个经验值得单独说一下：安装过程中，语言建议选“English”，不要选中文。因为 Linux 服务端的报错信息绝大多数是英文，你如果一开始用中文环境，遇到日志输出全是英文会比较懵。英语不好的朋友也别担心，报错信息翻来覆去就那些关键词，看几天就熟了。后续想要中文支持，可以装完系统后再安装语言包，不影响操作。

2.5 安装过程中的网络配置与分区思路

Ubuntu Server 安装器会自动配置 DHCP 获取 IP，你装完系统先别管它，等部署阶段再改成静态 IP。但有一个地方你最好在安装过程中就确认一下——网卡名称。现在的 Ubuntu 用的是类似 ens33、ens160 这样的名字，不是老教材里的 eth0。记下这个名字，后面配置静态 IP、防火墙规则的时候都要用到。

分区这里，新手最容易纠结，我来把逻辑讲清楚。默认的分区方案（使用整个磁盘并设置 LVM）其实很合理，它能帮你在以后空间不够的时候通过扩容逻辑卷来增加容量，不用重新分区。所以我的建议是：初次安装直接使用默认分区即可，不用手动折腾。如果你有特殊需求，比如要单独挂载 /data 做数据盘，可以等熟悉之后再重新规划。实验阶段，一台机器的主要任务是让你跑通流程，分区越简单越好。

安装完成后系统会自动重启，重启后你会看到登录提示符。输入安装时设置的用户名和密码，你就进入了第一个真实的命令行环境。到这里，环境搭建这个任务就完成了一大半。接下来要做的第一件事，不是急着装软件，而是先执行一条命令：sudo apt update && sudo apt upgrade -y。这一步会把软件源缓存刷新，并把系统自带的软件包升级到最新，避免后续因为依赖包版本老旧导致各种莫名其妙的报错。

3. 系统部署实战：把一个服务真正跑起来

3.1 静态 IP 配置：为什么不用 DHCP 跑生产

环境装好之后，下一步要做的是给服务器配置静态 IP。你在虚拟机里装完系统，默认用的是 DHCP 自动获取地址，这意味着你的 IP 每次重启都可能变化。在实验环境还好，但如果你要模拟一个长期运行的服务器，IP 地址不稳定是非常痛苦的——你今天 SSH 连的是 192.168.1.100，明天重启变成了 192.168.1.110，配置文件里写死的地址全部失效。

Ubuntu 24.04 的网络配置跟老版本不一样，它不是直接改 /etc/network/interfaces，而是使用 netplan 工具，配置文件在 /etc/netplan/ 目录下，一般是 50-cloud-init.yaml 或 99-config.yaml。我的操作方式是这样：

先用 ip addr 查一下当前网卡的名字，记下来。然后编辑 netplan 配置文件：

bash复制sudo vim /etc/netplan/99-config.yaml

内容参考如下，注意缩进必须用空格，不要用 Tab：

yaml复制network:
  version: 2
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 223.5.5.5
          - 119.29.29.29

这里 192.168.1.100 是我的虚拟机地址，192.168.1.1 是我的路由器网关，DNS 用的是国内公共 DNS。你实际配置的时候，地址段要根据你本地的网段来调整。改完之后执行：

bash复制sudo netplan apply

再执行 ip addr 确认地址是否生效。这里有一个小坑：如果你是通过 SSH 远程连接的，改了静态 IP 之后当前会话会断掉，你得用新 IP 重新连接。如果是虚拟机本机操作，直接重新登录就行。

注意：netplan 配置文件的缩进错了会导致 apply 失败，报错信息会提示语法错误。这时候别慌，用 sudo netplan try 可以先测试，如果配置有问题它会自动回滚到之前的配置，给你一个反悔的机会。这个命令比直接 apply 更安全，强烈建议每次改完网络都先试一下。

3.2 Nginx 部署：从安装到页面显示的全过程

Nginx 是运维工作中打交道最多的 Web 服务器之一，拿它来做第一次系统部署练习很合适。安装非常简单：

bash复制sudo apt update
sudo apt install -y nginx

装完以后，先确认一下服务的状态：

bash复制systemctl status nginx

如果看到 active (running) 的绿色字样，说明服务已经跑起来了。这时候你打开浏览器，输入虚拟机的 IP 地址，正常会看到 Nginx 的默认欢迎页。

但这里往往就会遇到第一个问题——页面打不开。我这次在云服务器上部署的时候就遇到了。排查思路按顺序来：先看服务活着没，用 systemctl status；再防火墙，Ubuntu 和 Debian 默认装的防火墙是 ufw，你可以先查看规则：

bash复制sudo ufw status

如果是 inactive，说明防火墙没启用，那就不是它的问题。再继续查，可能是云服务商的安全组没有放行 80 端口，这个得去云控制台里设置。如果用的是 VMware 虚拟机，则可能是虚拟机网络模式的问题，NAT 模式下宿主机访问虚拟机 IP 一般是通的，桥接模式则需要保证 IP 在同一网段。

排查到这里你就会发现，运维里最难的不是装软件，而是顺着请求链路一层层找问题。这个技能没办法靠背命令学会，只能靠实际踩坑来积累。这也是为什么我强调“实操”的原因，看十篇教程不如自己把服务部署一遍、再故意把防火墙打开、再把安全组关掉，亲眼看看每一种故障长什么样。

3.3 MySQL 安装与基础初始化

接下来部署 MySQL。这里我要特别提醒一下：不要用 apt install mysql-server 一把梭，因为在 Ubuntu 24.04 上，你通过 apt 直接装到的可能是 MySQL 8.0，但部分发行版默认装的是 MariaDB 的兼容包，装错会导致后续行为不一致。更稳妥的做法是，先明确你要装的是 MySQL 还是 MariaDB，再选择对应的安装源。我这次用 MySQL 官方源装的 8.0 版本，步骤也不复杂。

先去 MySQL 官网下载对应的 apt 仓库配置包：

bash复制wget https://dev.mysql.com/get/mysql-apt-config_0.8.33-1_all.deb
sudo dpkg -i mysql-apt-config_0.8.33-1_all.deb

安装过程中会弹出一个图形化选择界面，默认选项就是 MySQL 8.0，直接回车确认即可。然后更新源并安装：

bash复制sudo apt update
sudo apt install -y mysql-server

安装过程中会要求你设置 root 密码。为了安全，root 默认只允许本地登录，这是正常的，别慌。装完以后建议执行一下安全初始化脚本：

bash复制sudo mysql_secure_installation

这个脚本会引导你设置密码强度策略、移除匿名用户、禁止 root 远程登录、删除测试数据库。初次部署的时候建议全部选择 yes，安全无小事，尤其是你后面可能真把这台机器用作生产环境。配置完成后，用 root 登录验证一下：

bash复制mysql -u root -p

如果登录成功，并能在 MySQL 命令行里执行 show databases; 看到系统自带的几个库，那么这个环境就算部署成功了。

3.4 防火墙与 SSH 加固：部署完成前必做的两件事

系统部署到这个阶段，服务已经能跑了，页面也访问通了，但离“可以交付”还有最后两步：防火墙规则和 SSH 安全加固。这两件事不好好做，后面被人扫描爆破，你会非常被动。

先配置 ufw。Ubuntu 的 ufw 用起来比较直觉：

bash复制sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

注意顺序——先把 SSH 和 Nginx 的端口放行了，再启用防火墙，避免把自己锁在外面。如果你在云服务器上操作，尤其要注意：云平台的安全组相当于外层的“总闸”，系统内的 ufw 是内层的“门禁”，两边都要放行对应端口才能访问。

SSH 加固这里，我的做法是修改 SSH 配置文件：

bash复制sudo vim /etc/ssh/sshd_config

重点改这几个参数：

• Port 62222：把默认的 22 端口换成不常用的端口，能挡住 99% 的自动化扫描攻击
• PermitRootLogin no：禁止 root 直接 SSH 登录，日常操作用普通用户加 sudo 就够了
• PasswordAuthentication no：如果已经配置了 SSH 密钥对，建议直接禁用密码登录，这是最有效的防爆破手段

改完之后重启 SSH 服务：

bash复制sudo systemctl restart sshd

重要：如果你远程连接，修改 SSH 配置之前一定要确认密钥登录已经可用，并且当前连接不要断开。我见过太多人改了配置、重启服务之后发现密钥没配对，自己被自己锁在门外的惨案。稳妥起见，可以先开一个额外的 SSH 会话测试新配置能登录，再断开旧会话。

4. 基础命令实战：按场景学比背命令清单高效得多

4.1 文件与目录操作：最常用但最容易出错的几个命令

系统部署完成之后，第三天的主线就是基础命令。我看过很多新人整理的命令清单，一列能列一两百个，看着很努力，但真到用的时候都想不起来。我自己带人的经验是：不要按字母表背命令，而是按“场景”来学。你在什么场景下用哪些命令，这些命令之间存在什么配合关系，弄明白这个，才能形成真正的肌肉记忆。

文件和目录操作是运维的基础中的基础。这个场景里最高频的三个命令是 ls、cd、find。ls 大家都会用，但很多人不知道 -lh 这个组合参数，它能把文件大小显示成可读的 K/M/G，而不是一长串字节数。find 是排查问题的利器，比如你要找一个占用磁盘空间的日志文件：

bash复制find / -name "*.log" -size +100M

这条命令会从根目录开始查找所有大于 100M 的 .log 文件，定位日志爆盘的元凶就是瞬间的事。另外还有一个高频操作是 du，如果你想看某个目录下每个子目录占了多少空间，用：

bash复制du -sh /var/log/*

它会列出 /var/log 下每一项的大小，一眼就能看出谁在“吃”磁盘。这三个命令配合起来，基本能覆盖日常 80% 的文件操作需求。

4.2 用户与权限：为什么 chmod 777 是灾难

用户和权限这块，我要单独拎出来说一说。很多新手一遇到权限报错，第一反应就是 chmod 777，这个习惯非常危险。777 意味着所有用户都有读、写、执行的权限，在单机实验环境里看起来没事，但如果这台机器暴露在网络上，任何人都能修改你的文件——这等于把家门钥匙复制给全楼的人。

理解权限之前，先要分清楚文件和目录权限的区别。文件权限的 rwx 很好理解：读、写、执行。但目录的权限逻辑不一样，目录的 r 权限决定你能不能列出目录内容，w 权限决定你能不能在这个目录里创建或删除文件，x 权限决定你能不能进入这个目录。你如果没有目录的 x 权限，就算有 r 权限也进不去。这也是为什么有时候你会遇到“明明这个文件权限没问题，但就是访问不了”的情况——问题出在上层目录的权限上。

掌握用户和权限管理的核心命令组合是：useradd（创建用户）、usermod（修改用户）、passwd（设置密码）、chown（修改属主）、chmod（修改权限）、groupadd（创建组）。实际运维中，最常见的操作是给某个用户分配指定目录的管理权限，这时候你要明白“属主、属组、其他用户”三层权限模型，再用 chown 把目录交给对应用户，用 chmod 精确控制权限位。少用 777，多用 750、640 这类具体的权限组合，你会安全很多。

4.3 网络排障命令四件套：ping、ip、ss、curl

网络故障排查，是运维里最考验功力的部分。我遇到过的情况五花八门：页面打不开、数据库连不上、服务器响应超时、域名解析失败。每一步都要靠命令去定位。这个场景里，我最常用的命令有四个。

ping 用来测连通性。能 ping 通，说明网络链路是通的；ping 不通，要么是本机网络配置问题，要么是对端防火墙拦截了 ICMP 协议。注意：ping 不通不等于服务不通，有些服务器会禁 ping，但 HTTP 服务正常。

ip addr 查看本机 IP 和网卡状态。这个前面已经说过，配静态 IP 的时候就要用到。

ss 是我排查端口问题时最常用的命令。老一点的教程会让你用 netstat，但现代系统里 ss 的信息更准确、速度更快。想查看某个端口是否在监听：

bash复制ss -tlnp | grep 3306

这个命令会显示所有监听中的 TCP 端口，配合 grep 过滤出你关心的端口号。能在这个列表里看到 3306，说明 MySQL 服务在跑，监听地址也正常；如果看不到，说明服务没起来、或者配置的监听地址不对。

curl 用来做应用层的测试。比如你要确认本机的 Nginx 配置是否生效，直接：

bash复制curl -I http://localhost

它会返回 HTTP 响应头，看到 200 OK 就说明服务正常，看到其他状态码，再按状态码去排查原因。这四个命令的组合，基本能让你定位到“网络层、端口层、应用层”这三个维度中的哪一个出了问题。

4.4 日志分析思路：从 systemctl 到 journalctl 的完整链条

最后说日志。运维里有一句老话：日志不会骗人，但你要知道去哪儿看。我在给排障新人培训的时候，一定会让他们先学会三件事：怎么看服务状态、怎么看服务日志、怎么看系统日志。

服务状态用 systemctl status，这个前面已经讲过。服务日志在 systemd 系统里统一用 journalctl 管理，比如查看 Nginx 最近的日志：

bash复制journalctl -u nginx --since "1 hour ago"

这个命令会显示系统启动后一小时内的 Nginx 相关日志，包含错误和正常启动信息，排错的时候非常有用。如果你想看更底层的系统日志，比如内核报错、硬件识别信息，用 dmesg 或者 journalctl -k。

日志分析最忌讳的就是眉毛胡子一把抓。我的经验是：先按时间缩小范围，再按关键字精确过滤，最后才逐条读内容。比如，服务昨天还能启动今天不行了，那就把日志时间范围先切到昨天，再 grep ERROR 关键词，基本上就能快速定位到问题。掌握这个思路，比记住 100 个日志命令更管用。

5. 常见问题与排查技巧实录

5.1 实际问题一：虚拟机网络连接不断重连

做实验的第一天，我遇到了一个很典型的问题：虚拟机启动后可以正常上网，但没几分钟，SSH 就会突然断掉，重连之后过一会儿又断。一开始我以为是 VMware 的 NAT 服务出问题了，排查了半天，最后发现根源在网卡的节能策略上。

Ubuntu Server 默认开启了网卡的节能模式，当网络空闲一段时间后，虚拟网卡会自动进入省电状态，导致连接中断。解决办法是关闭网卡的节能特性。修改 netplan 配置文件，在对应网卡下面加一行：

yaml复制      wakeonlan: true

再执行 sudo netplan apply。不过要注意，这个参数并非在所有虚拟化环境下都能生效，如果你用了不同的虚拟化平台，可能需要通过 ethtool 命令来调整：

bash复制sudo ethtool -s ens33 wol g

这个问题排查的过程比较曲折，但很有代表性——很多时候网络问题不是配置错误，而是系统默认策略导致的，需要你有耐心顺着线索一层层查。

5.2 实际问题二：Nginx 页面返回 403 而非 200

部署 Nginx 后的第二天，我修改了默认站点配置，把网站根目录指向了 /opt/www 这个自定义目录。结果浏览器一访问，直接出现了 403 Forbidden。

我最初的判断是权限问题，于是把目录权限改成了 755，还是没有解决。后来我意识到问题可能出在另一个地方：Nginx 的 worker 进程用户（www-data）没有进入 /opt 目录的权限。Linux 的目录权限是逐层检查的，/opt 目录本身如果是 700 权限，那么其他用户就算对 /opt/www 有权限，也进不去 /opt 这一层。

查清楚之后，我调整了 /opt 目录的权限为 755，问题立刻解决。这个案例很好地说明了前面提到的目录权限逻辑：目录的 x 权限“进不去”，权限是逐层叠加的。遇到 403 不要只盯着目标目录，把上级目录的权限都检查一遍，你会发现很多问题豁然开朗。

5.3 排查思路小结：定位问题要形成自己的顺序

通过这两天的排查，我逐渐形成了一个自己的定位顺序：先服务状态，再网络层，再应用层，最后看日志。这个顺序不一定是最优的，但它能保证你不遗漏任何一个环节。

具体来说，碰到问题我通常按以下顺序进行排查：

这套流程看起来简单，但真坚持下来，能解决 90% 以上的日常问题。剩下那 10%，大多是系统组件之间相互影响的组合问题，那就要靠多积累案例来解决。运维这套东西，书上看一百遍，不如亲手踩一脚坑，你踩过的坑越多，你这个人的“经验浓度”就越高。

6. 三天复盘：这套流程对我的实际影响

跑完这三天的完整流程，回头来看，最有价值的不只是“会装系统”“会部署 Nginx”“会用几个命令”，而是建立了一套从底层环境到上层应用的完整认知链条。

以前我遇到服务器问题，第一反应是去网上搜“xxx 报错怎么办”，搜到的答案五花八门，试了半天可能完全不匹配。但现在我的处理方式变了——先自己理一理问题可能出在哪个层面，然后用工具验证，实在解决不了再搜索，搜的时候也更有针对性。这个变化，就是建立认知链条之后带来的直接收益。

还有一点心得想分享给看到这里的读者：学运维别求快。三天就是三天，能走完环境搭建、系统部署、基础命令这条线，你已经做到了很多人坚持不下来的事。剩下的那些高级主题，比如 Shell 脚本自动化、Ansible 批量管理、容器化部署，都是在这条主线之上长出来的枝叶。等你的基础命令用熟了，再学那些东西，会轻松很多。相反，如果一开始就想着把什么技术都学一遍，很容易被海量的知识点淹没，最后什么都没拿下。

如果你是按这篇文章的节奏走下来的，下一步我建议你做两件事。第一件事，把虚拟机的快照功能用起来，每完成一个阶段就做一个快照，这样重启实验的时候就不用从零再来。第二件事，试着在一台机器上同时部署 Nginx 和 MySQL，然后写一个简单的 Shell 脚本，每天定时备份 MySQL 数据库到指定目录。这两件事做完，你的运维实操能力就会有一个质的飞跃。