上一篇完成 IPAM，把地址空间、VRF、Prefix、VLAN 和 IP Address 建成可治理对象。本篇进入 DCIM。DCIM 在 NetBox 中不是“设备资产表”，而是把站点、位置、机架、设备类型、设备、模块、接口、电源、控制台、库存件和连接关系组织成一套结构化模型。只有 DCIM 与 IPAM 同时准确，NetBox 才能回答“这个 IP 在哪台设备哪个接口上、设备位于哪个机架、它的上联和电源在哪里、变更会影响哪些对象”。

本文以 NetBox 当前官方 DCIM 数据模型为依据。需要注意两个常见误区：第一，设备类型变更不会自动回溯更新已创建设备的组件，不能把设备类型当动态模板；第二，机框、线卡和模块化设备不应简单建成父子设备，官方文档明确建议 line card 等非自治硬件用 module 或 inventory item 建模。本文会按这些边界重写设备管理流程。

DCIM 的目标

DCIM 的目标是让物理基础设施具备可查询、可审计、可自动化消费的期望状态。设备在哪里、属于谁、是什么型号、处于什么生命周期、有哪些接口、连接到哪里、占用哪个 U 位、有什么电源路径，应该能从 NetBox 读取，而不是从现场照片、设备配置、Excel 和个人经验中拼接。

这并不意味着 NetBox 要替代全部资产系统。采购、财务折旧、维保合同和工单流程可以仍在 ITSM、ERP 或资产平台中；NetBox 重点保存网络和基础设施自动化需要的对象关系。资产号、序列号和维保信息可以作为关联字段存在，但不应把 NetBox 变成完整财务资产系统。

DCIM 的价值来自关系。一个 Device 关联 Device Type、Manufacturer、Device Role、Platform、Site、Location、Rack、Tenant、Interfaces、Power Ports、Console Ports、Modules 和 IP 地址。若只录入设备名称和管理 IP，后续自动化仍然缺少上下文。若关系建完整，监控、配置生成、布线审计和容量规划都能使用同一套事实来源。

站点、站点组和区域

官方文档说明，Site 通常代表建筑、园区、分支、总部或托管机房。如何使用 Site 取决于组织，但 Site 应对应一个有实际运营意义的地点，而不是临时项目或抽象网络。每个 Site 有唯一名称、slug、状态、可选 region、facility、ASN、时区、地址和经纬度等字段。

Region 适合地理层级，例如中国、华东、上海。Site Group 适合按组织或管理方式分组，例如工厂、办公室、云接入点或托管机房。不要把地理、业务、租户和生命周期都塞进 Region。每个维度选择合适对象，后续过滤和权限才清晰。

Site 的 slug 是 URL 友好标识，可用于过滤。部署前应制定命名规范。名称可以中文或业务友好，slug 建议稳定、英文、短横线分隔。Site 名称变更可能影响用户认知，slug 变更可能影响脚本和链接，因此不要随意调整。

Site status 也要治理。计划建设的站点、运行中的站点、暂停使用的站点和退役站点应有明确状态和切换流程。若退役站点仍有 active 设备、Prefix 或 Circuit，质量报表应能发现。

Location 与机房内层级

Location 用于在 Site 内组织 Rack 和 Device。官方文档说明，Location 可以表示楼层、房间、笼区等组织单元，并支持嵌套。例如一个 Site 下可以有 F2、F2-Room-A、F2-Room-A-Row-01 这样的层级。

Location 不应过细。若把每个机架位置、每个冷通道、每个机柜门都建成 Location，维护成本会高于收益。通常把需要权限、容量或现场导航的层级建成 Location，把更细的物理属性留给 Rack、描述或外部设施系统。

Location 与 Prefix 的 scope、VLAN scope、设备权限和报表都可能产生关系。若工厂 OT 区域由不同团队维护，可以把 OT 机房建成 Location 并作为权限或自动化范围。若只是同一房间的装饰性区域，则无需过度建模。

Location status 用于表示运营状态。扩建中、临时停用和退役的 Location 不应继续新增 active 设备。质量检查可以发现 active 设备位于非 active Location 的情况。

Rack：容量、位置和设施标识

官方 Rack 文档说明，Rack 表示两柱或四柱设备机架，必须归属 Site，可选 Location，并可按用户定义角色组织。Rack 的名称和 facility ID 可用于区分内部称呼与托管设施编号；Rack height 用 U 表示，常见 42U 或 48U，但 NetBox 允许任意高度。

Rack 不是简单“机柜名称”。它承载设备安装位置、前后面、U 位方向、序列号、资产标签、角色、设施 ID、类型、重量等信息。机架建模准确后，NetBox 的 rack elevation 才能用于变更和容量判断。

Rack Type 适合定义物理属性，例如高度和重量等，Rack 实例则表示具体机架。若每个 Rack 都手工填一堆物理属性，后续标准化会困难。类似设备类型，能抽象为类型的内容应尽量抽象。

在托管机房中，内部可能称某机架为 A01，设施方称它为 M204.313。Rack name 和 facility ID 的分工能减少混淆。现场工单、线路和交付文档若使用设施编号，应在 NetBox 中保留。

机架容量不能只看 U 位。还要看供电、重量、散热、网络端口、布线空间和维护空间。NetBox 可以表达一部分物理属性和连接关系，但不替代完整设施容量平台。对关键站点，应把 NetBox 机架数据与设施系统或人工容量评审结合。

设备类型不是动态模板

Device Type 表示现实世界中的具体硬件型号。官方文档说明，它定义设备的物理属性和组件，例如 rack height、深度、console、power、network interfaces 等。创建 Device 时，设备会从 Device Type 的模板实例化组件。

关键点是：修改 Device Type 不会自动回溯更新已创建的 Device。若早期设备类型少建了接口，后来补齐模板，已存在设备不会自动获得新接口。生产中要在批量创建设备前认真校验 Device Type。已经创建的设备需要单独脚本或手工修复。

Device Type 的 Manufacturer 和 Model 应与厂商型号保持一致。Part number 可用于精确采购型号，airflow 用于表达默认气流方向，front/rear image 可用于机架立面图。不是所有字段都必须填，但用于自动化和容量判断的字段应有规范。

设备类型模板中创建接口、console port、power port、module bay、device bay 等组件。对于同一型号的标准接口，模板非常有价值；对于现场因模块变化而不同的接口，应该通过 Module Type 或实例组件建模，不要把每种现场组合都建成一个伪型号。

父子设备关系不能滥用。官方文档提醒，父子关系不适合建模共享控制平面的机框式设备；线卡和类似非自治硬件应使用 Module 或 Inventory Item。只有真正可作为独立设备安装在 device bay 中的子设备，才适合父子设备模型。

Device：实例与生命周期

Device 是具体硬件实例，关联 Device Type、Role、Site、Location、Rack、Platform、Tenant、serial、asset tag 和 status。Device Role 表示功能定位，例如核心交换机、接入交换机、防火墙、服务器或 PDU；Platform 表示操作系统或网络 OS，例如 IOS XE、Junos、SONiC、Linux。

状态管理决定设备是否参与下游自动化。planned、staged、active、offline、failed、inventory、decommissioning 等状态要与团队流程匹配。监控系统通常只消费 active 或特定状态设备；配置生成也不应把 inventory 设备推入生产。

设备创建前应先有 Device Type。若设备型号未知，可以临时使用明确的占位类型，但要在流程中补齐。大量“Generic Server” 会让接口、功耗、U 位和自动化失真。对常见设备型号，应建立标准模板库，并由平台团队维护。

设备命名建议与真实网络配置和监控一致。若设备 hostname 与 NetBox name 不同，自动化需要映射，会增加错误。必要时可以用 custom field 或 asset tag 保存其他系统名称，但权威名称应清晰。

Device 与 IPAM 的连接是接口和 IP。管理地址不应只填在设备描述里，而应创建接口、分配 IP，并设置 primary IP。这样 API、监控和 DNS 集成才能从设备找到正确地址。

NetBox DCIM 创建路径

Interface 与网络属性

官方 Interface 文档说明，接口表示设备用于与连接设备交换数据的网络接口，IP 地址和 VLAN 可以分配到接口。设备接口与虚拟机接口是不同模型，自动化需要区分。

接口名称应尽量与设备操作系统一致，例如 GigabitEthernet1/0/1、xe-0/0/0、eth0。Label 可用于保存物理面板标签。接口名称在所属设备内必须唯一。接口类型应表达实际介质或收发器使用方式；官方文档提醒，对于可插拔光模块，应按使用的 transceiver 类型建模，而不只是按笼子外形。

只有物理接口可以通过 Cable 连接。LAG、Loopback、SVI、隧道和 VLAN 子接口等虚拟接口不能作为物理电缆端点。NetBox 支持 parent interface、LAG interface、bridged interface 和 802.1Q mode，用于表达逻辑关系。建模时要区分“物理连接”和“逻辑二层/三层配置”。

802.1Q mode 包括 access、tagged、tagged all 和 Q-in-Q 等模式。Access 口使用 untagged VLAN；tagged 口可以有 native VLAN 和多个 tagged VLAN；Q-in-Q 使用服务 VLAN。下游自动化若要生成交换机配置，必须读取这些字段，而不是从接口描述中解析。

接口有 enabled、management only、speed、duplex、MTU、PoE、wireless 等字段。不要把这些信息都写在描述里。字段化后，质量报表可以发现管理口未标记、禁用接口仍有 active IP、PoE 端口配置异常等问题。

MAC 地址在 NetBox v4.2 之后也有模型变化：接口的 MAC 地址作为属性反映 primary linked MAC address object。旧脚本若直接写旧字段，需要按当前 API 修正。

Module 与 Inventory Item

模块化设备需要单独建模。Module Type 表示模块型号，Module Bay 表示设备中的插槽，Module 表示具体安装的模块。线卡、扩展卡、可插拔接口模块等，通常适合 Module。模块可以拥有接口和其他组件，使同一机框根据实际插卡产生不同端口。

Inventory Item 更适合记录设备内部组件、备件、序列号和资产项，例如电源模块、风扇、内存、硬盘或其他不作为独立网络组件的硬件。它可以用于审计和资产追踪，但不一定参与接口连接模型。

不要为了省事把每块线卡建成独立 Device 再放到机架里。这样会错误表达控制平面和物理位置，也会让接口、IP 和电缆追踪混乱。除非硬件确实是可独立管理的子设备，并安装在 device bay 中，否则优先使用 Module 或 Inventory Item。

模块模型对自动化也重要。接口名称、类型、端口数量和位置可能来自模块，而不是主设备固定模板。脚本在读取设备接口时，不应假设所有接口都来自 Device Type，也要处理 installed module。

电源、控制台和布线

DCIM 不只管理网络接口。Console Port、Console Server Port、Power Port、Power Outlet、Power Panel、Power Feed 等对象可以表达控制台和电源路径。对于数据中心运维，故障时知道设备接在哪个 PDU、哪个断路器和哪个 OOB 终端服务器，价值很高。

Power Port 与 Power Outlet 的连接可以通过 Cable 建模。PDU 本身可作为 Device，电源插座作为组件。上游 Power Panel 和 Power Feed 用于表达更高层级供电。具体是否建到断路器级别，取决于设施团队和故障处置要求。

控制台连接同样值得记录。核心网络设备、防火墙和存储的 console 口通常接到终端服务器。记录这些连接后，设备不可达时可以快速找到带外管理路径。没有带外管理的设备，也应明确标记，不要让值班人员临时猜测。

电缆对象记录端点、类型、状态、标签、颜色和长度等。官方 Cable 文档提供了支持的连接端点模型。电缆数据只有在现场标签与 NetBox 对齐时才可靠，因此布线治理需要标签规范和现场验证。

NetBox 连接与结构化布线

建模顺序

DCIM 落地建议按依赖顺序执行：

  1. 建 Region、Site Group、Site、Location。
  2. 建 Rack Type、Rack Role、Rack。
  3. 建 Manufacturer、Platform、Device Role。
  4. 建 Device Type、Module Type 和组件模板。
  5. 创建设备实例并放入 Site、Location、Rack。
  6. 校验接口、电源、控制台和模块。
  7. 关联 IP 地址、VLAN、平台和租户。
  8. 建立电缆、电源和控制台连接。
  9. 建立生命周期、导入、审计和自动化消费。

先建基础对象再建实例，可以减少重复和错误。若直接导入设备表，后续还要补 Manufacturer、Device Type、Role、Rack 和接口模板，工作量会翻倍。

首期试点不应追求覆盖全部资产。可以选择一个机房的一排机架、一组网络设备和部分服务器，完整走通设备类型、设备、接口、IP、连接和验证，再扩大范围。

导入和数据清洗

旧资产表通常包含设备名、IP、型号、机房、机柜、U 位、序列号和备注。导入前要拆分字段：型号映射 Device Type，厂商映射 Manufacturer，机房映射 Site/Location，机柜映射 Rack，IP 走 IPAM，备注中的维护人、业务和状态进入 owner、tenant、tag 或 custom field。

导入唯一键必须明确。Device name 是否全局唯一？Rack name 是否在 Location 内唯一？Device Type 是否以 manufacturer 加 model 唯一？接口名称是否与设备 OS 一致？如果源数据没有唯一键，先人工清洗，不要让脚本猜测合并。

设备类型应先导入并校验，再导入设备。若很多型号缺少模板，可以先导入少量高频型号。不要为每台服务器创建一个不同 Device Type，只因为内存或硬盘略有差异；这些差异更适合 Inventory Item 或自定义字段。

导入脚本应支持 dry-run。输出将创建、更新、跳过和冲突的记录，人工确认后再执行。每个对象记录源行和目标 ID，方便复查。导入不应直接写数据库，应使用 API 或 NetBox 导入功能，以保留校验和变更日志。

导入后抽样现场验证。检查机架位置、设备序列号、接口数量、管理 IP、上联和电源连接。页面能显示对象，不代表数据正确。现场抽样能发现命名、U 位和连接方向等问题。

数据清洗还要处理“同名不同物”和“同物不同名”。例如同一台设备在资产表中叫 SW-CORE-01，在监控里叫 sh-core-sw01，在现场标签上又写 CORE-A。这类映射不能靠导入脚本临时猜测，应先确定权威命名，再把其他名称放入自定义字段、标签或外部系统映射表。否则后续 LLDP 对账、监控同步和配置备份会把同一设备识别成多个对象。

型号清洗是 DCIM 项目中最容易低估的工作。服务器资产表常把 CPU、内存、硬盘和采购批次写进型号字段，网络设备表也可能混用营销型号、订货号和面板型号。NetBox 的 Device Type 更适合表达厂商和硬件型号，差异化配置应放到模块、库存件、自定义字段或外部资产系统。若把 R650-128G-2T-2024 建成设备类型，几年后会得到一堆无法复用的伪型号。

接口清洗应优先服务自动化。交换机、路由器、防火墙和服务器的接口名称要尽量使用设备系统真实名称；面板丝印、配线架端口和现场标签放到 label、description 或 Cable label。若接口名称按现场人员习惯缩写，自动化从设备采集接口状态后就无法直接匹配。对网络设备尤其如此，GigabitEthernet1/0/1 与 Gi1/0/1 在人眼看来相近，但在 API 对账中是两个字符串。

清洗后的数据应分批导入。第一批导入站点、位置、机架和基础字典；第二批导入设备类型和模块类型；第三批导入设备实例；第四批补接口、IP、电源、控制台和电缆。每批之间都要留出人工检查窗口。一次性把全部 CSV 推进 NetBox，失败时很难判断是基础对象缺失、唯一键冲突、权限不足，还是业务规则本身不清楚。

如果已有 CMDB 或资产系统，不建议让两个系统互相覆盖。更稳妥的方式是定义字段权威：采购编号、折旧状态和合同归资产系统；Site、Rack、Device、Interface、Cable 和 primary IP 归 NetBox；业务归属和责任人可以由 ITSM 或组织目录提供，再同步到 NetBox 的 Tenant、Contact 或自定义字段。权威边界明确后，接口同步才不会反复打架。

设备类型库治理

设备类型库需要像代码库一样治理。每个 Device Type 的创建都应有来源、命名规范和复核流程。来源可以是厂商规格、现场设备、官方设备类型库或内部验证记录；命名应保持 manufacturer、model、part number 的语义一致；复核要确认 U 高度、接口模板、电源口、console 口、模块槽位和气流方向是否符合实际。

对常见型号，可以先建立最小可用模板，再逐步补齐细节。最小可用不等于只写型号，它至少应能支撑机架占位、接口创建、管理口建模和电源连接。对自动化会消费的字段，宁愿少批量上线一些型号，也不要把未经校验的模板扩散到几百台设备上。因为设备创建后，模板修改不会回灌，早期错误会转化成大规模修复成本。

模板变更要区分“新增能力”和“纠错”。新增一个可选模块槽位，通常只影响后续设备；纠正接口数量或接口类型，则可能意味着已存在设备不准确。后一类变更应伴随修复计划：列出受影响设备，比较模板和实例组件，决定是批量补接口、重建设备，还是仅在新设备上采用新模板。

设备类型库还要避免重复。Cisco C9300-48P、C9300-48P、Catalyst 9300 48P 如果同时存在，导入人员会随机选择，报表和自动化会失去一致性。建立模板前先搜索 Manufacturer 和 Model；确实存在不同订货号或硬件版本时，用 part number、description 或 device type variant 表达差异，不要靠随意命名区分。

模块类型库的治理与设备类型类似，但更强调组合关系。一个机框可能支持多种线卡，不同线卡带来不同接口。应把 Module Bay、Module Type 和模块组件模板建清楚，再让设备实例通过安装模块获得真实接口。这样既能表达同一机框的差异，又不会把每种组合复制成不同 Device Type。

设备生命周期

设备生命周期管理流程

设备生命周期可以分为规划、采购或库存、预上架、运行、维护、故障、退役和归档。NetBox status 应与这些阶段对应，并驱动下游系统。

规划阶段创建设备对象可以帮助预留机架、IP 和端口，但状态不应是 active。预上架阶段可以记录 Rack 和接口，待配置完成后再启用监控。运行阶段要求 primary IP、role、platform、owner、接口和关键连接完整。

维护或故障阶段应反映在状态和工单中。若设备临时下线但仍保留位置和 IP，可以用 offline 或 failed 表达；若已准备退役，应进入 decommissioning，并触发回收 IP、释放端口、撤销监控和备份配置等流程。

退役不等于立即删除。删除设备会影响历史关系和审计。更稳妥方式是先切换状态，解除 active IP、连接和监控，保留序列号和资产标签，经过审计期后再归档或删除。关键设备的退役要保留工单和影响分析。

生命周期与自动化绑定时，必须定义每个状态的行为。例如 active 进入监控，staged 只进入配置准备，inventory 不进入配置生成，decommissioning 触发回收。没有状态契约，状态字段只是装饰。

生命周期还要约束变更入口。新设备从规划进入预上架时，应检查 Site、Rack、U 位、Device Type、序列号、资产标签、管理 IP 和电源预算是否齐全；预上架转 active 时，应确认配置备份成功、监控目标已创建、上联和电源连接已核对；active 转 decommissioning 时，应确认业务迁移、监控停用、地址回收和线路释放计划。每个状态切换都对应不同证据，不应只靠人工点一下状态。

机架移动是典型高风险变更。移动设备不仅改变 Rack 和 position，还可能改变上联、电源、控制台、管理路径和现场标签。如果只修改 Rack 字段，NetBox 页面看起来正确，实际连接却可能仍指向旧机柜。规范流程应先生成影响清单，记录原位置、目标位置、相关 Cable、Power Port、Console Port 和 IP，再在变更窗口内按步骤更新。

设备退役也要分层处理。第一层是业务退役，设备不再承载流量；第二层是运维退役，监控、备份、自动化和告警停止引用；第三层是物理退役，设备下架并释放机架、端口和电源；第四层是数据归档，保留审计信息或删除对象。把这些动作压缩成“删除设备”会丢失历史，也容易留下孤立 IP、连接和监控目标。

与 IPAM 和自动化集成

DCIM 与 IPAM 的结合点是接口和 IP。设备创建后，应为管理口或 loopback 分配 IP，并设置 primary IP。服务器业务地址、交换机 SVI、路由器点到点接口和防火墙接口都应按真实关系分配。

自动化 inventory 可以按 Site、Role、Platform、Status、Tenant 和 primary IP 分组。Ansible、Nornir 或自研脚本读取 NetBox 时，应过滤 active 设备，并处理无 primary IP 或平台缺失的对象。不要让脚本从描述字段解析设备类型或站点。

配置生成可以使用 Device Role 决定模板，Platform 决定语法，Interface 读取 VLAN 与 IP，Cable 或 LLDP 对账上联。若 DCIM 数据不完整，自动化应失败并报告缺失，而不是生成猜测配置。

监控系统可以从 NetBox 获取目标和元数据。监控标签使用 Site、Role、Tenant、Platform 和 Rack，帮助告警分组。设备状态变为 decommissioning 后，监控同步应删除或停用目标，避免残留告警。

NetBox 不是实际状态采集器。发现系统可以把 LLDP、接口列表、序列号和 MAC 与 NetBox 比较，输出差异。差异进入审核，不应无条件覆盖期望状态。若现场配置就是错误，自动覆盖会把错误变成新真相。

自动化写入 NetBox 时应坚持幂等。脚本不要每次都创建新对象，而应先按唯一键查询目标对象，再判断需要创建、更新、跳过还是报冲突。Device 可按 name 唯一定位，Rack 通常要结合 Site 或 Location，Interface 要结合 Device 和 name，Cable 要结合两个端点。唯一键不清楚时，宁愿报错人工确认，也不要猜测更新。

读 API 的脚本要控制字段和分页。NetBox REST API 支持通过 brief、fields、omit 等参数减少返回体，适合大规模 inventory 同步。若每次同步都拉取所有字段和嵌套对象，数据量增长后会拖慢平台。自动化只读取必要字段，例如设备名、状态、站点、角色、平台、primary IP 和接口关键信息，其余细节按需查询。

发现对账适合采用“差异报告优先”的节奏。比如采集设备 LLDP 邻居、接口 admin 状态、序列号、MAC 地址和模块信息，然后与 NetBox 期望状态比较，输出新增、缺失、冲突和疑似命名不一致。只有低风险、规则明确的差异才自动修复；涉及物理连接、设备移动和 IP 归属的差异应进入人工审核。

监控同步同样要尊重状态契约。active 设备进入监控，staged 设备可以进入预检查，failed 设备可以保留但降低告警噪声，decommissioning 设备应从生产告警目标中移除。若监控平台只按“NetBox 中存在设备”同步，就会把库存设备、退役设备和模板对象都纳入告警，反而降低 NetBox 的可信度。

配置生成要把缺失数据视为质量问题。比如缺少 Platform，模板无法确定语法；缺少 primary IP，工具无法连接设备；接口 VLAN 不完整，生成的 access 或 trunk 配置不可信；Cable 关系缺失，无法校验上联。自动化系统应把这些缺口反馈为数据待修复清单，而不是在脚本里填默认值继续运行。

变更评审与容量规划

DCIM 的一个重要用途是把变更从“经验判断”变成“基于对象关系的评审”。新增一台服务器时，不只问有没有空 U 位，还要问目标 Rack 的剩余电源、网络端口、上联容量、散热约束和运维可达性。NetBox 可以提供机架占位、设备角色、接口和连接信息，再结合设施系统或人工评审完成容量判断。

对网络设备扩容，评审重点是端口和拓扑。新增接入交换机需要确认核心或汇聚设备的可用端口、链路类型、光模块类型、布线路径、管理地址、VLAN 范围和监控模板。若这些信息散落在 Excel、聊天记录和现场照片中，变更评审只能靠人记忆；若都进入 NetBox，评审可以形成固定检查项。

对机房搬迁，NetBox 的价值更明显。搬迁前可以导出旧 Site、Location、Rack、Device、Interface、Cable、Power 和 IP 关系，形成迁移清单；搬迁中按批次更新状态和位置；搬迁后通过现场抽样、LLDP 对账和监控同步确认数据与现实一致。没有这套对象关系，搬迁后最常见的问题是设备能用但台账失真，几年后再排障就会付出代价。

容量报表不应只展示“还剩多少 U”。更实用的报表包括：active 设备无 Rack、Rack 中设备无 U 位、同一 U 位冲突、设备无 primary IP、网络设备无上联、PDU 无上游电源、接口有 IP 但 disabled、退役设备仍占用连接、站点中 active 设备没有 owner。这些报表能直接驱动治理任务。

验证与质量报表

验证 DCIM 数据完整性

DCIM 验收从层级开始。检查 Site、Location、Rack 是否按规范创建，Rack 是否位于正确 Location，设备是否位于正确机架和 U 位，机架高度和方向是否符合现场。没有位置的 active 设备应进入待处理清单。

设备模板检查包括：Device Type 是否有 Manufacturer、型号、U 高度、深度和必要组件；已创建设备的接口数量是否与真实设备一致；模块化设备是否用 Module 表达；旧设备是否仍缺失接口、电源或 console 端口。

关系检查包括：active 设备是否有 role、platform、site、primary IP；管理接口是否标记 management only；禁用接口是否仍有 active IP；设备状态与 IPAM、监控、连接是否一致；PDU 和终端服务器连接是否完整。

物理验证包括：抽样核对序列号、资产标签、机架 U 位、前后面、网线标签、电源线标签和上联。对于新导入数据，建议每个站点至少抽样关键网络设备、服务器和 PDU。

自动化验证包括：通过 API 拉取设备清单，确认字段足以生成 inventory；读取接口和 IP，确认能生成配置或监控目标；读取连接，确认能做邻居对账。若自动化需要的字段缺失，应回到模型补齐，而不是在脚本里硬编码。

验收还要区分一次性验收和持续验收。项目上线时的一次性验收可以确认初始数据质量，但 DCIM 数据会随着设备采购、上线、搬迁、扩容和退役持续变化。持续验收应通过周期任务执行，例如每天检查孤立对象，每周检查 active 设备完整性，每月抽样核对现场标签，每个变更窗口后检查受影响对象。

质量报表最好分为阻断、告警和建议三类。阻断类问题会影响自动化或生产判断，例如 active 设备没有 Site、没有 primary IP、接口名称无法匹配设备采集结果；告警类问题需要跟进但不一定阻断，例如 Rack 缺少 facility ID、设备缺少资产标签；建议类问题用于持续改进，例如描述字段过长、标签使用不统一。

对数据质量的评分应看趋势，不要只看单次结果。早期导入后问题很多是正常的，关键是每轮治理后阻断类问题是否下降，新增设备是否按规范创建，退役设备是否按流程释放资源。如果数据质量报表长期只增不减，说明流程没有嵌入日常变更，NetBox 仍然只是事后补账。

现场验证要选择有代表性的样本。只抽查容易访问的几台设备，会高估质量。更合理的样本包括核心网络设备、PDU、OOB 设备、不同厂商服务器、模块化机框、新上线设备、历史最久设备和近期搬迁设备。每类样本验证位置、序列号、接口、上联、电源和管理地址，才能发现模型和流程的盲区。

权限和职责

DCIM 数据涉及多个团队。数据中心团队可能维护 Site、Location、Rack 和电源；网络团队维护设备、接口和连接；服务器团队维护服务器资产；平台团队维护 Device Type、Platform 和自动化字段。权限应按职责分离。

全局对象如 Manufacturer、Device Type、Device Role 和 Platform 应由少数数据管理员维护，避免重复和近义对象。区域团队可以维护其授权 Site 下的 Device、Rack 和连接。自动化 token 只拥有需要的读写范围。

如果对象权限粒度无法完全表达流程，就用工单和自定义脚本控制高风险操作。例如批量退役设备、批量移动机架、批量改接口 VLAN，都应通过受控脚本和审批执行，而不是让每个用户在 UI 中自由修改。

变更记录只能说明谁改了什么，不一定说明为什么。关键设备、机架移动、连接变更和状态切换应关联工单号。没有工单的重大修改进入审计清单。

备份与恢复

NetBox DCIM 备份恢复策略

DCIM 数据同样位于 PostgreSQL 中，数据库备份是恢复基础。还要保留媒体文件，因为设备类型可能上传 front/rear images，附件或导入文件也可能影响审计。配置、插件、自定义字段和验证规则也属于恢复范围。

恢复演练要验证关系而不是只验证对象数量。恢复后抽查 Site、Rack、Device、Interface、IP、Cable、Power 和 Console 关系，确认机架立面图、设备详情、API 和自动化查询都可用。

若发生误删除，先保护当前数据库副本，再在隔离环境恢复最近备份并比较差异。不要直接用 SQL 手工补对象。DCIM 关系复杂，漏补接口或电缆会留下隐患。

常见反模式

第一，把每台设备都建成唯一 Device Type。第二，修改 Device Type 后以为已存在设备自动更新。第三，把线卡建成独立设备。第四，把管理 IP 写在备注里而不分配给接口。第五，机架 U 位随意填，现场从不核对。

第六，所有设备都标 active，导致监控和自动化误纳入库存或退役设备。第七，用描述字段保存平台、租户、业务和 owner。第八，接口名称与设备配置不一致。第九，只记录网络线，不记录电源和控制台。第十，发现结果无审核覆盖 NetBox。

反模式的根因通常是没有定义数据消费者。如果 DCIM 数据会被监控、配置生成、容量规划和变更审核使用，字段自然需要准确；如果只作为展示页，大家很快就会回到旧表。

小结

NetBox DCIM 的核心是把物理基础设施对象化：Site 表示地点，Location 表示站点内层级，Rack 表示设备安装空间，Device Type 表示硬件型号模板，Device 表示实例，Interface、电源、控制台、Module 和 Cable 表示组件与连接。设备类型不是动态模板，模块化设备应用 Module 或 Inventory Item 建模，状态应驱动生命周期和自动化。

完成 DCIM 后，IPAM 中的地址可以连接到真实接口，下一篇将继续深入电路和连接管理，把设备间、配线架、运营商电路和物理路径纳入同一套可审计模型。

参考资料