|
|
知识路径： > 信息系统设施运维 > 信息系统设施运维的内容 > 响应支持运维 > 响应支持运维 > 应急响应 >
|
|
相关知识点：4个
|
|
|
|
|
（1）建立应急管理的组织和制度：建立应急管理组织，确保组建合适的组织以满足日常运维和应急响应的服务要求，明确应急响应组织中的角色及关系。应急管理组织建立后对应的应急管理制度包括负责制定应急响应方针（应急响应原则、范围等），明确应急响应的范围、要求、等级等。
|
|
|
|
（2）风险评估与改进：风险评估与改进的目的是系统地识别运维服务对象及运维活动中可能出现的风险并提前改进，包括风险识别与评估、风险应对。
|
|
|
|
运维人员从系统的角度识别风险要素，如运维对象、运维内容、组织及流程接口等。根据风险要素，应急响应组织按照一个确定的方法和流程来实施风险评估，明确其在其运维过程中的关键活动、所需资源、限制条件及组织面临的各种威胁，明确当威胁演变为应急事件时所产生的影响和后果，以及业务中断可能带来的损失。分析评估后应形成《风险评估报告》，报告应包括与服务水平目标相比较的运维要求、现状及趋势信息、风险要素、不符合项及问题等，并据此提出纠正措施建议，确认后的《风险评估报告》将作为风险应对预案。
|
|
|
|
对于识别出的各种风险，制定明确的应对策略，包括风险规避、风险转嫁、风险降低、风险接受等。根据《风险评估报告》，形成《系统改进方案》以降低风险，包括降低风险转变为应急事件的可能性，缩短应急事件的持续时间，限制应急事件的影响范围。
|
|
|
|
（3）应急事件级别划分：应急事件分级的主要参考要素为信息系统的重要程度、紧急程度、系统损失和社会影响。相关负责人按照以上要素对可能发生的事件进行评估。确定应急事件的级别。包括以下内容。
|
|
|
|
灾难事件（Ⅰ级）：指由地震、火灾、恐怖袭击等原因造成主要IT设施毁灭性损坏，或者由于系统平台或业务数据遭受严重破坏，无法在短时间内恢复系统服务，造成核心业务服务中断超过48小时。
|
|
|
|
重大事件（Ⅱ级）：指造成核心业务服务中断超过24小时，或重要业务数据丢失，或业务数据需要后退到上一备份状态。
|
|
|
|
严重事件（Ⅲ级）：指造成核心业务服务中断超过12小时，或少量业务数据丢失。
|
|
|
|
一般事件（Ⅳ级）：指造成核心业务服务中断超过4小时，或管理支撑系统服务中断超过24小时。
|
|
|
|
（4）预案制定：预案制定的目的是提供应对运维应急事件的操作性文件。
|
|
|
|
根据风险评估和事件级别划分制定《应急响应预案》。预案可以分为总体预案和针对某个核心系统的专项预案及其附则；预案中应该考虑到各种应急资源的调配和预置，主要包括人员、备品备件、资金、系统工具等。《应急响应预案》的内容包括应急响应预案的编制目的、依据和适用范围；具体的组织体系结构及人员职责；应急响应的监测和预警机制；应急响应的启动；应急响应的处置；应急响应的总结；应急响应的保障措施；应急预案的附则等。
|
|
|
|
经过评审确认的应急响应预案，由责任者或授权管理者负责预案的分发，同时建立预案的版本控制。
|
|
|
|
（5）培训与演练：培训需要制定应急响应培训计划，并组织相关人员参与，将应急响应预案作为培训的主要内容。培训应使得相关组织及人员明确其在应急响应过程中的责任范围、接口关系，明确应急处置的操作规范和操作流程。
|
|
|
|
应急响应演练的目的，一是为了验证预案是否能够真正满足实际的需求，二是为了检验应急响应小组成员之间相互配合的默契程度和对运维事件应对步骤的熟练程度。演练的方式分为工具测试演练和场景模拟演练。
|
|
|
|
为了检验预案的有效性，同时使相关人员了解运维预案的目标和流程，熟悉应急响应的操作规程，应急响应的演练应做到：预先制定演练计划，在计划中说明测试工具或演练的场景；演练的整个过程有详细的记录，并形成报告；演练不能对业务运行造成负面影响；按照约定周期，进行完整演练（可以有被委托的第三方机构参与），周期建议可以设定为季度、一年或三年。
|
|
|
