应急响应程序Word格式文档下载.docx
- 文档编号:22119666
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:13
- 大小:64.50KB
应急响应程序Word格式文档下载.docx
《应急响应程序Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《应急响应程序Word格式文档下载.docx(13页珍藏版)》请在冰豆网上搜索。
3.2组织指挥机构与职责
公司成立应急和谐小组(以下简称和谐小组),应急和谐小组成员由厂长、治理部主管、各车间主管组成。
当发生突发事件时,治理部主管负责和谐相应的各车间主管等人员成立应急事件响应小组,负责突发事件的应急处置工作。
3.3应急响应流程
4.应急准备
4.1成立应急响应小组
企业应急和谐小组成员由厂长、治理部主管、各车间主管组成。
4.2职责划分
厂长职责:
应急响应和谐治理,统筹计划
治理部主管职责:
应急预案的制定,负责评估应急响应的运维本钱
各车间主管:
负责应急响应的实施,及应急人员能力的培训
不同的应急事件,成立专项应急小组,具体职责细化如下:
1)应用系统应急小组:
负责运维应用软件发生错误或大面积故障时的响应;
2)系统应急小组:
负责对支撑应用运行的系统故障及数据库故障的响应;
3)网络安全应急小组:
负责对网络问题及其设备发生故障的响应;
4)硬件应急小组:
负责对主机、存储、外设、终端等设备发生故障时的响应;
5)基础环境应急小组:
负责对电力,空调,消防等基础类建设发生故障时的应急响应。
4.3应急处置前风险评估
运维项目启动后,应急小组应结合项目SLA要求及项目实际情形,进行风险评估,依照风险评估结果划分应急响应事件品级,成立保障机制,成立回退机制。
4.3.1风险评估
依照风险项可能致使的应急事件划分,设置三个关键指标,重要性、阻碍值、可能性,通过三个指标对可能致使应急事件的风险项进行分析,并最终给出风险品级。
以下为要紧风险评估内容:
应急响应风险评估列表
应急风险
风险评
重要性
风险点
影响值
可能性
评估内容
估细项
风险等级
管理风险
机构、制度、人员
1
容易因公司制度、人员问题导致项目管理风险,对公司生产经营造成损失。
2
日常维护
因日常操作不当造成的项目风险,对公司生产经营造成损失。
3
网络脆弱性风险
网络设备脆弱性
因网络设备脆弱造成的风险
操作系统脆弱性
因操作系统脆弱造成的风险
系统风险
数据库脆弱性
因数据库脆弱造成的风险
网络服务脆弱性
因网络服务不规范、达不到SLA要求造成的风险
应急演练的风险
应急预案及演练
因应急预案不完善、应急演练达不到预定要求的风险
(1)当发生突发事件时,治理部应做好先期应急处置工作,当即采取方法操纵局势,同时向相关主管部门通报。
(2)突发事件分为三级:
(参见4.4)
重大(Ⅰ级):
设备在运行中显现整机系统瘫痪货效劳中断,致使设备的大体功能不能实现或全面退化的故障;
较大(Ⅱ级):
设备在运行中显现的故障具有潜在的系统瘫痪或效劳中断的危险,并可能致使的大体功能不能实现或全面退化;
一样(Ⅲ级)
:
设备在运行安装进程中,客户对产品功能、配置等方面需要的信息和需求,对业务系统几乎无阻碍。
;
4.6应急预案流程图
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)根据客户的反馈,完善优化应急预案。
7.优化改良
针对应急响应事件预备时期、监控时期、处置时期的不同工作内容,总结整个应急响应进程中的不足和在实际操作中暴露出的缺点,和现场处置中应该改良及优化的地址,提出明确且有针对性的改良意见,具体可从以下几方面入手进行优化改良:
1)应急准备阶段的工作是否完善,包括应急小组的成立和分工是否明确,小组在实际应急过程中的作用是否清晰可靠,职责划分是否没有异议且不重复,确保小组行动的高效性;
2)应急准备阶段,风险评估是否合理,是否能够真实体现应急事件的情况和存在风险隐患的情况;
3)应急事件等级划分时应该涵盖所有已知事件和未知但可能发生的事件的等级划分定义,并且在实际应急事件中,对应事件的等级分值与事件实际级别相一致;
4)在实际处理完应急响应事件后,应该就应急预案在实际情况中的表现,优点与不足之处,在事件结束后进行总结,结果作为优化预案的考量;
5)对于应急事件的发生,是无可避免的,不过在应急事件发生后,可总结在例行监控中的不完善项,进行优化改进,从根源上降低应急事件的发生率;
6)总结应急处置阶段,应急调度是否具有及时性和高效性,对于制度的影响导致事件响应延后的情况进行优化改进;
7)对于应急处置过程中,涉及具体排查诊断技术、处理恢复技术的情况,要求相关运维人员,对于实际操练过程中,多进行练习和摸索,在真实应急响应事件中,总结相关经验和不足,优化运维人员的技术级别和现场处理问题的准确性、高效性。
关于关闭时期的应急事件,由效劳台记录,相关人员进行归纳总结,完善进程中的细节,改良流程管控中的不足的地方。
制定:
日期:
日期:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应急 响应 程序