×

扫描二维码登录本站

标签: 暂无标签
本帖最后由 monicazhang 于 2015-11-6 11:19 编辑

20151106 淡然
续上





4.2   事件管理流程
4.2.1                现状描述
在事件管理流程中所提及的事件,是指各业务系统进行的所有与IT基础架构和应用相关的服务请求和故障,事件管理流程的目的是为了使中断的服务尽快恢复到正常工作状态。
通过前期调研,目前某公司各业务系统对于1级故障,即事故的处理均按照优先保障业务稳定的方式处理,这是符合监管要求和业务需求现状的,但同时造成事后补单的情况也非常普遍。其中,以“集中交易系统”为例,针对事件管理流程的现状如下:                        ITSS考试
4‑2 集中交易系统事件管理流程现状
[td]
编号

内容

现状

1

流程认知

·           目前,集中交易系统在执行事件管理流程时,多采用“先处理,后补单”的形式,ITSM系统中的事件工单仅作为故障备忘与合规检查时使用;
·           由于集中交易系统的故障类工单均在管理员处集中处理,服务台仅承担个别服务请求的转派工作,因此不存在一/二线的技术升级活动。

2

流程操作

·           在“创建故障并分类分级”活动中:
1.   不判断重复事件;
2.   判断“故障紧急度”时无固定标准,会根据目前忙闲程度主观确定;
3.   部分工单“故障优先级”的算法与流程文档不符,如:ID-IN-20121127-00012;
4.   创建事件时,填写“事件主题”无明确规范。
·           在“处理事件”活动中:
1.   对经过验证可批处理的操作,建立“维护菜单”,可视为动态知识库;
2.   供应商资源的服务质量无法通过合同形式制约,造成业务影响的责任无法完全承担;
3.   事后补单在明确故障原因情况下,仍有因不便填写,或人为失误造成的“原因不详”工单,如:ID-IN-20130402-00021。

3

流程平台

·           ITSM系统中,各优先级事件的处理时限到无告警;
·           外部工具接入受VPN、网速的限制,潜在影响事件分析解决速度;
·           ITSM记录IT提交的服务请求,而取数据、调资金等业务问题由业务部门通过BPM提交,记录内容不关联。

在具体的事件处理过程中,我们也统计了距今6个月内共10条工单的处理情况,我们将工单划分为:故障通知、故障定位和故障解决三个阶段,在故障通知阶段:

4‑3 集中交易系统故障处理统计
[td]
编号

流水号

主题

发现时长

工具支持

1

ID-IN-20140103-00019

深圳报价回购报盘异常

0


2

ID-IN-20140107-00025

深圳报价回购自动扫单操作因程序bug,比例配售失败,影响485位客户

N/A


3

ID-IN-20140116-00038

【告警】恒生集中交易172.22.101.36(消息插件使用状况阈值)

0


4

ID-IN-20140127-00041

集中交易中间件udp代码和行情组件中代码未刷新问题                                

0


5

ID-IN-20140218-00032

客户账户异常

N/A


6

ID-IN-20140219-00031

2014年2月19日集中交易系统故障

20


7

ID-IN-20140303-00045

集中交易影像服务器备机172.22.98.55不可用故障

0


8

ID-IN-20140116-00037

【告警】恒生集中交易172.22.101.36(海通网关日志有错误)                               ITSS认证

0


9

ID-IN-20140218-00002

【告警】恒生集中交易172.22.101.36(海通网关日志有错误)

0


10

ID-IN-20140224-00035

【告警】恒生集中交易172.22.101.36(海通网关日志有错误)

0


可见,在监控系统的支持下,绝大多数故障都可以在第一时间通知到业务系统管理员进行故障处理,其通知时间几乎可忽略不计。接下来的故障定位和解决阶段:

4‑3 集中交易系统故障处理统计(续)
[td]
编号

流水号

定位时长

文档指导

工具支持

外包支持

1

ID-IN-20140103-00019

N/A




2

ID-IN-20140107-00025

30




3

ID-IN-20140116-00038

N/A




4

ID-IN-20140127-00041

5




5

ID-IN-20140218-00032

2




6

ID-IN-20140219-00031

40




7

ID-IN-20140303-00045

N/A




8

ID-IN-20140116-00037

30




9

ID-IN-20140218-00002

30




10

ID-IN-20140224-00035

30






4‑5 集中交易系统故障处理统计(续)                                       ITSS培训[td]
编号

流水号

解决时长

文档指导

工具支持

外包支持

1

ID-IN-20140103-00019

3




2

ID-IN-20140107-00025

NA




3

ID-IN-20140116-00038

30




4

ID-IN-20140127-00041

2




5

ID-IN-20140218-00032

NA




6

ID-IN-20140219-00031

80




7

ID-IN-20140303-00045

NA




8

ID-IN-20140116-00037

无需解决




9

ID-IN-20140218-00002

5




10

ID-IN-20140224-00035

5




在故障定位和解决阶段,我们可以看出无论从操作规范上,或是工具或外包支持上,都缺乏必要的支撑,这是由于绝大部分故障都是首次发生,事前无法准备对应的操作手册,其应急预案在辅助定位和解决的过程中,也存在更新不及时,超出既有范围等情况。同时,由于业务系统的开发代码归供应商所有,即使业务系统管理员定位了故障大致范围,也无法深入到代码级别排障,导致部分故障必须由供应商解决,延长了处理时间。








上一篇:如何量化评估ITSS运维成熟度
下一篇:从哪些ITSS角度来对整年度的事件进行统计分析
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by ITIL  © 2001-2025
返回顶部