3. 资产信息模型与数据字典
在ThinkSystem资产配置与生命周期治理中，资产信息模型是全部治理动作的“共同语言”。如果服务器、存储、网络、机柜和配件各自用不同的字段描述，后续的容量分析、保修跟踪、变更审计和退役决策都会失去可靠基础。本节的目标不是简单罗列字段，而是建立一套可落地、可扩展、可校验的资产数据模型，并用数据字典把它固定下来。
一、资产信息模型的三层结构
ThinkSystem资产信息模型可以按“实体—关系—属性”三层来组织。实体是治理对象的最小单元，例如一台SR650 V3服务器、一台DE4000H存储、一台NE1032T交换机、一个42U机柜或一块ThinkSystem 2.5英寸SSD。关系描述实体之间的连接与归属，例如服务器安装在哪个机柜的哪个U位、服务器通过哪些端口连接到哪台交换机、存储阵列由哪些硬盘组成。属性则是每个实体的可量化、可检索、可审计的特征字段。
这三层中，实体决定“管什么”，关系决定“怎么连”，属性决定“记什么”。三者缺一不可：只有实体没有关系，就无法做拓扑影响分析；只有关系没有属性，就无法做保修、容量和成本判断。
二、核心实体的属性字段设计
以一台ThinkSystem SR650 V3为例，其资产记录至少应包含以下字段组。标识属性用于唯一识别：资产编号（如AST-SRV-2024-0017）、序列号（如J300A1B2）、MTM（如7D6A1CTO1WW）、主机名（如sh-prod-app-17）、管理IP（如10.20.30.17）。生命周期属性用于治理节奏：采购日期、保修截止日期、当前状态（在用/备用/维修/待退役/已退役）、责任人、机房与机柜位置。技术属性用于容量与兼容性分析：CPU型号与数量、内存容量、硬盘槽位与已用槽位、固件版本、网卡型号与端口数、电源功率。财务属性用于成本分摊：采购成本、折旧年限、成本中心。
存储、网络、机柜和配件的字段设计遵循同样的分组逻辑，但各有侧重。存储阵列需要额外记录RAID级别、可用容量、控制器数量、缓存大小；交换机需要记录端口总数、已用端口、上行链路、VLAN范围、固件版本；机柜需要记录总U数、已用U数、剩余U数、承重、PDU数量与功率；配件需要记录所属父资产、安装位置、更换日期和兼容机型。
三、关系模型：从“孤立台账”到“可追溯网络”
关系模型的价值在于把静态台账变成可追溯网络。ThinkSystem资产治理中最常用的四类关系是：安装关系（服务器/存储/交换机安装在机柜的哪个U位）、连接关系（服务器网卡端口连接到交换机端口，存储控制器连接到FC交换机）、组成关系（存储阵列由哪些硬盘和控制器组成，服务器由哪些配件组成）、归属关系（资产属于哪个业务系统、哪个成本中心、哪个责任人）。
以连接关系为例，一条典型的端口连接记录应包含：源资产编号、源端口标识（如Slot3/Port1）、目标资产编号、目标端口标识（如Eth1/17）、链路类型（10GbE/16Gb FC）、链路状态（Up/Down）、最后验证时间。这条记录让“某台服务器断网”可以快速定位到具体交换机端口，而不是逐台排查。
四、数据字典设计：字段的“法律条文”
数据字典是对每个字段的正式定义，必须明确字段名、中文含义、数据类型、长度、是否必填、取值范围、默认值、数据来源和校验规则。没有数据字典，不同人录入的“状态”可能是“在用”“运行中”“Active”三种写法，后续统计就会失真。
下面给出一份可直接参考的ThinkSystem资产数据字典示例片段，覆盖服务器和机柜两类实体：
| 字段名 | 中文含义 | 类型/长度 | 必填 | 取值范围/规则 | 数据来源 |
|---|---|---|---|---|---|
| asset_id | 资产编号 | VARCHAR(32) | 是 | AST-类型-年份-序号，全局唯一 | 资产系统生成 |
| serial_no | 序列号 | VARCHAR(32) | 是 | 厂商序列号，唯一 | 设备标签/带外管理 |
| mtm | 机型型号 | VARCHAR(20) | 是 | 如7D6A1CTO1WW | 采购合同/Lenovo XCC |
| hostname | 主机名 | VARCHAR(64) | 是 | 符合命名规范，唯一 | 操作系统/CMDB |
| mgmt_ip | 管理IP | VARCHAR(15) | 是 | IPv4，唯一 | XCC/网络规划 |
| status | 资产状态 | ENUM | 是 | 在用/备用/维修/待退役/已退役 | 人工更新+流程触发 |
| warranty_end | 保修截止日期 | DATE | 是 | YYYY-MM-DD | Lenovo保修查询 |
| rack_id | 所属机柜 | VARCHAR(32) | 是 | 关联机柜资产编号 | 机房台账 |
| u_position | U位起始 | INT | 是 | 1-48 | 机房台账 |
| u_height | 占用U数 | INT | 是 | 1U/2U/4U等 | 机型规格 |
| cpu_model | CPU型号 | VARCHAR(64) | 否 | 如Intel Xeon 6430 | XCC/采购清单 |
| mem_gb | 内存容量(GB) | INT | 否 | ≥0 | XCC/采购清单 |
| fw_version | 固件版本 | VARCHAR(32) | 否 | 如UEFI 2.90 | XCC |
| cost_center | 成本中心 | VARCHAR(32) | 是 | 财务编码 | 财务系统 |
五、落地要点与常见陷阱
第一，字段设计要“先治理后扩展”。初期字段不宜过多，但标识、状态、位置、保修、责任人五类必须齐全，否则后续无法做生命周期提醒。第二，关系模型要明确基数和方向。例如“一台服务器安装在一个机柜的一个U位”是一对一，“一台交换机连接多台服务器”是一对多，基数错误会导致数据重复或丢失。第三，数据字典要配套校验规则。例如序列号必须唯一、管理IP必须符合网段、保修截止日期不得早于采购日期。第四，状态字段必须用枚举值而不是自由文本，并定义状态迁移规则，例如“在用→维修→在用”或“在用→待退役→已退役”。