摘要：数据中心运维团队需能够在没有任何预警的情况下，能够迅速、有效地应对突发状况。对于不可预见的问题，故障、危险可导致人身伤害或宕机的情况，都需有应对措施。
表3
所有事件应根据严重程度分配“等级”级别，第1级是最严重的，第5级是最不严重的级别。事件类的摘要定义如下：
第1类：人身安全
此类覆盖其它所有类。对人身造成生命威胁比对IT负载造成的威胁更重要。数据中心运维团队职责是通知应急响应团队，致电911，根据需要协助安全，并将责任传递给安全部门。本类别涵盖火灾、自然灾害、对人类生命的威胁和物理安全威胁。在经由数据中心内安全部门、消防部门或警察确认第1类事件后，数据中心管理层必须决定如何在工作环境中进行其它所需的恢复工作。
第2类：关键设施
定义为lT中断功能的事件，或者任何制冷系统或电气中的“N”丢失。可以通过询问两个问题来确定二级情况：IT在负载的冷却或电气支持方面是否丢失了“N”(冗余)? 或者丢失任何关键的IT负载? 第二类事件是“恢复”情况，需要数据中心管理层做出决策，才能执行恢复操作。
第3类：严重
没有其它备份系统可用; 即冗余已经从“N + 1”减少到“N”。还涵盖任何非调度发电机运行。当定义这个类时，需要问：“我们有额外的备份或空间吗?”如果答案是“否”，那么必须假定类3。
第4类：重要
关键系统冗余仍然可用，即存在“N + 1”。 由于可能存在的“冗余”的许多定义，第4类可能难以定义。 例如，在11号楼，服务器楼层的CRAC单位的损失将是4级。这是因为有许多其它单位将能够承担冷却，而不会因为损失而产生很大的影响 。虽然有备份，但故障依然被评定为重要的。 UPS系统的功率增加可以被认为是4级。
第5类：通知
该类旨在通知数据中心小组的直接上级主管。例如：强风警告，雷雨风暴警告。这类主要用于通知升级到更高级别的情况。该类还包括可能升级到更高级别的设备变化与维护工作，即冷却设备，UPS等。
对于设备事故、升级，应按照设备既有的相关升级程序执行。对于设备多数据中心，应该有一个24x7的操作中心作为集中资源来协调升级程序。
二、应急训练
训练的主要功能是评估运维人员对紧急事件的反应的熟练程度。书面和口头测试可以证明掌握专业知识的能力，但更重要的是，演习能够呈现知识和行动的熟练程度。安全解决危机或紧急情况在很大程度上取决于当时第一反应，并知道身处在哪里。演练可以了解技能、知识缺陷的部分，从而为持续培训提供机会，以便在发生真正紧急情况之前弥补这些缺陷。
演习是基于对现场环境的了解以及对设备系统运行理解的基础上进行。演习报告文档允许评估和记录个人绩效考核指标之一。也可以将演练作为加强运维人员对对数据中心环境以及对现有设备深入了解的机会。
演练应是强制性的，并且应针对每个高概率和/或高严重性的预期事件依据紧急操作程序(EOP)进行演练。应在每月对每项设备进行至少一次演练，但在任何情况下都必须满足合同要求与义务。重点应放在前十个EOPs，结合当前的情况进行威胁评估。基于对事件的分级，如复杂性或难度级别(例如“基本”，“中间”和“高级”)来对训练进行分组。
演练评估必须在是演练开始之前确认演练的目的，并在整个评估过程中关注评估重点。运维人员如若能以安全、及时的方式精准地执行流程取决于以下几点：
·充分了解设备、系统知识
·充分了解设备运行操作流程以及系统集成知识。
熟悉和正确使用各种流程文件(如：EOP，SOP，操作员手册等);当演习作为评估工具时，评估员需对整个过程在不提供任何指导，提示或更正的情况下，进行严格评估、记录数据中心运营团队的绩效。基本上数据中心运维人员都不会一次通过所有评估。
如果运维人员没有通过评估，则评估者或设备经理有责任制定一份行动培训计划，以解决评估过程中发现的所有缺陷。未通过评估的运维人员需完成指定的补习训练，受训人员可以进行一次或多次训练，经过多次重复训练，直至通过评估考核。在以训练为目进行评估的情况下，教练承担教练和参与者的作用，在训练期间积极地辅助和指导受训者。
随着训练演练的重复和操作员的学习，教练参与将减少，直到受训者自己做。将多个故障组合到单个演练中可以使它们更具挑战性。这使得对故障优先级，团队合作、事件管理技能能够进行更彻底的测试。例如：将主电源故障与备用应急发电机启动故障放在一起将是一个很好的示例。
当进行演练评估时，需考虑以下几点：
三、事件管理
· 为演练预演做简报，并提前提供评估记分卡，向工程师解释测试。
· 经验丰富评估员应事先熟悉脚本，再对演练进行记录与评估。
· 应在演练之前安装标志，以便告知正在进行评估的工程师演练情况以及报警情况。
· 评估人员在评估中扮演实时口述宣布改变报警状态与设备状态的角色，例如“发电机不会与母线同步”或“有来自UPS的报警面板”。
· 观察者不应帮助工程师确定解决方案，除非提供工程师有效信息，例如“该面板显示在1的位置”。
· 当获得解决方案或者评估人员不需要运维团队再解决什么问题的时候，评估结束。
· 评估人员对照评估记分卡上详细标准对工程师进行评估和记录，然后与工程师详细沟通评估全部内容，评估人员向工程师说明他们做对的部分，同时向他们详细解释他们做错什么。这需在评估后立马安排去做。
*事件管理
什么是事件?
关键设备中的“事件”是指由于意外、不寻常的、或突发事件导致的影响设备操作或安全的事件。
·设备或系统故障
·运维人员受伤/设施设备受损
网络通信故障/UPS报警/温度升高，超过阈值/UPS由市电供电切换到电池供电/面板断路器跳闸/烟雾报警器关闭/入侵报警/漏水传感器报警
· 关键设备需投入大量资金与人力来确保业务持续运行。这些设备环境条件应受到高度管理与监控。作为控制方案的一部分，重要的是要注记录和报告可能影响操作或安全性的任何意外事件。如果处理不当，这些事件可能成为危机，甚至是灾难。具有良好的应急准备和响应能力的组织将具有事件管理过程，该过程提供处理这些事件的标准化方法。一个有效的过程有三个元素：事件通知，事件报告和故障分析。
· 事件通知和标识事件通知包括提醒利益相关者发生事件的系统，过程和人员。重要的是及时通知事件。“及时”的意思将取决于事件的严重性和紧急性。环境中的烟雾将显然需要比涉及与单个环境传感器的通信丢失的事件更快速的通知。谁应该警告需要提前确定和计划。如前面表3所示，事故可以按紧急程度或临界程度分类。然后，该分类系统可以管理需要被通知的人，时间和频率。当然，假设基础设施系统被计量，装备和与软件通信，包括楼宇管理系统(BMS)在内的数据中心基础设施管理(DCIM)软件可以非常有助于简化和自动化事件通知(和报告)。可以集中配置和管理告警阈值和通知策略。太多警报或不正确的通知可能会导致系统无效。
事件报告
事件报告是一个通用流程，可能会改善或替代现有现有系统(例如，DCIM或BMS)或者现有的流程。以下部分涵盖从事件发生到事件响应以及后续行动的事件报告过程。
一旦检测到初始事件，做出及时响应并通知与事件相关的人; 建议事故报告在24小时内完成，并发送给所有与此事相关者。一旦有时间开始填写报告(当事件在人们心中是还记忆犹新)，如果情况允许，在整个事件期间需不断完善报告。
应使用标准化模板报告所有事件。这有助于确保收集信息的完整性。它应存储在计算机化文档管理系统(CDMS)中。报告应包含以下信息。
· 报告信息
· 报表标题
· 提交报告日期
· 创建报表的日期和时间
· 报告提交的日期和时间网站信息
数据中心信息
· ·地址，城市，州或省，邮政编码，国家/地区
· 联系方式
事件报告创建者事件概述
· 事件简要说明
· 事件影响位置(例如发电机舱，UPS房间或整个设施)
· 涉及的设备
· 事件属性事件详细信息
· 事件和持续时间的时间/日期
· 谁发现
· 谁在场
· 描述初始响应操作
· 谁被通知和什么时候
· 情况如何稳定或解决
· 使用哪些资源
· 事件持续跟进：一旦初始事件被记录，后续将持续记录可能在这个事件中会发生的问题。例如，当系统组件发生故障并通过冗余单元恢复运行并致电供应商前往修复时，可能会发生事件。
故障部分。事故报告需要立即填写，并在批准与分配之前修复被影响的部分。一旦供应商开始进行升级工作时，需在报告中有所体现。
行动项目
· 这是针对特定事件发生制定的具体行动。
· 特定任务时用来纠正或提供有关事件的额外信息(例如订购部件，致电供应商，长期监控问题)。
· 负责执行任务的人员姓名。
· 预期或要求完成任务的日期。
推荐：
· 建议应采取各种可以防止未来事故发生的措施。如果故障分析报告涵盖这一部分内容，则可以跳过此步骤，但可以在任何情况下使用故障分析报告来推荐短期活动以减少故障连带反应的风险。
支持信息
这里可以添加任何支持信息，如插入照片，图表，附件文件名称，链接等的地方。语言必须是专业，准确，简洁，并且限于已经发生的事实。它应通过专业口吻传达必要的信息，无需通过叙事的方式描述事实。考虑到报告通常是给更多专业人士看，他们想要看到的是相关事实，而不是小说，或对任何人的行为道歉。避免长篇大论，建议将项目分成一系列带时间标记的步骤，显示活动的进展。任何对事故原因的猜测都应被推迟，除非原因显而易见与容易理解的。
报告的目的是通知与故障相关的人发生的故障情况，不是原因分析，这通常在后续的故障分析报告中显示。报告中的图片是非常有用的。每个步骤应该有已知的时间戳。当事件超过一天，应插入日期分隔符，其中包含模板中提供的新一天的第一个条目。
故障分析和经验教训
故障分析过程旨在提供一种确定和记录事件原因的标准方法，可以方便随时进行此类调查。它侧重于情况为什么发生。故障分析报告应该提供对发生在何处，何时以及如何响应的描述。这可以通过简单地参考事故报告或附加事件报告作为参考文件来完成。准确详细的问题记录可以为为运维人员提供宝贵的“经验教训”。当事件报告完成时对事件的完全理解尚未完成时，需要提供故障分析报告。
一旦事件得到解决，有一些问题需要考虑：
·故障分析：如果事故报告中没有写明事故发生主要原因，则应创建完整故障分析报告。这需撰写事件报告作者以及事件参与所有人的参与完成此报告。
·整合：对现有规定与流程进行重新审核，确保是否需要改善流程，从而有效防止或避免未来该类事件发生。
·经验教训：事故发生后，将事故报告发给运维人员学习，这对运维人员是难得的学习经验，应为此创建经验教训文件供运维人员学习。将经验教训资料与EOP、SOP交叉参考学习，对于运维人员是很好的培训、学习资料。
·归档：所有已结束的事件报告上传到文档管理系统并做出标识。
本文转自d1net（转载）
