本帖最后由 monicazhang 于 2015-10-22 11:40 编辑
20151022 淡然
续上
4.5 流程执行原则4.5.1 常规原则 n 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件 ITSS考试
n 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
n 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
n 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程
4.5.2 所有权原则 所有权原则用来确保每个事件在任何时段都有适当的人员负责，帮助台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。
[td][td]
| | | | |
检测和记录(detection and recording)
| | | |
|
分类和支持(classification & initial support)
| | | |
|
分析和诊断(investigation and diagnosis)
| |
| | |
解决和恢复(resolution and recovery)
| | | | |
事件关闭(Incident closure)
| | | |
|
监控和沟通(ownership, monitoring, tracking & communication)
| | | | |
RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会
|
4.5.3 再分派原则 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组，由组内的支持人员处理。事件单的重分派次数不应该超过5次。
n 帮助台可以将事件单分配给一、二线支持
n 一、二线支持可以将事件单重新分配给帮助台、其他一、二线支持人员和厂商人员 ITSS认证
n 现场厂商人员直接使用系统记录处理情况，没有条件使用系统的厂商，由一、二线支持代为记录
4.5.4 重复事件原则 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。
n 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
n 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
n 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一、二线支持人员负责重复事件的处理
4.5.5 关闭原则 由IT用户申报的事件单，关闭必须由帮助台完成。
n 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。帮助台负责和IT用户再次确认事件的解决
Ø 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
Ø 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理
n 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单
n 一、二线人员自行创建的事件单，本着“谁开单，谁负责关闭”的原则
n 监控平台自动发送的事件单，第一次接收的维护人员负责关闭
4.5.6 升级原则 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
n 优先级为紧急的事件，帮助台应立即派发到一、二线支持，由其再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层，由事件经理启动紧急事件处理流程
n 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，帮助台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理 ITSS培训
n 帮助台应及时将不能解决的事件升级，若未及时升级，事件经理应及时介入，负责协调升级处理
转播
分享
淘帖
()