应急响应程序.docx

昆山易昌泰塑胶有限公司
昆山易昌泰塑胶有限公司
应急响应管理程序
1. 目标
为规范应急管理工作，建立健全应急机制,提高应对和防范风险与事故的能力，确保在事故发生后能迅速、有序地控制和处理事故，最大限度地减少事故所造成的损失和环境影响并将其控制在预期的、可接受的目标内，结合公司实际情况，特制定本制度。
2. 适用范围
突发事件包括通信线路和设备故障、主机（服务器）、存储系统、网络设备（各类网络交换机、路由器、防火墙等）、电源故障运行中断；重要系统资料、应用数据损坏货丢失，或重要信息系统数据损坏或丢失；发生计算机程序、系统参数和数据被删除等信息攻击和破坏货计算机病毒疫情导致信息系统不能提供正常服务；自然灾害（水、火、电等）造成的物理破坏、人为失误造成的安全事件。
3. 要求
3.1 工作原则
预防为主：立足安全防护，加强预警，重点保护网络设备、服务器等重要的信息系统，从预防、监控、应急处理、应急保障和防止失泄密等环节，在法律、管理、技术、人才等方面，采取多种措施，充分发挥各方面的作用，共同构筑网络与信息安全保障体系。
快速反应：在突发事件发生时，按照快速反应机制，及时获取充分而准确的信息，跟踪研判，果断决策，迅速处置，最大程度地减少危害和影响。
分级负责：按照“谁主管谁负责”的原则，建立和完善运维部安全责任制及联动工作机制。根据运维部的职能分工，各司其职，加强部门间的协调与配合，形成合力，共同履行应急处置工作的管理职责。
常备不懈：加强技术储备，规范应急处置措施与操作流程，定期进行预案演练，确保应急预案切实有效，实现突发事件应急处置的科学化、程序化与规范化。
3.2 组织指挥机构与职责
公司成立应急协调小组(以下简称协调小组)，应急协调小组成员由厂长、管理部主管、各车间主管组成。当发生突发事件时，管理部主管负责协调相应的各车间主管等人员成立应急事件响应小组，负责突发事件的应急处置工作。
3.3 应急响应流程

4. 应急准备
4.1 建立应急响应小组
企业应急协调小组成员由厂长、管理部主管、各车间主管组成。
4.2 职责划分
厂长职责：应急响应协调管理，统筹规划
管理部主管职责：应急预案的制定，负责评估应急响应的运维成本
各车间主管：负责应急响应的实施，及应急人员能力的培训
不同的应急事件，成立专项应急小组，具体职责细化如下：
1) 应用系统应急小组：负责运维应用软件发生错误或大面积故障时的响应；
2) 系统应急小组：负责对支撑应用运行的系统故障及数据库故障的响应；
3) 网络安全应急小组：负责对网络问题及其设备发生故障的响应；
4) 硬件应急小组：负责对主机、存储、外设、终端等设备发生故障时的响应；
5) 基础环境应急小组：负责对电力，空调，消防等基础类建设发生故障时的应急响应
4.3 应急处理前风险评估
运维项目启动后，应急小组应结合项目SLA要求及项目实际情况，进行风险评估，根据风险评估结果划分应急响应事件等级，建立保障机制，建立回退机制。
4.3.1风险评估
根据风险项可能导致的应急事件划分，设置三个关键指标，重要性、影响值、可能性，通过三个指标对可能导致应急事件的风险项进行分析，并最终给出风险等级。
以下为主要风险评估内容：
应急响应风险评估列表
应急风险
评估内容
风险评
估细项
重要性
风险点
影响值
可能性
风险等级
管理风险
机构、制度、人员
1
容易因公司制度、人员问题导致项目管理风险，对公司生产经营造成损失。
2
2
2
日常维护
1
因日常操作不当造成的项目风险，对公司生产经营造成损失。
3
2
2
网络脆弱性风险
网络设备脆弱性
3
因网络设备脆弱造成的风险
2
3
3
操作系统脆弱性
3
因操作系统脆弱造成的风险
2
3
3
系统风险
数据库脆弱性
3
因数据库脆弱造成的风险
2
2
3
网络服务脆弱性
2
因网络服务不规范、达不到SLA要求造成的风险
2
2
2
应急演练的风险
应急预案及演练
1
因应急预案不完善、应急演练达不到预定要求的风险
1
1
1
（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 应急事件关闭
65.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) 对于应急处置过程中，涉及具体排查诊断技术、处理恢复技术的情况，要求相关运维人员，对于实际操练过程中，多进行练习和摸索，在真实应急响应事件中，总结相关经验和不足，优化运维人员的技术级别和现场处理问题的准确性、高效性。
对于关闭阶段的应急事件，由服务台记录，相关人员进行归纳总结，完善过程中的细节，改进流程管控中的不足之处。

制定： 审核：
日期： 日期：