华为鲲鹏一体机ARM架构安装与调优实战笔记

项目标题是“华为鲲鹏一体机 安装笔记”，我印象最深的是：这类机器第一次上手，真正耗时间的环节往往并不在“点下一步安装”，而在从开箱到系统跑起来的十几个衔接点上。带外口没通、虚拟光驱挂不上、镜像架构拿错、阵列模式选反、分区方案定错，任何一个环节出问题，后面都得从头再来一遍。这篇笔记就是把这台 ARM 架构一体机从纸箱里拿出来、到能稳定跑业务的全过程整理出来，偏向实际操作中遇到的细节，不是官方手册的复述。刚接触 ARM 服务器的人、需要在一体机上部署业务的中级运维，或者正准备做一次平台迁移的开发者，都能从里面找到能直接照做的东西。

1. 开箱到上架：两个前置动作决定后面顺不顺

一体机这种东西，装箱清单看起来很唬人，实际上真正需要当场确认的没几样。我把这一步拆成“硬件核对”和“管理链路打通”两件事，前者出问题要立刻找供应商，后者出问题会让后面所有远程操作都变成不可能。

1.1 到货核对别只看箱子外观

箱子没破不代表里面没动过。我的习惯是拆箱第一件事对照装箱单看三样：整机序列号与合同是否一致、硬盘托架的实配数量与容量标签是否对得上、导轨和理线臂是否齐全。这三样里最容易被忽略的是硬盘——有些批次出厂时硬盘是单独包装塞在泡沫里，不插在盘位上，如果没核对，装到一半发现少盘，就得停下来等。

第二件事是记录机器的初始状态。把 BMC 网口的 MAC 地址、机器的 SN、面板上的资产标签全部拍照存档。一体机的一个特点是整机作为一个交付单元，后面如果要走保修或者换件，这几个号是唯一的凭证。我见过有人装完系统才想起来不知道 BMC 的 MAC，结果现场几十台机器混在一起，只能一台台开机箱找。

第三件事是确认供电规格。多路电源的机型，电源线要按路数配齐，机柜 PDU 的电流余量要提前算。ARM 平台整机功耗比同核数的通用平台低一些，但多路电源满载时的瞬时电流还是有峰值的，尤其是和旁边几台机器共用一个 PDU 的时候。上架前把电源线分到不同 PDU 上，这个动作只要两分钟，但能省掉后面一次整机断电排查。

导轨安装没什么技术含量，唯一要提醒的是走线。一体机的内部走线空间通常比较紧凑，理线臂装反了会顶到后部模块，我第一次装就干过这事，机器推进去一半卡住，只能整个抽出来重装。

1.2 先让管理网口通，再谈装系统

这是我最想强调的一条：系统可以晚半天装，带外管理必须先通。原因很实在——机房噪音大、温度低，物理接触机器的成本远高于远程操作。一旦带外链路可用，后面所有的开关机、挂载镜像、看启动日志都能在工位上完成；带外不通，每改一个 BIOS 参数就得跑一趟机房。

实际操作是先规划一个管理网段。我的习惯是单独划一个不跑业务的小网段，把 BMC 地址固定下来，不依赖现场 DHCP。规划表大概长这样：

地址定好之后，用笔记本直连 BMC 口，改本机网卡为同网段静态地址，浏览器登录确认能进控制台。这一步能通，后面的远程装机才有意义。如果现场有多台机器，建议一次性把地址规划表填完再统一改，别装一台改一台，容易乱。

顺带说一个细节：大部分机型的 BMC 出厂是 DHCP 模式，如果现场没有 DHCP 服务器，它可能一直拿不到地址，表现就是网口灯闪但ping 不通。这时候要么用面板上的小屏幕（有些机型配了）查地址，要么直接笔记本抓包看它发出来的 DHCP 请求，或者按随机附带的说明卡改成静态。总之别在“网口灯亮不亮”上耗时间，灯亮只代表物理层通。

2. 带外控制台的实操：远程 KVM、虚拟介质与串口

带外管理台是这台机器上我使用频率最高的功能，没有之一。装系统、改 BIOS、查硬件告警、看开机自检卡在哪一步，全靠它。但它也是最容易在关键时候掉链子的地方，下面几个问题我基本每次装机都会遇到至少一个。

2.1 首次登录必须改掉的几项设置

出厂状态下管理口通常是 DHCP，第一次登录后的第一件事就是改成静态地址，同时把登录密码换掉。这不是形式主义——管理口一旦暴露在业务网段且用默认口令，风险是很实在的。

除了地址和密码，还有两项我建议一起改：一是关闭不必要的服务，很多带外管理台默认开着一些用不上的协议，能关就关；二是确认固件版本，如果版本比较老，趁机器还没上业务先升一次。固件升级这事有个经验：不要等到出问题才升，因为升级本身要重启管理芯片，如果这时候机器正在跑业务，虽然不影响操作系统，但你会失去一段时间的远程可见性，心里很没底。

升级固件前记得导出当前配置，有些版本升级会重置网络设置。我第一次升完发现管理地址回到 DHCP，人在工位上，机器在机房，只能又跑一趟。

2.2 虚拟光驱挂 ISO 经常挂不上的几个原因

一体机一般没有光驱，装系统靠带外管理台的虚拟介质功能，把本地 ISO 映射成机器眼里的一个 USB 光驱。这个功能好用，但失败率不低，常见原因有这几类：

• ISO 体积超过限制。部分管理台对单次上传的文件大小有上限，完整版服务器镜像动辄几个 G，容易踩线。解决办法是先在管理台里看有没有“远程文件服务”或者 HTTP 挂载方式，绕开浏览器上传。
• 浏览器兼容性。老版本管理台依赖特定插件，新版浏览器直接不支持。我的做法是备一个旧版浏览器的便携版本专门干这事，或者优先用管理台自带的 HTML5 控制台。
• 网络抖动导致映射中断。虚拟介质是把本地文件通过网络实时喂给远端的，链路一抖，安装程序就报读盘错误。这种情况最坑，因为错误出现在安装中途，看起来像镜像坏了。判断方法是换成本地 HTTP 服务提供 ISO，让管理台从内网地址拉取，稳定性高一个档次。
• 映射后没在启动项里选对。虚拟光驱映射成功，但 BIOS 启动顺序里没有它，机器还是从硬盘起。要在启动菜单里手动选一次，装完之后再改回来。

提示：映射 ISO 之前先把镜像的校验值算好，装完如果起不来，第一件事是回头校验镜像，而不是怀疑硬件。

2.3 串口重定向是被低估的救命通道

图形控制台在系统装好之后很顺，但在两个场景下会失效：一是系统内核 panic，画面卡死；二是网络配置改错，SSH 连不上。这时候串口重定向（SOL）就是唯一能看见内核输出的通道。

开启方式是在 BIOS 或管理台里把串口重定向打开，然后在本地用 IPMI 工具或者管理台自带的 SOL 功能连上去。连上之后看到的是纯文本启动日志，虽然简陋，但能看清卡在哪一步——是卡在 grub，还是卡在挂载根文件系统，还是内核起来了但网络服务没起。

我遇到过装完系统重启进不去，图形控制台一片黑，最后靠 SOL 看到内核在报根分区找不到，原因是安装时把引导装到了错误的磁盘上。没有这条通道，这个问题只能靠猜。

3. 阵列与分区：装完再改就要推倒重来

存储这块是典型的“决策成本前置”。装系统之前花二十分钟想清楚，能省掉后面几个小时的重装。

3.1 RAID 还是直通，取决于上面要跑什么

一体机通常配阵列卡，可选做 RAID 或者把盘直通给操作系统。这两条路没有绝对优劣，关键看业务形态：

我的常规做法是系统盘做 RAID1，数据盘按业务定。系统盘做 RAID1 的理由很朴素：系统盘挂了整机就没了，而系统盘写入量小、两块盘的成本可以接受。数据盘如果是跑分布式存储或者数据库自带副本的，直通反而更灵活，扩容和换盘不用碰阵列卡。

这里有个实操细节值得说：阵列卡的管理工具在 ARM 平台上，可执行文件名可能和 x86 上不一样。很多教程里写的命令带 64 后缀，拿到 ARM 机器上根本找不到这个文件。正确做法是装完系统后到厂商的工具包目录里看一眼实际文件名，或者直接用带外管理台里的图形化阵列配置，更省事。

3.2 系统盘和数据盘分开的两个理由

第一是重装成本。业务跑起来之后，重装系统是难免的事，系统盘和数据盘分开，重装时只动系统盘，数据盘原地保留，挂载回去就行。

第二是 IO 干扰。系统盘的日志写入、包管理器的元数据读写都是随机小 IO，和数据盘的顺序大 IO 混在一起会互相拖累。物理上分开，哪怕只是不同的盘位、不同的阵列组，效果也比全塞一块盘上好。

分区方案上我的习惯，供参考：

ARM 平台上 swap 的取舍和 x86 没本质区别，但有一点要注意：如果这台机器跑的是内存密集型业务，swap 开着反而会在内存紧张时引入不可控的延迟，宁可让它 OOM 快速失败，也不要卡在 swap 上慢慢磨。

3.3 引导分区这块别省

UEFI 引导的机器，/boot/efi分区是必须的，而且必须是 FAT 格式。有些人在分区时手快把它删了或者格式化成别的文件系统，装完直接起不来。/boot单独分区也建议保留，因为内核和 initramfs 更新会占用空间，跟根分区混在一起，遇到根分区写满的情况会连带内核都升不了。

还有一点：如果是多路径或者多块系统盘做冗余的机器，安装时要注意引导程序装到了哪块盘上。有些安装器默认只往第一块盘写引导，另一块盘虽然做了镜像但没有引导记录，主盘一坏就起不来。装完之后用efibootmgr -v看一眼启动项，确认指向正确。

4. 镜像与引导：aarch64 不是换个镜像那么简单

这一节是我认为整个安装过程中最容易出错的地方，因为很多人的思维惯性还停留在 x86 上。

4.1 镜像校验和架构确认

拿到镜像的第一件事是算校验值，第二件事是确认它真的是 aarch64 架构的。现在不少发行版官网会把多个架构的镜像放在同一个页面，文件名前缀看起来差不多，下载的时候点错是常事。

校验用sha256sum，比对官网公布的摘要。这一步别省，镜像下载不完整导致的安装失败，排查起来非常浪费时间，因为报错往往出现在解压某个包的时候，看起来像软件源的问题。

确认架构可以在安装介质启动后、正式安装前，进 shell 敲一下：

uname -m # 期望输出：aarch64

如果输出是x86_64，说明拿错镜像了，赶紧换。还有一种情况是镜像本身是 aarch64 的，但里面混进了 x86 的包，这种少见但存在，表现为安装过程中某个包解压失败。遇到这种第一反应应该是重新下载镜像，而不是去调安装参数。

4.2 UEFI 启动项与 PXE 里的文件名差异

一体机基本都是 UEFI 引导，没有传统 BIOS 那套。虚拟光驱映射好之后，开机按启动菜单键，选 UEFI 的虚拟光驱项。如果没看到这一项，通常是映射没成功，回到上一节排查。

PXE 批量装的时候有个细节：ARM 平台的引导文件名和 x86 不同。x86 上常见的是grubx64.efi，ARM 上是grubaa64.efi。DHCP 配置文件里的filename字段如果照抄 x86 的模板，机器会一直卡在获取地址之后没下文。我第一次做 ARM 的 PXE 就栽在这，抓包看到 TFTP 请求了一个不存在的文件才反应过来。

配置大致是这样：

# dhcpd.conf 片段 subnet 10.10.20.0 netmask 255.255.255.0 { range 10.10.20.100 10.10.20.200; option routers 10.10.20.1; next-server 10.10.20.5; filename "grubaa64.efi"; }

对应的 TFTP 根目录下要放grubaa64.efi和 grub 的配置文件，配置文件里再指向内核和 initrd 的路径。这套东西配一次能用很久，值得花时间做好。

4.3 安装界面里三个容易被默认值坑到的选项

第一个是软件源。ARM 平台的完整镜像里包比较全，但如果安装时选了最小化安装又没配好源，装完会发现很多常用工具都没有，得一个个补。我的做法是首次安装选“带开发工具的基础环境”，把编译链和常用诊断工具一次装齐，省得后面反复折腾。

第二个是安全策略。某些发行版默认开启强制访问控制策略，装完第一次启动可能因为策略没配好导致一些服务起不来。如果这台机器是内部环境、有边界防护，安装时可以先设成宽松模式，业务跑通之后再逐步收紧；如果直接上生产，那就得在装的时候就配好策略，别等到上线前一天才发现。

第三个是内核参数。安装界面通常允许在启动时追加内核参数，这里有几个在 ARM 平台上值得加的：

# 典型追加参数示例 iommu=pt pcie_ports=native

iommu=pt让直通设备走透传模式，减少 DMA 转换开销，对网卡和阵列卡性能有实际帮助。pcie_ports=native在某些平台上能避免 PCIe 设备枚举异常。这两个参数不是万能的，但加上之后出问题的概率更低，我一般默认加。加完装好系统后可以用cat /proc/cmdline确认参数确实生效了。

5. 首启之后的收尾：网络、时间、软件源

系统装完第一次进桌面或者命令行，很多人就直接开始装业务软件了。我习惯先把三件基础的事做完，因为这三件事没做好，后面所有的问题都会变得难以复现。

5.1 网卡命名和多网口绑定

ARM 服务器的网卡命名规则和 x86 一致，都是基于 PCI 拓扑生成的名字，所以同一台机器重装之后名字可能变化。这在配了多网口的场景下很麻烦，脚本里写死的网卡名一换就全乱。

两个做法：一是用nmcli或者配置文件把网卡名固定下来，通过 udev 规则绑定 MAC；二是在配置管理里不写死名字，用 MAC 或者连接名定位。我更倾向第二种，简单。

多网口绑定是常见需求，做之前先确认交换机侧支持什么模式。链路聚合如果两边模式不匹配，表现是网口灯正常但流量不通，排查起来很绕。基本配置：

# 创建一个 802.3ad 模式的 bond nmcli con add type bond con-name bond0 ifname bond0 \ bond.options "mode=802.3ad,miimon=100,xmit_hash_policy=layer3+4" # 把两个物理口加进去 nmcli con add type ethernet con-name bond0-slave1 ifname enp1s0f0 master bond0 nmcli con add type ethernet con-name bond0-slave2 ifname enp1s0f1 master bond0 # 配地址并启用 nmcli con mod bond0 ipv4.addresses 10.10.30.10/24 ipv4.method manual nmcli con up bond0

xmit_hash_policy=layer3+4这一项值得单独说：默认的哈希策略只看 MAC，单条大流量（比如两个 IP 之间的大文件传输）会全部压在一条链路上，另一端闲着，带宽上不去。改成按 IP 和端口哈希，多连接场景下能真正用上两条链路。

5.2 时间同步没做对，后面全是玄学

这个问题我在不止一个环境里见过：集群里几台机器时间差了几分钟，表现是节点认证失败、日志时间对不上、证书校验报错，排查方向全跑偏。

装完系统第一件事把时间同步配好，指向内网的时间源：

# 查看当前同步状态 chronyc sources -v # 手动触发一次同步 chronyc makestep

如果内网没有时间源，至少选一个稳定可达的，别让机器裸奔。还有个细节：虚拟化环境里的时间漂移比物理机明显，如果这台一体机上面还要跑虚拟机，宿主机的时间同步更要配准。

5.3 自建本地源，解决 aarch64 包不全

ARM 生态这几年进步很大，但和 x86 比，第三方仓库的包覆盖还是有差距。实际装业务软件时经常会遇到“某个依赖在这个架构上没有预编译包”。

我的做法是在内网搭一个本地源，把官方镜像、厂商提供的补充包、以及自己编译出来的 RPM 全放进去，统一管理。这样做有三个好处：一是安装速度快，不受外网影响；二是版本可控，不会因为上游仓库更新导致环境漂移；三是可以把自己编译的包纳入统一管理。

搭源本身不复杂：

# 安装建仓工具 dnf install -y createrepo_c httpd # 把包放进目录后生成元数据 createrepo_c /var/www/html/repo/aarch64 # 客户端配置 cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=Local aarch64 Repo baseurl=http://10.10.20.5/repo/aarch64 enabled=1 gpgcheck=0 EOF dnf clean all && dnf makecache

gpgcheck=0只建议在内网自建源里用，公网源还是要验签的。生成元数据这一步在包更新之后要重新跑，别忘了写进发布脚本。

6. ARM 平台上最耗时间的部分：软件包与依赖

前面几步做完，系统能跑起来了，接下来才是真正的硬仗。我个人的统计是，同样的业务从 x86 迁到 ARM，装机本身占的时间不到三成，剩下的全花在软件适配上。

6.1 拿到一个 x86 二进制包时该做什么

先别急着想办法跑起来。正确的顺序是：

1. 确认这个软件有没有官方或社区提供的 aarch64 版本。很多主流开源软件现在都有，只是下载页面藏得比较深。
2. 如果没有预编译包，看能不能从源码编译。这一步要看它的依赖链是否完整，有没有用到 x86 特有的指令集或汇编。
3. 如果源码里带 x86 内联汇编或者依赖闭源的 x86 库，那就要考虑替代方案或者容器化隔离。

判断一个二进制文件是什么架构，用file命令最快：

file /usr/local/bin/some-tool # ELF 64-bit LSB executable, ARM aarch64, ... 正常 # ELF 64-bit LSB executable, x86-64, ... 跑不了

遇到第二种情况，别浪费时间尝试兼容层。ARM 上跑 x86 二进制需要额外的指令翻译层，性能损失明显，而且不是所有软件都能跑起来。生产环境上这条路基本走不通。

6.2 源码编译的依赖补齐顺序

编译失败十次有八次是缺依赖，剩下两次是编译器版本不对。我的习惯是按这个顺序来：

先装编译工具链和基础开发库：

dnf groupinstall -y "Development Tools" dnf install -y gcc gcc-c++ make cmake automake libtool pkgconfig

然后逐个确认目标软件的依赖。这里有个技巧：不要一次性把所有可能相关的包都装上，容易引入版本冲突。正确做法是先跑一次./configure或者cmake，看它报缺什么，缺什么补什么，补完再跑。这样依赖关系是清晰的，出问题好定位。

编译时注意-j参数：

make -j$(nproc)

ARM 机器核数通常不少，但内存也要跟上。有些软件单个编译单元占用内存很大，-j开到核数会 OOM。我遇到过编译到一半被系统杀掉的情况，一开始以为是代码问题，后来发现是并行度太高。稳妥做法是先-j4试，没问题再逐步加。

还有一个容易被忽略的点：部分软件默认会编译出针对当前平台优化的指令。ARMv8 有很多可选扩展，如果编译机和支持的指令集不一致，产出的二进制在别的机器上可能非法指令崩溃。跨机器部署时，编译参数里要明确指定基线架构，不要用-march=native。

6.3 容器镜像的多架构适配

如果业务跑在容器里，恭喜，这一层反而好办。现在的容器工具链对多架构支持已经很成熟，关键是确认镜像有没有 arm64 版本。

# 查看镜像支持的架构 docker manifest inspect nginx:latest | grep architecture # 明确拉取 arm64 版本 docker pull --platform linux/arm64 nginx:latest

构建自己的镜像时，用 buildx 直接产出多架构镜像：

docker buildx create --name multiarch --use docker buildx build --platform linux/amd64,linux/arm64 \ -t registry.local/app:v1 --push .

这里有个前提：Dockerfile 里的基础镜像本身要支持多架构，安装依赖的步骤也不能写死 x86 的源地址。我见过 Dockerfile 里直接curl一个 x86 的二进制包下来解压，这种在多架构构建时会在 arm64 阶段直接失败。

还有一个坑：某些语言的包管理器会在安装时编译原生扩展，比如 Node.js 的某些模块、Python 的 C 扩展。这些在 arm64 镜像里构建时需要有对应的编译工具链，基础镜像如果是 slim 版本可能没有，需要在构建阶段临时装。

7. 性能相关的几个开关：NUMA、中断、页大小

系统跑起来、业务装好，接下来是调优。这一步不是必须的，但如果业务对延迟或者吞吐敏感，值得花时间。

7.1 先看清 NUMA 拓扑再谈绑核

ARM 多核处理器通常是多 NUMA 节点的，跨节点访问内存的延迟明显高于节点内。调优第一步是把拓扑看清楚：

numactl -H lscpu | grep -i numa

输出会告诉你每个节点的 CPU 核范围和内存大小。看完之后，绑核策略才有意义。基本原则是：一个进程的 CPU 和内存尽量在同一个节点内，跨节点的内存访问能避则避。

对于数据库这类对延迟敏感的服务，可以用numactl --cpunodebind=0 --membind=0把进程固定在一个节点上。但要注意，如果单节点的内存不够用，强行绑反而会导致 OOM，这时候要考虑拆分实例。

绑核这事我不建议一上来就做。先跑基准测试，看瓶颈到底在哪，如果瓶颈在 IO 或者网络，绑核带来的收益很小，反而增加了运维复杂度。

7.2 网卡多队列与中断亲和

高吞吐场景下，单个网卡队列会成为瓶颈。先看当前队列数：

ethtool -l enp1s0f0

如果 combined 只有 1 或者很少，可以调大：

ethtool -L enp1s0f0 combined 16

调完之后配合irqbalance让中断分散到不同核上。默认的 irqbalance 策略在多数场景下够用，如果是极端性能场景，可以手工把每个队列的中断绑到固定的核上，避免中断在核间迁移带来的缓存失效。

手工绑定的做法是先看中断号：

grep enp1s0f0 /proc/interrupts

然后把对应的中断号写进/proc/irq/<num>/smp_affinity_list。这个操作在重启后会失效，要写进开机脚本或者用 tuned 配置持久化。

7.3 64K 页内核这个坑要提前知道

ARM64 架构支持 4K、16K、64K 三种页大小，部分发行版提供 64K 页的内核变体。64K 页在大内存、大 IO 场景下确实有优势，TLB 命中率高，某些数据库跑分更好看。

但它的兼容性问题很实在：一些第三方软件、驱动、甚至某些语言的运行时，是按 4K 页假设写的，在 64K 页内核上会直接崩溃或者行为异常。表现往往是段错误或者 mmap 失败，日志里看不出明显原因。

判断当前页大小：

getconf PAGE_SIZE

如果输出 65536，说明是 64K 页内核。这时候装业务软件前先去查一下它的兼容性说明。如果不确定，最稳的做法是换成 4K 页内核，牺牲一点理论性能换兼容性。这个选择在装机阶段做最省事，装完业务再换内核，风险大得多。

8. 卡住过的几个现场：现象、链路与根因

前面讲的是流程，这一节讲几个实际卡住的场景。我把排查过程完整写出来，因为排查思路比结论更有复用价值。

8.1 装完重启进不去系统，图形控制台黑屏

现象：安装过程一切正常，提示安装完成重启，之后图形控制台一直是黑的，只有光标在闪。

排查链路：先连 SOL 串口重定向，看到内核输出停在Waiting for root device之类的信息。这说明内核起来了，但找不到根分区。回到带外管理台看存储配置，发现安装时选的是 RAID 模式，但系统盘所在的逻辑盘没有被正确识别为第一启动设备。

根因是引导安装位置和实际启动顺序不一致。安装器把引导写到了另一块盘上，而 BIOS 启动顺序里第一项指向的是没引导的那块。

处理方式：进 BIOS 调整启动顺序，或者用安装介质进救援模式重装引导。更省事的做法是重装一遍，安装时明确指定引导设备。

教训是：装完第一次重启的时候一定要盯着看，别装完就去干别的，回来发现黑屏，已经错过了最有信息量的启动日志。

8.2 网口灯亮但 ping 不通

现象：网线插好，交换机侧灯也亮，机器上ip a显示网卡 up，但没有地址，或者有地址对端不通。

排查链路：先看链路协商速率，ethtool enp1s0f0看 Speed 和 Duplex 是否正常。如果速率跑到了 100M 而不是 1000M 或更高，说明网线或者模块有问题。再看交换机侧 VLAN 配置，很多时候是端口没划到正确的 VLAN 里。

还有一种情况是网卡绑定了多个口做 bond，但交换机侧没配聚合，两边模式不匹配。表现就是灯亮、链路 up、但流量不通，而且没有明显报错。这时候看cat /proc/net/bonding/bond0里的 LACP 状态，如果是down就说明协商没成功。

根因通常是配置不一致，不是硬件故障。我的经验是遇到“灯亮不通”先查配置，最后才怀疑硬件，因为硬件坏的概率远低于配置写错。

8.3 几个高频问题的速查表

这张表是我自己在多次装机里攒下来的，遇到问题先对一遍，能省掉不少时间。当然具体情况具体分析，表里给的是方向，不是结论。

最后分享一个个人习惯：每装完一台机器，我会把这次遇到的非预期情况记在一个文本文件里，跟着机器资产编号一起存档。下一次装同型号的时候翻一眼，能避开大部分重复的坑。一体机这种整机交付的设备，同一批次的机器问题往往高度相似，前面踩过的坑后面基本都会再遇到一次。

另外提一句，装机过程中所有的手工操作，只要有第二次的可能，就顺手写成脚本。改 BMC 地址、配 bond、装基础包、调内核参数，这些都能脚本化。脚本化的意义不只是省时间，更重要的是保证多台机器的配置完全一致，减少后面“为什么这台正常那台不正常”的排查成本。