企业官网建设流程全解析

机房里的裸金属设备，最怕的不是坏，而是“半死不活”——开机亮、能进系统、跑点小任务没问题，真上生产负载就随机崩、训到一半丢训练节点、数据库偶尔报内存校验错。传统排查思路是先进操作系统再跑烤机工具，可这时候驱动、散热、系统负载全搅在一起，根本分不清是硬件暗病还是系统问题。所以我直接绕开操作系统，在 UEFI 固件这个层面写了一个免费的裸金属硬件故障排查工具，我内部叫它 FullDiag，一共 21 项自检，覆盖 CPU、内存、存储、PCIe、网络、外设，全程可视化进度条，跑完一键出报告。这篇就聊聊我当时的设计思路、踩过的坑，以及怎么把它和裸金属服务器的批量预检流程接起来。

工具的核心价值很简单：不装系统、不依赖驱动、不看 BMC 脸色，只要机器能亮、能进 UEFI Shell，就能做一次硬件健康度体检。适合三类人：一是搞机房运维、要批量上架的，二是折腾二手服务器、怕买到“药机”的，三是被硬件问题折磨到想“先杀硬件再排系统”的排障工程师。

1. 为什么我坚持在 UEFI 层做自检，而不是进系统烤机

1.1 裸金属排障的三个真实困境

第一次做硬件排障的人，第一反应往往是“进系统跑个 memtest、AIDA64、Linpack 不就完了”。但这套逻辑在裸金属生产环境里经常走不通。

没系统可用是最常见的情况。新到的机器还没有装操作系统，或者系统已经崩到起不来，安装镜像本身就加载了半天，这时候你没法进 Windows/Linux 去跑诊断工具。

带外管理通道不是标配。大厂服务器有 iDRAC、iLO、IPMI 这些带外管理系统，可以远程挂载诊断 ISO、看传感器日志，甚至直接截屏。但白牌机、二手拆机服务器，很多就没有 BMC 模块，或者管理口是残的。IPMI 有，但 SOL 不通、传感器数据读不出。这种机器，带外诊断约等于零。

就算有系统、有带外，进了系统再诊断还有个致命问题：驱动和固件微码会“掩盖”硬件问题。内存 ECC 纠错挡着、NVMe 控制器自动重试、GPU 驱动把显存错误吞了，系统层面看一切正常，实际硬件已经虚了。等到哪天驱动没加载成功、纠错达到峰值，问题才会一次性爆发。

UEFI 自检规避了这三层问题。硬件刚上电，固件按规范做 POST、初始化内存控制器、枚举 PCIe 设备、加载 Option ROM，此时没有任何操作系统驱动在“兜底”。我们在这个层面做检查，看到的是硬件最原始的状态。

1.2 现成方案为什么没接住需求

我也不是一上来就打算自研。当时先找了一圈免费方案，结论是：免费的不够全，够全的不免费。

开源圈子里的传统艺能是 memtest86+，它的内存测试确实强，一个 usb 启动盘跑一遍，模式全、时间长，定位内存颗粒问题一把好手。但问题是它只测内存，不碰 CPU 指令集、NVMe SMART、网卡 PHY、PCIe 链路宽度这些整机指标。

纯 Linux 小内核方案（比如 SystemRescue 里那一堆工具）能力强，但又要先进 BIOS 选启动项，又要等内核起来，又要敲命令，给流水线上的批量自检场景用太慢了。而且它跑在 OS 驱动层，对于“固件枚举出问题、设备根本没出现在 PCIe 总线上”这类状况，Linux 直接“设备未发现”，没法区分是硬件坏了还是固件配置问题。

商业方案我也咨询过，PC-Doctor、SuperProbe 这类授权不便宜，而且部分功能绑定到品牌机。对混合机型、白牌裸金属，报价和适配都是事。

后来想明白了：与其找“万能工具”，不如自己利用 UEFI 固件已经完成硬件初始化的特性，把这些检查项“串”起来。UEFI 固件启动时本来就干了一轮硬件初始化，我们只是把“只看结果”变成“主动注入测试”，并且把结果可视化、落盘。这样既是自研，又能确保每一个测试项都是针对裸金属运维的痛点设计的。

2. 21 项测试怎么设计：每一项都是冲着排障去的

2.1 测试框架分层：基础信息、压力测试、外设链路、可靠性

我一开始犯过贪多求全的错，列了 40 多项，跑一轮要两个多小时。后来砍到 21 项，把测试分成了四层：

• 基础信息采集：不产生压力，只读固件和 SMBIOS 信息，用来确认“机器身份”和“固件状态”；
• 核心部件压力测试：主动制造负载，让 CPU、内存在高负载下暴露毛病；
• 存储与 I/O 链路测试：检查盘能不能认、SMART 有没有告警、PCIe 链路宽度对不对；
• 外设与可靠性测试：USB、串口、网卡、TPM、CMOS、风扇传感器这些“容易忽略但坏了很烦”的边角。

这四层对应四种不同的故障现场：身份类用于“上架前盘点”，压力类用于“随机崩溃定位”，链路类用于“开机不认盘/网卡丢”，可靠性类用于“服务器看着正常但温度失控/时间重置”。

2.2 21 项测试清单速览

2.3 压力测试的边界：不是把硬件往死里整

有人可能会问：UEFI 环境里做 CPU 满载和内存读写测试，安全吗？我的原则是：必须做，但要留边界。

UEFI 固件自己也要用内存，比如 ACPI 表、SMBIOS 结构、内存映射信息都在低地址区域。设计内存测试时，我先读取 EFI GetMemoryMap 接口返回的内存图，把 EfiReservedMemoryType、EfiRuntimeServicesData 这些固件占用的区域排除掉，只在 Available 内存块里跑回写校验。这样既能把内存颗粒测透，又不会测试测到一半把固件自己的数据结构给冲了。

CPU 压力测试的主要目的是发现“过热降频”和“个别核心不稳定”，所以我在 8/9/10 三项里加了一个“单线程跑 30 秒，观察 APIC 中断响应延时”的辅助逻辑。如果某个核心响应明显变慢，日志里会标一个 W（警告），提示该核心可能有问题。

2.4 报告心态设计：P/W/F 三态，不搞“玄学结论”

很多商业诊断工具喜欢输出“Pass”或“Fail”，但实际运维最需要的是警告态。比如风扇转速没有读到，不一定代表风扇坏了，也可能是主板 EC 固件还没初始化传感器；NVMe SMART 备用块低于阈值，盘还能用，但直觉告诉我这盘离寿终正寝不远。

所以这 21 项统一输出三种状态：

• P（Pass）：测试数据正常，硬件状态健康；
• W（Warning）：测试完成但结果异常，需要人工复核；
• F（Fail）：测试失败，判定为硬件故障。

后面解读报告时，重点不是看有没有 F，而是看有没有 W——大部分要返修的机器，都是先在 W 里露出马脚的。

3. 全程可视化与一键出报告的实现细节

3.1 在 UEFI 里做界面，没有想象中那么难

UEFI 图形界面最正统的做法是通过 HII（Human Interface Infrastructure）框架，但这套东西开发效率低，颜色、字体、布局都要定义。我选择了更直接的方式：用 GOP（Graphics Output Protocol）拿到显存帧缓冲，自己在每个像素上画。

具体做法是：

1. 初始化 GOP，拿到当前分辨率、像素格式（常见是 BGRX8888）；
2. 做一个简单的字体点阵表，英文字母和数字各 1 个字节一个像素，中文干脆不用，全英文界面避免编码问题；
3. 实现一个 draw_text() 和 draw_progressbar()，在屏幕固定的区域刷新测试状态；
4. 测试循环里每隔 500 毫秒重绘一次进度。

整个过程说起来简单，但有几个细节值得说。

UEFI Shell 默认的文字模式是 80x25 字符，分辨率很低，想要好看的可视化效果必须切到 GOP 图形模式。我提供了一条命令 first-run 时自动调用 gop 协议设置成 1024x768 或更高分辨率。如果遇到老显卡不支持高分辨率，就回退到字符模式，这时候进度条改用一行一行的字符块。

进度条不单是一个装饰。我在每个测试项启动时记录开始时间，跑完记录结束时间。最后一屏除了“21/21”，还会显示每项耗时。这等于自带性能参考数据，比如内存测试如果某条通道的时间明显超出平均值，基本可以怀疑那条通道跑在了降频或纠错模式。

3.2 报告落盘与“一键出报告”的工程化

“一键出报告”是我最初的需求，但真正实现起来才发现，难的不是保存文件，而是“断点安全”和“格式统一”。

EFI Shell 环境里写文件要自己处理 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL。核心步骤是：

# 在 UEFI Shell 里运行时，工具会挂载当前文件系统 # 然后进入 \EFI\FULLDIAG\ 目录，把报告写进去： # 第一步，先写临时文件 fs0:\EFI\FULLDIAG\report.tmp # 第二步，结束后把临时文件改名为 report_20250115_143022.txt # 改名操作在 FAT32 上是“先删旧文件再写新文件”， # 如果走到一半断电，临时文件还在，下次运行会继续写，不会把上一次结果搞丢。

这个临时文件机制非常关键。FAT32 没有日志事务，测试过程中如果突然断电，正在写的文件可能只有几百字节，目录项还是旧的。我改成每完成一个测试项就往 report.tmp 里追加一行，跑完再整体改名。即使中途断电，至少上一次的数据还在，恢复后也能看到“跑了 12/21、第 13 项失败”的线索。

报告格式上我同时输出三种：

• 纯文本后缀 .txt：方便 Shell 里 cat 直接看；
• CSV 后缀 .csv：方便运维同事用 Excel 筛选状态；
• 内联 CSS 的 HTML：方便打开浏览器直接看，不需要外链任何文件。

HTML 报告是重点。我第一次生成的 HTML，没写 meta charset，结果浏览器默认按 GBK 打开，乱码一片。后来直接在文件头写死 UTF-8，并且在 HTML 里把表格样式、状态颜色、时间轴全部内联，不依赖网络。

3.3 UEFI Shell 2.2 的兼容性处理

工具运行环境是 UEFI Interactive Shell，我主要在 Shell 2.2 上测试，也就是 EDK2 编译出来的标准 UEFI Shell。Shell 版本太老（比如 1.0）有的命令不支持，所以我尽量少依赖 Shell 命令，核心逻辑都放在一个 UEFI Application 里面，Shell 只是启动器。

还有一个坑是启动脚本 startup.nsh。很多机器插上启动盘，固件会自动找 \EFI\BOOT\BOOTX64.EFI 作为默认启动项，但它不会主动执行 startup.nsh 里的命令。我处理的方式是：BOOTX64.EFI 本身就是一个引导程序，内部逻辑是先扫描各文件系统，找到 \EFI\FULLDIAG\fulldiag.efi，然后 LoadImage/StartImage 把这个自检程序拉起来。这样不管用户在哪个盘、哪个目录，只要插上 U 盘开机，就能自动进入自检界面。

如果不想做成全自动，也可以用 Shell 启动盘，手动输入：

fs0: cd \EFI\FULLDIAG fulldiag.efi

我实测下来，把 fulldiag.efi 直接放到 ESP 分区的 \EFI\BOOT\ 下，比单独做一张 Shell 启动盘省事得多。

4. 真实排障现场：从 U 盘到故障定位的完整流程

4.1 制作启动 U 盘的几个关键选择

工具写好了，怎么把它塞进一台裸金属？我最初直接被“UEFI 引导 U 盘用 FAT32 还是 NTFS”这个问题卡住了。

结论很简单：一定要 FAT32，除非你想让固件在你面前报“无法加载文件系统驱动”。

UEFI 固件规范只要求支持 FAT12/FAT16/FAT32 作为启动文件系统，NTFS 在绝大多数服务器主板上是读不了引导文件的。虽然有网友给过 NTFS 驱动的 EFI 模块，但为了一个启动盘多挂一层驱动，不值得。

另外注意，FAT32 单文件不能超过 4GB。我的工具加上字体、日志模板也不到 50MB，完全没影响。

分区表用 MBR 或 GPT 都行，关键是文件系统必须是 FAT32，里面要有 \EFI\BOOT\BOOTX64.EFI 这个路径。我习惯用 GPT + FAT32 ESP 分区，因为有些新机型纯 UEFI 模式下只认 GPT 的 ESP。

制作完 U 盘后，强烈建议在一台正常的机器上先跑一遍，确认能亮界面再拿去现场。我就干过拿一张没拷全文件的 U 盘跑到机房，结果整台机器又开机又关机，反复折腾半小时，最后发现少了一个字体文件。

4.2 案例一：AI 训练服务器“跑着跑着就掉卡”

某次现场排障，一台 8 卡 GPU 服务器，训练任务跑两三天就概率性掉卡。系统日志里只能看到 “NVRM: fallen off the bus”，完全定位不到是卡的问题还是 PCIe 插槽的问题。这台机器有 IPMI，但传感器没有明显告警。

我的操作流程：

1. 插上 FullDiag 启动 U 盘，开机进入工具界面；
2. 看到 21 项测试逐项跑，前 15 项全绿；
3. 跑到第 18 项“GPU 设备识别与显存映射”时，抓到 3 号卡识别正常，但通过 PCIe 扩展 ROM BAR 读取显示容量时，读回的数据跟型号标称值差了 512MB；
4. 对应日志显示 3 号卡链路速率是 PCIe Gen2 x8，而其他卡是 Gen3 x16；
5. 结论清晰了：PCIe 链路降速说明金手指或插槽接触有问题，不是卡本身坏了。

后来拆机重新插拔，在 3 号槽位的金手指上发现轻微氧化痕迹，清理后重新上机，链路恢复到 Gen3 x16。这种问题如果在 Windows 里跑 GPU 压力测试，驱动会自动重试，可能压一整天也复现不出来，但在 UEFI 层直接读链路协商结果，一眼就知道问题。

4.3 案例二：二手服务器“开机电量跑不到 100%”

一个朋友买了两台二手服务器，卖家说“一切正常”。他到手后跑了一遍我做的自检，第 11 项“内存地址线测试”直接报了 F，FAIL 项指向 DIMM_A2。

我看了下报告里的内存映射信息，A2 通道 32GB 容量能被识别，但地址线测试在 2GB 边界处发现了地址重叠。这意味着有根地址线虚焊或者内存条某个 Rank 失效。朋友直接找卖家，用报告做证据退了 800 块钱。

这种用报告“说事”的用法，意外成了工具最常用的场景之一。二手服务器水太深，SMBIOS 信息可以伪造，MEMTEST 跑一晚上也不一定暴露问题，但地址线测试这种底层硬性校验很容易抓到马脚。

4.4 报告解读速查表

4.5 报告文件写不进 U 盘的问题

工具运行过程中，如果插入的 U 盘不是 FAT32，或者分区被写保护，日志落盘就会失败。我的策略是：U 盘和启动盘用同一个 —— 工具启动后自动找到当前所在文件系统，把报告写到当前目录下 report 文件夹，不依赖额外的 “数据盘”。这样的好处是现场少带一个 U 盘，坏处是如果机器上有多个 fs 设备，要遍历一遍确认哪个是启动 U 盘，而不是选到硬盘上的 EFI 分区。

判断逻辑是：启动 U 盘的卷标必须写成 FULLDIAG，工具遍历所有 Block IO 设备，找到卷标匹配的那一个，然后锁定它。这样即使机器原有硬盘也有 EFI 系统分区，也不会搞混。

5. 老平台和批量部署场景怎么适配

5.1 老主板不支持 UEFI 怎么处理

这是被问得最多的问题。像 Supermicro X8、X9 时代的主板，很多是传统 BIOS 优先，UEFI 兼容性一言难尽。我在工具文档里专门写了三种应对方案。

方案一：用 UEFITool 0.28.0 这类固件分析工具先检查 BIOS 里到底有没有图形驱动和 UEFI Shell 模块。有些板子出厂时固件里就没有 UEFI Shell，这时候你插任何 UEFI 启动盘都只会进传统 BIOS 界面，不是 U 盘做错了。

方案二：如果 BIOS 里确实没有 UEFI 启动逻辑，可以试试 DUET（Developer UEFI Environment）。它是一个能让传统 BIOS 机器加载 UEFI 运行环境的引导程序。本质上是先通过传统 BIOS 加载 DUET 内核，再模拟出一个 UEFI 环境，然后运行我的工具。实际测试过几台老机器，能用，但兼容性不算完美，个别机器的 S3 睡眠功能会受影响。

方案三：最稳妥的方式，是用 GRUB2 启动一个精简 Linux 内核，把同一套检查逻辑在 Linux 用户态重新编译一份跑。为此我维护了一个 Linux 版的轻量检查包，测试项不减，只在可视化部分退化为命令行彩色输出。

这里还要额外提一个坑：Supermicro 老主板的 UEFI 模式经常只能找到 FAT32 的 FAT 卷，但对多分区 U 盘支持很差。老主板开 UEFI 模式时，建议用单分区 FAT32 U 盘，不要像新机器那样搞多分区。我在实验室里用 X9DRi 主板测试过，U 盘如果带 EFI 分区 + 数据分区，老固件可能在枚举时直接卡死。

5.2 从单机自检到机房批量预检

工具做出来之后，很快就遇到第二个需求：机房一次性到了 50 台裸金属服务器，总不能一台一台插 U 盘吧。

我进一步把 FullDiag 和数据中心现有的“批量安装操作系统”流程接在了一起。思路是这样的：

1. 通过 PXE 引导 iPXE 菜单；
2. iPXE 菜单里多增加一项 “FullDiag Hardware Self-Test”；
3. 服务器 PXE 启动后进入 FullDiag 自检界面，自动跑 21 项；
4. 测试完成后，日志通过 HTTP PUT 上传到内网的报告服务器，同时机器自动关机；
5. 运维只查看报告服务器汇总的通过率，没通过的机器直接拎出来检修。

这个批量预检流程帮机房省了很大人工。以前是人工目检 + 抽查，现在是每台机器上架前都有硬性自检记录。报告服务器上我写了一个简单表格页面，不同部门的人看不同字段：运维看状态，采购看序列号，财务看资产编号。

但引入 PXE 之后也有一个副作用：网卡驱动必须内置。虽然 UEFI 环境普遍自带网卡 UNDI 驱动，但在 iPXE 进入的 UEFI 环境下，很多网卡的 UNDI 驱动没有加载，PHY 检测会误报。我的解决方案是：PXE 进入后先做一个“网卡驱动加载”的预检步骤，明确提示是否已经从固件 ROM 加载了 UNDI，如果没有而 PXE 又成功了，就以“网卡可 PXE 引导”作为通过依据，不依赖状态报告里的 PHY 值。

5.3 用虚拟机验证：KVM/OVMF 固件调试

开发过程中不可能每改一版代码都跑到真机上去测。我的日常调试环境是 KVM 虚拟机，配 OVF（OVMF）固件来模拟 UEFI。这样可以在本地快速验证显示输出、文件写入、日志格式，只有 UI 层代码稳定之后才拿到真机上做硬件测试。

OVMF 固件可以从各大发行版的 edk2-ovmf 包里获取，QEMU 启动参数大致为：

qemu-system-x86_64 -m 4096 \ -bios /usr/share/edk2-ovmf/OVMF_CODE.fd \ -hda fat:rw:full_disk_dir \ -netdev user,id=n1 -device e1000,netdev=n1

这种方式适合测报告生成、文件重命名、启动脚本逻辑，但不能测真硬件传感器。虚拟机里风扇、温度、SMART 全都是空的，所以那些测试项在 OVMF 环境下会显示 W（警告）。这反而是个特性：能判断工具在“信息不完整”环境下是否仍能正常出报告，而不是直接崩溃。

6. 常见问题速查与避坑笔记

6.1 从“工具启动不了”到“报告乱码”的合集

6.2 几个容易被忽略的细节

U 盘的扇区分配单元大小尽量设成 4096 字节或更小。有些 UEFI 固件对 64KB 大簇的 FAT32 分区兼容性很差，遇到“固件列表里能看到设备但看不到文件”的问题，重新格式化成默认 4096 字节往往就好了。

日志里不要出现中文字符。UEFI Shell 默认的代码页是 ASCII/英文，中文写进去在固件控制台显示乱码，在 Windows 记事本里又是一套编码。我统一用英文输出，文字报告也只用英文字段，中文说明只放到启动菜单的大字说明里。

温度传感器读不到不代表一定是硬件坏。部分国产白牌主板的 EC 固件在 UEFI Shell 阶段没有暴露 ACPI 方法，传感器读不到非常正常。这种情况我会在报告里标 W 而不是 F，并且附一句 “manual check required”，提醒人复核。

6.3 排障顺序建议：先看报告头部，再看 W，最后看 F

很多人拿到报告喜欢先看红色 FAIL 标记，但我实际用下来，建议的顺序是：

先看报告的“基本信息采集”部分，确认 SMBIOS 版本、CPU 微码、内存通道映射是否正常。这部分经常能解释机器为什么会随机崩 —— 比如微码版本不匹配导致 CPU 在特定指令下挂起；然后再看 W 项，W 是“边界模糊”的线索，往往指向接触不良、固件配置、链路降速这一类需要人工介入的问题；最后才处理 F 项，F 是明确的坏，直接换件就行。

有一次排障，机器 21 项全 P，但一跑业务就重启。我一开始没方向，后来重新看报告头部才发现：BIOS 版本是五年前的，ACPI 表里缺少一个低功耗 C-state 相关的表项。升级 BIOS 后才解决。这说明报告头部信息不是摆设，它可能带着固件层面最关键的线索。

7. 工具还差什么，以及我打算怎么补

FullDiag 现在能覆盖裸金属上架前 80% 的硬件暗病排查，但离“一次到位”还有距离。按我这两年的实操体会，有几个方向值得后续扩展。

传感器数据目前只有“读到/读不到”和“当前值”两个维度。我想把 UEFI Shell 阶段的温度、风扇转速、电压采样值按时间轴记录下来，在压力测试结束后生成一条“温度上升曲线”。如果 CPU 散热硅脂老化，压力测试过程中温度曲线会比正常机器陡得多，这种问题当前静态值很难看出来。

IPMI 通道想做对接。很多服务器板载 BMC 虽然是残的，但 IPMI 命令接口能通。如果 FullDiag 生成报告后能主动尝试通过 KCS 接口读一下 SEL（System Event Log），把带外日志也合并到报告里，定位问题的信息量会增加非常多。

再说回“免费”这件事。裸金属硬件排查工具这个领域，免费且开源、能在 UEFI 层直接跑、还带可视化界面的，确实非常少。我在分享这个工具的代码时附带了一句话：不要把它当成一个万能的硬件裁判，它的价值在于把“固件已经知道的信息”和“硬件能承受的极限状态”翻译成运维能看懂的报告。真正最稳的硬件，不一定是测试全 P 的机器，而是那些报告里有几个 W、但运维人员都记在心里的机器。