大型企业的IT基础设施一般分布在不同的地理位置上，有几千到几万台服务器不等。传统的资产管理方式依靠运维人员定时登录设备进行操作或者手动登记，存在着三大缺点：
- 数据时效性差：人工盘点周期长，资产变更与记录之间存在时间差，CMDB数据滞后于实际环境。
- 存在严重的信息孤岛问题，各个机房和各个业务线都有一套自己的账本，没有统一的数据模型来整合所有的资产信息。
- 人为误差不可控：手动录入IP、序列号、硬件配置等信息时，错漏率可达5%-10%，直接影响容量规划与成本核算准确性。
整体架构设计
该方案采用了“Agent收集数据、中央CMDB存储信息、自动化的任务分配”的三层结构：
┌─────────────────────────────────────────────────────────────┐
│ 中心管控层 │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ CMDB核心库 │ │ 任务调度引擎 │ │ 差异比对与告警 │ │
│ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ │
├─────────┼──────────────────┼───────────────────┼───────────┤
│ │ 多机房接入层 │ │ │
│ ┌──────▼──────┐ ┌──────▼──────┐ ┌───────▼────────┐ │
│ │ 机房A Agent │ │ 机房B Agent │ │ 机房N Agent │ │
│ │ (物理/虚拟) │ │ (物理/虚拟) │ │ (物理/虚拟) │ │
│ └─────────────┘ └─────────────┘ └────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Agent采集层的具体做法
Agent被安装在每一台服务器上，负责收集数据并向上级汇报。主要的技术选型有：
采集维度覆盖
| 采集类别 | 具体字段 | 采集方式 |
|---|---|---|
| 硬件信息 | 厂商、型号、序列号、CPU型号/核数、内存容量/插槽、磁盘类型/容量/Raid级别 | dmidecode、lscpu、lsblk、/proc/meminfo |
| 网络信息 | 网卡型号、IP地址、MAC地址、bond配置、交换机端口对应关系 | ip addr、ethtool、lldpctl |
| 系统信息 | OS版本、内核版本、运行时间、已安装软件包列表 | uname、/etc/os-release、rpm/dpkg |
| 虚拟化信息 | 宿主机UUID、虚拟机UUID、Hypervisor类型 | systemd-detect-virt、virt-what |
| 业务标签 | 所属业务线、集群角色、环境类型（生产/测试/预发） | 本地配置文件 + CMDB API回写 |
Agent技术选型对比
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 自研轻量Agent（Go编译静态二进制） | 资源占用<5MB内存，无运行时依赖，启动快 | 开发成本高，需自行维护 | 大规模异构环境 |
| Ansible+SSH批量采集 | 无需部署Agent，利用现有通道 | 并发受限，网络抖动导致超时，无法实时 | 中小规模、低频盘点 |
| 开源采集框架（如Facter、Ohai） | 社区成熟，插件丰富 | 输出格式需二次适配，冗余数据多 | 已有Puppet/Chef体系 |
建议使用自己编写的Go语言Agent来运行，用systemd服务的方式一直挂着，可以有两种工作方式：
- 主动上报模式：Agent按设定周期（默认24小时）采集数据并推送至CMDB API。
- 被动触发模式：CMDB调度引擎通过消息队列（如Redis Pub/Sub或Kafka）下发即时采集指令，Agent收到后立刻执行并回传。
数据验证系统
Agent收集完数据之后会进行一些基本的检查：
- 用正则表达式来匹配序列号，去掉一些明显的错误数据（比如全部是0或者全部是F）。
- IP地址冲突检测、同一条网线多个IP地址的情况需要进一步核实。
- 硬件变化检测：和上次收集的数据进行比较，在CPU、内存或者硬盘有增加或减少的情况下会产生一个需要人工审核的事件。
CMDB核心层设计
CMDB是唯一的权威数据来源，负责数据的规范化、关系模型构建以及一致性保证工作。
数据模型设计
核心实体包括：
- 物理服务器：序列号为主键，关联机房位置、机柜U位、上架日期、维保到期日。
- 虚拟机：UUID为主键，关联宿主机、资源配额、业务归属。
- 网络设备：管理IP为主键，关联端口、VLAN、互联拓扑。
- 业务应用：应用名为主键，关联服务器集群、负责人、SLA等级。
关系模型用图结构来保存数据（可以选用Neo4j或者关系型数据库加闭包表），能够快速地执行诸如“某个业务部署在哪台服务器上”这样的拓扑查询。
保证数据的一致性
- 唯一性约束：序列号、UUID、管理IP在全局范围内强制唯一，重复上报直接拒绝并告警。
- 状态机管理：每台资产记录包含状态字段（已上架/已下架/待回收/故障），状态变更需审批流驱动，禁止Agent直接修改状态。
- 版本快照：每次数据更新自动生成版本快照，支持任意时间点回滚与变更审计。
自动调度和差值处理
盘点任务编排
调度引擎有三种触发方式：
- 定时任务：每日凌晨低峰期执行全量盘点，周末执行深度盘点（含硬件健康状态）。
- 事件驱动：监控系统检测到服务器重启、硬件告警时，自动触发该节点重新盘点。
- 手动触发：运维人员通过API或Web界面指定单台/批量节点即时盘点。
差异比对与闭环处理
当盘点结果回来之后，CMDB会进行三次对比：
- Agent采集的值和CMDB中现有的数据
- CMDB当前值与上次采集的数据对比
- 根据严重程度进行分级：
| 差异级别 | 判定条件 | 处理动作 |
|---|---|---|
| 严重 | 序列号变更、IP冲突、未授权新设备接入 | 立即阻断并发送告警至运维值班组 |
| 重要 | 硬件配置增减（内存/磁盘）、业务标签变更 | 生成变更工单，要求业务方确认 |
| 一般 | OS版本升级、运行时间更新 | 自动合并至CMDB，记录变更日志 |
解决信息孤岛问题的方法就是使用数据联邦和API网关
在多机房的情况下，各个机房都有自己的独立CMDB或者Excel台账，该方案利用API网关层来进行数据联邦：
- 适配层：为各存量系统开发数据适配器，将异构数据格式统一映射至标准CMDB模型。
- 同步策略：主CMDB作为权威源，定期向各机房本地缓存推送增量数据；各机房Agent采集数据统一上报至主CMDB，形成双向同步。
- 权限隔离：通过RBAC模型控制各机房运维人员仅可见本机房资产，全局管理员拥有跨机房视图。
实施路径与效果验证
分步实施
| 阶段 | 周期 | 交付物 | 验收标准 |
|---|---|---|---|
| 试点机房 | 2周 | Agent部署、CMDB基础模型、采集脚本 | 试点机房100%服务器纳入管理，数据准确率>99% |
| 全量推广 | 4周 | 多机房接入、调度引擎上线、差异告警 | 全量服务器自动盘点覆盖率>95%，人工介入率<5% |
| 深度优化 | 持续 | 硬件生命周期管理、容量预测、成本分摊 | 资产数据实时性<1小时，盘点人力成本降低80% |
量化收益
- 把周期由月份缩短到小时。
- 数据的准确性由原来的90%-95%提高到99.5%以上。
- 一台服务器的整个生命周期内的总费用可以降低大约40%，即减少了人工审核和空闲浪费。
- 故障定位时间减少：利用CMDB拓扑进行查找，由原来的30分钟缩短至现在的3分钟。
总结
多机房服务器资产自动化盘点方案的核心就是把Agent采集的数据和CMDB中的信息结合起来，用统一的数据模型来打通各个机房、各个业务线之间的信息孤岛，通过自动化的调度和差异对比的方式减少人为录入错误，从而达到从“被动记录”到“主动感知”的转变。该方案能否成功的因素不是技术栈是否先进，而是数据治理规范是否得到严格执行以及相关的组织流程是否有相应的调整——技术工具可以提供能力，而管理规范可以保证质量。