搜索
ICS35.080L77中华人民共和国国家标准GB/T×××××4—××××信息技术服务运行维护第3部分：应急响应规范Informationtechnologyservice-Operationandmaintenance-Part4：Specificationforemergencyresponse（征求意见稿：2009-12-1）××××-××-××发布××××-××-××实施中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会发布GB/T×××××—××××I目次前言....................................................................II引言....................................................................II1范围......................................................................12规范性引用文件.............................................................13术语和定义.................................................................14应急准备...................................................................25监测与预警.................................................................46应急处置...................................................................67总结改进...................................................................8附录A（资料性附录）规范的使用............................................11GB/T×××××—××××I前言本部分由全国信息技术标准化技术委员会归口。本部分起草单位：本部分主要起草人：GB/T×××××—××××II引言运维服务是信息技术服务中一个新兴的领域，应急响应又是运维服务中的一个重要组成部分。针对突发公共事件，国家和地方政府出台了各项总体预案和专项预案，从整体或专业角度，对预防与应急准备、监测与预警、应急处置与救援、事后恢复与重建等方面进行了规定。但在信息技术运维服务领域，与之相对应的应急响应规范尚未建立起来，责任单位和服务单位往往凭借自身熟悉的技术经验和借鉴个别案例进行规划实施，这种做法往往不符合应急响应的实际要求，存在片面性，对技术、资金盲目追求和投入，缺乏运维服务标准流程和技术手段，资源无法整合，应急响应运维服务达不到应有效果。为了更好的保障信息化投资效益，避免无序运维，提升应急状态下运维服务响应能力，提前发现和解决问题，降低突发事件造成的不良影响，以合理的投入创造更大的效益，在做运维服务应急响应工作时，无论是规划方、业主单位、服务单位，都希望有一个“运维服务应急响应规范”，从适用范围、应急响应运维服务流程、技术手段、管理措施等方面都能作为一个指导和参考，让更多的运维服务从一开始就有规范可循，准备工作充分，各环节衔接合理，应急处置到位迅捷，能力持续改善。信息化发展至今，很多单位都积累了丰富的运维服务应急响应经验。将这些宝贵的经验重新融合起来，取长补短，进行规范化、标准化，制定成一个适合该领域需要的标准，这对促进信息技术的运用和发展，规范信息系统工程的建设行为具有重要的意义。在这个意义上，它可以确保本部分适用于所有组织，无论大型组织，还是小型组织，而不论组织的目的、规划和股东结构。本部分旨在为参与设计和实施运维服务中应急响应的管理体系方针、流程和结构的人员提供信息和指南。GB/T×××××—××××1信息技术服务运行维护第3部分：应急响应规范1范围本部分规定了信息技术运维服务中应急响应的四个主要环节，如图1所示。图1运维服务应急响应过程本部分规定了每个主要环节的实施要求和管理要求。本部分适用于所有组织，包括公众和私有公司、政府组织和非赢利组织。本部分也适用于从小型到大型不同规模的组织，而不论其对IT利用的程度。本部分目标是通过以下方式，促进所有组织有效、高效和合理的应对可能出现的应急事件，并不断提升组织的应急响应能力：a)使各方组织对信息技术运维服务应急响应基本过程和要求达成一致；b)为信息技术运维服务应急响应体系的规划、建设、实施、评估等提供参考和依据；c)为服务提供方提供最佳实践参考和服务衡量标准。本部分中包含的目标和要求并不详尽，组织应根据自己的实际情况进行补充和完善，以满足特定应急响应的运维服务要求。2规范性引用文件下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分。然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。ISO/IEC20000-1:2005信息技术—服务管理－第1部分：规范ISO/IEC20000-2:2005信息技术—服务管理－第2部分：实施指南ISO/IEC27001:2005信息技术安全技术信息安全管理体系要求GB/T××××.1—××××信息技术服务运行维护第1部分：通用要求GB/T××××.2—××××信息技术服务运行维护第2部分：安全要求GB/T××××.3—××××信息技术服务运行维护第3部分：数据中心规范3术语和定义下列术语和定义适用于本部分。3.1信息化设施（Informationfacilities）支撑办公及业务活动的各类信息化软硬件资产及环境。3.2重点时段保障（keytimeprotection）GB/T×××××—××××2需要提升服务等级，以确保某一时间段内重要活动或重点业务的开展所采取的措施和行为。3.3运维服务应急事件（Operationandmaintenanceemergencyevents）导致或即将导致信息化设施运行中断或运行质量降低或需要实施重点时段保障的事件。3.4应急响应（Emergencyresponse）组织为预防、监控、处置和管理运维服务应急事件所采取的措施和行为。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风险识别与评估在风险识别与评估中，组织应做到：a）应按照一个确定的方法和流程来实施风险评估，确保组织理解其在运维过程中的关键活动、所需资源、限制条件及组织面临的各种威胁。b）应理解当威胁演变为应急事件时所产生的影响和后果，以及业务中断所可能带来的损失。c）应授权组织内或组织外的服务提供方进行风险识别，并将授权通知到所有相关方面。d）被授权的服务提供方应结合具体的现状和要求，独立或与相关方面共同提出风险要素。GB/T×××××—××××3e）风险要素应从系统级的角度考虑，如运维对象、运维服务内容、组织及流程接口等。f）应根据风险要素进行评估，评估可采用一种或多种方法相结合的方式，如定性评估、定量评估、基于知识的评估、基于模型的评估等。其中，分析评估后应形成报告，报告应包括：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)应急响应预案的编制目的、依据和适用范围；GB/T×××××—××××4b）具体的组织体系结构及人员职责；c）应急响应的监测和预警机制；d）应急响应的启动；e）应急响应的处置；f）应急响应的总结；g）应急响应的保障措施；h）应急预案的附则。4.4.3预案发布经过评审确认的应急响应预案，应由责任者或授权管理者负责预案的分发。应确认应急响应参与工作的所有人员都接受预案。应建立预案的版本控制。4.5培训与演练4.5.1方法与手段应急响应演练的目的，一是为了验证预案是否能够真正满足实际的需求，二是为了检验应急响应小组成员之间的相互配合默契程度和对运维事件应对步骤的熟练程度。演练的方式分为：工具测试演练；场景模拟演练。4.5.2培训培训的要求包括：a）应制定应急响应培训计划，并组织相关人员参与。应急响应预案应作为培训的主要内容。b）培训应使得相关组织及人员明确其在应急响应过程中的责任范围、接口关系，明确应急处置的操作规范和操作流程。c）培训至少每年举办一次。4.5.3演练为了检验预案的有效性，同时使相关人员了解运维预案的目标和流程，熟悉应急响应的