GB T 28827.3-2012 信息技术服务.运行维护.第3部分：应急响应规范.pdf

1、ICS 35.080 L77 西昌中华人民-=H二/、和国国家标准G/T 28827.3-2012 信息技术服务运行维护第3部分:应急晌应规范Information technology service一Operationand maintenance一Part 3: Emergency response specification 2012-11-05发布2013-02-01实施d;fE均在/飞JEJ码防伪中华人民共和国国家质量监督检验检茂总局中国国家标准化管理委员会发布GB/T 28827.3-2012 目次前言.皿引言. lV I 范围-2 规范性引用文件-3 术语和定义4 应急响应过程

2、概述5 应急准备26 监测与预警.4 7 应急处置68 总结改进.8 附录A(资料性附录)应急事件级别划分指南.10 附录B(资料性附录)应急响应各阶段工作内容与日常工作、故障响应、重点时段保障等不同类型活动的对应关系12参考文献.13 I GB/T 28827.3一-2012目。吕GB/T 28827(信息技术服务运行维护分为6个部分:一-第1部分:通用要求;一一第2部分:交付规范;一一第3部分:应急响应规范;一一一第4部分:数据中心服务规范;一一第5部分:桌面及外围设备服务规范;一第6部分:应用系统服务规范。本部分为GB/T28827的第3部分。本部分按照GB/T1. 1-2009给出的规

3、则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由全国信息技术标准化技术委员会CSAC/TC28)提出并归口。本部分起草单位z太极计算机股份有限公司、山东浪潮齐鲁软件产业股份有限公司、东软集团股份有限公司、中国电子技术标准化研究院、神州数码系统集成服务有限公司、北京信城通数码科技有限公司、成都勤智数码科技有限公司、武汉太阳花网络安全维护有限公司、成都信息化技术应用发展中心、万达信息股份有限公司。本部分主要起草人:范凯、张帆、潘纯峰、马英皑、陈强、王志鹏、白璐、李娜、刘玲、王春涛、陈涛、杨凯楠、顾峻。皿GB/T 28827.3-2012 引随着各行业、

4、各领域信息化工作的深入开展，越来越多的信息系统进入运行维护阶段。然而，提供运行维护服务的各类组织的能力水平参差不齐，需方缺乏评价或选择供方的方法、手段及规范。GB/T 28827(信息技术服务运行维护规定了提供信息技术运行维护服务的组织应具备的能力、服务交付形式和内容，以及运行维护服务中的应急响应过程和管理方法等。各部分之间的关系如图1所示。工作内容进行了描述。本部分的第5章规定了应急准备阶段的工作要求。本部分的第6章规定了监测与预警阶段的工作要求。本部分的第7章规定了应急处置阶段的工作要求。本部分的第8章规定了总结改进阶段的工作要求。本部分的附录A给出了应急事件级别划分要素和定级步骤。本部分

5、的附录B给出了应急响应各阶段的工作内容与日常工作、故障响应、重点时段保障等不同类型活动的对应关系。N GB/T 28827.3-2012 1 范围信息技术服务运行维护第3部分:应急晌应规范GB/T 28827的本部分规定了应急响应过程的基本活动和任务。本部分适用于指导在经济建设、社会管理、公共服务以及生产经营等领域重要信息系统运行维护中实施和管理应急响应。本部分也适用于组织为满足应急响应实施需要而开展的信息系统完善和升级改造工作。本部分不适用于电信基础设施和电信业务系统的运行维护。2 规范性引用文件下列文件对于本文件的应用是必不可少的，凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注

6、日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB/T 28827.1-2012信息技术服务运行维护第1部分:通用要求3 术语和定义GB/T 28827.1-2012中界定的以及下列术语和定义适用于本文件。3. 1 重点时段保障important period assurance 提升服务级别以确保某一时间段内重要活动或重点业务的开展所采取的措施和活动。3.2 应急事件emergency event 导致或即将导致运行维护服务对象运行中断、运行质量降低，以及需要实施重点时段保障的事件。3.3 应急晌应emergency response 组织为预防、监控、处置和管理应急事件所采取

7、的措施和活动。4 应急晌应过程概述4. 1 应急晌应过程的阶段划分本部分将运行维护服务中应急响应过程划分为4个主要阶段:应急准备、监测与预警、应急处置和总结改进。如图2所示。i应?准备卜寸监测与预警卜寸应急处置卡士兰兰图2运行维护服务应急晌应过程1 GB/T 28827.3-2012 4.2 应急晌应各阶段的工作内容应急响应各阶段的工作内容如下:a) 应急准备阶段的工作包括:组建应急响应组织，确定应急响应制度，系统性识别运行维护服务对象及运行维护活动中可能出现的风险，定义应急事件级别，制定预案，开展培训11和演练;b) 监测与预警阶段的工作包括:进行日常监测，及时发现应急事件并有效预警，进行核

8、实和评估，以规定的策略和程序启动预案，并保持对应急事件的跟踪;c) 应急处置阶段的工作包括:采取必要的应急调度手段，基于预案开展故障排查与诊断，对故障进行有效、快速的处理与系统恢复，及时通报应急事件，提供持续性服务保障，进行结果评价，关闭事件;进应A业阶段，从运行维护嘛和姗两个角度开展监测预警。在应急处置阶段，根据业务教据啡情况采取相应措注:应急响应/在阶层的工矿内容与日常工作、故障响应、重点时段保障等不同类型活边的叫5 应急准备/ 。值班人员:组织内承担现场值守工作的人员;c) 应就应急响应服务的范围、要求等与相关利益方达成一致，确定沟通流程和方式，并形成记录;d) 运行维护过程中涉及组织和

9、人员的变更应与相关利益方达成一致，并形成记录;e) 应建立对应急响应组织内人员的考核机制，明确考核指标及方法。考核至少每年进行一次，以确保组织能持续满足应急响应要求。5.2 制定应急晌应制度组织应制定应急响应制度，明确应急响应的目标、原则、范围以及各项管理制度，并要求:a) 与相关利益方就应急响应制度达成一致;b) 定期对应急响应制度进行评审;c) 在组织战略、业务流程、客户要求等发生重大变化时对应急响应制度进行调整。2 GB/T 28827.3-2012 5.3 风险评估与改进5.3. 1 凤险评估组织应按照确定的方法和流程对重要信息系统实施风险评估，确保组织了解其在运行维护过程中的关键活动

10、、所需资源、限制条件及信息系统面临的各种风险要素。组织应了解当风险演变为应急事件时所产生的影响和后果，以及信息系统服务中断所带来的损失。组织应授权组织内或组织外的服务供方进行风险识别，并将授权通知到所有相关利益方。被授权的服务供方应结合具体的信息系统现状和要求，从技术和管理等方面确定风险要素。应对风险要素进行评估，形成风险评估报告，报告内容应包括:a) 结论摘要;b) 背景及现状;c) 风险要素;d) 识别出的风险及风险分析;e) 建议的应对措施。应在需方授权范围内对风险评估报告进行评审和沟通，并达成一致。5.3.2 改进对于识别出的各种风险，组织应该制定明确的控制策略，必要时应对信息系统进行

11、升级改造。可供选择的风险控制策略包括:风险规避、风险转移、风险降低、风险接受。根据风险评估报告，组织应该形成改进方案并实施，以利于:a) 降低风险转变为应急事件的可能性;b) 缩短应急事件的持续时间;c) 限制应急事件的影响范围。5.4 划分应急事件级别5.4.1 参考要素应急事件分级的主要参考要素为:信息系统的重要程度、信息系统服务时段、信息系统受损程度。a) 重要程度重要程度主要应考虑信息系统所支撑的业务的重要性，以及信息系统内信息资产的重要性和信息系统服务的重要性。b) 服务时段服务时段主要应考虑应急事件发生时系统提供服务的状态。c) 受损程度受损程度主要应考虑应急事件发生时信息系统功能

12、和性能等方面的影响程度。5.4.2 级别划分组织可按照5.4.1中的要素对可能发生的应急事件进行级别划分(级别划分方法见附录A)。组织应结合自身的业务要求，对应急事件级别对应的响应时间、处置完成时间等达成一致。组织应根据应急事件级别配置响应的保障措施，如人员、资金和设备等。5.5 应急晌应预案制定5.5.1 预案制定与评审组织应根据应急事件级别制定应急响应预案。3 GB/T 28827.3-2012 应急响应预案可以分为总体预案和针对某个核心系统的专项预案。应急响应预案的格式应该能够为应急响应组织进行系统恢复操作提供快速明确的指导。应急响应预案应该明确、简洁，易于在紧急情况下执行，并使用检查列

13、表。应急响应预案的内容应包括:a) 应急响应预案的编制目的、依据和适用范围zb) 具体的组织体系结构及人员职责;c) 应急响应的监测和预警机制;d) 应急响应预案的启动;e) 应急事件级别及对应的处置流程、方法;f) 应急响应的保障措施;g) 应急预案的附则。服务需方应组织对应急响应预案进行评审，并与相关利益方达成一致。5.5.2 预案发布经过评审确认的应急响应预案，应由应急响应责任者负责发布。应急响应预案应进行版本控制。5.6 培训与演练5.6. 1 培训组织应制定应急响应培训计划，并组织相关人员参与。应急响应预案应作为培训的主要内容。培训应使得组织及人员明确其在应急响应过程中的责任范围、接

14、口关系，明确应急处置的操作规范和操作流程。培训应至少每年举办一次。5.6.2 演练为检验应急响应预案的有效性，同时使相关人员了解运行维护预案的目标和内容，熟悉应急响应的操作规程，组织应进行应急演练，应:a) 预先制定演练计划、演练脚本;b) 演练的整个过程应有详细的记录，并形成报告;c) 演练不能影响业务的正常运行。为提升应急响应能力，组织可采用元脚本演练。必要时，组织可根据演练的效果，对应急响应预案进行完善。6 监测与预警6. 1 日常监测与预警6. 1. 1 范围4 组织应持续开展日常监测活动，实施有效预瞥，范围如下za) 组织应该对运行维护服务对象的运行情况进行监测与预誓，以跟踪和判别以

15、下对象的容量、可用性和连续性21) 应用系统;2) 支撑应用系统运行的系统软件、工具软件;G/T 28827.3-2012 3) 网络及网络设备50 安全设备;5) 主机、存储、外设、终端等设备;6) 电力、空调、消防等基础环境。b) 组织应对信息系统所承载的业务数据进行监测，以跟踪和判别业务数据是否超出了预警条件。6. 1. 2 手段与工具组织应结合运行维护服务级别协议和应急响应预案，开展日常监测与预警活动，包括:a) 设立服务台并保持运营;b) 建立知识库并保持更新;c) 确定监测项、监测时间间隔与阔值;d) 确定活动中的人员、角色和职责。组织可以采用运行维护工具与人工相结合的方式开展日常

16、监测与预警活动。6.1.3 记录与报告组织应建立监测、预警的记录和报告制度，并按照约定的形式和时间间隔上报现场负责人。发现应急事件时，值班人员应提交报告，报告内容应包括:a) 应急事件发生及发现的时间、位置;b) 现象描述;c) 影响的范围;d) 初步原因分析;e) 报告人。报告应及时提交给现场负责人。报告方式包括电话、邮件、传真或书面文件等，并确认对方收到报告。值班人员应采取必要措施，开展应急事件的先期处置，以提高应急响应效率，避免次生、衍生事件的发生。应该对应急事件保持持续性跟踪。6.2 核实与评估6.2.1 核实现场负责人应对报告内容进行逐项核实。核实确认后的应急事件报告，应提交给应急响

17、应责任者。应急事件报告应作为事件级别评估的输入。重点时段保障需求也应作为事件级别评估的输入。6.2.2 事件级别评估现场负责人应根据事件级别定义，初步确定应急事件所对应的事件级别。应将事件级别置于动态调整控制中。6.3 应急晌应预案启动6.3.1 预案启动组织应建立、审议应急响应预案启动的策略和程序，以控制预案启动的授权和实施。5 G/T 28827.3-2012 组织应就应急响应预案启动可能造成的影响进行评估。相关利益方之间应就启动何种类型预案达成一致，包括当事件升级时，与之相对应的预案调整的方式。可根据先期处置要求进行应急响应预案的自动启动，或由应急响应责任者或现场负责人启动预案。应记录应

18、急响应预案启动的过程和结果。重点时段保障应启动的应急响应预案可参考同级别预案确定。6.3.2 信息通报现场负责人应向相关利益方通报应急响应预案启动信息，内容应包括:a) 预案启动的原因;b) 事件级别zc) 事件对应的预案;d) 要求采取的技术应对措施或处置的目标;巳)实现目标所应采取的保障措施，如人员、资金和设备等;。对应急处置过程及结果的报告要求，如报告程序、报告内容、报告频率等Eg) 信息通报的范围和接收者。信息通报应选取适当的方式，如电话、邮件、传真、书面文件等。所有相关利益方应对收到的通报信息进行确认和反馈。6.3.3 监测与预警状态的调整通报信息应作为监测与预警状态调整的输入，调整

19、内容包括监测范围、监测频率等。监测与预警状态的调整应通知各相关利益方。7 应急处置7. 1 应急调度按照预案，开展统一的应急调度，包括人员、资金和设备等。应急调度中应:a) 获取现场信息;b) 组织必要人员进行勘察、分析;c) 下达调度命令并保持眼踪;d) 保护可追查的相关线索。7.2 排查与诊断7.2.1 基本流程6 故障排查与诊断的流程应包含以下内容za) 现场负责人调度处置人员进行现场故障排查;b) 现场处置人员进行故障排查和诊断，必要时可寻求组织其他人员以现场或远程方式进行支持，在此过程中可借助各类排查诊断分析工具，如应用软件、电子分析工具、故障排查知识库等;c) 现场处置人员应随时向

20、现场负责人汇报故障排查情况、诊断信息、故障定位结果等;d) 将排查与诊断的过程与结果信息进行整理与归档。GB/T 28827.3-2012 7.2.2 问题沟通与确认处置过程中，现场负责人应及时与相关利益方进行沟通，沟通的内容主要包括系统故障点、造成故障的原因、排查诊断状况等。现场负责人应组织相关利益方对问题进行确认。问题确认过程不应延误处理与恢复工作的开展。7.3 处理与恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复，处理与恢复的原则包括:a) 应在满足事件级别处置时阁要求的前提下，尽快恢复B坠务;11 / 现场负责人应组织处理与恢复的结果进行初步确认。/ / 7.4

21、 事件升级.4. 1 升纽飞飞方。飞组织应建立、审议应急事件升级的策略和程序，以控制应急事件升级的授权和实施。i/、，-_t!o.r )._ L: 当实际处置时间超过事件级别处置时间要求时，Jl作为事件升级的参考要素。L ,._. . _, . ,_ 组织应该对事件升级可能造成的影响进行评估，并在相关利益方之间达成一致。升级内容应包含预案调整、人员调整、资金调整以及设备调整。、J事件升级的实施授权应由现场负责人启动。/ / 应该对事件奸级的过程和结果信息进行整理与归档。7.4.2 信息通报,J 、/现场负责人应向a事件b) 事件c) 事件对升级事件处置拉姆刺在告要求，如报告程序布告荐信息通报的

22、范围和涉及的接受者。二三:/信息通报应选择适当的方式，如电话、邮件、传真、书面文件等形式。事件升级信息应作为处理与恢复的参考要素。7.5 持续服务完成处理与恢复后，应组织运行维护人员提供持续性服务。组织应对持续性服务的效果进行评价。持续服务的评价结果，应作为应急事件关闭的输入。7.6 事件关闭7.6.1 申请组织应建立、审议事件关闭的策略和程序，以控制事件关闭的授权和实施。7 GB/T 28827.3-2012 应该对应急事件处置的过程文档进行整理。事件关闭申请应由相关的分组负责人提出，并提交相关文档资料。事件关闭申请和文档资料，应作为事件关闭核实的参考要素。7.6.2 核实现场负责人接到事件

23、关闭申请后，应逐项核实报告内容，以判别应急事件处置过程和结果信息是否属实。7.6.3 调查和取证当应急事件涉及到责任认定、赔偿或诉讼时，应收集、保留和呈递证据。证据可能用于za) 内部问题分析;b) 用作合同违约或其他纠纷的法律取证;c) 与相关方谈判赔偿事宜。7.6.4 关闭通报组织应建立、审议应急事件关闭通报制度。现场负责人应向相关利益方通报事件关闭信息，内容应包括:a) 事件发生的原因、事件级别及影响范围;b) 事件对应的预案;c) 事件的处置过程和方法Fd) 事件的调整升级情况zd 持续性服务情况;f) 事件处置评价;g) 事件关闭申请的处理意见;h) 关闭通报的范围和涉及接受者。应急

24、事件发生的原因、处置过程和方法应记入知识库。8 总结改进8.1 应急工作总结组织应定期对应急响应工作进行分析和回顾，总结经验教训，并采取适当的后续措施。对应急响应工作的分析和回顾应考虑以下方面:a) 应急响应工作的绩效;b) 应急准备工作的充分性和有针对性;c) 应急事件发生原因、数量及频率;d) 应急事件处置的经验得失;e) 应急事件的趋势信息;f) 信息系统中潜在的类似隐患。对应急响应工作的分析和回顾应形成总结报告，并将总结报告作为改进应急响应工作及信息系统的重要依据。8.2 应急工作审核为保证应急响应的有效性和时效性，应急响应责任者应定期组织对应急响应工作的评审，以确保应8 GB/T 2

25、8827.3-2012 急响应过程和管理符合预定的标准和要求。审核的结果应该正式存档并通知给相关利益方。评审应至少每年举行一次。a) 审核时应考虑的要素包括:1) 相关利益方的要求和反馈;2) 组织所采纳的用于支持应急响应的各种资源和流程;3) 风险评估的结果及可接受的风险水平;4) 应急预案的测试结果及实际执行效果;5) 上次评审的后续活动跟踪;的可能影响应急响应的各种业务变更;7) 近期在处置应急事件过程中总结的经验和教训18) 培训的结果和反锣卡-) 审核的输出结果应该包括f1) 改进民莎fj乒乒/2) 改进的具体作内容;3)忡忡源，包括/8.3应 应急事件总结、应急工作审核的结果应该作

26、为应急准备阶段各项工作的改进要素与组织应根据总结报告中给出的建议项和评审结果，完善信息系统，深化应急准备工作。 - / / / / / 导飞飞/ 9 GB/T 28827.3-2012 附录A(资料性附录)应急事件级别划分指南A.1 参考要素的赋值应急事件分级的主要参考要素为:信息系统的重要程度、信息系统服务时段、信息系统受损程度。a) 信息系统的重要性由以下要素决定:1) 信息系统所属类型，即信息系统资产的安全利益主体。2) 信息系统主要处理的业务信息类别。3) 信息系统服务范围，包括服务对象和服务网络覆盖范围。业务对信息系统的依赖程度。其中第1)、2)个要素决定信息系统内信息资产的重要性，

27、第3)、的个要素决定信息系统所提供服务的重要性，而信息资产及信息系统服务的重要性决定了信息系统的重要性。信息系统的重要程度划分为4级，对应赋值14。由其在经济建设、社会管理、公共服务以及生产经营中的重要程度决定。其划分方法参见GBjT22240-2008。b) 信息系统服务时段划分为3级。依据应急事件发生的不同时间，对信息系统恢复正常服务所需的时间要求而确定，具体划分方法见表A.1。表A.1信息系统服务时段赋值表赋值描述1 非系统服务时段(不含系统服务时段即将开始2 系统服务时段或系统服务时段即将开始3 系统处于重点时段保障或处于服务高峰时段c) 应急事件造成的信息系统损失程度划分为3级。依据

28、故障发生对信息系统提供的服务能力的下降程度而确定，具体划分方法见表A.2。表A.2信息系统损失程度赋值表系统功能系统性能功能元损部分损失全部损失小于阂值1 3 大于或等于阂值1 2 3 注:重点时段保障的损失程度赋值为3。A.2 事件定级步骤首先为应急事件的3个定级要素赋值，然后将3个要素赋值相乘，得到应急事件具体分值E。其范围在136。建议将分值在16区间的定义为三级事件，分值在818区间的定义为二级事件，分值10 GB/T 28827.3-2012 在2436区间的定义为一级事件。级别定义步骤如图A.l所示。1.赋值2.计算应急事件分值H3.定义应急事件级别三级:1三三rI运6，二级:8

29、三rI18，一级:26三三月运36图A.1应急事件级别定义步骤11 GB/T 28827.3-2012 附录B(资料性附录)应急晌应各阶段工作内容与日常工作、故障晌应、重点时段保障等不同类型活动的对应关系运行维护服务应急响应过程包括应急准备、监测与预警、应急处置和总结改进4个主要阶段，每个阶段中包括若干工作内容，这些工作内容覆盖了日常工作、故障响应和重点时段保障等不同类型的活动。表B.l描述了不同类型活动与工作内容的基本对应关系。表B.1 应急晌应各阶段工作内容与日常工作、故障晌应、重点时段保障等不同类型活动的对应关系主要阶段工作内容日常工作故障响应重点时段保障建立应急响应组织、/制定应急响应

30、制度、J风险评估与改进、/应急准备划分应急事件级别J 预案制定J 、J培训与演练、/、J日常监测与预警、/、/、J监测与预警核实与评估、/、/预案启动J 、/应急调度、/J 排查与诊断、/处理与恢复、/应急处置事件升级J 、/持续服务、/、J事件关闭、/、/应急工作总结、/、J总结改进应急工作审核、/J 应急工作改进、JJ 、/12 G/T 28827.3-2012 参考文献lJ GB/T 19000-2008 质量管理体系基础和术语2J GB/T 22080-2008 信息技术安全技术信息安全管理体系要求3J GB/T 22240-2008 信息安全技术信息系统安全等级保护定级指南4J GB

31、/T 22239-2008 信息安全技术信息系统安全等级保护基本要求5J GB/T 25058-2010 信息安全技术信息系统安全等级保护实施指南6J GB/T 24405. 1-2009 信息技术服务管理第1部分:规范7J GB/T 24405. 2-2010 信息技术服务管理第2部分:实践规则8J ITIL Version 3 Service Stra tegy 9J ITIL Version 3 Service Design -10J ITIL Version 3 Service Transition 11J ITIL Version 3 Service Operation 12J IT

32、IL Version 3 Service Improvement -. NFQN!i问.hNNH阁。. . d 国华人民共和国家标准信息技术服务运行维护第3部分:应急晌应规范GB/T 28827.3-2012 由l,_ . 当&中国标准出版社出版发行北京市朝阳区和平里西街甲2号(100013)北京市西城区三里河北街16号(100045)网址总编室:(010)64275323发行中心:(010)51780235读者服务部:(010)68523946中国标准出版社秦皇岛印刷厂印刷各地新华书店经销4陪印张1.25 字数29千字2013年3月第一次印刷开本880X12301/16 2013年3月第一版 书号:155066 1-46193 21. 00元如有印装差错由本社发行中心调换版权专有侵权必究举报电话:(010)68510107定价GB/T 28827.3-2012 打印日期:2013年3月28日F002A