由 superadmin 于 2024/06/20, 11:30 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] [[ 阅读下一篇>>https://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/26%20%E6%9F%90%E9%93%B6%E8%A1%8C%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83ITIL%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E4%BD%93%E7%B3%BB%E2%80%94%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] | ||
| 2 | |||
| 3 | |||
| 4 | = **某银行数据中心ITIL信息技术服务管理体系—突发事件管理规范** = | ||
| 5 | |||
| 6 | |||
| 7 | === **第一章 总 则** === | ||
| 8 | |||
| 9 | |||
| 10 | 第一条 为保证XX银行数据中心信息化服务的交付质量,根据《银行业信息科技监管政策汇编》、《金融行业信息系统信息安全等级保护实施指引》等有关规定,特制定突发事件管理规范,以确保数据中心及时响应并处理各类IT服务事件,在最短的时间内恢复与服务对象约定的IT服务,减少事件造成的影响和损失。 | ||
| 11 | |||
| 12 | 第二条 突发事件管理应遵循以下工作原则: | ||
| 13 | |||
| 14 | (一)遵从原则:突发事件管理应该遵从相关国家标准和行业监管规定; | ||
| 15 | |||
| 16 | (二)明确职责:突发事件管理应该明确中心内各成员的在突发事件管理中的工作职责,以计划,落实和不断改善突发事件管理活动; | ||
| 17 | |||
| 18 | (三)处置高效:应加强突发事件处置队伍建设,提供充分的资源保障,确保突发事件发生时反应快速、报告及时、措施得力、操作准确,降低突发事件可能造成的损失。 | ||
| 19 | |||
| 20 | 第三条 突发事件的处理可能激发应急管理、紧急变更;突发事件管理为问题管理提供数据和信息。 | ||
| 21 | |||
| 22 | 第四条 以下术语适用于本规范: | ||
| 23 | |||
| 24 | (一)突发事件(Incident),是导致(或可能导致)数据中心服务中断或质量下降的任何事件。 | ||
| 25 | |||
| 26 | (二)临时解决办法(Workaround),是尽快恢复受突发事件影响的服务的方法。临时解决办法不要求找到突发事件根本原因和从根本上解决突发事件。 | ||
| 27 | |||
| 28 | (三)突发事件管理,是负责处理导致数据中心服务中断或服务质量下降的突发事件的运维流程。它的目的是尽快恢复被中断和受到影响的服务,而不是在于查找根本原因。 | ||
| 29 | |||
| 30 | (四)突发事件升级,是指突发事件处置人员不能按时解决突发事件或根据监管规定需要采取的动作。突发事件升级包括技术升级和管理升级。技术升级指将突发事件重新分配给不同的处理人员或邀请更多的技术专家参与突发事件的解决。管理升级指将突发事件的发生和处理情况及时汇报给相关管理人员。 | ||
| 31 | |||
| 32 | (五)问题(Problem)管理,是负责解决重大突发事件或具有相同特征的一组突发事件的运维流程。它的目的是找出产生这些突发事件的根本原因,并通过永久性解决方案防止类似突发事件的再次发生,同时问题管理流程也通过主动式管理降低突发事件发生的数量。 | ||
| 33 | |||
| 34 | |||
| 35 | === **第二章 组织与职责** === | ||
| 36 | |||
| 37 | |||
| 38 | 第五条 数据中心按照监管要求,建立突发事件管理和应急管理队伍,明确人员职责。 | ||
| 39 | |||
| 40 | 第六条 突发事件管理负责人,从宏观上规划和监控流程,确保突发事件流程在数据中心被正确的执行。当流程不能够适应数据中心的情况时,流程负责人必须及时对此进行分析、找出缺陷、进行改进,从而实现可持续提高。 | ||
| 41 | |||
| 42 | 第七条 突发事件经理,负责突发事件解决过程中的协调和监控,以及突发事件升级的判断以及具体执行。 | ||
| 43 | |||
| 44 | 第八条 一线支持人员,负责接收所有的突发事件,对突发事件进行分类,并根据实际情况尝试对突发事件进行处理,或将突发事件分派到合适的二线支持人员。 | ||
| 45 | |||
| 46 | 第九条 二线支持人员,是相关领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研,找出解决方案并尽快恢复服务。 | ||
| 47 | |||
| 48 | 第十条 三线支持人员,泛指与数据中心签订了服务合同的厂商支持人员或数据中心外部可以寻求支持的支持人员。二线根据服务支持协议向三线支持人员寻求支持。 | ||
| 49 | |||
| 50 | |||
| 51 | === **第三章 突发事件分级** === | ||
| 52 | |||
| 53 | |||
| 54 | 第十一条 突发事件依照其影响范围及持续时间等因素分级。当突发事件同时满足多个级别的定级条件时,按最高级别确定突发事件等级。 | ||
| 55 | |||
| 56 | (一)特别重大突发事件(I级) | ||
| 57 | |||
| 58 | 1、造成重要信息系统服务中断或重要数据损毁、丢失、泄露,造成经济秩序混乱或重大经济损失、影响金融稳定的,或对公众利益造成特别严重损害的突发事件; | ||
| 59 | |||
| 60 | 2、造成重要信息系统服务异常,在业务服务时段导致两个(含)以上省(自治区、直辖市)业务无法正常开展达3 个小时(含)以上,或一个省(自治区、直辖市)业务无法正常开展达6 个小时(含)以上的突发事件; | ||
| 61 | |||
| 62 | 3、业务服务时段以外,出现的故障或事件救治未果,可能产生1 至2 类的突发事件。 | ||
| 63 | |||
| 64 | (二)重大突发事件(II级) | ||
| 65 | |||
| 66 | 1、由于重要信息系统服务中断或重要数据损毁、丢失、泄露,对银行或客户利益造成严重损害的突发事件; | ||
| 67 | |||
| 68 | 2、由于重要信息系统服务异常,在业务服务时段导致两个(含)以上省(自治区、直辖市)业务无法正常开展达半个小时(含)以上,或一个省(自治区、直辖市)业务无法正常开展达3 个小时(含)以上的突发事件; | ||
| 69 | |||
| 70 | 3、业务服务时段以外,出现的重要信息系统故障或事件救治未果,可能产生上述1 至2 类的突发事件。 | ||
| 71 | |||
| 72 | (三)较大突发事件(III级) | ||
| 73 | |||
| 74 | 1、由于重要信息系统服务中断或重要数据损毁、丢失、泄露,对银行或客户利益造成较大损害的突发事件; | ||
| 75 | |||
| 76 | 2、由于重要信息系统服务异常,在业务服务时段导致一个省(自治区、直辖市)业务无法正常开展达半个小时(含)以上的突发事件; | ||
| 77 | |||
| 78 | 3、业务服务时段以外,出现的重要信息系统故障或事件救治未果,可能产生上述1 至2 类的突发事件。 | ||
| 79 | |||
| 80 | (四)一般突发事件(IV级) | ||
| 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 | |||
| 114 | 第二十一条 如果不能在规定的时间内解决问题,要根据规定进行技术升级或管理升级。如果需要支持厂商介入处理,应该及时通知厂商介入处理并监督处理质量和进度。 | ||
| 115 | |||
| 116 | 第二十二条 应该按规定报告任何已知的或可能的突发事件的相关信息和处理进展,按规定与受到影响的用户或部门进行沟通。同时应根据行业监管要求,统一口径,协调相关人员做好突发事件的信息发布工作。 | ||
| 117 | |||
| 118 | 第二十三条 在突发事件处理过程中,应做好处理过程的相关记录。 | ||
| 119 | |||
| 120 | |||
| 121 | === **第七章 突发事件解决** === | ||
| 122 | |||
| 123 | |||
| 124 | 第二十四条 找到解决方案后,决定是否可以马上实施解决方案。如果解决方案的实施需要触发变更管理流程,根据变更管理的要求,提交变更请求,并协助进行解决方案的实施。 | ||
| 125 | |||
| 126 | 第二十五条 实施完解决方案后,需要记录解决方案和实施过程,并将突发事件转回一线,由一线通知相关人员突发事件的解决结果并请求确认。 | ||
| 127 | |||
| 128 | |||
| 129 | === **第八章 突发事件关闭** === | ||
| 130 | |||
| 131 | |||
| 132 | 第二十六条 当相关人员确认突发事件已经解决后,可以关闭突发事件的处理。 | ||
| 133 | |||
| 134 | 第二十七条 关闭突发事件时,应该记录结束突发事件关闭的方式。关闭的方式包括但不限于:完全解决;以临时措施解决;无法重现等。 | ||
| 135 | |||
| 136 | |||
| 137 | === **第九章 突发事件的分析与总结** === | ||
| 138 | |||
| 139 | |||
| 140 | 第二十八条 突发事件处理结束后,应做好事件分析与总结工作。 | ||
| 141 | |||
| 142 | (一)应全面收集、整理相关记录和日志。 | ||
| 143 | |||
| 144 | (二)应及时析总结事件发生现象、事件发生原因、事件影响范围、应急处置过程等。 | ||
| 145 | |||
| 146 | (三)Ⅲ级突发事件应急结束后一个工作日内,当事单位应按照本行业信息安全信息通报制度规定的程序和要求上报突发事件处理总结报告。 | ||
| 147 | |||
| 148 | (四)Ⅱ级(含)以上突发事件应急结束后两个工作日内,当事单位应按照本行业信息安全信息通报制度规定的程序和要求上报突发事件处理总结报告。 | ||
| 149 | |||
| 150 | 第二十九条 突发事件总结报告内容应包括但不限于: | ||
| 151 | |||
| 152 | (一)事件概况,包括发生经过、突发事件影响范围和损失。 | ||
| 153 | |||
| 154 | (二)应急处置过程,包括事件上报过程、采取的措施及效果。 | ||
| 155 | |||
| 156 | (三)事件发生的主要原因分析、结论。 | ||
| 157 | |||
| 158 | |||
| 159 | === **第十章 监督管理** === | ||
| 160 | |||
| 161 | |||
| 162 | 第三十条 应该根据中心的服务水平管理的要求,结合行业监管要求,确定各级别突发事件的解决时间目标和系统恢复指标,主要包括: | ||
| 163 | |||
| 164 | (一)恢复时间目标(RTO):业务功能恢复正常的时间要求; | ||
| 165 | |||
| 166 | (二)恢复点目标(RPO):业务功能恢复时能够容忍的数据丢失量。 | ||
| 167 | |||
| 168 | 第三十一条 基于确定的恢复时间目标和监管要求,事件经理负责对事件的解决进行监控并根据实际情况决定是否升级。 | ||
| 169 | |||
| 170 | |||
| 171 | === **第十一章 附 则** === | ||
| 172 | |||
| 173 | |||
| 174 | 第三十二条 本规范由中国邮政储蓄银行数据中心负责解释和修订。 | ||
| 175 | |||
| 176 | 第三十三条 本规范自发布之日起执行。 | ||
| 177 | |||
| 178 | |||
| 179 | |||
| 180 | [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] [[ 阅读下一篇>>https://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/26%20%E6%9F%90%E9%93%B6%E8%A1%8C%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83ITIL%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E4%BD%93%E7%B3%BB%E2%80%94%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] |