当进行演练评估时，需考虑以下几点：

　　三、事件管理

　　• 为演练预演做简报，并提前提供评估记分卡，向工程师解释测试。

　　• 经验丰富评估员应事先熟悉脚本，再对演练进行记录与评估。

　　• 应在演练之前安装标志，以便告知正在进行评估的工程师演练情况以及报警情况。

　　• 评估人员在评估中扮演实时口述宣布改变报警状态与设备状态的角色，例如“发电机不会与母线同步”或“有来自UPS的报警面板”。

　　• 观察者不应帮助工程师确定解决方案，除非提供工程师有效信息，例如“该面板显示在1的位置”。

　　• 当获得解决方案或者评估人员不需要运维团队再解决什么问题的时候，评估结束。

　　• 评估人员对照评估记分卡上详细标准对工程师进行评估和记录，然后与工程师详细沟通评估全部内容，评估人员向工程师说明他们做对的部分，同时向他们详细解释他们做错什么。这需在评估后立马安排去做。

　　*事件管理

　　什么是事件?

　　关键设备中的“事件”是指由于意外、不寻常的、或突发事件导致的影响设备操作或安全的事件。

　　•设备或系统故障

　　•运维人员受伤/设施设备受损

　　网络通信故障/UPS报警/温度升高，超过阈值/UPS由市电供电切换到电池供电/面板断路器跳闸/烟雾报警器关闭/入侵报警/漏水传感器报警

　　• 关键设备需投入大量资金与人力来确保业务持续运行。这些设备环境条件应受到高度管理与监控。作为控制方案的一部分，重要的是要注记录和报告可能影响操作或安全性的任何意外事件。如果处理不当，这些事件可能成为危机，甚至是灾难。具有良好的应急准备和响应能力的组织将具有事件管理过程，该过程提供处理这些事件的标准化方法。一个有效的过程有三个元素：事件通知，事件报告和故障分析。

　　• 事件通知和标识事件通知包括提醒利益相关者发生事件的系统，过程和人员。重要的是及时通知事件。“及时”的意思将取决于事件的严重性和紧急性。环境中的烟雾将显然需要比涉及与单个环境传感器的通信丢失的事件更快速的通知。谁应该警告需要提前确定和计划。如前面表3所示，事故可以按紧急程度或临界程度分类。然后，该分类系统可以管理需要被通知的人，时间和频率。当然，假设基础设施系统被计量，装备和与软件通信，包括楼宇管理系统(BMS)在内的数据中心基础设施管理(DCIM)软件可以非常有助于简化和自动化事件通知(和报告)。可以集中配置和管理告警阈值和通知策略。太多警报或不正确的通知可能会导致系统无效。

　　事件报告

　　事件报告是一个通用流程，可能会改善或替代现有现有系统(例如，DCIM或BMS)或者现有的流程。以下部分涵盖从事件发生到事件响应以及后续行动的事件报告过程。

　　一旦检测到初始事件，做出及时响应并通知与事件相关的人; 建议事故报告在24小时内完成，并发送给所有与此事相关者。一旦有时间开始填写报告(当事件在人们心中是还记忆犹新)，如果情况允许，在整个事件期间需不断完善报告。

　　应使用标准化模板报告所有事件。这有助于确保收集信息的完整性。它应存储在计算机化文档管理系统(CDMS)中。报告应包含以下信息。

　　• 报告信息

　　• 报表标题

　　• 提交报告日期

　　• 创建报表的日期和时间

　　• 报告提交的日期和时间网站信息

　　数据中心信息

　　• •地址，城市，州或省，邮政编码，国家/地区

　　• 联系方式

　　事件报告创建者事件概述

　　• 事件简要说明

　　• 事件影响位置(例如发电机舱，UPS房间或整个设施)

　　• 涉及的设备

　　• 事件属性事件详细信息

　　• 事件和持续时间的时间/日期

　　• 谁发现

　　• 谁在场

　　• 描述初始响应操作

　　• 谁被通知和什么时候

　　• 情况如何稳定或解决

　　• 使用哪些资源

　　• 事件持续跟进：一旦初始事件被记录，后续将持续记录可能在这个事件中会发生的问题。例如，当系统组件发生故障并通过冗余单元恢复运行并致电供应商前往修复时，可能会发生事件。

　　故障部分。事故报告需要立即填写，并在批准与分配之前修复被影响的部分。一旦供应商开始进行升级工作时，需在报告中有所体现。

　　行动项目

　　• 这是针对特定事件发生制定的具体行动。

　　• 特定任务时用来纠正或提供有关事件的额外信息(例如订购部件，致电供应商，长期监控问题)。

　　• 负责执行任务的人员姓名。

　　• 预期或要求完成任务的日期。

　　推荐：

　　• 建议应采取各种可以防止未来事故发生的措施。如果故障分析报告涵盖这一部分内容，则可以跳过此步骤，但可以在任何情况下使用故障分析报告来推荐短期活动以减少故障连带反应的风险。

　　支持信息

　　这里可以添加任何支持信息，如插入照片，图表，附件文件名称，链接等的地方。语言必须是专业，准确，简洁，并且限于已经发生的事实。它应通过专业口吻传达必要的信息，无需通过叙事的方式描述事实。考虑到报告通常是给更多专业人士看，他们想要看到的是相关事实，而不是小说，或对任何人的行为道歉。避免长篇大论，建议将项目分成一系列带时间标记的步骤，显示活动的进展。任何对事故原因的猜测都应被推迟，除非原因显而易见与容易理解的。

　　报告的目的是通知与故障相关的人发生的故障情况，不是原因分析，这通常在后续的故障分析报告中显示。报告中的图片是非常有用的。每个步骤应该有已知的时间戳。当事件超过一天，应插入日期分隔符，其中包含模板中提供的新一天的第一个条目。

　　故障分析和经验教训

　　故障分析过程旨在提供一种确定和记录事件原因的标准方法，可以方便随时进行此类调查。它侧重于情况为什么发生。故障分析报告应该提供对发生在何处，何时以及如何响应的描述。这可以通过简单地参考事故报告或附加事件报告作为参考文件来完成。准确详细的问题记录可以为为运维人员提供宝贵的“经验教训”。当事件报告完成时对事件的完全理解尚未完成时，需要提供故障分析报告。

　　一旦事件得到解决，有一些问题需要考虑：

　　•故障分析：如果事故报告中没有写明事故发生主要原因，则应创建完整故障分析报告。这需撰写事件报告作者以及事件参与所有人的参与完成此报告。

　　•整合：对现有规定与流程进行重新审核，确保是否需要改善流程，从而有效防止或避免未来该类事件发生。

　　•经验教训：事故发生后，将事故报告发给运维人员学习，这对运维人员是难得的学习经验，应为此创建经验教训文件供运维人员学习。将经验教训资料与EOP、SOP交叉参考学习，对于运维人员是很好的培训、学习资料。

　　•归档：所有已结束的事件报告上传到文档管理系统并做出标识。

　　作者： Leonid Shishlov Mark Rentzke 张永萍 Patrick Donovan

　　责任编辑：DJ编辑