项目标题是“华为鲲鹏一体机 安装笔记”我印象最深的是这类机器第一次上手真正耗时间的环节往往并不在“点下一步安装”而在从开箱到系统跑起来的十几个衔接点上。带外口没通、虚拟光驱挂不上、镜像架构拿错、阵列模式选反、分区方案定错任何一个环节出问题后面都得从头再来一遍。这篇笔记就是把这台 ARM 架构一体机从纸箱里拿出来、到能稳定跑业务的全过程整理出来偏向实际操作中遇到的细节不是官方手册的复述。刚接触 ARM 服务器的人、需要在一体机上部署业务的中级运维或者正准备做一次平台迁移的开发者都能从里面找到能直接照做的东西。1. 开箱到上架两个前置动作决定后面顺不顺一体机这种东西装箱清单看起来很唬人实际上真正需要当场确认的没几样。我把这一步拆成“硬件核对”和“管理链路打通”两件事前者出问题要立刻找供应商后者出问题会让后面所有远程操作都变成不可能。1.1 到货核对别只看箱子外观箱子没破不代表里面没动过。我的习惯是拆箱第一件事对照装箱单看三样整机序列号与合同是否一致、硬盘托架的实配数量与容量标签是否对得上、导轨和理线臂是否齐全。这三样里最容易被忽略的是硬盘——有些批次出厂时硬盘是单独包装塞在泡沫里不插在盘位上如果没核对装到一半发现少盘就得停下来等。第二件事是记录机器的初始状态。把 BMC 网口的 MAC 地址、机器的 SN、面板上的资产标签全部拍照存档。一体机的一个特点是整机作为一个交付单元后面如果要走保修或者换件这几个号是唯一的凭证。我见过有人装完系统才想起来不知道 BMC 的 MAC结果现场几十台机器混在一起只能一台台开机箱找。第三件事是确认供电规格。多路电源的机型电源线要按路数配齐机柜 PDU 的电流余量要提前算。ARM 平台整机功耗比同核数的通用平台低一些但多路电源满载时的瞬时电流还是有峰值的尤其是和旁边几台机器共用一个 PDU 的时候。上架前把电源线分到不同 PDU 上这个动作只要两分钟但能省掉后面一次整机断电排查。导轨安装没什么技术含量唯一要提醒的是走线。一体机的内部走线空间通常比较紧凑理线臂装反了会顶到后部模块我第一次装就干过这事机器推进去一半卡住只能整个抽出来重装。1.2 先让管理网口通再谈装系统这是我最想强调的一条系统可以晚半天装带外管理必须先通。原因很实在——机房噪音大、温度低物理接触机器的成本远高于远程操作。一旦带外链路可用后面所有的开关机、挂载镜像、看启动日志都能在工位上完成带外不通每改一个 BIOS 参数就得跑一趟机房。实际操作是先规划一个管理网段。我的习惯是单独划一个不跑业务的小网段把 BMC 地址固定下来不依赖现场 DHCP。规划表大概长这样项目建议取值说明BMC 网段独立小网段如 10.10.10.0/24不与业务网混用BMC 地址手工静态指定避免 DHCP 续租后地址漂移管理交换机口单独 VLAN与业务流量隔离访问方式工位 PC 直连或跳板机减少暴露面地址定好之后用笔记本直连 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 或者把盘直通给操作系统。这两条路没有绝对优劣关键看业务形态模式适合场景代价RAID如 RAID1/RAID10系统盘、对可靠性要求高的单机业务容量利用率低换盘要进阵列卡管理直通 / JBOD分布式存储、需要操作系统自己管盘的场景失去硬件冗余依赖上层软件做副本我的常规做法是系统盘做 RAID1数据盘按业务定。系统盘做 RAID1 的理由很朴素系统盘挂了整机就没了而系统盘写入量小、两块盘的成本可以接受。数据盘如果是跑分布式存储或者数据库自带副本的直通反而更灵活扩容和换盘不用碰阵列卡。这里有个实操细节值得说阵列卡的管理工具在 ARM 平台上可执行文件名可能和 x86 上不一样。很多教程里写的命令带 64 后缀拿到 ARM 机器上根本找不到这个文件。正确做法是装完系统后到厂商的工具包目录里看一眼实际文件名或者直接用带外管理台里的图形化阵列配置更省事。3.2 系统盘和数据盘分开的两个理由第一是重装成本。业务跑起来之后重装系统是难免的事系统盘和数据盘分开重装时只动系统盘数据盘原地保留挂载回去就行。第二是 IO 干扰。系统盘的日志写入、包管理器的元数据读写都是随机小 IO和数据盘的顺序大 IO 混在一起会互相拖累。物理上分开哪怕只是不同的盘位、不同的阵列组效果也比全塞一块盘上好。分区方案上我的习惯供参考挂载点建议大小说明/boot/efi512M 到 1GUEFI 引导必需别给太小/boot1G内核更新会堆多个版本太小会装不下swap内存的 0.5 到 1 倍或直接不用内存足够大的业务机可以只留少量应急/100G 到 200G系统和软件包/var单独分50G 起日志容易涨单独分避免撑爆根分区/data剩余全部业务数据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.efiARM 上是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 平台上值得加的# 典型追加参数示例 iommupt pcie_portsnativeiommupt让直通设备走透传模式减少 DMA 转换开销对网卡和阵列卡性能有实际帮助。pcie_portsnative在某些平台上能避免 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 mode802.3ad,miimon100,xmit_hash_policylayer34 # 把两个物理口加进去 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 bond0xmit_hash_policylayer34这一项值得单独说默认的哈希策略只看 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] nameLocal aarch64 Repo baseurlhttp://10.10.20.5/repo/aarch64 enabled1 gpgcheck0 EOF dnf clean all dnf makecachegpgcheck0只建议在内网自建源里用公网源还是要验签的。生成元数据这一步在包更新之后要重新跑别忘了写进发布脚本。6. ARM 平台上最耗时间的部分软件包与依赖前面几步做完系统能跑起来了接下来才是真正的硬仗。我个人的统计是同样的业务从 x86 迁到 ARM装机本身占的时间不到三成剩下的全花在软件适配上。6.1 拿到一个 x86 二进制包时该做什么先别急着想办法跑起来。正确的顺序是确认这个软件有没有官方或社区提供的 aarch64 版本。很多主流开源软件现在都有只是下载页面藏得比较深。如果没有预编译包看能不能从源码编译。这一步要看它的依赖链是否完整有没有用到 x86 特有的指令集或汇编。如果源码里带 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 有很多可选扩展如果编译机和支持的指令集不一致产出的二进制在别的机器上可能非法指令崩溃。跨机器部署时编译参数里要明确指定基线架构不要用-marchnative。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 --cpunodebind0 --membind0把进程固定在一个节点上。但要注意如果单节点的内存不够用强行绑反而会导致 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 几个高频问题的速查表现象优先怀疑快速验证方式虚拟光驱挂载失败ISO 超限或浏览器不兼容换 HTTP 方式提供镜像安装时找不到磁盘阵列卡未配置或处于直通模式进带外管理台看存储配置装完起不来引导安装位置错误SOL 看内核输出停在哪网口灯亮不通VLAN 或 bond 模式不匹配ethtool看速率看 bond 状态yum 装包报架构不匹配镜像里混了 x86 包file查包内容编译到一半被杀并行度过高导致 OOM降低-j数值服务启动即崩64K 页内核不兼容getconf PAGE_SIZE集群节点认证失败时间不同步chronyc sources -v这张表是我自己在多次装机里攒下来的遇到问题先对一遍能省掉不少时间。当然具体情况具体分析表里给的是方向不是结论。最后分享一个个人习惯每装完一台机器我会把这次遇到的非预期情况记在一个文本文件里跟着机器资产编号一起存档。下一次装同型号的时候翻一眼能避开大部分重复的坑。一体机这种整机交付的设备同一批次的机器问题往往高度相似前面踩过的坑后面基本都会再遇到一次。另外提一句装机过程中所有的手工操作只要有第二次的可能就顺手写成脚本。改 BMC 地址、配 bond、装基础包、调内核参数这些都能脚本化。脚本化的意义不只是省时间更重要的是保证多台机器的配置完全一致减少后面“为什么这台正常那台不正常”的排查成本。
