应急响应程序Word下载.docx
《应急响应程序Word下载.docx》由会员分享，可在线阅读，更多相关《应急响应程序Word下载.docx（22页珍藏版）》请在冰点文库上搜索。
公司成立应急协调小组（以下简称协调小组），应急协调小组成员由厂长、管理部主管、各车间主管组成。
当发生突发事件时，管理部主管负责协调相应的各车间主管等人员成立应急事件响应小组，负责突发事件的应急处置工作。
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应急预案流程图
应急响应管理
输入运维团队运维项目经理运维部经理输出
合同需求分析
是否制
定预案
NO关闭
YES
制定应急预案应急预案
评审
测试培训
是否改进
确立应急预案
定期培训、演练
应急演练记录
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）对于应急处置过程中，涉及具体排查诊断技术、处理恢复技术的情况，要求相关运维人员，对于实际操练过程中，多进行练习和摸索，在真实应急响应事
件中，总结相关经验和不足，优化运维人员的技术级别和现场处理问题的准确性、高效性。
对于关闭阶段的应急事件，由服务台记录，相关人员进行归纳总结，完善过程中的细节，改进流程管控中的不足之处。
制定：
审核：
日期：
日期：
升级会员 