刚接手一套新服务器或者帮客户做基础环境交付的时候，最怕的不是某个软件装不上，而是整个流程没有章法：分区拍脑袋分、源配错、安全策略漏得跟筛子一样、日志日积月累把磁盘塞满。等系统上线跑业务再发现底子没打好，返工成本极高。这篇文章我把这些年做系统部署的经验浓缩成一份通用操作手册，从前期规划、系统安装、初始化配置到应用环境搭建，配合具体的验证手段和常见坑点讲解，你照着这套思路走，无论面对的是麒麟、统信UOS、openEuler、Ubuntu还是Debian系，都能快速交出一台规范、可维护、经得起业务考验的服务器系统。
这套手册不是什么高深的理论，就是一线运维和交付工程师实实在在的作业标准。如果你是刚入行的实施新人，建议完整读一遍；如果你是带了几年项目的老人，重点看我标的“易错点”和“排查技巧”，一定有能对上号的踩坑经历。
1. 部署前的全局规划
系统安装看着简单，插个U盘点几下鼠标就完事，但实际上80%的返工问题都出在安装前没有想清楚。这就像盖楼，地基没打正，后面砌墙、装门窗全得歪。部署前我习惯先把下面几件事梳理清楚。
1.1 需求盘点与容量预估
先搞清楚这台服务器将来要干什么，这个决定zhe了操作系统选型、分区策略、硬件扩展方向，直接影响后续几年的维护体验。
做需求盘点时，至少要把下面四类信息问清楚：
- 业务类型：是跑数据库、Web服务、容器平台、大数据计算，还是纯文件存储？不同类型的业务，对CPU、内存、磁盘IO的需求差异很大。
- 峰值负载：业务上线后预计有多少并发？数据量年增长大概多少？这个数字决定了分区预留空间和swap大小的设计。
- 高可用等级：这系统是允许短暂停机维护，还是要求7×24小时不间断？如果是后者，可能从硬件层就要考虑RAID卡电池保护、双电源等，分区上也要预留冗余。
- 运维条件：机房带宽多少？是否有集中监控？是否需要接入统一的日志收集平台？这些决定了系统初始化时要装哪些agent。
以最小化规划为原则，我通常建议生产服务器的初始资源至少是业务闲时需求的2到3倍。比如一个预估日均10万请求的Web服务，8核16G起步，磁盘系统盘200G、数据盘1T起步。宁可在前期把量给足，也不要等业务增长再停机扩分区，那是非常痛苦的经历。
1.2 硬件兼容性与固件检查
这几年国产化替代推进很快，部署环境里经常遇到飞腾、鲲鹏、海光、兆芯等国产CPU平台，各种国内服务器品牌像宝得、浪潮、超聚变也很常见。第一原则是：操作系统版本必须与硬件架构匹配。
我踩过一次最典型的坑：在ARM架构的鲲鹏服务器上装了x86的ISO镜像包，结果安装引导直接报错，连安装界面都进不去。所以拿到服务器第一件事，确认CPU架构，再去找对应的aarch64版本镜像。同样，有些老型号服务器的RAID卡驱动不在主流内核里，安装时需要额外加载驱动盘，否则根本认不到磁盘。
固件方面也容易被忽略。批量到货的服务器，尤其是刚拆封的全新设备，建议在部署前统一检查BIOS固件版本、RAID卡固件、SSD固件。很多莫名其妙的性能问题、偶发掉盘问题，最终都指向固件版本过老。虽然升级固件有风险，但通常厂商提供的升级工具已经很成熟，在业务上线前完成固件更新，比上线后再折腾要安全得多。
1.3 介质准备与引导方式
确认完架构和固件，接下来就是准备安装介质。现在的主流做法是使用Ventoy这类工具制作U盘启动盘，把多个ISO镜像丢进一个U盘里，安装时选择需要的那个就行，非常方便。不过要注意，部分国产系统或老版本系统对Ventoy的兼容性不佳，遇到引导不了的情况，老老实实用dd模式或官方写入工具重新制作。
引导方式上，新设备基本都是UEFI引导了，老设备可能是Legacy BIOS。这两种引导方式对应的分区需求不一样：UEFI需要创建ESP分区（通常是FAT32格式的/boot/efi分区），Legacy BIOS则没有这个要求。安装前能进BIOS确认一下引导模式是哪个，能避免分区时多绕弯子。另外不要小看一个细节：安装介质做好后，一定要在U盘上做个标识，因为我遇到过多次装机现场几个人并排操作，拿错U盘把测试环境装成了生产系统的惨剧。
2. 操作系统选型与安装底层逻辑
系统选型和安装是整个部署流程的价值观地基。这一步一旦选错，后续怎么补救都很别扭。这里我把选型的思路和安装时的分区设计逻辑拆开讲清楚。
2.1 主流操作系统发行版差异与选择
现在市面上系统发行版多，选型时容易眼花缭乱。我习惯把Linux发行版分成三大阵营：
第一阵营是Red Hat系，代表性产品有RHEL、CentOS、Rocky Linux、AlmaLinux，以及国产的麒麟高级服务器系统V10（其内核和包管理跟RHEL系同源）。这个阵营的特点是稳定、商业支持体系完善、企业级工具链成熟，适合绝大多数生产业务。我目前交付的大多数金融、政务、企业项目都是基于这个阵营，文档好找，问题排查经验也丰富。
第二阵营是Debian系，代表是Debian、Ubuntu。Debian的稳定性极佳，apt包管理用起来非常舒服，软件仓库里的包版本也比较新。很多互联网公司和开发测试环境偏爱Debian系，日志系统、容器平台跑在上面体验很好。但如果你面对的是传统企业客户，他们对Ubuntu的接受度可能不如RHEL系高。
第三阵营是国产化桌面及专用场景系统，比如统信UOS、麒麟桌面版。它们面向桌面办公场景做得比较多，适配了日常办公软件、外设驱动。如果在政务窗口、信创办公终端上部署，这类系统是刚需。另外还有openEuler这类面向数字基础设施的开源系统，在云计算、大数据场景已经有不少落地案例。
选择的核心逻辑只有一条：看业务生态和运维团队的熟悉程度，而不是哪款最新就选哪款。生产环境求的是稳，最新不等于最好。我见过有团队跟风用某个刚发布的新版本，结果业务依赖的一个组件库还没适配，折腾两周又退回老版本，白白浪费了时间窗口。
2.2 磁盘分区与文件系统规划
分区规划是系统安装中最能体现部署功底的部分。很多人图省事，安装时一路回车让系统自动分区，这种操作在测试环境没问题，但在生产环境会埋下很大的隐患。自动化分区通常把大部分空间划给根分区，如果某天日志把根分区塞满，服务直接瘫痪。
通用的分区建议可以参考下面这张表：
| 挂载点 | 分区类型 | 容量建议 | 文件系统 | 说明 |
|---|---|---|---|---|
| /boot | 标准分区或EFI分区 | 1G-2G | xfs或fat32（UEFI） | 存放内核和引导文件，不需要太大 |
| / | 逻辑卷或标准分区 | 50G-100G | xfs或ext4 | 系统程序占用的主要分区，建议给足余量 |
| /tmp | 标准分区 | 10G-20G | xfs或ext4 | 临时文件单独挂载，可加nosuid执行权限保护 |
| swap | 标准分区 | 取决于内存 | swap | 内存小于8G建议与内存等大，16G以上可按业务情况设为8G-16G |
| /data | 逻辑卷或标准分区 | 剩余全部 | xfs或ext4 | 业务数据目录，尽量独立挂载 |
为什么要把业务数据单独挂载到/data？核心原因有两点：第一是安全隔离，系统分区满了不影响业务数据，反之亦然；第二是运维方便，数据目录独立之后，做备份、扩容、迁移都有清晰的边界。另外有条件的话，数据盘建议用LVM（逻辑卷管理）来做，后续磁盘空间不够可以直接在线扩容，不需要停机迁移数据，这一点在实战中价值巨大。
文件系统选xfs还是ext4，也是一个老生常谈的话题。xfs在大型文件和高并发写入场景表现更好，是目前RHEL系默认的文件系统。ext4则胜在成熟稳定，小文件密集场景也不差。我的习惯是：根分区和业务数据盘都用xfs，遇到特殊情况比如跑数据库OLTP场景，再根据数据库引擎的官方建议调整。
2.3 引导程序与启动流程
启动这块新手容易糊涂，但弄懂引导程序是排查很多系统毛病的钥匙。
当前主流Linux使用GRUB2作为引导程序。计算机上电后，经过BIOS/UEFI初始化硬件，GRUB2负责加载内核到内存，然后内核接手完成系统初始化。整个过程可以简化成：电源开关 → BIOS自检 → 引导介质识别 → GRUB2界面 → 内核加载 → systemd初始化 → 登录界面。
安装过程中有两点要留意。第一，部分国产系统安装完成后，默认的等待时间很短，比如只有5秒的GRUB菜单等待，遇到需要进单用户模式或修改内核参数时会手忙脚乱，部署完建议顺手把GRUB的等待时间改成10秒以上。第二，某些双系统部署场景（比如Windows和Linux共存），如果不小心把引导装错了盘，重启可能直接进Windows而看不到Linux的引导菜单。所以安装引导的磁盘和目标磁盘一定要在安装界面确认清楚。
3. 核心配置与系统初始化
系统装完只是第一步，接下来的初始化配置才是真正拉开部署水平差距的地方。一台规范交付的服务器，网络、源、账户、安全、日志这些方面都有标准动作。
3.1 网络配置：静态IP与主机名规划
Linux服务器默认可能走DHCP动态获取地址，但生产环境必须使用静态IP，否则重启后IP变了，远程连接和管理会立刻抓瞎。
在RHEL系系统里，配置静态IP最顺手的方式是用nmcli命令。举个例子，把ens192网卡配置成静态IP 192.168.10.50，网关192.168.10.1，DNS 114.114.114.114，可以这样操作：
nmcli con mod ens192 ipv4.method manual ipv4.addresses 192.168.10.50/24 nmcli con mod ens192 ipv4.gateway 192.168.10.1 nmcli con mod ens192 ipv4.dns "114.114.114.114 223.5.5.5" nmcli con up ens192在Debian系上，通常直接编辑/etc/network/interfaces文件，或者使用netplan工具（Ubuntu常见）。无论用哪种方式，配置完成后都要立即验证连通性：ping一下网关、ping一下外网地址、确认DNS解析正常。
主机名规划同样重要。小规模环境随便起名无所谓，一旦规模上来，主机名混乱会让你在登录每一台机器时都得多花几秒钟确认自己是不是进错了机房。我采用的主机命名规范是：业务缩写-环境类型-编号，比如web-prod-01、db-test-02。修改主机名用hostnamectl set-hostname命令即可，同时检查/etc/hosts文件避免出现localhost解析异常。
3.2 软件源配置与包管理策略
很多刚入行的部署工程师，装完系统后第一件事就是连外网下载软件包，遇到下载失败就抓瞎。实际上，把软件源配置好是最基础的准备工作，也是决定后续安装应用是否顺畅的关键。
对于RHEL系，配置源的方式取决于操作系统的版本。麒麟V10可以直接使用系统自带的源配置工具，openEuler则提供了官方或镜像站的repo文件。通用的操作习惯是：优先配置离自己网络最近的镜像站源，这样下载速度快、稳定性高。
这里放一个Debian系配置阿里云镜像源的示例，帮助大家理解这个操作的套路：
cat > /etc/apt/sources.list <<EOF deb http://mirrors.aliyun.com/debian/ bullseye main non-free contrib deb http://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib deb http://mirrors.aliyun.com/debian-security bullseye-security main EOF apt update配置完源之后，建议立即做一次完整的系统更新，把内核和所有基础软件包升到最新，再重启一次系统。很多人会问：“刚装好的系统为什么要马上更新？”因为官方ISO发布后，仓库里往往有安全补丁，第一时间更新到位就能避免系统以带漏洞的状态跑上线。
3.3 时区、时间同步与基础系统设置
排查系统问题最怕什么？日志时间对不上。两台服务器时间差半小时，联合排障时就算同时发生的异常，看起来也像隔了很久，这种体验我经历过太多次。
时间同步的标准动作是设置系统时区为Asia/Shanghai，然后使用chrony或ntp做时间同步。以chrony为例：
# 设置时区 timedatectl set-timezone Asia/Shanghai # 安装chrony dnf install -y chrony # 修改 /etc/chrony.conf 配置上游时间服务器 cat >> /etc/chrony.conf <<EOF server ntp.aliyun.com iburst server cn.pool.ntp.org iburst EOF systemctl restart chronyd systemctl enable chronyd # 验证时间同步状态 chronyc sources -v不要小看这一步。日志服务、数据库主从同步、以后要加的监控告警系统，全都依赖统一的时间基准，这是架构能否顺利扩展的底层条件。
基础设置里还有几件小事：关闭SELinux（如果业务组件兼容性确实有问题时），设置系统语言为C.UTF-8或en_US.UTF-8避免中文乱码，调整文件描述符上限和内核参数（如/etc/security/limits.conf、sysctl.conf中的net.core.somaxconn、vm.swappiness等）。这些不是必须全部照搬，但要结合业务需要评估。
3.4 安全加固：SSH配置、防火墙与账户策略
系统安全是整个部署流程里不能糊弄的一环。我刚入行那年，经常遇到客户底线要求“审计通过、等保合规”，如果基础安全没做好，后面补起来全是窟窿。
第一关是SSH安全配置。修改/etc/ssh/sshd_config，至少要包含这几项：
- 端口改掉默认的22（可选，但如果你暴露在公网，强烈建议改）
- PermitRootLogin改为prohibit-password或no，严禁root直接密码登录
- PasswordAuthentication设为no（如果业务允许只用密钥登录）
- MaxAuthTries设置为3，防止暴力破解
改完配置后重启sshd服务前，必须先敲一遍sshd -t来验证语法是否正确。我在这里吃过亏，配置里多加了一个无效参数，重启后SSH直接起不来，人又在机房外面，只能让机房同事帮忙救援，场面一度非常狼狈。
第二关是防火墙。RHEL系默认使用firewalld，Debian系是ufw。通用做法是先封掉所有入站流量，再放行必要端口。以常用Web服务为例：
# firewalld systemctl enable --now firewalld firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https firewall-cmd --permanent --add-port=22/tcp firewall-cmd --reload第三关是账户策略和最小权限。创建业务专用账户而不是所有程序都跑在root下，给运维人员分配sudo权限而不是直接给root密码，定期轮换密码，重要系统建议开启两因素认证。这些动作执行完之后，才敢说这台系统基本能拿出来见人了。
4. 应用环境搭建与场景化部署
系统初始化完成后，服务器已经有了一副干净、强壮的身体，接下来就可以往上面安装具体业务组件了。这一部分我挑三个有代表性的场景来讲，一个是文件服务，一个是AI推理服务，一个是日志监控，覆盖了最常见的部署需求。
4.1 场景一：麒麟V10部署vsftpd并创建虚拟用户
文件共享和传输服务在企业里使用频率很高。以麒麟高级服务器系统V10为例，部署vsftpd并配置虚拟用户，是做信创项目交付时很典型的一个需求。
基础安装非常简单：
dnf install -y vsftpd systemctl enable --now vsftpd但默认vsftpd不允许本地系统用户登录FTP，也不会区分不同的文件传输账号，这在多人使用场景下很不安全。标准做法是创建虚拟用户，将FTP账号从系统账户中剥离出来，账号密码保存在独立的数据库里，权限隔离也更干净。
创建虚拟用户的步骤大致如下：
- 创建基础目录和虚拟用户数据库存储文件：
mkdir -p /etc/vsftpd/vuser_dir touch /etc/vsftpd/vuser.txt- 在/etc/vsftpd/vuser.txt里按“用户名/密码”交替行的方式写下虚拟账号信息，比如：
ftpuser1 Passw0rd@123 ftpuser2 Passw0rd@456- 使用db_load工具把明文文本转换成vsftpd认证库：
db_load -T -t hash -f /etc/vsftpd/vuser.txt /etc/vsftpd/vuser.db chmod 600 /etc/vsftpd/vuser.db配置PAM认证文件，这一步容易被忽略。在/etc/pam.d/vsftpd里指定调用刚才生成的vuser.db，并把原来系统用户认证的行注释掉。
修改/etc/vsftpd/vsftpd.conf，启用guest_enable=YES、guest_username=vuser，并将虚拟用户锁定在各自的家目录中，配置anonymous_enable=NO。
为每个虚拟用户创建独立目录并设置相应的属主权限。
重启服务验证：
systemctl restart vsftpd实操时最容易出错的地方是PAM模块路径和数据库文件权限。db文件如果权限太开放，vsftpd会直接拒绝加载，报错信息又比较隐晦，新手很容易卡在这里。遇到客户端登录失败时，优先检查/var/log/secure里PAM认证相关的报错，九成问题都是路径和权限没写对。
4.2 场景二：openEuler 24.03 LTS下的AI应用本地部署思路
近一年本地部署大语言模型相关应用的需求明显多了起来。之前在网上看到一个很典型的场景：在openEuler 24.03 LTS系统里部署DeepSeek harness和DeepSeek本地推理环境，这也是很多政企项目做智能体验证时需要做的事。
先声明一个原则：本地跑AI应用的部署手册，核心价值在于“推理环境搭建”这件事本身。不管跑的是DeepSeek还是其他开源模型，通用的思路是一致的：先确认GPU驱动和计算环境，再准备Python运行时，最后启动推理服务的框架。
以openEuler 24.03 LTS为例，完整的思路是这样的：
确认硬件环境。检查GPU是否被系统识别，执行nvidia-smi如果没有输出，说明NVIDIA驱动没有装好。openEuler的kernel和驱动版本匹配有讲究，在官方源之外，有时需要额外添加NVIDIA官方仓库或者通过runfile安装。
配置Python虚拟环境。DeepSeek新版本harness基于Python实现，依赖一堆Python包。强烈建议用venv或conda建独立环境，不要直接装到系统Python里，否则以后某个依赖升级了，整套环境说崩就崩：
python3 -m venv /opt/deepseek-env source /opt/deepseek-env/bin/activate pip install --upgrade pip安装模型框架和依赖。按照harness官方文档的要求安装对应版本的torch、transformers等组件，用requirements.txt锁定版本是个好习惯。
验证推理链路。先跑一个最简单的推理测试，确认模型能加载、数据能返回。这个步骤验证的不是模型效果，而是整个推理链路是否通畅，包括CPU/GPU内存是否足够、算子兼容性是否正常。
在纯CPU环境下部署大模型推理，要提前做好性能预期管理。以几十亿参数规模的模型为例，CPU推理速度通常只是GPU的几十分之一，如果业务对响应延迟有要求，硬件选型阶段就该上GPU或NPU。这个坑我在项目前期没有帮客户把关时踩过，后来每次部署AI应用，都会先做一轮硬件算力测算。
4.3 场景三：轻量级日志系统Grafana Loki部署
日志是系统运维的第三只眼。生产服务器上跑了什么、报了什么错、有没有异常访问，全都在日志里。很多小规模团队觉得一套ELK太重，资源消耗大、部署复杂，这时候轻量级的Grafana Loki就是一个非常合适的选择。
Loki跟ELK最大的区别是：它只建立日志内容的索引元数据，不把整条日志的全文索引都做进去，所以资源占用低得多，部署方式也更轻便。对于单个机房的几十台服务器来说，一套Loki + Promtail + Grafana的安装部署，半天时间就能完成。
在openEuler或CentOS类系统上，最省心的方式是直接用官方提供的二进制包或者通过容器方式部署。以二进制方式为例：
# 下载loki和promtail二进制到/usr/local/bin # 准备loki的配置文件，定义存储路径、接收端口等 ./loki -config.file=loki-config.yaml &Loki配置里有两个参数新手容易搞混：一个是存储路径，默认存在本地目录，要确保磁盘空间足够；另一个是日志保留时间，可以根据运维要求设置。前端展示用Grafana接入Loki数据源，然后在Dashboard里输入LogQL查询语句就能看到实时日志。
部署完日志系统后，建议马上做一件事：把服务器重要的日志文件（如/var/log/messages、/var/log/secure）都配置成由Promtail采集，并且用日志里的关键字配置几个基础告警规则，比如出现“error”、“failed”、“out of memory”就告警。这样系统部署的最后一公里才算闭环，后续出现故障时，你能第一时间看到日志异常，而不是等业务方打电话来投诉。
5. 部署验证与交付检查
系统配置完、应用装好后，不能直接就交付。我习惯在正式交付前做一轮系统性验证，把该看的地方过一遍，相当于给系统做一次全面的“体检”。
5.1 基础功能验证清单
验证环节不需要特别复杂的工具，用系统自带命令加上几个常用检查项就能覆盖大部分问题。
- 内核日志检查：执行dmesg -T | grep -i error，看看有没有硬件级别的异常，比如磁盘IO错误、内存报错。这一步能提前发现硬件隐患。
- 服务状态检查：把系统关键服务（sshd、firewalld/ufw、chronyd、NetworkManager）全部用systemctl status确认一遍运行状态，再执行systemctl list-units --failed查看有没有启动失败的服务。
- 端口监听检查：执行ss -tlnp确认业务端口都有进程在监听，比如Web服务的80/443端口、数据库的3306端口。
- 资源状况基线：用free -h、df -h查看内存和磁盘剩余空间，记录一条初始基线。以后系统慢下来、磁盘满了，拿这份基线做对比，马上能评估异常程度。
- 关键路径访问验证：如果是Web服务，本地用curl -I http://127.0.0.1验证一下HTTP响应头，确认页面正常返回。
每验证完一项，就在部署文档里打一个勾。这个动作看似繁琐，但它能养成好习惯，避免将来排查问题时两手一摊、脑子里一团浆糊。
5.2 性能压测与容量评估
正式上线前，有条件的话跑一轮轻量级的压力测试当然最好。压测不是炫技，而是验证系统在极限情况下能不能扛得住、哪块先成为瓶颈。
Web服务场景可以用ab（ApacheBench）简单压一下：
ab -n 10000 -c 100 http://127.0.0.1/观察两个核心指标：每秒请求数和平均响应时间。如果压测时错误率突然抬高，就要去检查是不是文件描述符限制（ulimit -n）、内核TCP参数或者数据库连接池设置的问题。
数据库场景可以用sysbench跑一轮基础性能测试，看看TPS和QPS能不能达到预期的水平。这些数据同时也能作为交付文档的性能基线，以后做扩缩容评估时都有据可依。
需要注意压测必须选在业务低峰期或者测试环境进行，千万别对着生产库直接压。压测工具用得越顺，越容易忽视这背后的风险，这是资深运维都懂的底线。
5.3 备份策略与系统回滚预案
很多部署手册不写备份，但实际交付中备份才是救命稻草。系统部署完成后，至少要确认三件事有备份方案：操作系统可以重新部署，但配置文件、业务数据和数据库数据必须要有恢复路径。
简单实用的备份方案可以是：配置一个每日凌晨执行的cron任务，把/etc目录、业务代码目录、数据库导出文件等关键数据用tar打包，再用rsync同步到备份服务器或对象存储。关键目录备份脚本可以参考下面的思路：
#!/bin/bash BACKUP_DIR=/data/backup/$(date +%Y%m%d) mkdir -p $BACKUP_DIR tar czf $BACKUP_DIR/etc.tar.gz /etc mysqldump -uroot -p**** --all-databases > $BACKUP_DIR/all_databases.sql rsync -av $BACKUP_DIR backup-server:/data/backup/$(hostname)/另外一个经常被忽略的是“回滚预案”。新部署的系统如果在上线后几天内发现某个配置项写错了，能不能快速回到上一个正常状态？我的习惯是在部署完成的关键节点拍一个“快照”（云环境直接做云盘快照，物理机可以记录详细的配置导出版本），做好标记和日期。这样万一后续改动出了问题，可以快速回到刚交付时的健康状态，而不是重新花半天时间手动恢复。
6. 常见问题与排查技巧实录
部署过程中的坑，踩一次长一次记性。我把自己和团队这些年高频踩到的问题汇总成一张表，再展开讲几个经典案例的排查思路。
6.1 故障速查表
| 现象 | 可能原因 | 快速排查思路 |
|---|---|---|
| 系统安装时找不到磁盘 | RAID卡驱动未加载或架构不匹配 | 确认镜像架构和RAID卡型号，加载驱动后再进安装界面 |
| 配置好静态IP后无法上网 | 网关、DNS配置错误或网络管理工具冲突 | 检查nmcli状态，确认网关可达，用dig/nslookup验证DNS |
| SSH端口改了连不上 | 防火墙未放行或sshd配置语法错误 | 尝试从本地直接登录控制台，检查sshd服务状态并恢复配置 |
| 软件源下载速度极慢或失败 | 默认源不可用，未切换到镜像源 | 检查yum/apt源配置，telnet测试源站连通性 |
| 某个服务一启动就崩溃 | 依赖库缺失或版本不兼容 | 使用journalctl -u 服务名查看启动日志 |
| 系统运行一段时间后磁盘满 | 日志文件未做轮转或业务数据增长过快 | 执行du -sh/*逐级定位大文件，配置logrotate清理策略 |
| 数据库连接数打满 | 连接池配置不合理或存在慢查询 | 查看MySQL的processlist，优化SQL和连接池参数 |
6.2 系统引导修复实例
有位客户反映，一台做完RAID的机器重启后直接进了GRUB命令行界面，启动不了系统。现场排查过程是这样的：先确认了系统之前能正常启动，说明不是硬件故障，而是引导记录出了问题。重启进入救援模式，检查/etc/fstab发现有一行挂载条目的UUID写的还是旧盘符的UUID，RAID重建后UUID变了导致挂载失败，系统一直在引导阶段循环。
修这个问题的标准动作是用LiveCD启动，chroot进入原系统，重新生成GRUB配置：
mount /dev/mapper/系统分区 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg exit reboot同时把/etc/fstab里过时的UUID替换成blkid查询到的新UUID。这起故障的根本原因就是磁盘RAID信息变更后，文件系统设备的持久标识发生了变化，系统仍然拿着旧的UUID找设备，自然找不到。这个案例告诉我们：所有基于块的配置，一律用UUID而不是/dev/sdX，因为设备名会随加载顺序变化，而UUID是唯一的。
6.3 日志排查的经验之谈
排查新部署系统问题时，最高效的路径是先看日志，再看配置，最后找代码。很多人一上来就改配置、重启服务，像无头苍蝇一样乱撞，时间全浪费了。
systemd时代，查看服务日志最直接的方式是journalctl。比如排查vsftpd登录失败的问题：
journalctl -u vsftpd --since today tail -f /var/log/securejournalctl配合--since参数能过滤出最近一段时间的日志，排查效率非常高。日志里如果出现“PAM unable to dlopen”这类字样，基本都是PAM模块路径或依赖库的问题；如果出现“vsftpd: refusing to run with writable root inside chroot”，则是FTP根目录权限设置过宽，这个报错尤其隐蔽，很多新手会花很长时间排查。
日志轮转方面，系统自带logrotate工具可以帮助管理日志大小。部署工作完成后，检查/etc/logrotate.conf和/etc/logrotate.d/目录下是否有针对应用日志的轮转配置。没有的话，花十分钟建一个：
cat > /etc/logrotate.d/custom-app <<EOF /data/logs/*.log { daily rotate 14 compress missingok notifempty copytruncate } EOF这份配置的作用是每天都对业务日志做轮转，保留14天，超过期限的自动压缩归档。我个人强烈建议所有手动启动的、输出到本地文件的程序都配置上logrotate，否则日志文件会一直膨胀，直到把磁盘占满才被发现，那时候再处理就很被动了。
七、最后的几点建议
做系统部署这份工作，成就感和挫折感往往只有一线之隔。一套系统规范交付后的那种踏实感，跟每次上线都提心吊胆的感觉，是完全不同的状态。我这些年最大的体会就是：部署不是把系统装完交差，而是给后续多年的运维打底子。底子打好了，以后业务扩展、故障排查、合规审计都能顺顺利利；底子没打好，后面每一次维护、每一次扩容都在为当初的随机应付买单。
如果让我用一个词概括这套通用部署手册的精髓，我会选“标准化”。把每一个环节都沉淀成固定的流程、固定的模板、固定的检查清单，不依赖个人经验和临场发挥，这套方法无论交给谁去执行，都能交付出一致的结果。最后再分享一个小技巧：把每次部署过程中的关键操作、易错点、命令记录整理成内部Wiki，版本化保存，下次再遇到同样的场景，直接复制经验，效率翻倍。部署这件事，没有捷径，但把每一步走扎实后，后面的路会越走越宽。
