Wiki源代码32 某银行ITIL问题管理规范
由 superadmin 于 2024/10/15, 16:45 最后修改
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | = **第一章 总 则** = | ||
2 | |||
3 | |||
4 | 第一条 为保证XX银行数据中心信息系统运行维护中的问题得到有效管理,根据《银行业信息科技监管政策汇编》、《金融行业信息系统信息安全等级保护实施指引》等有关规定,特制定问题管理规范,以实施问题根源分析和解决,预防故障发生,避免问题重复出现。 | ||
5 | |||
6 | |||
7 | 第二条 问题管理规范应遵循以下工作原则: | ||
8 | |||
9 | (一)全面管理原则:问题管理范围包括与IT生产系统相关的各种问题,包括事件单和问题单,以及围绕问题解决所发生的发现与记录、审核与分派、升级与递转、诊断与解决、关闭与总结的整个过程; | ||
10 | |||
11 | (二)组织保障原则:应为呼叫中心提供技术支持,并配备专门人员受理用户问题,规范化工单流转,界定维护范围,强化责任管理; | ||
12 | |||
13 | (三)平台保障原则:应建立统一的运维支撑平台,并保证“7X24”正常运行,以保证紧急问题能够得到及时处理; | ||
14 | |||
15 | (四)严重等级原则:严重等级表明了该问题对服务所产生的业务影响,它是评定问题处理优先等级的一个重要指标;应本着先急后缓、先外后内、先联机后批量的原则,面向客户、面向服务的问题应重点保证,优先排除; | ||
16 | |||
17 | (五)有效沟通原则:应预先定义的问题单内容和分发清单,并基于严重等级将有关信息及时通知关键的人员和用户,重大问题及相关信息要及时上报,并保证信息的真实性和完整性; | ||
18 | |||
19 | (六)全面记录原则:所有受理的问题均要登记,不得遗漏任何信息; | ||
20 | |||
21 | (七)定期分析原则:应每月组织定期回顾,并产生问题管理报表,对所处理事件历史记录进行趋势分析; | ||
22 | |||
23 | (八)持续完善原则:应每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾,以改进和优化流程。 | ||
24 | |||
25 | |||
26 | 第三条 问题管理规范适用于本数据中心所有信息系统生产环境以及与生产系统相关的网络、设备、机房等基础设施。 | ||
27 | |||
28 | |||
29 | 第四条 问题管理规范的不应独立设计,与事件管理、变更管理、配置管理等规范综合考虑,以确保全面性。 | ||
30 | |||
31 | |||
32 | 第五条 以下术语适用于本规范: | ||
33 | |||
34 | (一)问题,是指一个或多个事件(incident)的原因,在创建问题记录时,通常不知道原因,由问题管理流程负责进一步的研究。 | ||
35 | |||
36 | (二)已知错误,已经记录了根本原因和规避措施的问题,已知错误由问题管理在其整个生命周期中创建和管理,也可以在开发过程中或由服务商确定。 | ||
37 | |||
38 | (三)已知错误数据库,包含所有已知错误记录的数据库,该数据库由问题管理创建,并可被其它运维流程使用。 | ||
39 | |||
40 | (四)问题任务,是指在进行复杂问题处理时,由问题分析人员创建的需要其他人员辅助处理的任务。 | ||
41 | |||
42 | (五)问题单,在系统中存在并在问题管理流程中运行,以数据形式存在的工单。 | ||
43 | |||
44 | (六)变通方法,有时也称临时规避措施或应对措施,相对“根本解决方法”而言,变通方法是指没有根本解决一个问题引起的故障,但恢复了问题影响的服务(或业务)的方法。 | ||
45 | |||
46 | (七)服务台,此功能作为业务部门和信息化部门的唯一接口,通过集中受理方式提供服务支持,通过使用变通方法、解决方案或升级到专业支持团队等手段,帮助业务部门恢复到正常工作状态。 | ||
47 | |||
48 | = = | ||
49 | |||
50 | = **第二章 组织与职责** = | ||
51 | |||
52 | |||
53 | 第六条 问题协调人,针对不同层面系统的问题,由相应的管理维护部门事先指定专人接受问题分派,初步判断问题优先级,准确填写问题处理单,并在问题处理过程中协助问题处理专家。 | ||
54 | |||
55 | |||
56 | 第七条 问题管理负责人,负责问题管理流程的评估、实施和持续优化机制;监控流程的执行情况,确保流程被正确、有效地执行;当流程不能适应生产运行的实际情况时,及时进行分析、找出缺陷、进行改进,从而实现流程的不断完善。 | ||
57 | |||
58 | |||
59 | 第八条 问题经理,负责协调日常的问题管理工作,包括对问题的审核、监控、协调资源、定期产生报表等,其主要职责包括:定期组织相关人员对事件记录进行分析,发现潜在问题;确认和审核问题,必要时对问题进行上报;监控问题的诊断、分析和处理过程,必要时与服务台或问题提出者沟通问题的相关信息;协调处理问题所需的资源;定期制定问题报表,提供正确的决策信息等。 | ||
60 | |||
61 | |||
62 | 第九条 问题处理专家,负责为问题的诊断及解决提供技术支持,其主要职责为:接受问题经理分派的问题;分析和诊断问题,找出根本原因;制定和测试解决方案;必要时提交变更申请并监控变更的实施;必要时协调所需资源来帮助诊断和解决问题等。 | ||
63 | |||
64 | |||
65 | 第十条 外包服务商,根据服务合同要求,参与问题诊断和分析,为问题解决提供技术支持,针对自身产品承担最终责任。 | ||
66 | |||
67 | = = | ||
68 | |||
69 | = **第三章 识别与记录** = | ||
70 | |||
71 | |||
72 | 第十一条 问题识别,重复发生的或非常严重的事件应归类为问题,技术人员在事件处理或趋势分析过程中,根据识别规则发现问题并提交问题申请。 | ||
73 | |||
74 | |||
75 | 第十二条 问题记录,应侧重于记录事件症状,以及与事件相关的系统运行情况等信息,问题记录时应指定问题解决小组,并要求在规定时间内进行处理和反馈。 | ||
76 | |||
77 | |||
78 | 第十三条 问题分类,业务部门报告的问题按照重要性、紧迫性等因素,可以分为一般问题、紧急问题、特急问题三类;对同类问题按照处理难易、影响程度等因素,还可以划分出高、中、低三类处理优先级。 | ||
79 | |||
80 | = = | ||
81 | |||
82 | = **第四章 分析与诊断** = | ||
83 | |||
84 | |||
85 | 第十四条 问题分析,问题协调人应首先初步探求问题原因,如果该问题需要其它专业组配合,则应发起协调通知单或召开问题协调会。 | ||
86 | |||
87 | |||
88 | 第十五条 问题审核,利益相关者应参与到讨论会中共同审核问题,以求在解决问题的优先级上达成一致;经过评审后,应基于评审结果制定后续工作计划、分配相应资源。 | ||
89 | |||
90 | |||
91 | 第十六条 问题诊断,各专业组处理专家针对已分配问题进行调查和诊断,应首先判断是否具备有效的永久解决方案或变通方法,新问题须进一步确定根本原因和应对措施,并将应对措施记录到已知错误数据库中。 | ||
92 | |||
93 | = = | ||
94 | |||
95 | = **第五章 审批与实施** = | ||
96 | |||
97 | |||
98 | 第十七条 解决方案审批,解决方案应经过充分的验证和测试,相关测试结果应上报问题经理审批,实施前应正式提交变更请求,以便变更管理全程监视的实施情况。 | ||
99 | |||
100 | |||
101 | 第十八条 解决方案实施,根据已批准的工作计划,问题处理专家组织并安排相关人员实施解决方案,实施过程中应进行明细记录,因紧急处理而省略的内容应事后补录,必要时应将明细记录和状态报告一起提交问题经理审阅。 | ||
102 | |||
103 | = = | ||
104 | |||
105 | = **第六章 关闭与总结** = | ||
106 | |||
107 | |||
108 | 第十九条 问题单关闭,根据问题的性质,可能需要在指定的时间段内将问题保持打开状态,以验证问题是否被真正解决;关闭问题单事,应检查并确保问题记录信息的完整性。 | ||
109 | |||
110 | |||
111 | 第二十条 问题总结与报告,应定期对问题受理、处理情况及解决方案进行总结分析,记录整体问题管理过程中所获取的经验;问题处理的结果形成知识库,要对一线进行培训,实现知识传递。应定期将问题受理、上报及解决情况形成统计报告,相关报告和审核记录由问题管理部门统一管理,并应保存至少三年。 | ||
112 | |||
113 | = = |