Saturday, December 04, 2010

ITIL两要素: incident, problem

ITIL的本质:以流程为导向的最佳实践集合,用于IT服务管理,并非理论


通常做法:一期先上五个基础模块:事件管理、问题管理、变更管理、配置管理和发布管理——这五个日常管理的流程。

ITIL的两个最核心的基石一个是配置管理,另一个是SLA管理

变更是指在维护过程中对系统或服务所作出的各种改变,包括增补、移除和其他修改。说的再具体一点,变更的对象是两个,一个是IT基础架构,一个是IT服务(包括与流程和文档),

变更管理审批的是要不要做
发布管理审批的是怎么做


变更是指在维护过程中对系统或服务所作出的各种改变,包括增补、移除和其他修改。说的再具体一点,变更的对象是两个,一个是IT基础架构,一个是IT服务(包括与流程和文档),

服务台不是流程,只是职能

事故就是任何标准操作之外的事件,可能会导致服务质量问题。事故管理的要点就是尽快恢复服务,减少事故损失。

问题管理就是解决问题根源,减少和防止事故,强调主动预防。

Incident Management can be defined as :

An 'Incident' is any event which is not part of the standard operation of the service and which causes, or may cause, an interruption or a reduction of the quality of the service.

The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price.


. A 'problem' is an unknown underlying cause of one or more incidents, and a 'known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified

人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会,一方面在“重在参与”精神的感召下,ITIL 在企业用户中迅速普及;另一方面,“更高、更快、更强”的目标激发了参与者的潜能,用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中,CMDB因其对企业ITIL实施效果的决定性作用,被比喻为ITIL的“发动机”。

Service support(侧重于用户as a customer of ICT service) and service delivery(侧重于business as customer of ICT service,包括Service level mgmt,capacity mgmt, Continuity, availa, financial mgmt )

service desk
“配置管理”是对CI进行管理,但更是对CI关系进行管理,所以可以这样说,CMDB中记录的20%是CI项,80%是CI项之间的关系。 (business process can be CI as well)
服务台 事件管理 问题管理 变更管理 日常作业管理 知识库管理

区分服务请求和事件:服务请求 service requests 也可以作为 “标准服务 standard services”。总体来说服务请求是在前期就已经协商好的。需要提供给用户的服务。而事件是临时出现的影响了或是可能影响了业务的事件。

ITIL的核心是服务管理模块,它包括服务支持和服务提供两个流程组:
事件管理、问题管理、配置管理、变更管理、发布管理构成了服务支持流程组。
服务级别管理、IT服务财务管理、IT服务持续性管理、可用性管理、能力管理构成了服务提供流程组。

配置项(CI)是ITIL中所有活动的最基本的支撑,

事件从服务台到事件管理再到问题管理是一个解决力度逐步加强的过程,但也是一个治标未治本的过程。要真正做到防范于未然或者减少事件影响,必须实施一定的变更

第3个问题,什么是配置信息,一个常见的误区是,我们以为CMDB的所有信息就是配置信息,这个观念是大家先天存在的,不能说它错,但是它不精确不全面,因为这里面暗含着一个逻辑是,不在CMDB中的信息就不是配置信息,这会直接导致一个极端,大家只关心CMDB的信息与是否变更与维护,但其实真正的配置信息以现在的CMDB技术发展而言,只有不到20%的配置信息记录着CMDB之中。到底什么是配置信息呢?,CMDB之中记录了一些CI,以及它们之间的属性,加上CI之间的关系信息,但对于现实的IT架构而言,这些信息的技术价值太低了,它在你重建与故障时只能给你有限的指导,我们有大量的配置信息是记录在各种手册之中的,大多数CMDB的做法是把这些手册当成CI,加一个版本属性,我们有更大量的配置信息是记录在架构本身的,比如一个软件的接口关系与访问关系,或者操作系统本身的设置信息,或者数据库的内部结构,所有的CMDB的做法同样是把这些当成一个CI,再加上几个属性了事。有一个设备是什么型号,这是配置信息,有一个软件是什么版本,这是配置信息,但这些都是粗放性,而且是偏管理性质的,真正的配置信息是更深入的,比如网络设备的ACL、软件内部的参数设置,这种层面的配置信息才是核心的,它分布于各种文档与对象本身中,从当前的CMDB而言,弄几个CI,加几个属性与关系,是根本无法将配置信息真正的管理起来的,这也是为什么CMDB一直难以发挥架构的控制与记录作用的关键因素,这是先天性的,这也是为什么所有的工程师最后觉得CMDB对他们的工作没有实际作用的原因,这现在的产品与实施方法都解决不了这一问题,以我目前的认知,只有云计算,才有可能让这一问题从根本上解决,但解决方式是另一个极端。

Labels:

0 Comments:

Post a Comment

<< Home