4.0 什么是配置管理
配置管理是itop的核心，而且其他模块几本都要依赖这个模块的部分功能来实现
本手册不会太详细的讲解整个配置管理是怎么构成和运作的，重点是告诉你怎么使用，基本的结构是怎样的，这些内容官方wiki基本都有，而且更详细。
如果英文没有问题的可以直接去这里看wiki资料.
当然了，我后面写的内容可能会风格不同，从用户角度去讲解怎么使用。
本章大概会包含一下几个部分：联系人介绍、帐号、配置管理基本流程、配置项的创建和修改、配置项的关联关系。
4.1 联系人和帐号
首先，联系人和帐号是完全不同的两个东西，很多人没搞清楚
- 联系人：其包含 person和team，指一个具体的人或者一群人组成的团队，在配置管理中任何地方都是联系人，不是帐号
- 帐号：account，通常情况下是一个人的帐号，用于登录系统，帐号必须要属于某一个联系人才有效，在权限管理（profiles）里面都是帐号，不是具体的人。
一个人可以有零个或者多个帐号，但是一个帐号必须属于一个人。
4.1.1 联系人管理
在配置菜单下面点击Contacts下面的New contact，在右边区域就会显示创建联系人的第一个页面，选择好创建一个人还是一个团队进入下一个具体的创建页面
第二章 后台基本操作在前面章节其实已经讲过了，所以就不详细介绍操作方法了，这里大家要根据自己公司的情况，安排lastname和fistname的区分，在itop里面这两个名字是分别存在accout和person两张表里面的。对大部分公司来说，其实这个“人”应该都是从ldap或者其他oa等集中目录服务里面去导入的，很少会一个一个创建。
创建和修改都没有什么可说的，需要注意的是删除，
删除一个联系人会重置所有他关联的CI，和工单相关属性。比如已经关闭的工单，重置以后也是没有办法修改的，所以，在确定删除之前，尽量把需要的一些数据做处理，避免以后统计的时候没法找到历史数据。
4.1.2 团队的创建和维护
这个只说两个事情：
- 一个团队至少要有一个人，注意合理安排人员的组织，通常来说团队是后面配置功能的时候用到的，比如服务台配置、变更管理的各个团队
- 团队的邮箱是可选的，但是，这是一个重要的通知邮件，在很多场合会用到，建议配置单独邮箱或者邮件组，不支持配置多个邮箱
其他注意一个notification就好了，这个是当被选作contact联系人时，是否可以实现通知，默认都要选上yes
4.2.1 itop的主要配置项
itop里面配置项分为功能性配置项和连接性配置项，我们关注的都是功能性的配置项，这个在数据模型里面很清楚。
配置管理的核心并不是知道怎么创建每一个Item，核心是管理好每个Item之间的关系
那么我们有一些什么样的Item呢，除了前面提到的联系人，我们还有一些 location、Document等，然后才是我们的主要功能CI，也就是我们常说的资产类，比如服务器、中间件、软件、网络设备等。
在overview里面可以看到itop对配置项的默认分组和主要的配置项的名称和数量，可以在任何项上面开始新建和搜索已有的配置项，也可以在左边菜单开始创建或者搜索。
4.2.2配置管理的主要工作
单纯的说配置管理其实没有太大意义，因为我们不会为了配置而去做配置管理，配置管理就是整理所有的资产配置项，把他们的关系正确的表示出来，并且会伴随这变更管理事件管理等对配置进行更新、发布，让配置信息和实际生产的实体相符合。
成功的配置管理一定是每天都有人用，随时依赖配置管理去构建其他应用的流程。
所以配置管理员通常会和变更实施团队一起工作
那么配置管理员到底做什么呢？
1.制定配置管理基线，确定配置项的颗粒度
1.根据配置变更需求进行配置项的增加、删除、修改。、
2.通过对配置信息的影响、依赖关系，提供数据报告，以方便变更、发布作出判断和计划
4.2.3 配置管理默认架构的理解
虽然说单纯的添加、修改CI都会了，操作也并不复杂，但是很多人还是无法执行配置管理的操作，问题在于？他根本不知道要怎么去组织这些CI，需要修改那些东西。既然这是真谛配置管理员的一个手册，简单说一些itop里面定义的配置项关系：
在官方的wiki里面大概将配置项分为了这样几组：Infrastructure、Virtualization（选择安装）、End user devices、Software and applications、Network、Miscellaneous
具体的关系：
这个内容会有点多，要说清楚不容易，作为一个用户手册在这里不做详细说明，更多的信息我会在博客专题（www.hardie.me）里面进行解释
- Contacts： 联系人，很简单，前面已经有介绍，单独出现没有太多意义，主要包含人员和团队，更多的时候是出现在别的CI tab里面，作为和CI相关的主体，通常意味着是负责人或者需要提醒的人。
- Documents：这里其实包含普通文件（比如PDF文档，各种上传的附件，方便其他CI引用）、 Document Note（通常是比较简短的文本记录，支持HTML）和Document Web（外链方式URL记录）三种，可以理解为一个文档中心，有人单独拿出来作为一个大的菜单使用。
- Application Solution：应用方案，可以理解为一个能够交互的项目或者功能，通常由一些中间件或者其他子Application Solution组成。注意，这个一定是以功能项目为导向来做的。
- Business Process：业务流程，这个可以理解为一个应用或者一项操作逻辑，通常可以用来描述一个高级的应用解决方案的流程，用于规范操作或者提示。
- DB Server&Database Schema：这个应该比较好理解，不过对于不同的数据库要不同对待，简单点说，DB Server相当于一个具体的数据库实例，而Database Schema是一个库或者一个应用栈，面对具体应用，通常应用的直接依赖就是 Schema，而Schema依赖 DB Server 注意这里不是Server（服务器）哦
- Middleware&Middleware Instance：中间件、实例，这个也比较好理解，和数据库类似，不过在实际应用当中，我们通常一个机器上一个角色，一个应用，这种情况下，我们可以考虑把Middleware Instance取消了，应用直接对中间件，可以根据自己的实际环境做安排。
- Network Device：网络设备，这个就是交换机、防火墙、网络接口等，网络设备一般是比较底层的了，上连就是机柜级别的了，下连是服务器存储级别的。
- Other Software：各种应用，一般是为了给其他应用方案提供支持的，也可能是操作系统辅助的，总之都是建立在Server上面的这种级别。
- PC Software：这个和普通软件没什么区别，对于重点使用服务台的企业来说可能比较有用，其他比较少
- Server：服务器，一台真实的物理设备，注意，虚拟机不算哦（启用了虚拟化设备）
- Web Application：这个主要是指直接提供web服务的应用，在现在这个互联网时代，其实很多application Solution就是由 web application组成的
- Miscellaneous：这里包含OS Licence&OS Patch、Organization、Software&Software Licence&Software Patch等，这些都是小型CI，不参与主要架构组成，但是软资产的一部分
- Typology：这个理解为CI的模型分组管理，不是网络的top结构，在数据管理的菜单下面可以快速设置。
4.3.1 配置管理的职责和目标
很多人都知道要做配置管理，但是很多人都不明白为什么要做配置管理，怎么才能做好。
明确一点：配置管理不是资产管理，配置管理不仅关心这是谁，更关心这和谁有关系。在配置管理里面，我们需要表示的是一个产品它由什么东西组成，它锁依赖的项和影响的项。这样才能为我们的三方流程提供数据支持。
所以配置管理的职责就是维护好所有CI的真实性，关系的正确性，确保CMDB里面的数据和真实的数据一致，完成生产环境的虚拟化，可以从cmdb里面看到我们的整个环境情况。每当有配置需要变更（服务器上架、新的软件部署等）要及时的根据流程进行更新反馈。
通常来说，配置变更会定义几个角色来共同管理配置数据，配置信息搜集岗、配置管理岗、分类的配置维护岗等。收集岗位负责收集配置需求，发布配置计划，负责和变更管理人员进行协调整理数据；配置管理岗位负责配置库的基础数据建立，定义范围，验证配置的正确性。配置维护岗位负责自己专业方向的设备、软件的配置维护，一般来说会有网络、服务器、应用等维护人员，他们可以和收集岗位协同工作。
要保障IT服务的稳定性、可靠性，我们必须保证CMDB的正确性，督促所有相关人员主动提供配置信息，依赖流程去执行变更，让配置管理成为所有IT服务的核心支撑。
文章评论