运维应急响应管理新规制度Word文件下载.docx
- 文档编号:17694430
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:17
- 大小:24.79KB
运维应急响应管理新规制度Word文件下载.docx
《运维应急响应管理新规制度Word文件下载.docx》由会员分享,可在线阅读,更多相关《运维应急响应管理新规制度Word文件下载.docx(17页珍藏版)》请在冰豆网上搜索。
4.2突出关键,加强演练
对关键信息系统加大监控和应急处理力度,确保应急信息立即正确传输。
每十二个月开展应急演练工作,确保应急方法合理、有效。
4.3技术支撑,健全机制
在充足利用用户现有信息资源、系统和设备基础上,采取优异适用估计、预防、预警和应急处理技术,改善和完善应急处理装备、设施和手段,提升应对信息系统应急事件技术支撑。
建立健全应对信息系统应急事件有效机制。
5风险评定
应急响应小组每十二个月对关键信息系统进行一次风险评定,并依据风险评定结果来制订或更新应急预案。
风险评定方法以下:
5.1系统关键性评定
等级
描述
赋值
1级
将对用户造成极严重或灾难性损失
4
2级
将对用户造成较关键损失
3
3级
将对用户造成一定损失
2
4级
将对用户造成有限损失
1
依据上表对信息系统和相关外部环境进行关键性评定。
5.2影响度评定
影响度描述
高
关键业务全方面中止;
影响大面积用户正常使用;
中
部分关键业务中止;
影响一定范围内用户正常使用;
低
单一业务中止;
影响部分用户正常使用;
依据上表对信息系统和相关外部环境进行影响度评定。
5.3发生几率评定
可能性取值
可能性描述(威胁发生频率)
常常
可能每个季度发生一次或以上
偶然
可能每六个月会发生一次
极少
可能每十二个月发生一次或更少
依据上表对风险发生几率进行评定。
5.4发生时段评定
时段程度描述
关键业务并发高峰期;
关键业务关键程序实施期;
部分关键业务并发高峰期;
部分关键程序实施期;
非关键业务并发期;
非关键程序实施期;
5.5风险等级评定
根据关键性、影响度、发生几率赋值相乘,得出信息系统和相关环境风险等级。
等级描述以下:
可能性
影响度
关键性
6
9
8
12
18
7
16
24
风险值=关键性×
风险发生可能性×
风险发生严重性
风险等级
风险值n
高(H)
n>
=12
中(M)
12>
低(L)
n<
=4
5.6进行风险评定
根据风险等级评定,列出信息系统和相关外部环境,描述可能发生风险,针对每一个风险制订控制方法,并明确对应责任人,形成《风险评定表》,撰写风险评定汇报。
6事件分级
依据信息系统事件分级考虑要素,将信息系统事件划分为三个等级:
I级事件、II级事件、III级事件。
●通常(III级):
综合分值在1-4分;
●较大(II级):
综合分值在5-12分;
●重大(I级):
综合分值在大于12分;
6.1信息系统关键性
信息系统关键性由以下要素决定:
1)信息系统所属类型,即信息系统资产安全利益主体。
2)信息系统关键处理业务信息类别。
3)信息系统服务范围,包含服务对象和服务网络覆盖范围。
4)业务对信息系统依靠程度。
其中第1)和2)个要素决定信息系统内信息资产关键性,第3)和第4)个要素决定信息系统所提供服务关键性,而信息资产及信息系统服务关键性决定了信息系统关键性。
信息系统分级及赋值以下:
4级信息系统
3级信息系统
2级信息系统
1级信息系统
6.2信息系统服务时段
信息系统服务时段划分为3级。
依据应急事件发生不一样时间,对信息系统恢复正常服务所需时间要求而确定。
非系统服务时段(不含系统服务时段立即开始)
系统服务时段或系统服务时段立即开始
系统处于关键时段保障(业务必需正常运行时间)或处于服务高峰时段
信息系统损失程度赋值
应急事件造成信息系统损失程度划分为3级。
依据故障发生对信息系统提供服务能力下降程度而确定。
系统性能
系统功效
功效无损
部分损失
全部损失
小于阈值
—
大于或等于阈值
关键时段保障损失程度赋值为3
6.3事件定级
将以上应急事件三个要素赋值相乘,事件等级以下表所表示:
范围
1~6
III事件
8~18
II事件
26~36
I事件
7组织机构和职责
7.1企业内部组织
企业内成立应急处理领导小组、指挥小组、工作小组。
应急组织设置依据实际项目标应急组织管理机制,受用户应急组织领导。
7.1.1总责任人
总责任人关键职责:
统一领导信息系统应急事件企业内部应急处理工作,提议研究重大应急决议和布署,决定实施和终止应急预案。
7.1.2应急指挥小组
应急指挥小组关键职责:
接收应急总责任人领导,传达和落实应急总责任人各项指令,汇总和上报应急信息,负责应急工作小组组员协调沟通,协调应急事件处理工作中重大问题。
7.1.3应急工作小组
应急工作小组关键职责:
落实应急总责任人及应急指挥小组部署各项任务;
组织制订应急预案,并监督实施情况;
掌握应急事件处理情况,立即向应急总责任人和应急指挥小组汇报应急过程中重大问题。
角色
角色匹配
总责任人
总经理、工程运维中心总监(副总经理)
应急指挥小组
运维部经理、技术支持部经理、运维项目经理、综合管理部、质量管理部经理
应急工作小组
技术支撑主管、研发主管、运维主管、运维工程师、备件管理员等运维团体组员、质量管理员
7.1.4相关外部角色
服务需方应急响应责任人和供给商等外部联络人及相关人员。
8应急要素和体系
8.1事件处理要素
8.1.1管理层面
1)开启指挥体系:
I级事件开启和指挥由应急总责任人负责,II、III级事件开启应急指挥小组负责。
2)掌握事件动态:
事件动态由应急工作小组人员搜集并立即反馈给应急指挥小组,应急指挥小组决定信息共享、沟通、处理。
3)处理实施:
●控制事态预防蔓延
●做好处理消除隐患
4)后期处理:
事件调查汇报和经验教训总结及改善提议。
5)保障方法:
包含通讯和信息保障,应急支援和设备保障,技术贮备和保障,宣传、培训和演练,监督检验等。
8.1.2技术层面
信息系统事件发生后,事发部门应立即开启相关应急预案,实施处理并立即报送信息。
1)控制事态发展,防控蔓延。
事发部门先期处理,采取多种技术方法,立即控制事态发展,最大程度地预防事件蔓延。
2)快速判定事件性质和危害程度。
立即分析事件发生原因,依据信息系统运行和承载业务情况,初步判定事件影响、危害和可能包含范围,提出应对方法提议。
3)立即汇报信息。
事发部门在先期处理同时要根据预案要求,立即向上级汇报事
4)做好事件发生、发展、处理统计和证据留存。
8.1.3事件归口
发生应急事件归口部门是应急体系开启责任部门。
8.1.4分级响应
发生I级事件,由应急工作小组初步判定事件等级后,将信息通知应急指挥小组并注意连续监控事态、搜集信息、做出应急准备;
应急指挥小组响应判定为I级事件后,立即通知应急总责任人,并由应急总责任人开启应急预案。
发生II、III级事件,由应急工作小组初步判定事件等级后,将信息通知应急指挥小组并注意连续监控事态、搜集信息、做出应急准备;
应急指挥小组响应判定为II、III级事件后,立即开启应急预案。
应急事件等级应置于动态调整控制中。
8.2指挥和协调
I级级事件,由应急工作小组搜集信息,应急指挥小组做出预判,并快速通知应急总责任人,由应急总责任人进行指挥和决议。
II、III级事件,由应急指挥小组进行指挥和决议,并立即将处理过程、汇报等上报应急总责任人。
8.3信息共享和处理
I级事件,由应急工作小组搜集信息并提交给应急指挥小组和应急总责任人,由应急总责任人决定信息分发、共享和处理。
II、III级事件,由应急指挥小组决定信息分发、共享和处理,并上报应急总责任人。
8.4通讯
应急响应小组和工作小组建立通信录,并二十四小时开通联络电话,保持通信顺畅。
通信录应上报应急总责任人。
事件处理过程中值班人员必需拥有完整通信联络方法,并有足够通信手段确保联络顺畅。
8.5外部沟通
应急组织应和外部相关利益方进行沟通确定统一沟通步骤和方法。
8.6服务需方
当应急事件发生时,若是由用户报障到服务台,服务台人员应向用户具体了解事件情况。
项目经理接单后应立即和用户方责任人沟通,立即开展工作。
若是由现场工程师主动发觉,则应立即通知用户方责任人。
在事件处理过程中,现场责任人应立即向用户方相关人员通报最新情况。
完成处理和恢复后,现场责任人应通知用户方责任人,由用户方责任人进行现场确定。
以后应组织运行维护人员提供连续性服务,并定时向用户方责任人汇报。
在连续性服务证实一切正常后,由用户方责任人在事件单上签字,并由服务台进行回访确定后,现场责任人可向应急指挥小组申请关闭事件。
在应急事件关闭后,应急总责任人应授权应急指挥小组向相关利益方通报事件信息。
8.7供给商
在应急事件处理过程中,可能会需要供给商提供服务。
此时现场责任人应依据应急预案,和供给商联络。
9运行机制
9.1日常监测和预警
组织应该对运行维护服务对象运行情况进行监测和预警,以跟踪和判别以下对象容量、可用性和连续性。
1)应用系统;
2)支撑应用系统运行系统软件、工具软件;
3)网络及网络设备;
4)安全设备;
5)主机、存放、外设、终端等设备;
6)安防、一卡通、会议等智能化设备。
如发觉有异常情况时,要立即处理并向现场责任人汇报,并立即排除信息系统中存在风险隐患。
9.2应急开启
应急预案开启有以下两种方法:
1)碰到I级事件,事件信息由应急工作小组提供并提交给应急指挥小组,应急指挥小组做出初步判定和初步事件等级确实定,初步确定为I级事件,呈报应急总责任人,由应急总责任人下达开启应急预案。
2)碰到II、III级事件,应急指挥小组自行开启应急预案,并立即上报应急总责任人。
9.3事件汇报
当发觉各类信息系统事件时,应根据事件等级逐层汇报。
汇报分为紧急汇报和具体汇报。
紧急汇报是指对应部门在事件发生后,立即向本部门应急指挥小组以口头和应急汇报表形式汇报事件简明情况;
具体汇报是指由对应部门应急处理机构在事件处理暂告一段落后,以书面形式提交具体汇报。
应急指挥小组对各类事件影响进行初步判定,汇报矩阵以下:
事件等级
汇报事件要求
汇报对象
I
10分钟内
II
30分钟内
III
60分钟内
汇报内容应正确、详实,任何部门和个人均不得缓报、瞒报、谎报或授意她人缓报、瞒报、谎报事件。
事件汇报信息通常包含以下要素:
发生事件信息系统名称及业务部门、地点、原因、信息起源、事件类型及性质、危害和损失程度、影响部门及业务、事件发展趋势、采取处理方法等。
9.4应急调度
企业应该根据预案开展统一应急调度,包含人员、资金和设备等。
应急调度由应急总责任人授权应急指挥小组实施。
9.5排查和诊疗
组织应明确故障排查和诊疗步骤;
应急事件排查和诊疗步骤参考《事件和服务请求过程》,排查和诊疗过程需在《应急事件汇报》进行统计。
处理应急事件过程中,现场责任人应立即和相关利益方就排查、诊疗结果进行沟通和问题确定。
9.6处理和恢复
应急事件处理和恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复。
必需时可启用备品备件、灾备系统等。
应急事件处理和恢复步骤参考《事件和服务请求过程》,处理和恢复过程需在《应急事件汇报》进行统计,并立即通知利益相关方。
在处理和恢复应急事件时,应在满足事件等级处理时间要求前提下,立即恢复服务。
事件等级处理时间要求以下:
处理时间要求
2小时
4小时
6小时
9.7事件升级
当事件处理超出事件等级处理时间要求时,应急工作小组应向应急指挥小组申请事件升级,递交《应急事件升级审批表》。
事件升级实施授权应由应急指挥小组责任人开启。
应急指挥小组应对事件升级可能造成影响进行评定,并在相关利益方间达成一致。
9.8连续服务
完成处理和恢复后,应组织运行维护人员提供连续性服务。
应急响应组织应对连续性服务效果进行评价。
连续服务评价结果,应作为应急事件关闭输入。
I级应急事件应急处理结束后应亲密关注,监测系统2周,确定无异常现象。
II级应急事件应急处理结束后应亲密关注,监测系统1周,确定无异常现象。
III级应急事件应急处理结束后应亲密关注,监测系统3天,确定无异常现象。
9.9应急事件关闭
9.9.1申请
在同时满足下列条件下时,应急工作小组责任人可向应急指挥小组提出关闭申请。
●应急事件处理已经结束,设备、系统已经恢复运行。
●连续服务阶段系统无异常,连续服务阶段结束。
●服务需方应急响应责任人同意事件关闭。
●应急事件处理过程文档已整理完成。
9.9.2核实
应急指挥小组接到关闭申请后,应逐项核实汇报内容,以判别应急事件处理过程和结果信息是否属实以后通报应急总责任人,由应急总责任人做出关闭决定。
9.9.3事件通报
应急总责任人应授权应急指挥小组向相关利益方通报事件信息,内容应包含:
●事件发生原因、事件等级及影响范围;
●事件对应预案;
●事件处理过程和方法;
●事件调整升级情况;
●连续性服务情况;
●事件处理评价;
●事件关闭申请处理意见;
●关闭通报范围和包含接收者。
应急事件发生原因、处理过程和方法应记入知识库。
9.10总结改善
9.10.1应急工作总结
组织应定时对应急响应工作进行分析和回顾,总结经验教训,并采取合适后续方法。
对应急响应工作分析和回顾应考虑以下方面:
●应急响应工作绩效;
●应急准备工作充足性和有针对性;
●应急事件发生原因、数量及频率;
●应急事件处理经验得失;
●应急事件趋势信息;
●信息系统中潜在类似隐患。
对应急响应工作分析和回顾应形成《应急响应工作总结汇报》,并将总结汇报作为改善应急响应工作及信息系统关键依据。
9.10.2应急工作审核
应急总责任人应定时提议对应急响应工作评审,以确保应急响应过程和管理符合预定标准和要求。
审核结果应该正式存档并通知给相关利益方。
评审最少每十二个月一次,可于企业内审时进行。
1)审核时应考虑要素包含:
2)相关利益方要求和反馈;
3)组织所采纳用于支持应急响应多种资源和步骤;
4)风险评定结果及可接收风险水平;
5)应急预案测试结果及实际实施效果;
6)上次评审后续活动跟踪;
7)可能影响应急响应多种业务变更;
8)近期在处理应急事件过程中总结经验和教训;
9)培训结果和反馈。
10)审核输出结果应该包含:
●改善目标;
●改善具体工作内容;
●所需多种资源,包含人员、资金和设备等。
10保障方法
10.1通信保障
指挥、通信联络和信息交换渠道关键有外线电话、手机、传真、电子邮件、微信、QQ等方法,相关应急联络人员手机应保持天天二十四小时处于开机状态。
10.2物资保障
各部门依据信息系统事件防治工作所需确保经费,配置对应应急设施,以确保事件应急工作顺利进行。
应急物资关键有备品备件、常见工具等。
10.3技术保障
任何状态下,应提供充足技术保障,如网络拓扑图、服务器清单、网络设备配置、访问控制策略、应用系统和各类软件版本,并定时进行数据备份,以保障发生事件时,受影响信息系统能立即恢复。
重视信息系统事件体系建设、运维和升级换代,确保信息系统稳定和安全,确保在事件处理过程、系统恢复或重建过程中有足够技术支撑。
10.4经费保障
各部门应保障应急培训、演练、添置应急物资等所需经费。
10.5人员保障
各部门需加强信息系统应急事件应急技术支持队伍建设,提升人员业务素质、技术水平和应急处理能力。
确保在事件处理过程和系统恢复或重建工作中人员在岗并含有处理能力。
11宣传、培训和演练
11.1宣传
企业各部门应加强应急工作宣传和教育,提升各级人员对应急预案关键性认识,加强各部门和部门之间协调和配合。
11.2培训
各信息系统应急预案包含人员应定时开展应急预案培训,做好信息系统相关知识宣传和普及,增强各运维人员责任意识,熟练掌握应急响应程序和应急处理技能等内容。
11.3演练
企业要组织对预案进行定时演练,经过演练验证预案合理性,立即修订和完善不符合实际应急处理情况,有针对性地改善信息系统应急事件处理能力,确保事件发生后应急处理手段立即到位和有效。
相关部门在做应急演练前要做好相关准备工作,确保演练工作安全。
要明确演练目标和要求,统计演练过程,对演练结果进行评定和总结。
附件1:
应急响应体系矩阵表以下:
等级判定
预案开启
指挥和决议
信息分发、共享和处理
事件升级、应急调度
关闭及通报
I级
指挥小组
领导小组
II级
III级
附件2:
应急响应责任人和应急小组责任人记录表
责任人
姓名
职务
办公电话
手机
组长
王增强
总经理
副组长
赵存会
副总经理
吴喆峰
运维部经理
组员
运维研发主管
技术支撑主管
质量管理部经理
综合管理部
人力资源部
运维部
注:
所列事项发生变更时,须重新报运维部、质量管理部、综合管理部立案。
12应急响应管理关键指标
应急响应管理工作指标应每十二个月组织进行评定,依据评定结果确定是否需要调整指标或指标目标值。
指标名称
考评要求
考评指标
应急响应宣贯体系建设
每六个月度最少进行一次关键项目应急培训、演练
针对应急预案,关键运维项目是否制订演练计划、演练脚本、培训
应急工作审核
每六个月度最少进行一次应急工作组织会议,对应急响应工作进行评审和总结
每六个月度组织人员对应急响应工作进行评审
逐项应急演练次数大于一次
检验全部运维项目标应急演练统计
每十二个月度全部运维项目应组织一次应急演练
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应急 响应 管理 规制