每天例行的机房巡检都按ITIL事件流程处理了，大家觉得这个合适吗？
学习资料：IT运维管理社区专家讲堂直播300期视频回放
下面对话，来自IT运维管理社区QQ群：
天津-longerwood(57547249)15:17:45
每天例行的机房巡检都按事件流程处理了，大家觉得这个合适吗？
WillYeung(240122308)15:18:53
是巡检按事件流程处理的意思是说，每次巡检的内容和结果用事件工单记录？
江苏-陈多思(463651731)15:19:00
不太合适
天津-longerwood(57547249)15:19:08
大概是这个意思吧
WillYeung(240122308)15:19:23
那样的话不太好吧
天津-longerwood(57547249)15:19:36
我直觉不太合适，可也没找到什么特别好的理由驳斥，所以想听听大家的想法
WillYeung(240122308)15:20:53
我想到的一个弊端是，这些记录可能都会以附件的形式存在ITSM里面
WillYeung(240122308)15:21:00
做性能容量分析的时候
WillYeung(240122308)15:21:07
就需要一个一个工单打开
WillYeung(240122308)15:21:17
将里面东西复制出来
WillYeung(240122308)15:21:26
很麻烦也很容易疏漏
上海-Leon(280839258)15:21:41
这个东东应该不用放流程里流转的吧
上海-Leon(280839258)15:22:02
我们都是放日常运维里，做记录，但不走流程
天津-longerwood(57547249)15:22:02
嗯，目前的机房巡检只是查看设备指示灯的工作状态
天津-longerwood(57547249)15:23:20
相当于每天到点儿服务台起一个事件单，派给相应人员，这个人就去巡检，回来将巡检结果记录在事件单中，目前看所有巡检结果都是无异常，然后正常关闭事件单。
WillYeung(240122308)15:24:32
我觉得这种情况，他们还不如在系统里面加一个工单类叫巡检单
江苏-陈多思(463651731)15:25:25
这是典型的没有区分事件与服务
WillYeung(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。
:lol 讨论很精彩呀。。。这些内容分享很有价值。。谢谢楼主整理。。
页:
[1]