3. 资产标识与CMDB建模
在HPE ProLiant服务器的生命周期治理中，资产标识是全部管理动作的锚点。没有稳定、唯一、可追溯的标识体系，CMDB就只是一堆无法关联的表格。本节从HPE ProLiant实际可获取的标识字段出发，说明它们各自代表什么、从哪里读取、如何组合成配置项（CI），以及如何设计一个能支撑变更、故障定位和生命周期决策的CMDB数据模型。
一、四类标识的本质区别
HPE ProLiant上常见的标识字段容易混淆，必须区分清楚：
- 序列号（Serial Number，SN）：整机唯一标识，由HPE在生产时分配，形如"CN70160D2F"。它标识"这一台物理服务器"，是保修、备件、iLO许可和资产台账的主键。序列号可通过iLO界面、
show system命令、SMBIOS或机身标签获取。 - 产品编号（Product Number / SKU）：标识"这一款机型配置"，如"P55241-B21"代表某款DL380 Gen10特定配置。同一SKU下可以有多台不同序列号的机器。产品编号决定规格、支持的部件和固件基线。
- 部件编号（Part Number，PN / Spare Part Number）：标识可更换单元，如电源"P38997-001"、内存"P00924-B21"。部件编号用于备件采购、保修判定和配置比对，同一部件编号可能出现在多台服务器中。
- 资产标签（Asset Tag）：企业自定义的编号，如"BJ-IDC-A-0231"，用于对接财务固定资产或机房位置管理。它由企业分配，与HPE出厂标识无关，但必须与序列号建立一对一映射。
四者的关系可以概括为：产品编号定义"型号"，序列号定义"个体"，部件编号定义"组成单元"，资产标签定义"企业归属"。CMDB建模时，序列号是服务器CI的自然主键，资产标签是业务侧索引，产品编号和部件编号则作为属性或关联CI存在。
二、从物理标识到配置项关系
一台ProLiant服务器不是单一CI，而是一棵CI树。典型层级为：机箱（Chassis）→ 主板/系统板 → CPU、内存、网卡、HBA、电源、风扇、硬盘背板 → 硬盘、NVMe、光模块。每个可管理部件都应有独立CI记录，并通过关系与父级服务器关联。
关系类型至少需要三种：
- 包含关系（contains）：服务器包含电源、内存等，用于配置清点和影响分析。
- 连接关系（connects_to）：网卡端口连接交换机端口，HBA连接SAN交换机，用于故障传播分析。
- 依赖关系（depends_on）：业务系统依赖某台服务器，服务器依赖机柜PDU和上行链路，用于变更风险评估。
下面这张图展示了从物理标识到CMDB数据模型的映射关系，以及CI之间的层级与连接结构。
三、CMDB数据模型设计要点
基于上述标识和关系，一个可用的ProLiant CMDB模型至少包含四张核心表：
| 表名 | 主键 | 关键字段 | 作用 |
|---|---|---|---|
| ci_server | serial_number | asset_tag、product_sku、model、rack_u、status | 服务器主记录，唯一标识物理机 |
| ci_component | component_id | server_sn(FK)、part_number、slot、firmware、health | 部件级配置清点与保修关联 |
| ci_relation | relation_id | source_ci、target_ci、relation_type、valid_from/to | 表达包含、连接、依赖关系 |
| ci_lifecycle | event_id | ci_id、event_type、event_time、operator | 记录上线、变更、故障、退役事件 |
设计时需注意几个关键约束：第一，serial_number作为自然主键，必须来自iLO或SMBIOS的真实值，不能人工编造；第二，asset_tag加唯一索引，避免一物多标签；第三，ci_relation中的valid_from和valid_to支持关系的时间维度，例如网卡从A端口迁移到B端口时，旧关系失效、新关系生效，而不是直接覆盖；第四，ci_component中的part_number应与HPE备件目录对齐，便于自动判断保修状态。
四、实操：从iLO采集到CMDB入库
以一台DL380 Gen10为例，采集流程如下。首先通过iLO REST API或ilorest工具获取系统清单：
ilorest login 10.20.30.41 -u admin -p ******
ilorest select SystemInventory
ilorest get --json > dl380_0231_inventory.json返回的JSON中可提取：SerialNumber、ProductId（即SKU）、AssetTag，以及Processors、Memory、NetworkAdapters等部件数组。每个部件包含PartNumber和SerialNumber。将这些字段映射到上述四张表，即可完成一次入库。
入库后应做三项校验：一是序列号与资产标签是否唯一；二是部件编号是否在HPE支持列表中；三是关系表是否完整，例如每块网卡是否都有对应的交换机端口连接记录。若某台服务器缺少connects_to关系，则故障影响分析会断链。
五、常见建模误区
- 用资产标签代替序列号做主键：资产标签可能因企业重组、机房搬迁而变更，序列号才是稳定锚点。
- 只建服务器CI，不建部件CI：导致无法回答"哪些机器用了同一批有缺陷的内存"这类问题。
- 关系表只存当前状态：没有时间维度，无法回溯"三个月前这台机器的网卡接在哪个端口"。
- 忽略产品编号的配置基线作用：同一SKU应有统一的固件基线和部件兼容列表，否则批量升级时无法分组。
总结来说，ProLiant资产标识体系的核心是"四码一树"：序列号定个体、产品编号定型号、部件编号定单元、资产标签定归属，再以CI树和关系表承载结构与连接。CMDB数据模型只有把这四类标识和三类关系都落成可查询、可追溯、带时间维度的表结构，才能真正支撑后续的变更管理、故障定位和生命周期决策。