应急响应管理程序Word下载.docx

应急响应管理程序Word下载.docx

《应急响应管理程序Word下载.docx》由会员分享，可在线阅读，更多相关《应急响应管理程序Word下载.docx（21页珍藏版）》请在冰豆网上搜索。

不同的应急事件，成立专项应急小组，具体职责细化如下：

1）应用系统应急小组：

负责运维应用软件发生错误或大面积故障时的响应；

2）系统应急小组：

负责对支撑应用运行的系统故障及数据库故障的响应；

3）网络安全应急小组：

负责对网络问题及其设备发生故障的响应；

4）硬件应急小组：

负责对主机、存储、外设、终端等设备发生故障时的响应；

5）基础环境应急小组：

负责对电力，空调，消防等基础类建设发生故障时的应急响应。

4.3应急处理前风险评估

运维项目启动后，应急小组应结合项目SLA要求及项目实际情况，进行风险评估，根据风险评估结果划分应急响应事件等级，建立保障机制，建立回退机制。

4.3.1风险评估

根据风险项可能导致的应急事件划分，设置三个关键指标，重要性、影响值、可能性，通过三个指标对可能导致应急事件的风险项进行分析，并最终给出风险等级。

重要性：

赋值

描述

1

涉及人员、桌面设备、会议及系统监控的级别

2

涉及网络安全、系统运行、大型主机故障的级别

3

涉及基础环境的故障、灾害气候导致的环境、机房、网络瘫痪的级别

影响值：

个别客户业务或信息资产受到影响

单独业务或信息资产受到影响

多个业务或信息资产受到影响

可能性：

未曾发生或可能性极小的情况

偶尔发生且在运维过程中无可避免的情况

发生概率较大，人为或故障都有可能引发的情况

风险等级=重要性*0.5+影响值*0.4+可能性*0.1

风险等级不足整数的，自动进位至整数

根据风险级别，可以有针对性的在应急准备阶段、监控预警阶段对风险项进行相应的准备和监控。

以下为主要风险评估内容：

应急响应风险评估列表

应急风险

评估内容

风险评

估细项

重要性

风险点

影响值

可能性

风险等级

管理风险

机构、制度、人员

容易因公司制度、人员问题导致项目管理风险，对公司生产经营造成损失。

日常维护

因日常操作不当造成的项目风险，对公司生产经营造成损失。

网络脆弱性风险

网络设备脆弱性

因网络设备脆弱造成的风险

操作系统脆弱性

因操作系统脆弱造成的风险

系统风险

数据库脆弱性

因数据库脆弱造成的风险

网络服务脆弱性

因网络服务不规范、达不到SLA要求造成的风险

应急演练的风险

应急预案及演练

因应急预案不完善、应急演练达不到预定要求的风险

基础环境的风险

环境因素及设备故障

因环境因素或设备问题造成的风险

物理脆弱性风险

存储介质脆弱性风险

远程控制木马风险

4.4应急事件等级划分

对重要信息系统风险评估后，项目经理还应组织客户、其它服务提供商等对信息系统可能发生的应急事件进行等级划分。

4.4.1等级划分的依据

信息系统应急事件等级划分的主要依据包括：

信息系统的重要程度、信息系统服务时段、信息系统受损程度。

其中：

Ø

信息系统的重要程度

重要程度主要应考虑信息系统所支撑的业务的重要性，以及信息系统内信息资产的重要性和信息系统服务的重要性。

根据重要程度的不同，划分为1－4个等级，并对应赋值1－4分，如下表所示：

三个业务或信息资产受到影响

4

大面积业务或信息资产受到影响

信息系统服务时段

服务时段主要应考虑应急事件发生时系统提供服务的状态。

服务时段的划分及赋值如下：

非系统服务时段（不含系统服务时段即将开始）

系统服务时段或系统服务时段即将开始

系统处于重点时段保障或处于服务高峰时段

信息系统受损程度

受损程度主要应考虑应急事件发生时信息系统功能和性能等方面的影响程度。

受损程度的划分及赋值如下：

系统性能

系统功能

功能无损

部分损失

全部损失

小于阈值

—

大于或等于阈值

*注：

重点时段保障的损失程度赋值为3。

4.4.2重要事件分值计算与定级

重要事件分值＝重要程度值*服务时段值*受损程度值

重要事件定级与重要事件分值有关，具体划分标准如下：

重要事件分值区间

重要事件定级

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流程图

4.6.3主要活动描述

编号

流程活动

输入

输出

责任人

需求分析

合同

1.项目启动初期，项目经理向运维部提交《启动应急流程申请单》，《启动应急流程申请单》获批准后（包括口头批准），组建应急响应工作小组，对发生的重大事故进行讨论分析并制定应急处理方案。

应急响应工作小组人员应由项目经理、甲方业务代表、运维工程师、厂家支撑组成。

2.应急小组应结合项目SLA要求及项目实际情况，进行风险评估，并建立保障机制，建立回退机制。

运维项目经理

制定应

急方案

应急请求

项目经理根据应急响应工作小组的风险评估及应急事件等级划分结果，组织编制相应的应急响应方案。

应急响应方案应根据客户自身业务的需要，对应急事件级别的响应时间、处置完成时间等达成一致，并为不同的应急事件级别，配置相应的保障措施如人员、资金、设备等。

应急方案

运维工程师

评审

1.应急预案评审应遵循以下原则：

实事求是、符合客户单位应急管理工作实际；

对照相关标准、客户系统风险评估结果等发现预案存在的问题与不足；

依靠专家，综合评定，及时补充完善应急预案。

2.应急预案评审应依据以下文件,并考虑单位实际：

可能存在事故风险和生产安全事故应急能力。

3.参加应急预案的评审应包括客户方、厂家或其它供应商等的人员参加；

4.应急预案评审的频率：

规定每个项目应急预案必须经过评审通过后方可组织培训、演练及实施。

5.应急演练的方法：

规定应急演练的方法为远程与现场想结合方式进行。

6.审核通过后，项目经理组织运维团队所有人员进行应急响应方案的培训及演练工作。

运维部经理

测试培训

对已经评审通过的应急方案进行实地演练，若演练成功，运维部经理确认应急方案。

确认应急方案成立后，由项目经理制定并发布《运维项目应急处理培训计划》。

项目经理需有针对的制定培训计划、培训资料，培训内容包括：

服务技能、服务意识、服务流程等。

使运维工程师可以按应急处理服务过程和服务规范要求，提供并交付约定的服务。

5

定期培训、演练

1.运维项目需每年不少于1次进行应急处理的演练工作。

项目经理需在应急演练前制定《应急演练计划》，《应急演练计划》需对演练的目的、风险评估、保障措施等做详细说明。

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流程图

7.优化改进

针对应急响应事件准备阶段、监控阶段、处置阶段的不同工作内容，总结整个应急响应过程中的不足和在实际操作中暴露出的缺点，以及现场处理中应该改进及优化的地方，提出明确且有针对性的改进意见，具体可从以下几方面入手进行优化改进：

1）应急准备阶段的工作是否完善，包括应急小组的成立和分工是否明确，小组在实际应急过程中的作用是否清晰可靠，职责划分是否没有异议且不重复，确保小组行动的高效性；

2）应急准备阶段，风险评估是否合理，是否能够真实体现应急事件的情况和存在风险隐患的情况；

3）应急事件等级划分时应该涵盖所有已知事件和未知但可能发生的事件的等级划分定义，并且在实际应急事件中，对应事件的等级分值与事件实际级别相一致；

4）在实际处理完应急响应事件后，应该就应急预案在实际情况中的表现，优点与不足之处，在事件结束后进行总结，结果作为优化预案的考量；

5）对于应急事件的发生，是无可避免的，不过在应急事件发生后，可总结在例行监控中的不完善项，进行优化改进，从根源上降低应急事件的发生率；

6）总结应急处置阶段，应急调度是否具有及时性和高效性，对于制度的影响导致事件响应延后的情况进行优化改进；

7）对于应急处置过程中，涉及具体排查诊断技术、处理恢复技术的情况，要求相关运维人员，对于实际操练过程中，多进行练习和摸索，在真实应急响应事件中，总结相关经验和不足，优化运维人员的技术级别和现场处理问题的准确性、高效性。

对于关闭阶段的应急事件，由服务台记录，相关人员进行归纳总结，完善过程中的细节，改进流程管控中的不足之处。