扯扯ITSM和ITIL

2010-01-25  籽藤 

 ITSM,即Information Technical Service Management,也叫IT服务管理。

 Matt向我解释它的时候,打了一个很简单的比方:“公司的电脑或是打印机坏了,就向IT服务部门申报,该部门再安排人员去解决。”这是一个很常见的场景,我觉得了解这个项目的业务应该不难。但当我试着了解了ITIL,我立即意识到自己的愚蠢。

 ITIL(IT Infrastructure Library),是一套方法论,帮助说明了如何管理IT基础设施的流程。话说ITIL产生的根源是英国国家电信局的IT服务水平不高,就找了一帮顾问和专家来寻找解决方案,最后ITIL就诞生了。

 闲话少说,我还是借用上面的例子,对于ITIL指导ITSM来说说自己的看法。

 一间稍具规模的公司,每层楼有四台打印机。(对这些IT设备的基本信息进行管理,就是配置管理Configuration Management的范畴)

 员工甲发现一楼的打印机(编号为A)不能正常使用,于是(打电话/Email/Self-Service)联系IT服务部门报修。一线部门的人员一般只能解决常见的简单问题,对于无法解决的问题需要联系二线人员。同时,需要通过Email或是其他方式告知一楼的员工:“打印机A有故障”;还可能要联系采购部门,新添加一台打印机,以免影响日常工作。(这属于一个事故的处理流程,称作事故管理Incident Management)

 在新添加一台打印机的同时,又涉及到另一条流程,对这样新增一项设备的需求进行审批。(这正是需求管理,Require Management)

 ok,在解决了打印机A故障的不久之后,打印机B、C、D陆续都发生了故障,于是这个小故障就不单单是个故障了,它已经是一个大问题了。因此,前文中提到的Incident Management事故管理,显然到了Problem Management的级别。这个时候,可能就需要所谓的专家团队去研究这个问题的根源。在找到这个Problem的症结之后,也需要进行整理总结,建立“知识库”,进行知识管理。这样,以后出现类似的问题,就能有效地解决了……

 这个例子讲述了一些涉及到ITSM的活动。就拿事故管理Incident Management来说,ITIL提出“影响度”“紧急度”“优先级”这些概念定义incident,并提出SLA、OLA作为考量IT服务的指标。但真正困扰我们的东西,比如配置管理中如何把握配置项的粒度(仅把一台设备作为配置项显然是没有意义的~)、如何构建配置项间的关系,ITIL都没有提及。

 所以说,ITIL只是把各个部门间的协作和流程间传递和处理input、output信息的活动,定义成一些XX管理的概念而已。但如果真正要做ITSM的项目,ITIL却不可不知。毕竟,站在巨人的肩膀上,视野会更远、思维广度会更宽。当然,站得太高就得谨慎些,摔下来会很痛。

378°/3784 人阅读/0 条评论 发表评论

登录 后发表评论