运维服务应急响应管理规范模板Word格式文档下载.docx
《运维服务应急响应管理规范模板Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《运维服务应急响应管理规范模板Word格式文档下载.docx（14页珍藏版）》请在冰点文库上搜索。
运维工程师、客户指定的联系人、营销部门主管客户业务的销售经理、营销中心、服务分包方、设备供应商为应急响应组织的成员。
运维工程师负责应急预案的编制、修订、演练，突发事件的现场处置；
销售人员负责协助完成服务客户的需求分析，配合完成应急响应预案的实施；
营销中心负责配合完成应急预案的成本预算支持及相关分包商、设备提供商的资源协调；
服务分包商负责配合完成与其相关的应急响应预案的可行性分析和制定，配合应急预案实施；
设备供应商负责配合相关设备的技术支持、设备供给，配合完成应急响应预案实施；
客户指定联系人，负责配合应急事件发生时现场协调及实施，配合完成应急响应预案制定。
3.应急响应制度管理原则
3.1应急响应制度定期评审
在组织战略、业务流程、需方要求等发生重大变化时对应急响应制度进行调整，由运维中心发起，每年至少对应急响应制度进行一次评审，并与相关利益方就应急响应制度达成一致。
3.2应急预案定期演练及培训
由运维中心负责组织，进行应急预案、法律法规、避险、自救、互救、减灾等常识的培训，增强员工的忧患意识、社会责任意识和自救、互救能力。
提高其应急专业技能，并保存培训记录。
3.3突发事故应急处置奖惩
突发事故应急处置工作实行责任追究制对突发事故应急管理工作中做出突出贡献的先进集体和个人要给予表彰和奖励。
对迟报、谎报和瞒报突发事故重要情况或者应急管理工作中有其它失职、渎职行为，造成人员伤亡或重大经济损失的，对有关责任人给予处罚或行政处分。
4.风险评估
应急响应小组每年对重要信息系统进行一次风险评估，并根据风险评估结果来制定或更新应急预案。
风险评估值如下：
等级
极高
高
中
低
赋值
4
3
2
1
概率
4.1系统重要性评估
描述
将对客户造成极严重的或灾难性的损失
将对客户造成较重要的损失
将对客户造成一定损失
将对客户造成有限损失
根据上表对信息系统以及相关外部环境进行重要性评估。
4.2影响度评估
影响度描述
核心业务全面中断；
影响大面积用户正常使用；
部分核心业务中断；
影响一定范围内用户的正常使用；
单一业务中断；
影响个别用户正常使用；
根据上表对信息系统以及相关外部环境进行影响度评估。
4.3发生几率评估
可能性取值
可能性描述（威胁发生的频率）
可能每个月发生一次或者以上
可能每季度会发生一次
可能每半年发生一次或更少
可能每年发生一次或更少
根据上表对风险发生几率进行评估。
4.4发生时段评估
时段程度描述
核心业务并发高峰期；
核心业务关键程序执行期；
部分核心业务并发高峰期；
部分核心程序执行期；
非核心业务并发期；
非核心程序执行期；
4.5风险等级评估
按照重要性、影响度、发生几率赋值相乘，得出信息系统以及相关环境的风险等级。
等级描述如下：
可能性
影响度
重要性
6
9
8
12
18
7
16
24
风险值＝重要性×
风险发生可能性×
风险发生的严重性
风险等级
风险值n
高（H）
n>
=12
中（M）
12>
低（L）
n<
=4
4.6进行风险评估
按照风险等级评估，列出信息系统以及相关外部环境，描述可能发生的风险，针对每一个风险制定控制措施，并明确相应责任人，形成《风险评估表》，撰写风险评估报告。
5.制定项目预案
5.1应急需求分析
运维中心在启动项目运维服务后，要对项目做应急需求分析，确定项目范围及应急响应需求。
按次维护的项目不考虑应急响应。
5.2制定项目应急预案
运维中心在项目启动完成后五个工作日内建立《应急响应预案》，应急预案具有针对性，实用性和可操作性，应急对策简练实用。
6.应急预案演练
运维中心要结合实际，有计划、有重点地组织对相关预案的演练。
每年至少进行一次，并作好演练过程的原始记录。
演练不通过应针对存在问题重新进行预案编制和审核，由运维中心进行审核直至预案通过。
7.应急预案的风险评估
由运维中心至少每年对应急方案的适应范围进行一次识别，对存在的风险进行分析，并做好风险评估记录。
8.应急响应级别
按照突发事件的影响范围、业务重要度两个维度对应急响应级别进行分级：
突发事件级别
影响范围
业务重要度
I级
特别重大
照明系统发生灾害类事件，导致系统损毁
II级
重大
与系统有关的内外场软硬件或其它突发事件引起的局部故障，导致超过半数以上的无信息显示
较大
与子系统有关的内外场软硬件或其它突发事件引起的局部故障
III级
一般
单点设备故障
9.应急响应处置
9.1应急响应的启动
运维服务相关人员在发现或受理突发应急事件后，根据事件影响范围、业务重要度判断响应级别，启动应急响应处置操作。
I级事件主管副总现场指挥处置。
II级事件运维中心主任现场指挥处置。
III级事件运维项目部经理现场指挥处置。
9.2立即处置原则
运维服务相关人员在发现或受理突发应急事件后，需第一时间出发、着手处理故障，争取一切时间尽快处理事件，可暂缓登记、录入等流程信息。
针对具体发生的突发事件和突发故障，我公司将以尽快恢复系统基本功能和基本业务为目标，启动快速应对处置流程：
1）我公司将合理安排，采用人防、技防等多种手段，在8小时之内发现设施故障并发出故障报警；
2）在接到事件（故障）报警后，我公司将在故障响应时间要求规定的时间内作出响应，同时通知业主，并派遣处置人员快速到达故障现场，处置人员在到达现场后须立即向业主报告，并在发现故障原因后通知业主；
3）应急处置人员在对故障分析的基础上，按照预案规定，以恢复基本功能为目标进行快速应对处置作业，并在故障响应时间要求规定的时间内完成快速应对处置作业，恢复系统基本功能；
4）应急处置人员对快速应对处置的过程如实记录，记录内容包括故障现象描述、故障原因分析、处置方案、处置过程、参与抢修人员名单以及各个时间节点数据等；
5）快速应对处置过程由业主进行监督，记录过程数据，包括时间特征数据和故障排除、基本功能恢复的过程数据记录，并对故障设施的基本功能恢复进行确认。
6）业主单位在发生Ⅱ级（重大）以上安全事件时，必须到达现场参与事故分析、讨论处置方案、监督处置过程，对Ⅲ级（较大）以下故障一般采用事后检查的方式进行管理。
9.3现场处置原则
运维工程师必须现场处置,其他人员按照事件级别由现场指挥人员指挥调配。
I级事件二线运维工程师现场处置。
II级、III级事件一线运维工程师现场处置。
9.4应急响应事件汇报
9.4.1汇报原则
9.4.1.1立即汇报原则
运维人员发现问题10分钟内完成汇报
9.4.1.2逐级汇报原则
运维人员应将应急事件发生时的情况首先向所属部门经理汇报。
9.4.1.3可越级汇报情况
直接上级电话连续3次无法接通，可越级汇报。
9.4.1.4汇报信息内容
汇报信息包括突发事故的类别、地点、起始时间、可能影响范围、故障级别、计划采取的措施等。
9.4.2汇报链条
I级别：
汇报链条：
运维工程师——运维项目部经理——运维中心主任（现场指挥）——公司分管副总经理——公司总经理
II级别：
运维工程师——运维项目部经理——运维中心主任（现场指挥）——公司分管副总经理
III级别：
运维工程师——运维项目部经理——运维中心主任（现场指挥）
9.5应急处置优先级排序
I级、II级、III级
9.6应急响应结束
突发事故应急处置完毕后，运维项目部经理需向客户提交《应急响应处理报告》，将应急事件发生的情况向客户及公司分管副总经理进行汇报。
相关危险因素消除后，现场应急指挥机构予以撤销，宣布恢复正常工作。
在完成快速应对处置的基础上，启动后续规范处理流程，按业主管理制度要求落实规范处理的方案编制并实施方案，提交故障报告和工作量及费用清单报批，并做好后续资料归档管理工作等。
快速应对处置完成后，根据突发故障的不同情况：
1）如需进行工程性后续规范处理的：
a）我公司将在对故障分析的基础上，按照现场实际情况，制订后续规范处理的技术方案报业主审核后，报业主审批；
2）我公司将按批准的方案实施，参照专项整治项目原则进行管理；
业主对实施过程进行监督和管理；
b）实施完毕，故障设施完全恢复后，业主组织针对性验收测试，包括对关联系统或局部系统的功能测试、性能测试，在测试合格后组织验收。
3）根据应急事件处置过程和处置内容，我公司将编制应急事件处置工作量列表和费用决算，业主负责对处置工作量和费用决算进行审核，报业主审批。
4）我公司将按照应急抢修过程记录和故障分析，编制应急抢修处置工作总结报告，包括处置过程描述、成因分析、自我评价、进一步工作建议和预防建议等内容。
5）应急抢修处理完毕后，Ⅱ级（重大）以上安全事件由业主组织我公司及其他关联方进行故障分析，并编制应急抢修处置监理总结报告，包括处置过程描述、处置过程考评意见、验收测试说明、改进建议、今后的预防措施等。
6）如有需要，按技术档案管理要求，做好技术文档的整理、归档工作。
10.运行机制
10.1日常监测和预警
组织应该对运行维护服务对象的运行情况进行监测与预警，以跟踪和判别以下对象的容量、可用性和连续性。
1）应用系统；
2）支撑应用系统运行的系统软件、工具软件；
3）网络及网络设备；
4）安全设备；
5）主机、存储、外设、终端等设备；
6）安防、会议等智能化设备。
如发现有异常情况时，要及时处理并向现场负责人报告，并及时排除信息系统中存在的风险隐患。
10.2应急启动
应急预案的启动有以下两种方式：
1）遇到I级事件，事件信息由应急工作小组提供并提交给应急负责人，应急负责人做出判断，确认为I级事件后启动应急预案。
2）遇到II、III级事件，应急指挥小组自行启动应急预案，并及时上报应急负责人。
10.3事件报告
当发现各类信息系统事件时，应按照事件等级逐级汇报。
报告分为紧急报告和详细汇报。
紧急报告是指运维中心运维部在事件发生后，立即向应急工作小组以口头和应急报告表形式汇报事件的简要情况；
详细汇报是指由运维中心运维部在事件处理暂告一段落后，以书面形式提交的详细报告。
应急指挥小组对各类事件的影响进行初步判断，汇报矩阵如下：
事件级别
报告事件要求
报告对象
I
10分钟内
负责人
II
30分钟内
III
60分钟内
报告内容应准确、详实，任何部门和个人均不得缓报、瞒报、谎报或者授意他人缓报、瞒报、谎报事件。
事件报告信息一般包括以下要素：
发生事件的信息系统名称及业务部门、地点、原因、信息来源、事件类型及性质、危害和损失程度、影响部门及业务、事件发展趋势、采取的处置措施等。
10.4应急调度
公司应该按照预案开展统一的应急调度，包括人员、资金和设备等。
应急调度由应急负责人授权应急小组执行。
10.5排查和诊断
组织应明确故障排查和诊断流程；
应急事件的排查与诊断流程参考《事件与服务请求过程》，排查与诊断过程需在《应急事件报告》进行记录。
处置应急事件的过程中，现场负责人应及时与相关利益方就排查、诊断结果进行沟通和问题确认。
10.6处理和恢复
应急事件的处理与恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复。
必要时可启用备品备件、灾备系统等。
应急事件的处置与恢复流程参考《事件与服务请求过程》，处理与恢复过程需在《应急事件报告》进行记录，并及时告知利益相关方。
在处理和恢复应急事件时,应在满足事件级别处置时间要求的前提下，尽快恢复服务。
事件级别处置时间要求如下：
处置时间要求
2小时
4小时
6小时
10.7事件升级
当事件处置超过事件级别处置时间要求时，应急工作小组应向应急负责人申请事件升级，递交《应急事件升级审批表》。
事件升级的实施授权应由应急负责人启动。
10.8持续服务
完成处理与恢复后，应急小组组织运行维护人员提供持续性服务。
应急响应组织应对持续性服务的效果进行评价。
持续服务的评价结果，应作为应急事件关闭的输入。
I级应急事件应急处理结束后应密切关注，监测系统2周，确认无异常现象。
II级应急事件应急处理结束后应密切关注，监测系统1周，确认无异常现象。
III级应急事件应急处理结束后应密切关注，监测系统3天，确认无异常现象。
10.9应急事件关闭
10.9.1申请
在同时满足下列条件下时，应急工作小组申请关闭。
1）应急事件处理已经结束，设备、系统已经恢复运行。
2）持续服务阶段系统无异常，持续服务阶段结束。
3）服务需方应急响应负责人同意事件关闭。
4）应急事件处置的过程文档已整理完成。
10.9.2核实
应急小组负责人接到关闭申请后，应逐项核实报告内容，以判别应急事件处置过程和结果信息是否属实之后做出关闭决定。
10.9.3应急工作总结
应急小组应定期对应急响应工作进行分析和回顾，总结经验教训，并采取适当的后续措施。
对应急响应工作的分析和回顾应考虑以下方面：
1）应急响应工作的绩效；
2）应急准备工作的充分性和有针对性；
3）应急事件发生原因、数量及频率；
4）应急事件处置的经验得失；
5）应急事件的趋势信息；
6）信息系统中潜在的类似隐患。
对应急响应工作的分析和回顾应形成《应急响应工作总结报告》，并将总结报告作为改进应急响应工作及信息系统的重要依据。
10.9.4应急工作审核
应急负责人应定期发起对应急响应工作的评审，以确保应急响应过程和管理符合预定的标准和要求。
审核的结果应该正式存档并通知给相关利益方。
评审至少每年一次，可于公司内审时进行。
1）审核时应考虑的要素包括：
2）相关利益方的要求和反馈；
3）组织所采纳的用于支持应急响应的各种资源和流程；
4）风险评估的结果及可接受的风险水平；
5）应急预案的测试结果及实际执行效果；
上次评审的后续活动跟踪；
6）可能影响应急响应的各种业务变更；
7）近期在处置应急事件过程中总结的经验和教训；
8）培训的结果和反馈。
审核的输出结果应该包括：
a）改进目标；
b）改进的具体工作内容；
c）所需的各种资源，包括人员、资金和设备等。
11.总结评估
应急事件处理完成后，运维中心主任应组织召开专题分析会，对本次事件的起因、影响、责任、经验教训和恢复重建等问题进行调查、评估和分析。
通过对应急事件深层次原因的分析，及时修正和改进应急响应制度及预案。
升级会员 