目 次
前 言
本部分由全国信息技术标准化技术委员会归口。
本部分起草单位：
本部分主要起草人：
引 言
运维服务是信息技术服务中一个新兴的领域，应急响应又是运维服务中的一个重要组成部分。针对突发公共事件，国家和地方政府出台了各项总体预案和专项预案，从整体或专业角度，对预防与应急准备、监测与预警、应急处置与救援、事后恢复与重建等方面进行了规定。但在信息技术运维服务领域，与之相对应的应急响应规范尚未建立起来，责任单位和服务单位往往凭借自身熟悉的技术经验和借鉴个别案例进行规划实施，这种做法往往不符合应急响应的实际要求，存在片面性，对技术、资金盲目追求和投入，缺乏运维服务标准流程和技术手段，资源无法整合，应急响应运维服务达不到应有效果。
为了更好的保障信息化投资效益，避免无序运维，提升应急状态下运维服务响应能力，提前发现和解决问题，降低突发事件造成的不良影响，以合理的投入创造更大的效益，在做运维服务应急响应工作时，无论是规划方、业主单位、服务单位，都希望有一个”运维服务应急响应规范”，从适用范围、应急响应运维服务流程、技术手段、管理措施等方面都能作为一个指导和参考，让更多的运维服务从一开始就有规范可循，准备工作充分，各环节衔接合理，应急处置到位迅捷，能力持续改善。
信息化发展至今，很多单位都积累了丰富的运维服务应急响应经验。将这些宝贵的经验重新融合起来，取长补短，进行规范化、标准化，制定成一个适合该领域需要的标准，这对促进信息技术的运用和发展，规范信息系统工程的建设行为具有重要的意义。
在这个意义上，它可以确保本部分适用于所有组织，无论大型组织，还是小型组织，而不论组织的目的、规划和股东结构。
本部分旨在为参与设计和实施运维服务中应急响应的管理体系方针、流程和结构的人员提供信息和指南。
信息技术服务 运行维护 第3部分：应急响应规范
1 范围
本部分规定了信息技术运维服务中应急响应的四个主要环节，如图1所示。
图1 运维服务应急响应过程
本部分规定了每个主要环节的实施要求和管理要求。
本部分适用于所有组织，包括公众和私有公司、政府组织和非赢利组织。本部分也适用于从小型到大型不同规模的组织，而不论其对IT利用的程度。
本部分目标是通过以下方式，促进所有组织有效、高效和合理的应对可能出现的应急事件，并不断提升组织的应急响应能力：
-
使各方组织对信息技术运维服务应急响应基本过程和要求达成一致；
-
为信息技术运维服务应急响应体系的规划、建设、实施、评估等提供参考和依据；
-
为服务提供方提供最佳实践参考和服务衡量标准。
本部分中包含的目标和要求并不详尽，组织应根据自己的实际情况进行补充和完善，以
满足特定应急响应的运维服务要求。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分。然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。
ISO/IEC 20000-1:2005 信息技术—服务管理－第1部分：规范
ISO/IEC 20000-2:2005 信息技术—服务管理－第2部分：实施指南
ISO/IEC 27001:2005 信息技术 安全技术 信息安全管理体系要求
GB/T ××××.1—×××× 信息技术服务 运行维护 第1部分：通用要求
GB/T ××××.2—×××× 信息技术服务 运行维护 第2部分：安全要求
GB/T ××××.3—×××× 信息技术服务 运行维护 第3部分：数据中心规范
3 术语和定义
下列术语和定义适用于本部分。
3.1信息化设施（Information facilities）
支撑办公及业务活动的各类信息化软硬件资产及环境。
3.2重点时段保障 （key time protection）
需要提升服务等级，以确保某一时间段内重要活动或重点业务的开展所采取的措施和行为。
3.3运维服务应急事件（Operation and maintenance emergency events）
导致或即将导致信息化设施运行中断或运行质量降低或需要实施重点时段保障的事件。
3.4应急响应（Emergency response）
组织为预防、监控、处置和管理运维服务应急事件所采取的措施和行为。
4应急准备
4.1应急管理方针与应急管理组织
4.1.1 目的
确保组建合适的组织以满足日常运维和应急响应的服务要求。
4.1.2应急管理方针
应急管理方针包括：
a)组织及相关利益方应就应急响应的方针达成一致；
b)应急响应方针应该包括组织进行应急响应的目标、原则、范围；
c)应该按照计划好的时间间隔对应急响应方针进行评审。当业务环境发生重大变化时也需要对应急管理方针进行调整。
4.1.3应急管理组织建立
应急管理组织应具备：
a）应策划和组建运维服务组织，运维服务组织应由所有相关方面组成，如服务需求方、服务提供方、分包方、供应商等；
b）应急响应组织应在运维服务组织基础上建立，参与应急响应的组织及组织内人员应确保属于提供运维服务的组织及人员，必要时也包括专家顾问及其他机构和人员；
c）应就运维服务及其应急响应服务的范围、要求、等级及沟通过程接口与相关方达成一致，并书面记录；
d）应清楚规定运维服务及应急响应所有各相关方面的角色及关系；
e）组织内对应角色的人员应有多个备份计划；
f）运维过程中涉及组织及人员的角色及关系的变更应与其他相关方达成一致，并书面记录；
g）应建立对组织的重要评审过程。评审至少每年进行一次，以确保仍能继续满足运维服务和应急响应要求。
4.2风险评估与改进
4.2.1目的
系统性识别运维服务对象及运维活动中可能出现的风险并提前改进。
4.2.2风险识别与评估
在风险识别与评估中，组织应做到：
-
应按照一个确定的方法和流程来实施风险评估，确保组织理解其在运维过程中的关键活动、所需资源、限制条件及组织面临的各种威胁。
-
应理解当威胁演变为应急事件时所产生的影响和后果，以及业务中断所可能带来的损失。
-
应授权组织内或组织外的服务提供方进行风险识别，并将授权通知到所有相关方面。
-
被授权的服务提供方应结合具体的现状和要求，独立或与相关方面共同提出风险要素。
-
风险要素应从系统级的角度考虑，如运维对象、运维服务内容、组织及流程接口等。
-
应根据风险要素进行评估，评估可采用一种或多种方法相结合的方式，如定性评估、定量评估、基于知识的评估、基于模型的评估等。
其中，分析评估后应形成报告，报告应包括：
1）与服务水平目标相比较的运维要求；
2）现状及趋势信息；
3）风险要素；
4）不符合项及问题；
5）据此提供的管理决策和纠正措施建议。
评估报告应在服务需求方授权的范围内进行评审和沟通，并达成一致。
确认后的评估报告应作为风险应对和预案制定的信息输入。
4.2.3 风险应对
对于识别出的各种风险，组织应该制定明确的应对策略。可供选择的风险策略包括：风险规避、风险转嫁、风险降低、风险接受。
根据风险评估报告，组织应该形成改进方案以降低风险，可选择的方案包括：
a) 降低风险转变为应急事件的可能性；
b）缩短应急事件的持续时间；
c）限制应急事件的影响范围。
4.3应急事件级别划分
应急事件分级的主要参考要素为：信息系统的重要程度、紧急程度、系统损失和社会影响。相关责任人应按照以上要素对可能发生的事件进行评估，确定应急事件的级别。
建议应急事件划分为四级：灾难事件（Ⅰ级）、重大事件（Ⅱ级）、严重事件（Ⅲ级）和一般事件（Ⅳ级）。下文给出了四级事件的概要描述，供组织对事件定级时参考：
灾难事件：由于地震、火灾、恐怖袭击等原因造成主要IT设施毁灭性损坏，或者由于系统平台或业务数据遭受严重破坏，无法在短时间内恢复系统服务，造成核心业务服务中断超过48小时。
重大事件：造成核心业务服务中断超过24小时，或重要业务数据丢失，或业务数据需要后退到上一备份状态。
严重事件：造成核心业务服务中断超过12小时，或少量业务数据丢失。
一般事件：造成核心业务服务中断超过4小时，或管理支撑系统服务中断超过24小时。
4.4预案制定
4.4.1目的
提供应对运维服务应急事件的操作性文件。
4.4.2预案制定与评审
应根据风险评估和事件级别划分制定应急预案，预案可以分为总体预案和针对某个核心系统的专项预案及其附则。
预案中应该考虑到各种应急资源的调配和预置。应急资源主要包括人员、备品备件、资金、系统工具等。
预案的格式应该能够为运维服务应急响应人员进行系统恢复操作提供快速明确的指导。
预案应该明确、简洁，易于在紧急情况下执行，并尽量使用检查列表和详细规程。
应急响应预案的内容应包括：
a) 应急响应预案的编制目的、依据和适用范围；
b）具体的组织体系结构及人员职责；
c）应急响应的监测和预警机制；
d）应急响应的启动；
e）应急响应的处置；
f）应急响应的总结 ；
g）应急响应的保障措施；
h）应急预案的附则。
4.4.3预案发布
经过评审确认的应急响应预案，应由责任者或授权管理者负责预案的分发。
应确认应急响应参与工作的所有人员都接受预案。
应建立预案的版本控制。
4.5培训与演练
4.5.1方法与手段
应急响应演练的目的，一是为了验证预案是否能够真正满足实际的需求，二是为了检验应急响应小组成员之间的相互配合默契程度和对运维事件应对步骤的熟练程度。
演练的方式分为：工具测试演练；场景模拟演练。
4.5.2培训
培训的要求包括：
a）应制定应急响应培训计划，并组织相关人员参与。应急响应预案应作为培训的主要内容。
b）培训应使得相关组织及人员明确其在应急响应过程中的责任范围、接口关系，明确应急处置的操作规范和操作流程。
c）培训至少每年举办一次。
4.5.3演练
为了检验预案的有效性，同时使相关人员了解运维预案的目标和流程，熟悉应急响应的操作规程，组织应按以下要求，组织应急响应的演练：
a）预先制定演练计划，在计划中说明测试工具或演练的场景；
b）演练的整个过程应有详细的记录，并形成报告；
c）演练不能对业务运行造成负面影响；
d）按照与最终用户的约定周期，进行有最终用户（或被委托的第三方机构）参与的完整演练。周期建议可以设定为季度、一年或三年。
5监测与预警
5.1日常监测与预警
5.1.1目的
保障运维服务的可用性和连续性，及时发现运维服务应急事件并有效预警。
5.1.2范围
日常监测和预警的范围包括：
a）应该对信息化设施的运行情况进行监测与预警，以跟踪和判别以下对象的容量、可用性和连续性：
1）应用系统；
2）支撑应用系统运行的系统软件、工具软件；
3）网络及网络设备；
4）安全设备；
5）主机、存储、外设、视频会议、桌面等设备；
6）电力、空调、消防等基础环境。
b）应该对信息化设施支撑的业务数据进行监测与预警，以跟踪和判别业务数据是否超出了预警条件。
5.1.3手段与工具
服务提供方应结合运维服务级别协议和应急响应预案，开展日常监测与预警活动，包括：
a) 设立服务台并保持运营；
b）确定监测项、监测时间间隔与阈值；
c）确定活动中的人员、角色和职责。
服务提供方可以采用运维工具与人工相结合的方式开展日常监测与预警活动。
5.1.4记录与报告
所有方面应建立监测、预警的信息登记和报告制度。
服务提供方应对日常监测的结果进行记录，并按照约定的形式和时间间隔报告给上级责任者。
服务提供方发现运维服务应急事件时，应提交单独的报告，报告内容应包括：
a）故障或预警发生及发现的时间和地点；
b）表象及影响的范围；
c）原因初步分析；
d）报告人。
报告应第一时间提交给上级责任者。报告方式包括电话、邮件、短信或书面报告等，并确认上级责任者收到报告。
应该对运维服务应急事件保持持续性跟踪。
5.2核实与评估
5.2.1目的
对出现的运维服务应急事件进行有效识别。
5.2.2核实
核实应做到：
a）接到报告的责任者应对报告内容进行逐项核实，以判别运维服务应急事件是否属实。
b）核实确认后的应急事件报告，应作为事件级别评估的输入。
c）重点时段保障需求，也应作为事件级别评估的输入。
5.2.3事件级别评估
责任人应参见应急准备活动中的事件级别划分，确定应急事件所对应的事件级别。
应将事件级别置于动态调整控制中。
5.3预案启动
5.3.1 目的
确保以规定的策略和程序启动预案，并保持对应急事件的跟踪。
5.3.2预案启动
预案启动应做到：
a）建立、审议预案启动的策略和程序，以控制预案启动的授权和实施。
b）就预案启动可能造成的影响进行评估。应在相关方之间就启动何种类型预案达成一致。过程应包括一旦事件升级，与之相对应的预案调整的方式。
c）预案应由明确的责任者或授权管理者启动。
d）记录预案启动的过程和结果。
f）重点时段保障应启动的预案可参考同级别预案确定。
5.3.3信息通报
预案启动的责任者或授权管理者应向服务提供方和其他相关方通报信息，内容应包括：
a）预案启动的原因；
b）事件级别；
c）事件对应的预案；
d）要求采取的技术应对或处置的目标；
e）实现目标所应采取的保障措施，如人员、物资、环境、资金等；
f）对应急处置过程及结果的报告要求，如报告程序、报告内容、报告频率等；
g）信息通报的范围和接收者。
信息通报的方式如电话、邮件、电视、广播、文件等。
通报信息应作为调整监测与预警状态及后续活动的输入，后续活动包括应急处置、总结改进等。
所有相关方应对收到的通报信息进行确认和反馈。
5.3.4监测与预警状态的调整
在监测与预警状态的调整中，供方应：
a）根据调整后的状态开展监测与预警活动，并按一致约定的程序和监测范围、监测频率提供报告。
b）监测与预警状态的调整应通知各相关方。
6应急处置
6.1应急调度
明确应急调度手段，规范应急调度过程整体及归档。
在各级责任者调度安排下，实施应急处置。各级责任者根据应急处置要求，对应急处置经费、应急处置人员、应急处置设施等统一调配和管理，并完成调度明细说明的整理和归档。
应急调度中的工作流程应包含以下内容：
- 在规定时间要求内，迅速组织人员勘察、分析；
- 通过网络、媒体、广播等多种手段快速获取应急事件的相关信息；
- 及时组织并协调相关部门及人员召开应急处置工作会议；
- 根据应急处置要求，对涉及应急处置组织下达调度命令；
- 组织人员保护可追查的相关线索。
应对调度过程记录进行整理、归档。
6.2排查与诊断
6.2.1目的
基于启动的预案，开展排查与诊断。
6.2.2手段工具
在排查与诊断中，应建立多渠道的应急处置支持模式，如：建立由服务商、供应商、生产制造商构成的应急处置支持模式。
故障排查与诊断的流程应包含以下内容：
- 应急处置责任者调配处置人员进行现场故障排查；
- 现场处置人员进行故障排查和诊断，必要时可寻求外协人员以现场或远程方式进行支持，在此过程中可借助各类排查诊断分析工具，如：应用软件、电子分析工具、故障排查知识库等；
- 现场处置人员应随时向处置责任者汇报故障排查情况、诊断信息、故障定位结果等；
- 将排查与诊断的过程与结果信息进行整理与归档。
6.2.3问题沟通与确认
在问题的沟通与确认中，应做到：
a）在实施应急处置过程中，各级责任者应及时与相关利益方进行沟通，沟通的内容主要包括应急处置故障点、造成故障的原因、排查诊断等。
b）应及时完成对沟通信息及对应组织人员的核实与确认，同时对确认信息完成归档、上报、审批等事项。
c）应将问题沟通结果与确认信息告知相关利益方。
6.3处理与恢复
对故障进行有效、快速的处理与恢复。
应基于预案和知识库进行故障的处理与恢复，处理与恢复的原则包括：
- 应在满足相应服务级别协议要求的前提下，尽快恢复服务；
- 采用的方法、手段不应造成新的事件发生。
必要时可启用备品备件、灾备系统等。
应该对过程及结果信息进行记录，并及时告知相关方面及人员。
责任者应组织对处理与恢复的结果进行初步确认。
6.4升级与信息通报
6.4.1目的
通过实施有效评审，实现对应急处置的升级与通报。
6.4.2处置过程及结果的评审
故障处置责任者应组织相关人员对故障处置过程及结果情况进行评审。
在评审中，应参考服务级别协议中对事件处置内容情况的设定，同时结合应急故障处置的现场情况进行分析和比较。
当应急故障现场处置的情况超过原应急预案中的事件处置级别要求时，应作为应急事件升级的输入。
6.4.3升级
在升级中，组织应做到：
- 在规定时间要求内，迅速组织人员勘察、分析；
-
建立、审议应急事件升级的策略和程序，以控制应急事件升级的授权和实施。
-
就事件应急事件升级可能造成的影响进行评估。应在应急处置涉及组织单位之间就确认事件升级达成一致。
-
升级过程应包含预案调整、人员调整、资金调整以及相关设施调整。
-
应急事件升级的实施授权应由明确的责任者或授权管理者启动。
-
对应急事件升级的过程和结果信息进行整理与归档。
6.4.4信息通报
应急事件升级的责任者或授权管理者应向服务提供方和其他相关方通报信息，内容应包括：
- 事件升级的原因；
- 事件升级后的级别；
- 事件升级后与之对应的预案；
- 根据升级事件处置的要求和目标，确定所需的技术应对措施；
- 实现目标所应采取的保障措施，如：人员、物资、环境、资金等；
- 对升级事件处置过程及结果的报告要求，如：报告程序、报告对象、报告内容、报告频率等；
- 信息通报的范围和涉及接受者。
信息通报的方式如电话、邮件、电视、广播、文件等形式。
通报信息应作为应急事件故障处置恢复的输入。
6.5持续服务与评价
为应急故障处置提供持续性服务保障，并完成对故障处置结果的评价。包括：
a）在完成对应急事件故障处置后，应组织运维人员提供持续性服务。
b）应对持续性服务的效果进行评价。
c）故障处置责任者应对已完成的故障处置和持续性服务阶段的运行状态，做出自评报告。
d）在相关方之间就持续性服务与评价报告达成一致的前提下，由明确的责任者或授权管理者提出应急事件关闭需求。
e）持续服务的评价结果，应作为应急事件关闭的输入。
6.6事件关闭
6.6.1 目的
规范并明确应急处置的关闭流程。
6.6.2 申请
在申请事件关闭前，应做到：
a）建立、审议事件关闭的策略和程序，以控制事件关闭的授权和实施。
b）该对应急事件处置的过程文档和各评审/评价报告进行整理。
c）由明确的责任者或授权管理者提出事件关闭申请，并提交相关文档资料。
d）应急事件关闭申请和文档资料，应作为事件关闭核实的输入。
6.6.3 核实
接到事件关闭申请的责任者应逐项核实报告内容，以判别应急事件处置过程和结果信息是否属实。
核实后的应急事件关闭申请报告，应作为事件关闭通报的输入。
6.6.4关闭通报
应建立、审议应急事件关闭通报制度。
应急事件关闭的责任者或授权管理者应向相关利益方通报信息，内容应包括：
- 应急事件的级别；
- 事件对应的预案信息；
- 应急事件处置的过程情况；
- 事件的调整升级情况；
- 持续性服务状况信息；
- 事件处置评价信息；
- 事件关闭申请的处理意见；
-
关闭通报的范围和涉及接受者。
7总结改进
7.1应急事件总结
7.1.1 对事件的总结
在事件关闭之后，应组织相关人员对本次事件的原因、处理过程和结果进行分析，总结经验教训，并采取必要的后续措施。事件总结应该包含：
a）事件发生的原因分析；
b）应急事件的处理过程和结果；
c）评估应急事件造成的影响；
d）降低事件发生频率、减轻损害和避免再次发生的方法。
7.1.2 调查和收证
当一个事件涉及到责任认定、赔偿或诉讼时，应收集、保留和呈递证据。证据可能用于：
a）内部问题分析；
b）用作有关可能违反合同或规章要求的法律取证；
c）与供应商或其他组织谈判赔偿事宜。
7.2应急体系的保持
7.2.1 总则
为保证应急体系的有效性和时效性，需要对应急体系进行不定期及定期的维护和审核，以确保组织具有足够的应急响应能力。
体系维护主要是指当组织战略、业务流程、客户要求等发生重大变化的时候，对现有的应急体系，尤其是风险评估和应急预案进行修改。体系维护应该是不定期进行的，是由事件驱动的。
体系审核主要是指对组织当前的应急响应能力和管理模式进行评审，以确保它们符合预定的标准和要求，同时明确组织在应急响应方面的主要不足和改进方向。体系审核应该是定期进行的，组织应该至少一年进行一次体系审核。
7.2.2体系维护
组织应该建立起一个明确的应急体系维护计划。此维护计划应该确保任何影响到组织应 急管理的重大变更都能被识别出来，同时采取必要的措施对这些变更进行分析，并对应急管理体系做出相应调整，这种调整可能涉及应急管理的方针策略、流程、应急预案和资源配置。
体系维护流程的结果应该包括：
a）关于应急体系维护活动的文档记录；
b）确保应急响应的相关人员都已经明确应急体系的调整内容，并接受必要的培训；
c）当需要对风险评估、组织架构、人员配备进行调整时，保留必要的文档记录。
7.2.3体系审核
相关责任者应该按照预定的时间间隔对应急管理体系进行审核，以确保体系具有持续的适用性和有效性。体系审核应该包括评估体系不足和改进建议。体系审核的结果应该正式存档并通知给相关责任者。
a）体系审核的输入信息应该包括：
1）相关利益方的要求和反馈；
2）组织所采纳的用于支持应急响应的各种技术、产品和流程；
3）风险评估的结果及可接受的风险水平；
4）应急预案的测试结果及实际执行效果；
5）上次体系评审的后续跟踪活动；
6）可能影响应急体系的各种业务变更；
7）近期在处置应急事件过程中的总结经验和教训；
8）培训的结果和反馈。
b）体系审核的输出结果应该包括：
1）应急体系的改进目标；
1）如何改进应急体系的有效性和效率；
2）所需的各种资源，包括人员、软硬件、资金等。
7.3应急准备工作的改进
应急事件总结、体系维护和体系审核的结果应该作为应急准备阶段的重要输入信息。组织应根据应急事件总结报告中给出的建议项和体系评审结果来调整应急准备和风险应对的策略。
附录A
（资料性附录）
规范的使用
运维服务应急响应过程包括应急准备、监测与预警、应急处置和总结改进四个主要环节，每个环节中包括若干重点任务，这些任务覆盖了日常工作、故障响应和重点时段保障等不同类型的活动。下表描述了不同类型活动与重点任务的基本对应关系。
表1 日常工作、故障响应、重点时段保障与任务的对应关系表
主要环节
重点任务
日常工作
故障响应
重点时段保障
应急准备
运维组织建立
√
风险评估与改进
√
事件级别划分
√
预案制定
√
培训与演练
√
监测与预警
日常监测与预警
√
√
核实与评估
√
√
预案启动
√
√
应急处置
应急调度
√
√
排查与诊断
√
处理与恢复
√
升级与信息通报
持续服务与评价
√
√
事件关闭
√
√
总结改进
事件总结
√
√
应急准备工作的保持
√
√
√
应急管理体系的改进
√
√
- 事件升级的原因；
