应急响应管理标准规范.docx

应急响应管理规范

历史修订统计
序号
更改单号
更改说明
修订人
生效日期
现行版次

目录
1. 总则 5
1.1 编制目标 5
1.2 适用范围 5
1.3 事件分级 5
1.3.1 影响度判定标准 5
1.3.2 紧急度度判定标准 5
1.3.3 判定优先级矩阵 5
1.3.4 等级判定标准 6
2. 组织机构和职责 6
2.1 企业内部组织 6
2.1.1 应急总责任人 6
2.1.2 应急指挥小组 6
2.1.3 应急工作小组 7
2.2 相关外部角色 7
3. 应急要素和体系 7
3.1 事件处理要素 7
3.1.1 管理层面 7
3.1.2 技术层面 8
3.1.3 事件归口 8
3.2 分级响应 8
3.3 指挥和协调 8
3.4 信息共享和处理 9
3.5 通讯 9
4. 运行机制 9
4.1 日常检测和预警 9
4.2 应急开启 9
4.3 事件汇报 10
4.4 应急调度 10
4.5 排查和诊疗 10
4.6 处理和恢复 10
4.7 事件升级 11
4.8 连续服务 11
4.9 应急事件关闭 11
4.9.1 申请 11
4.9.2 核实 11
4.9.3 事件通报 11
4.10 总结改善 12
4.10.1 应急工作总结 12
4.10.2 应急工作审核 12
5. 保障方法 13
5.1 通信保障 13
5.2 物资保障 13
5.3 技术保障 13
5.4 经费保障 13
5.5 人员保障 13
6. 宣传、培训和演练 13
6.1 宣传 13
6.2 培训 13
6.3 演练 14

1. 总则
1.1. 编制目标
确保用户业务运作所需基础架构和服务在突发事故发生后限定时间内能够得到恢复，确保用户业务运行和服务协议SLA达成。提升应对应急事件管理水平和应急处理能力，有效防范信息系统风险，降低信息系统故障对生产业务造成影响，确保信息系统运行连续性，特制订本预案。
1.2. 适用范围
本预案适适用于企业所承接运维项目范围内信息系统应急事件。
1.3. 事件分级
依据运维项目所包含事件分级考虑要素，将信息系统事件划分为三个等级：I级事件、II级事件、III级事件。
1.3.1. 影响度判定标准
等级
判定说明
一级
（重大）
关键系统设备或服务端软件系统瘫痪
二级
（严重）
关键系统设备或服务端软件系统故障
三级
（通常）
辅助子系统在运行过程中发生不影响关键业务系统使用或间接性故障
1.3.2. 紧急度判定标准
等级
判定说明
一级（危急）
A类用户申告故障影响度为一级
二级（紧急）
B类用户申告故障影响度为二级。
三级（通常）
C类用户申告故障影响度为三级
1.3.3. 判定优先级矩阵
影
响
度
优
先
级
紧
急
度

重大
严重
通常
危急
Ⅰ级
Ⅰ级
Ⅱ级
紧急
Ⅰ级
Ⅱ级
Ⅲ级
通常
Ⅱ级
Ⅲ级
Ⅲ级
1.3.4. 等级判定标准
等级
判定说明
Ⅰ级
因关键系统设备或服务端软件系统瘫痪，造成关键业务或整个业务系统功效丧失性故障（如：程控交换机瘫痪造成报警话务无法呼入、数据库瘫痪、关键服务程序故障、整个系统无法进行受理等）。
Ⅱ级
因关键系统设备或服务端软件系统故障，造成部分关键业务或整个业务系统功效间歇性不可用或数据丢失（如无法调派、警单无法保留、无录音、终端无法登陆等）。
Ⅲ级
辅助子系统在运行过程中发生不影响关键业务系统使用或间接性故障。
2. 组织机构和职责
2.1. 企业内部组织
企业成立应急处理领导小组、指挥小组、工作小组。
2.1.1. 应急总责任人
应急总责任人关键职责：
统一领导信息系统应急事件企业内部应急处理工作，提议研究重大应急决议和布署，决定实施和终止应急预案。
2.1.2. 应急指挥小组
应急指挥小组关键职责：
接收应急总责任人领导，传达和落实应急总责任人各项指令，汇总和上报应急信息，负责应急工作小组组员协调沟通，协调应急事件处理工作中重大问题。
2.1.3. 应急工作小组
应急工作小组关键职责：落实应急总责任人及应急指挥小组部署各项任务；组织制订应急预案，并监督实施情况；掌握应急事件处理情况，立即向应急总责任人和应急指挥小组汇报应急过程中重大问题。
角色
角色匹配
应急总责任人
系统运维事业部总经理(张湛)
应急指挥小组
运维服务部主管（罗建仁）、服务经理、运维客服主管（周矿喜）、运维技术支持部主管（王兴元）、销售主管（应丹红）
应急工作小组
运维团体
2.2. 相关外部角色
1） 服务需方应急响应责任人。
2） 供给商。
3） 分包方。
4） 供电部门
5） 网络通信运行部门
3. 应急要素和体系
3.1. 事件处理要素
3.1.1. 管理层面
(1) 开启指挥体系：
I级事件开启和指挥由应急总责任人负责；II、III级事件开启应急指挥小组负责。
(2) 掌握事件动态：
事件动态由应急工作小组人员搜集并立即反馈给应急指挥小组，应急指挥小组决定信息共享、沟通、处理。
(3) 处理实施
a) 控制事态预防蔓延。
b) 做好处理消除隐患。
(4) 后期处理：
事件调查汇报和经验教训总结及改善提议。
(5) 保障方法：
包含通讯和信息保障，应急支援和设备保障，技术贮备和保障，宣传、培训和演练，监督检验等。
3.1.2. 技术层面
信息系统事件发生后，事发部门应立即开启相关应急预案，实施处理并立即报送信息。
(1) 控制事态发展，防控蔓延。事发部门先期处理，采取多种技术方法，立即控制事态发展，最大程度地预防事件蔓延。
(2) 快速判定事件性质和危害程度。立即分析事件发生原因，依据信息系统运行和承载业务情况，初步判定事件影响、危害和可能包含范围，提出应对方法提议。
(3) 立即汇报信息。事发部门在先期处理同时要根据预案要求，立即向上级汇报事件信息。
(4) 做好事件发生、发展、处理统计和证据留存。
3.1.3. 事件归口
发生信息系统应急事件归口部门是应急体系开启责任部门。
3.2. 分级响应
发生I级事件，由应急工作小组初步判定事件等级后，将信息通知应急指挥小组并注意连续监控事态、搜集信息、做出应急准备；应急指挥小组响应判定为I级事件后，立即通知应急总责任人，并由应急总责任人开启应急预案。
发生II、III级事件，由应急工作小组初步判定事件等级后，将信息通知应急指挥小组并注意连续监控事态、搜集信息、做出应急准备；应急指挥小组响应判定为II、III级事件后，立即开启应急预案。
应急事件等级应置于动态调整控制中。
3.3. 指挥和协调
I级级事件，由应急工作小组搜集信息，应急指挥小组做出预判，并快速通知应急总责任人，由应急总责任人进行指挥和决议。
II、III级事件，由应急指挥小组进行指挥和决议，并立即将处理过程、汇报等上报应急总责任人。
3.4. 信息共享和处理
I级事件，由应急工作小组搜集信息并提交给应急指挥小组和应急总责任人，由应急总责任人决定信息分发、共享和处理。
II、III级事件，由应急指挥小组决定信息分发、共享和处理，并上报应急总责任人。
3.5. 通讯
应急响应小组和工作小组建立通信录，并二十四小时开通联络电话，保持通信顺畅。通信录应上报应急总责任人。
事件处理过程中值班人员必需拥有完整通信联络方法，并有足够通信手段确保联络顺畅。
4. 运行机制
4.1. 日常检测和预警
组织应该对运行维护服务对象运行情况进行监测和预警，以跟踪和判别以下对象容量、可用性和连续性：
a)应用系统；
b)支撑应用系统运行系统软件、工具软件；
c)网络及网络设备；
d)安全设备；
e)主机、存放、外设、终端等设备；
如发觉有异常情况时，要立即处理并向现场责任人汇报，并立即排除信息系统中存在风险隐患。
4.2. 应急开启
应急预案开启有以下两种方法：
1) 碰到I级事件，事件信息由应急工作小组提供并提交给应急指挥小组，应急指挥小组做出初步判定和初步事件等级确实定，初步确定为I级事件，呈报应急总责任人，由应急总责任人下达开启应急预案。
2) 碰到II、III级事件，应急指挥小组自行开启应急预案，并立即上报应急总责任人。
4.3. 事件汇报
当发觉各类信息系统事件时，应根据事件等级逐层汇报。
汇报分为紧急汇报和具体汇报。紧急汇报是指对应部门在事件发生后，立即向本部门应急指挥小组以口头（电话）和应急汇报表（书面）形式汇报事件简明情况；具体汇报是指由对应部门应急处理机构在事件处理暂告一段落后，以书面形式提交具体汇报。
应急指挥小组对各类事件影响进行初步判定，汇报矩阵以下：
事件等级
汇报时间要求
汇报对象
I
10分钟内
应急总责任人
II
30分钟内
应急总责任人
III
60分钟内
应急总责任人
汇报内容应正确、详实，任何部门和个人均不得缓报、瞒报、谎报或授意她人缓报、瞒报、谎报事件。
事件汇报信息通常包含以下要素：发生事件信息系统名称及业务部门、地点、原因、信息起源、事件类型及性质、危害和损失程度、影响部门及业务、事件发展趋势、采取处理方法等。
4.4. 应急调度
企业应该根据预案开展统一应急调度，包含人员、资金和设备等。应急调度由应急总责任人授权应急指挥小组实施。
4.5. 排查和诊疗
a)组织应明确故障排查和诊疗步骤；
排查和诊疗过程需在应急事件汇报进行统计。处理应急事件过程中，现场责任人应立即和相关利益方就排查、诊疗结果进行沟通和问题确定。
4.6. 处理和恢复
应急事件处理和恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复。必需时可启用备品备件、灾备系统等。在处理和恢复应急事件时,应在满足事件等级处理时间要求前提下，立即恢复服务。
事件等级处理时间要求以下：
事件等级
处理时间要求
I
4小时
II
6小时
III
8小时
4.7. 事件升级
当事件处理事件超出事件等级处理时间要求时，应急工作小组应考虑向应急指挥小组申请事件升级， 事件升级实施授权应由应急指挥小组责任人开启。应急指挥小组应对事件升级可能造成影响进行评定，并在相关利益方间达成一致。
4.8. 连续服务
完成处理和恢复后，应组织运行维护人员提供连续性服务。应急响应组织应对连续性服务效果进行评价。连续服务评价结果，应作为应急事件关闭输入。
I级应急事件应急处理结束后应亲密关注，监测系统2周，确定无异常现象。
II级应急事件应急处理结束后应亲密关注，监测系统1周，确定无异常现象。
III级应急事件应急处理结束后应亲密关注，监测系统3天，确定无异常现象。
4.9. 应急事件关闭
4.9.1. 申请
在同时满足下列条件下时，应急工作小组责任人可向应急指挥小组提出关闭申请。应急事件处理已经结束，设备、系统已经恢复运行；连续服务阶段系统无异常，连续服务阶段结束；服务需方应急响应责任人同意事件关闭；应急事件处理过程文档已整理完成。
4.9.2. 核实
应急指挥小组接到关闭申请后，应逐项核实汇报内容，以判别应急事件处理过程和结果信息是否属实以后通报应急总责任人，由应急总责任人做出关闭决定。
4.9.3. 事件通报
应急总责任人应授权应急指挥小组向相关利益方通报事件关闭信息，内容应包含：
a) 事件发生原因、事件等级及影响范围；
b) 事件对应预案；
c) 事件处理过程和方法；
d) 事件调整升级情况；
e) 连续性服务情况；
f) 事件处理评价；
g) 事件关闭申请处理意见；
h) 关闭通报范围和包含接收者。
4.10. 总结改善
4.10.1. 应急工作总结
组织应定时对应急响应工作进行分析和回顾，总结经验教训，并采取合适后续方法。对应急响应工作分析和回顾应考虑以下方面：
a）应急响应工作绩效；
b）应急准备工作充足性和有针对性；
c）应急事件发生原因、数量及频率；
d）应急事件处理经验得失；
e）应急事件趋势信息；
f）信息系统中潜在类似隐患。
对应急响应工作分析和回顾应形成应急响应工作总结汇报，并将总结汇报作为改善应急响应工作及信息系统关键依据。
4.10.2. 应急工作审核
应急总责任人应定时提议对应急响应工作评审，以确保应急响应过程和管理符合预定标准和要求。审核结果应该正式存档并通知给相关利益方。评审最少每十二个月一次，于企业内审时进行。
审核时应考虑要素包含：
1）相关利益方要求和反馈；
2）组织所采纳用于支持应急响应多种资源和步骤；
3）风险评定结果及可接收风险水平；
4）应急预案测试结果及实际实施效果；
5）上次评审后续活动跟踪；
6）可能影响应急响应多种业务变更；
7）近期在处理应急事件过程中总结经验和教训；
8）培训结果和反馈。
审核输出结果应该包含：
1）改善目标；
2）改善具体工作内容；
3）所需多种资源，包含人员、资金和设备等。
5. 保障方法
5.1. 通信保障
指挥、通信联络和信息交换渠道关键有外线电话、手机、传真、电子邮件等方法，相关应急联络人员手机应保持天天二十四小时处于开机状态。
5.2. 物资保障
系统运维事业部依据运维项目包含系统事件防治工作配置对应应急设施，以确保事件应急工作顺利进行，物资部提供给急物资所需要备品备件、常见工具等。
5.3. 技术保障
任何状态下，应提供充足技术保障，如网络拓扑图、服务器清单、网络设备配置、访问控制策略、应用系统和各类软件版本，并定时进行数据备份，以保障发生事件时，受影响信息系统能立即恢复。
重视信息系统事件体系建设、运维和升级换代，确保信息系统稳定和安全，确保在事件处理过程、系统恢复或重建过程中有足够技术支撑。
5.4. 经费保障
企业财务部保障应急培训、演练、添置应急物资等所需经费。
5.5. 人员保障
系统运维事业部加强信息系统应急事件应急技术支持队伍建设，提升部门人员业务素质、技术水平和应急处理能力。确保在事件处理过程和系统恢复或重建工作中人员在岗并含有一定战斗力。
6. 宣传、培训和演练
6.1. 宣传
系统运维事业部应加强应急工作宣传和教育，提升各级人员对应急预案关键性认识，加强各部门和部门之间协调和配合。
6.2. 培训
系统运维事业部包含系统应急预案包含到人员应定时开展应急预案培训，做好信息系统相关知识宣传和普及，增强各运维人员责任意识，熟练掌握应急响应程序和应急处理技能等内容。
6.3. 演练
系统运维事业部组织对运维承建项目标预案进行十二个月一次演练，经过演练验证预案合理性，立即修订和完善不符合实际应急处理情况，有针对性地改善信息系统应急事件处理能力，确保事件发生后应急处理手段立即到位和有效。
相关部门在做应急演练前要做好相关准备工作，确保演练工作安全。要明确演练目标和要求，统计演练过程，对演练结果进行评定和总结。