[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放[p=30,2,center]
[p=30,2,center]
配置管理”通过识别、控制、维护和验证现存的所有“配置项（CI）”的版本来制定IT基础架构的逻辑模型。
[配置管理数据库（CMDB）]的定义
记录CI项和CI关系的数据库
[配置项（CI）]的定义
ITIL中是这样定义CI的：它是基础设施组件或者是一个对象，处于（或将处于）“配置管理”的控制下。各种CI的复杂性、大小和类型可能有很大的差异，可能是一个完整的系统（包括所有硬件、软件和文档），也可能是一个模块或较小的硬件组件。
CI类型有以下几大类：
硬件
软件
文档（包括技术文档、流程和规范及图表）
IT人员
[目标]
对公司内部的所有IT资产和配置及相关服务做出说明
提供相关配置及其记录的准确信息以支持其它IT服务的运行
为“事件管理”、“问题管理”、“变更管理”、“发布管理”提供坚实的基础
对照基础设施验证配置记录并纠正任何异常情况
[学习体会]
我们将其目标分解成几个部分，然后分别进行分析：
通过识别、控制、维护和验证现存的所有“配置项（CI）”的版本来制定IT基础架构的逻辑模型
“配置管理”是围绕着配置项（CI）展开的。刚接触ITIL的人很容易将配置管理与资产管理搞混淆，实质上二者也有相似之处。通常我们说的资产管理，指的是设备、装备、机器、工具、材料等这些物质形态存在的资产，像打印机、PC机、服务器等等。但在ITIL中，这样的管理线条明显太粗了，我们需要的是更具体一点的内容，比如一个服务器配置了不同的端口，每一个不同的端口可能会有不同的链接，这时端口就可以定义成为CI。
配置项（CI）是ITIL中所有活动的最基本的支撑，可以这样说，如果没有准确的配置项，实施ITIL就是“天方夜谈”。
但是，仅有配置项（CI）就想完成配置管理，也是一件非常困难的事情。因为不但要搞清楚自己的家底有多少，还要摸清楚家底的状态（哪些在用，哪些不在用），也就是说要搞清楚资产项目之间的关系，只有这样才能在出现问题时把故障点及与它关联的这些设备找出来，并估计故障影响范围，及时作出调整。
“配置管理”是对CI进行管理，但更是对CI关系进行管理，所以可以这样说，CMDB中记录的20%是CI项，80%是CI项之间的关系。
该目标的特定要素还包括对配置项（CI）进行维护和使用，这就要求CI的准确性，并且有一套行之有效的方法来管理CI。要不然下面的这种情况就不足为奇了，例如客户报告“我的扫描仪不能使用了”。服务台的回答是：“这并不奇怪，根据我们系统的记录，你并没有配置扫描仪”。（虽然这看似荒诞无稽，但的确说明了问题所在。）
因此，如果还没有一个集中的CMDB，那么我们需要实施ITIL；如果还没有一套行之有效的方法来把握IT资产状况，那么我们需要实施ITIL。
对公司内部的所有IT资产和配置及相关服务做出说明
这是一个重要目标，因为并不是所有CI看上去都是资产。例如，内部编写的程序、规程记录以及人员通常不会被视为资产，但是它们都是“配置对象”。该目标要素意味着应该进行核查以确保所有可能的CI都应该包括在“配置管理数据库（CMDB）”中。确定是否满足该要素的要求非常简单。是否进行了核查？当然，如果您没有CMDB，的确也不会有什么内容可供核查。
提供相关配置及其记录的准确信息以支持其它IT服务的运行
CMDB是所有其它IT服务运行的基础，但并只是记录它就够了，而是要把它与其它的服务流程有机的结合在一起。例如，当服务台在事件记录中输入数据时，是否能够自动从CMDB中取得相关的数据；这完全依赖于CMDB中正确记录CI项的关系。
|
转播
分享
淘帖
()
