【专题】一步一步实施itop项目之用户手册(4.配置管理)

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 团队的创建和维护

这个只说两个事情:

  1. 一个团队至少要有一个人,注意合理安排人员的组织,通常来说团队是后面配置功能的时候用到的,比如服务台配置、变更管理的各个团队
  2. 团队的邮箱是可选的,但是,这是一个重要的通知邮件,在很多场合会用到,建议配置单独邮箱或者邮件组,不支持配置多个邮箱
    其他注意一个notification就好了,这个是当被选作contact联系人时,是否可以实现通知,默认都要选上yes

 

4.2.1 itop的主要配置项

itop里面配置项分为功能性配置项和连接性配置项,我们关注的都是功能性的配置项,这个在数据模型里面很清楚。

配置管理的核心并不是知道怎么创建每一个Item,核心是管理好每个Item之间的关系

那么我们有一些什么样的Item呢,除了前面提到的联系人,我们还有一些 location、Document等,然后才是我们的主要功能CI,也就是我们常说的资产类,比如服务器、中间件、软件、网络设备等。
在overview里面可以看到itop对配置项的默认分组和主要的配置项的名称和数量,可以在任何项上面开始新建和搜索已有的配置项,也可以在左边菜单开始创建或者搜索。

4.2.2配置管理的主要工作

单纯的说配置管理其实没有太大意义,因为我们不会为了配置而去做配置管理,配置管理就是整理所有的资产配置项,把他们的关系正确的表示出来,并且会伴随这变更管理事件管理等对配置进行更新、发布,让配置信息和实际生产的实体相符合。
成功的配置管理一定是每天都有人用,随时依赖配置管理去构建其他应用的流程。
所以配置管理员通常会和变更实施团队一起工作
【专题】一步一步实施itop项目之用户手册(配置管理) 那么配置管理员到底做什么呢?
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服务的核心支撑。

发表评论

*