前几天在一个服务器运维交流群里，又有人问：怎么才能从一台机器上一次性拿到厂商、型号、序列号、BIOS 版本、内存槽位和当前功率？底下有人回“跑 dmidecode”，有人回“开 IPMI 自己拉”，还有人直接说“上 BMC 网页慢慢点”。我当时给的答案是：把 DMTF 这两套协议搞清楚，这问题已经解决一大半——一套是 SMBIOS，负责静态资产信息；一套是 Redfish，负责动态状态和带外管理。这篇是我准备写的 DMTF 相关协议系列第一篇，就拿 Redfish 和 SMBIOS 这两个最常用的协议，把它们“各自管什么、怎么配合、怎么落地”完整聊一遍。适合服务器运维、IDC 基础设施建设、硬件兼容性测试，以及正在做资产系统或监控平台对接的朋友参考。
1. 开篇先把底摸清：DMTF 管着哪些服务器管理的事
1.1 为什么这两年又得回头聊 DMTF 协议
DMTF 全称 Distributed Management Task Force，也就是分布式管理任务组。很多人第一次听到这个组织，是因为见过它出的某一个标准，但没太在意。实际上服务器管理领域绕不过去的好几个关键规范，SMBIOS、Redfish、CIM/WBEM，甚至曾经的 DASH，都是 DMTF 在维护。
这几年大家重新关注 DMTF，核心原因很直接：传统服务器管理方式已经不够用了。我举个例子，以前机房里有几百台机器，用 IPMI 拉硬件信息虽然能跑，但那玩意儿是二进制协议，返回的数据不直观，想要对接自己的监控平台或者资产管理工具，得自己写解码逻辑。而且不同厂商的网卡、功率、温度数据，字段定义还不完全一样。
Redfish 出来之后，整个思路变了。它直接把带外管理接口做成了 HTTP 接口，返回 JSON 数据，像访问普通 Web API 一样就能拿到服务器状态。SMBIOS 则是从另一个维度补位，它解决的是“操作系统内部看到的硬件信息”，不需要带外网络，开机就能读。一个是静态、带内、本地可读，一个是动态、带外、网络可读，两者正好形成互补。
1.2 Redfish 和 SMBIOS，两张牌各管哪一段
我经常跟同事用一个比喻：一台服务器相当于一个人，SMBIOS 是写在身份证上的静态信息——姓名、籍贯、证件号，基本不变化；Redfish 则是体检报告和实时监护数据——心率、血压、体温，随时在动，而且能通过远程方式查看。
对应到实际场景，SMBIOS 主要在操作系统层面用，比如 Linux 下的 dmidecode 工具、Windows 下的 msinfo32，数据来源是固件在启动时留在内存里的 DMI 表。它包含厂商、产品型号、序列号、UUID、BIOS 版本、内存条信息、CPU 信息等，适合做资产入库、硬件变更审计、序列号追溯。
Redfish 则跑在 BMC 上，走网络接口，哪怕服务器操作系统挂掉了，只要 BMC 还活着，你依然能通过 Redfish 看到电源状态、温度、风扇转速、功耗，甚至远程开关机、挂载镜像、升级固件。它适合做生产环境的带外监控、自动巡检、故障诊断和批量操作。
这两套协议不是替代关系。真实落地的时候，往往先靠 SMBIOS 把每一台机器的静态资产建档，再靠 Redfish 把动态状态持续采集上来，两边数据一拼，才算把一台服务器管起来了。
2. SMBIOS：服务器固件里那张“硬件户口本”
2.1 别被结构类型吓到：Type 0/1/2/3/4/17 分别说什么
SMBIOS 标准里有一个核心概念叫 Structure Type，也就是结构类型。初次接触的人会被 Type 0、Type 1、Type 127 这些数字搞晕，其实它就是一个编号体系，每一种编号对应一类硬件信息。我列了一张常用表，基本覆盖日常资产管理需求：
| 结构类型 | 含义 | 关键字段 |
|---|---|---|
| Type 0 | BIOS 信息 | 厂商、版本、发布日期、BIOS 起始地址 |
| Type 1 | 系统信息 | 厂商、产品名、序列号、UUID、SKU |
| Type 2 | 基板信息 | 主板厂商、型号、序列号 |
| Type 3 | 机箱/整机信息 | 机箱类型、资产标签、机箱序列号 |
| Type 4 | 处理器信息 | CPU 厂商、型号、频率、核心数、线程数 |
| Type 7 | 缓存信息 | L1/L2/L3 缓存大小、结构 |
| Type 17 | 内存设备 | 内存类型、容量、频率、序列号、槽位 |
| Type 41 | 设备类型 | 板载设备、PCIe 设备类型与状态 |
| Type 127 | 结束标记 | 表示结构列表到此结束 |
日常资产盘点用到最多的就是 Type 1、Type 2、Type 4 和 Type 17。Type 1 能拿到整机序列号和 UUID，Type 2 能确认主板信息，Type 4 和 Type 17 用来统计 CPU 和内存配置。
这里有一个容易忽视的点：SMBIOS 结构类型虽然全球统一，但不同厂商往里填的字段完整度差别很大。有的服务器厂商会在 Type 1 里把产品名写得很规范，比如 PowerEdge R750、SR650 V2，但也有厂商只写一个非常含糊的内部代号，这时候还需要结合 Type 2 和 Type 3 的信息综合判断。所以做资产系统的时候，不要只依赖某一个字段，多取几个字段做交叉校验更靠谱。
2.2 实操：Linux 下把 SMBIOS 信息读出来
Linux 下最常用的 SMBIOS 读取工具是 dmidecode，几乎所有的发行版软件源里都有。装好之后，几条命令就能把关键信息捞出来：
# 读取系统整体信息（Type 1） dmidecode -t 1 # 读取主板信息（Type 2） dmidecode -t 2 # 读取 CPU 信息（Type 4） dmidecode -t 4 # 读取内存信息（Type 17） dmidecode -t 17如果不想看完整结构，只想拿某个字段，可以用-s参数直接取字符串，这个在写脚本的时候特别方便：
dmidecode -s system-manufacturer dmidecode -s system-product-name dmidecode -s system-serial-number dmidecode -s system-uuid dmidecode -s bios-version除了 dmidecode，Linux 内核还会把一部分 DMI 信息暴露在/sys/class/dmi/id/目录下，比如product_name、product_serial、bios_version。这种方式不依赖额外工具，读取速度也更快，适合在脚本里直接读取：
cat /sys/class/dmi/id/product_name cat /sys/class/dmi/id/product_serial cat /sys/class/dmi/id/bios_version做批量资产采集的时候，我一般会配合 ssh 循环执行，把每台机器的信息汇总成 CSV。比如这样一个小例子：
while read host; do echo -n "$host," ssh "$host" "dmidecode -s system-manufacturer; dmidecode -s system-product-name; dmidecode -s system-serial-number" | tr '\n' ',' echo "" done < servers.txt > assets.csv这种采集方式不需要操作系统上装 agent，只要 SSH 能通，就能拿到完整的资产信息。对于已有操作系统运行的老旧机器，是最快的摸底手段。
2.3 SMBIOS 读数的三个经典坑
第一坑：虚拟机里的 SMBIOS 信息会被虚拟化软件改写。在 VMware、Proxmox、Nutanix 这类虚拟化平台上，默认看到的产品名往往是“VMware Virtual Platform”或者“KVM”这类字样，序列号也可能变成虚拟机的 UUID。这不能怪厂商，因为虚拟化平台本来就会拦截并改写 DMI 数据。碰到这种情况，要在宿主机层面去读取物理硬件的 SMBIOS，而不是在虚拟机里读。
第二坑：同一个字段不同厂商的写法规格不同。比如内存信息，有的厂商 Type 17 里会写清楚 Part Number 和序列号，有的厂商则留空。又比如机箱资产标签，Dell 喜欢写到 Type 3，Lenovo 可能写到 Type 11 OEM 字符串里。做兼容性比较多的朋友应该深有体会，所以解析的时候不能假设所有字段都有值，代码里必须做空值兜底。
第三坑：UUID 字段的字节序问题。这个问题在后面的常见问题部分我会展开讲，这里先提醒一句：SMBIOS Type 1 里的 UUID 格式跟 RFC 4122 标准 UUID 不是完全一致的，直接用 dmidecode 看到的结果和 Redfish 接口返回的 UUID 有可能会对不上。不是数据错了，而是字节序转换规则不同。
3. Redfish：让带外管理接口长成 REST 风格是什么体验
3.1 为什么大家要放弃 IPMI 投奔 Redfish
在 Redfish 之前，带外管理几乎就是 IPMI 的天下。IPMI 本身非常稳定，很多老机房到现在还在跑，但它的体验确实跟不上时代了。IPMI 走的是 RMCP+ 协议，默认 UDP 623 端口，返回的数据是二进制结构，想拿到一条内存信息还要按偏移量手动解析，开发效率很低。
Redfish 最大的改变，是把整个带外管理数据模型做成了基于 RESTful 架构的 HTTP/HTTPS 接口，数据格式统一使用 JSON，并且用 Schema 来描述资源结构。这意味着什么呢？意味着你可以像调用微信公众号接口、支付接口一样，用 curl、Python requests、甚至浏览器直接去请求服务器 BMC，拿到结构化的数据。前端监控页面要展示温度曲线，直接拉一次 Redfish Thermal 接口然后画图就行。
Redfish 还有一个很实用的能力叫事件订阅，也就是 EventService。BMC 可以主动把新事件推送到你指定的 Webhook 地址，比如电源异常、风扇故障、温度过高，这些事件会实时推送，不用你反复去轮询。这个能力对监控告警来说非常省事，我在后面的实操部分会给出一个订阅示例。
3.2 入门 Redfish 先背下这套资源树
Redfish 的 URL 结构可以用“资源树”来理解，根节点固定是/redfish/v1/。从根节点出发，最常见的就是这几个主干：
| 资源路径 | 作用 |
|---|---|
| /redfish/v1/ | 服务根入口，列出所有服务 |
| /redfish/v1/Systems/ | 计算机系统，也就是逻辑服务器 |
| /redfish/v1/Chassis/ | 机箱/硬件容器，包含电源、温度、风扇 |
| /redfish/v1/Managers/ | BMC 管理控制器本身 |
| /redfish/v1/AccountService/ | 账号服务，管理本地用户 |
| /redfish/v1/SessionService/ | 会话服务，负责登录令牌 |
| /redfish/v1/UpdateService/ | 固件更新服务 |
| /redfish/v1/EventService/ | 事件服务，支持订阅推送 |
在 Systems 下面，每一台逻辑服务器会有一个 Id，比如"1"或者"System.Embedded.1"，这取决于厂商实现。访问/redfish/v1/Systems/1就能拿到这台服务器的完整信息，里面包含 AssetTag、Manufacturer、Model、SerialNumber、ProcessorSummary、MemorySummary、PowerState 这些字段。
在 Chassis 下面，每一台物理机箱也会有对应的子资源，比如/redfish/v1/Chassis/1/Thermal返回温度传感器和风扇数据，/redfish/v1/Chassis/1/Power返回功耗和电源状态。如果你只需要资产信息，一般只要访问 Systems 就行；如果你要做硬件健康监控，Thermal 和 Power 是重点。
3.3 实操：curl 五分钟把服务器健康状态抓出来
假设你有一台带 BMC 的服务器，IP 是192.168.10.11，BMC 管理账号是admin，密码是admin123。先用最基本的 Basic Auth 试试根路径是否通：
curl -k -u admin:admin123 https://192.168.10.11/redfish/v1/注意我这里加了-k参数，因为大多数 BMC 默认使用的是自签名证书，不加-k会报证书校验失败。这一步如果能正常返回 JSON，说明 Redfish 服务已经在运行。
然后看系统信息：
curl -k -u admin:admin123 https://192.168.10.11/redfish/v1/Systems/1 | jq .加了jq是为了格式化 JSON，实测中如果字段太多，可以只筛选关键字段：
curl -sk -u admin:admin123 https://192.168.10.11/redfish/v1/Systems/1 \ | jq '{Id, Manufacturer, Model, SerialNumber, PowerState, CPU: .ProcessorSummary.Model, MemGB: .MemorySummary.TotalSystemMemoryGiB}'接下来抓机箱功耗和温度。不同厂商的路径可能略有差异，但大体都是走 Chassis 资源下面的 Thermal 和 Power：
curl -sk -u admin:admin123 https://192.168.10.11/redfish/v1/Chassis/1/Power | jq '.PowerControl[0] | {PowerConsumedWatts, PowerCapacityWatts}' curl -sk -u admin:admin123 https://192.168.10.11/redfish/v1/Chassis/1/Thermal | jq '.Temperatures[] | {Name, ReadingCelsius, Status}'如果发现Systems/1返回 404，说明这台机器的 System Id 不一定是1。可以先访问/redfish/v1/Systems看集合里到底有哪些成员，再按返回的实际 Id 去请求。这是我刚开始用 Redfish 时踩得最频繁的坑。
3.4 进阶：Python 巡检脚本连捞一整个机柜
curl 适合临时调试，但只要机器数量一多，还是要写脚本。DMTF 官方维护了一个redfishPython 库，封装了会话管理、认证、请求重试这些重复工作，拿来写巡检脚本很顺手。如果不想引入额外依赖，直接用requests也能做。
我用一个简化版示例说明批量巡检的思路，脚本会遍历 BMC 列表，去/redfish/v1/Systems/1拉资产和运行状态：
import requests import json import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) BMC_LIST = ["192.168.10.11", "192.168.10.12", "192.168.10.13"] USERNAME = "admin" PASSWORD = "your-password" # 建议改为环境变量或密钥管理 def get_system_summary(bmc): base_url = f"https://{bmc}/redfish/v1" with requests.Session() as sess: sess.auth = (USERNAME, PASSWORD) sess.verify = False resp = sess.get(f"{base_url}/Systems/1", timeout=10) resp.raise_for_status() data = resp.json() return { "bmc_ip": bmc, "model": data.get("Model"), "serial": data.get("SerialNumber"), "power_state": data.get("PowerState"), "cpu": data.get("ProcessorSummary", {}).get("Model"), "mem_gb": data.get("MemorySummary", {}).get("TotalSystemMemoryGiB"), } if __name__ == "__main__": results = [] for ip in BMC_LIST: try: results.append(get_system_summary(ip)) except Exception as exc: results.append({"bmc_ip": ip, "error": str(exc)}) for item in results: print(json.dumps(item, ensure_ascii=False))这里用 Session 而不是裸请求，是为了复用连接，减少 TCP 握手开销。另外在 BMC 数量较多的时候，requests默认每请求都重新建连会慢很多，用 Session 是第一个有效优化手段。
如果你还想让巡检更省事一点，Redfish 支持$expand参数。比如直接请求：
curl -sk -u admin:admin123 "https://192.168.10.11/redfish/v1/Systems?$expand=." | jq '.Members[] | {Model, SerialNumber, PowerState}'这会把集合里的每个成员详细数据直接嵌在返回结果里，省去了逐个请求成员详情的步骤。不过注意，$expand=.返回的数据体量会大不少，BMC 解析起来也慢一些。在大型机房里，我会控制并发数，或者只在数量少于几十台的场景下使用。
4. 落地上手：工具选型、认证配置与安全边界
4.1 Redfish 常用工具横向对比
接触 Redfish 的人常常纠结到底用哪种工具，我的建议是分场景，别只押一种。下面这张表是我自己平时常用的工具组合：
| 工具 | 适用场景 | 备注 |
|---|---|---|
| curl + jq | 单台调试、临时验证、写简单脚本 | 几乎任何机器都有 |
| redfish Python 库 | 批量巡检、平台对接开发 | DMTF 官方维护，支持 Schema 校验 |
| requests + python | 轻量定制化采集 | 不依赖第三方 redfish 库，灵活 |
| PowerShell + Invoke-RestMethod | Windows 环境下快速验证 | 原生支持 REST，写起来也快 |
| Postman / Apifox | 接口开发调试 | 适合看返回结构、测试 Token |
| 厂商 CLI（racadm / ilorest 等） | 厂商特有字段设置 | 只能配合自家硬件使用 |
如果你是刚上手，我建议先装一个 Postman，把所有 GET 请求都试一遍，把返回结构看清楚。等到要写自动化脚本的时候再用 Python redfish 库。
这里还要推荐一个用于没有物理机的练手方案：DMTF 官方有开源的 Redfish Interface Emulator，可以跑在本地，模拟一套标准的 Redfish 资源树，你在上面做认证测试、接口联调都没问题。我自己在开发监控脚本的时候，就经常先在模拟器上把逻辑调通，再拿到真机上去跑，省了不少现场调试的时间。
4.2 认证配置与账号安全我这么设置
Redfish 一般支持两种认证方式：Basic Auth 和 Session Auth。Basic Auth 就是每次请求都在 Header 里带上用户名密码，简单直接，但密码会反复出现在网络请求中，而且 BMC 每次都要做一次认证校验，性能也不好。
更推荐的做法是先用登录接口换取 Session Token。具体流程是请求POST /redfish/v1/SessionService/Sessions，带上用户名和密码，成功后返回的X-Auth-Token后续放在请求头里用：
# 1. 登录获取 token curl -sk -u admin:admin123 -X POST \ https://192.168.10.11/redfish/v1/SessionService/Sessions \ -H "Content-Type: application/json" \ -d '{}' # 2. 使用 token 访问 curl -sk https://192.168.10.11/redfish/v1/Systems/1 \ -H "X-Auth-Token: <上一步返回的token>"Session Token 有有效期，也能主动注销，整体比 Basic Auth 安全一些。账号安全方面，我的底线是三条：第一，拿掉所有默认账号和默认密码；第二，BMC 管理口只放在独立管理网段或者管理 VLAN，绝对不能直接暴露到公网；第三，给关键账号配置登录失败锁定策略，防止被暴力试密码。
证书的问题也不能忽略。很多 BMC 出厂自带的 SSL 证书是自签名的，企业环境里最好能换成你们自己的 CA 签发的证书。如果暂时换不了，至少要让脚本在连接时做好证书校验策略，不能因为是内网就无脑跳过校验。
4.3 SMBIOS 与 Redfish 怎么配合落地资产管理
资产管理最忌讳的是“只用一种数据源”。我曾经见过一个项目，一开始只靠 Redfish 拉设备信息，后来发现部分老服务器的 BMC 固件版本太旧，Redfish 接口返回的 SerialNumber 字段是空的。这时候如果旁边没有 SMBIOS 数据做兜底，这批设备在资产系统里就成了一堆“未知设备”。
正常的落地方式是这样的：先在每台服务器操作系统层面跑一轮 SMBIOS 采集脚本，把厂商、型号、序列号、BIOS 版本这些基础字段入库存档。再通过 Redfish 带上外管理信息，比如 BMC 版本、电源状态、功耗、温度、固件版本。两者通过序列号做关联，序列号就成了天然的主键。
在维护阶段也是这样。SMBIOS 适合做周期性全量核对，比如每个月跑一次全量资产扫描；Redfish 适合做实时的状态监控，比如每 5 分钟拉一次 PowerState 和健康状态。静态信息变化少，动态信息变化快，用不同的采集频率去适配，既能保证数据新鲜度，又不会给 BMC 带来太大压力。
5. 常见问题速查与实战避坑记录
5.1 Redfish 调不通？按这四条排查
第一类问题是 HTTPS 证书验证失败。这个最简单，先加-k跳过证书校验，确认接口能通，再去解决证书信任问题。注意某些 BMC 固件对 TLS 版本有要求，老设备可能只支持 TLS 1.0/1.1，而新版 curl 默认禁用，这种时候要显式指定--tlsv1.2或者更新 BMC 固件。
第二类问题是认证失败，返回 401。排查顺序是：确认账号是不是有 Redfish 访问权限，确认密码里是否有特殊字符被 shell 转义，再确认是不是触发了账号锁定策略。我之前遇到过一台服务器的 BMC 因为之前登录失败次数过多，账号被锁了 30 分钟，排查了老半天才反应过来。
第三类问题是资源路径不对，返回 404。不同厂商对 System Id 的命名规则不一样，有Systems/1的，也有Systems/System.Embedded.1的。不要硬编码路径，先访问/redfish/v1/Systems看返回集合，再根据@odata.id动态拼路径。
第四类问题是网络不通。Redfish 走的是带外管理口，不是业务网卡。很多新人在服务器上 curl 内网 IP，发现怎么都不通，最后发现 BMC 管理口和业务口本来就是两张网卡，IP 也是分开配置的。先ping一下 BMC 管理 IP，再确认防火墙放行了 443 端口，这才是正经排查顺序。
5.2 SMBIOS 里的 UUID 和 Redfish 对不上
这是我在做多厂商设备数据比对时遇到最多的问题。同一台机器，dmidecode -s system-uuid得到的结果，和 Redfish/redfish/v1/Systems/1里的 UUID 字段，看起来可能是完全不同的两个值。第一次遇到的时候，我也以为哪里弄错了，后来翻了 SMBIOS 规范和 RFC 4122 才明白，两者对 UUID 的字节序处理不一致。
SMBIOS Type 1 结构里的 UUID 字段，前三个组是 little-endian，后两个组按 big-endian 存储，而标准 UUID 字符串是按 RFC 4122 的网络字节序呈现的。所以 Raw 数据在转换时要把前 3 个组做字节反转。如果你拿到的是一个 hex 字符串，可以这样转：
import uuid def smbios_uuid_to_standard(raw_hex): # raw_hex 例如 "4c4c4544-0031-2d4a-8048-b7c04f593331" clean = raw_hex.replace("-", "") b = bytes.fromhex(clean) return str(uuid.UUID(bytes=b[:4][::-1] + b[4:6][::-1] + b[6:8][::-1] + b[8:]))如果你是直接读 dmidecode 输出，有些版本的 dmidecode 已经帮你做了一次格式化，所以它显示的字符串很可能和 Redfish 返回的不一样。遇到这种差异，不要急着改数据，先用字节序转换脚本验证一下，确认是同一个值再继续。
5.3 巡检脚本批量抓取时的性能雷区
Redfish 虽然好用，但 BMC 的本质还是一个嵌入式系统，CPU 和内存资源非常有限。我在帮客户做几千台机器巡检的时候，最开始的脚本是每台机器起一个并发线程，结果跑了一会儿就有 BMC 开始丢响应，有些甚至直接重启了。后来跟厂商工程师聊了才知道，BMC 的 IPMI/Redfish 服务对并发连接数是有限制的，一台机器同时有几个连接还好，几十个连接打过来，直接就把 BMC 打挂了。
所以批量巡检的正确姿势是控制并发度。我现在的做法是：并发数控制在 8 到 16 之间，每台机器请求之间加一点随机延时，大概 0.2 到 0.5 秒，避免所有请求同时打过来。同时给每个请求设置合理的超时时间，比如 10 秒，超时就直接标记为失败，不要一直等下去。
另一个优化思路是减少请求次数。像前面的$expand=.技巧，可以把一个集合里所有成员的详情一次拉回来。要抓多台机器的时候，还可以使用批量操作接口，用一次请求操作多个目标资源。但要注意，这种深操作对 BMC 的消耗也更大，要评估好自己硬件的能力，不要盲目上。
关于采集频率，静态资产信息一天拉一次就够，动态状态信息也不要低于 30 秒一轮。如果监控平台想看实时趋势，现在很多 BMC 其实有自己的历史数据查询接口，可以让 BMC 自己存，监控端按需补充拉取，而不是自己高频轮询。
5.4 事件订阅没生效？多半是这两处问题
用 Redfish 做告警推送，最省心的方式是配置事件订阅。我见过不少人在这一步翻车，明明配置了 Destination 和 EventTypes，事件却没有推过来。查了一圈，问题大多出在两个地方。
第一，Destination 地址不对。BMC 只能访问到它网络能到达的地址，如果你的告警接收服务在业务网段，而 BMC 管理口在管理网段，两边网络不同路由，事件自然推不过来。先要在 BMC 侧确认，Destination 指向的 HTTP/HTTPS 端口可达，然后再做订阅。
第二，EventTypes 没有配对。不同固件支持的 EventTypes 不完全一样，常见的有Alert、StatusChange、ResourceUpdated、ResourceAdded、ResourceRemoved。如果只订阅了Alert，但实际告警走的是StatusChange，也会收不到。稳妥的做法是先通过查询/redfish/v1/EventService/看固件暴露了哪些支持类型，再按照固件实际支持的类型去订阅。
我在生产环境里一般会写一个健康检查任务，定期向接收端发送测试事件，确认订阅链路没有因为 BMC 重启或者网络策略变更而失效。毕竟告警通道这种事，等出事的时候再去验证就晚了。
最后再分享一点实际动手的体会
如果你现在正准备做一套服务器管理系统，我个人的建议是：先从 SMBIOS 把资产老底摸清楚，再上 Redfish 管动态状态，两条腿走路，信息才不会缺腿。Redfish 接口虽然比 IPMI 友好太多，但不同厂商的实现质量还是有差距，遇到奇怪问题不要先怀疑自己代码，先拿厂商自带的工具在 BMC 上手动验证一遍接口，往往能快速缩小问题范围。还有一点，平时多留心固件更新，Redfish 这类基于 Schema 的协议，厂商会在固件迭代里不断补全接口字段，同一个型号的老固件和新固件返回的数据完整度可能差着不少。这个系列我后续还会继续拆 DMTF 的其他协议，感兴趣的可以先对照着把 SMBIOS 和 Redfish 的基础字段梳理清楚，后面再聊其他内容会顺很多。
