信息技术服务运行维护第3部分应急响应规范复习课程.doc

《信息技术服务运行维护第3部分应急响应规范复习课程.doc》由会员分享，可在线阅读，更多相关《信息技术服务运行维护第3部分应急响应规范复习课程.doc（22页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Good is good, but better carries it.精益求精，善益求善。信息技术服务运行维护第3部分应急响应规范-ICS35.080L77SJ中华人民共和国电子行业标准SJ/TXXXXX.320XX信息技术服务运行维护第3部分：应急响应规范InformationtechnologyserviceOperationsandmaintenancePart3：EmergencyresponsespecificationXXXX-XX-XX发布XXXX-XX-XX实施中华人民共和国工业和信息化部发布SJ/T.3目次前言.II引言.III1范围.12规范性引用文件.13术语和定义.1

2、4应急响应过程概述.14.1应急响应过程的阶段划分.14.2应急响应各阶段的工作内容.15应急准备.25.1建立应急响应组织.25.2制定应急响应制度.25.3风险评估与改进.25.4划分应急事件级别.35.5预案制定.35.6培训与演练.36监测与预警.46.1日常监测与预警.46.2核实与评估.56.3预案启动.57应急处置.57.1应急调度.57.2排查与诊断.57.3处理与恢复.67.4事件升级.67.5持续服务.67.6事件关闭.68总结改进.78.1应急事件总结.78.2应急体系的保持.78.3应急工作的改进.8附录A（资料性附录）应急事件级别划分指南.9A.1参考要素的赋值.9A

3、.2事件定级步骤.9附录B（资料性附录）应急响应规范的使用.11参考文献.12SJ/T.32.1前言SJ/T信息技术服务运行维护分为六个部分：第1部分：通用要求；第2部分：交付规范；第3部分：应急响应规范；第4部分：数据中心服务规范；第5部分：桌面及外围设备服务规范；第6部分：应用系统服务规范。本部分为SJ/TXXXXX的第3部分。本部分按照GB/T1.12009给出的规则起草。本部分的附录A和附录B是资料性附录。本部分由中华人民共和国工业和信息化部软件服务业司提出。本部分由中国电子技术标准化研究所归口。本部分起草单位：本部分主要起草人：SJ/T.32.2引言随着各行业、各领域信息化工作的深入

4、开展，越来越多的重要信息系统进入运维阶段。运维工作一方面是要保障信息系统安全、可靠和高效运行，另一方面是要提供信息以支撑业务工作的开展。同时，也应该注意到，随着运维项目增多，运维范围不断扩大，运维内容持续深化，信息系统出现应急事件的可能性也将逐步提高。目前，一些信息化发展比较成熟的行业如金融、电信等，都开展和不断完善应急响应的相关工作。但就信息技术服务整个领域来说，如何应对运行维护中的应急事件，应遵循的基本过程和管理方法有哪些，以及其中的主要活动和内容有哪些等，还缺乏必要的规范指导。SJ/TXXXXX的本部分提出了应急响应的基本过程，以及过程管理要求，旨在提升组织的应急响应能力，提前发现隐患，

5、及时解决问题，降低应急事件可能带来的不良影响。本部分与突发事件应对所涉及的领域是有区别的。一般来说，前者主要涉及信息技术服务领域；而后者主要涉及自然灾害、事故灾难、公共卫生事件和社会安全事件等突发事件应对的业务领域。本部分不涉及信息系统的建设，但在信息系统运维阶段，通过应急响应的实施，可以反馈系统使用效果，并根据业务发展不断进行系统适应性调整，用以指导信息系统完善和升级改造工作的开展。SJ/T.3信息技术服务运行维护第3部分：应急响应规范1范围SJ/TXXXXX的本部分规定了应急响应的基本过程和管理方法，包括应急准备、监测与预警、应急处置和总结改进等内容。本部分适用于指导在经济建设、社会管理、

6、公共服务以及生产经营等领域重要信息系统运行维护服务中的应急响应实施和管理。本部分同样适用于组织为满足应急响应实施需要而开展的信息系统完善和升级改造工作。2规范性引用文件下列文件对于本文件的应用是必不可少的，凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。SJ/T.1信息技术服务运行维护第1部分:通用要求GB/T22240-2008信息安全技术信息系统安全等级保护定级指南3术语和定义SJ/T.1确立的以及下列术语和定义适用于本部分。3.1重点时段保障importantperiodassurance提升服务级别以确保某一时间段内

7、重要活动或重点业务的开展所采取的措施和行为。3.2应急事件emergencyevent导致或即将导致运行维护服务对象运行中断、运行质量降低，以及需要实施重点时段保障的事件。3.3应急响应emergencyresponse组织为预防、监控、处置和管理应急事件所采取的措施和活动。4应急响应过程概述4.1应急响应过程的阶段划分本部分将运行维护服务中应急响应过程划分为四个主要阶段：应急准备、监测与预警、应急处置和总结改进。如图1所示。应急准备监测与预警应急处置总结改进图1运行维护服务应急响应过程4.2应急响应各阶段的工作内容应急响应各阶段的工作内容如下：a）应急准备阶段的工作包括：组建应急响应组织，确

8、定应急响应制度，系统性识别运行维护服务对象及运行维护活动中可能出现的风险，定义应急事件级别，制定预案，开展培训和演练；SJ/T.3b）监测与预警阶段的工作包括：进行日常监测，及时发现应急事件并有效预警，进行核实和评估，以规定的策略和程序启动预案，并保持对应急事件的跟踪；c）应急处置阶段的工作包括：采取必要的应急调度手段，基于预案开展故障排查与诊断，对故障进行有效、快速的处理与恢复，及时通报应急事件，提供持续性服务保障，进行结果评价，关闭事件；d）总结改进阶段的工作包括：对应急事件发生原因、处理过程和结果进行总结分析，持续改进应急体系，完善信息系统。应将信息系统所支撑业务的数据采集、使用和管理纳

9、入应急响应过程中。在应急准备阶段，结合业务领域突发事件级别和运维活动中的应急事件级别，制定总体预案，开展培训和演练。在监测与预警阶段，从运行维护对象和数据两个角度开展监测预警。在应急处置阶段，根据业务数据变化情况采取相应措施。在总结改进阶段，也应该对业务数据采集、使用和管理体系进行完善。5应急准备5.1建立应急响应组织运行维护服务的组织由相关利益方组成，包括服务需方、服务供方、分包方、供应商等。应在运行维护服务组织基础上建立应急响应组织，要求如下：a）应急响应组织的人员应属于运行维护服务组织的人员，也可包括其他机构的专家和人员；b）应规定运行维护服务及应急响应所有相关利益方的角色及职责，并为关

10、键角色提供备份人选。应明确：1）应急响应责任者：可由服务需方的信息化部门最高管理者担任，统筹协调应急响应工作；2）现场负责人：由应急响应责任者授权，负责应急事件监测与预警、应急处置等现场工作；3）分组负责人：可在组织内成立多个分项小组并设定负责人，承担应急响应中各专业性工作；4）值班人员：组织内承担现场值守工作的人员。c）应就应急响应服务的范围、要求等与相关利益方达成一致，确定沟通流程和方式，并形成记录；d）运行维护过程中涉及组织和人员的变更应与相关利益方达成一致，并形成记录；e）应建立对应急响应组织内人员的考核机制，明确考核指标及方法。考核至少每年进行一次，以确保组织能持续满足应急响应要求。

11、5.2制定应急响应制度组织应制定应急响应制度，明确应急响应的目标、原则、范围以及各项管理制度，并要求：a）与相关利益方就应急响应制度达成一致；b）定期对应急响应制度进行评审；c）在组织战略、业务流程、客户要求等发生重大变化时对应急响应制度进行调整。5.3风险评估与改进5.3.1风险评估组织应按照确定的方法和流程对重要信息系统实施风险评估，确保组织了解其在运行维护过程中的关键活动、所需资源、限制条件及信息系统面临的各种风险要素。组织应了解当风险演变为应急事件时所产生的影响和后果，以及信息系统服务中断所带来的损失。组织应授权组织内或组织外的服务供方进行风险识别，并将授权通知到所有相关利益方。被授权

12、的服务供方应结合具体的信息系统现状和要求，从技术和管理等方面确定风险要素。应对风险要素进行评估，形成风险评估报告，报告内容应包括：a）结论摘要；b）背景及现状；c）风险要素；d）识别出的风险及风险分析；e）建议的应对措施。SJ/T.3应在需方授权范围内对评估报告进行评审和沟通，并达成一致。5.3.2改进对于识别出的各种风险，组织应该制定明确的控制策略，必要时应对信息系统进行升级改造。可供选择的风险控制策略包括：风险规避、风险转移、风险降低、风险接受。根据风险评估报告，组织应该形成改进方案并实施，以利于：a)降低风险转变为应急事件的可能性；b）缩短应急事件的持续时间；c）限制应急事件的影响范围。

13、5.4划分应急事件级别5.4.1参考要素应急事件分级的主要参考要素为：信息系统的重要程度、信息系统服务时段、信息系统受损程度。a）重要程度重要程度主要应考虑信息系统所支撑的业务的重要性，以及信息系统内信息资产的重要性和信息系统服务的重要性。b）服务时段服务时段主要应考虑应急事件发生时系统提供服务的状态。c）受损程度受损程度主要应考虑应急事件发生时信息系统功能和性能等方面的影响程度。5.4.2级别划分组织可按照5.4.1中的要素对可能发生的应急事件进行级别划分（级别划分方法见附录A）。组织应结合自身的业务要求，对应急事件级别对应的响应时间、处置完成时间等达成一致。组织应根据应急事件级别配置响应的

14、保障措施，如人员、资金和设备等。5.5预案制定5.5.1预案制定与评审组织应根据应急事件级别制定应急预案。预案可以分为总体预案和针对某个核心系统的专项预案。预案的格式应该能够为应急响应组织进行系统恢复操作提供快速明确的指导。预案应该明确、简洁，易于在紧急情况下执行，并使用检查列表。应急响应预案的内容应包括：a)应急响应预案的编制目的、依据和适用范围；b）具体的组织体系结构及人员职责；c）应急响应的监测和预警机制；d）应急响应预案的启动；e）应急事件级别及对应的处置流程、方法；f）应急响应的保障措施；g）应急预案的附则。服务需方应组织对预案进行评审，并与相关利益方达成一致。5.5.2预案发布经过

15、评审确认的应急响应预案，应由应急响应责任者负责预案的发布。应急预案应进行版本控制。5.6培训与演练5.6.1培训组织应制定应急响应培训计划，并组织相关人员参与。应急响应预案应作为培训的主要内容。SJ/T.3培训应使得组织及人员明确其在应急响应过程中的责任范围、接口关系，明确应急处置的操作规范和操作流程。培训应至少每年举办一次。5.6.2演练为检验预案的有效性，同时使相关人员了解运行维护预案的目标和内容，熟悉应急响应的操作规程，组织应进行应急演练，应：a）预先制定演练计划、演练脚本；b）演练的整个过程应有详细的记录，并形成报告；c）演练不能影响业务的正常运行。为提升应急响应能力，组织可采用无脚本

16、演练。必要时，组织可根据演练的效果，对预案进行完善。6监测与预警6.1日常监测与预警6.1.1范围a）组织应该对运行维护服务对象的运行情况进行监测与预警，以跟踪和判别以下对象的容量、可用性和连续性：1）应用系统；2）支撑应用系统运行的系统软件、工具软件；3）网络及网络设备；4）安全设备；5）主机、存储、外设、终端等设备；6）电力、空调、消防等基础环境。b）组织应该对信息系统所承载的业务数据进行监测，以跟踪和判别业务数据是否超出了预警条件。6.1.2手段与工具组织应结合运行维护服务级别协议和应急响应预案，开展日常监测与预警活动，包括：a)设立服务台并保持运营；b)建立知识库并保持更新；c）确定监

17、测项、监测时间间隔与阈值；d）确定活动中的人员、角色和职责；组织可以采用运行维护工具与人工相结合的方式开展日常监测与预警活动。6.1.3记录与报告组织应建立监测、预警的记录和报告制度，并按照约定的形式和时间间隔上报现场负责人。发现应急事件时，值班人员应提交报告，报告内容应包括：a）应急事件发生及发现的时间、位置；b）现象描述；c）影响的范围；d）初步原因分析；e）报告人。报告应及时提交给现场负责人。报告方式包括电话、邮件、传真或书面文件等，并确认对方收到报告。值班人员应采取必要措施，开展应急事件的先期处置，以提高应急响应效率，避免次生、衍生事件的发生。应该对应急事件保持持续性跟踪。SJ/T.3

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

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

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

21、情况、诊断信息、故障定位结果等；d)将排查与诊断的过程与结果信息进行整理与归档。7.2.2问题沟通与确认处置过程中，现场负责人应及时与相关利益方进行沟通，沟通的内容主要包括系统故障点、造成故障的原因、排查诊断状况等。现场负责人应组织相关利益方对问题进行确认，问题确认过程不应延误处理与恢复工作的开展。7.3处理与恢复应基于预案、配置管理数据库、知识库等进行故障处理和系统恢复，处理与恢复的原则包括：a)应在满足事件级别处置时间要求的前提下，尽快恢复服务；b)采用的方法、手段不应造成次生、衍生事件的发生。必要时可启用备品备件、灾备系统等。应该对过程及结果信息进行记录，并及时告知相关利益方，现场负责人

22、应组织对处理与恢复的结果进行初步确认。7.4事件升级7.4.1升级组织应建立、审议应急事件升级的策略和程序，以控制应急事件升级的授权和实施。当实际处置时间超过事件级别处置时间要求时，应作为事件升级的参考要素。组织应该对事件升级可能造成的影响进行评估，并在相关利益方之间达成一致。升级内容应包含预案调整、人员调整、资金调整以及设备调整。事件升级的实施授权应由现场负责人启动。应该对事件升级的过程和结果信息进行整理与归档。7.4.2信息通报现场负责人应向相关利益方通报事件升级信息，内容应包括：a)事件升级的原因；b)事件升级后的级别；c)事件升级后与之对应的预案；d)对升级事件处置过程及结果的报告要求

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

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

25、生的原因、处置过程和方法应记入知识库。8总结改进8.1应急事件总结组织应定期对应急事件进行分析和回顾，总结经验教训，并采取适当的后续措施。对应急事件的分析和回顾应考虑以下方面：a）应急事件发生原因、数量及频率；b）应急事件处置的经验得失；c）应急事件的趋势信息；d）信息系统中潜在的类似隐患。对应急事件的分析和回顾应形成总结报告，并将总结报告作为改进应急体系及信息系统的重要依据。8.2应急体系的保持为保证应急体系的有效性和时效性，应对应急体系进行不定期的维护和及定期审核，以确保组织具有足够的应急响应能力。体系维护主要是指当组织战略、业务流程、客户要求等发生重大变化的时候，对现有的应急体系，尤其是

26、风险评估和应急预案进行修改。体系维护应该由上述事件驱动。体系审核主要是指对组织当前的应急响应能力和管理模式进行评审，以确保它们符合预定的标准和要求，同时明确组织在应急响应方面主要存在的不足和改进的方向。体系审核应该是定期进行的，组织应该至少一年进行一次体系审核。8.2.1体系维护SJ/T.3组织应该制定一个明确的应急体系维护计划。此维护计划应该确保任何影响到组织应急管理的重大变更都能被识别出来，同时采取必要的措施对这些变更进行分析，并对应急管理体系做出相应调整，这种调整可能涉及应急管理的方针、组织、流程、应急预案和资源配置。体系维护流程的结果应该包括：a）关于应急体系维护活动的文档记录；b）确

27、保应急响应的相关人员都已经明确应急体系的调整内容，并接受必要的培训；c）当需要对风险评估、组织体系结构、人员配备进行调整时，保留必要的文档记录。8.2.2体系审核应急响应责任者应该按照预定的时间间隔对应急管理体系进行审核，以确保体系具有持续的有效性和时效性。体系审核应该包括评估体系的不足和改进的建议。体系审核的结果应该正式存档并通知给相关利益方。a）体系审核时应考虑的要素包括：1）相关利益方的要求和反馈；2）组织所采纳的用于支持应急响应的各种资源和流程；3）风险评估的结果及可接受的风险水平；4）应急预案的测试结果及实际执行效果；5）上次体系评审的后续活动跟踪；6）可能影响应急体系的各种业务变更

28、；7）近期在处置应急事件过程中总结的经验和教训；8）培训的结果和反馈。b）体系审核的输出结果应该包括：1）应急体系的改进目标；2）如何改进应急体系的有效性和效率；3）所需的各种资源，包括人员、资金和设备等。8.3应急工作的改进应急事件总结、体系维护和体系审核的结果应该作为应急准备阶段各项工作的改进要素。组织应根据总结报告中给出的建议项和体系评审结果，完善信息系统，深化应急准备工作。SJ/T.3附录A（资料性附录）应急事件级别划分指南A.1参考要素的赋值应急事件分级的主要参考要素为：信息系统的重要程度、信息系统服务时段、信息系统受损程度。a）信息系统的重要性由以下要素决定：1)信息系统所属类型，

29、即信息系统资产的安全利益主体。2)信息系统主要处理的业务信息类别。3)信息系统服务范围，包括服务对象和服务网络覆盖范围。4)业务对信息系统的依赖程度。其中第1、2个要素决定信息系统内信息资产的重要性，第3、4个要素决定信息系统所提供服务的重要性，而信息资产及信息系统服务的重要性决定了信息系统的重要性。信息系统的重要程度划分为4级，对应赋值1至4。由其在经济建设、社会管理、公共服务以及生产经营中的重要程度决定。其划分方法参考GB/T22240-2008信息安全技术信息系统安全等级保护定级指南。b）信息系统服务时段划分为3级。依据应急事件发生的不同时间，对信息系统恢复正常服务所需的时间要求而确定，

30、具体划分方法参见表A.1。表A.1信息系统服务时段赋值表赋值描述1非系统服务时段（不含系统服务时段即将开始）2系统服务时段或系统服务时段即将开始3系统处于重点时段保障或处于服务高峰时段c）应急事件造成的信息系统损失程度划分为3级。依据故障发生对信息系统提供的服务能力的下降程度而确定，具体划分方法参见表A.2。表A.2信息系统损失程度赋值表赋值系统功能系统性能功能无损部分损失全部损失小于阈值13大于或等于阈值123注：重点时段保障的损失程度赋值为3。A.2事件定级步骤首先为应急事件的三个定级要素赋值，然后将三个要素赋值相乘，得到应急事件具体分值。其范围在136。建议将分值在16区间的定义为三级事

31、件，分值在818区间的定义为二级事件，分值在2436区间的定义为一级事件。级别定义步骤如图A.1所示。2计算应急事件分值SJ/T.31.赋值信息系统重要性信息系统服务时段信息系统受损程度计算应急事件分值应急事件分值3.定义应急事件级别三级：16；二级：818；一级：2636图A.1应急事件级别定义步骤SJ/T.3附录B（资料性附录）应急响应规范的使用运行维护服务应急响应过程包括应急准备、监测与预警、应急处置和总结改进四个主要阶段，每个阶段中包括若干重点任务，这些任务覆盖了日常工作、故障响应和重点时段保障等不同类型的活动。表B.1描述了不同类型活动与重点任务的基本对应关系。表B.1日常工作、故障

32、响应、重点时段保障与任务的对应关系主要阶段重点任务日常工作故障响应重点时段保障建立应急响应组织制定应急响应方针风险评估与改进应急准备划分应急事件级别预案制定培训与演练日常监测与预警监测与预警核实与评估预案启动应急调度排查与诊断处理与恢复应急处置事件升级持续服务事件关闭应急事件总结总结改进应急体系的保持应急工作的改进SJ/T.3参考文献1GB/T19000-2008质量管理体系基础和术语2计算机软件著作权登记中使用的软件分类编码指南3GB/T22240-2008信息安全技术信息系统安全等级保护定级指南4GB/T22239-2008信息安全技术信息系统安全等级保护基本要求5GB/T25058-20

33、10信息安全技术信息系统安全等级保护实施指南6ISO/IEC27001:2005信息技术安全技术信息安全管理体系要求7ISO/IEC20000-1:2005,InformationTechnology-ServiceManagement-Part1:Specification8ISO/IEC20000-2:2005,InformationTechnology-ServiceManagement-Part2:CodeofPractice9ITILVersion3ServiceStrategy10ITILVersion3ServiceDesign11ITILVersion3ServiceTransition12ITILVersion3ServiceOperation13ITILVersion3ServiceImprovement