对于配置管理，相信每个从事IT运维的管理者并不陌生，要说其重要性和意义，相信也可以引经据典，娓娓道来。但具体到执行层面，就会是1000个读者会有1000个哈姆雷特的现象，本文在此也来谈一谈配置管理在IT运维管理工作的落地问题。
规范的IT运维，如果遵循ITIL的管理模型，就配置管理相关的事情上，事实上包含两种类别的管理：IT资产管理和配置管理。
IT资产管理，就是对IT资产实物的生命周期全过程的管理，包括：采购、存储、使用、维修、退役、报废各个环节。其关联的信息有价格、价值、合同、人、位置、时间等要素，其过程实质是对企业资产进行监控的一套会计核算流程。
配置管理与资产管理有着相同的实物承载对象，是IT资产实物管理在逻辑维度上的延伸，具体特点体现在管理的对象上。对IT实体系统的配置管理，主要管理两种元素，一类是CI项，即配置管理项，一类是该对象与其它CI项的关系。配置管理主要表达是以下两类信息：1.它是谁；2.如果我对它进行改动，会影响到谁。一个有效的配置管理数据库，可用于故障定位、问题分析、变更影响分析、容量决策、组件失效影响度分析（CFIA）、故障树分析（FTA）等决策辅助，这正是资产管理无法做到的功能，是规范化IT运维的价值体现。
虽然配置管理在IT运维工作中有着积极作用，但在实践应用的过程中普遍会存在以下问题：
问题一：CI项的粒度问题
多数IT部门一旦决定上ITIL标准化管理，便容易进入一个误区，即“贪大求全”，特别是在某些ITIL化软件的预设模板下，很容易就不假思索的要求实现的CI项尽量详细，结果经过IT运维人员一番折腾，终于将信息收集和录入完成，正所谓“一鼓作气，再而衰，三而竭“，经历了一段时间的运行后，繁重的配置项更新工作接续而来，IT工程师发现，配置管理能够一定程度帮助解决问题，但原来并不需要的维护工作却多得透不过气了，结果怨声载道，最终配置管理无法执行。针对该问题，我们认为问题的症结在于CI的粒度把控不恰当，可以通过控制CI粒度探索解决方案。
解决办法：
解决上述问题的关键，在于如何确定CI的颗粒度，这里我们建议在定义CI项的构思阶段，遵循以下原则：
1、目的导向原则
所制定的CI必须以面向服务、面向客户、或面向业务为导向，任何与以上目标不相干的CI创建，都不予考虑。如设备的颜色，重量，尺寸等，一般情况下，无需关注。
2、够用原则
从相互影响，辅助判断的必要性等角度考虑设定必须的识别项，实行够用原则定义识别项
3、持续改进原则
持续改进即贯彻ITIL的PDCA原则，在开始阶段，不求完美，但力求建立持续改进机制，定义CI项在开始阶段可以采取宁缺勿滥的方案，在后续运行中完善改进。具体操作，可先对某一配置管理依赖程度较高的领域入手试行推进，将配置关系信息转化为抽象信息存储于CMDB，用数据库记录替代人的记忆，使配置信息发挥类似地图的作用，降低对处理者的能力要求，摆脱对人的依赖程度。
问题二：配置管理的实现方法问题
上面提到，配置管理可用于故障定位、问题分析、变更影响分析、容量决策、组件失效影响度分析（CFIA）、故障树分析（FTA）等决策辅助。但在实践中，由于管理者对其理解的不透彻，导致实现方法出现偏差，常见的错误是简单地将配置管理止步于CMDB，即仅仅建立了配置数据库，便认为实现了配置管理，但在运行过程中，发现并不能发挥预期的效果，反而在维护成本，运作效率等地方表现出负偏离，对于复杂程度不算高，规模不算大的IT运行环境，该状况尤其突出。
事实上要实现配置管理前述的功能，是有其前提条件的，其前提条件正是ITIL管理模式中各个管控流程有效协调运转。配置管理只是IT运维管理中的一个管控环节，要发挥其最大作用，必须有其它管理流程协同运转。通常，建立了一个新流程，无可避免产生了运作成本，而我们的目的是要这个流程产出的价值，要比产生的额外成本低。有此认识之后，我们就明白当我们用Excel表格，或单一数据库实现的配置管理，其功能将会非常有限，因为当中的条目（配置项）未能有效地与事件，时间，动作，状态相关联，其表达的信息是孤立的，静止的，也就不能理解，该种配置管理的实现方法不能发挥预期作用的结果了。简单孤立的CMDB，只能得到比资产管理稍稍详细的状态数据，而系统性的配置管理事实上是ITSM的一个模块，通过与各个管控模块之间的协作，才会发挥出其应有的作用，以有效的机制应付庞大的IT系统，真正帮助IT运维工作高效持续有序的运转。
