应急响应管理规范.docx

上传人:b****7 文档编号:8910291 上传时间:2023-02-02 格式:DOCX 页数:10 大小:23.42KB
下载 相关 举报
应急响应管理规范.docx_第1页
第1页 / 共10页
应急响应管理规范.docx_第2页
第2页 / 共10页
应急响应管理规范.docx_第3页
第3页 / 共10页
应急响应管理规范.docx_第4页
第4页 / 共10页
应急响应管理规范.docx_第5页
第5页 / 共10页
点击查看更多>>
下载资源
资源描述

应急响应管理规范.docx

《应急响应管理规范.docx》由会员分享,可在线阅读,更多相关《应急响应管理规范.docx(10页珍藏版)》请在冰豆网上搜索。

应急响应管理规范.docx

应急响应管理规范

应急响应管理规范

历史修订记录

序号

更改单号

更改说明

修订人

生效日期

现行版次

 

总则

编制目的

确保用户业务运作所需的基础架构和服务在突发事故发生后的限定时间内能够得到恢复,保证用户业务的运行和服务协议SLA的达成。

提高应对应急事件的管理水平和应急处理能力,有效防范信息系统风险,减少信息系统故障对生产业务造成的影响,确保信息系统运行的连续性,特制定本预案。

适用范围

本预案适用于公司所承接的运维项目范围内的信息系统应急事件。

事件分级

根据运维项目所涉及的事件分级考虑要素,将信息系统事件划分为三个级别:

I级事件、II级事件、III级事件。

影响度判断原则

级别

判断说明

一级

(重大)

核心系统设备或服务端软件系统瘫痪

二级

(严重)

主要系统设备或服务端软件系统故障

三级

(一般)

辅助子系统在运行过程中发生的不影响主要业务系统使用或间接性故障

紧急度判断原则

级别

判断说明

一级(危急)

A类客户申告的故障影响度为一级

二级(紧急)

B类客户申告的故障影响度为二级。

三级(一般)

C类客户申告的故障影响度为三级

判断优先级矩阵

重大

严重

一般

危急

Ⅰ级

Ⅰ级

Ⅱ级

紧急

Ⅰ级

Ⅱ级

Ⅲ级

一般

Ⅱ级

Ⅲ级

Ⅲ级

级别判断原则

级别

判断说明

Ⅰ级

因核心系统设备或服务端软件系统瘫痪,造成关键业务或整个业务系统功能丧失性故障(如:

程控交换机瘫痪造成报警话务无法呼入、数据库瘫痪、核心服务程序故障、整个系统无法进行受理等)。

Ⅱ级

因主要系统设备或服务端软件系统故障,造成部分关键业务或整个业务系统功能间歇性不可用或数据丢失(如无法调派、警单无法保存、无录音、终端无法登陆等)。

Ⅲ级

辅助子系统在运行过程中发生的不影响主要业务系统使用或间接性故障。

组织机构与职责

公司内部组织

公司成立应急处置领导小组、指挥小组、工作小组。

应急总负责人

应急总负责人的主要职责:

统一领导信息系统的应急事件的公司内部应急处理工作,发起研究重大应急决策和部署,决定实施和终止应急预案。

应急指挥小组

应急指挥小组的主要职责:

接受应急总负责人的领导,传达和落实应急总负责人的各项指令,汇总和上报应急信息,负责应急工作小组成员的协调沟通,协调应急事件处置工作中的重大问题。

应急工作小组

应急工作小组主要职责:

落实应急总负责人及应急指挥小组布置的各项任务;组织制定应急预案,并监督执行情况;掌握应急事件处理情况,及时向应急总负责人和应急指挥小组报告应急过程中的重大问题。

角色

角色匹配

应急总负责人

系统运维事业部总经理(张湛)

应急指挥小组

运维服务部主管(罗建仁)、服务经理、运维客服主管(周矿喜)、运维技术支持部主管(王兴元)、销售主管(应丹红)

应急工作小组

运维团队

相关外部角色

1)服务需方应急响应责任人。

2)供应商。

3)分包方。

4)供电部门

5)网络通信运营部门

应急要素与体系

事件处置要素

管理层面

(1)启动指挥体系:

I级事件的启动和指挥由应急总负责人负责;II、III级事件的启动应急指挥小组负责。

(2)掌握事件动态:

事件动态由应急工作小组人员收集并及时反馈给应急指挥小组,应急指挥小组决定信息的共享、沟通、处置。

(3)处置实施

a)控制事态防止蔓延。

b)做好处置消除隐患。

(4)后期处置:

事件调查报告和经验教训总结及改进建议。

(5)保障措施:

包括通讯与信息保障,应急支援与设备保障,技术储备与保障,宣传、培训和演练,监督检查等。

技术层面

信息系统事件发生后,事发部门应立即启动相关应急预案,实施处置并及时报送信息。

(1)控制事态发展,防控蔓延。

事发部门先期处置,采取各种技术措施,及时控制事态发展,最大限度地防止事件蔓延。

(2)快速判断事件性质和危害程度。

尽快分析事件发生原因,根据信息系统运行和承载业务情况,初步判断事件的影响、危害和可能涉及的范围,提出应对措施建议。

(3)及时报告信息。

事发部门在先期处置的同时要按照预案要求,及时向上级报告事件信息。

(4)做好事件发生、发展、处置的记录和证据留存。

事件归口

发生信息系统应急事件的归口部门是应急体系启动的责任部门。

分级响应

发生I级事件,由应急工作小组初步判定事件级别后,将信息通知应急指挥小组并注意持续监控事态、收集信息、做出应急准备;应急指挥小组响应判断为I级事件后,立即通知应急总负责人,并由应急总负责人启动应急预案。

发生II、III级事件,由应急工作小组初步判定事件级别后,将信息通知应急指挥小组并注意持续监控事态、收集信息、做出应急准备;应急指挥小组响应判断为II、III级事件后,立即启动应急预案。

应急事件的级别应置于动态调整控制中。

指挥和协调

I级级事件,由应急工作小组收集信息,应急指挥小组做出预判,并迅速通知应急总负责人,由应急总负责人进行指挥和决策。

II、III级事件,由应急指挥小组进行指挥和决策,并及时将处理过程、报告等上报应急总负责人。

信息共享和处理

I级事件,由应急工作小组收集信息并提交给应急指挥小组和应急总负责人,由应急总负责人决定信息的分发、共享和处置。

II、III级事件,由应急指挥小组决定信息的分发、共享和处置,并上报应急总负责人。

通讯

应急响应小组和工作小组建立通信录,并24小时开通联系电话,保持通信顺畅。

通信录应上报应急总负责人。

事件处理过程中的值班人员必须拥有完整的通信联系方式,并有足够的通信手段保证联系顺畅。

运行机制

日常检测与预警

组织应该对运行维护服务对象的运行情况进行监测与预警,以跟踪和判别以下对象的容量、可用性和连续性:

a)应用系统;

b)支撑应用系统运行的系统软件、工具软件;

c)网络及网络设备;

d)安全设备;

e)主机、存储、外设、终端等设备;

如发现有异常情况时,要及时处理并向现场负责人报告,并及时排除信息系统中存在的风险隐患。

应急启动

应急预案的启动有以下两种方式:

1)遇到I级事件,事件信息由应急工作小组提供并提交给应急指挥小组,应急指挥小组做出初步判断和初步事件级别的确认,初步确认为I级事件的,呈报应急总负责人,由应急总负责人下达启动应急预案。

2)遇到II、III级事件,应急指挥小组自行启动应急预案,并及时上报应急总负责人。

事件报告

当发现各类信息系统事件时,应按照事件等级逐级汇报。

报告分为紧急报告和详细汇报。

紧急报告是指相应部门在事件发生后,立即向本部门应急指挥小组以口头(电话)和应急报告表(书面)形式汇报事件的简要情况;详细汇报是指由相应部门应急处理机构在事件处理暂告一段落后,以书面形式提交的详细报告。

应急指挥小组对各类事件的影响进行初步判断,汇报矩阵如下:

事件级别

报告时间要求

报告对象

I

10分钟内

应急总负责人

II

30分钟内

应急总负责人

III

60分钟内

应急总负责人

报告内容应准确、详实,任何部门和个人均不得缓报、瞒报、谎报或者授意他人缓报、瞒报、谎报事件。

事件报告信息一般包括以下要素:

发生事件的信息系统名称及业务部门、地点、原因、信息来源、事件类型及性质、危害和损失程度、影响部门及业务、事件发展趋势、采取的处置措施等。

应急调度

公司应该按照预案开展统一的应急调度,包括人员、资金和设备等。

应急调度由应急总负责人授权应急指挥小组执行。

排查与诊断

a)组织应明确故障排查和诊断流程;

排查与诊断过程需在应急事件报告进行记录。

处置应急事件的过程中,现场负责人应及时与相关利益方就排查、诊断结果进行沟通和问题确认。

处理与恢复

应急事件的处理与恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复。

必要时可启用备品备件、灾备系统等。

在处理和恢复应急事件时,应在满足事件级别处置时间要求的前提下,尽快恢复服务。

事件级别处置时间要求如下:

事件级别

处置时间要求

I

4小时

II

6小时

III

8小时

事件升级

当事件处置事件超过事件级别处置时间要求时,应急工作小组应考虑向应急指挥小组申请事件升级,事件升级的实施授权应由应急指挥小组负责人启动。

应急指挥小组应对事件升级可能造成的影响进行评估,并在相关利益方间达成一致。

持续服务

完成处理与恢复后,应组织运行维护人员提供持续性服务。

应急响应组织应对持续性服务的效果进行评价。

持续服务的评价结果,应作为应急事件关闭的输入。

I级应急事件应急处理结束后应密切关注,监测系统2周,确认无异常现象。

II级应急事件应急处理结束后应密切关注,监测系统1周,确认无异常现象。

III级应急事件应急处理结束后应密切关注,监测系统3天,确认无异常现象。

应急事件关闭

申请

在同时满足下列条件下时,应急工作小组负责人可向应急指挥小组提出关闭申请。

应急事件处理已经结束,设备、系统已经恢复运行;持续服务阶段系统无异常,持续服务阶段结束;服务需方应急响应负责人同意事件关闭;应急事件处置的过程文档已整理完成。

核实

应急指挥小组接到关闭申请后,应逐项核实报告内容,以判别应急事件处置过程和结果信息是否属实之后通报应急总负责人,由应急总负责人做出关闭决定。

事件通报

应急总负责人应授权应急指挥小组向相关利益方通报事件关闭信息,内容应包括:

a)事件发生的原因、事件级别及影响范围;

b)事件对应的预案;

c)事件的处置过程和方法;

d)事件的调整升级情况;

e)持续性服务情况;

f)事件处置评价;

g)事件关闭申请的处理意见;

h)关闭通报的范围和涉及接受者。

总结改进

应急工作总结

组织应定期对应急响应工作进行分析和回顾,总结经验教训,并采取适当的后续措施。

对应急响应工作的分析和回顾应考虑以下方面:

a)应急响应工作的绩效;

b)应急准备工作的充分性和有针对性;

c)应急事件发生原因、数量及频率;

d)应急事件处置的经验得失;

e)应急事件的趋势信息;

f)信息系统中潜在的类似隐患。

对应急响应工作的分析和回顾应形成应急响应工作总结报告,并将总结报告作为改进应急响应工作及信息系统的重要依据。

应急工作审核

应急总负责人应定期发起对应急响应工作的评审,以确保应急响应过程和管理符合预定的标准和要求。

审核的结果应该正式存档并通知给相关利益方。

评审至少每年一次,于公司内审时进行。

审核时应考虑的要素包括:

1)相关利益方的要求和反馈;

2)组织所采纳的用于支持应急响应的各种资源和流程;

3)风险评估的结果及可接受的风险水平;

4)应急预案的测试结果及实际执行效果;

5)上次评审的后续活动跟踪;

6)可能影响应急响应的各种业务变更;

7)近期在处置应急事件过程中总结的经验和教训;

8)培训的结果和反馈。

审核的输出结果应该包括:

1)改进目标;

2)改进的具体工作内容;

3)所需的各种资源,包括人员、资金和设备等。

保障措施

通信保障

指挥、通信联络和信息交换的渠道主要有外线电话、手机、传真、电子邮件等方式,有关应急联系人员手机应保持每天24小时处于开机状态。

物资保障

系统运维事业部根据运维项目涉及的系统事件防治工作配备相应的应急设施,以确保事件应急工作的顺利进行,物资部提供应急物资所需要的备品备件、常用工具等。

技术保障

任何状态下,应提供充足的技术保障,如网络拓扑图、服务器清单、网络设备配置、访问控制策略、应用系统和各类软件的版本,并定期进行数据备份,以保障发生事件时,受影响的信息系统能及时恢复。

重视信息系统事件体系的建设、运维和升级换代,确保信息系统的稳定与安全,确保在事件处置过程、系统恢复或重建过程中有足够的技术支撑。

经费保障

公司财务部保障应急培训、演练、添置应急物资等所需经费。

人员保障

系统运维事业部加强信息系统应急事件应急技术支持队伍的建设,提高部门人员的业务素质、技术水平和应急处置能力。

确保在事件处置过程和系统恢复或重建工作中人员在岗并具有一定的战斗力。

宣传、培训和演练

宣传

系统运维事业部应加强应急工作的宣传和教育,提高各级人员对应急预案重要性的认识,加强各部门和部门之间的协调与配合。

培训

系统运维事业部涉及系统的应急预案涉及到人员应定期开展应急预案的培训,做好信息系统相关知识的宣传和普及,增强各运维人员的责任意识,熟练掌握应急响应的程序和应急处置技能等内容。

演练

系统运维事业部组织对运维承建项目的预案进行一年一次的演练,通过演练验证预案的合理性,及时修订和完善不符合实际的应急处置情况,有针对性地改进信息系统应急事件处置能力,确保事件发生后应急处理手段及时到位和有效。

相关部门在做应急演练前要做好相关准备工作,确保演练工作的安全。

要明确演练的目的和要求,记录演练过程,对演练结果进行评估和总结。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 农学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1