整体模型

3.1.2.2 录入配置项

1. 配置网络设备

(1).
在配置管理功能中,通过新建配置项或配置管理概览页面选择“网络设备”,新建一台新的网络设备;

图片 1

添加网络设备

图片 2

添加网络设备页面

(2). 在创建网络设备前确认网络设备配置项依赖的基础配置项是否已经创建,
如组织信息、地理位置信息(机房)、机柜及机位信息、电源信息等,
如果未创建, 需要先进行创建,
或者也可以在创建网络设备后创建,最后再对创建的网络设备进行修改;

(3). 录入网络设备的配置项信息;

网络设备的基础配置项应该包括以下信息:

  • 名称: 网络设备名称
  • 组织: 所属组织, 设备所属的组织,如信息技术部
  • 状态: 生产/上线/下线/空闲
  • 业务级别: 关联业务的重要程度
  • 地理位置: 网络设备所在的IDC信息
  • 机柜: 网络设备所在的机柜信息
  • 网络类型: 路由器/交换机/防火墙,可自行添加
  • 品牌: 网络设备所属品牌信息, 可自行添加
  • 型号: 网络设备型号信息,可自行添加
  • 管理IP: 网络设备的管理IP信息
  • 序列号: 网络设备的序列号
  • 资产编号: 公司对于设备的固定资产编号

图片 3

录入网络设备配置项信息

(4). 添加网络设备的关联配置项,
如果关联配置项未定义,可在关联配置项定义后再对服务器的关联配置项进行修改,关联配置项包括联系人、文档、所属的应用系统(解决方案)、相关设备等。

图片 4

添加联系人

2. 配置服务器

(1).
在配置管理功能中,通过新建配置项或配置管理概览页面选择“服务器”,新建一台新的服务器;

图片 5

新建服务器

图片 6

新建服务器页面

(2). 在创建服务器前确认服务器配置项依赖的基础配置项是否已经创建,
如组织信息、地理位置信息(机房)、机柜及机位信息、电源信息等,
如果未创建, 需要先进行创建,
或者也可���在创建服务器后创建,最后再对创建的服务器进行修改;

(3). 录入服务器的配置项信息;

服务器的基础配置项应该包括以下信息:

  • 名称: 服务器名称
  • 组织: 所属组织, 设备所属的组织,如信息技术部
  • 状态: 生产/上线/下线/空闲
  • 业务级别: 关联业务的重要程度
  • 地理位置: 服务器所在的IDC信息
  • 机柜: 服务器所在的机柜信息
  • 品牌: 服务器所属品牌信息, 可自行添加
  • 型号: 服务器型号信息,可自行添加
  • OS家族: 服务器所安装的操作系统类型, 可自行添加
  • OS版本: 服务器所安装操作系统的版本,可自行添加
  • 管理IP: 服务器的管理IP信息
  • MAC地址:服务器管理IP地址所属的MAC地址信息
  • KVM目录: 服务器所在的KVM目录信息
  • CPU: 服务器的CPU信息
  • 内存: 服务器的内存信息
  • 序列号: 服务器的序列号
  • 资产编号: 公司对于服务器设备的固定资产编号

图片 7

创建服务器

(4). 添加服务器的关联配置项,
如果关联配置项未定义,可在关联配置项定义后再对服务器的关联配置项进行修改,关联配置项包括联系人、文档、所连接的网络设备、所属的应用系统(解决方案)等。

  • 添加联系人

    图片 8
    添加服务器所属的联系人信息

  • 添加软件/应用实例

    图片 9
    添加服务器所运行的软件/应用实例

  • 添加解决方案(应用系统)

    图片 10
    添加解决方案

(5). 确认服务器配置项信息无误后,
点击“应用”按钮便可完成服务器的添加操作。

图片 11

确认服务器添加信息

(6).
如果需要对服务器配置信息进行修改,可以选择具体需要修改的服务器信息,
点击“修改”按钮,便可对服务器进行修改操作(如上图所示)。

3. 配置解决方案

(1).
在配置管理功能中,通过搜索配置项或者在配置管理概览界面中选择“解决方案”,新建一个新的解决方案配置项;

图片 12

添加解决方案

(2). 录入解决方案的基础配置信息;

解决方案必须录入的配置项包括:

  • 解决方案名称:
    IT系统名称,如:集中交易系统、融资融券系统、资管系统、OTC系统等)
  • 组织: 管理运维部门,如信息技术部
  • 状态: 启用/停用
  • 业务级别: 根据系统的重要程度设置其业务级别高低
  • 投产日期: 系统的上线运行日期

图片 13

录入解决方案基础信息

(3). 添加解决方案的关联配置项,
如果关联配置项未定义,可在关联配置项定义后再对解决方案的关联配置项进行修改,关联配置项包括联系人、文档、配置项(服务器/网络设备)、供应商合同、服务等。

关联配置项说明

  • 联系人:
    与该解决方案相关的联系人,包括供应商联系人信息、运维负责人信息、业务部门负责人信息及其他关键联系人;
  • 文档:
    系统所涉及到的文档信息,包括安装部署文档、运维文档、应急文档等,由于iTop系统将文档文件存放于数据库中,因此建议将文档放置在项目管理平台上,该处创建的文档类型为网页文档,只存放文档所在的URL路径;
  • 配置项: 系统所涉及到的关联配置项信息,
    包括服务器、网络设备和应用中间件信息;
  • 供应商合同:系统所涉及到的所有合同信息;

图片 14

配置联系人信息

图片 15

配置服务器/网络设备信息

(4). 确认解决方案配置项信息无误后,
点击“应用”按钮便可完成解决方案的添加操作。

图片 16

完成解决方案添加操作

(5). 解决方案添加完成后, 我们可以点击上图右上角的“其他操作”菜单,
在弹出菜单中选择“依赖于”,我们可以看到该方案所有的依赖配置关系,
如下图所示。

图片 17

配置项依赖关系

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-11/148408.htm

图片 18

·企业CMDB运营管理成本(后期能够投入多大的人力成本去维护和管理)

1.CMDB简介
CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。CMDB也被认为是构建其他ITIL流程的基础而优先考虑。
2.CMDB的功能
CMDB工具中至少包含这几种关键的功能:整合、调和、同步、映射和可视化。
3.CMDB建模思路
CMDB模型具有层次,包含核心模型和扩展模型,而扩展模型就是基于核心模型扩展出来的。围绕核心模型逐步驱动周边的资源配套,逐步实现资源完善。主要配置管理面向消费,发挥数据的价值,以数据和模型为核心、以整合的思路进行推进,实现元模型和拓展模型的相结合。
4.CMDB的优势与缺陷
1.整合、关系映射、防止配置偏差
2.CMDB节省成本和可扩展性
3.CMDB集成ITIL
4.为管理变更提供可预测方法
5.增强版本管理流程
6.CMDB初创时与各管理业务的数据模型不兼容
7.CMDB的易用性较差
5.CMDB难题-数据的准确度
数据的准确性对CMDB来讲是致命的,而CI无法及时更新、数据维护流程繁琐、数据完整性低等都会造成数据准确性降低。我们在构建CMDB时应该对这些方面的问题有所警觉。
6.CMDB的价值
1.避免配置数据被重复维护,降低数据管理的总成本;
2.共享同一套配置数据,使各运维业务对IT资产的基本配置情
况达成共识,并驱动各流程的自动化协同;
3.能够以CI为核心,拉通各个管理工具中孤立的数据,并通过面
向管理场景的数据分析和可视化,使IT管理者能更加全面的掌握
CI的运行状态和管理现状,提升管理的透明度

最终找到一个解决方法,是一个周五下午快下班的时候,当时正在画一个示意图,想向领导表达,日后如果我们完成配置的结构与关系构建后,呈现给我们的是一个怎样的东西,当时只把CI抽象成几个集合,CI是用一个圆圈图示代替,在画了几个图示后,突然有一点灵光闪过,我发现当把几十万个CI用这样方式串联起来时,象一个个灯泡一样,有的亮有的不亮,通过关系将这数量庞大的灯泡连接起来时,这种情况好象电路图,每一个CI
位于一个复杂的线路中,形成我们公司自已的配置地图,而且这是一个三维的图形,多个项目形成一个面,每个项目的根据结构展开的所有CI形成一个面,而每个
CI之间的关系又形成一个面,脑子里当时形成了这图象(这个三维的图形后来尝试了好几次用VISIO或PPT画出来,一直没有成功),想到这一点当时很兴奋,终于看到了一道门。于在是周末休息时,去书店把数字电路的书找来看了一些篇章,最终确定引入门电路的概念来解决关系的问题。

3.1.1 概述

配置管理提供了一个虚拟数据库,用来记录企业中的基础设施信息以及它们之间的关联关系,并提供科学化的流程来负责核实IT基础设施中实施的变更和配置项之间的关系记录是否正确、监控IT组件的运行状态,以确保配置管理数据库(CMDB)能够准确地反映目前IT运行环境配置项的实际状况。

从IT管理的角度上来看,对IT资产配置项(CI)的修改不应直接进行,而必须由变更管理流程发起,因此配置管理与变更管理是紧密结合的,变更管理流程引发和控制对配置项的修改和变更;相反,配置管理向变更管理提供详细的配置信息,以帮助变更发起人分析评估变更对IT运营所带来的影响。

iTop应用系统提供了一个完备的CMDB管理应用,使得IT运维人员可以管理其IT资产的配置项信息。它通过识别、控制、维护和验证现有的所有配置项(CIs)的版本,提供一个IT基础设施的逻辑模型。由于CMDB会记录配置项之间的关系,因此IT运维工程师们基于其关联关系对基础设施与服务之间的依赖关系进行分析。

图片 19

iTop系统配置管理

所有配置项(CI)都在iTop系统的数据模型中得到展现,并且可以根据企业本身的应用配置需求进行自定义。针对CI的所有变更可以通过变更时间、变更的属性值(旧值和新值)以及变更人员来对配置变更进行跟踪。

·有没有一套可落地的变更流程来对CI项必要的维护

由于以前实施REMEDY时,我们积累了一定的经验与知识,也具备一些配置管理的概念,所以规划方面,相对单纯一些,我们以管理科为主导,各业务领域的主管为成员,目标是所有项目的CI项纳入管理,在此作业开展前,我制作了一个作业计划,主要分几个阶段。

2. iTop系统概述

iTop,是IT运营门户(IT Operation
Portal)的简称,它是一个开源web应用程序,适用于IT服务的日常运维管理。它基于ITIL最佳实践,适应符合ITIL最佳实践的流程,同时它又很灵活,可以适应一般的IT服务管理流程。

iTop的核心是CMDB,即配置管理数据库(Configuration Management Data
Base)。CMDB是iTop最早开发的部分。以CMDB为中心的设计理念,需要保证CMDB的准确性和及时更新,服务人员和客户均使用iTop来解决运维管理中的各类问题将会对这一点有帮助。此外,CMDB与其它工具,如监控系统、报表工具、库存管理系统等整合得越多,CMDB的信息就会越丰富。CMDB快速实施,与其它系统相比iTop有丰富的CMDB接口,支持多种方式的数据导入。

iTop具备方便、快捷的二次开发接口,仅需要简单的数据库表操作知识及XML编写知识即可完成表单的二次开发定制。

iTop的功能包括:

  • 记录IT配置项(如服务器、应用程序、网络设备、虚拟机、联系人、位置、VLAN等)及其各个配置项之间的关联关系;
  • 管理事件、用户请求和变更审批与执行等;
  • 归档IT服务及与外部供应商的合约,包括SLA(服务级别协议);
  • 手动或脚本方式导出所有信息;
  • 批量导入或同步/联调所有来自外部系统的数据;

iTop角色包括:

  • 超级管理员(Administrator);
  • 变更主管(Change Supervisor);
  • 变更审批经理(Change Approver);
  • 变更执行人员(Change Implementor);
  • 文档作者(Document author);
  • 服务经理(Service Manager);
  • 桌面支持(Service Desk Agent);
  • 现场工程师(Support Agent);
  • 配置管理员(Configuration Manager);
  • 门户增强用户(Portal power user);
  • 门户用户(Portal user);
  • 问题经理(Problem Manager);

iTop基于Apache/IIS、MySQL和PHP,它可以在任何支持这些程序的操作系统上运行,如Windows、Linux(Debian、Ubuntu和RedHat)、Solaris和MacOS
X等。此外,由于iTop是基于B/S架构的应用程序,不需要在用户电脑上部署任何客户端,只需要一个简单的Web浏览器(IE
8+、Firefox 3.5+、Chrome或Safari 5+)即可使用。

·企业IT服务管理的水平(依据目前的管理水平能做到什么程度)

说明:

目录

  1. CMDB概述
  2. iTop系统概述
  3. iTop功能操作
    3.1. 配置管理
    3.2. 变更管理
    3.3. 事件管理
    3.4. 问题管理
    3.5. 服务管理

·物理关系——可以了解到,业务系统安装在哪台PC服务器上,PC服务器是通过哪台交换机的什么端口连接网络的,同时PC服务器与存储如何连接的,PC服务器存放在哪个机柜和机房,以及PC服务器是通过哪个断路器和UPS供电的等

运维组织:指我们内部的服务机构及员工信息

3.1.2.1 准备工作
  1. 做好基础配置信息,IT资产的配置项依赖于基础的配置信息,
    基础的配置信息包括组织、联系人、品牌、型号、OS系统及版本、用户角色、机柜、机位、电源等;

    图片 20
    组织信息配置

    图片 21
    联系人信息配置

    图片 22
    基础类型配置

  2. 做好基础配置数据后,就可以对配置项进行增加、修改、删除等操作。

·一套结构:我们通常可以把一个CI的属性分为五大来源

示意1

3. iTop功能操作

图片 23

先介绍一下我们的业务情况,我们公司的运维项目较多,有网络、系统的、桌面的、软件的,而且这些项目用到的设备都存在共用的情况,比如一个段线路,会属于多个项目使用,一台客户的电脑,也可能装有多个管理软件,同时它又是属于桌面运维的,这些我们的IT组件一是数量多(光是需要桌面运维的电脑台数在5000台以上),二是相互的关系复杂。

1. CMDB概述

随着信息技术的发展,
IT系统已经成为企业业务发展不可或缺的支撑基础。IT运维管理系统是以CMDB为核心,以网络、服务器、应用的监控为基础,操作行为审计为安全准则,上层整合了符合ITIL管理思想的服务台、事件管理、问题管理、变更管理等流程,从而使IT管理从日常的运营监控、统计分析、发现问题、解决问题向流程化管理转型。

CMDB(Configuration Management Database,
配置管理数据库),提供配置管理数据库的功能,衔接监控与运维管理,是实现运维管理的核心数据支撑环境。

CMDB包含了每一个配置项(Configuration Item,
简称:CI)全部管理细节以及配置项之间的重要关联细节的数据库。CMDB把零散在各处的不规范的资源信息,通过采集和关联的方式,集中在一个整体规划的信息库中,打破了管理模式之间的壁垒,通过识别、控制、维护、审查、展示IT资源,为技术监管、管理流程和业务服务提供准确、统一的配置数据支撑,帮助信息部门有效管控不断变化的IT环境和服务。

CMDB提供动态的配置模型构建,数据模型基于面向对象的数据建模,实现配置项分类、属性继承、关系建模、字典维护等,用户可以根据实际管理需求进行灵活扩展,完成IT基础框架的构建。

根据企业IT资源,我们对CMDB标准模型进行分类,如下图所示。

图片 24

CMDB标准模型分类

CMDB系统可分为:

  1. 面向基础设施的CMDB
  2. 面向业务应用的CMDB

图片 25

CMDB系统分层

所有配置项都有存在的意义,而他们之间的内在关系是CMDB的重要价值体现之一,关系明确了,运维人员就能准确的找到相关实体资源,当发生故障时能够快速定位故障来源及其影响范围,从而迅速的解决各种隐患。

服务目录:不作名词解释了

3.1.2 配置项管理

iTop系统提供了配置项管理功能,方便IT运维工程师可以通过配置项类型维护相关的配置项信息。

iTop系统维护复杂的IT资产关联关系,
配置项之间的关系存在相互的关联,如下图所示。

图片 26

配置项关联

因此,在实际的CMDB配置数据库管理过程中,
一般按照硬件基础设施到软件基础设施的配置管理过程进行配置管理的。

注:
以下配置说明过程可能与实际的系统有所差别(如后期系统定制),配置时以实际的系统操作为准。

·有没有制定与配置项相关的管理规范和制度

在构建ITSM系统时,我的建议是首先从配置管理开始,而不是通常人们建议的从事件管理开始,配置管理决定地你们的运维管理的精细度与作业方向,它如何规划设计,会直接影响流程,你的绝大多数的数据质量也是由配置管理所决定的,在这个基石没有想清楚与确定前,展开事件及其它流程,最后整个作业可能是松散的,甚至可能是错误的,你的配置管理越精细,它对你的事件流程及变更流程,都是会产生影响的,配置管理颗粒度越细,它对我们的服务人员的作业行为要求就越高,引发的变更控制措施也就越多。在我的想象中,配置管理是一个服务平台的最底层建筑,它也是一个约束整个服务机制的重要所在。所以在项目的最初期,我一直是想先开发CMDB的,先把CDMB搞出来,然后灌数据,直接维护,不用事件管理,也不要变更管理,而是光光的
CMDB,到时我想看看所有的CI信息进去后,整个运维地图是如何的,故障的推演是否能实现,如果这些都是稳固的,再在这个基础上构建其它的应用模块。

3.1 配置管理

·何时灭?(对CI记录进行删除)

剩下的关系是花的时间比较久的,查了不少资料,我一直想确定到底CI之间有哪几种关系,这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的,而不应该由我来思考,我也看了常态下象IBM他们的做法,但他们关系与结构是互为一体的,而且他们对关系的定义简单了些,所以最后没有采用。在思考CI的关系时,我甚至上升到哲学的层面,去思考人与人之间的关系有哪一些,事物与事物之间的关系有哪一些,看是否能对得出CI之间的关系有一些启发作用,也在网上查了很多关于事物关系的说明,可惜没有找到有用的说明资料。

作为IT管理的核心,CMDB逐渐成为系统管理项目实施的热点。在很多的案例中,由于忽视了CMDB的因素,ITIL的深入应用受到了极大的挑战。同时,由于CMDB是IT管理信息的集中,CMDB也是一个重要的工具和手段。

决定后,剩下来就是攻破结构与关系了。在那段时间的思考中,CI的结构是首先想通的,可能是因为以前是做ERP实施的关系,也可能是因为客户是汽车制造商的关系,最终我发现将CI组装时,它的呈现很象ERP中的BOM结构,这是个父子结构,它可展开任意的节点,这种结构具有很大的扩展空间,也解决了配置管理颗粒度大小变化的问题,经过几天的思考后,我已非常确定这个思路可以解决我们的CI结构问题。

·相关法案和法规对IT管理的需求

上面介绍的是思考过程,在完成这个思考过程后,在项目启动会上,汇报了此构想,得到领导认可,同时为了验证可行性,我找了一个公司典型的项目做了一次试验,看一下这样的模型是否存在问题。这里要说明一下,我们把结构与关系分离,一是考虑结构与关系是互不对等的,二是可以让其独立作用在不现的地方,这样分离之后,结构与关系本身更加严谨,我们将结构用于事件定位,关系用于故障推演,一个着眼于现在,一个着眼于未来。下面将展开细节说明。

广通软件在2004年就开始ITIL落地的尝试,并独立自主持续研发积累,形成CMDB为核心的运维解决方案,这两年为海关总署、中国航信、铁路总公司、浙商银行、黑龙江农信等政企用户,提供了专业的CMDB咨询设计及落地实施服务,在整个过程中,笔者深深的体会到,CMDB项目的成功,重中之重在于CMDB模型的顶层设计,下面针对CMDB的设计过程进行深入剖析。

客户组织:指我们的客户的组织及用户信息

·宏观政策:主要是涉及IT部门层面指导性、方向性的政策,其目标是在IT部门自上而下形成统一认识,从而有利于项目的成功。

细节的作业进程就不一一介绍了,在做这个计划与真正执行时,发现一些很有意思的现象,也算是经验了,这些点我会在下面逐一介绍到,下面将我们的整体的配置模型做一个介绍,

模型分类设计样例:

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注