400-8615-123 CMDB（配置管理数据库）的构建没有统一标准，但遵循ITIL框架、按“模型设计—流程运作—渐进实施”三步走，是当前企业落地配置管理的主要路径。
CMDB是什么，为什么ITSM离不开它
CMDB是记录每个配置项（CI）全部信息及配置项之间关联关系的数据库。ITIL《IT服务支持》对它的定义是：“包含每一个配置项全部关联细节，以及配置项之间重要关联细节的数据库”。
在ITSM体系中，CMDB为事件、变更、问题等流程提供配置信息支撑。没有CMDB，变更影响分析、故障定位、服务影响评估都缺乏数据基础。早期CMDB以电子报表形式存在，后来依附于帮助台资产库，如今已发展为独立的系统管理模块。ITIL v2确立了CMDB在ITSM中的核心位置，ITIL v3则把CMDB与知识管理、报告展现更紧密地结合起来。
构建第一步：模型设计，保证数据完整
CMDB模型设计的核心目标是让记录的数据完整反映IT服务真实状态。设计工作分三步：确定配置管理范围、定义CI属性、构建CI关系。
确定配置管理范围
范围涉及CI的宽度、深度和生命周期。规划宽度与深度时，要从企业IT服务需求、IT服务管理水平、CMDB运营维护成本三方面权衡。IT服务本身可作为CI记录到CMDB，其依赖的基础架构和重要信息也应纳入。CI颗粒度越细，信息维护成本越高；管理水平越高，对CMDB数据准确性和完整性的依赖也越大。
CI生命周期覆盖从采购申请到报废退出的全过程。实际实施中，流程执行主体的管理范围和职责决定CI被识别和删除的时间点。例如租赁设备，IT部门只关心运营状态，设备被更换后该记录可标记为删除。标记删除而非物理删除，是为IT审计保留数据痕迹。
定义CI属性：精而不多
CI属性选取遵循“精而不多”原则，注重“面向服务”的属性。一台商用服务器可能有上百个属性，对企业有实际意义的往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。属性过多加大维护成本，过少则削弱对流程的支持。一套CI属性通常可划分为五大来源，具体划分方式因企业需求而异。
构建CI关系：自上而下还是自下而上
CI关系定义是配置管理与资产管理的核心区别。梳理关系有两种方法：
- 自上而下：先明确服务目录，按“业务服务→IT服务→IT系统→IT组件”顺序梳理。
- 自下而上：先梳理内部IT组件关系，再逐步映射到IT服务。
两种方法适合不同成熟度的企业。自上而下适合服务定义清晰的组织，自下而上适合从现有资产盘点起步的团队。
构建第二步：流程运作，确保数据正确
上线后的CMDB要与生产环境保持一致，需要配置管理政策、变更流程接口、审计流程和角色安排四方面机制保障。
配置管理政策
政策分宏观和运营两层。宏观政策是IT部门层面的方向和指导原则；运营政策涉及流程目标、人员、输入输出、活动及KPI，包含CI命名规范、数据保留、备份恢复等政策。政策的作用是统一认识，减少沟通成本。
与变更/发布流程的接口
变更管理流程掌握CMDB数据变更的“通行证”。CMDB数据的任何变更都应对应已批准的变更请求单，由变更管理将信息递送给配置管理人员执行更新。更新分三种情况：
- CMDB数据结构变更：因管理需要重构模型，如新增CI类型、重新梳理关系。
- 新增或删除CI：如更换设备、新采购配置项。
- 修改CI属性：如服务器硬盘扩容后调整对应属性。
CI属性变更往往关联其他CI的调整。比如硬盘CI变更，管理员还需修改服务器CI属性。为降低维护成本，可让属性数据从可靠数据源继承，例如服务器硬盘容量从硬盘CI的属性直接获取。
CMDB审计流程
审计用于检查、分析和修订账实不符的问题。首次审计在CMDB初始化上线前进行，此后全面审计定期展开，周期一般至少一年一次。专项审计可小范围核查某类CI或关键服务的“账实相符”情况。发现数据不符时，应查明原因、通过变更工单提请变更、最终修改CMDB数据。审计员应由监管单位或独立部门人员担任，审计流程独立于日常运维。
配置管理角色
配置管理活动涉及四类角色，各司其职：
- 配置流程负责人：对流程执行结果负责，拥有管理权力。
- 配置经理：负责流程开发与管理，确保配置信息准确可用。
- 配置管理员：维护配置数据，保证CMDB信息持续准确。
- 配置审计员：通过审计操作确认配置数据真实性。
构建第三步：部署推进，丰俭由人
CMDB构建投入没有固定答案，有的企业自建，有的采购商业软件，也有开源低成本起步的案例。选择哪种方式，取决于企业对数据覆盖能力、投入预算和落地周期的判断。
自建还是购买
部分金融企业选择自建CMDB。商业CMDB工具能自动发现基于服务器的软件应用并构建映射关系，但对主机应用或企业自行开发的应用检测能力有限。对于存在大量自有和遗留应用的行业，商业工具对整个IT环境的覆盖能力不足。自建需要投入更多资金，但能保障CMDB的独立性和实时性。电信行业也有用户倾向自建，原因同样是商业软件对生产环境中管理对象的发现能力欠缺。
低成本起步的路径
CMDB并非必须大额投入。有高校基于开源数据库（如MySQL）构建校园CMDB，严格筛选CI的类和子类，规避颗粒度过细带来的成本上升和构建难度。后续再评估升级到商业数据库平台。这个案例说明，CMDB的投入规模可以按需控制。
分阶段实施的建议
传统自下而上的做法是先建大型配置数据库再精炼CI，缺点是投入大、周期长，有的企业耗时数年才能完成。已有简单配置数据库的用户，可自中而上，在现有数据库基础上添加CI和关系，短时间内组建功能较丰富的CMDB。
对白手起家的用户，“自上而下、渐进式扩充”可行性更高。可从订单系统、邮件系统等垂直应用开始，在单一环境中积累配置管理经验，形成成熟流程后再扩大范围。试验项目应包含审计、控制、自动化等必要环节，选择有广泛支持、更新不频繁、相对独立的IT服务启动，频繁变更会增加管理难度和出错概率。
CMDB成熟度怎么判断
Gartner的CMDB研究报告指出，不是所有配置数据库都能称为CMDB。成熟CMDB具备联邦性、协调性、同步性、映射和可视化四个特性。市场上有些所谓CMDB，更像帮助台资产库的延伸，数据实时性无法保证，模型设计不符合ITIL规范。
联邦性是区分成熟与不成熟CMDB的刚性标准之一，也是技术演进的重点方向。传统CMDB把数据复制到专有架构中，容易造成CI冗余，且限制了对多数据源的集成。联邦式CMDB通过逻辑连接多个配置数据库，记录配置信息的关联关系，访问时快速追溯数据位置。在高度异构化环境中，把所有配置数据存进一个通用数据库并不现实，联邦式方案更可行。
适合谁：CMDB选型问与答
问：我们公司IT环境不大，有必要建CMDB吗？
答：如果IT服务管理刚起步，可以先从资产台账和变更记录做起，不必一步到位建完整CMDB。CMDB的价值在于支撑事件、变更、问题等流程的联动，流程不成熟时建CMDB容易变成“数据坟墓”。建议先跑通变更流程，再逐步引入CMDB。
问：CMDB怎么选型，自建和商业产品怎么取舍？
答：商业产品适合标准化IT环境、应用以常见商业软件为主的用户；自建适合存在大量自研或遗留应用、商业工具覆盖不足的企业。开源方案适合预算有限、愿意投入人力维护的团队。选型前先评估现有IT环境复杂度、配置管理成熟度和可投入的运营成本，以实际需求为准。
Servicehot是永服科技旗下的ITSM工具，产品不开源，提供配置管理功能。永服科技面向企业IT服务管理场景，把CMDB作为ITSM体系的一部分来交付。选型时，可以把Servicehot这类商业ITSM产品作为参照，对照自身需求逐项评估。
