×

扫描二维码登录本站

QQ登录

只需一步,快速开始

监控是否适合做服务台工作?  

标签: 服务台监控
本帖最后由 nilewole2008 于 2013-8-29 09:37 编辑

来,大家一起来讨论些具体案例,增加对概念的理解。

       某单位提供公众服务。内部IT部门为内部的所有IT业务提供设计、开发、运维等、数据分析处理、项目管理等各项工作。
其中有个专门的支持部门,负责受理技术团队内外(含非公司员工外部用户)的报障;
在运维团队,也有安排一名监控人员,负责受理报障。运维监控负责查看所有系统流量图以及各类监控系统的告警信息;
按规定,有故障了,如果可明确是运维方面的问题,可以直接找监控报障。如果不确定只知道服务受影响了,可向支持部门报障。监控负责记录运维故障信息。
在实际过程中,大家发现,用户方(都是同事)都往往会直接找到具体的工程师来报障。而忽略监控。而监控也觉得自己忙于看流量图和系统告警信息,难以跟进及记录详细的故障信息。

监控目前是7*16 二班的形式。一共编制3个人。

综合考虑全局情况,讨论几点:
一、在人员编制不增加的必要前提下
1)监控是否适合继续承担服务台故障记录、受理故障之责;
2)服务台该如何设计、人员如何分工更适合??(可综合考虑支持部门、运维部门,可以考虑部门人员调动)

二、在人员编制可增加的情况下
服务台的设计应该如何规划?对于用户来说需要最高效的方式。找运维监控或工程师最快捷。找支持部门的人员,就慢了很多。特别故障都是要尽快解决的

谢谢大家的回帖支持,讨论的话题做了内容进一步的完善。


微信扫一扫,阅读更方便^_^





上一篇:北京8月份ITIL Foundation团购班完满结束!
下一篇:开发团队也负责上线后运维,这个开发团队也算在做运维工作吗?
nilewole2008

写了 190 篇文章,拥有财富 21136,被 12 人关注

B Color Link Quote Code Smilies
cloudliu 发表于 2013-8-29 09:12:05
这个题目挺实际,不错,看看大家的高见。
挨踢达人 发表于 2013-8-29 09:33:50
监控一班只有一个人,确实少挺多,可能报警策略有调整,就会有大量报警过去,对监控人员要求挺高,技术手段可以做一些沟通工具提醒的功能做优化。单从这方面看,人手的问题,监控是不适合做服务台故障记录和受理的。除非添加人员。
另外一方面若建立服务台,服务台的人数需根据具体业务规模来定。并保证同事保障有人接听记录,然后分派。但这么看,有可能会有监控上报故障,然后给到服务台,服务台又将任务给到监控处理(比如重启机器等简单的操作)。
增加人员,可将服务台合并到监控当中。
风铃 发表于 2013-8-29 13:17:34
一、在人员编制不增加的必要前提下
1)监控是否适合继续承担服务台故障记录、受理故障之责;
2)服务台该如何设计、人员如何分工更适合??(可综合考虑支持部门、运维部门,可以考虑部门人员调动)

由于贵公司已有支持部门接收内外用户的报障,并可保证故障详细记录,而且监控团队压力较大,建议尽量引导用户通过支持部门报障,当然需要很长的过渡期。
如果在人员编制不增加,并且各部门工作量比较饱和的情况下,可考虑将支持部门作为服务台,培训支持部门报障接收人以及准备流程和指引手册,可将故障直接指派到处理人,从而减轻监控团队压力。
另外可深入调查监控工作是否存在优化空间,可通过自动化程序或工具代替日常监控人工工作,降低监控人工工作量。
针对紧急故障,必须建立紧急故障评判标准(不是所有用户反馈的紧急故障都一定是紧急故障),并且提供相应绿色通道,避免因工作排期而延迟。


二、在人员编制可增加的情况下
服务台的设计应该如何规划?对于用户来说需要最高效的方式。
找运维监控或工程师最快捷。找支持部门的人员,就慢了很多。
特别故障都是要尽快解决的


其实直接找到运维监控以及具体工程师,只是用户感知比较快,实际不一定快。
直接联系工程师,中间缺乏服务台的监控与跟进,紧急的事情很容易被人为地延迟。
人员编制可增加,建议搭建独立的内部IT服务台,并考虑与监控团队融合,内部IT服务台在闲时可协助监控团队处理日常工作。
善良的小桂 发表于 2013-8-29 15:04:51
确实是一个实际的问题,其实从某种角度上来说,监控本身也是一种意义上服务台。理解这点的话,可能就只要从工作量的角度去协调就ok了
手机版|小黑屋|最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部