每天例行的机房巡检都按ITIL事件流程处理了，大家觉得这个合适吗？

2013-12-23 16:08

学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放

下面对话，来自ITIL先锋论坛QQ群：天津-longerwood(57547249) 15:17:45 每天例行的机房巡检都按事件流程处理了，大家觉得这个合适吗？ Will Yeung(240122308) 15:18:53 是巡检按事件流程处理的意思是说，每次巡检的内容和结果用事件工单记录？江苏-陈多思(463651731) 15:19:00 不太合适天津-longerwood(57547249) 15:19:08 大概是这个意思吧 Will Yeung(240122308) 15:19:23 那样的话不太好吧天津-longerwood(57547249) 15:19:36 我直觉不太合适，可也没找到什么特别好的理由驳斥，所以想听听大家的想法 Will Yeung(240122308) 15:20:53 我想到的一个弊端是，这些记录可能都会以附件的形式存在ITSM里面 Will Yeung(240122308) 15:21:00 做性能容量分析的时候 Will Yeung(240122308) 15:21:07 就需要一个一个工单打开 Will Yeung(240122308) 15:21:17 将里面东西复制出来 Will Yeung(240122308) 15:21:26 很麻烦也很容易疏漏上海-Leon(280839258) 15:21:41 这个东东应该不用放流程里流转的吧上海-Leon(280839258) 15:22:02 我们都是放日常运维里，做记录，但不走流程天津-longerwood(57547249) 15:22:02 嗯，目前的机房巡检只是查看设备指示灯的工作状态天津-longerwood(57547249) 15:23:20 相当于每天到点儿服务台起一个事件单，派给相应人员，这个人就去巡检，回来将巡检结果记录在事件单中，目前看所有巡检结果都是无异常，然后正常关闭事件单。 Will Yeung(240122308) 15:24:32 我觉得这种情况，他们还不如在系统里面加一个工单类叫巡检单江苏-陈多思(463651731) 15:25:25 这是典型的没有区分事件与服务 Will Yeung(240122308) 15:25:30 避免在做事件单统计分析的时候，被这种无意义的数据混进来天津-longerwood(57547249) 15:25:38 给位觉得单纯从ITIL理论上讲，有无违和感？天津-longerwood(57547249) 15:26:05 多思多说说江苏-陈多思(463651731) 15:26:45 这个说来话长，先要从服务级别管理说起北京-文祺(2973305) 15:26:52 多思不能多说江苏-陈多思(463651731) 15:27:10 我们知道每项服务都应该有服务级别指标，也就是SLA 江苏-陈多思(463651731) 15:27:36 那么事件是否也有多长时间响应，多长时间解决的指标要求呢江苏-陈多思(463651731) 15:27:40 答案是肯定的江苏-陈多思(463651731) 15:27:53 那么事件的指标和服务的指标有什么关联呢江苏-陈多思(463651731) 15:28:41 现在可以确定的一件事是违反SLA的服务，是一个事件江苏-陈多思(463651731) 15:28:59 而在SLA之前的服务是否是一个事件江苏-陈多思(463651731) 15:29:30 比如终端维护服务，服务台接到一个保修，是算服务请求还是算事件江苏-陈多思(463651731) 15:29:34 报修天津-longerwood(57547249) 15:31:12 严格按照定义，应该算服务请求，但在实践中，运维体系建设初期，为能够快速铺开，类似的报修走事件流程处理了，但在事件性质一项中选择了“请求” 江苏-陈多思(463651731) 15:31:42 我们再回到机房巡检中去，首先确认一点这是一项服务，只有当这项服务不能正常进行，或者未达到服务指标，才是一个事件。那么工单是什么，工单既是服务过程的记录，也是事件处理的记录。这样就好理解了江苏-陈多思(463651731) 15:32:41 换句话说，统计运维部门工作量，包含了对正常服务工作量统计和对事件问题处理的统计江苏-陈多思(463651731) 15:33:05 当然还有管理工作量的统计，这里就不展开了。深圳-艾科(2412628190) 16:02:49 多思专家，牛！深圳-艾科(2412628190) 16:03:30 巡检工作是服务，不应算作事件，因为事件是服务的中断或质量下降，也就是偏离了SLA。