应急响应管理程序Word文档下载推荐.docx
- 文档编号:22969762
- 上传时间:2023-02-06
- 格式:DOCX
- 页数:32
- 大小:26.49KB
应急响应管理程序Word文档下载推荐.docx
《应急响应管理程序Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《应急响应管理程序Word文档下载推荐.docx(32页珍藏版)》请在冰豆网上搜索。
3)网络安全应急小组:
负责对网络问题及其设施发生故障的响应;
4)硬件应急小组:
负责对主机、储存、外设、终端等设施发生故障时的响应;
5)基础环境应急小组:
负责对电力,空调,消防等基础类建设发生故障时的应急响应。
4.3应急办理前风险评估
运维项目启动后,应急小组应联合项目SLA要求及项目实质状况,进行风险评估,依据风险评估结果区分应急响应事件等级,成立保障体制,成立回退体制。
4.3.1风险评估
依据风险项可能致使的应急事件区分,设置三个要点指标,重要性、影响值、
可能性,经过三个指标对可能致使应急事件的风险项进行剖析,并最后给出风
险等级。
重要性:
赋值描绘
1波及人员、桌面设施、会议及系统监控的级别
2波及网络安全、系统运转、大型主机故障的级别
3波及基础环境的故障、灾祸天气致使的环境、机房、网络瘫痪的级别
影响值:
赋值
描绘
1
个别客户业务或信息财产遇到影响
2
独自业务或信息财产遇到影响
3
多个业务或信息财产遇到影响
可能性:
1不曾发生或可能性极小的状况
2有时发生且在运维过程中无可防止的状况
3发生概率较大,人为或故障都有可能引起的状况
风险等级=重要性*0.5+影响值*0.4+可能性*0.1
风险等级不足整数的,自动进位至整数
依据风险级别,能够有针对性的在应急准备阶段、监控预警阶段对风险项进行
相应的准备和监控。
以下为主要风险评估内容:
应急响应风险评估列表
应急风险
风险评
重要性
风险点
影响值
可能性
风险
评估内容
估细项
等级
简单因公司制度、人
机构、制
员问题致使项目管理
度、人员
风险,对公司生产经
管理风险
创造成损失。
因平时操作不妥造成
平时保护
的项目风险,对公司
生产经创造成损失。
网络设施
因网络设施柔弱造成
柔弱性
的风险
网络柔弱性风险
操作系统
因操作系统柔弱造成
数据库脆
因数据库柔弱造成的
弱性
系统风险
网络服务
因网络服务不规范、
达不到SLA要求造成
应急方案
因应急方案不完美、
应急演练的风险
应急演练达不到预约
及演练
要求的风险
环境因素
因环境因素或设施问
基础环境的风险
及设施故
题造成的风险
障
储存介质
柔弱性风
险
物理柔弱性风险
远程控制
木马风险
4.4应急事件等级区分
对重要信息系统风险评估后,项目经理还应组织客户、其余服务供给商等对信息系
统可能发生的应急事件进行等级区分。
4.4.1等级区分的依照
信息系统应急事件等级区分的主要依照包含:
信息系统的重要程度、信息系统
服务时段、信息系统受损程度。
此中:
信息系统的重要程度
重要程度主要应试虑信息系统所支撑的业务的重要性,
以及信息系统内信息财产
的重要性和信息系统服务的重要性。
依据重要程度的不一样,
区分为1-4个等级,
并对应赋值1-4分,以下表所示:
1个别客户业务或信息财产遇到影响
2独自业务或信息财产遇到影响
3三个业务或信息财产遇到影响
4大面积业务或信息财产遇到影响
信息系统服务时段
服务时段主要应试虑应急事件发生时系统供给服务的状态。
服务时段的区分及
赋值以下:
1非系统服务时段(不含系统服务时段马上开始)
2系统服务时段或系统服务时段马上开始
3系统处于要点时段保障或处于服务顶峰时段
信息系统受损程度
受损程度主要应试虑应急事件发生时信息系统功能和性能等方面的影响程
度。
受损程度的区分及赋值以下:
系统性能
系统功能
功能无损
部分损失
所有损失
小于阈值
—
大于或等于阈值
*注:
要点时段保障的损失程度赋值为
3。
重要事件分值计算与定级
重要事件分值=重要程度值*服务时段值*受损程度值
重要事件定级与重要事件分值有关,详细区分标准以下:
重要事件分值区间
重要事件定级
28~36区间
一级事件
18~24区间
二级事件
1~6区间
三级事件
4.5先期处理
(1)当发生突发事件时,运维部应做好先期应急处理工作,立刻采纳举措控制局势,同时向有关主管部门通告。
(2)突发事件分为三级:
(拜见4.4)
重要(Ⅰ级):
设施在运转中出现整机系统瘫痪货服务中止,致使设施的基本功能不可以实现或全面退化的故障;
较大(Ⅱ级):
设施在运转中出现的故障拥有潜伏的系统瘫痪或服务中止的危险,并可能致使的基本功能不可以实现或全面退化;
一般(Ⅲ级):
设施在运转安装过程中,客户对产品功能、配置等方面需要的信息和需求,对业务系统几乎无影响。
;
(3)运维项目经理在接到突发事件发生或可能发生的信息后,应增强与运维工程师的联系,掌握最新发展态势。
对Ⅲ级的突发事件,由运维项目经理自行负
责应急处理工作。
对有可能演变成Ⅱ级或Ⅰ级的突发事件,要成立公司协调小组处理工作提出建议方案,并作好启动应急方案的各项准备工作。
运维部要依据事件发展态势,组织差遣应急增援力量,支持做好应急处理工作。
4.6应急方案
4.6.1应急方案拟订流程
1)项目经理依据合同内容,以及需求方的需求剖析,确认能否有需要成立应急方案;
2)不需要成立应急方案,则按事件办理;
不然成立应急方案;
3)由运维经理率领的运维团队负责应急方案的评审;
4)对应急方案进行测试,明确能否切合需求剖析,并对有关运维工程师进行应急培训;
5)测试不经过,则返回项目经理,从头拟订应急方案;
不然运维部经理确定应急方案;
6)组织按期针对应急方案的培训和演练。
4.6.2流程图
应急响应管理
输入运维团队运维项目经理运维部经理输出
合同需求剖析
能否制
定方案
NO封闭
YES
拟订应急方案
评审
测试培训
能否改良
确定应急方案
按期培训、演练
应急演练记录
4.6.3主要活动描绘
编
流程活动输入描绘输出责任人
号
1.项目启动早期,项目经理向运维部提交《启动应急流程申请单》,《启动应急流程申请单》获同意后(包含口头同意),组建应急响应工作小
1需求剖析
合同
组,对发生的重要事故进行议论剖析并拟订应急办理方案。
应急响应工
运维项目经理
作小组人员应由项目经理、甲方业务代表、运维工程师、厂家支撑构成。
2.应急小组应联合项目SLA要求及项目实质状况,进行风险评估,并建
立保障体制,成立回退体制。
项目经理依据应急响应工作小组的风险评估及应急事件等级区分结果,
拟订应
应急恳求
组织编制相应的应急响应方案。
应急响应方案应依据客户自己业务的需
运维工程师
急方案
要,对应急事件级其他响应时间、处理达成时间等达成一致,并为不一样
的应急事件级别,配置相应的保障举措如人员、资本、设施等。
1.应急方案评审应依照以下原则:
脚踏实地、切合客户单位应急管理
工作实质;
比较有关标准、客户系统风险评估结果等发现方案存在的问
题与不足;
依赖专家,综合评定,实时增补完美应急方案。
2.应急方案评审应依照以下文件,并考虑单位实质:
可能存在事故风险和生产安全事故应急能力。
3.
参加应急方案的评审应包含客户方、厂家或其余供给商等的人员参
加;
4.
应急方案评审的频次:
规定每个项目应急方案一定经过评审通事后方
运维部经理
可组织培训、演练及实行。
5.
应急演练的方法:
规定应急演练的方法为远程与现场想联合方式进
行。
6.
审查通事后,项目经理组织运维团队所有人员进行应急响应方案的培
训及演练工作。
对已经评审经过的应急方案进行实地演练,若演练成功,运维部经理确
认应急方案。
4
确认应急方案成立后,由项目经理拟订并公布《运维项目应急办理培训
计划》。
项目经理需有针对的拟订培训计划、培训资料,培训内容包含:
服务技术、服务意识、服务流程等。
使运维工程师能够按应急办理服务过程和服务规范要求,供给并交托约
定的服务。
1.运维项目需每年许多于1次进行应急办理的演练工作。
项目经理需在
应急演练前拟订《应急演练计划》,《应急演练计划》需对演练的目的、
按期培训、
风险评估、保障举措等做详尽说明。
应急演
5
演练
2.应急演练前项目经理将《应急演练计划》上报给运维部及用户进行
练记录
评估、审查,在获得运维部及用户审查通事后,项目经理对项目构成员
进行针对本次应急演练的培训及宣贯工作。
4.6.4主要输出
《应急方案》
《应急演练记录》
4.7培训及查核
4.7.1培训
依据人事部有关规章制度中的《职工培训计划》,对应急负责人的应急能力
进行有关培训。
4.7.2查核
依据人事部有关规章制度中的《职工绩效查核》中的有关能力的查核,对应急负责人员进行有关查核。
5.监控预警
5.1目的
为了防备突发应急事件的发生,保护系统长久高效稳固的运转,降低系统运转的风险,需要有必定的监控预警体制,防备于已然。
5.2例行监控
5.2.1范围
1)应用系统
煤炭运销管理系统、煤炭物质供给管理系统、CMIS煤炭公司薪水信息管理系统、
Portal门户、财务核算子系统、资本管理子系统、人力资源管理子系统、综合
统计子系统、BQ商业智能子系统、数据管理平台等
2)支撑应用系统运转的系统软件、工具软件
AIX操作系统、HACMP高可用服务、数据库软件服务、中间件软件服务、备份管
理软件服务
3)网络及网络设施
互换机、路由器等网络设施
4)安全设施
防火墙
5)主机、储存、外设、终端等设施
IBM小型机、X86服务器、刀片服务器、磁盘阵列、NetApp储存、台式机、笔
记本、扫描仪、打印机、复印机、传真机、投影仪、视频监控设施、电视电话会议设施等
6)电力、空调、消防等基础环境精细空调、UPS电源等
5.2.2方法
1)建立服务台,保持监控长久健康营运
2)成立知识库,完美监控内容,保证监控工作的理论依照
3)完美明确的监控制度,包含监控项目、监控时间、监控频次、监控项目指标、监控结果反应等
4)确定监控人员及职责区分
运维人员可依据实质状况运用有关工具进行监控
5.3监控报告
成立监控预警的记录和报告,并依据规定完好填写报告的内容,在应急事件发生后,监控责任人应当向应急事件响应小组提交监控报告
应急事件响应责任人应付报告内容进行逐项核实,核实确认后,出拥有关应急事件报告,应急事件报告应作为事件级别评估的输入,要点时段保障需求也应作为事件级别评估的输入。
5.4事件级别评估
应急事件响应小组负责人应依据事件级别定义,初步确定应急事件所对应的事
件级别,并将事件级别置于动向调整控制中。
5.5启动应急方案
组织架构下拥有成立、评审、审批应急方案的策略和程序,控制启动方案的受权和实行。
应急事件有关各方,包含服务供给商,需求方,厂商等,需要对应急方案达成一致。
可依据先期处理要求进行应急响应方案的自动启动,或由应急响应责任人或现场负责人启动方案。
应记录应急响应方案启动的过程和结果。
应急事件现场负责人,应当向有关组织、单位见告方案启动信息,内容大概如
下:
1)方案启动的原由;
2)事件级别;
3)事件对应的方案;
4)要求采纳的技术应付举措或处理的目标;
5)实现目标所应采纳的保障举措,如人员、资本和设施等;
6)对应急处理过程及结果的报告要求,如报告程序、报告内容、报告频次等;
7)信息通告的范围和接收者。
信息通告应选用适合的方式,如电话、邮件、传真、书面文件等。
所有有关利益方应付收到的通告信息进行确认和反应。
6.应急处理过程
6.1应急调动
依照拟订好的应急方案,组建应急事件响应小组,对发生的重要事故进行议论剖析并拟订应急办理方案,安排波及应急响应的人员包含:
运维工程师、项目经理、运维部经理、服务需求方负责人,服务厂商支撑。
应急事件响应小组应联合项目SLA要求及项目实质状况,进行风险评估,并成立保障体制,成立回退体制。
有关人员保证各自业务流程范围内应急事件实时响应,保持连续追踪,直到应急事件结束。
6.2排查诊疗
流程:
1)应急事件响应小组,组织有关专项应急小构成员,对现场进行故障排查;
2)专项应急小构成员排查故障时,可使用各种工具,包含应用软件、电子剖析工具、知识库等;
3)专项应急小构成员在排查故障中,关于没法解决和确定的故障类型,需要实时联系有关厂商,进行问题定位;
4)专项应急小构成员应实时向应急事件响应负责人报告故障排查状况、诊疗信息、故障定位结果等;
5)将故障排查诊疗过程与结果进行整理概括,提交服务台;
6)应急事件响应负责人应实时与有关利益方进行交流,交流的内容主要包含系统故障点、造成故障的原由、排查诊疗状况等;
7)应急事件响应负责人应组织有关利益方对问题进行确认。
6.3办理恢复
鉴于应急响应方案、配置管理数据库、知识库等进行故障办理和系统恢复,办理与恢复的原则包含:
1)应在知足事件级别处理时间要求的前提下,赶快恢复服务;
2)采纳的方法、手段不该造成次生、衍惹祸件的发生;
3)必需时可启用备品备件、灾备系统等;
4)应当对过程及结果信息进行记录,并实时见告有关利益方;
5)现场负责人应组织对办理与恢复的结果进行初步确认。
6.4事件升级
6.4.1原则
组织应成立、审议应急事件升级的策略和程序,以控制应急事件升级的受权和实行。
当实质处理时间超出事件级别处理时间要求时,应作为事件升级的参照因素。
组织应当对事件升级可能造成的影响进行评估,并在有关利益方之间达成一致。
升级内容应包含方案调整、人员调整、资本调整以及设施调整。
事件升级的实行受权应由现场应急事件响应小组负责人启动。
应当对事件升级的过程和结果信息进行整理与归档。
6.4.2信息通告
现场应急事件响应小组负责人应向有关利益方通告事件升级信息,内容应包含:
1)事件升级的原由;
2)事件升级后的级别;
3)事件升级后与之对应的方案;
4)对升级事件处理过程及结果的报告要求,如:
报告程序、报告对象、报告内容、报告频次等;
5)信息通告的范围和波及的接收者。
信息通告应选择适合的方式,如电话、邮件、传真、书面文件等形式。
6.5应急事件封闭
6.5.1申请与核实
组织应成立、审议事件封闭的策略和程序,以控制事件封闭的受权和实行。
应当对应急事件处理的过程文档进行整理。
事件封闭申请应由有关的专项应急小组负责人提出,并提交有关文档资料。
事件封闭申请和文档资料,应作为事件封闭核实的参照因素。
现场应急事件响应小组负责人接到事件封闭申请后,应逐项核实报告内容,以鉴别应急事件处理过程和结果信息能否真实。
6.5.2封闭信息通告
组织应成立、审议应急事件封闭信息通告制度。
现场应急事件响应小组负责人应向有关利益方通告事件封闭信息,并将应急事件发生的原由、处理过程和方法应记入知识库,事件封闭信息内容应包含:
1)事件发生的原由、事件级别及影响范围;
2)事件对应的方案;
3)事件的处理过程和方法;
4)事件的调整升级状况(没有则不填);
5)连续性服务状况;
6)事件处理评论;
7)事件封闭申请的办理建议;
8)封闭通告的范围和波及接收者。
6.6流程
6.6.1应急响应流程
1)项目经理接到用户应急服务恳求;
2)依据应急方案,组建应急事件响应小组。
客户单位负责人配合办理,服务台做好故障追踪并向用户报告;
3)应急事件响应小组判断事件能否能够独立办理。
假如不可以独立办理,协调厂
家工程师诊疗故障,厂商需要给出可行的应急方案并做好技术支撑;
假如能独立达成,则启动应急方案;
4)用户审批我方的应急方案;
5)我方实行应急方案,解决故障;
6)用户确认故障办理结果;
7)项目经理拿到用户反应的故障办理结果,将办理结果返回服务台;
8)服务台回访用户应急故障办理状况,并将反应结果见告项目经理;
9)项目经理依据客户的反应,完美优化应急方案。
6.6.2流程图
应急响应实行流程
用户服务台项目经理运维部经理产出文档
接用户应急
服务恳求
配合应
故障追踪并
应急事件响应小
协调厂家工程
组能否能够独立
否
急办理
向用户报告
师诊疗故障
达成
是
审批应急方案
启动应急方案
确认应急方案
并技术支撑
用户确认应急
办理结果
实行应急方案,
解决故障
应急响应实行
回访用户故障
将办理结果返
总结报告
办理状况
回服务台
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应急 响应 管理程序