运维应急响应管理制度0803.docx

《运维应急响应管理制度0803.docx》由会员分享，可在线阅读，更多相关《运维应急响应管理制度0803.docx（21页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精品文档，仅供学习与交流，如有侵权请联系网站删除应急响应管理制度山西精英科技股份有限公司版本记录目录1 目的52 术语定义与引用标准52.1术语定义52.2引用标准53 适用范围64 工作原则64.1统一指挥、有效组织64.2突出重点，加强演练64.3技术支撑，健全机制65 风险评估65.1系统重要性评估75.2影响度评估75.3发生几率评估75.4发生时段评估85.5风险等级评估85.6进行风险评估96 事件分级96.1信息系统重要性96.2信息系统服务时段106.3事件定级107 组织机构和职责117.1公司内部组织117.1.1总负责人117.1.2应急指挥小组117.1.3应急工作小组

2、117.1.4相关外部角色128 应急要素与体系128.1事件处置要素128.1.1管理层面128.1.2技术层面128.1.3事件归口138.1.4分级响应138.2指挥和协调138.3信息共享和处理148.4通讯148.5外部沟通148.6服务需方148.7供应商159 运行机制159.1日常监测和预警159.2应急启动159.3事件报告159.4应急调度169.5排查和诊断169.6处理和恢复169.7事件升级179.8持续服务179.9应急事件关闭179.9.1申请179.9.2核实189.9.3事件通报189.10总结改进189.10.1应急工作总结189.10.2应急工作审核191

3、0 保障措施1910.1通信保障1910.2物资保障2010.3技术保障2010.4经费保障2010.5人员保障2011 宣传、培训和演练2011.1宣传2011.2培训2011.3演练2112 应急响应管理关键指标231 目的为了规范客户的各类信息系统应急事件的应急管理，提高应对应急事件的管理水平和应急处理能力，有效防范信息系统风险，减少信息系统故障对生产业务造成的影响，确保信息系统运行的连续性，特制定本预案2 术语定义与引用标准2.1 术语定义服务级别管理术语定义如下：术 语缩略词定 义重点时段保障important period assurance提升服务级别以确保某一时间段内重要活动或

4、重点业务的开展所采取的措施和活动。应急事件emergency event导致或即将导致运行维护服务对象运行中断、运行质量降低，以及需要实施重点时段保障的事件。应急响应emergency response组织为预防、监控、处置和管理应急事件所采取的措施和活动。2.2 引用标准l GB/T 28827.12012 信息技术服务 运行维护 第1部分：通用要求；l GB/T 28827.22012 信息技术服务 运行维护 第2部分：交付规范；l GB/T 28827.32012 信息技术服务 运行维护 第3部分：应急响应规范；l ITSS 1-2015 信息技术服务 运行维护服务能力成熟度模型V1.0

5、；l ISO/IEC 27001:2013信息技术-安全技术-信息安全管理体系要求。3 适用范围本制度适用于公司运维业务范围内的信息系统、网络系统、数据中心等应急事件。本制度用于指导和规范公司运维业务范围的信息系统、网络系统、数据中心等应急预案，建立自上而下、分级负责应急事件应急处置体系，规范处理突发事件的逐级汇报流程。本制度适用于应急预案编制、预案评审、预案实施、应急队伍、培训教育、应急装备、应急演练等工作。4 工作原则4.1 统一指挥、有效组织成立应急总负责人，由公司总经理担任；应急指挥小组，由公司副经理，技术骨干等组成；并成立应急工作小组。组织开展事件预防、应急处置、恢复运行、事件通报等

6、各项应急工作。相关部门要主动协调有关各方面，参与实施部门听从指挥、步调一致。4.2 突出重点，加强演练对关键信息系统加大监控和应急处理力度，确保应急信息及时准确传递。每年开展应急演练工作，确保应急措施合理、有效。4.3 技术支撑，健全机制在充分利用客户现有的信息资源、系统和设备基础上，采用先进适用的预测、预防、预警和应急处置技术，改进和完善应急处理的装备、设施和手段，提高应对信息系统应急事件的技术支撑。建立健全应对信息系统应急事件的有效机制。5 风险评估应急响应小组每年对重要信息系统进行一次风险评估，并根据风险评估结果来制定或更新应急预案。风险评估方法如下：5.1 系统重要性评估等级描述赋值1

7、级将对客户造成极严重的或灾难性的损失42级将对客户造成较重要的损失33级将对客户造成一定损失24级将对客户造成有限损失1根据上表对信息系统以及相关外部环境进行重要性评估。5.2 影响度评估等级赋值影响度描述高3核心业务全面中断；影响大面积用户正常使用；中2部分核心业务中断；影响一定范围内用户的正常使用；低1单一业务中断；影响个别用户正常使用；根据上表对信息系统以及相关外部环境进行影响度评估。5.3 发生几率评估等级可能性取值可能性描述（威胁发生的频率）经常3可能每个季度发生一次或者以上偶尔2可能每半年会发生一次极少1可能每年发生一次或更少根据上表对风险发生几率进行评估。5.4 发生时段评估等级

8、赋值时段程度描述高3核心业务并发高峰期；核心业务关键程序执行期；中2部分核心业务并发高峰期；部分核心程序执行期；低1非核心业务并发期；非核心程序执行期；5.5 风险等级评估按照重要性、影响度、发生几率赋值相乘，得出信息系统以及相关环境的风险等级。等级描述如下：可能性123影响度123123123重要性1123246369224648126283369612189874481281624246风险值 重要性 风险发生可能性 风险发生的严重性风险等级风险值n高（H）n=12中（M）12n4低（L）n=45.6 进行风险评估按照风险等级评估，列出信息系统以及相关外部环境，描述可能发生的风险，针对每一

9、个风险制定控制措施，并明确相应责任人，形成风险评估表，撰写风险评估报告。6 事件分级根据信息系统事件的分级考虑要素，将信息系统事件划分为三个级别：I级事件、II级事件、III级事件。l 一般（III级）：综合分值在1-4分；l 较大（II级）：综合分值在5-12分；l 重大（I级）：综合分值在大于12分；6.1 信息系统重要性信息系统的重要性由以下要素决定：1) 信息系统所属类型，即信息系统资产的安全利益主体。2) 信息系统主要处理的业务信息类别。3) 信息系统服务范围，包括服务对象和服务网络覆盖范围。4) 业务对信息系统的依赖程度。其中第1）与 2）个要素决定信息系统内信息资产的重要性，第3

10、）与第4）个要素决定信息系统所提供服务的重要性，而信息资产及信息系统服务的重要性决定了信息系统的重要性。信息系统分级及赋值如下：赋值描述14级信息系统23级信息系统32级信息系统41级信息系统6.2 信息系统服务时段信息系统服务时段划分为3级。依据应急事件发生的不同时间，对信息系统恢复正常服务所需的时间要求而确定。赋值描述1非系统服务时段（不含系统服务时段即将开始）2系统服务时段或系统服务时段即将开始3系统处于重点时段保障（业务必须正常运行时间）或处于服务高峰时段信息系统损失程度赋值应急事件造成的信息系统损失程度划分为3级。依据故障发生对信息系统提供的服务能力的下降程度而确定。系统性能系统功能

11、功能无损部分损失全部损失小于阈值13大于或等于阈值123重点时段保障的损失程度赋值为36.3 事件定级将以上应急事件三个要素的赋值相乘，事件级别如下表所示：范围级别16III事件818II事件2636I事件7 组织机构和职责7.1 公司内部组织公司内成立应急处置领导小组、指挥小组、工作小组。应急组织设置根据实际项目的应急组织管理机制，受客户的应急组织领导。7.1.1 总负责人总负责人的主要职责：统一领导信息系统的应急事件的公司内部应急处理工作，发起研究重大应急决策和部署，决定实施和终止应急预案。7.1.2 应急指挥小组应急指挥小组的主要职责：接受应急总负责人的领导，传达和落实应急总负责人的各项

12、指令，汇总和上报应急信息，负责应急工作小组成员的协调沟通，协调应急事件处置工作中的重大问题。7.1.3 应急工作小组应急工作小组主要职责：落实应急总负责人及应急指挥小组布置的各项任务；组织制定应急预案，并监督执行情况；掌握应急事件处理情况，及时向应急总负责人和应急指挥小组报告应急过程中的重大问题。角色角色匹配总负责人总经理、工程运维中心总监（副总经理）应急指挥小组运维部经理、技术支持部经理、运维项目经理、综合管理部、质量管理部经理应急工作小组技术支撑主管、研发主管、运维主管、运维工程师、备件管理员等运维团队成员、质量管理员7.1.4 相关外部角色服务需方应急响应责任人与供应商等外部联络人及相关

13、人员。8 应急要素与体系8.1 事件处置要素8.1.1 管理层面1) 启动指挥体系：I级事件的启动和指挥由应急总负责人负责，II、III级事件的启动应急指挥小组负责。2) 掌握事件动态：事件动态由应急工作小组人员收集并及时反馈给应急指挥小组，应急指挥小组决定信息的共享、沟通、处置。3) 处置实施：l 控制事态防止蔓延l 做好处置消除隐患4) 后期处置：事件调查报告和经验教训总结及改进建议。5) 保障措施：包括通讯与信息保障，应急支援与设备保障，技术储备与保障，宣传、培训和演练，监督检查等。8.1.2 技术层面信息系统事件发生后，事发部门应立即启动相关应急预案，实施处置并及时报送信息。1) 控制

14、事态发展，防控蔓延。事发部门先期处置，采取各种技术措施，及时控制事态发展，最大限度地防止事件蔓延。2) 快速判断事件性质和危害程度。尽快分析事件发生原因，根据信息系统运行和承载业务情况，初步判断事件的影响、危害和可能涉及的范围，提出应对措施建议。3) 及时报告信息。事发部门在先期处置的同时要按照预案要求，及时向上级报告事4) 做好事件发生、发展、处置的记录和证据留存。8.1.3 事件归口发生应急事件的归口部门是应急体系启动的责任部门。8.1.4 分级响应发生I级事件，由应急工作小组初步判定事件级别后，将信息通知应急指挥小组并注意持续监控事态、收集信息、做出应急准备；应急指挥小组响应判断为I级事

15、件后，立即通知应急总负责人，并由应急总负责人启动应急预案。发生II、III级事件，由应急工作小组初步判定事件级别后，将信息通知应急指挥小组并注意持续监控事态、收集信息、做出应急准备；应急指挥小组响应判断为II、III级事件后，立即启动应急预案。应急事件的级别应置于动态调整控制中。8.2 指挥和协调I级级事件，由应急工作小组收集信息，应急指挥小组做出预判，并迅速通知应急总负责人，由应急总负责人进行指挥和决策。II、III级事件，由应急指挥小组进行指挥和决策，并及时将处理过程、报告等上报应急总负责人。8.3 信息共享和处理I级事件，由应急工作小组收集信息并提交给应急指挥小组和应急总负责人，由应急总

16、负责人决定信息的分发、共享和处置。II、III级事件，由应急指挥小组决定信息的分发、共享和处置，并上报应急总负责人。8.4 通讯应急响应小组和工作小组建立通信录，并24小时开通联系电话，保持通信顺畅。通信录应上报应急总负责人。事件处理过程中的值班人员必须拥有完整的通信联系方式，并有足够的通信手段保证联系顺畅。8.5 外部沟通应急组织应与外部相关利益方进行沟通确认统一的沟通流程和方式。8.6 服务需方当应急事件发生时，若是由用户报障到服务台，服务台人员应向用户详细了解事件情况。项目经理接单后应立即与客户方负责人沟通，尽快开展工作。若是由现场工程师主动发现，则应立即通知客户方负责人。在事件解决过程

17、中，现场负责人应及时向客户方相关人员通报最新情况。完成处理与恢复后，现场负责人应告知客户方负责人，由客户方负责人进行现场确认。之后应组织运行维护人员提供持续性服务，并定期向客户方负责人汇报。在持续性服务证实一切正常后，由客户方负责人在事件单上签字，并由服务台进行回访确认后，现场负责人可向应急指挥小组申请关闭事件。在应急事件关闭后，应急总负责人应授权应急指挥小组向相关利益方通报事件信息。8.7 供应商在应急事件解决过程中，可能会需要供应商提供服务。此时现场负责人应根据应急预案，与供应商联系。9 运行机制9.1 日常监测和预警组织应该对运行维护服务对象的运行情况进行监测与预警，以跟踪和判别以下对象

18、的容量、可用性和连续性。1) 应用系统；2) 支撑应用系统运行的系统软件、工具软件；3) 网络及网络设备；4) 安全设备；5) 主机、存储、外设、终端等设备；6) 安防、一卡通、会议等智能化设备。如发现有异常情况时，要及时处理并向现场负责人报告，并及时排除信息系统中存在的风险隐患。9.2 应急启动应急预案的启动有以下两种方式：1) 遇到I级事件，事件信息由应急工作小组提供并提交给应急指挥小组，应急指挥小组做出初步判断和初步事件级别的确认，初步确认为I级事件的，呈报应急总负责人，由应急总负责人下达启动应急预案。2) 遇到II、III级事件，应急指挥小组自行启动应急预案，并及时上报应急总负责人。9

19、.3 事件报告当发现各类信息系统事件时，应按照事件等级逐级汇报。报告分为紧急报告和详细汇报。紧急报告是指相应部门在事件发生后，立即向本部门应急指挥小组以口头和应急报告表形式汇报事件的简要情况；详细汇报是指由相应部门应急处理机构在事件处理暂告一段落后，以书面形式提交的详细报告。应急指挥小组对各类事件的影响进行初步判断，汇报矩阵如下：事件级别报告事件要求报告对象I10分钟内总负责人II30分钟内总负责人III60分钟内总负责人报告内容应准确、详实，任何部门和个人均不得缓报、瞒报、谎报或者授意他人缓报、瞒报、谎报事件。事件报告信息一般包括以下要素：发生事件的信息系统名称及业务部门、地点、原因、信息来

20、源、事件类型及性质、危害和损失程度、影响部门及业务、事件发展趋势、采取的处置措施等。9.4 应急调度公司应该按照预案开展统一的应急调度，包括人员、资金和设备等。应急调度由应急总负责人授权应急指挥小组执行。9.5 排查和诊断组织应明确故障排查和诊断流程；应急事件的排查与诊断流程参考事件与服务请求过程，排查与诊断过程需在应急事件报告进行记录。处置应急事件的过程中，现场负责人应及时与相关利益方就排查、诊断结果进行沟通和问题确认。9.6 处理和恢复应急事件的处理与恢复应基于应急响应预案、配置管理数据库、知识库等进行故障处理和系统恢复。必要时可启用备品备件、灾备系统等。应急事件的处置与恢复流程参考事件与

21、服务请求过程，处理与恢复过程需在应急事件报告进行记录，并及时告知利益相关方。在处理和恢复应急事件时,应在满足事件级别处置时间要求的前提下，尽快恢复服务。事件级别处置时间要求如下：事件级别处置时间要求I2小时II4小时III6小时9.7 事件升级当事件处置超过事件级别处置时间要求时，应急工作小组应向应急指挥小组申请事件升级，递交应急事件升级审批表。事件升级的实施授权应由应急指挥小组负责人启动。应急指挥小组应对事件升级可能造成的影响进行评估，并在相关利益方间达成一致。9.8 持续服务完成处理与恢复后，应组织运行维护人员提供持续性服务。应急响应组织应对持续性服务的效果进行评价。持续服务的评价结果，应

22、作为应急事件关闭的输入。I级应急事件应急处理结束后应密切关注，监测系统2周，确认无异常现象。II级应急事件应急处理结束后应密切关注，监测系统1周，确认无异常现象。III级应急事件应急处理结束后应密切关注，监测系统3天，确认无异常现象。9.9 应急事件关闭9.9.1 申请在同时满足下列条件下时，应急工作小组负责人可向应急指挥小组提出关闭申请。l 应急事件处理已经结束，设备、系统已经恢复运行。l 持续服务阶段系统无异常，持续服务阶段结束。l 服务需方应急响应负责人同意事件关闭。l 应急事件处置的过程文档已整理完成。9.9.2 核实应急指挥小组接到关闭申请后，应逐项核实报告内容，以判别应急事件处置过

23、程和结果信息是否属实之后通报应急总负责人，由应急总负责人做出关闭决定。9.9.3 事件通报应急总负责人应授权应急指挥小组向相关利益方通报事件信息，内容应包括：l 事件发生的原因、事件级别及影响范围；l 事件对应的预案；l 事件的处置过程和方法；l 事件的调整升级情况；l 持续性服务情况；l 事件处置评价；l 事件关闭申请的处理意见；l 关闭通报的范围和涉及接受者。应急事件发生的原因、处置过程和方法应记入知识库。9.10 总结改进9.10.1 应急工作总结组织应定期对应急响应工作进行分析和回顾，总结经验教训，并采取适当的后续措施。对应急响应工作的分析和回顾应考虑以下方面：l 应急响应工作的绩效；

24、l 应急准备工作的充分性和有针对性；l 应急事件发生原因、数量及频率；l 应急事件处置的经验得失；l 应急事件的趋势信息；l 信息系统中潜在的类似隐患。对应急响应工作的分析和回顾应形成应急响应工作总结报告，并将总结报告作为改进应急响应工作及信息系统的重要依据。9.10.2 应急工作审核应急总负责人应定期发起对应急响应工作的评审，以确保应急响应过程和管理符合预定的标准和要求。审核的结果应该正式存档并通知给相关利益方。评审至少每年一次，可于公司内审时进行。1) 审核时应考虑的要素包括：2) 相关利益方的要求和反馈；3) 组织所采纳的用于支持应急响应的各种资源和流程；4) 风险评估的结果及可接受的风

25、险水平；5) 应急预案的测试结果及实际执行效果；6) 上次评审的后续活动跟踪；7) 可能影响应急响应的各种业务变更；8) 近期在处置应急事件过程中总结的经验和教训；9) 培训的结果和反馈。10) 审核的输出结果应该包括：l 改进目标；l 改进的具体工作内容；l 所需的各种资源，包括人员、资金和设备等。10 保障措施10.1 通信保障指挥、通信联络和信息交换的渠道主要有外线电话、手机、传真、电子邮件、微信、QQ等方式，有关应急联系人员手机应保持每天24小时处于开机状态。10.2 物资保障各部门根据信息系统事件防治工作所需确保经费，配备相应的应急设施，以确保事件应急工作的顺利进行。应急物资主要有备

26、品备件、常用工具等。10.3 技术保障任何状态下，应提供充足的技术保障，如网络拓扑图、服务器清单、网络设备配置、访问控制策略、应用系统和各类软件的版本，并定期进行数据备份，以保障发生事件时，受影响的信息系统能及时恢复。重视信息系统事件体系的建设、运维和升级换代，确保信息系统的稳定与安全，确保在事件处置过程、系统恢复或重建过程中有足够的技术支撑。10.4 经费保障各部门应保障应急培训、演练、添置应急物资等所需经费。10.5 人员保障各部门需加强信息系统应急事件应急技术支持队伍的建设，提高人员的业务素质、技术水平和应急处置能力。确保在事件处置过程和系统恢复或重建工作中人员在岗并具有处置能力。11

27、宣传、培训和演练11.1 宣传公司各部门应加强应急工作的宣传和教育，提高各级人员对应急预案重要性的认识，加强各部门和部门之间的协调与配合。11.2 培训各信息系统应急预案涉及人员应定期开展应急预案的培训，做好信息系统相关知识的宣传和普及，增强各运维人员的责任意识，熟练掌握应急响应的程序和应急处置技能等内容。11.3 演练公司要组织对预案进行定期演练，通过演练验证预案的合理性，及时修订和完善不符合实际的应急处置情况，有针对性地改进信息系统应急事件处置能力，确保事件发生后应急处理手段及时到位和有效。相关部门在做应急演练前要做好相关准备工作，确保演练工作的安全。要明确演练的目的和要求，记录演练过程，

28、对演练结果进行评估和总结。附件1：应急响应体系矩阵表如下：事件级别级别判定预案启动指挥和决策信息分发、共享和处置事件升级、应急调度关闭及通报I级指挥小组领导小组领导小组领导小组指挥小组领导小组II级指挥小组指挥小组指挥小组指挥小组指挥小组领导小组III级指挥小组指挥小组指挥小组指挥小组指挥小组领导小组附件2：应急响应负责人和应急小组责任人登记表责任人姓名职务办公电话手机组长王增强总经理0551-6533185513505515137副组长赵存会副总经理0551-65331854913349294929副组长吴喆峰运维部经理0551-6530918513866173277组员运维研发主管0551

29、-6533185118010875817组员技术支撑主管0551-6530916218056078503组员质量管理部经理0551-6530916213866127756组员综合管理部0551-6530912315255159060组员人力资源部0551-6530915215357908027组员运维部0551-6221299913865972485组员运维部0551-6530918518155193176组员运维部0551-6530918518155199376组员运维部0551-6530918515256095997组员运维部0551-6530918513866199361组员运维部055

30、1-6530918518056092050组员运维部0551-653091621806646008组员运维部0551-6221299913865517177注：所列事项发生变更时，须重新报运维部、质量管理部、综合管理部备案。12 应急响应管理关键指标应急响应管理的工作指标应每年组织进行评估，根据评估结果确定是否需要调整指标或指标目标值。指标名称考核要求考核指标应急响应宣贯体系建设每半年度至少进行一次重点项目应急培训、演练针对应急预案，重点运维项目是否制定演练计划、演练脚本、培训应急工作审核每半年度至少进行一次应急工作组织会议，对应急响应工作进行评审与总结每半年度组织人员对应急响应工作进行评审逐项应急演练次数不小于一次检查所有运维项目的应急演练记录每年度所有运维项目应组织一次应急演练【精品文档】第 21 页