系统补丁和驱动都管了，中间还夹着一层几乎没人碰：物理机的固件与微码到底归谁维护

系统补丁有人管、内核和驱动有人管，夹在它们和硬件之间的那一层，往往从上线那天起就没人再碰过。很多人做运维多年，能一口气背出自己机器的内核版本、驱动版本、补丁基线，却说不出这块主板的 BIOS 是哪一年的、阵列卡固件停在哪个版本、CPU 现在跑的微码是哪一版。不是记性问题，是这一层从来没被纳入任何一张巡检表。

本篇只谈一件事：物理机上「系统之下、硬件之中」的那层固件，到底由谁维护、怎么更新、更新失败了怎么办。不谈机器怎么选，也不谈服务器运维的泛泛流程。

一、一台物理机的软件栈至少有三层：操作系统与驱动、固件（BIOS/UEFI、BMC、网卡与阵列卡与盘固件）、CPU 微码。常规补丁管理只覆盖第一层。

二、CPU 微码是特殊的一层，由内核在启动阶段加载，用来修正处理器层面的已知问题。这类更新可能带来小幅性能变化，也可能修复稳定性问题，所以更新前后必须拿同一组指标对比，不能凭感觉判断。

三、四类固件的更新特性完全不同：BIOS/UEFI 决定启动行为与虚拟化、功耗、风扇策略，刷失败有变砖风险；BMC 是独立供电独立网口的管理面，自己也要打补丁；网卡、阵列卡与盘固件直接压在 IO 路径上，很多看着像驱动问题的故障根因就在这一层，其中盘固件的数据面风险最高。

四、这一层长期没人管，原因就三个：要停机窗口、更新本身有失败风险、责任边界模糊。云主机上这一层根本看不见，也就无从管理，这正是物理机与云主机在运维上的真实差异之一。

五、责任边界必须在采购阶段问清，并且一律写成需向服务商确认：固件由谁维护、更新前是否通知、是否提供维护窗口、更新失败由谁恢复、带外是否可用。动作上要走清单、评估、窗口、备机、分批、回滚、核对这七步。

三层栈里被跳过的那一层

把一台物理机从上往下画，第一层是操作系统、内核、驱动，加上你日常打的各种补丁。第二层是固件：BIOS 或 UEFI、BMC 带外管理芯片、网卡与阵列卡与 NVMe 盘各自的固件。第三层是 CPU 微码，也就是处理器内部那层可以由厂商更新的微程序。常规补丁管理，绝大多数只覆盖第一层。

为什么会这样？因为补丁管理工具盯的是包管理器数据库，扫的是 rpm、deb 那张表。固件根本不在那张表上，它没有包的概念，不通过包管理器安装，卸载也无从谈起。你在系统里跑一遍漏洞扫描，看到的全是第一层的结果，第二第三层的版本号压根不会出现在报告里。看不见，自然就没人管。

说白了，这三层的更新机制完全不是一回事：第一层热补丁也好、滚动重启也好，代价是可控的；第二层通常要重启进专用更新环境，甚至要断电源；第三层每次开机都要由内核重新往 CPU 里塞一次，掉电就丢。机制不同、代价不同、失败后果也不同，用同一套补丁流程去管，本身就不成立。

三层交界的那个位置最容易出问题。系统日志干干净净，驱动版本看着也对，但机器行为就是不对：网卡偶尔闪断一下、某块盘隔几天掉一次、写入到一半速度掉下来、虚拟化特性时有时无。这类现象的共同点是，往上查查不到东西，因为根因在下面一层。

举个典型场景，并非特指某一真实环境：一台机器跑着跑着链路闪断，运维把网卡驱动降了级、把内核换了个版本、把交换机端口也换了，问题依旧。最后进带外界面一看，网卡固件停留在两年前的一个版本，而厂商在这个版本之后修过一条与链路训练相关的已知问题。这种「看着像驱动问题、根因在固件」的情况，在这一层里是常态而不是特例。

所以第一步结论很直白：没有清单就没有治理。不知道当前版本，谈更新、谈风险、谈责任，全是空谈。

CPU 微码为什么特殊：由内核加载，会改行为，也可能改性能

微码是什么？处理器出厂之后，内部那套控制逻辑已经固化在硅片里，但厂商保留了一个口子，可以往 CPU 内部的可编程存储里加载一小段微程序，用来修正已经发现的硬件缺陷，或者打开某些新的能力。人话版：CPU 自己也有一份需要更新的固件，区别在于它不存盘，每次开机都要重新灌进去。

谁加载它？CPU 上电复位的时候，先拿到的是 BIOS 或 UEFI 里内置的那一份微码。操作系统启动的早期，内核的早期微码加载器会再读一次微码包，通常是发行版提供的处理器微码固件包（比如 intel-ucode、amd-ucode 这一类，具体名称以你所用发行版为准），如果里面的版本比当前 CPU 里的新，就把 CPU 里的微码升上去。这条链上任何一环断了，机器就停留在 BIOS 内置的那份。

什么时候生效？早期加载发生在内核启动的最开始，CPU 还在逐个 bring-up 的时候就完成了，这一步之后 CPU 全程跑在新微码上。另外还有运行后加载这条路，可以在系统起来之后再加载，但限制多得多：已经执行过的指令流不受保护，某些情况下内核会拒绝加载，部分场景需要把 CPU 离线再加载。所以真正可靠的还是重启一次走早期加载。

为什么重启之后微码可能又回到旧版本？三个常见原因。第一，微码存在 CPU 内部的易失性存储里，掉电即丢，每次开机都得重新加载，它不像 BIOS 那样写进闪存。第二，你更新了微码包但没有重建 initramfs，启动的时候内核根本没拿到新文件，加载的还是老版本。第三，也是最容易踩的一个：刷了 BIOS 之后，新 BIOS 里内置的那份微码版本可能比你原来由操作系统加载的版本还旧，而操作系统的加载链又恰好没接上，结果刷完 BIOS 一查，微码版本号反而降了。这种情况在做过 BIOS 更新的机器上并不罕见。

版本号在哪读？/proc/cpuinfo 里的 microcode 字段能看到，sysfs 下每个 CPU 的 microcode/version 节点也能读到，启动日志里通常会有一行早期更新到某个 revision 的记录。要注意的是这个数字各家格式不同，不要跨厂商去比大小，也不要跨平台去对数字，只在同一个型号上纵向比。

再说性能这件事。微码更新会改变 CPU 的行为，其中一个重要方向是给内核里的一批安全缓解措施打底。处理器层面与投机执行相关的那些问题，很多缓解手段要求 CPU 先具备对应的微码能力，内核才会把相应的缓解开关打开，比如与分支预测隔离、间接分支预测屏障、缓存刷新相关的那一批机制。这些缓解措施本身是有代价的：额外的序列化、上下文切换时的屏障操作、关键路径上的刷新动作。所以一次「微码加内核」的组合更新之后，性能可能带来小幅变化，方向和幅度取决于你的负载类型，是密集计算还是频繁系统调用，差别很大。这就是「安全与稳定性补丁会改变性能」最典型的一个例子，别听别人说涨了还是跌了，自己跑同一组对比。

但也不必谈之色变。反过来的情况同样存在：新的微码可能提供效率更高的缓解能力，内核因此可以从较昂贵的软件缓解切到较便宜的硬件缓解，性能反而回来一点。还有一些微码更新修的是纯稳定性问题，比如特定指令序列下的异常、某些条件下触发的挂死、特定场景下的错误结果。所以看到「更新微码」就默认等于掉性能，这是把复杂问题简单化了。

还有个在集群环境里特别容易忽略的点：同一批机器如果微码版本不一致，暴露给上层的处理器特性标志就不一致。做虚拟机在线迁移的时候，源端和目的端特性集合对不上，迁移可能被拒绝，或者在迁移之后客户机行为异常；做按特性分发的调度、做二进制按特性选择代码路径的程序，也会踩坑。同一批机器尽量把微码版本对齐，这件事在规划阶段做成本最低。

BIOS 与 UEFI：虚拟化开关、功耗策略和变砖风险

BIOS 或 UEFI 是开机跑的第一棒，负责硬件自检、初始化、把设备表交给操作系统，它本身就是一段写在主板闪存里的固件。它决定的东西，上层改不动，只能接受。

先说与虚拟化相关的那批开关。硬件虚拟化支持（Intel 平台上通常叫 VT-x 与 VT-d，AMD 平台上叫 SVM 与 IOMMU）默认是不是打开的；SR-IOV 能不能用；Above 4G Decoding 开没开；PCIe 通道怎么拆分；NUMA 相关的选项怎么设。这些开关关着的时候，上层看到的现象一律是「不支持」：虚拟化软件起不来、设备直通失败、大 BAR 的加速卡识别不到、SR-IOV 虚拟功能切不出来。表现出来全是软件问题，实际是主板上一个开关的事。

再说功耗与散热策略。C-state 与 P-state 的上限、睿频开关、功耗封顶值、风扇曲线、性能偏好档位，这些直接决定机器在持续负载下的频率行为。同样一颗 CPU，封顶设得紧，跑半小时就降频；风扇曲线设得保守，温度贴着阈值走，也会触发保护性降频。你以为的「机器性能不稳定」，很多时候就是这一层策略的结果。反过来，把功耗策略调激进，噪音和电费又上去了，这又是个需要按业务权衡的事。

启动相关的设置同样要留意。启动项顺序、安全启动的开关与策略、PXE 与网络启动是否允许。顺序错了机器卡在找盘，安全启动策略一变，某些内核或者第三方驱动模块就加载不了，现象是「系统起不来」，但根因不在系统里。

然后是变砖风险。固件更新过程中断电、写错镜像、或者刷了不匹配的包，机器可能直接起不来。这一层没有「回滚一次重启」这种便宜事。常见的恢复手段有几种：双闪存镜像自动切换的设计、主板上的恢复跳线、或者通过带外管理芯片重新刷写。你的平台到底支持哪一种，能不能自己救，这属于采购阶段就该问清的事，别等到真砖了再翻手册。

还有个小坑值得单独提一句：很多平台刷完 BIOS 会把设置重置为出厂默认。你之前调过的虚拟化开关、启动顺序、功耗策略，一刷全没了。表现是「刷完固件之后某些功能突然不好使了」，其实是设置被清了。所以刷之前务必把当前设置逐项截图或记录，刷完立刻核对一遍，这一步省不得。

BMC 自己也是一台要打补丁的小电脑（点到为止）

BMC 是主板上独立于主机 CPU 的一颗小处理器，有自己的固件、自己的内存、自己的网口，靠待机电源供电。主机彻底关机，它照样活着，所以你能远程开关机、挂载安装镜像、看串口输出、读温度和电压传感器。它本质上就是一台藏在服务器里的小电脑。

既然是一台独立的小电脑，它就有自己的固件版本、自己的安全公告、自己的补丁节奏，历史上也出现过默认凭据一类的问题。它的特殊性在于：它挂了，或者被人进去了，你连重装系统都做不了，远程救援这条路直接断掉。所以它的固件版本必须进你的清单，它的补丁也要排窗口，不能因为它「不算业务系统」就跳过。

更新 BMC 固件还有一个操作上的注意点：更新过程中带外访问本身会短暂中断，这段时间你失去远程手段，所以窗口要选在你有备选接触方式的时候。带外的隔离与访问控制怎么设计，本站另有文章专门讲，这里不展开，只提醒一句：它自己也是要打补丁的。

网卡、阵列卡与 NVMe 固件：很多「驱动问题」其实在这一层

这三类卡的本质，是「带 CPU 的小设备」。它们自己跑着固件，操作系统里的驱动只是跟这块固件对话的翻译。翻译没问题，不代表对面那台小设备没问题。

网卡固件影响的东西比多数人想的多：链路协商与训练的过程、多队列与各种卸载能力（分段卸载、大接收卸载、校验和卸载）、高精度时间同步的行为、网络启动时的工作方式。固件有缺陷时的表现特别像软件问题：链路隔一段时间闪断一下、特定包长下丢包、某个卸载打开之后吞吐反而异常、时间同步的抖动变大。换驱动版本有时能绕开触发条件，但根因还在固件里，换环境就会复发。

阵列卡固件影响的是另一组行为：磁盘超时策略、写缓存策略、巡检读取的节奏、重建的优先级、盘组状态机的判定。它的典型故障现象是「掉盘」、重建卡在某一个百分比不动、或者在掉电保护模块状态变化之后写策略被悄悄改掉，而你在系统里完全看不到这个变化。

NVMe 控制器固件影响的是队列与中断行为、掉盘之后的复位流程、温度与限速阈值、以及 SMART 里报出来的那些属性值。有些「写着写着就慢下来了」，是盘固件触发的温度保护限速，不是文件系统、也不是调度器的问题。还有一类是盘在超时之后复位流程处理不当，主机侧看到的就是设备消失又出现。

判断路线上有句话值得记住：先看版本，再看发布说明。把当前固件版本记下来，去翻厂商的发布说明，看有没有跟你现象对得上的条目。很多发布说明里写得清清楚楚「修复了某条件下链路中断的问题」，你的现象能对上，那就不用再在驱动层打转了。上来就换内核、换驱动，是最常见的无效动作。

版本从哪读？网卡用 ethtool -i 通常能读到固件版本；阵列卡需要厂商提供的命令行工具；NVMe 盘用 nvme id-ctrl 或者 smartctl -i 能看到固件版本。要提醒的是，带内读到的信息是有限且不完整的，尤其是阵列背后的物理盘、某些板卡的从属固件，往往只能进带外界面或者用厂商的巡检工具才看得到。这也是为什么清单这件事不能只靠在系统里敲几条命令。

盘固件为什么最该谨慎：它直接压在数据面上

前面那些固件刷失败，最坏的结果是机器起不来、网卡不通，业务中断但数据还在。盘固件不一样，它直接压在读写路径上，出问题就是数据面出问题。

三个理由决定了它要格外谨慎。第一，更新过程本身常常要求设备进入独占或复位状态，阵列里有多块盘的时候还要协调顺序，这个操作窗口本质上是 IO 停顿窗口，对在线业务来说就是一次抖动。第二，盘固件很多型号不支持降级，刷上去就下不来，这是单向门，出问题时你想回退都回不去。第三，固件变了之后盘的行为也跟着变：错误恢复超时、限速阈值、掉盘后的复位流程，主机侧会把这当成一块「不太一样的盘」来对待，极端情况下会触发盘组降级，而一旦降级重建，又会带来新一轮的 IO 压力和时间成本。

所以在优先级排序上，盘和阵列卡属于「影响面大、失败后果重」这一类，必须最先纳入治理、最先做评估与验证，但动作上要最慢：先在同型号的备机或者空盘上验证，再挑一台非关键节点刷，观察一段时间，确认没问题再分批。千万别一次性给整个阵列的所有盘都刷掉，那等于把全部鸡蛋放在一次操作里。

还有一句听起来像废话但必须写下来的话：盘固件更新之前，先确认备份完整且可恢复。备份存在和备份能恢复是两件事，这一层的操作一旦失手，备份就是唯一的底。

长期没人管的三个原因：窗口、风险、责任边界

原因一，需要停机窗口。系统补丁可以热打，实在不行可以深夜滚动重启，业务侧几乎无感。固件更新通常是重启进专用环境，有些还要断电或者进带外操作，一次更新意味着一次明确的业务中断。跟业务方排窗口的沟通成本，比刷固件本身高得多。拖着拖着，就拖到没人再提了。

原因二，更新本身有失败风险。补丁打坏了，回滚一次重启就回来了；固件刷坏了，可能是设备起不来、板卡不识别、数据读不到。对负责这件事的人来说，没出事是应该的，出了事是自己的，理性选择自然是不动。这不是责任心的问题，是激励结构的问题。

原因三，责任边界模糊。这一层到底归谁？整机租用时，服务商说系统是客户自己管的，客户说硬件是你们的；托管时更明显，机器是客户的，但如果服务商代维，刷坏了谁赔、谁恢复？没人提前写清楚，出了事就只能靠事后扯皮，而扯皮的结果通常是谁也不再提这件事。

三个原因叠在一起，结果就是：只要机器还能跑，这一层就没人碰。直到某天出现一个用驱动解释不了的故障，大家才第一次打开带外界面去看版本号，而这时候看到的往往是一个三年前的日期。

责任边界要在采购阶段问清：谁维护、谁通知、谁恢复

五个问题必须在下单之前问清，并且最好写进合同或者工单流程里：固件由谁维护、更新前是否会通知、是否提供维护窗口、更新失败由谁负责恢复、带外管理是否可用。这五条里任何一条含糊，后面都会变成扯皮的起点。

三种形态下的典型分界是这样的，具体仍以合同约定为准。整机租用：硬件产权在服务商，BIOS、BMC、板卡固件通常由服务商侧维护，但你要确认这一项是否包含在你所购买的服务范围内，不要默认包含在里面。托管或者自购机器上架：硬件是你的，固件责任就是你的，服务商通常只提供带外接入与上下架协助，最多代为操作，操作的风险承担方仍是你。云主机：这一层你根本看不见，也管不着，由云平台自己维护，你只对客户机内部负责。

还要多问一句容易被漏掉的：服务商更新固件的时候，会不会顺带改变你的 BIOS 设置，会不会把 CPU 微码版本降回去？前面说过，BIOS 内置微码版本和操作系统加载的版本不是一回事，一次 BIOS 更新可能让微码悄悄回退。这类「更新引发的更新」最容易被忽略，也最容易在事后变成一个说不清的性能变化。

落到具体选型上，像一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，处理器的虚拟化特性是否全开、BIOS 是否开放给客户自行配置、带外是否可用、固件维护是否包含在服务范围内，这几条要逐条向服务商确认，不要想当然。价格层面一律需实时询价，以官网实时报价与签约合同为准。

更新流程：清单、评估、窗口、备机、分批、回滚、核对

第一步，建清单。每台机器一行，字段至少包括：机型与序列号、BIOS 或 UEFI 版本、BMC 版本、网卡型号与固件版本、阵列卡型号与固件版本、每一块盘的型号与固件版本、CPU 型号与当前微码版本。这张表是整个治理工作的地基，没有它，后面每一步都是盲操作。清单建好之后，还要定期回头更新，它是一次性建立、长期维护的东西。

版本从哪读，前面分散说过，这里汇总一下：BIOS 用 dmidecode 读 SMBIOS 里的 BIOS 信息段；微码看 /proc/cpuinfo 里的 microcode 字段、sysfs 下 CPU 的 microcode/version 节点，以及启动日志里早期更新的那行记录；网卡用 ethtool -i；阵列卡与盘需要厂商的命令行工具；BMC 用 ipmitool mc info 或者直接进带外界面。要承认一个现实：带内读到的信息是有限且不完整的，尤其是阵列背后的物理盘、某些板卡的从属固件、BMC 的详细版本，很多时候必须进带外界面或者厂商的巡检工具才看得到。所以清单不能只靠在系统里敲几条命令就完事。

第二步，评估影响。把「这次更新了什么」和「会影响什么」白纸黑字写清楚：是修安全问题、修稳定性问题，还是修兼容性问题？影响的是启动行为、虚拟化能力、IO 路径，还是功耗散热？然后按「影响面乘以失败后果乘以能否回滚」排优先级。

排序上给一个明确建议：先处理数据面风险高的，也就是盘和阵列卡，注意这里是「先纳入治理、先做验证」，不是「先大批量刷」；再把管理面也就是 BMC 处理掉；BIOS 放在后面做，因为它改动面最大、直接影响能不能开机。这个顺序的依据是失败后果的严重程度，不是工作量大小。

第三步，排窗口。窗口要有明确的起止时间、联系人、以及回退的触发条件——比如多长时间内起不来就走恢复流程，哪几个指标异常就中止推进。窗口长度要覆盖「更新加核对加观察」，不要只按更新时间来排，那样会把自己逼到没有退路的境地。

第四步，备机验证。同型号的备机先来一遍，没有备机就挑一台非关键节点，跑一段时间再看。这一步的作用是验证两件事：更新流程本身在你的环境里能不能走通，以及更新之后的行为有没有异常。

第五步，分批推进。按一台、小批、大批的节奏走，批与批之间留观察期。别追求一次推完，固件更新的风险是随批量线性上升、但排查难度是指数上升的。

第六步，留回滚。刷之前保存旧固件镜像，记录当前全部设置，BIOS 那部分尤其要逐项截图。哪些能回滚要提前搞清楚，这是这一步的核心：BIOS 多数平台能刷回上一个版本；微码可以通过卸载微码包、或者禁用内核加载来回退；网卡固件一般能重刷，但有些工具不支持降级；盘固件很多型号不支持降级，等于单向门，只能靠备份兜底。能回滚不等于可以大胆，不能回滚就等于必须更保守。

第七步，更新后核对与观察。先核对版本号，确认它真的是你预期的那个版本，别以为刷完了就是刷对了。然后用更新之前同一组指标做对比：吞吐、延迟、温度、错误计数。同一组指标、同样的负载条件、同样的观测时长，这样才能说清楚变化。别凭感觉说「好像变慢了」或者「好像变快了」，感觉在这一层是最不靠谱的东西。

云主机上看不见这一层，这也是物理机和云主机的真实差别之一

云主机里，你拿到的是虚拟化之后的一台客户机：BIOS 是虚拟出来的，微码版本由宿主机决定，网卡是虚拟设备，盘在远端。你读不到真实的固件版本，也不需要为它排窗口，更不会有变砖这种风险落在你头上。

好处很明显：这一层的维护成本被平台吃掉了。代价同样明显：你也彻底失去了对这一层的控制权。宿主机侧什么时候更新、更新到什么版本、更新之后性能特性怎么变，你既不知道也管不了，只能接受平台给出的结果。遇到需要特定处理器特性、需要特定虚拟化开关、需要对一批机器的微码版本做对齐的场景，云主机给不了你。

反过来看，物理机的价值恰好就在这里：这一层是可见的、可管的、可调的。你想要某个虚拟化开关按要求打开、想要特定的功耗与风扇策略、想要同一批机器的微码版本完全一致、想要在阵列卡上调整超时策略，只有物理机能做。但这份自由是带账单的——你得自己承担维护它所需要的工作量、窗口和风险。所谓物理机运维更重，很大一部分就重在这里。

所以选择物理机的时候，「固件归谁维护」不是一个可以拖到运维阶段再议的细节。它决定了你之后会不会被这一层反咬一口，也决定了出事的时候你能不能找到人。

避坑：动固件最容易做错的四件事

坑一：没有清单就开刷。为什么坑：你不知道自己在从哪个版本刷到哪个版本，也就无法判断这次更新到底解决了什么、会不会引入新的变化，出问题之后连回退目标都没有。怎么避：先把清单建起来，型号加当前版本加厂商最新版本三列齐全，再谈动作。清单不完整的时候，宁可不刷。

坑二：把微码更新当成纯安全动作，不做性能对比。为什么坑：微码配合内核缓解措施，是有可能改变性能表现的，方向也不是单向的。不做对比，出问题时你无法判断是这次更新带来的，还是业务本身波动；想回退的时候又说不清依据。怎么避：更新前后用同一组指标对比，吞吐、延迟、温度、错误计数四项固定下来，同样负载同样时长，拿数据说话。

坑三：刷 BIOS 不备份设置、不留旧镜像。为什么坑：刷完设置被重置，之前调过的虚拟化开关、启动顺序、功耗策略全部丢失，表现出来是「功能突然不好使了」，排查方向很容易跑偏；不留旧镜像则意味着想回退时手上没有目标版本。怎么避：刷之前逐项截图，把旧固件镜像下载到本地妥善保存，刷完第一件事就是核对设置项。

坑四：一次性全量推送。为什么坑：固件更新的失败概率不是零，全量推进等于把风险一次性放大到全部节点，而且批量出问题时排查难度会指数上升，你连「是哪一批先出的问题」都分不清。怎么避：一台验证、小批观察、再大批，批与批之间留出观察期，观察期内盯住错误计数和延迟这两类最敏感的指标。

物理机固件这件事，最该先问清楚的六个问题

1. 我现在的 BIOS、微码、网卡与盘固件分别是什么版本，从哪能读到？BIOS 版本用 dmidecode 读 SMBIOS 里的 BIOS 信息段；微码版本看 /proc/cpuinfo 的 microcode 字段、sysfs 下 CPU 的 microcode/version 节点，以及启动日志里早期更新那一行；网卡固件版本用 ethtool -i 通常能直接看到；阵列卡和盘需要各自的厂商命令行工具；BMC 用 ipmitool mc info 或进带外界面。要接受一个现实：带内读到的信息有限，阵列背后的物理盘、部分板卡的从属固件，往往只能进带外或厂商巡检工具才能看全。所以清单不要指望几条命令搞定。

2. 更新微码一定会导致性能下降吗？不一定，两个方向都有可能。微码更新可能让内核打开某些安全缓解措施，而这些缓解本身带来额外开销，于是性能出现小幅变化；也可能新微码提供更高效的硬件缓解能力，让内核从较昂贵的软件缓解切过来，性能反而回来一点；还有些微码更新纯粹修稳定性问题，对性能没有可感知影响。关键在于幅度和方向取决于你的负载类型，不能套别人的结论，只能自己在同一组指标上对比。

3. 为什么重启之后微码版本号又变回去了？最常见的是三种情况。微码存在 CPU 内部的易失性存储里，掉电即丢，每次开机都要由内核重新加载，加载链断了就回到 BIOS 内置那份；更新了微码包但没有重建 initramfs，启动时内核根本没拿到新文件；刷了新 BIOS 之后，BIOS 内置的那份微码版本比操作系统原来加载的旧，导致版本号反而下降。排查顺序建议是先看启动日志有没有早期更新记录，再确认 initramfs 里有没有微码包，最后核对 BIOS 内置版本。

4. 盘固件能不能回滚，刷之前要准备什么？多数盘型号不支持固件降级，刷上去就下不来，这一层要按单向门来对待。准备动作有三件：确认完整且可恢复的备份，这一步没有商量余地；保存当前固件版本信息，作为万一需要更换硬件时的对照；确认更新过程需要设备进入什么状态、阵列里多块盘的操作顺序是什么，把 IO 停顿的时间窗口算清楚。能验证就在同型号备机或空盘上先走一遍完整流程。

5. 整机租用时这一层到底归谁，采购时该问哪几句？通常的划分是：整机租用硬件产权在服务商，BIOS、BMC、板卡固件多由服务商侧维护，但要确认是否包含在你购买的服务范围内；托管或自购上架的机器，固件责任在使用方，服务商通常只提供带外接入与上下架协助。采购阶段要问清五句：固件由谁维护、更新前是否通知、是否提供维护窗口、更新失败由谁恢复、带外是否可用。像一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，处理器虚拟化特性是否全开、BIOS 是否开放给客户自行配置、带外是否可用、固件维护是否包含在内，都需逐条向服务商确认，价格需实时询价。

6. 云主机需要关心这一层吗，什么时候还是得用物理机？云主机上这一层你既看不见也管不着，BIOS 是虚拟的、微码由宿主机决定、网卡是虚拟设备、盘在远端，维护成本被平台承担了。代价是控制权也一并让渡：宿主机侧什么时候更新、更新到什么版本，你无法干预。所以需要对一批机器的微码版本做对齐、需要特定虚拟化开关按要求配置、需要调整阵列卡超时策略、需要自定义功耗与风扇策略时，云主机给不了，还是得用物理机。选之前把「固件维护责任与通知机制」写进问清单，比事后扯皮划算得多。

补上固件这一层，物理机的运维才算完整

这一层的治理没有捷径，就三句话：先建清单，没有清单就没有治理；按「影响面乘以失败后果乘以能否回滚」排序，数据面风险高的先纳入治理先验证，BIOS 放在后面；任何更新都要有窗口、有备机、有回滚路径，更新前后用同一组指标对比，不凭感觉下结论。至于责任边界，别指望出问题那天再谈清楚，采购阶段就把固件由谁维护、更新前是否通知、是否提供维护窗口、更新失败由谁恢复、带外是否可用这五条问明白并写下来。像一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，处理器虚拟化特性、BIOS 是否开放、带外是否可用、固件维护是否包含在服务范围内，均需向服务商确认，价格一律需实时询价，具体以签约时最新报价与合同为准。把这一层接进你的运维体系，物理机才算是真的在你手上；不接，它就只是一台暂时还没出事的机器。

本文关于固件层次与更新流程的技术出处

处理器微码的早期加载机制与微码包随发行版固件包分发的方式，以所用发行版官方文档与内核文档为准，常见路径为 intel-ucode、amd-ucode 一类固件包与 initramfs 的打包流程；微码版本读取路径以 /proc/cpuinfo、sysfs 下 CPU 的 microcode/version 节点与启动日志为准。BIOS 或 UEFI 的更新方式、是否支持回退、设置是否会被重置，以及 BMC 的固件更新与恢复手段，随平台与厂商设计而不同，需向服务商确认。网卡、阵列卡与盘的固件版本读取方式（ethtool、nvme、smartctl 及厂商命令行工具）以所用工具与厂商文档为准，是否支持降级需向厂商确认。表中「通常谁来维护」一列为常见的责任划分惯例，不构成对任一服务商的承诺描述，实际以合同约定为准。

涉及一万网络的部分，处理器虚拟化特性是否全开、BIOS 是否开放给客户自行配置、带外是否可用、固件维护是否包含在服务范围内，均需向服务商确认；品牌与业务信息参见官网 https://www.idc10000.net/，深耕 IDC 19 年（成立于 2007 年）。价格一律需实时询价，具体以签约时最新报价与合同为准。文中所述流程为通用的固件治理思路，非特指某一真实环境，不承诺任何未在官网明示的服务内容与时效。