3. 标准化交付流程与阶段划分

Intel Xeon 计算平台的交付不是“把服务器搬进机房、插上电、装个系统”这么简单。它是一条从客户业务需求出发、经过方案设计、到货验收、上架安装、系统配置、测试验证，最终以交付文档收口的完整工程链路。标准化的意义在于：把每个阶段该做什么、由谁做、依据什么判断通过，固化成可复用的动作，使不同项目、不同工程师交付出来的平台在质量上保持一致。本节按七个阶段展开，重点讲清各阶段的输入、关键动作和阶段出口判据。

阶段一：需求分析——把业务语言翻译成平台参数

需求分析的核心产出是一份可被方案设计直接消费的“平台需求基线”。它至少要回答四类问题：算力需求（CPU 型号、核数、主频、是否启用超线程）、内存需求（容量、通道数、是否要求 8 通道满配）、存储与网络需求（系统盘、数据盘、RAID 级别、网口速率与数量）、以及可用性与环境约束（是否双电源、冗余风扇、机柜 U 位、供电与散热上限）。

实践中常见的做法是把业务指标换算成平台参数。例如某数据库业务要求约 20000 IOPS 的随机读、单机内存不低于 512GB，则可推导出：选用支持 8 通道 DDR5 的双路 Xeon 平台，内存按 16×32GB 配置以填满通道，存储采用 NVMe SSD 并配置 RAID 10。这里的关键是“换算过程要留痕”，即记录业务指标到平台参数的映射依据，否则后续验收时无法判断配置是否合理。

阶段二：方案设计——确定拓扑、兼容性与配置清单

方案设计把需求基线转化为可采购、可安装的具体配置。此阶段必须完成三件事：一是 CPU 与主板、内存、RAID 卡、网卡、电源的兼容性核对，尤其是内存颗粒与主板 QVL（合格供应商列表）的匹配；二是确定物理拓扑，包括 CPU 插槽与内存通道的对应关系、PCIe 插槽分配（如 RAID 卡插 CPU1 的 PCIe x16、网卡插 CPU2 的 PCIe x8）；三是输出 BOM 配置清单与固件版本基线。

内存插法是最容易出错的环节。以双路 8 通道平台为例，若只插 8 条内存，应优先插满每个通道的第一槽位（通常标注为 DIMM_A1、B1、C1…），而不是把 8 条集中插在 CPU1 侧，否则会造成 CPU2 侧无内存、NUMA 结构失衡，性能显著下降。方案设计阶段就应把内存插槽分布图作为附件固化下来。

阶段三：到货验收——把问题挡在机房之外

到货验收要在设备进入机房前完成，因为一旦上架，退换货成本会大幅上升。验收动作分四步：核对装箱单与采购订单的型号、数量、序列号；检查外包装与机箱外观有无运输损伤；开箱核对内部配置，重点确认 CPU 型号与数量、内存条数与单条容量、硬盘数量与型号、RAID 卡与网卡是否与 BOM 一致；最后通电做一次最小化自检，观察 POST 是否报错、能否进入 BIOS 识别全部 CPU 与内存。

验收中最常见的偏差是内存条数量或容量与 BOM 不符，以及硬盘托架缺失。建议逐台记录序列号与配置，形成《到货验收记录表》，作为后续资产管理和故障追溯的依据。

阶段四：上架安装——物理交付的规范动作

上架安装包括机柜定位、导轨安装、设备推入、电源连接、网络布线和加电。规范要求：按机柜 U 位图安装，设备间预留散热空间；双电源分别接入 A、B 两路 PDU，实现供电冗余；网线按“设备-端口-对端”规则贴标签，管理口与业务口分开走线；加电顺序为先外设后主机，观察风扇与电源指示灯状态。

此阶段要特别关注供电与散热余量。例如一台双路 Xeon 服务器满载功耗约 500W，若一个机柜计划装 10 台，则需预留约 5kW 供电与相应制冷能力，避免加电后因过载跳闸或高温降频。

阶段五：系统配置——BIOS、RAID 与操作系统的落地

系统配置是把方案设计落到设备上的关键环节，顺序通常是：BIOS 配置 → RAID 配置 → 操作系统安装 → 驱动与固件更新。BIOS 阶段需确认超线程、内存频率、电源策略、启动模式（UEFI）等设置与方案一致；RAID 阶段按设计创建阵列，例如 4 块 NVMe SSD 做 RAID 10，并确认阵列状态为 Optimal；操作系统安装后，安装芯片组、网卡、RAID 卡驱动，并将固件升级到基线版本。

# 示例：查看内存与 CPU 识别情况（Linux）
lscpu | grep -E "Socket|Core|Thread|Model name"
dmidecode -t memory | grep -E "Size|Locator|Speed"

# 示例：查看 RAID 阵列状态（以 MegaRAID 为例）
storcli /c0 /vall show
# 期望输出：State = Optimal，VD 数量与设计一致

配置完成后应保存 BIOS 配置导出文件与 RAID 配置记录，作为交付文档的一部分。若后续出现性能异常，可据此比对是否有人改动过配置。

阶段六：测试验证——用数据判断是否达标

测试验证分功能、性能、稳定性三类。功能测试确认 CPU、内存、硬盘、网卡全部被正确识别，RAID 状态正常，网络连通；性能测试用工具采集关键指标，例如用 stream 测内存带宽、用 fio 测磁盘 IOPS、用 iperf3 测网络吞吐，并与需求基线比对；稳定性测试让平台在接近满载条件下连续运行不少于 2 小时，观察是否出现降频、报错、掉盘或重启。

判断依据要事先约定。例如需求基线要求内存带宽不低于 200GB/s，实测若为 180GB/s，则需检查内存是否插满通道、频率是否被降频，而不是直接判定“通过”。测试数据应记录在《测试验证报告》中，包含测试项、工具、命令、实测值、基线值和结论。

阶段七：交付文档——让平台可被接手和运维

交付文档是整条链路的收口，也是运维团队接手平台的依据。标准交付文档通常包括：需求基线表、方案设计与 BOM、到货验收记录、上架与布线图、BIOS/RAID 配置记录、测试验证报告、资产与序列号清单、以及遗留问题与注意事项。文档的价值不在于厚度，而在于“下一个工程师能否仅凭文档完成故障定位和配置复原”。

把这条链路固化下来，交付质量就不再依赖某位工程师的熟练程度，而是依赖流程本身的可重复性。这也是标准化交付相对于“能装就行”的根本区别。