服务器交付后如何验收？Deluxe (MY) v2裸金属配置、磁盘与网络检查要点

服务器交付后，先按订单或交付单核对 CPU、内存、磁盘、网卡和公网信息，再检查磁盘健康、端口连通、路由、带宽与持续运行表现。Deluxe (MY) v2 的具体配置应以本次订单和交付信息为准，不能仅凭型号名称推断硬件、端口速率或带宽承诺；验收的重点是逐项对照约定，并保留可复核的命令输出和测试时间。

开始前准备好交付单、预期 IP 地址、系统登录权限，以及一台位于其他网络的测试设备。服务器端命令通常需要 Linux 管理权限；若系统没有预装相应工具，应先确认发行版和软件包来源，再按系统文档安装。网络测试尽量安排在低业务负载时进行，不要在生产流量上直接跑高并发或长时间压测。

先确定验收基准

将交付单中的内容整理成核对表。至少记录处理器型号及核心数、内存容量、磁盘数量和容量、网卡接口及协商速率、管理方式、公网 IPv4/IPv6、网络端口速率、带宽口径、流量限制和测试范围。交付信息没有明确某一项时，先向服务方确认，不要用常见配置替代约定值。

特别要区分以下概念：

“1 Gbps 端口”和“1 Gbps 可用带宽”并不总是同一承诺：前者描述接口链路能力，后者还可能受服务配置、共享策略或流量规则影响。验收前应以交付单写明的口径为准，遇到模糊表述先确认测试方法和判定阈值。

按顺序核对配置真实性

1. 检查主机识别信息

先记录系统版本、主机名和启动时间，随后核对 CPU、内存及可见设备。以下命令以常见 Linux 环境为例：

hostnamectl
uname -a
lscpu
free -h
sudo dmidecode -t system
sudo dmidecode -t memory

重点查看 lscpu 中的型号、Socket、每 Socket 核心数和逻辑 CPU 数；free -h 中的总内存应与订单约定大致一致。操作系统和固件可能占用少量内存，因此显示值与标称容量不一定逐字相等。若差异明显，或 CPU 型号、核心数与约定不符，应保存完整输出，先不要自行调整系统参数来“修正”显示结果。

dmidecode 读取的是固件提供的 SMBIOS 信息，适合辅助核对，但不能单独证明资源归属或性能表现。虚拟设备、固件信息不完整、特殊配置都可能影响输出；如信息冲突，应把 lscpu、free、dmidecode 和交付单一起提交核实。

2. 检查磁盘数量、容量和挂载关系

使用块设备信息确认系统识别到的设备、分区、文件系统和挂载点：

lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
df -hT
sudo fdisk -l

lsblk 用于查看设备层级；df 反映已挂载文件系统的可用空间；fdisk -l 可辅助确认分区信息。磁盘厂商按十进制标称容量，操作系统通常按二进制单位显示，标称容量换算后略小属于常见情况。还要留意 RAID、LVM、分区及系统保留空间：例如系统只显示一个逻辑卷，不代表底层只有一块物理盘。

如果交付单约定磁盘数量或型号，建议对照 MODEL、SERIAL 与设备树；若序列号被隐藏，记录这一点并请服务方提供可核实方式。不要为了验收而执行格式化、分区重建、wipefs、mkfs 或 RAID 重组，这些操作可能破坏已有数据。

健康状态可以通过 smartctl 检查，但不同磁盘类型和控制器的支持情况不同。工具未安装时先确认系统发行版；不要因命令不存在就推断磁盘故障。已具备工具时可运行：

sudo smartctl -H /dev/sda
sudo smartctl -a /dev/sda

设备名需按 lsblk 输出替换。重点关注整体健康判断、介质错误、待处理扇区、接口错误及错误计数是否持续增加。部分 NVMe 设备需使用相应设备路径，RAID 控制器也可能屏蔽物理盘 SMART 信息。遇到不支持或无法读取时保留错误输出，要求提供对应控制器下的健康核验方式；不要仅凭一次非零计数就判定故障，应结合字段含义、历史变化和服务方说明判断。

需要验证实际读写时，避免对原始设备做写入测试。可以在确认有足够空间的临时目录中创建测试文件，测试结束后删除该文件；生产环境应避开繁忙时段，并先评估磁盘剩余空间。若只做交付验收，设备识别、健康信息和文件系统读写状态通常应先于压力测试。

核对网卡、端口与地址

3. 确认网卡接口和协商速率

查看接口、地址和链路状态：

ip -br link
ip -br addr
ip route

找到承载公网流量的接口后，用 ethtool 查询协商速率和双工状态：

sudo ethtool eno1

将 eno1 替换为实际接口名。关注 Link detected、Speed、Duplex 及协商状态。网卡硬件支持的速率不等于当前链路已协商到该速率；而服务器接口显示的速率也不必然代表服务端承诺的公网带宽。若 ethtool 未安装、驱动不支持或显示 Unknown，记录输出并向服务方确认交换端口侧信息，不要据此直接判断端口损坏。

接口状态为 DOWN 时，先确认是否查看了正确网卡、系统是否使用聚合接口或其他命名方式，再检查链路状态和系统日志。不要未经确认执行网卡重启、修改 MTU 或覆盖网络配置：远程操作可能导致 SSH 断开。若确需调整，应先备份网络配置、准备控制台或带外管理通道，并确保有恢复原配置的办法。

4. 核对 IP、网关和双向可达性

本机看到地址只能证明地址已配置，不能证明公网入站、出站和回程都正常。先检查地址与路由表：

ip -br addr
ip route
ip -6 route

确认默认路由指向交付信息中的网关，地址前缀与分配信息相符。IPv6 未分配时，ip -6 route 没有公网默认路由不一定是故障；是否需要 IPv6 应按订单核对。

再测试到网关和外部目标的连通性：

ping -c 5 <网关地址>
ping -c 5 1.1.1.1
tracepath 1.1.1.1

示例地址仅用于说明命令格式，实际目标可选稳定、允许 ICMP 的外部地址。ping 的丢包和时延可用于观察连通性，但部分网络会限制或降低 ICMP 响应优先级，因此 ping 不通不能单独证明业务端口不可用。tracepath 可辅助观察路径及路径变化；中间节点不回应也常见，不应把单个 * 直接视为链路中断。

同时从外部测试端反向检查服务器地址，并使用实际业务所需端口进行连接测试。例如服务已正常监听时，可从测试机执行：

nc -vz <服务器公网地址> <业务端口>

若业务尚未部署，可在维护窗口临时启用受控测试服务，但必须限制来源地址、明确监听端口，并在测试后关闭。外部连接失败时，按“服务是否监听—主机防火墙—上游安全策略—路由和地址配置”的顺序排查。不要为测试而长期开放管理端口或关闭整台服务器的防火墙。

测试带宽与持续稳定性

5. 使用同口径测试带宽

带宽结果受测试端能力、测试服务器位置、并发连接数、协议、时段和路径影响。一次网页测速或单条连接速度，不能代表整条链路的持续能力。优先采用服务方确认的测试节点与方法，并记录测试方向、时长、并发数、时间及双方网络环境。

如果双方允许使用 iperf3，可在受控测试端启动服务端，再由待验收服务器发起测试。测试端的监听应仅对测试来源开放，结束后停止服务：

iperf3 -s

在待验收服务器上执行：

iperf3 -c <测试端地址> -t 30 -P 4

反向方向可用 -R 单独测试。示例中的 30 秒和 4 条并发流只是便于说明的测试参数，不是产品规格，也不保证适用于所有网络。先确认测试节点可用、服务端端口已获准通过，并控制测试时长与流量；不要对不属于自己的地址进行压测。

查看结果时同时记录发送端与接收端速率、重传情况和测试时段。单向明显偏低，可能与路径、对端能力或方向性策略相关；多次结果波动较大，则需换测试时间或节点复核。确认网络路径和测试端正常后仍持续低于约定口径，再提交证据。不要把端口协商速率、短时峰值或单一测试点的数据直接当作持续带宽结论。

6. 观察链路稳定性

完成基础连通后，进行一段有代表性的连续观察。可对网关和一个外部目标分别采样，例如：

ping -i 1 -c 300 <网关地址>
ping -i 1 -c 300 <外部目标地址>

这类命令约持续数分钟，适合发现短时丢包和时延波动，但 ICMP 可能被限速，不能替代业务协议测试。若业务使用 TCP，可结合业务端口连接结果或应用自身健康检查观察。记录丢包率、平均及最大时延、是否出现连续中断，并与测试时段、服务器负载对应起来。

同时查看接口错误计数和系统日志：

ip -s link
dmesg -T | tail -n 100

关注 RX/TX errors、dropped、链路反复 up/down，以及驱动或设备重置信息。计数器应结合观察前后的差值判断；历史累计值非零，不一定表示当前仍有问题。若错误持续增长并伴随丢包或链路重连，保存两次采样结果和日志时间点，提交服务方排查。

结果解释、异常留证与复核

验收结果可按“符合、待确认、不符合”记录。符合表示与交付约定一致且基本连通；待确认表示工具受限、口径不清或结果受外部测试条件影响；不符合表示在可重复测试中，关键配置与约定不一致或链路异常。不要因单次测速偏低、单个路由节点不响应或 SMART 工具不支持，就直接下故障结论。

发现异常时，保留以下材料：

• 订单或交付单中对应的配置与网络承诺，标明待核对的具体字段。
• 命令原始输出、执行时间、服务器时区、系统版本及测试端网络环境。
• 测试目标、方向、持续时间、并发参数、丢包和速率结果。
• 异常出现频率、是否可复现，以及同期接口计数器或系统日志。

提交问题时描述“预期值、实际值、复现步骤、影响范围”，比只写“网络慢”更便于定位。配置不一致时先不要自行重装系统、重建分区或修改路由；网络疑点也不要通过关闭防火墙、改 MTU、重启网卡等高影响操作掩盖问题。若已经做过变更，记录原配置和变更内容，并按备份恢复；远程网络调整前应确保有控制台或带外访问方式。无法安全恢复时，停止进一步操作并联系服务方。

复核时使用与首次相同的测试条件，避免把不同节点、不同时间段或不同并发结果直接比较。确认配置、磁盘健康、端口、路由和稳定性问题均已解释或处理后，再开始正式部署；验收记录与原始输出应一并保存，便于后续区分交付差异、系统变更和运行期间出现的问题。