ITIL 学而思 (二) [ZT FROM 51CTO]
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
在讨论ITIL（信息技术基础设施库）之前，让我们先来听一段小故事。
在一个周五的傍晚，一家ISP技术支持中心的接线员不断地接到来自不同客户的质询：有些客户收不到电子邮件；有些客户却收到一些发给其他人的邮件；还有的客户无法发送任何邮件。总之，一切都乱套了，愤怒的客户开始抱怨！显然，ISP的系统出了问题。
问题究竟出在哪里？是系统遭到电脑黑客的破坏吗？公司的安全部门开始仔细地调查。结果发现，问题是由另一个业务部门当天安装的一个Java程序引起的，安装这一程序的原意是让客户能够更容易地通过网络收发电子邮件，但不幸的是，这段Java程序存在错误，而且这段Java程序的开发人员并没有把这一变化及时地通知IT部门的最高主管。在被问及此事时，他称这是一次“心血来潮”的做法。
更糟糕的是，没有人将这一变化通知技术支持中心，从而使接线员可以告诉客户，或者在企业网站上发布详细的业务中断信息。虽然这种情况不明的业务中断只持续了几个小时，但却在客户中产生了非常不良的影响。
对那些在夜晚负责管理IT系统的管理员来说，以上情况是每天都可能遇到的紧急情况。不过，如果公司有一套经过测试和验证的常识准则，并要求每一个环节的员工都遵守这一准则，这种情况是完全可以避免的。这就是信息技术基础设施库（ITIL）要解决的问题。
摘自 ]viewtopic.php?t=11451
看完上面的故事可以想想。有多少技术人员就是因为相似的原因在加班、在挨老板骂、在挨顾客骂、在心里窝火。原来我们可能认为这是某某部门没有责任心、某某人GP不懂。可是如果频繁出现这类问题。或是你的大部分时间都在解决此类问题。那你就要思考这种表象下深层次的东西了。
感觉这个ISP 像是 ICP 。 ISP 网络服务提供商。 ICP 网络内容提供商。e-mail 多是应用吧。呵呵。无所谓了。
以目前对ITIL的了解来看看上面的故事。
1 技术人员对应用进行变更。居然没有变更管理、配置管理、发布管理。真是自由的很啊。
他到是自由了。可是对同事的影响、对公司的影响却全然不觉。 这个人很寸。脑子里很缺氧。但是深层次的是制度的缺失、管理的缺失、培训的缺失。 “不知者不为过”可是不知者为什么不知。不知又该是谁之过呢？
2 部门之间没有沟通。各各部门各自为政。信息无法共享。出现问题后无法快速进行故障定位。 配置管理没有做好。
工作中经常郁闷。 例如: 工程部做完项目，资料不全，移交不完整。 维护部就得多花N倍的经历重新摸一遍。 一个工程可能要近半年的时间对业务单位进行逐一切割。 这个变更过程中。用户报来故障。是切割引起的？ 还是没有切割在老的链路上出现的？ 还是切割后引起的？ 处理问题和分析问题的方式是大部一样的。 而用户可能并非专业人士。不了解情况。问深了可能引起用户不满。只能转过头去问工程部。如果工程部没有统一接口人。那你就得逮着电话一个个问。那么故障处理的时间就可想而知了。这里耽误的时间完全是可以避免的。因此产生的用户投诉也是完全可以避免的。
就算是同一个部门之间。也可能会出现一个同事离职。他做过的所有事情都无法接收。这对公司的损失和影响是显而易见的。 怎样在制度和流程上防治这种问题的出现是一个课题。
----------------------------------------------------------------------------------------------------------------------
《IT服务管理 基于ITIL的全球最佳实践》 39 页
一个服务请求可能是要求进行一个标准变更，但是只要他属于“标准服务”的范畴，那么就应当由事件管理而不是变更请求流程进行处理。
也就是说在SLA 中定义有 进行变更类的标准服务。那这类变更就属于标准服务。而不是变更请求。
服务请求-- 用户想要获得支持、递送、信息、建议或文档的请求，它并不属于IT基础设施方面的故障。
事件是一种故障。服务请求则不是。但服务请求和故障在服务台处理的流程确实相似的。
所以也把服务请求当做一种事件来处理。只是这种事件是非突然的。是不影响SLA的。是在服务交付前就协商好的。
如果被请求的服务不是事先已经定义好的“标准服务”，并且它将改变IT 基础设施的状态，那我们将根据此提交一个变更请求（Request For Change， RFC）。
变更请求------变更管理流程的正式组成部分，用于记录在一个基础设施内对任何配置项或服务、程序以及与基础设施相关的项目进行变更的需求的详细情况
变更请求（RFC）并不由事件管理流程处理，而是由变更管理流程负责对其进行正式的处理。
2 影响度、紧急度和优先级
当同时处理若干事件时，必须设定优先级。优先级是根据错误对用户和正常业务带来的影响的严重程度来确定的。服务台通过与用户进行协商，并根据服务级别协议SLA 确定事件的优先级。优先级决定了时间得到处理的先后顺序。当事件被提升至二线（第二层）、三线（第三层）或者更高级别的支持小组时，其优先级的维护及协调仍是在与服务台进行协商后确定的。
俗话说的好 事有轻重缓急。处理故障也是同样的道理。那什么是严重的故障，而什么是其次的呢。 这就要按签订的SLA 来决定了。比如SLA 说故障在发生2小时内必须解决。那这个故障就比SLA要求在24小时解决的优先级要高一些。 但又如果只是一个人的PC出了故障。但这个人是个大BOSS。 SLA 上要求保证其 7X24小时无故障。那我们只能认为SLA 在签订上可能有不合理。因为BOSS 不可能7X24小时用。这么高的服务等级似乎不必要。但还是要按SLA走。业务是王。以业务为主导。反正有人付钱就行。呵呵。个人理解。
当然，每个用户都会认为自己的事件应该有更高的优先级，但是用户的要求通常比较主观。为做出一个客观的评价，可与用户按照以下准则进行协商：
影响度（impact）-- 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度。重要事件是指对用户团体带来非常严重影响的事件。而有些在时间上极度紧迫的需要解决的事件。而有些在时间上极度紧迫的需要解决的事件也应当作重要事件来处理。
紧急度（urgency)----紧急度指解决故障时，对用户业务来说可以接受的耽搁时间。
优先级（priority）---主要基于紧急度和影响度来决定。而对于具有同样优先级的事件，可以按解决他们需要花费的精力的多少来安排顺序。例如：对某个影响不大且容易解决的故障，可先于一个影响较大且需要大量精力解决的故障。
影响度 。 如果一个公司都无法上网和一个人无法上网。那前者影响度自然比后者大。
如果一个公司对外的web站点无法访问。和内网ftp无法访问。那前者的影响度自然比后者大。
如果一个财务今天最后一天报数据给财政局。而另一个人今天只是想上上互联网。那前者的影响度自然比后者大。
如果一个业务单位无法访问internet。而另一个业务单位只是出现了延时大的现象。那前者的影响度自然比后者大。
如果一个用户嚷着要投诉。而另一个用户并不急着用。那前者的影响度自然比后者大。
以上这些需要对公司的业务种类。业务单位。业务性质。可能会产生的后果有全面的深刻的认识。
紧急度 是在影响度相同或相似的情况下。对耽搁时间进行比较。耽搁时间要求少的事件优先处理。
在优先级的设定上。在SLA签订阶段就可以跟业务单位进行沟通。对其业务进行合理的优先级设置。 如果一个普通的业务周六日和下班后根本就不使用而且却要7X24的4个9保障。可以告知情况。协调是否在工作时间内保证4个9。
事件管理具有降低影响度和紧急度的手段和措施，例如交换硬件或指派另一个打印队列。事件的影响度和紧急度在此事件的生命周期中也有可能发生改变，例如当事件影响了更多的用户或事件发生在危机时刻。
以上的图表只是一个草稿。具体要根据公司的业务来决定优先级。明确可行的优先级是行动的重要依据。
上面是一个比较通用的事件管理流。 分成1 2 3 。。。 N 线。逐层完成相关工作。
本文出自 “一颗平和的心” 博客，请务必保留此出处57448/70864
好好学习 不错 谢谢分享，学习中
页:
[1]