学习资料： ITIL培训基地专家讲堂直播 300期视频回放

IT运维05：配置管理

终于把IT运维服务中关于配置管理的内容整理了一遍，分享一下整理过程（见大标题），希望能够提供一些思路。主要做了两部分：

第一部分，设计配置管理过程控制的内容和方法，输出了《配置管理控制程序》；第二部分，设计指导运维人员如何开展配置管理的工作手册，完成了《IT运维服务工作规程》之配置管理部分。

配置管理是什么?

配置管理是对运维对象信息进行管理的过程，包括运维对象具体的配置项信息和运维对象之间关系的管理。

[color=rgba(0, 0, 0, 0.9)]配置管理有什么用？

[color=rgba(0, 0, 0, 0.9)]1）运维对象的各种信息能够被识别和记录，记录是完整的，持续更新的；

[color=rgba(0, 0, 0, 0.9)]2）可以为运维或其它管理活动提供准确的信息，提高工作效率，为实现SLA目标提供基础；

[color=rgba(0, 0, 0, 0.9)]3）所有运维对象的信息可追溯，部分甚至可回退至某一状态。

配置管理做什么？↓↓

[color=rgba(0, 0, 0, 0.9)]

[color=rgba(0, 0, 0, 0.9)]一）确定配置管理的范围

配置管理的范围主要是确定配置项有哪些，可以将配置项理解为运维对象中需要记录当前和历史状态的硬件、软件和文档。确定配置项范围，可以考虑以下几点：

• 需要记录当前和历史状态的；
• 需要追溯历史操作记录的；
• 需要确定初始状态或回退至某一历史状态的；
• 需要经常报告基本信息和状态的；
• 需要被审计的；   
• 服务范围内的。
  

分类管理配置项：

[color=rgba(0, 0, 0, 0.9)]

a. 文档类配置项包括合同、运维服务体系文件、工具文档等，例如：↓↓b. 软件类配置项包括应用软件、中间件、运维工具等，例如：↓↓c. 硬件类配置项，按照组织的服务目录进行分类，例如：↓↓
（二）设计配置层次结构
通过设计配置层次结构、命名规则，实现区别配置项的层次关系或从属关系等，层次结构如下图：↓↓
（三）确定配置项的关系、状态、命名规则

配置项之间的关系

• 安装在……上

  
  

  • 表示软件安装在硬件平台上，例如数据库安装在服务器上。

  • 表示硬件配置项的子CI关系，例如光模块安装在交换机上。
    
• 依赖关系
  
  • 表示软件之间的依赖关系，例如OA需要数据库才能正常运行。
    
• 连接关系
  
  • 表示硬件之间物理连接，例如服务器连接到交换机上。
    
• 文档关联
  
  • 表示文档类配置项与其它配置项之间的关系，例如与某硬件或软件相关的文档。
    

• 接入

  
  

  • 表示接入至某管理系统进行统一管理的硬件，例如摄像机接入至视频管理平台。

  • 表示接入至运维工具软件进行统一监测的硬件，例如服务器接入至运维平台。

  • 表示硬件接受管理或监测的所有软件。

    
    

• 配置调试软件

  
  

  • 表示硬件需要使用的运维工具软件，例如某特种设备需要使用的专用配置调试客户端。

    
    

• 托管关系

  
  
  • 表示机柜安装的硬件设备，例如1#机柜安装的交换机、路由器。
    
配置项的状态
• 文档状态
  

  • 已发布，文档审核通过并进行发布。

  • 审核中，文档草稿已经提交审核，尚未形成审核结果。

  • 草稿，文档草稿拟定中。

  • 废弃，文档已废弃。

    
    
• 软件状态
  

  • 启用，软件测试通过并发布，投入使用。

  • 测试，软件测试中，尚未提交测试报告。

  • 停用，软件停用状态。

    
    
• 硬件状态
  

  • 启用，硬件投入使用中，工作状态正常。

  • 闲置，硬件功能正常，未投入使用。

  • 故障，硬件处于故障状态，无法正常工作。

  • 在线，指硬件设备接入网络正常。

  • 离线，指硬件设备未接入网络，设备工作状态不详。
    
设计命名规则

按照配置项类型分别定义，每一类配置项又细分为不同类型，目的是通过名称能够快速理解配置项的属性和关系信息。

• 文档类包括:
  
  • 合同类文档
  • 服务体系类文档
  • 工具类文档
    
    
• 软件类包括:
  
  • 通用软件
  • 运维工具软件
    
    
• 硬件类包括:
  
  • 需方资产或安装在现场的供方资产
  • 需方资产或安装在现场的供方资产的子CI
  • 非现场的供方资产
  • 非现场的供方资产的子CI
    
分享一个例子（硬件类a）：↓↓
[color=rgba(0, 0, 0, 0.9)]
配置项命名注意事项：
• 名称不能太长
• 需要有具体的含义解释
• 能够反映从属关系和关联关系
• 应考虑未来的可扩展性
  
（四）确定配置项的属性

接下来需要针对不同的配置项定义其属性及关联信息，可以按照配置项的类型和功能分别进行定义。

文档配置项的属性：↓↓
软件配置项的属性：↓↓
部分硬件配置项的属性：↓↓
服务对象种类越多，需要定义的属性信息就越多，好在都是一次性工作。↓↓
[size=1.412em]（五）建立配置项
第一步，编制计划
计划内容至少应该包括以下内容：
• 合同、服务协议中规定的维护对象清单；（获取途径：复制粘贴）
• 运维对象的定义与分类；（获取途径：复制粘贴）
• 配置数据的规范要求；（获取途径：复制粘贴）
• 人员配置及分工；（自己编）
• 时间计划及交付成果。（自己编）
  
第二步，获取IT资产台账
与需方沟通并获取客户IT资产台账，一般的IT资产台账都涉及到保密的问题，但是如果运维人员不了解运维对象，就无法兑现承诺的SLA，况且经过日积月累，运维人员终究会获取到运维对象的信息，所以说不存在对运维人员或组织保密的做法。可靠的做法是需方与供方组织签订保密协议，要求需方组织与员工签署保密协议，并提供切实有效的保密措施，而不是“范本”。

将已获取的IT资产台账与合同中规定的维护对象清单对比，确定最终的配置项清单初稿。

第三步，收集配置项信息在收集配置项的属性信息和关联信息之前，事先编制好用于统计配置项信息的台账范本，如下图：↓↓

第二部分是将编号部分筛选后序列填充即可，尽量减少由于命名带来的工作量。

第五步，配置项审核配置审核工作由配置经理组织、配置管理员实施、配置项负责人配合进行，审核工作应以系统、单位、区域为单位进行抽查（量大抽查、量小全查），漏查的列入下次审核工作中，总之，要对全部新建的配置项进行审核，确保信息准确。

审核的内容至少应该包括：
• 配置项信息准确、完整并与实际情况一致；
• 配置项的状态描述准确；
• 配置项之间的关系描述一致。
  

---

结语

通过实际操作发现实施配置管理的最大阻力来自于人，即供方运维人员、需方的主管人员等相关干系人，大家对配置管理的认识比较模糊，不理解其内容和作用，再加上各方的关注点不同，导致这项工作很容易被忽视。

所以，我觉得它需要一个适宜的环境，才能发挥它应有的作用。

学习资料： ITIL培训基地专家讲堂直播 300期视频回放

IT运维05：配置管理

终于把IT运维服务中关于配置管理的内容整理了一遍，分享一下整理过程（见大标题），希望能够提供一些思路。主要做了两部分：

第一部分，设计配置管理过程控制的内容和方法，输出了《配置管理控制程序》；第二部分，设计指导运维人员如何开展配置管理的工作手册，完成了《IT运维服务工作规程》之配置管理部分。

配置管理是什么?

配置管理是对运维对象信息进行管理的过程，包括运维对象具体的配置项信息和运维对象之间关系的管理。

[color=rgba(0, 0, 0, 0.9)]配置管理有什么用？

[color=rgba(0, 0, 0, 0.9)]1）运维对象的各种信息能够被识别和记录，记录是完整的，持续更新的；

[color=rgba(0, 0, 0, 0.9)]2）可以为运维或其它管理活动提供准确的信息，提高工作效率，为实现SLA目标提供基础；

[color=rgba(0, 0, 0, 0.9)]3）所有运维对象的信息可追溯，部分甚至可回退至某一状态。

配置管理做什么？↓↓

[color=rgba(0, 0, 0, 0.9)]

[color=rgba(0, 0, 0, 0.9)]一）确定配置管理的范围

配置管理的范围主要是确定配置项有哪些，可以将配置项理解为运维对象中需要记录当前和历史状态的硬件、软件和文档。确定配置项范围，可以考虑以下几点：

• 需要记录当前和历史状态的；
• 需要追溯历史操作记录的；
• 需要确定初始状态或回退至某一历史状态的；
• 需要经常报告基本信息和状态的；
• 需要被审计的；   
• 服务范围内的。
  

分类管理配置项：

[color=rgba(0, 0, 0, 0.9)]

a. 文档类配置项包括合同、运维服务体系文件、工具文档等，例如：↓↓b. 软件类配置项包括应用软件、中间件、运维工具等，例如：↓↓c. 硬件类配置项，按照组织的服务目录进行分类，例如：↓↓
（二）设计配置层次结构
通过设计配置层次结构、命名规则，实现区别配置项的层次关系或从属关系等，层次结构如下图：↓↓
（三）确定配置项的关系、状态、命名规则

配置项之间的关系

• 安装在……上

  
  

  • 表示软件安装在硬件平台上，例如数据库安装在服务器上。

  • 表示硬件配置项的子CI关系，例如光模块安装在交换机上。
    
• 依赖关系
  
  • 表示软件之间的依赖关系，例如OA需要数据库才能正常运行。
    
• 连接关系
  
  • 表示硬件之间物理连接，例如服务器连接到交换机上。
    
• 文档关联
  
  • 表示文档类配置项与其它配置项之间的关系，例如与某硬件或软件相关的文档。
    

• 接入

  
  

  • 表示接入至某管理系统进行统一管理的硬件，例如摄像机接入至视频管理平台。

  • 表示接入至运维工具软件进行统一监测的硬件，例如服务器接入至运维平台。

  • 表示硬件接受管理或监测的所有软件。

    
    

• 配置调试软件

  
  

  • 表示硬件需要使用的运维工具软件，例如某特种设备需要使用的专用配置调试客户端。

    
    

• 托管关系

  
  
  • 表示机柜安装的硬件设备，例如1#机柜安装的交换机、路由器。
    
配置项的状态
• 文档状态
  

  • 已发布，文档审核通过并进行发布。

  • 审核中，文档草稿已经提交审核，尚未形成审核结果。

  • 草稿，文档草稿拟定中。

  • 废弃，文档已废弃。

    
    
• 软件状态
  

  • 启用，软件测试通过并发布，投入使用。

  • 测试，软件测试中，尚未提交测试报告。

  • 停用，软件停用状态。

    
    
• 硬件状态
  

  • 启用，硬件投入使用中，工作状态正常。

  • 闲置，硬件功能正常，未投入使用。

  • 故障，硬件处于故障状态，无法正常工作。

  • 在线，指硬件设备接入网络正常。

  • 离线，指硬件设备未接入网络，设备工作状态不详。
    
设计命名规则

按照配置项类型分别定义，每一类配置项又细分为不同类型，目的是通过名称能够快速理解配置项的属性和关系信息。

• 文档类包括:
  
  • 合同类文档
  • 服务体系类文档
  • 工具类文档
    
    
• 软件类包括:
  
  • 通用软件
  • 运维工具软件
    
    
• 硬件类包括:
  
  • 需方资产或安装在现场的供方资产
  • 需方资产或安装在现场的供方资产的子CI
  • 非现场的供方资产
  • 非现场的供方资产的子CI
    
分享一个例子（硬件类a）：↓↓
[color=rgba(0, 0, 0, 0.9)]
配置项命名注意事项：
• 名称不能太长
• 需要有具体的含义解释
• 能够反映从属关系和关联关系
• 应考虑未来的可扩展性
  
（四）确定配置项的属性

接下来需要针对不同的配置项定义其属性及关联信息，可以按照配置项的类型和功能分别进行定义。

文档配置项的属性：↓↓
软件配置项的属性：↓↓
部分硬件配置项的属性：↓↓
服务对象种类越多，需要定义的属性信息就越多，好在都是一次性工作。↓↓
[size=1.412em]（五）建立配置项
第一步，编制计划
计划内容至少应该包括以下内容：
• 合同、服务协议中规定的维护对象清单；（获取途径：复制粘贴）
• 运维对象的定义与分类；（获取途径：复制粘贴）
• 配置数据的规范要求；（获取途径：复制粘贴）
• 人员配置及分工；（自己编）
• 时间计划及交付成果。（自己编）
  
第二步，获取IT资产台账
与需方沟通并获取客户IT资产台账，一般的IT资产台账都涉及到保密的问题，但是如果运维人员不了解运维对象，就无法兑现承诺的SLA，况且经过日积月累，运维人员终究会获取到运维对象的信息，所以说不存在对运维人员或组织保密的做法。可靠的做法是需方与供方组织签订保密协议，要求需方组织与员工签署保密协议，并提供切实有效的保密措施，而不是“范本”。

将已获取的IT资产台账与合同中规定的维护对象清单对比，确定最终的配置项清单初稿。

第三步，收集配置项信息在收集配置项的属性信息和关联信息之前，事先编制好用于统计配置项信息的台账范本，如下图：↓↓

第二部分是将编号部分筛选后序列填充即可，尽量减少由于命名带来的工作量。

第五步，配置项审核配置审核工作由配置经理组织、配置管理员实施、配置项负责人配合进行，审核工作应以系统、单位、区域为单位进行抽查（量大抽查、量小全查），漏查的列入下次审核工作中，总之，要对全部新建的配置项进行审核，确保信息准确。

审核的内容至少应该包括：
• 配置项信息准确、完整并与实际情况一致；
• 配置项的状态描述准确；
• 配置项之间的关系描述一致。
  

---

结语

通过实际操作发现实施配置管理的最大阻力来自于人，即供方运维人员、需方的主管人员等相关干系人，大家对配置管理的认识比较模糊，不理解其内容和作用，再加上各方的关注点不同，导致这项工作很容易被忽视。

所以，我觉得它需要一个适宜的环境，才能发挥它应有的作用。